Clash 자주 묻는 질문

Clash는 규칙 기반 프록시 도구와 그 설정 생태계를 가리킵니다. 클라이언트는 주로 구독 가져오기, 정책 선택, 시스템 프록시 설정, 로그 표시를 담당하고, 코어는 연결과 DNS, 규칙 매칭을 처리합니다. mihomo는 이 생태계에서 계속 개발되고 있는 코어입니다. 클라이언트마다 사용하는 코어와 지원하는 설정 항목이 다를 수 있습니다. 문제를 진단할 때는 먼저 정보 또는 코어 정보 화면에서 클라이언트와 코어의 이름 및 버전을 기록한 다음 해당 문서를 확인하세요. 화면에 옵션이 있다고 해서 현재 로드된 코어가 관련 설정을 모두 지원하는 것은 아닙니다.

설치가 끝나도 클라이언트만 실행할 수 있을 뿐, 프록시 설정은 별도로 필요합니다. 서비스 제공업체의 Clash 구독을 가져오거나 직접 관리하는 YAML 파일을 사용할 수 있으며, 설정에는 사용 가능한 노드와 프록시 그룹, 규칙이 포함되어야 합니다. 사이트의 튜토리얼과 설정 예시는 항목 간 관계를 설명하기 위한 것으로 실제 서비스를 대신하지 않습니다. 가져오기 전에 구독 형식이 코어와 호환되는지 확인하고, 가져온 뒤 노드가 표시되는지 확인한 다음 정책을 선택하고 시스템 프록시를 켜세요. 구독 URL에는 접속 자격 증명이 포함되는 경우가 많으므로 계정 비밀번호처럼 안전하게 보관해야 합니다.

규칙 모드는 rules의 순서대로 연결을 매칭하고, 일치하는 규칙의 지정된 정책을 적용합니다. 사이트별로 트래픽을 나누는 일상적인 사용에 적합합니다. 전역 모드는 코어로 들어오는 연결에 전역 정책을 적용하므로 문제가 규칙에서 비롯됐는지 임시로 확인할 때 유용합니다. 다만 모든 앱의 연결을 가로채는 것은 아닙니다. 직접 연결 모드는 코어로 들어온 연결을 대상에 직접 연결하지만, DNS 처리는 코어를 거칠 수 있습니다. 모드를 바꾼 뒤에는 새 연결로 확인하세요. 기존 장기 연결은 이전 경로를 계속 사용할 수 있으므로 열려 있던 탭만 보고 전환 결과를 판단하면 안 됩니다.

기존 설정의 일반 항목은 마이그레이션의 출발점으로 활용할 수 있지만, 새 클라이언트가 사용하는 코어에서 실제로 지원하는지 확인해야 합니다. 옮기기 전에 설정을 내보내고 프록시 그룹 선택, 시스템 프록시 포트, TUN 및 DNS 설정을 기록하세요. 가져온 뒤 문법 오류가 없는지 확인하고 연결을 테스트합니다. 이전 클라이언트의 화면 설정이나 스크립트, 오버라이드 방식은 그대로 옮기지 못할 수 있습니다. 다운로드 페이지에서 지속적으로 관리되는 클라이언트를 선택하고, 오류 메시지를 참고해 항목을 하나씩 조정하세요. 새 클라이언트가 정상 작동하는 것을 확인한 다음 이전 클라이언트의 자동 실행과 프록시 서비스를 끄면 네트워크를 동시에 가로채는 일을 방지할 수 있습니다.

클라이언트의 설정 또는 구독 화면에서 URL 가져오기를 선택하고 전체 주소를 붙여 넣으세요. 다운로드가 완료되면 해당 설정을 현재 사용 항목으로 지정합니다. 구독을 추가만 하고 활성화하지 않으면 노드 화면에 이전 내용이 계속 표시될 수 있습니다. 목록이 비어 있다면 응답이 Clash YAML인지 확인하세요. 로그인 페이지나 오류 메시지, 다른 도구용 인코딩 목록이면 안 됩니다. 이어서 설정에 proxies가 있는지, 또는 proxy-providers에서 노드를 정상적으로 가져왔는지 확인합니다. 구독 URL을 공개 변환 사이트에 붙여 넣지 말고 서비스 제공업체가 안내하는 호환 링크를 사용하세요.

먼저 업데이트 로그에서 HTTP 상태 코드와 오류 유형을 확인하세요. 401 또는 403은 자격 증명이나 권한, 서비스 제공업체의 제한과 관련 있을 수 있고, 404는 주소가 변경됐을 가능성이 있습니다. 시간 초과라면 네트워크와 도메인 확인을 추가로 살펴보세요. 서비스 제공업체 계정 페이지에서 링크를 다시 복사하고 계정 상태와 구독 초기화 여부를 확인합니다. 업데이트에 프록시가 필요한데 현재 노드를 사용할 수 없다면, 클라이언트가 지원하는 방식으로 직접 연결 다운로드로 전환하거나 임시로 사용 가능한 설정을 적용하세요. 업데이트 전에 로컬 사본을 보관하세요. 설정을 삭제해도 원격 링크는 복구되지 않으며, 기존에 사용 가능했던 노드만 잃을 수 있습니다.

