Clash 자주 묻는 질문

클라이언트는 설정을 가져오고 정책을 전환하며 시스템 프록시를 설정합니다. 코어는 설정을 해석하고 연결을 만들며 트래픽을 분기합니다. 구독은 서비스 제공자가 노드나 설정을 제공하는 경로입니다. 클라이언트를 설치했다고 바로 사용할 수 있는 회선이 생기는 것은 아니므로, 사용 권한이 있는 설정을 가져와야 합니다. Clash 생태계의 클라이언트마다 사용하는 코어가 다를 수 있으며, mihomo는 지속적으로 개발되고 있는 코어 중 하나입니다. 기능이 지원되지 않는다면 앱 이름만으로 판단하지 말고 클라이언트 이름과 실제 코어 버전을 함께 기록하세요. 이 사이트는 다운로드와 설정 정보를 제공하며, 구독을 발급하거나 서비스 계정을 복구해 드리지는 않습니다.

평소에는 Rule을 선택해 이미 프록시가 적용된 연결을 설정의 규칙에 따라 분기하는 것이 일반적입니다. Global은 적용 대상 연결을 전역 정책으로 처리하므로, 해당 정책에서 사용 가능한 노드를 선택했는지 확인해야 합니다. Direct는 적용 대상 연결을 프록시 없이 직접 연결합니다. 모드를 바꿔도 트래픽 적용 범위가 자동으로 넓어지지는 않으며, 시스템 프록시를 따르지 않는 프로그램이 갑자기 프록시를 사용하게 되는 것도 아닙니다. 문제를 진단할 때는 잠시 Global로 바꾸고 같은 URL을 비교해 보세요. Global에서는 정상인데 Rule에서 문제가 생기면 규칙 매칭과 정책 선택을 먼저 확인하세요. 두 모드 모두 실패하면 노드, DNS 해석, 트래픽 적용 경로를 점검한 뒤 원래 모드로 되돌리세요.

지연 시간 테스트 성공은 테스트 당시 노드가 클라이언트에서 지정한 확인 요청에 응답했다는 뜻일 뿐, 모든 웹사이트와 프로토콜, 출구 IP를 사용할 수 있다는 의미는 아닙니다. 먼저 테스트에 사용된 URL을 확인한 다음, 대상 사이트 연결이 실제로 어떤 정책 그룹에 매칭됐는지 살펴보세요. 다른 노드의 테스트 결과를 현재 연결 상태로 착각하지 않도록 주의해야 합니다. 일반 웹페이지와 대상 페이지를 비교하고, 로그에서 DNS 해석 실패, 핸드셰이크 실패, 원격 서버의 연결 거부 여부를 확인하세요. 대상 사이트가 출구 IP를 제한할 수도 있고, 일부 앱은 UDP에 의존합니다. 지연 시간 숫자 하나만 보고 설정을 계속 바꾸기보다 트래픽 적용 실패, 노드 문제, 대상 사이트의 제한을 먼저 구분하세요.

YAML 확장자만으로 호환 여부를 판단할 수는 없습니다. 클라이언트마다 사용하는 코어, 지원 프로토콜, 규칙 유형, 오버라이드 방식이 다를 수 있으며, 특히 오래된 코어는 새 필드를 인식하지 못할 수 있습니다. 이전하기 전에 기존 설정을 보관하고 대상 클라이언트의 코어 안내를 확인하세요. 가져온 뒤에는 설정 검사를 실행하고 처음 나타난 구체적인 파싱 오류부터 확인하세요. 여러 설정 구간을 한꺼번에 삭제하지 마세요. 모바일에서는 시스템 VPN 인터페이스로 트래픽을 처리할 수 있어 데스크톱과 설정 위치가 다릅니다. 구독 제공자가 여러 형식을 제공한다면 대상 코어에 맞는 형식을 선택하세요. 설정을 변환할 때 구독 URL에 접근 인증 정보가 포함될 수 있으므로, 낯선 변환 서비스에 함부로 입력하지 마세요.

