Clash / mihomo · FAQ
Clash 자주 묻는 질문
설정 로드부터 트래픽 처리까지, 나타난 증상에 따라 점검할 항목을 찾아보세요. 먼저 요청이 코어에 들어오는지 확인한 다음 규칙, 출구, DNS를 점검하세요. 원래 설정을 보관하고 한 번에 한 가지 항목만 변경하면 쉽게 되돌릴 수 있습니다.
입문 가이드
클라이언트, 코어, 설정, 트래픽 처리 방식을 구분해 기능 스위치 상태와 실제 연결 결과를 혼동하지 마세요.
Clash, Clash Meta, mihomo는 어떤 관계인가요?
Clash는 프록시 코어와 설정 생태계를 가리키는 일반적인 이름입니다. Clash Meta는 관련 파생 코어가 사용했던 이름이며, 이후 mihomo라는 이름으로 개발이 이어지고 있습니다. 클라이언트는 설정 가져오기, 시스템 프록시, 연결 확인 등의 그래픽 기능을 제공합니다. 기능 지원 여부는 앱 이름만으로 판단하지 말고 클라이언트에 포함된 코어와 버전을 확인하세요. 오래된 가이드의 설정 항목도 현재 코어 문서와 대조해 서로 다른 코어의 설정을 혼용하지 않도록 합니다.
클라이언트를 설치했는데도 구독이나 설정이 필요한 이유는 무엇인가요?
클라이언트는 설정을 불러와 코어를 실행하지만, 설치만으로 원격 프록시 서비스를 사용할 수 있게 되지는 않습니다. 구독에는 보통 프록시 연결 정보, 정책 그룹, 규칙이 포함되며 직접 작성한 설정으로도 같은 기능을 구현할 수 있습니다. 먼저 설정이 신뢰할 수 있는 출처에서 왔는지 확인한 뒤 정상적으로 불러왔는지, 정책 그룹에 선택 가능한 항목이 있는지 점검하세요. 구독 주소에는 접속 정보가 포함되는 경우가 많으므로 공개 댓글이나 스크린샷, 온라인 변환 사이트에 올리지 마세요. 문제를 확인할 때는 민감 정보를 가린 오류 내용만 공유하세요.
규칙 모드, 전역 모드, 직접 연결 모드는 각각 언제 사용하나요?
규칙 모드는 rules 순서에 따라 코어에 들어온 연결에 정책을 적용하므로 일상적인 트래픽 분산에 적합합니다. 전역 모드는 해당 연결에 전역 정책을 적용해 특정 프록시 경로를 임시로 비교할 때 유용합니다. 직접 연결 모드에서는 연결이 대상에 바로 접속합니다. 모드는 코어에 전달된 트래픽의 처리 방식만 바꾸며, 시스템에서 트래픽을 가져오는 범위까지 바꾸지는 않습니다. 모드를 전환한 뒤에는 새 연결을 만들고 연결 기록을 확인하세요. 브라우저의 기존 장기 연결은 이전 경로를 계속 사용할 수 있습니다.
시스템 프록시와 TUN 모드는 어떻게 다르며, 둘 다 켜야 하나요?
시스템 프록시는 운영체제 설정을 통해 해당 설정을 따르는 앱이 로컬 프록시 포트에 연결하도록 합니다. TUN은 가상 네트워크 인터페이스와 라우팅으로 트래픽을 가져와 시스템 프록시를 사용하지 않는 일부 프로그램도 처리할 수 있습니다. 처음 설정할 때는 시스템 프록시로 먼저 확인한 뒤 필요에 따라 TUN을 켜세요. 두 기능을 처음부터 함께 사용할 필요는 없습니다. TUN 적용 범위는 라우팅, 제외 항목, 권한, 플랫폼에 따라 달라지므로 스위치가 켜져 있다는 이유만으로 모든 앱의 트래픽이 코어에 전달된다고 볼 수는 없습니다.
Clash iOS 클라이언트에서 데스크톱용 설정을 모두 그대로 사용할 수 있나요?
설정 파일을 가져올 수 있다고 해서 모든 항목이 적용된다고 단정할 수는 없습니다. 모바일 클라이언트는 구독 형식, 규칙 문법, 확장 필드, 네트워크 트래픽 처리 방식에 대한 지원이 데스크톱과 다를 수 있습니다. 클라이언트를 선택한 뒤 지원하는 설정 형식을 확인하고 가져오기 안내와 연결 기록을 살펴보세요. Clash Plus는 다운로드 페이지의 iOS 분류에서 App Store로 이동할 수 있으며 공식 사이트는 clashplus.io입니다. 데스크톱의 서비스 설치 및 시스템 프록시 설정 방법은 iOS에 적용되지 않습니다.
설치 및 설정
먼저 코어가 설정을 정상적으로 불러오는지 확인한 다음 포트, 권한, 업데이트 후 덮어쓰기 동작을 점검하세요.
구독 업데이트에 실패하거나 구독이 만료됐다고 표시될 때는 어떤 순서로 확인해야 하나요?
먼저 기기 시간, 현재 네트워크, 구독 계정 상태를 확인하세요. 그런 다음 주소를 빠짐없이 복사했는지, 공백이나 줄바꿈이 섞이지 않았는지, 접속 정보가 만료되지 않았는지 살펴보세요. 클라이언트에 표시된 HTTP 상태 코드도 기록하세요. 401과 403은 인증이나 접근 제한과 관련된 경우가 많고, 404는 주소가 변경됐을 수 있습니다. 시간 초과가 발생하면 네트워크 경로를 추가로 확인해야 합니다. 구독 업데이트에 프록시 설정을 사용할 수 있다면 직접 연결과 프록시 연결을 각각 테스트하세요. 아직 사용할 수 있는 기존 설정을 반복해서 삭제하거나 전체 구독 주소를 공개하지 마세요.
설정을 가져올 때 YAML 오류가 표시되면 문제 필드를 어떻게 찾나요?
오류 메시지에 나온 줄 번호와 필드명을 확인한 뒤 해당 줄과 바로 앞부분의 들여쓰기, 콜론, 목록 기호를 살펴보세요. YAML 들여쓰기에는 공백을 사용해야 합니다. 전각 콜론이나 탭 문자는 구문 분석 오류를 일으킬 수 있습니다. 구문 오류가 없는데도 코어가 설정을 거부한다면 정책 참조가 실제로 존재하는지, 현재 코어가 해당 필드를 지원하는지 확인하세요. 원본 파일은 보관하고 복사본에서 최근 변경 사항을 조금씩 되돌려 보세요. 구독 정보나 프록시 비밀번호가 포함된 전체 파일을 공개 온라인 검사 도구에 올리지 마세요.
mixed-port의 기본값은 7890인데, 변경한 뒤 어디를 더 수정해야 하나요?
mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 7890은 흔히 사용하는 값일 뿐 모든 클라이언트에서 고정으로 써야 하는 포트는 아닙니다. 값을 변경한 뒤 설정을 다시 불러오고 코어가 새 포트에서 실제로 대기 중인지 확인하세요. 그런 다음 시스템 프록시, 브라우저 확장 프로그램, 명령줄 환경 변수도 같은 포트로 바꾸세요. 클라이언트의 덮어쓰기 설정을 사용한다면 구독에 포함된 포트 항목을 덮어쓰는지도 확인해야 합니다. 설정 파일만 바꾸고 시스템에 이전 포트가 남아 있으면 클라이언트는 정상 실행되지만 앱이 연결되지 않을 수 있습니다.
TUN을 켤 수 없을 때 관리자 권한과 서비스 모드는 어떻게 확인하나요?
로그를 확인해 권한 부족, 가상 인터페이스 생성 실패, 라우트 설정 실패를 구분하세요. Windows 클라이언트는 백그라운드 서비스를 설치하고 시작해야 할 수 있으며, 클라이언트 안내에 따라 관리자 권한으로 실행해야 할 수도 있습니다. macOS에서는 관련 네트워크 권한을 승인해야 하고, Linux에서는 보통 TUN 장치와 네트워크 관리 권한이 필요합니다. 서비스 모드는 GUI 클라이언트의 실행 방식이지 범용 YAML 필드가 아닙니다. 권한을 승인하거나 서비스를 설치한 뒤 코어를 다시 시작하고 가상 인터페이스와 라우트를 확인하세요. 관련 없는 프로그램을 장기간 높은 권한으로 실행하지 마세요.
구독을 업데이트할 때마다 로컬 수정 사항이 덮어써집니다. 규칙과 DNS 설정을 어떻게 보존하나요?
구독 업데이트로 교체되는 캐시 파일에 장기간 관리할 규칙을 직접 작성하지 마세요. 클라이언트가 제공하는 덮어쓰기, 병합 또는 스크립트 기능을 사용해 개인 규칙과 DNS 변경 사항을 별도 위치에 저장하는 것이 좋습니다. 먼저 클라이언트의 병합 방식을 확인하세요. 목록이 교체되는지 추가되는지, 규칙 순서가 달라지는지 확인해야 합니다. 업데이트 후에는 편집기의 로컬 파일만 보지 말고 실제 적용된 최종 설정을 확인하세요. 클라이언트를 업그레이드하기 전에는 덮어쓰기 파일을 백업하고 정책 그룹 이름 간 의존 관계도 기록해 두세요.
사용 팁
연결 기록으로 정책 적용을 확인하고 탐지 결과, 규칙 일치, 실제 서비스 요청을 구분하세요.
정책 그룹에는 select, url-test, fallback 중 무엇을 선택해야 하나요?
select는 출구를 수동으로 고정할 때 적합합니다. url-test는 지정한 테스트 주소의 탐지 결과에 따라 구성원을 선택하고, fallback은 보통 구성원 순서대로 사용 가능한 항목을 선택합니다. 자동 탐지 결과는 테스트 대상과 테스트 시점에만 해당하며 모든 사이트와 프로토콜의 상태를 보장하지 않습니다. 자동 그룹을 select에 포함해 두면 필요할 때 수동으로 전환할 수 있습니다. 문제를 확인할 때는 사용 가능한 것으로 확인된 구성원을 고정하고 새 연결을 만드세요. 자동 전환으로 한 번의 테스트에 서로 다른 출구 결과가 섞이는 일을 막을 수 있습니다.
특정 웹사이트에 어떤 규칙이 적용됐는지 확인하려면 어떻게 하나요?
클라이언트의 연결 목록을 열고 대상 사이트에 다시 접속하세요. 도메인이나 프로세스로 필터링해 일치한 규칙, 대상 정책, 실제 출구 경로를 확인할 수 있습니다. 규칙은 대체로 위에서 아래로 검사하며 처음 일치하는 항목이 적용됩니다. 따라서 새 규칙은 먼저 적용될 수 있는 포괄적인 규칙보다 앞에 두어야 합니다. 도메인 없이 IP 주소만 표시된다면 DNS 경로와 스니핑 조건도 확인하세요. 설정을 변경한 뒤에는 해당 사이트의 기존 연결을 닫고 다시 테스트하세요. 웹페이지가 열리는지만 보고 규칙 적용 여부를 판단하지 마세요.
Fake-IP가 198.18 대역 주소를 반환하면 DNS 오류인가요?
Fake-IP를 사용하면 코어가 앱에 매핑 주소를 반환하고, 매핑 정보를 바탕으로 도메인을 복원해 트래픽을 분산할 수 있습니다. 설정에 fake-ip-range: 198.18.0.1/16이 지정돼 있다면 해당 대역의 주소가 반환되는 것만으로 오류라고 볼 수 없습니다. 중요한 점은 이후 연결이 매핑 정보를 관리하는 코어로 되돌아오는지입니다. LAN 기기 검색이나 특정 앱 호환성 문제가 있을 때만 필요한 도메인에 fake-ip-filter를 설정하세요. 매핑 주소가 보인다는 이유로 DNS 기능 전체를 끄지 마세요.
LAN에 연결된 다른 기기에서 이 기기의 Clash 프록시를 사용하려면 어떻게 하나요?
먼저 두 기기가 서로 통신할 수 있는 네트워크에 있는지 확인한 뒤 allow-lan, 수신 주소, 호스트 방화벽을 점검하세요. 다른 기기의 프록시 서버 주소에는 127.0.0.1이 아니라 클라이언트가 실행 중인 기기의 LAN IP를 입력하고, 실제로 대기 중인 mixed-port를 사용해야 합니다. 접근 허용 범위는 신뢰할 수 있는 LAN으로 제한하고 필요한 경우 인증을 설정하세요. 라우터에서 프록시 포트를 공용 인터넷에 노출하지 마세요. 호스트 IP 변경, 게스트 네트워크 격리, 무선 액세스 포인트 격리도 연결 실패의 원인이 될 수 있습니다.
연결 스위치 상태만 보지 않고 요청이 실제로 프록시를 통과하는지 확인하려면 어떻게 하나요?
확인할 대상을 정하고 먼저 해당 대상의 기존 연결을 정리하세요. 그런 다음 클라이언트 연결 목록에 요청이 표시되는지, 정책 경로가 예상과 일치하는지 살펴보세요. 브라우저 설정의 영향을 배제하려면 터미널에서 curl -I -x http://127.0.0.1:7890 https://example.com을 실행해 HTTP 프록시를 명시적으로 테스트할 수 있습니다. 포트는 실제 값으로 바꾸세요. 이 명령으로 확인할 수 있는 것은 해당 요청의 프록시 경로뿐이며, 시스템 프록시나 UDP, 모든 앱이 정상적으로 트래픽을 전달하는지까지 보장하지는 않습니다.
문제 해결
오류 메시지 원문과 발생 시간을 기록하고, 문제 범위를 좁힌 뒤 관련 항목을 조정하세요.
노드 테스트가 시간 초과되면 노드가 끊긴 건가요, 로컬 네트워크 문제인가요?
먼저 여러 구성원과 서로 다른 네트워크에서 결과를 비교하세요. 한 구성원만 실패한다면 해당 구성원의 접속 정보, 서비스 상태, 프로토콜 지원을 확인하세요. 모두 실패한다면 기기 시간, 네트워크 연결, DNS, 설정 로드 여부를 먼저 점검하세요. 테스트 주소에 접속할 수 있는지도 확인해야 합니다. 테스트 엔드포인트 자체에 문제가 있어도 여러 노드가 한꺼번에 시간 초과될 수 있습니다. 탐지에 성공했다고 실제 서비스가 항상 정상인 것은 아니며, 실패만으로 서비스 중단을 단정할 수도 없습니다. 실제 요청 결과와 로그의 핸드셰이크, 이름 확인, 연결 오류를 함께 살펴보세요.
시스템 프록시를 켰는데도 브라우저나 터미널이 직접 연결됩니다. 어떻게 점검하나요?
먼저 시스템 프록시의 주소와 포트가 코어의 실제 수신 설정과 일치하는지 확인하세요. 브라우저 확장 프로그램, 프록시 우회 목록, 설정을 변경하는 다른 프록시 프로그램도 점검해야 합니다. 터미널 프로그램은 운영체제의 프록시 설정을 읽지 않을 수 있으므로 HTTP_PROXY, HTTPS_PROXY를 별도로 설정하거나 프로그램의 명시적 프록시 옵션을 사용해야 할 수 있습니다. 프록시를 명시한 요청과 일반 요청을 비교하고 연결 기록을 살펴보세요. 명시적 프록시는 정상인데 일반 요청이 코어에 들어오지 않는다면 노드를 계속 바꾸기보다 앱이 프록시 설정을 읽는 방식을 확인하세요.
연결됨으로 표시되는데 웹페이지가 열리지 않습니다. DNS는 어떻게 확인하나요?
먼저 요청이 실제로 코어에 들어오는지 확인한 뒤 로그에서 이름 확인 실패, DNS 조회 시간 초과, 상위 서버 연결 실패가 있는지 살펴보세요. nameserver에 연결할 수 있는지 확인하고, 암호화 DNS를 사용한다면 해당 서버의 도메인을 확인하는 초기 DNS 경로도 점검해야 합니다. TUN을 사용할 때는 dns-hijack과 앱 자체의 보안 DNS가 예상 경로에 영향을 주는지 확인하세요. 한 번에 한 항목씩만 변경하고 설정을 다시 불러오세요. 필요하면 시스템 DNS 캐시를 비우고 연결을 새로 만드세요. 모든 DNS 항목을 동시에 바꾸면 문제의 원인을 찾기 어렵습니다.
Windows UWP 앱이 로컬 프록시를 사용하지 않을 때 루프백 제한을 어떻게 처리하나요?
AppContainer를 사용하는 일부 앱은 루프백 접근 제한으로 인해 일반 데스크톱 프로그램처럼 로컬 프록시에 연결하지 못할 수 있습니다. 먼저 대상 앱이 이 유형에 해당하는지 확인하고, 클라이언트에 루프백 예외 기능이 있다면 필요한 앱에만 권한을 부여하세요. 관리자 터미널에서 CheckNetIsolation LoopbackExempt -s를 실행해 기존 예외를 확인한 뒤 시스템 문서에 따라 특정 패키지를 설정할 수도 있습니다. 모든 앱의 접근을 한꺼번에 허용하지 마세요. 설정 후 대상 앱을 다시 시작하고 연결 목록에서 요청 경로를 확인하세요.
클라이언트를 종료한 뒤 인터넷에 연결되지 않습니다. 시스템 네트워크를 어떻게 복구하나요?
먼저 시스템 프록시가 더 이상 수신하지 않는 로컬 포트를 가리키는지 확인하세요. 남아 있는 프록시 설정을 끄거나 클라이언트를 다시 시작한 뒤 정상적으로 종료하세요. TUN을 사용했다면 백그라운드 서비스, 가상 인터페이스, 라우트가 복구됐는지도 점검하세요. 네트워크 프로그램 여러 개를 동시에 종료하면 상태를 파악하기 어려워질 수 있습니다. 필요하면 운영체제 설정에 따라 DNS 자동 설정을 복원하고 네트워크 연결을 다시 만드세요. 알 수 없는 네트워크 어댑터를 삭제하거나 모든 라우트를 지우지 마세요. 오류 전후의 설정과 로그를 보관하고 복구한 뒤 관련 기능을 하나씩 다시 시작하세요.