Clash 자주 묻는 질문과 문제 해결

클라이언트는 설정 가져오기, 정책 그룹 선택, 시스템 프록시 전환, 로그 확인 등의 그래픽 작업을 제공합니다. 코어는 포트를 수신하고 규칙을 실행하며 DNS와 트래픽 전달을 처리합니다. 구독 서비스는 설정 내용이나 프록시 노드를 제공합니다. 클라이언트를 설치해도 구독이 자동으로 제공되지는 않으며, 구독 제공업체가 클라이언트 개발자인 것도 아닙니다. 문제를 점검할 때는 먼저 원인이 화면 조작, 코어 실행, 구독 내용 중 어디에 있는지 구분해야 합니다.

이 사이트는 다운로드 경로, 설정 절차, 문제 해결 방법을 정리한 독립적인 중국어 사용 안내 사이트이며, 어떤 클라이언트·코어·구독 서비스도 대표하지 않습니다. 다운로드하기 전에 다운로드 페이지에서 클라이언트 이름, 지원 시스템, 유지 관리 상태를 확인하세요. 기능 차이는 사용 중인 클라이언트와 코어 버전에서 실제로 제공하는 설정을 기준으로 판단해야 합니다.

아닙니다. 구독을 가져오면 원격 설정이 클라이언트에 저장될 뿐입니다. 일반적으로 해당 설정을 선택하고 코어를 시작한 뒤 규칙 모드나 글로벌 모드를 선택하고 시스템 프록시 또는 TUN 같은 트래픽 전환 기능을 활성화해야 합니다. 완료 후에는 네트워크 경로를 확인할 수 있는 페이지에 접속하고, 클라이언트 로그에 해당 연결이 기록되는지도 확인하세요. 구독 이름이 보인다고 해서 트래픽이 이미 코어를 통과하는 것은 아닙니다.

규칙 모드는 설정 파일의 규칙을 위에서 아래 순서로 평가하며, 처음 일치한 규칙에 따라 DIRECT, REJECT 또는 특정 정책 그룹을 사용합니다. 글로벌 모드는 일반적으로 가로챌 수 있는 트래픽을 선택한 정책 그룹으로 보내므로, 규칙 때문에 접속 문제가 발생하는지 임시로 확인할 때 유용합니다. 직접 연결 모드에서는 트래픽이 대상에 직접 접속합니다. 글로벌 모드는 속도를 높이는 기능이 아니므로 장기간 사용하기 전에 LAN, 시스템 서비스, 필요한 직접 연결 규칙이 올바른지 확인해야 합니다.

먼저 브라우저에서 구독 링크를 열어 로그인 페이지, 만료 안내, 오류 페이지가 아닌 설정 내용이 반환되는지 확인하세요. 그런 다음 링크가 완전히 복사되었는지, 구독이 만료되지 않았는지, 기기 시간이 정확한지, 클라이언트가 구독 도메인에 접속할 수 있는지 점검합니다. 브라우저에서는 열리지만 클라이언트에서 실패한다면 업데이트 로그의 HTTP 상태, TLS, 시간 초과 정보를 확인하고 구독 업데이트에 별도 프록시가 설정되어 있는지도 점검하세요. 로컬 오버라이드를 잃을 수 있으므로 설정을 반복해서 삭제하지 마세요.

먼저 오류가 발생한 줄 번호를 기록한 다음 해당 줄과 바로 앞줄의 들여쓰기, 콜론, 하이픈, 따옴표가 올바르게 짝을 이루는지 확인하세요. YAML 들여쓰기는 공백만 사용해야 하며 Tab과 공백을 섞으면 안 됩니다. 같은 수준의 필드는 동일한 들여쓰기를 유지해야 합니다. 수동 수정 후 오류가 발생했다면 최근 변경 사항을 잠시 되돌린 뒤 다시 불러오세요. 구독 설정과 로컬 오버라이드는 분리해 관리해야 하며, 그렇지 않으면 구독 업데이트가 원본 파일에 직접 입력한 내용을 덮어쓸 수 있습니다.