먼저 다운로드 실패와 설정 파싱 실패를 구분하세요. 연결 시간 초과, 인증서 오류, 비정상적인 HTTP 상태 코드는 다운로드 단계의 문제입니다. 다운로드는 됐지만 필드, 들여쓰기, 프록시 유형 오류가 표시된다면 콘텐츠 파싱 단계의 문제입니다. 복사한 URL이 완전한지, 공백이나 줄바꿈이 섞이지 않았는지, 계정 웹페이지 주소를 구독 URL로 착각하지 않았는지 확인하세요. 현재 네트워크에서 구독 도메인에 접속할 수 없다면 이미 사용 가능한 연결을 통해 업데이트를 시도할 수 있지만, 여러 네트워크 설정을 반복해서 바꾸지는 마세요. 로그인 페이지나 오류 안내가 반환되면 서비스 제공자 계정에서 링크 상태를 확인하세요. 오류 화면을 공유할 때는 전체 구독 URL, 계정 정보, 노드 인증 정보를 가리세요.

먼저 현재 설정과 업데이트 오류를 보관한 뒤, 서비스 제공자 계정에서 구독 유효 기간, 트래픽 한도, 링크 재설정 여부와 공지 사항을 확인하세요. HTTP 401이나 403은 인증 또는 접근 제한과 관련된 경우가 많지만, 최종 원인은 서비스 제공자가 반환한 내용을 기준으로 판단해야 합니다. 업데이트에 실패할 때마다 계정이 만료됐다고 단정하지 마세요. 새 설정이 비어 있거나 노드 이름이 바뀌면 정책 그룹이 이전 이름을 참조하고 있을 수 있으므로 실제 선택 항목을 확인하세요. 이전 설정을 복원해도 로컬 설정만 되살아날 뿐 서비스 유효 기간이 연장되지는 않습니다. 서비스 제공자가 주소 변경을 안내한 경우에만 교체하고, 정기 업데이트가 사용 가능한 설정을 계속 덮어쓰지 않도록 만료된 항목을 제거하세요.

먼저 시스템 정보에서 운영체제 버전과 프로세서 아키텍처를 확인한 다음 다운로드 페이지에서 맞는 설치 파일을 선택하세요. x64와 ARM64는 서로 다른 아키텍처이며, macOS에서는 Apple Silicon과 Intel용 파일도 구분해야 합니다. Linux는 deb, rpm 등 배포판 패키지 형식도 확인하세요. 운영체제 버전이 지원되지 않는다는 메시지가 나오면 해당 클라이언트의 최소 요구 사항을 확인하세요. 파일 이름을 바꾸거나 시스템 보호 기능을 끄고 설치를 강행하지 마세요. 설치 후 실행되지 않는다면 오류 내용을 빠짐없이 기록하고, 이전 프로세스가 실행 중인지, 필요한 런타임이 있는지, 보안 프로그램이 차단했는지 확인하세요. 업데이트 전에 설정과 로컬 오버라이드를 백업해 제거 과정에서 문제 진단에 필요한 정보까지 지워지지 않도록 하세요.

먼저 TUN을 끄고 일반 시스템 프록시 연결이 정상인지 확인한 뒤 가상 네트워크 어댑터 계층을 따로 점검하세요. 데스크톱 클라이언트는 서비스 설치 또는 실행과 관리자 권한이 필요한 경우가 많고, macOS에서는 관련 시스템 권한을 승인해야 할 수 있습니다. 구체적인 요구 사항은 클라이언트 안내를 따르세요. 로그에서 서비스 미실행, 어댑터 생성 실패, 라우팅 충돌 여부를 확인하고 스위치만 반복해서 누르지는 마세요. 라우팅을 동시에 변경하지 않도록 다른 VPN, 가속기, TUN 도구를 잠시 종료한 뒤 다시 시도하세요. TUN을 켠 뒤 전체 인터넷 연결이 끊기면 먼저 TUN을 끄고 네트워크를 복구하세요. 오류 정보를 보관한 다음 어댑터, 기본 경로, DNS를 확인하고, 정체를 모르는 시스템 네트워크 어댑터를 한꺼번에 삭제하지 마세요.

