Clash 문제 해결 가이드

인터넷 연결 안 됨: 문제 발생 단계부터 확인

먼저 기기 자체가 오프라인인지, Clash를 켠 뒤에만 연결이 끊기는지 확인하세요. 클라이언트에서 ‘시스템 프록시’와 ‘TUN 모드’를 끄고 시스템 프록시 설정도 원래대로 돌아왔는지 확인한 다음, 평소 직접 접속할 수 있는 사이트를 열어 보세요. 그래도 연결되지 않으면 Wi-Fi, 라우터 또는 네트워크 로그인 페이지부터 확인해야 합니다. 프록시 설정으로 기본 네트워크 연결 문제를 해결할 수는 없습니다. 공용 네트워크에서는 웹 인증을 먼저 완료한 뒤 클라이언트를 다시 켜세요. 인증 차단을 노드 문제로 오해하지 않도록 주의하세요.

먼저 직접 연결과 명시적 프록시를 비교하세요

직접 연결로 복구한 다음 클라이언트를 실행하되, TUN은 아직 켜지 말고 코어가 정상인지 확인하세요. 아래 두 명령은 같은 대상에 접속합니다. 첫 번째는 프록시를 명시적으로 우회하고, 두 번째는 로컬 프록시 포트에 직접 연결합니다. Windows에서는 curl이 다른 명령으로 해석되는 PowerShell 환경이 있으므로 curl.exe를 사용하세요. 예시 포트는 7890입니다. 실행 전에 클라이언트 설정에서 실제 수신 포트를 확인해 바꿔 넣으세요.

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

HTTP 응답을 받았다면 해당 요청이 적어도 필요한 연결 단계를 거쳤다는 뜻입니다. 응답 코드가 성공이 아니더라도 프록시 연결이 끊겼다고 단정할 수는 없습니다. 두 번째 명령에서 Failed to connect to 127.0.0.1이 바로 표시되면 먼저 코어와 포트를 확인하세요. 포트에 연결되지만 이후 핸드셰이크나 원격 연결 단계에서 실패한다면 정책 그룹, 노드, DNS를 점검하세요. 테스트 사이트 하나로 확인할 수 있는 것은 해당 경로뿐이므로 원래 문제가 발생한 사이트에서도 다시 테스트해야 합니다.

연결 기록으로 요청이 코어에 도달했는지 확인하세요

‘연결’ 또는 ‘로그’ 화면을 열고 필터를 모두 지운 뒤 문제를 한 번만 재현하세요. 해당 요청이 전혀 보이지 않는다면 앱이 시스템 프록시를 사용하지 않거나, 기존 연결을 재사용하거나, TUN 처리가 설정되지 않았을 수 있습니다. 기록이 있다면 일치한 규칙, 정책 그룹, 실제 출구를 확인하세요. 홈 화면의 실행 상태만 보지 마세요. UI 프로세스가 실행 중이어도 코어가 설정을 정상적으로 불러왔다는 뜻은 아닙니다. 설정 파싱 오류가 있으면 노드 상태를 확인하기 전에 오류가 난 줄부터 수정하세요.

기록에 DIRECT가 표시되는데 해당 대상에 프록시가 필요하다면, 문제는 노드 속도가 아니라 트래픽 분기 선택에 있습니다. 잠시 ‘전역’ 모드로 전환하고 정상 작동이 확인된 출구를 직접 선택해 새 연결을 비교해 보세요. 전역 모드는 코어에 들어온 트래픽의 경로만 바꿉니다. 원래 클라이언트를 거치지 않는 앱까지 자동으로 프록시를 사용하게 하지는 않습니다. 테스트가 끝나면 규칙 모드로 되돌려 다른 사이트까지 같은 출구를 거치지 않도록 하세요.

복구할 때는 필요한 설정만 하나씩 켜세요

명시적 프록시는 작동하지만 브라우저가 연결되지 않는다면, 먼저 시스템 프록시만 켜고 브라우저를 다시 시작한 뒤 테스트하세요. 특정 앱만 여전히 프록시를 사용하지 않는다면 그때 TUN을 따로 확인하세요. 처음부터 여러 프록시 클라이언트, 가속 도구, VPN을 동시에 실행하지 마세요. 시스템 프록시, 기본 경로 또는 DNS를 서로 차지하려 할 수 있습니다. 다른 도구를 종료할 때도 창을 닫는 것만으로 끝내지 말고 네트워크 설정이 복구됐는지 확인하세요.

마지막으로 처음 문제가 발생한 대상으로 다시 테스트하고, 어떤 설정을 바꾸자 증상이 달라졌는지 기록하세요. 직접 연결과 프록시가 모두 실패하면 기본 네트워크를 확인하세요. 프록시만 실패하면 다음 장으로 이동하세요. 명시적 프록시는 작동하지만 일반 앱이 실패한다면 시스템 프록시 문제를 확인하세요. 가져오기와 활성화 절차를 다시 확인하려면 구독 가져오기 단계로 돌아가세요. 원인 확인 대신 반복해서 재설치하지 마세요.

노드 시간 초과: 연결 경로 확인

노드 테스트에 ‘시간 초과’가 표시되면 제한 시간 안에 테스트 요청이 완료되지 않았다는 뜻일 뿐, 서비스가 중단됐다고 단정할 수는 없습니다. 테스트 결과에는 테스트 주소, 도메인 확인, 프로토콜 핸드셰이크, 대상 서버의 응답이 모두 영향을 줍니다. 먼저 로그를 펼쳐 같은 시각의 전체 오류를 확인하고, 연결 대상이 노드 서버인지 DNS 상위 서버인지 테스트 사이트인지 구분하세요. 특히 오류에 표시된 대상 주소를 확인하세요. 코어가 노드에 연결하지 못한 경우와 노드가 대상에 연결하지 못한 경우는 해결 방법이 다릅니다.