먼저 로그에 표시된 줄 번호와 항목 이름을 확인하고 해당 줄의 앞뒤도 살펴보세요. 파서가 표시한 줄은 문제가 발견된 위치일 뿐, 실제 원인은 다른 곳일 수 있습니다. YAML은 공백으로 들여쓰며 같은 단계의 들여쓰기 폭을 일치시켜야 합니다. Tab으로 대신할 수 없습니다. 콜론 뒤 공백, 목록의 하이픈, 따옴표가 닫혔는지, 정책 이름과 노드 이름이 정확히 일치하는지 확인하세요. 특수 문자가 포함된 이름은 짝이 맞는 따옴표로 감쌀 수 있습니다. 한 번에 한 항목만 수정하고 설정을 다시 확인하세요. 오류가 생기면 가장 최근 변경 사항을 되돌립니다. 구독에서 생성한 파일은 다음 업데이트 때 수정 내용이 사라지지 않도록 오버라이드 기능으로 조정하는 것이 좋습니다.

먼저 클라이언트에서 사용하는 코어가 TUN을 지원하는지 확인한 다음, 해당 클라이언트 안내에 따라 서비스를 설치하거나 시스템 권한을 승인하세요. Windows에서는 관리자 권한이나 서비스 모드가 필요한 경우가 많고, macOS에서는 보조 구성 요소 또는 관련 네트워크 권한을 승인해야 할 수 있습니다. Linux에서는 적절한 네트워크 관리 권한과 사용 가능한 TUN 장치가 필요합니다. 권한을 승인한 뒤 코어를 다시 시작하고 라우팅 또는 장치 생성 오류가 계속 발생하는지 확인하세요. 경로 충돌을 피하려면 다른 VPN의 네트워크 가로채기 기능도 끄세요. 권한 상승 명령을 반복해서 추가하지 말고, 로그를 바탕으로 권한 부족, 장치 누락, 주소 충돌을 구분해 원인에 맞게 조치하세요.

select는 사용자가 노드나 다른 정책을 직접 선택하는 방식으로, 출구를 고정해야 하는 경우에 적합합니다. url-test는 설정된 테스트 주소와 주기에 따라 후보를 비교하고, 코어가 지원하는 허용 오차 등의 설정을 바탕으로 출구를 선택합니다. 테스트 결과는 해당 대상에 대한 연결 상태만 보여줍니다. fallback은 후보 순서에 따라 사용 가능한 항목을 선택하며, 주 출구에 문제가 생겼을 때 전환하는 데 쓰입니다. 세 방식 모두 해당 연결에 적용되려면 규칙에서 참조해야 합니다. 정책을 변경한 뒤에는 새 연결을 만들어 어떤 그룹과 노드가 선택됐는지 확인하세요. 한 번의 테스트 결과를 모든 사이트의 실제 속도와 동일하게 보면 안 됩니다.

먼저 클라이언트가 제공하는 로컬 오버라이드, 규칙 추가 또는 병합 기능을 사용하고 적용 순서를 확인하세요. 규칙은 일반적으로 위에서 아래로 매칭되므로 도메인을 지정하는 정밀한 규칙은 포괄적인 규칙과 마지막 MATCH 규칙보다 앞에 두어야 합니다. 참조하는 정책 이름이 실제로 존재하고 대소문자까지 일치하는지도 확인하세요. 특정 도메인을 지정된 정책으로 보내려면 해당 프록시 그룹에 사용 가능한 출구가 있어야 합니다. 저장한 뒤 설정을 다시 불러오고 연결 기록에서 실제로 매칭된 규칙을 확인하세요. 구독 캐시 파일을 직접 수정하면 업데이트 때 덮어써질 수 있으니 사용자 지정 부분을 별도로 저장하고, 업데이트 후 병합 결과를 확인하세요.

각 설정의 출처와 용도를 구분할 수 있는 이름을 붙이고 로컬 파일인지 원격 구독인지 기록하세요. Profile을 전환한 뒤에는 활성 표시와 프록시 그룹, DNS 설정이 바뀌었는지 확인합니다. 시스템 프록시와 TUN 옵션은 클라이언트의 전역 설정일 수 있어 Profile과 함께 전환되지 않을 수 있습니다. 백업할 때는 원본 설정과 로컬 오버라이드, 필요한 클라이언트 설정도 함께 저장하세요. 노드 목록만 백업해서는 안 됩니다. 원격 구독은 업데이트할 때 내용이 대체되는 경우가 많지만, 로컬 파일은 사용자가 직접 관리합니다. 기기를 바꿀 때는 설정 하나를 먼저 가져와 검증한 다음 추가 설정을 하나씩 복원하면 호환되지 않는 항목을 찾기 쉽습니다.

