TROUBLESHOOTING REFERENCE

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

구독 가져오기, 프록시 모드, 설정 문법부터 TUN, DNS, 노드 연결, 시스템 네트워크까지 단계별로 점검합니다. 각 답변에 명확한 순서를 제시해 설치 후 바로 따라 할 수 있습니다.

BASICS

기본 개념

먼저 클라이언트, 코어, 구독, 프록시 모드를 구분하세요. 개념을 정확히 이해하면 이후 설정 문제도 쉽게 찾을 수 있습니다.

Clash, Clash Meta, mihomo는 각각 무엇인가요?

Clash는 일반적으로 규칙 기반 프록시 클라이언트와 그 설정 체계를 가리킵니다. 초기 Clash 원본 코어는 더 이상 지속적으로 개발되지 않으며, Clash Meta는 일반적인 설정과의 호환성을 유지하면서 프로토콜, DNS, TUN 기능을 확장했습니다. 이후 프로젝트 이름은 mihomo로 변경되었습니다. 현재 많은 데스크톱 및 모바일 클라이언트는 그래픽 인터페이스일 뿐이며, 실제 연결, 규칙 매칭, DNS 처리는 mihomo 코어가 담당합니다.

구독 링크는 어디서 받으며, 클라이언트가 노드를 자동으로 생성하나요?

Clash 클라이언트는 설정을 읽고 정책을 선택한 뒤 연결을 전달하지만, 구독이나 노드를 자동으로 생성하지는 않습니다. 구독 링크는 보통 이용 중인 네트워크 서비스 제공업체가 제공하며, 로컬 YAML 설정을 직접 관리할 수도 있습니다. 가져오기 전에 링크가 아직 유효한지 확인하고, 접근 자격 증명이 포함된 구독 주소를 스크린샷, 포럼 또는 공개 문서에 게시하지 마세요.

규칙, 글로벌, 직접 연결 모드는 어떻게 선택하나요?

일상적인 사용에는 규칙 모드를 우선 선택하세요. 연결은 설정의 DOMAIN, GEOIP, MATCH 등의 규칙에 따라 프록시 또는 직접 연결로 처리됩니다. 글로벌 모드는 대부분의 연결을 현재 프록시 정책으로 보내므로 노드의 작동 여부를 임시로 확인할 때 적합합니다. 직접 연결 모드는 프록시를 우회해 문제가 프록시 경로에서 발생했는지 빠르게 판단할 수 있습니다. 점검이 끝나면 보통 규칙 모드로 되돌립니다.

시스템 프록시와 TUN 모드는 어떻게 다른가요?

시스템 프록시는 운영체제의 HTTP 및 SOCKS 프록시 설정을 주로 변경하며, 시스템 프록시를 따르는 브라우저와 앱에서 바로 사용할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 시스템 프록시 설정을 읽지 않는 프로그램과 UDP 트래픽까지 더 폭넓게 처리하지만, 추가 권한과 라우팅·DNS 설정이 필요합니다. 일반적인 브라우저 접속은 먼저 시스템 프록시를 사용하고, 시스템 프록시의 영향을 받지 않는 앱에 대해서는 TUN을 고려하세요.

INSTALLATION

설치 및 설정

구독 응답, 설정 형식, 권한, 가상 네트워크 어댑터를 중점적으로 확인하세요. 명확한 오류부터 해결한 뒤 기능 옵션을 조정합니다.

구독 링크를 붙여 넣어도 가져올 수 없으면 어떻게 하나요?

먼저 브라우저에서 구독 주소를 열어 설정 내용이나 다운로드 파일이 반환되는지 확인하세요. 로그인 페이지, 오류 페이지 또는 빈 응답이라면 안 됩니다. 그런 다음 링크 앞뒤에 공백이 있는지, 전체 주소가 복사되었는지, 클라이언트가 네트워크에 접근할 수 있는지 확인합니다. 브라우저에서는 다운로드되지만 클라이언트에서 가져올 수 없다면 YAML 파일로 저장한 뒤 로컬에서 가져오고, 로그의 HTTP 상태 코드와 설정 파싱 메시지를 확인하세요.

구독 업데이트에서 401, 403 또는 링크 만료가 표시되면 어떻게 처리하나요?