오류가 발생한 단계부터 범위를 좁히세요

dial tcp는 TCP 연결을 시도하는 상황을 나타내며, 중요한 단서는 그 뒤에 이어지는 내용입니다. connection refused는 대상 포트에서 서비스가 실행되지 않거나 연결을 거부했을 때 흔히 나타납니다. i/o timeout은 어느 단계에서 대기 시간이 초과됐다는 뜻이므로 주소와 앞뒤 로그를 함께 봐야 합니다. no such host라면 먼저 도메인 확인을 점검하세요. 모든 오류를 포트 충돌 탓으로 돌리지 마세요. 로컬 포트 충돌은 보통 시작 로그에 수신 대기 실패로 명확히 표시됩니다.

같은 네트워크와 테스트 대상을 유지한 채 다른 출구를 직접 선택해 확인하세요. 하나만 실패한다면 해당 설정이 만료됐는지, 서버 포트가 바뀌었는지, 서비스가 정상인지 먼저 살펴보세요. 모든 출구가 함께 실패하면 같은 서버 도메인, 구독 계정 또는 상위 네트워크를 공유하는지 확인하세요. 여러 항목으로 보이더라도 실제로는 하나의 장애 지점에 의존할 수 있습니다. 항목 수가 독립적인 비교 근거가 되지는 않습니다.

도메인 확인, 포트, 프로토콜 핸드셰이크를 각각 테스트하세요

노드 도메인을 시스템에서 조회하면 이름조차 확인되지 않는 문제인지 판단하는 데 도움이 됩니다. 다만 시스템 조회 결과가 코어에서 사용하는 결과와 같다고 보장할 수는 없습니다. 포트 연결 테스트도 특정 TCP 포트에 연결할 수 있다는 것만 증명하며, 인증 정보와 프로토콜 설정, 이후 프록시 요청까지 정상이라는 뜻은 아닙니다. Windows에서는 Test-NetConnection으로 실제 서버와 포트를 확인할 수 있습니다. 로컬 7890 포트 테스트 결과를 원격 노드가 정상이라는 근거로 삼지 마세요.

TCP 연결은 되지만 TLS 또는 프로토콜 핸드셰이크가 실패한다면 서버 이름, 기기 시간, 구독의 원래 매개변수를 확인하세요. server, servername 또는 다른 핸드셰이크 항목을 직접 수정했다면 제공업체가 안내한 값으로 먼저 되돌리세요. 인증서 검증과 서버 측 라우팅은 도메인에 의존할 수 있으므로 도메인을 임의로 IP 주소로 바꾸지 마세요. 인증서 검증 건너뛰기를 켜서 오류를 숨기지 마세요. 보안 기준이 달라질 뿐 아니라 실제 문제를 해결하지 못할 수도 있습니다.

시간 초과를 계속 늘리기보다 네트워크를 바꿔 비교하세요

가능하다면 휴대폰 핫스팟과 기존 네트워크를 비교하되 클라이언트, 설정, 테스트 대상은 그대로 유지하세요. 핫스팟에서는 정상이고 기존 네트워크에서 실패한다면 라우터 정책, 네트워크 출구 또는 UDP 제한을 확인할 근거가 됩니다. 웹은 정상인데 UDP를 사용하는 앱만 실패한다면 선택한 노드와 프로토콜이 해당 트래픽을 지원하는지 확인하세요. 일반 TCP 속도 테스트가 성공해도 UDP 앱의 테스트를 대신할 수 없으며 모든 앱이 정상이라는 뜻도 아닙니다.

테스트 대기 시간을 적당히 늘리면 응답이 느린 경우와 전혀 연결되지 않는 경우를 구분하는 데 도움이 됩니다. 하지만 잘못된 인증 정보나 연결 불가 경로를 해결해 주지는 않습니다. 테스트 주소 자체에 접속할 수 없다면 실제 용도에 맞는 안정적인 주소로 바꾸고, 클라이언트가 HTTP 상태 코드 등 어떤 방식으로 결과를 판단하는지 확인하세요. 전체 오류를 읽는 방법은 실행 로그 오류 의미 안내를 참고하세요. 문제를 문의할 때는 ‘모두 시간 초과’ 스크린샷보다 민감 정보를 가린 로그, 실패 단계, 네트워크 비교 결과를 제공하는 편이 원인 파악에 도움이 됩니다.

구독 오류: 다운로드와 파싱 구분

구독 오류는 먼저 두 가지로 나눠야 합니다. 주소에서 다운로드가 실패했거나, 콘텐츠는 받았지만 불러오지 못했거나 둘 중 하나입니다. ‘프로필’ 페이지에서 한 번 업데이트하고 HTTP 상태 코드, 파싱 오류, 발생 시각을 확인하세요. 반복해서 업데이트를 누르면 새로운 정보는 얻지 못하고 서비스 측 제한만 발생할 수 있습니다. 계속 사용할 수 있는 기존 설정을 먼저 저장하세요. 새 구독을 검증하기 전에는 이전 설정을 삭제하지 말고, 전체 주소를 공개된 문제 게시판에 붙여 넣지 마세요.

다운로드가 실패하면 주소, 권한, 네트워크 경로부터 확인하세요

서비스 제공업체 페이지에서 클라이언트용 구독 주소를 다시 복사하고 앞뒤 공백, 줄바꿈, 한글 문장부호, 클립보드에 함께 복사된 안내 문구가 없는지 확인하세요. 구독 주소는 계정 관리 페이지 주소와 다르며, 브라우저 주소창에 현재 표시된 주소와도 다를 수 있습니다. 계정 식별 정보가 포함된 링크는 재설정 후 사용할 수 없게 될 수 있습니다. 새 주소를 발급받았다면 설정 이름만 바꾸지 말고 클라이언트에 저장된 주소를 업데이트하세요. 이름을 바꿔도 실제 다운로드 위치는 바뀌지 않습니다.