먼저 클라이언트 코어가 실행 중인지 확인한 다음 시스템 프록시가 가리키는 로컬 주소와 포트가 현재 수신 대기 포트와 일치하는지 살펴보세요. 브라우저가 확장 프로그램, 사용자 지정 프록시, 별도의 네트워크 설정을 사용해 시스템 설정을 덮어쓸 수도 있습니다. 관련 확장 프로그램을 잠시 끄고 시스템 프록시를 따르는 브라우저 창에서 비교해 보세요. 대상 URL에 접속하면서 연결 목록도 확인하세요. 새 기록이 없다면 트래픽 적용 경로를 먼저 점검하고, 기록은 있지만 DIRECT로 표시된다면 규칙과 모드를 확인하세요. 노드를 경유했는데도 실패한다면 노드와 대상 사이트를 살펴보세요. 시스템 프록시 변경은 TUN 활성화와 다르며, 웹페이지 언어만으로 프록시 경유 여부를 판단할 수도 없습니다.

많은 명령줄 프로그램은 데스크톱 시스템 프록시를 자동으로 사용하지 않으므로 프록시 옵션이나 환경 변수를 별도로 설정해야 합니다. 먼저 curl --proxy http://127.0.0.1:7890 https://example.com 명령으로 직접 테스트해 보세요. 여기서 7890은 예시이므로 클라이언트가 실제 제공하는 HTTP 또는 mixed 포트로 바꿔야 합니다. 테스트에 성공하면 사용하는 터미널에 http_proxy와 https_proxy를 설정하고, no_proxy에 대상이 제외되어 있지 않은지 확인하세요. Git, 패키지 관리자, 컨테이너에도 별도의 프록시 설정이 있을 수 있습니다. WSL이나 컨테이너 내부의 127.0.0.1은 호스트 컴퓨터를 가리키지 않을 수 있습니다. 환경 간 연결은 네트워크 경계를 별도로 확인해야 하며, 로컬 주소를 그대로 복사해 사용하면 안 됩니다.

편집기에 저장된 파일만 확인하지 말고 코어가 실제로 불러온 설정을 먼저 확인하세요. 규칙은 대개 순서대로 매칭되므로 너무 앞에 있는 포괄적인 규칙이나 MATCH가 뒤쪽 규칙의 매칭을 막을 수 있습니다. 대상 정책 그룹 이름이 실제로 존재하고 정확히 일치하는지도 확인하세요. 전체 도메인에는 DOMAIN을 사용하고 도메인 접미사에는 DOMAIN-SUFFIX를 사용하세요. URL의 프로토콜이나 경로까지 함께 입력하지 않았는지도 살펴보세요. 저장 후 클라이언트 안내에 따라 설정을 다시 불러오고 새 연결을 만들어 로그를 확인하세요. 기존 연결은 이전 경로를 계속 사용할 수 있습니다. 구독 업데이트가 원격 설정을 덮어쓴다면 클라이언트가 제공하는 로컬 오버라이드 또는 병합 기능을 사용하세요.

AppContainer로 격리된 일부 앱은 로컬 루프백 프록시에 직접 접근할 수 없습니다. 브라우저는 정상인데 특정 스토어 앱만 실패한다면 루프백 제한을 확인해 볼 수 있지만, 스토어 앱이 모두 UWP인 것은 아닙니다. 먼저 해당 앱이 시스템 프록시를 사용하는지, 클라이언트에서 루프백 예외 도구를 제공하는지 확인하세요. 권한을 부여해야 한다면 관련 앱에만 적용하세요. 직접 설정하려면 관리자 권한으로 CheckNetIsolation LoopbackExempt -s를 실행해 기존 목록을 확인한 뒤, 앱의 실제 패키지 식별자를 기준으로 조정하세요. 표시 이름을 패키지 식별자로 간주하면 안 됩니다. 회사 기기가 정책으로 관리된다면 관리자에게 먼저 문의하세요. 연결 기록이 있다면 루프백 문제만으로 단정하지 말고 규칙과 노드도 확인해야 합니다.