401은 보통 구독 자격 증명이 유효하지 않다는 뜻이고, 403은 서버가 요청을 거부했다는 뜻입니다. 링크 만료는 404, 빈 파일 또는 웹 페이지 반환으로 나타날 수 있습니다. 먼저 서비스 제공업체의 관리 페이지에서 현재 구독 주소를 다시 복사한 다음, 클라이언트에 저장된 이전 주소를 삭제하고 다시 가져오세요. 자격 증명을 추측하며 URL 매개변수를 반복해서 수정하지 말고, 새 주소에서도 오류가 나면 구독 제공업체에 계정 상태와 접근 제한을 확인해야 합니다.

설정 파일에서 YAML 파싱 오류가 발생하면 어떻게 위치를 찾나요?

먼저 로그에 표시된 행과 열을 확인한 뒤 해당 위치부터 위쪽으로 들여쓰기, 콜론 뒤의 공백, 목록의 하이픈, 따옴표의 짝이 맞는지 점검하세요. YAML 들여쓰기에는 공백만 사용해야 하며 탭을 섞으면 안 됩니다. 같은 단계의 키는 동일한 들여쓰기를 유지해야 하고, 콜론이나 특수 문자가 포함된 값은 따옴표로 감쌀 수 있습니다. 수정 후에는 클라이언트의 설정 검사부터 실행하고 코어를 다시 불러오세요. 여러 곳을 동시에 바꾸면 오류 위치가 달라질 수 있습니다.

TUN을 켤 때 권한 부족 또는 네트워크 어댑터 생성 실패가 표시되면 어떻게 하나요?

Windows에서는 먼저 관리자 권한으로 클라이언트를 실행하고 가상 네트워크 어댑터 드라이버가 올바르게 설치되었는지 확인하세요. macOS에서는 시스템 안내에 따라 네트워크 확장 또는 보조 서비스를 승인해야 합니다. Linux에서는 일반적으로 CAP_NET_ADMIN 권한이 필요하거나 통제된 방식으로 권한을 높여야 합니다. 다른 VPN이나 가상 네트워크 어댑터 도구를 설치했다면 일시적으로 종료하고 라우팅 충돌을 확인하세요. 권한을 수정한 뒤 클라이언트를 다시 시작하고 로그에 create tun, route 또는 permission denied가 계속 나타나는지 확인합니다.

USAGE

사용 팁

노드 전환, 규칙 순서, Fake-IP, 로컬 네트워크 공유는 연결 기록으로 함께 확인해야 하며 단순히 스위치 상태만 봐서는 안 됩니다.

노드를 전환하고 사용 가능한 노드인지 어떻게 판단하나요?

프록시 정책 그룹에서 특정 노드를 선택한 다음 클라이언트의 지연 시간 테스트를 참고용으로 사용하세요. 지연 시간 테스트가 성공했다는 것은 테스트 주소와 연결할 수 있다는 뜻일 뿐, 모든 대상에 접근할 수 있다는 의미는 아닙니다. 더 확실한 방법은 정상 작동이 확인된 HTTPS 페이지를 열고 연결 패널에서 요청이 예상한 정책에 매칭되었는지 확인하는 것입니다. 여러 노드가 동시에 실패한다면 반복해서 속도만 측정하지 말고 먼저 구독과 로컬 네트워크를 점검하세요.

Clash 사용자 지정 규칙은 어디에 배치해야 하나요?

규칙은 위에서 아래 순서로 매칭되므로, 구체적인 도메인 및 서비스 규칙은 범위가 넓은 GEOIP, GEOSITE 또는 MATCH보다 앞에 배치해야 합니다. 특정 도메인을 고정 처리하려면 DOMAIN 또는 DOMAIN-SUFFIX를 먼저 작성하고 MATCH는 최종 기본값으로 남겨 두세요. 클라이언트가 규칙 오버라이드를 지원한다면 구독 업데이트로 수동 수정 사항이 덮어써지지 않도록 오버라이드 기능을 우선 사용하세요. 수정 후에는 연결 기록에서 실제로 어떤 규칙이 매칭되었는지 확인합니다.

Fake-IP 모드에서 도메인 확인 오류가 발생하면 어떻게 하나요?

먼저 DNS 강화 모드, 수신 주소, nameserver 설정이 완전한지 확인한 다음 문제가 발생한 앱이 로컬 네트워크 도메인, 장치 검색 또는 특수한 DNS 응답에 의존하는지 점검하세요. 관련 도메인을 fake-ip-filter에 추가하면 실제 주소를 반환하도록 할 수 있습니다. 수정 후 운영체제의 DNS 캐시를 지우고 클라이언트를 다시 시작하세요. 특정 앱에서만 문제가 발생한다면 redir-host로 임시 전환해 비교하고 Fake-IP 호환성 문제인지 판단할 수 있습니다.