401 또는 403이 표시되면 이용 권한, 주소 유효성, 서비스 제한을 확인하세요. 404라면 경로부터 점검하고, 429라면 반복 요청을 멈춘 뒤 서비스 제공업체의 안내에 따라 기다리세요. 서버 오류는 YAML을 수정해 해결할 문제가 아닙니다. 브라우저에서 열리더라도 다운로드가 정상이라고 단정할 수는 없습니다. 브라우저는 로그인 세션을 사용할 수 있지만 클라이언트는 별도 요청을 보내므로 서로 다른 콘텐츠가 반환될 수 있습니다.

업데이트 요청이 현재 프록시에 의존하는지도 확인하세요. 클라이언트에 따라 구독을 직접 연결로 업데이트하거나 프록시를 거쳐 업데이트하는 기능이 있지만 이름과 기본 동작은 다를 수 있습니다. 기존 출구가 작동하지 않는데 구독 업데이트도 그 출구를 통과하도록 되어 있다면, 고장 난 프록시를 통해 업데이트해야 하는 순환 문제가 생깁니다. 사용 가능한 네트워크에서 직접 업데이트하거나 검증된 출구를 임시로 선택하세요. 구독을 다운로드하려고 인증서 검증을 임의로 끄거나, 주소를 낯선 온라인 변환 서비스에 넘기지 마세요.

파싱 오류라면 실제 형식과 오류가 난 줄을 확인하세요

다운로드에 성공했다고 해서 콘텐츠가 현재 클라이언트에 적합하다는 뜻은 아닙니다. 반환된 내용은 YAML 설정, 프로토콜 링크 모음, 로그인 페이지 또는 오류 안내일 수 있습니다. yaml: unmarshal errors, cannot unmarshal 같은 메시지는 줄 번호와 함께 구조를 확인하세요. 내용이 웹페이지 태그로 시작한다면 웹페이지를 한 줄씩 수정할 것이 아니라 구독 주소나 접근 권한부터 바로잡아야 합니다. Base64 텍스트는 파일 확장자를 .yaml로 바꾸는 것만으로 완전한 설정이 되지 않습니다.

# 계층 구조만 보여 주는 예시입니다. 노드를 포함하지 않으며 완전한 구독을 대신할 수 없습니다
mode: rule
mixed-port: 7890
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

YAML은 공백으로 들여쓰며 Tab을 섞어 쓰지 마세요. 목록 항목에는 하이픈이 필요하고, 필드의 콜론 뒤에는 보통 공백을 넣습니다. 오류 줄은 파서가 문제를 발견한 위치일 뿐이며, 실제로 따옴표나 계층이 빠진 곳은 바로 앞 줄일 수 있습니다. 정책 그룹을 참조한다면 이름이 정의와 완전히 일치해야 합니다. 구독에 현재 코어가 지원하지 않는 프로토콜이나 필드가 포함되어 있다면 서비스 제공업체에 호환 형식을 요청하거나 호환되는 클라이언트를 선택하세요. 알 수 없는 필드를 삭제한다고 설정이 그대로 유지되는 것은 아닙니다.

업데이트가 끝나면 활성화와 저장 여부도 확인하세요

‘업데이트 성공’이 표시되면 방금 업데이트한 설정이 현재 활성화되어 있는지 확인한 다음, 프록시 페이지에서 필요한 정책 그룹이 있는지 확인하세요. 일부 클라이언트는 ‘구독 다운로드’, ‘프로바이더 새로고침’, ‘코어 다시 불러오기’를 별도 작업으로 구분합니다. 캐시가 남아 있으면 목록이 바뀌지 않은 것처럼 보일 수도 있습니다. 새 설정에 포함된 출구를 실제 연결 기록에서 사용해야 업데이트가 제대로 적용된 것입니다. 화면에 표시된 마지막 업데이트 시각만으로 확인을 끝내지 마세요.

구독 생성 파일에 직접 수정 사항을 넣으면 다음 업데이트 때 덮어써질 수 있습니다. 포트, DNS, 규칙 변경을 유지하려면 클라이언트가 지원하는 오버라이드, 병합 또는 확장 설정 기능을 사용하고 병합 순서부터 확인하세요. 형식을 더 자세히 알아보려면 구독 가져오기 및 YAML·Base64 형식 안내를 참고하세요. 처음 가져올 때는 시작하기를 따르세요. 클라이언트를 바꾸려면 먼저 다운로드 페이지의 Clash Plus에서 플랫폼 호환성을 확인할 수 있지만, 클라이언트가 유효한 구독과 올바른 권한을 대신해 주지는 않습니다.

속도 저하: 규칙과 연결 경로 점검

먼저 ‘느리다’는 증상을 구체적으로 구분하세요. 페이지 응답이 늦는지, 다운로드 속도가 계속 낮은지, 동영상이 간헐적으로 버퍼링되는지에 따라 DNS, 연결 핸드셰이크, 출구 혼잡, 앱 자체 제한 등 원인이 다를 수 있습니다. 비슷한 시간대에 같은 대상, 같은 파일, 같은 출구로 비교하세요. 클라우드 동기화, 시스템 업데이트, 대용량 트래픽 작업도 잠시 중지하세요. 서로 다른 사이트에서 나온 결과를 직접 비교하거나, 한 번의 빠른 속도 테스트로 장시간 전송도 안정적이라고 판단하지 마세요.

먼저 출구를 확인한 뒤 연결과 전송 속도를 비교하세요