먼저 호스트와 다른 기기가 서로 통신할 수 있는 LAN에 연결되어 있고, 클라이언트에서 LAN 접속을 허용했으며, 적절한 인터페이스 주소를 수신하도록 설정했는지 확인하세요. 다른 기기의 네트워크 프록시 설정에 호스트의 LAN IP와 클라이언트가 실제로 사용하는 HTTP 또는 혼합 포트를 입력합니다. 127.0.0.1은 해당 기기 자신을 가리키므로 입력하지 마세요. 계속 연결되지 않으면 호스트 방화벽, 게스트 네트워크 격리, 포트 사용 여부를 확인하세요. 신뢰할 수 있는 네트워크에서만 접속을 허용하고 필요에 따라 프록시 인증과 방화벽 범위를 설정하세요. 외부 컨트롤러는 관리 인터페이스용이지 다른 기기의 인터넷 연결에 사용하는 프록시 포트가 아니며, 인터넷에 직접 노출해서도 안 됩니다.

먼저 일반 직접 연결 웹사이트에 접속할 수 있는지 확인한 다음 설정이 정상적으로 로드됐는지, 구독 계정이 유효한지 살펴보세요. 여러 노드를 비교해 한 노드만 실패한다면 해당 노드의 서비스 상태를 먼저 확인합니다. 모든 노드가 실패한다면 기기의 시간, DNS, 네트워크 제한, 클라이언트 로그를 살펴보세요. 테스트 주소에 접속할 수 없어도 시간 초과가 발생할 수 있으므로 테스트 버튼만 보지 말고 실제 대상에 새 연결을 만들어 확인하세요. 네트워크를 임시로 바꿔 비교할 수 있지만 한 번에 조건 하나만 바꾸세요. 로그에 인증 실패나 지원되지 않는 프로토콜이 표시되면 자격 증명과 호환성을 해결해야 합니다. 테스트 시간 초과 값을 계속 높이는 것은 해결책이 아닙니다.

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용되며 모든 연결을 자동으로 가로채지는 않습니다. 먼저 시스템에 설정된 프록시 주소와 포트가 클라이언트의 실제 수신 값과 일치하는지 확인하세요. 브라우저의 별도 프록시 확장 프로그램은 끄고 새 연결을 만들어 클라이언트의 연결 기록을 확인합니다. 명령줄 도구, 게임, 일부 앱은 프록시를 별도로 설정하거나 라우팅 요구 사항을 확인한 뒤 TUN을 사용해야 할 수 있습니다. 연결 기록에 요청이 있는데 DIRECT로 매칭된다면 시스템 프록시를 계속 바꾸지 말고 규칙과 정책 선택을 확인하세요. 다른 프록시 도구는 시스템 설정을 반복해서 덮어쓸 수 있으므로 종료하세요.

앱 컨테이너 제한을 받는 일부 Windows 앱은 로컬 루프백 프록시에 접속하지 못할 수 있습니다. 일반 데스크톱 브라우저는 정상 작동하는데 해당 앱만 안 된다면 루프백 제한을 확인하세요. 클라이언트가 로컬 주소를 수신하는지 확인하고, 필요한 앱 패키지에 한해 클라이언트에서 제공하는 UWP 루프백 도구나 Windows의 CheckNetIsolation 도구로 예외를 설정하세요. 관리자 권한이 필요할 수 있습니다. 앱마다 패키징 방식과 네트워크 동작이 다르므로 모든 스토어 앱이 이 문제에 해당하는 것은 아닙니다. 설정을 마친 뒤 대상 앱을 다시 시작하고 연결 기록을 확인하세요. TUN을 사용한다면 라우팅과 DNS도 확인해야 합니다. 루프백 예외가 이를 대신해 주지는 않습니다.

Fake-IP는 도메인에 먼저 매핑 주소를 반환하고, 코어가 이를 실제 대상으로 연결합니다. DNS 처리 경로와 연결 경로가 다르면 접속에 실패할 수 있습니다. 먼저 다른 도구가 DNS를 가로채는지, 브라우저의 보안 DNS가 예상한 경로를 우회하는지, 관련 도메인을 fake-ip-filter에 추가해야 하는지 확인하세요. 클라이언트를 종료한 뒤 인터넷이 끊기면 남아 있는 시스템 프록시를 먼저 끄고, 시스템 DNS가 중지된 로컬 서비스를 가리키는지 확인하세요. 원래의 자동 또는 지정 설정으로 복구하고 DNS 캐시를 비운 다음 다시 시도합니다. 변경 전 네트워크 설정을 기록하고 하나씩 복구하세요. 문제 해결 로그를 공유하기 전에 구독 URL과 자격 증명, 민감한 도메인을 가리세요.