기본 개념
커널, 클라이언트, 프록시 서비스의 차이를 알아보고 모드 전환의 적용 범위를 확인합니다.
Clash Meta, mihomo 커널, GUI 클라이언트는 어떤 관계인가요?
Clash Meta는 이 커널 프로젝트에서 과거에 사용하던 이름이며, 현재는 mihomo라는 이름으로 관리됩니다. 커널은 프록시 프로토콜, 규칙 매칭, DNS, 연결 처리를 담당하고, GUI 클라이언트는 커널 외부에서 구독 관리, 정책 선택, 시스템 프록시, 로그 화면을 제공합니다. 클라이언트 이름이 다르다고 해서 사용하는 커널까지 반드시 다른 것은 아닙니다. 설정 호환성을 확인할 때는 먼저 정보 화면이나 시작 로그에서 커널 이름과 버전을 확인한 뒤 관련 문서를 살펴보세요. GUI를 업데이트해도 커널이 함께 업데이트되는 것은 아니며, 일부 클라이언트에서는 커널 관리 메뉴에서 별도로 업데이트해야 합니다.
Clash Meta 클라이언트를 설치했는데 구독이 왜 필요한가요?
클라이언트는 연결 및 트래픽 분기 기능을 제공하지만, 그 자체가 프록시 서비스는 아닙니다. 사용 가능한 설정에는 보통 프록시 서버 주소와 포트, 인증 정보, 해당 프록시를 참조하는 정책 그룹과 규칙이 포함되어야 합니다. 구독은 이런 설정을 배포하는 방법 중 하나이므로 실제 서비스 제공업체에서 받아야 합니다. 직접 구축한 서버가 있다면 설정 파일을 직접 작성할 수도 있습니다. 가져오기 전에 구독 형식이 Clash 또는 mihomo와 호환되는지 확인하고, 구독 URL은 로그인 정보처럼 안전하게 보관하세요. 전체 URL을 공개 로그나 스크린샷, 온라인 변환 사이트에 올리지 마세요. 특히 URL 쿼리 매개변수에 포함된 인증 정보를 주의해야 합니다.
규칙 모드, 전역 모드, 직접 연결 모드 중 무엇을 선택해야 하나요?
일상적인 트래픽 분기에는 보통 규칙 모드, 즉 mode: rule을 사용합니다. 연결은 rules를 위에서 아래로 확인해 일치하는 항목의 정책으로 전달됩니다. 전역 모드는 커널이 처리하는 연결을 전역 정책으로 보내며, 이때도 사용 가능한 프록시를 선택해야 합니다. 커널로 전달되지 않은 앱의 트래픽까지 자동으로 처리하지는 않습니다. 직접 연결 모드에서는 커널이 처리하는 연결이 목적지에 바로 접속합니다. 문제를 확인할 때 잠시 전역 모드로 바꿔 규칙이 원인인지 테스트할 수 있지만, 테스트 후에는 원래 모드로 되돌리세요. 모드 설정과 트래픽을 커널로 전달하는 방식은 별개입니다. 전역 모드를 켜도 시스템 프록시나 TUN을 대신할 수 없고, 모든 UDP 트래픽이 프록시를 통과한다고 보장할 수도 없습니다.
Clash for Windows 지원이 중단된 뒤에도 기존 설정을 옮겨 사용할 수 있나요?
대부분의 기본 YAML 설정은 옮길 수 있지만, 원본 구독과 클라이언트 덮어쓰기 설정, 스크립트는 구분해야 합니다. 먼저 구독 URL을 내보내고 로컬 설정, 사용자 지정 규칙, 정책 그룹 이름을 백업한 다음 현재도 관리되는 mihomo 커널 클라이언트를 설치하세요. 원본 구독을 먼저 가져와 기본 연결을 확인하고, 덮어쓰기 설정은 하나씩 복원합니다. 이전 클라이언트의 스크립트 인터페이스, 설정 디렉터리, 시스템 통합 기능은 호환되지 않을 수 있으므로 프로그램 폴더 전체를 복사하면 안 됩니다. 이전이 끝나면 구형 클라이언트의 시스템 프록시, 백그라운드 서비스, 시작 프로그램 설정을 해제해 두 커널이 포트를 놓고 경쟁하거나 라우팅을 중복 변경하지 않도록 하세요.
설치 및 설정
구독을 가져오는 단계부터 커널 실행까지 응답 내용, 수신 포트, 시스템 권한을 우선 확인하세요.
구독을 가져오지 못하거나 업데이트 후 작동하지 않을 때 먼저 무엇을 확인해야 하나요?
설정 또는 구독 관리 메뉴에서 직접 업데이트한 뒤 응답 상태와 오류 내용을 확인하세요. 401이나 403은 인증, 권한 또는 접근 정책 문제일 가능성이 높고, 404가 나오면 주소를 확인해야 합니다. 시간 초과라면 먼저 구독 도메인에 접속할 수 있는지 확인하세요. 다운로드는 성공했지만 파싱 오류가 발생한다면 응답이 로그인 페이지나 오류 페이지인지, Clash 설정 형식이 맞는지 확인합니다. 구독을 업데이트하기 전에는 정상 작동하는 설정을 복사해 두고, 반복해서 삭제한 뒤 다시 만들지 마세요. 현재 프록시를 통해 구독을 업데이트하도록 설정되어 있는지도 확인하세요. 프록시를 사용할 수 없다면 네트워크 상태가 허용하는 경우 직접 연결로 업데이트한 다음 서비스 제공업체에 구독 유효 기간을 문의하세요.
mixed-port: 7890은 무엇이며 포트 충돌은 어떻게 해결하나요?
mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받는 혼합 수신 포트입니다. 7890은 자주 쓰이는 값일 뿐 필수 설정은 아닙니다. 앱에서 프록시를 직접 설정한다면 클라이언트가 실제로 수신 중인 주소와 포트를 입력하세요. 로컬 PC에서는 보통 127.0.0.1을 사용합니다. 시작 로그에 address already in use가 표시되면 다른 프록시 클라이언트와 남아 있는 커널 프로세스를 종료한 뒤 포트 사용 현황을 확인하세요. 사용 가능한 다른 포트로 변경할 수도 있지만 시스템 프록시, 브라우저 확장 프로그램, 명령줄 환경 변수도 함께 수정해야 합니다. 일부 클라이언트는 구독에 지정된 포트를 덮어쓰므로 설정 화면과 시작 로그에 표시된 최종 값을 기준으로 삼으세요.
TUN 모드에서 권한 부족 오류가 표시될 때 서비스가 정상인지 어떻게 확인하나요?
TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 변경하므로 보통 관리자 권한이나 클라이언트가 제공하는 권한 서비스가 필요합니다. Windows에서는 서비스 모드가 설치되어 실행 중인지 확인한 뒤 클라이언트 안내에 따라 권한을 부여하세요. macOS에서는 보조 프로그램을 설치하고 시스템 권한을 승인해야 합니다. Linux에서는 서비스 계정에 필요한 네트워크 권한이 있는지 확인하세요. TUN 스위치가 켜졌다는 이유만으로 트래픽이 정상적으로 전달된다고 판단하지 말고, 인터페이스 생성 및 라우팅 설정 로그도 확인해야 합니다. 장치가 사용 중이라는 오류가 나오면 다른 VPN이나 가상 네트워크 어댑터 서비스를 먼저 중지하세요. 권한을 복구한 뒤 커널을 다시 시작해 보세요. 오류를 피하려고 방화벽을 끄거나 제어 인터페이스의 노출 범위를 넓히는 것은 권장하지 않습니다.
config.yaml을 수정한 뒤 오류가 발생합니다. YAML 들여쓰기 문제는 어떻게 찾나요?
오류가 발생한 파일을 먼저 보관한 뒤 로그에 표시된 줄 번호와 앞뒤 내용을 살펴보세요. YAML 들여쓰기에는 탭이 아닌 공백을 사용해야 합니다. 같은 단계의 키는 같은 위치에 맞추고, 목록 항목은 하이픈으로 표시하며, 키와 값 사이에는 공백을 둡니다. 로그의 줄 번호는 파서가 더 이상 읽지 못한 위치일 때가 많아 실제 오류는 바로 앞 줄에 있을 수 있습니다. 커널 프로그램을 직접 실행할 수 있다면 mihomo -t -f config.yaml로 설정을 검사하세요. 경로는 실제 파일 위치를 지정해야 합니다. 정책 그룹과 규칙에서 참조하는 이름이 실제로 존재하는지도 확인하세요. 구독 관리형 클라이언트에서는 덮어쓰기 메뉴에서 수정하는 편이 좋습니다. 다운로드 캐시를 직접 편집하면 다음 업데이트 때 변경 내용이 사라질 수 있습니다.
활용 팁
사용자 지정 규칙, 시작 프로그램, 여러 기기 간 동기화, DNS 요청 경로를 확인합니다.
Clash 사용자 지정 규칙은 어디에 추가하나요? 새 규칙이 적용되지 않는 이유는 무엇인가요?
규칙 모드는 rules에 적힌 순서대로 매칭합니다. 사용자 지정 규칙은 먼저 일치할 수 있는 포괄적인 규칙보다 앞에 두고, 특히 마지막 MATCH 뒤에는 추가하지 마세요. 예를 들어 DOMAIN-SUFFIX,github.com,PROXY 규칙을 사용하려면 PROXY라는 정책 또는 프록시 그룹이 있어야 하며, 이름은 문자 하나까지 정확히 일치해야 합니다. 구독 업데이트로 수정 내용이 덮어쓰이지 않도록 클라이언트의 규칙 덮어쓰기나 우선 규칙 메뉴를 사용하세요. 저장한 뒤 설정을 다시 불러오고 연결 상세 정보에서 실제로 일치한 규칙과 정책 경로를 확인합니다. 이미 연결된 장시간 연결은 기존 경로를 계속 사용할 수 있으므로 테스트 전에 해당 연결을 종료하고 다시 접속하세요. 도메인 규칙으로 앱에 하드코딩된 IP 주소 요청을 직접 매칭할 수는 없습니다.
Clash를 시작 프로그램에 등록했는데도 인터넷에 연결되지 않으면 어떤 설정을 확인해야 하나요?
클라이언트 시작, 커널 시작, 시스템 프록시 사용, TUN 사용은 각각 별개의 상태이므로 따로 확인해야 합니다. 시스템을 재부팅한 뒤 클라이언트가 백그라운드에서 실행 중인지, 현재 설정이 불러와졌는지, 커널이 포트를 정상적으로 수신하는지 확인한 다음 시스템 프록시나 TUN이 복구되었는지 살펴보세요. 서비스 모드를 사용하는 경우에는 서비스 시작 유형과 실행 상태도 확인해야 합니다. 화면에는 클라이언트가 실행 중으로 보여도 권한 서비스가 아직 준비되지 않았을 수 있습니다. 로그인 시점에 네트워크가 연결되지 않았다면 구독 업데이트나 연결 테스트가 일시적으로 실패할 수 있으므로 네트워크가 준비된 뒤 다시 시도하세요. 여러 클라이언트를 동시에 시작 프로그램에 등록하지 마세요. 클라이언트를 바꿀 때는 이전 프로그램이 남긴 프록시와 서비스 설정을 먼저 정리해야 합니다.
PC와 스마트폰에서 같은 구독과 설정을 함께 사용할 수 있나요?
같은 구독을 사용할 수는 있지만, 먼저 서비스에서 허용하는 기기 수와 동시 접속 제한을 확인해야 합니다. 프록시 목록과 규칙은 대체로 재사용하기 쉽지만, TUN, DNS 수신 주소, 인터페이스 이름, 파일 경로, 외부 제어 인터페이스는 기기별로 덮어써야 할 수 있습니다. 공통 설정은 구독 관리에 맡기고 포트 및 시스템 통합 설정은 각 기기의 클라이언트에 두는 것이 좋습니다. 파일을 동기화할 때 인증 정보가 포함된 구독 URL을 공개하지 말고, 제어 인터페이스의 접근 자격 증명을 공개 저장소에 올리지 마세요. 기기를 바꾼 뒤에는 정책 그룹 선택이 복원되었는지 확인해야 합니다. 설정 파일이 같아도 시스템 네트워크 스택, VPN 권한, 백그라운드 정책에 따라 동작이 달라질 수 있습니다.
Clash DNS 유출은 어떻게 확인하나요? fake-ip를 사용하면 모든 트래픽이 처리되나요?
fake-ip는 가상 주소를 도메인 정보에 연결해 보존하는 기능이지, 모든 DNS 요청이 자동으로 커널을 통과한다는 뜻은 아닙니다. 먼저 dns.enable이 켜져 있는지 확인하고 시스템 DNS, TUN의 DNS 가로채기 규칙, 브라우저나 앱에서 암호화 DNS를 별도로 사용하는지 살펴보세요. 커널 로그와 시스템 네트워크 설정을 함께 확인해 DNS 요청 경로를 파악하세요. 온라인 검사 페이지에 표시되는 리졸버 위치는 참고 자료일 뿐입니다. DNS를 변경한 뒤에는 시스템과 브라우저의 캐시를 지우고 연결을 다시 설정하세요. 검사 결과가 예상과 다르다고 nameserver를 무작정 여러 개 추가하지 마세요. 어떤 요청을 시스템이 해석하고 어떤 요청을 커널에 맡기는지, 상위 DNS 연결에 어떤 라우팅을 사용하는지 먼저 확인해야 합니다.
문제 해결
증상에 따라 비교 테스트를 진행하고, 설정은 한 번에 하나씩 변경하며 복구할 수 있도록 보관하세요.
노드 연결 테스트가 시간 초과될 때 서버 문제인지 설정 문제인지 어떻게 구분하나요?
테스트 시간 초과는 지정된 시간 안에 해당 테스트 요청이 완료되지 않았다는 뜻일 뿐, 이것만으로 서버가 중단되었다고 단정할 수는 없습니다. 먼저 시스템 시간이 정확한지, 구독이 최신 상태인지 확인한 다음 로그에서 도메인 확인 실패, 연결 거부, 핸드셰이크 실패, 인증 오류를 살펴보세요. 같은 설정으로 다른 네트워크에서 테스트하면 로컬 네트워크 제한과 원격 서버 문제를 구분하는 데 도움이 됩니다. 같은 정책 그룹의 다른 프록시로 바꿔 비교할 수도 있습니다. 속도 테스트만 실패하고 실제 접속은 정상이라면 테스트 주소와 시간 초과 설정을 확인하세요. 서비스 제공업체에 문의할 때는 오류 유형과 발생 시간을 남기고 서버 인증 정보는 가리세요. 시간 초과 화면만 보내는 것은 피하세요.
시스템 프록시를 켰는데 터미널이나 일부 앱은 왜 직접 연결되나요?
시스템 프록시는 해당 설정을 따르는 앱에 프록시 주소를 제공할 뿐, 모든 트래픽을 투명하게 가로채지는 않습니다. 일부 터미널 프로그램은 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY 환경 변수를 사용하고, 다른 프로그램은 자체 프록시 설정만 인식합니다. 브라우저 확장 프로그램이 시스템 설정을 덮어쓸 수도 있습니다. 먼저 커널이 실행 중인지 확인한 뒤 curl -I -x http://127.0.0.1:7890 https://example.com 명령으로 프록시를 명시해 테스트하세요. 포트는 실제 수신 포트로 바꿔야 합니다. 이 방식으로 연결된다면 앱이 프록시 설정을 가져오는 위치와 제외 목록을 확인하세요. 시스템 프록시를 따르지 않는 앱까지 처리해야 한다면 TUN 모드를 검토할 수 있지만, 라우팅과 권한, 다른 VPN과의 충돌도 확인해야 합니다.
Windows 스토어 앱이 연결되지 않을 때 UWP 루프백 제한은 어떻게 해결하나요?
AppContainer로 격리된 일부 앱은 로컬 루프백 프록시에 직접 접속하지 못할 수 있습니다. 브라우저는 정상인데 특정 앱만 실패한다면 루프백 제한을 확인하세요. 먼저 해당 앱이 실제로 로컬 프록시를 사용하는지 확인한 뒤 클라이언트에서 제공하는 루프백 예외 도구를 사용하거나 관리자 터미널에서 CheckNetIsolation LoopbackExempt -s를 실행해 현재 예외 목록을 확인합니다. 수동으로 추가할 때는 CheckNetIsolation LoopbackExempt -a -n= 뒤에 대상 앱의 패키지 패밀리 이름을 입력하세요. 시작 메뉴에 표시되는 앱 이름을 입력하면 안 됩니다. 필요한 앱에만 권한을 부여하고 모든 앱의 제한을 한꺼번에 해제하지 마세요. 대안으로 TUN을 통한 처리를 시험해 볼 수 있지만, 효과는 앱의 네트워크 동작과 라우팅 설정에 따라 달라집니다.
Android에서 화면을 잠근 뒤 연결이 끊기거나 배터리 소모가 커질 때 백그라운드 실행은 어떻게 확인하나요?
시스템 설정의 앱 관리에서 클라이언트를 찾아 배터리 사용량, 백그라운드 활동, 자동 시작 권한을 확인하세요. 메뉴 이름은 제조사별로 다를 수 있습니다. 화면을 잠근 뒤 연결이 끊기면 백그라운드 실행을 허용하고 VPN 상태가 유지되는지 확인하는 동시에 다른 VPN 앱이 연결을 가로채지 않는지도 살펴보세요. 배터리 소모가 크다면 빈번한 재연결, 반복되는 구독 업데이트, 계속 출력되는 디버그 로그가 있는지 확인한 뒤 불필요한 연결 테스트를 끄고 변화를 비교합니다. 절전 설정을 한꺼번에 바꾸지 말고 한 번에 하나씩 조정해 비슷한 네트워크 환경에서 확인하세요. 신호가 약하거나 핫스팟을 공유하거나 백그라운드 요청이 많아도 배터리 소모가 늘 수 있으므로 클라이언트의 배터리 사용 비율만으로 커널 이상을 판단하지 마세요.
문제를 계속 확인하려면 증상별 문제 해결 절차 보기 →