‘연결’ 페이지에서 속도가 느린 요청을 찾아 적용된 규칙, 정책 그룹, 실제 노드를 확인하세요. 웹사이트의 기본 페이지와 다운로드 파일이 서로 다른 도메인을 사용할 수 있으므로 기본 페이지가 프록시를 통과한다고 파일도 같은 출구를 사용한다는 뜻은 아닙니다. 정책을 바꾼 뒤에도 기존 연결은 이전 출구를 계속 사용할 수 있습니다. 비교하려면 해당 앱을 닫거나 관련 연결만 종료한 다음 새 요청을 보내세요. 테스트를 위해 정책 그룹 전체를 자주 바꾸면 매번 조건이 달라집니다.

규칙 모드에서는 느리지만 전역 모드에서는 정상이라면 대상 도메인이 부적절한 직접 연결 규칙과 일치했거나 관련 도메인들이 서로 다른 출구를 사용하는지 확인하세요. 두 모드에서 모두 느리다면 노드와 로컬 네트워크를 점검하세요. 특정 사이트 하나만 느리다면 출구 IP별 사이트 속도 제한, CDN 배정, 지역별 차이도 원인일 수 있습니다. 이 경우 클라이언트를 바꾸는 것이 우선은 아닙니다. 같은 리소스에 다른 출구로 접속해 사이트 경로와 소프트웨어 설정 중 무엇이 원인인지 먼저 구분하세요.

GeoIP 업데이트: 해당 데이터에 의존하는 규칙만 점검

GEOIP는 대상 IP의 지역을 기준으로 일치 여부를 판단하며, 회선 품질을 측정하지 않습니다. 로그에 지리 데이터베이스 다운로드 또는 로드 실패가 표시되면 현재 설정이 어떤 데이터 모드를 사용하는지와 클라이언트의 실제 데이터 디렉터리를 먼저 확인하세요. 코어마다 데이터베이스 파일과 로드 방식이 다를 수 있습니다. 인터넷에서 찾은 파일의 이름을 임의로 바꿔 덮어쓰지 마세요. 업데이트 기능은 보통 ‘설정’, ‘코어’ 또는 지리 데이터 관련 페이지에 있습니다. 메뉴 이름은 클라이언트마다 다를 수 있습니다.

업데이트한 뒤 로그에서 다운로드가 끝나고 다시 불러오기도 성공했는지 확인하세요. 다운로드 시작만 표시된 것은 완료가 아닙니다. 업데이트 주소에 접속할 수 없다면 먼저 다운로드 경로를 복구한 뒤 클라이언트가 지원하는 업데이트 메뉴에서 다시 시도하세요. 근거 없이 출처 주소를 바꾸거나, 아직 읽을 수 있는 기존 데이터베이스를 삭제해 업데이트를 강제하지 마세요. 규칙 프로바이더를 사용하는 설정에서는 해당 규칙 세트도 각각 새로고침해야 합니다. GeoIP 데이터와 원격 규칙 세트는 서로 다른 리소스입니다.

데이터베이스를 업데이트한 뒤 느린 요청을 새로 만들어 규칙이 예상대로 바뀌는지 확인하세요. IP 지역 정보는 데이터 시점과 CDN 경계의 영향을 받습니다. 특정 대상에 문제가 계속되면 용도를 확인한 뒤 범위가 좁은 도메인 규칙을 관련 범용 규칙보다 앞에 추가할 수 있습니다. 아래 예시는 순서만 보여 줍니다. Proxy는 현재 설정에 이미 정의된 정책 그룹이어야 합니다. 없다면 실제 이름으로 바꾸세요. 그대로 복사한다고 출구가 자동으로 생성되지는 않습니다.

rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

무선 네트워크, UDP, 전송 경로도 확인하세요

같은 기기에서 모든 출구가 느리다면 유선으로 연결하거나 라우터 가까이에서 다시 테스트하고 휴대폰 핫스팟과 비교하세요. 무선 간섭, 라우터 부하, 업로드 회선 포화도 프록시 불안정처럼 나타날 수 있습니다. TUN을 켰을 때만 느리다면 먼저 TUN을 끄고 명시적 프록시로 같은 대상을 테스트하세요. 차이가 꾸준히 나타나면 가상 네트워크 어댑터, 라우트 충돌, MTU를 확인하세요. 정해진 MTU 값을 그대로 적용하지 말고 기존 값을 기록한 뒤 한 번에 하나씩 바꾸고 복구할 수 있게 하세요.

일부 앱은 QUIC을 우선 사용하므로 UDP가 제한되면 일반 웹페이지의 TCP 테스트는 정상이어도 계속 대기할 수 있습니다. 앱에서 지원한다면 관련 기능을 잠시 꺼서 비교해 보세요. 모든 UDP를 끄는 것을 일반적인 속도 향상 방법으로 삼아서는 안 됩니다. 네트워크, 출구, 규칙, 대상, 발생 시간대 등 재현 가능한 조건을 기록하세요. 정책 그룹 선택 방식은 정책 그룹 용어 안내에서 확인할 수 있습니다. DNS 확인 단계에서만 대기가 길다면 연결 시간 제한을 계속 늘리지 말고 다음 장을 확인하세요.

DNS 문제: 이름 확인 경로 점검

DNS 문제는 no such host 오류, 도메인 접속 실패, 첫 접속 지연 또는 TUN을 켠 뒤 일부 앱이 연결되지 않는 증상으로 나타날 수 있습니다. 먼저 실패한 대상이 노드 도메인인지, 웹사이트 도메인인지, DNS 상위 서버 자체인지 확인하세요. 노드 도메인이 확인되지 않으면 여러 사이트가 함께 실패할 수 있습니다. 특정 대상 하나만 실패한다면 해당 도메인이나 그에 연결된 상위 서버 문제일 수 있습니다. 웹페이지가 열리지 않는다고 시스템 DNS, 코어 DNS, 브라우저 보안 DNS를 한꺼번에 바꾸지 마세요. 실제로 어느 단계가 적용됐는지 파악하기 어려워집니다.