먼저 기기 자체에서 인터넷에 직접 접속할 수 있는지 확인하고, 시스템 시간·구독 유효 기간·노드 정보가 최근에 갱신되었는지 점검하세요. 그런 다음 노드 하나만 선택해 테스트하면서 로그가 DNS 조회 실패인지, 연결 거부인지, 핸드셰이크 실패인지, 단순 시간 초과인지 확인합니다. 모든 노드에서 동시에 문제가 발생하면 로컬 네트워크, 구독 내용 또는 코어 설정 문제일 가능성이 높습니다. 하나의 노드만 문제가 있다면 구독 제공업체에 해당 노드의 상태를 문의하세요. 지연 시간 테스트 실패가 실제 모든 연결의 실패를 의미하지는 않습니다.

앱 컨테이너의 네트워크 격리를 사용하는 일부 Windows 앱은 로컬 프록시 수신 주소에 직접 접속하지 못할 수 있습니다. 이 경우 클라이언트가 제공하는 UWP 루프백 도구에서 대상 앱의 루프백 제한을 해제해야 할 수 있습니다. 먼저 브라우저 같은 일반 데스크톱 프로그램이 시스템 프록시로 접속되는지 확인한 뒤, 문제가 발생한 앱만 선택하고 해당 앱을 다시 시작하세요. 클라이언트에 루프백 도구가 없다면 문서에 따라 Windows의 해당 기능을 사용하고, 모든 앱을 무조건 추가하지는 마세요.

먼저 클라이언트의 HTTP 또는 mixed 수신 포트가 실행 중인지 확인한 다음 시스템 프록시 설정의 주소와 포트가 클라이언트와 일치하는지 점검하세요. 이어서 브라우저에 자체 프록시 확장 프로그램이나 독립적인 프록시 설정이 활성화되어 있는지, 시스템 프록시를 무시하는 정책이 적용되어 있는지 확인합니다. 이러한 재정의 설정을 잠시 끈 뒤 다시 시도하고 클라이언트 로그에서 대상 도메인을 검색하세요. 로그가 전혀 없다면 브라우저 트래픽이 아직 코어에 도달하지 않은 것이므로 노드를 계속 바꿔도 원인 파악에 도움이 되지 않습니다.

많은 터미널 프로그램은 데스크톱의 시스템 프록시를 자동으로 읽지 않습니다. 현재 shell 또는 특정 프로그램에 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 설정하고 클라이언트가 실제로 수신하는 프로토콜과 포트를 사용해야 합니다. 설정 후 터미널을 다시 열고 환경 변수가 적용되었는지 확인한 다음 명령의 상세 출력으로 연결 대상을 살펴보세요. 프로그램 자체의 프록시 옵션이 환경 변수를 덮어쓰고 있지 않은지도 확인해야 합니다. 테스트가 끝나면 임시 변수를 제거해 패키지 관리자나 LAN 접속에 영향을 주지 않도록 하세요.

TUN은 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 변경하므로 클라이언트에서 관리자 권한, VPN 구성, 네트워크 확장 프로그램 또는 보조 서비스 승인을 요구할 수 있습니다. 현재 클라이언트가 시스템에 표시하는 승인 절차에 따라 진행한 뒤 코어를 다시 시작하고 가상 인터페이스가 생성되었는지 확인하세요. macOS에서는 네트워크 확장 프로그램과 VPN 구성 안내를 확인하고, Linux에서는 서비스 권한과 TUN 장치 사용 가능 여부를 점검해야 합니다. 정상적인 승인을 우회하기 위해 시스템 보안 기능을 끄지는 마세요.

동시 활성화 여부는 클라이언트 구현에 따라 다릅니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 주로 영향을 주고, TUN은 가상 인터페이스를 통해 더 많은 네트워크 트래픽을 가로챕니다. 일부 클라이언트는 특정 앱과의 호환성을 위해 TUN을 켠 뒤에도 시스템 프록시를 유지하며, 다른 경우에는 둘 중 하나만 필요합니다. 처음 문제를 점검할 때는 시스템 프록시만 먼저 확인한 뒤 TUN을 활성화하세요. 두 트래픽 경로를 동시에 바꾸면 루프백·라우팅·DNS 문제의 원인을 구분하기 어려워집니다.