같은 로컬 네트워크의 기기에서 Clash 프록시를 사용하게 하려면 어떻게 하나요?

클라이언트에서 로컬 네트워크 연결 허용을 켜고 mixed-port가 로컬 네트워크에서 접근 가능한 주소를 수신하도록 설정되었는지 확인하세요. 시스템 방화벽에서는 신뢰할 수 있는 로컬 네트워크에만 해당 포트를 허용합니다. 다른 기기의 프록시 서버에는 Clash를 실행 중인 컴퓨터의 로컬 네트워크 IP를 입력하고, 포트에는 mixed-port 값을 입력하세요. 연결되지 않으면 두 기기가 같은 서브넷에 있는지, 포트가 수신 중인지, 방화벽이 허용하는지, 게스트 Wi-Fi에서 기기 격리가 활성화되어 있는지를 순서대로 확인합니다.

DIAGNOSIS

문제 해결

먼저 요청이 코어에 들어오는지 확인한 뒤 로컬 포트, 시스템 프록시, DNS, 노드, 대상 연결 문제를 구분하세요.

시스템 프록시가 켜져 있는데도 브라우저가 연결되지 않으면 어떻게 하나요?

먼저 클라이언트 코어가 실행 중인지 확인하고 시스템 프록시 포트가 설정의 mixed-port와 일치하는지 점검하세요. 이어서 브라우저가 별도의 프록시 확장 프로그램, 기업 정책 또는 수동 프록시를 사용하는지 확인합니다. 이러한 설정이 시스템 프록시를 덮어쓸 수 있습니다. 다른 프록시 프로그램을 종료한 뒤 시스템 프록시를 한 번 껐다가 다시 켜고, 테스트 페이지에 접속하면서 Clash 연결 기록을 확인하세요. 클라이언트에 요청이 전혀 들어오지 않으면 시스템 프록시 주소와 로컬 방화벽을 추가로 점검해야 합니다.

노드 테스트는 정상인데 접속할 때 timeout이 발생하면 어떻게 점검하나요?

먼저 같은 정책 그룹의 다른 노드로 전환해 문제가 특정 노드에만 해당하는지 모든 노드에서 발생하는지 확인하세요. 특정 노드만 타임아웃된다면 원격 상태, 전송 매개변수 또는 회선 문제일 가능성이 큽니다. 모든 노드가 타임아웃되면 구독 만료 여부, 로컬 네트워크의 연결 제한, 시스템 시간의 정확성, DNS 작동 여부를 확인해야 합니다. 로그의 dial tcp timeout은 연결 설정 시간 초과를 의미합니다. 동시에 DNS 오류가 나타난다면 먼저 이름 확인 문제를 해결한 뒤 노드를 판단하세요.

Windows 스토어 앱에서 프록시를 사용할 수 없을 때 UWP 루프백은 어떻게 처리하나요?

일부 UWP 앱은 Windows 네트워크 격리의 제한으로 로컬 루프백 주소에 직접 접근하지 못합니다. 따라서 시스템 프록시가 127.0.0.1을 가리켜도 적용되지 않을 수 있습니다. 클라이언트가 제공하는 UWP 루프백 도구를 사용해 인터넷 연결이 필요한 스토어 앱에 Loopback Exempt를 활성화하세요. 변경 후 대상 앱을 완전히 종료했다가 다시 엽니다. 실제로 프록시가 필요한 앱만 선택하고 시스템 구성 요소를 일괄적으로 허용하지 마세요.

Clash가 시작되지 않고 포트가 사용 중이라고 표시되면 어떻게 하나요?

포트 충돌은 보통 다른 Clash 인스턴스, 프록시 도구 또는 백그라운드 서비스가 같은 포트를 수신 중이라는 뜻입니다. 먼저 관련 프로그램을 완전히 종료하고 작업 관리자나 시스템 네트워크 도구에서 포트를 점유한 프로세스를 확인하세요. 해제할 수 없다면 mixed-port를 사용하지 않는 포트로 변경하고 시스템 프록시 설정도 새 포트를 사용하도록 맞추세요. 그래도 클라이언트가 즉시 종료된다면 설정 문법, 코어 파일 경로, 로그의 bind 및 address already in use 메시지를 확인합니다.