시스템, 브라우저, 코어의 DNS 결과를 구분하세요

시스템의 nslookup은 실제로 질의한 리졸버의 결과만 보여 주며 브라우저나 코어와 같다고 보장하지 않습니다. 브라우저는 별도의 암호화 DNS를 사용할 수 있고, 코어는 nameserver-policy에 따라 특정 도메인을 다른 상위 서버로 보낼 수 있습니다. 먼저 시스템에 설정된 DNS를 기록하고 클라이언트의 DNS 설정과 실제 적용된 설정을 확인하세요. 수정 후에는 오버라이드 기능이 구독 항목을 덮어쓰는지도 확인해야 합니다. 파일만 바뀌고 실행 매개변수는 그대로일 수 있습니다.

문제를 꾸준히 재현할 수 있는 도메인을 골라 시스템 조회, 브라우저 접속, 코어 로그를 각각 확인하세요. 시스템 조회는 정상인데 프록시 요청이 실패한다면 코어의 상위 서버와 연결 경로를 점검하세요. 브라우저만 정상이고 다른 앱은 실패한다면 브라우저가 별도로 DNS를 확인하는지 살펴보세요. 시스템, 브라우저, 코어가 서로 다른 결과를 캐시할 수도 있습니다. 한 곳의 캐시를 지운다고 모두 지워지지는 않습니다. 캐시를 지운 뒤에는 새 연결을 만들어 확인하고 기존 연결을 계속 관찰하지 마세요.

상위 서버 주소를 많이 넣기보다 실제로 연결되는지 확인하세요

암호화 DNS를 사용해도 상위 서버에 접속하려면 네트워크 연결이 필요합니다. 상위 서버 주소를 도메인으로 지정한 경우에는 해당 도메인을 먼저 확인해야 할 수도 있습니다. default-nameserver의 부트스트랩 용도와 nameserver의 일반적인 DNS 확인 용도를 구분하세요. 규칙에 따라 상위 서버 연결 경로를 선택하는 기능을 켰다면 순환 의존성이 생기지 않았는지도 확인해야 합니다. 노드 도메인을 프록시로 확인해야 하는데 프록시를 연결하려면 노드부터 확인해야 하는 상황이 그 예입니다. 이때는 상위 서버 주소를 더 추가하기보다 코어 문서에 따라 노드 도메인의 독립적인 확인 경로를 설정하세요.

아래 예시는 일반 DNS 연결을 임시로 확인하기 위한 설정이며 모든 네트워크에 권장되는 설정이 아닙니다. TUN 처리는 포함하지 않습니다. 이 필드를 지원하는 mihomo 설정에서만 사용할 수 있습니다. 병합 전에 기존 설정을 보존하고 로컬 수신 포트가 사용 중인지 확인하세요. 일부 네트워크에서는 일반 UDP DNS가 제한되거나 간섭을 받을 수 있습니다. 따라서 테스트 성공 여부는 하나의 참고 자료일 뿐이며 암호화 DNS의 접속 결과를 대신하지 않습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

Fake-IP, 로컬 네트워크 이름, DNS 가로채기는 각각 확인하세요

Fake-IP를 켜면 합성 주소가 반환되는 것은 정상적인 동작입니다. 단, 이후 연결도 같은 코어에 도달하고 매핑을 찾을 수 있어야 합니다. 앱이 합성 주소를 받은 뒤 TUN을 우회해 직접 연결하면 실패할 수 있습니다. 합성 주소를 실제 서버 주소로 착각해 다른 기기에 저장하지 말고, 해당 IP에 직접 접속한 결과로 웹사이트 상태를 판단하지 마세요. 특정 기기 검색이나 로컬 네트워크 서비스 때문에 필터가 필요하다면 충돌이 확인된 도메인 범위만 추가하세요. 모든 도메인을 제외하면 테스트 결과를 해석하기 어려워집니다.

프린터, NAS, 사내 도메인은 로컬 리졸버, 검색 접미사 또는 멀티캐스트에 의존하는 경우가 많습니다. 공용 DNS는 이런 이름을 알지 못하므로 공용 서버로 바꾼 뒤 작동하지 않을 수 있습니다. 도메인별 DNS 정책이 있는지, TUN 라우트가 로컬 네트워크 접근을 허용하는지 확인하세요. 일반 DNS 가로채기가 앱 내장 암호화 DNS까지 처리한다고 보장할 수는 없습니다. 특정 앱이 예상한 확인 경로를 계속 우회한다면 가로채기 범위를 더 넓히기보다 앱 설정을 비교하세요.

복구한 뒤에는 원래 문제가 난 도메인, 네트워크, 앱으로 다시 테스트하고 임시로 낮춘 로그 수준과 테스트 설정을 되돌리세요. 먼저 DNS 경로를 안정화한 다음 트래픽 분기나 성능을 확인하면 캐시가 우연히 일치한 결과를 해결로 착각하지 않을 수 있습니다. 필드 계층과 오버라이드 관계는 config.yaml의 port·dns·rules 구성 안내에서 확인하세요. DNS는 정상인데 연결 기록이 없다면 리졸버를 계속 바꾸지 말고 트래픽 처리 항목으로 이동하세요.

시스템 프록시 문제: 트래픽 처리 여부 확인

‘시스템 프록시 사용’이 켜져 있어도 기기의 모든 앱이 Clash를 통과하는 것은 아닙니다. 시스템 프록시는 보통 이를 지원하는 앱에 HTTP 등의 프록시 설정을 제공합니다. 직접 연결을 만들거나, 별도 프록시를 설정했거나, 시스템 설정을 읽지 않는 프로그램은 계속 직접 연결할 수 있습니다. 먼저 첫 장의 명시적 프록시 테스트로 로컬 서비스가 작동하는지 확인한 다음 문제가 있는 앱의 트래픽 처리 방식을 점검하세요. 명시적 프록시도 실패한다면 시스템 스위치를 반복해서 바꾸기보다 코어와 포트를 먼저 복구하세요.