먼저 프록시를 끄고 기본 네트워크로 정상 접속할 수 있는지 확인한 다음 구독 계정과 설정이 유효한지 살펴보세요. 노드 하나를 선택해 실제 요청을 보내고 같은 시각의 로그를 확인해 DNS 조회 실패, TCP 연결 시간 초과, 인증 실패, TLS 핸드셰이크 오류를 구분하세요. 각각 해결 방법이 다릅니다. 그다음 네트워크를 바꾸거나 사용 가능한 것으로 확인된 노드를 선택하는 등 한 번에 한 가지 변수만 바꿔 결과를 비교하세요. 지연 시간 테스트만 실패하고 실제 접속은 정상이라면 테스트 URL에 접근할 수 있는지 확인하세요. 여러 노드가 같은 접속 도메인이나 서비스 제공자를 공유한다면 동시에 실패해도 로컬 컴퓨터 문제라고 단정할 수 없습니다. 발생 시각과 오류 유형을 기록해 서비스 제공자에게 문의하세요.

먼저 시스템 DNS, 코어 DNS, 브라우저의 암호화 DNS 중 현재 어떤 설정을 사용하는지 확인하세요. 세 곳을 동시에 바꾸면 결과를 비교하기 어렵습니다. 현재 네트워크에서 상위 DNS 서버에 접근할 수 있는지 확인하세요. 노드 서버가 도메인 이름을 사용한다면 프록시 연결을 만들기 전에 필요한 DNS 조회가 가능한지도 점검해야 합니다. Fake-IP가 가상 주소를 반환하는 것은 정상 동작이므로 가상 IP 대역이 보인다는 이유만으로 DNS 오류라고 판단하지 마세요. 일부 도메인에서만 문제가 생기면 로그와 호환성을 확인한 뒤 사용 중인 코어가 지원하는 필터링 방식으로 최소한만 조정하세요. 설정을 변경한 뒤 관련 캐시를 지우고 연결을 다시 만드세요. 로컬 네트워크 장치 이름을 사용하는 경우에는 로컬 네트워크에 적합한 DNS 경로도 유지해야 합니다.

먼저 시스템 프록시가 종료된 로컬 포트를 계속 가리키는지 확인하세요. 시스템 네트워크 설정에서 수동 프록시를 끄고, 이전에 자동 프록시 스크립트를 사용했다면 해당 설정도 점검하세요. 이어서 TUN이 꺼져 있는지, 관련 서비스와 가상 네트워크 어댑터가 정상인지 확인하고 수동으로 설정한 DNS가 남아 있는지도 살펴보세요. 터미널 프로그램은 이번에 설정한 프록시 환경 변수를 지우거나 새 터미널을 열어 다시 테스트해야 합니다. 순서대로 복구한 뒤 네트워크 연결을 재시작할지 판단하세요. 처음부터 모든 네트워크 설정을 초기화하지 마세요. 회사 기기는 조직 프록시를 사용하고 있을 수 있으므로 수정 전에 기존 값을 기록해 조직에서 요구하는 네트워크 설정을 잘못 삭제하지 않도록 하세요.

같은 브라우저와 같은 IP 확인 페이지를 사용해 설정을 켜기 전과 후를 비교하고, 클라이언트에서 해당 요청의 연결 기록도 함께 확인하세요. 출구 IP는 여러 증거 중 하나일 뿐입니다. 확인 페이지가 규칙에 따라 직접 연결되도록 설정됐을 수도 있고, 캐시된 페이지로 인해 잘못 판단할 수도 있습니다. 브라우저에는 기록이 있지만 대상 앱에는 기록이 없다면 앱의 시스템 프록시 지원 여부, UDP 사용 여부, 별도 네트워크 설정을 확인한 뒤 TUN이 필요한지 판단하세요. IPv4와 IPv6는 서로 다른 경로를 사용할 수 있으므로 실제 연결을 각각 확인하세요. 주소가 다르다는 이유만으로 전역 설정을 바꾸지 마세요. TUN은 트래픽 적용 범위를 넓힐 수 있지만 라우팅과 규칙의 영향을 받으므로 모든 연결이 자동으로 같은 출구를 사용한다고 보장할 수는 없습니다.