아닙니다. no-resolve는 일반적으로 IP-CIDR 같은 규칙 뒤에 사용되며, 코어가 해당 IP 규칙을 평가할 때 도메인을 IP로 적극 조회하지 않도록 합니다. 불필요한 조회나 규칙 평가 경로의 변화를 막기 위한 설정입니다. 모든 DNS를 끄는 것과는 다르며 nameserver, fallback, fake-ip 같은 DNS 설정을 대신하지도 않습니다. 도메인 조회 문제가 발생하면 모든 no-resolve 표시를 삭제하기보다 DNS 설정, 시스템 조회 경로, 로그를 확인해야 합니다.

먼저 시스템 프록시 또는 TUN을 끄고 직접 연결이 복구되는지 확인하세요. 그런 다음 클라이언트 코어를 다시 시작하고 수신 포트를 다른 프로그램이 사용 중인지 점검합니다. 정상 작동이 확인된 설정과 노드 하나를 선택해 글로벌 모드로 짧게 비교 테스트하세요. 글로벌 모드는 작동하지만 규칙 모드가 실패하면 규칙과 정책 그룹을 확인하고, 둘 다 실패하면 DNS·노드 연결·핸드셰이크 로그를 살펴봐야 합니다. 매번 하나의 설정만 변경해 모드, DNS, 노드를 동시에 바꾸면서 결과를 재현할 수 없게 만들지 마세요.

먼저 TUN을 끄고 문제가 즉시 사라지는지 확인한 다음 클라이언트 로그에서 라우팅 생성, 인터페이스 시작, DNS 오류를 점검하세요. LAN 접속에 문제가 있다면 사설 주소 대역이 DIRECT로 유지되는지, TUN 설정에서 로컬 게이트웨이·프린터·회사 내부망 대역을 제외했는지 확인해야 합니다. 다른 VPN, 가상 네트워크 어댑터, 네트워크 필터링 프로그램을 함께 실행 중이라면 하나씩 잠시 중지해 충돌을 테스트하세요. 라우팅을 수정하기 전 기존 설정을 기록하고 복구 방법을 확인한 뒤 진행하세요.

구독 업데이트는 일반적으로 원격 내용으로 해당 설정을 교체하므로 구독 파일에 직접 작성한 로컬 규칙과 정책 그룹 선택이 초기화될 수 있습니다. 먼저 클라이언트가 오버라이드, 병합, 스크립트 처리 또는 정책 선택 유지 기능을 제공하는지 확인하고, 개인 규칙은 별도의 로컬 관리 영역에 저장하세요. 업데이트 전에 주요 정책 그룹과 규칙을 기록하고, 업데이트 후 그룹 이름이 바뀌었는지와 참조 대상이 여전히 존재하는지 점검합니다. 원격 설정 구조가 변경되었다면 기존 그룹 이름을 계속 참조하지 말고 오버라이드 규칙도 함께 수정해야 합니다.

클라이언트의 연결 기록이나 코어 로그를 열고 대상 도메인에 다시 접속해 일치한 규칙 유형, 규칙 내용, 최종 정책 그룹을 확인하세요. 로그의 처리 방향이 예상과 다르면 더 앞에 있는 DOMAIN, DOMAIN-SUFFIX, GEOIP, RULE-SET, IP-CIDR 규칙을 점검해야 합니다. 규칙은 순서대로 일치하므로 뒤의 규칙이 이미 일치한 결과를 덮어쓰지 않습니다. 임시 사용자 지정 규칙으로 한 항목씩 검증한 뒤 안정적인 로컬 오버라이드에 추가하세요. 구독 업데이트로 교체될 파일을 직접 수정하는 방식은 피해야 합니다.