시스템에 설정된 주소와 포트를 확인하세요

클라이언트에서 혼합 포트 또는 HTTP 포트를 확인한 다음 시스템 네트워크의 프록시 설정으로 이동해 호스트와 포트가 일치하는지 확인하세요. 로컬 기기에서는 보통 127.0.0.1을 사용하며 노드 서버 주소를 입력하지 않습니다. external-controller는 제어 인터페이스이지 브라우저 프록시 포트가 아닙니다. 9090을 프록시 포트로 입력하면 연결에 실패합니다. HTTP와 SOCKS 프로토콜도 일치해야 합니다. 단, 설정에서 둘 다 받는 혼합 포트를 사용하는 경우는 예외입니다.

Windows에서는 사용자 프록시 설정과 일부 서비스에서 사용하는 WinHTTP 프록시를 구분하세요. 한 화면의 스위치가 다른 설정까지 바꾼다고 보장할 수 없습니다. macOS에서는 현재 활성화된 네트워크 서비스를 확인하세요. Wi-Fi와 다른 네트워크 어댑터에 서로 다른 설정이 적용될 수 있습니다. Linux 데스크톱의 프록시 설정도 모든 프로그램이 읽는 것은 아닙니다. 주소가 남아 있다면 먼저 어느 프로그램이 설정했는지 확인한 다음 해당 화면에서 수정하세요. 업무용 네트워크에 영향을 주는 전역 초기화 명령을 인터넷에서 복사해 실행하지 마세요.

포트 충돌과 앱별 설정 덮어쓰기를 각각 확인하세요

시작 로그에 address already in use 또는 bind 실패가 표시되면 먼저 포트를 사용 중인 프로세스를 확인하세요. Windows에서는 아래 명령으로 수신 대기 정보를 확인한 뒤 작업 관리자에서 프로세스를 식별할 수 있습니다. PID가 하나 보인다고 무조건 종료하지 마세요. 다른 서비스에서 사용 중인 프로세스일 수 있습니다. 포트를 바꾼다면 클라이언트, 시스템 프록시, 수동으로 설정한 앱의 포트를 모두 맞춘 뒤 연결을 다시 시작하세요.

netstat -ano | findstr :7890

터미널은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY 환경 변수를 읽을 수 있으며 브라우저 확장 프로그램이 시스템 프록시를 덮어쓸 수도 있습니다. 먼저 앱에서 시스템 설정을 따르도록 되돌리거나 명확한 로컬 프록시를 임시로 지정해 비교하세요. 환경 변수를 바꾼 뒤에도 기존 터미널이나 이미 실행 중인 앱은 이전 값을 계속 사용할 수 있으므로 새로 열어야 합니다. 프록시 우회 목록에 있는 도메인도 결과에 영향을 줍니다. 확인할 때 와일드카드와 주소 범위를 놓치지 마세요.

필요한 경우에만 TUN을 테스트에 추가하세요

명시적 프록시는 정상이고 대상 앱이 시스템 프록시를 지원하지 않을 때만 TUN을 따로 테스트하세요. 클라이언트에 필요한 서비스 또는 권한이 정상적으로 활성화됐는지, 가상 인터페이스와 라우트가 설정됐는지 확인하세요. 스위치가 켜져 있어도 코어 로그에 오류가 있으면 트래픽 처리가 완료된 것이 아닙니다. 다른 VPN, 가상 머신 네트워크, 컨테이너 네트워크 대역이 TUN 규칙과 충돌할 수 있습니다. 원래 라우트와 제외 범위를 기록하고 충돌 가능성이 있는 도구를 하나씩 중지해 비교하세요. 라우트 테이블 전체를 지우지 마세요.

로컬 네트워크 연결 허용과 이 기기의 시스템 프록시는 별개입니다. 이 기기에서 프록시를 사용할 때는 보통 allow-lan을 켤 필요가 없습니다. 다른 기기가 이 기기의 프록시에 접속해야 하는 경우에만 수신 주소, 방화벽 범위, 신뢰할 수 있는 네트워크 경계를 확인하세요. 다른 기기에는 이 컴퓨터의 로컬 네트워크 주소를 입력해야 하며 그 기기 자신의 127.0.0.1을 입력하면 안 됩니다. 포트 기본 사용법은 포트 설정 가이드를 참고하세요. 부팅 후 작동하지 않는다면 시작 시 자동 실행 FAQ와 함께 코어가 실제로 실행됐는지 확인하세요.

클라이언트 충돌: 로그를 보존한 뒤 복구

먼저 UI가 종료된 것인지, 멈춘 것인지, 코어가 중단된 것인지 구분하세요. 창이 사라져도 프록시 코어는 계속 실행 중일 수 있고, 창이 남아 있어도 코어가 이미 종료됐을 수 있습니다. 프로세스 목록, 수신 대기 포트, 마지막 로그를 확인한 다음 문제 범위를 판단하세요. 기기 전체에서 네트워크 문제가 생겼다면 클라이언트 데이터보다 먼저 시스템 프록시와 TUN을 복구해 기본 연결을 확보하세요. 재현 조건과 오류 기록을 함께 잃기 쉬우므로 ‘삭제 후 재설치’를 첫 단계로 삼지 마세요.

문제 발생 전후의 핵심 정보를 보존하세요

시작 방법, 시작 중·구독 업데이트 중·특정 페이지를 열 때 중 어느 시점에 문제가 발생했는지, 직전에 설정을 바꿨는지 기록하세요. 마지막 한 줄만 캡처하지 말고 시간 정보와 앞뒤 내용이 포함된 로그 파일을 복사해 보관하세요. 설정 오류가 나오기 전의 메시지가 더 중요할 수 있습니다. 로그에 경로, 서버 도메인, 요청 대상이 포함되어 있다면 공유 전에 민감 정보를 가리세요. 시스템 이벤트와 충돌 보고서에도 사용자 폴더가 포함될 수 있으므로 원본 전체를 공개적으로 올리지 마세요.

같은 설정을 불러올 때마다 시작이 중단된다면 먼저 클라이언트 데이터 디렉터리를 백업한 뒤 프로그램이 제공하는 설정 비활성화 또는 복구 메뉴를 사용하세요. UI에 들어갈 수 있다면 정상적으로 불러올 수 있는 설정으로 전환해 충돌이 계속되는지 비교하세요. UI를 열 수 없다면 클라이언트 문서에 따라 설정 선택 상태를 처리하세요. 알 수 없는 파일을 추측으로 삭제하지 마세요. 사용자 지정 규칙 프로바이더, 큰 설정 파일, 손상된 캐시 등 여러 요소가 원인일 수 있으므로 한 번에 한 종류씩 확인하고 되돌릴 수 있는 사본을 보관하세요.

설치 패키지, 코어, 시스템 권한을 나누어 확인하세요

클라이언트 다운로드 페이지에서 기기의 운영체제와 프로세서 아키텍처를 확인하고, 해당 플랫폼용 Clash Plus 설치 방법을 우선 확인하세요. Clash Verge Rev 또는 FlClash를 선택한 경우에도 패키지 형식이 운영체제에 맞는지 확인해야 합니다. 서로 다른 클라이언트의 프로그램 디렉터리를 덮어쓰거나 코어 파일 하나만 바꿔 호환성을 기대하지 마세요. UI와 코어의 제어 인터페이스 및 설정 생성 방식이 다를 수 있어 혼합 설치하면 문제 재현이 더 어려워집니다.

Windows에서는 보안 소프트웨어의 실제 차단 기록과 필요한 백그라운드 서비스의 실행 여부를 확인하세요. 신뢰할 수 있으며 오탐이 확인된 항목만 처리하고 기기 보호 기능 전체를 계속 끄지 마세요. macOS에서는 출처와 시스템 안내를 먼저 확인한 뒤 시스템 설정 화면에서 필요한 기능을 허용하세요. 모든 클라이언트가 같은 네트워크 확장 방식을 사용하는 것은 아닙니다. 관련 안내는 macOS 권한 및 키체인 처리를 참고하세요. 시스템 보호를 우회하는 명령을 무분별하게 실행하지 마세요.

Linux에서는 터미널에서 해당 프로그램을 먼저 실행해 누락된 의존성, 디스플레이 환경, 권한 오류를 확인하세요. 데스크톱 앱과 서비스 프로세스는 환경 변수, 작업 디렉터리, 사용자 권한이 서로 다를 수 있습니다. ‘터미널에서는 실행되지만 메뉴에서는 실패’한다면 실행 환경을 비교하세요. 시스템 서비스로 실행하는 경우 서비스 관리자의 출력을 확인하고 설정 경로와 파일 읽기 권한을 점검하세요. 일반 UI 실행은 가능한 한 일반 사용자 권한으로 유지하고, 명확한 기능상 필요가 있을 때만 권한을 부여하세요.

모든 데이터를 지우지 말고 단계별로 복구하세요

캐시 문제는 클라이언트의 정리 기능으로 해결할 수 있지만, 먼저 캐시와 구독, 설정, 인증 정보를 구분해야 합니다. 사용자 데이터를 새로 만들어야 한다면 먼저 UI와 관련 백그라운드 프로세스를 종료하고 기존 디렉터리를 삭제하는 대신 백업용으로 옮기세요. 새 데이터로 시작한 뒤 필요한 설정 하나만 가져오고 과거 설정을 전부 복원하지 마세요. 정상적으로 작동하는지 확인한 다음 오버라이드, 규칙 세트, 시작 옵션을 하나씩 복구해야 문제를 일으킨 항목을 찾을 수 있습니다.

복구 후에는 창이 열리는지만 확인하지 말고 처음 문제를 일으킨 동작을 재현하세요. 구독을 한 번 업데이트하고 설정을 다시 불러온 뒤 실제 연결을 만드세요. 문제가 계속되면 클라이언트 이름, 시스템 아키텍처, 재현 순서, 민감 정보를 가린 오류 내용을 제출하고 새 데이터 상태에서도 발생했는지 설명하세요. 버전 관련 결론을 지어내거나 한 번 발생한 종료를 특정 프로토콜 탓으로 돌리지 마세요. UI가 익숙하지 않다면 클라이언트 화면별 안내에서 설정과 로그 메뉴를 찾아보세요.

모바일: 권한, 백그라운드, 네트워크 전환

모바일에서는 연결 직후 실패하는 경우, 화면을 잠근 뒤 중단되는 경우, Wi-Fi에서 모바일 데이터로 바꾼 뒤 실패하는 경우를 먼저 구분하세요. 각 문제는 VPN 권한, 백그라운드 제한, 네트워크 재연결을 우선 확인해야 합니다. 한 네트워크에 고정해 테스트하고 VPN 경로를 사용하는 다른 앱을 종료한 다음 현재 클라이언트를 실행하세요. 일반적으로 모바일 운영체제에서는 주 VPN 경로 하나만 사용할 수 있습니다. 광고 차단, 기업 네트워크, 다른 네트워크 도구가 프록시와 충돌할 수 있으므로 앱 창이 열려 있는지만 확인해서는 안 됩니다.

Android: 권한, 앱 범위, 백그라운드 제한 확인

Android에서 처음 연결할 때 보통 시스템의 VPN 권한 요청이 표시됩니다. 권한을 거부했다면 연결을 다시 시작해 허용해야 합니다. 화면에서 노드를 선택했다고 VPN 경로가 실제로 설정된 것은 아닙니다. 시스템에서 상시 VPN 또는 VPN을 사용하지 않는 연결 차단을 켰다면 현재 클라이언트에 적용되어 있는지 확인하세요. 이전 클라이언트를 비활성화했는데 시스템 제한이 남아 있으면 기기 전체가 오프라인이 될 수 있습니다. 업무 프로필과 개인 프로필은 관리 범위가 다르며 회사 정책이 트래픽 처리를 제한할 수도 있습니다. 일반 앱 설정으로 이를 강제로 바꾸지 마세요.

특정 앱만 프록시를 사용하지 않는다면 앱별 프록시, 우회 목록, 포함·제외 모드를 확인하세요. 대상 앱이 제외 목록에 들어간 경우 노드를 사용할 수 없는 증상과 다르게 나타납니다. 먼저 연결 기록에 해당 요청이 있는지 확인하세요. 앱 자체 프록시나 암호화 DNS 설정도 살펴보세요. 일부 앱은 UDP에 의존하므로 웹페이지가 열려도 음성 통화, 게임, 실시간 통신이 작동한다고 보장할 수 없습니다. 해당 앱에서 실제 사용하는 기능으로 테스트하세요.

화면을 잠근 뒤 연결이 끊긴다면 시스템의 배터리 최적화, 백그라운드 활동, 자동 시작 제한을 확인하세요. 필요한 백그라운드 연결을 허용한 뒤 알림 표시와 로그를 살펴보세요. 제조사마다 설정 메뉴 이름이 다르므로 설정 검색을 이용하고 다른 휴대폰의 안내를 그대로 따라 하지 마세요. 백그라운드 제한을 해제해도 끊긴다면 네트워크 전환 여부와 함께 프로세스가 종료됐는지, VPN은 유지되지만 연결만 안 되는지 기록하세요. 두 경우의 해결 방법은 다릅니다.

iOS: VPN 경로 상태와 구독 유효성 확인

iOS에서는 다운로드 페이지를 통해 Clash Plus의 App Store 페이지로 이동할 수 있습니다. 공식 사이트 주소는 clashplus.io입니다. 처음 사용할 때는 시스템 VPN 설정을 허용한 뒤 앱으로 돌아와 현재 설정과 정책 선택을 확인하세요. 시스템에 VPN 표시가 있어도 경로 상태만 나타낼 뿐 구독이 유효하거나 원격 서버에 연결할 수 있다는 보장은 없습니다. 실제 요청과 앱 로그로 확인하고, 시스템 표시만으로 노드 상태를 판단하지 마세요.

VPN 연결 뒤 모든 사이트에 접속할 수 없다면 먼저 VPN 경로를 끄고 원래 네트워크가 정상인지 확인한 다음 구독, DNS, 출구 순서로 점검하세요. 특정 Wi-Fi에서만 실패한다면 웹 인증이 필요한지 또는 네트워크가 해당 연결 방식을 제한하는지 확인하세요. 기기가 회사에서 관리된다면 VPN 설정이 관리 정책으로 제어될 수 있으므로 조직의 지침을 따르세요. 용도를 알 수 없는 관리 설정을 삭제해 테스트하지 말고, 업무 네트워크 문제를 단순히 클라이언트 권한 부족으로 단정하지 마세요.

네트워크 전환, 핫스팟, 데이터 사용량은 같은 조건으로 비교하세요

Wi-Fi에서 모바일 데이터로 전환하면 기존 연결, DNS 캐시, NAT 매핑이 더 이상 유효하지 않을 수 있습니다. 시스템 네트워크가 안정될 때까지 기다린 다음 VPN 경로를 중지하고 다시 시작한 뒤 대상 앱을 새로 열어 연결을 만드세요. 네트워크를 바꿀 때마다 문제가 재현된다면 두 네트워크에서 각각 연결이 정상인지와 어느 방향으로 전환했는지를 기록하세요. 모바일 데이터 자체의 연결 문제와 클라이언트가 연결을 다시 설정하지 못한 경우를 구분할 수 있습니다. 설정 전체를 먼저 삭제할 필요는 없습니다.

휴대폰 자체에서 프록시를 사용한다고 해서 핫스팟에 연결된 기기도 같은 경로를 자동으로 사용하는 것은 아닙니다. 시스템은 핫스팟 트래픽과 기기 자체의 VPN을 다르게 처리할 수 있으므로 연결된 기기에서 따로 테스트하세요. 휴대폰에서 사이트가 열린다는 이유로 핫스팟 연결 기기도 정상이라고 판단하지 마세요. 모바일 데이터 요금은 통신사 정책을 따르며 프록시가 요금제 제한을 바꾸지는 않습니다. 데이터 사용량이 이상하면 시스템의 앱별 사용량을 확인한 다음 백그라운드 업데이트와 대용량 작업을 점검하세요. 클라이언트 연결 기록을 요금 청구 내역으로 간주하지 마세요.

수정을 마친 뒤 ‘현재 네트워크 접속, 화면 잠금 후 복구, 네트워크 전환 후 새 연결’ 세 단계로 다시 테스트하고 문제 해결 과정에서 임시로 바꾼 설정을 되돌리세요. 그래도 실패하면 네트워크 유형, VPN 경로 상태, 발생 시각, 민감 정보를 가린 로그를 보관하고 해당 시간 초과 또는 DNS 장으로 돌아가 원인을 확인하세요. 문제가 재현되는 경로가 분명해야 클라이언트를 바꿀지 판단할 수 있습니다. 재설치로 구독 권한, 백그라운드 정책, 실제 연결 경로 점검을 대신할 수는 없습니다.