이 글의 목차
Clash는 연결됨으로 표시되는데 인터넷이 안 된다면 어떤 유형의 실패인지부터 확인하세요
'Clash가 연결됨으로 표시된다'는 같은 말도 코어 프로세스가 실행 중이라는 뜻일 뿐 시스템 프록시 포트, 노드 연결, DNS가 정상임을 보장하지는 않습니다. 구체적인 오류 하나, 대상 주소 하나, 현재 모드를 먼저 기록해야 점검을 시작할 수 있습니다.
증상별 첫 확인 지점
| 증상 | 먼저 확인할 항목 |
|---|---|
| 모든 사이트에서 즉시 프록시 연결 실패가 표시됨 | 시스템 프록시가 가리키는 로컬 주소와 포트 |
| 도메인은 열리지 않지만 IP로 직접 접속하면 응답함 | DNS 및 브라우저 보안 DNS |
| 국내 사이트는 정상이나 프록시가 필요한 사이트는 시간 초과됨 | 노드, 정책 그룹, 규칙 일치 결과 |
| 시스템 프록시는 정상이나 TUN을 켜면 전체 연결이 끊김 | 서비스, 가상 네트워크 어댑터, 기본 경로, 다른 VPN |
| 특정 애플리케이션만 실패함 | 해당 프로세스가 Clash에 들어오는지와 애플리케이션 자체 상태 코드 |
두 개의 스위치로 먼저 문제 범위를 나누세요
TUN을 끄고 Rule 모드와 시스템 프록시만 남긴 뒤 같은 웹페이지를 다시 여세요. 시스템 프록시는 되는데 TUN에서 끊긴다면 구독과 노드에는 적어도 하나의 기본 경로가 작동하므로 서비스, 라우팅, DNS를 중점적으로 확인합니다. 두 모드 모두 실패하면 가상 네트워크 어댑터는 아직 건드리지 마세요.
이어서 시스템 프록시를 끄고 직접 연결로 되돌려 일반 네트워크 자체가 정상인지 확인하세요. 직접 연결도 실패한다면 Wi-Fi, 광대역, 기업 인증 또는 라우터 문제부터 처리해야 합니다. Clash는 원래 외부 연결이 없는 기반 네트워크를 고칠 수 없습니다.
이번 요청이 연결 페이지에 나타나는지가 가장 중요한 분기점입니다
연결 기록을 비우고 고정된 도메인 하나에 접속하세요. 새 요청이 전혀 없다면 브라우저가 시스템 프록시를 사용하지 않거나 포트가 잘못됐거나 애플리케이션이 현재 인계 방식을 우회하는 것입니다. 규칙과 노드를 계속 바꿔도 달라지지 않습니다.
요청이 이미 나타난다면 대상, 일치 규칙, 정책 그룹, 오류를 기록하세요. 예상치 못한 DIRECT, REJECT, timeout, connection refused는 각각 다른 계층을 가리킵니다. 트레이 아이콘 색상만 보면 문제를 가장 잘 설명하는 근거를 놓치게 됩니다.
최소 재현 한 번
설정과 노드 고정
자동 전환을 잠시 끄고 출구 하나만 남깁니다.
연결 및 로그 화면 비우기
백그라운드 업데이트를 방금 발생한 웹 요청으로 오인하지 않게 합니다.
같은 HTTPS 주소에 접속하기
Clash에 들어오는지, 어떤 규칙에 일치하는지, 어떤 오류가 생기는지 기록합니다.
변수 하나만 바꾸고 다시 시도하기
노드, 규칙, DNS, TUN을 동시에 바꾸지 않습니다.
즉시 오류가 나면 시스템 프록시와 수신 포트를 확인하세요
브라우저를 열자마자 프록시 서버에 연결할 수 없다고 표시된다면 Windows 또는 macOS가 여전히 127.0.0.1의 이전 포트를 가리키지만 현재 클라이언트가 수신하지 않는 경우가 흔합니다. 클라이언트 설정에서 실제 mixed-port를 확인한 뒤 netstat, lsof 또는 ss로 검증하세요.
포트가 열려 있다면 curl -x로 명시적인 요청을 보내 로컬 프록시 진입점과 시스템 프록시 설정을 구분할 수 있습니다. 명시적 프록시는 성공하고 브라우저만 실패하면 시스템 또는 브라우저 설정 문제입니다. 명시적 프록시도 실패할 때만 코어, 노드, 로그로 돌아가세요.
# 将 7890 换成客户端实际端口
curl -I -x http://127.0.0.1:7890 https://example.com
# Windows
netstat -ano | findstr :7890
# macOS / Linux
lsof -nP -iTCP:7890 -sTCP:LISTEN이름 확인에만 이상이 있을 때 DNS를 점검하세요
도메인 요청에 오랫동안 대상 주소가 나타나지 않거나 nslookup이 실패하거나 브라우저 보안 DNS를 끈 뒤 증상이 달라질 때만 DNS를 우선 점검할 가치가 있습니다. 먼저 브라우저, 시스템, Clash가 하나의 이름 확인 진입점을 사용하게 한 뒤 nameserver 연결 여부를 확인하세요.
시스템은 라우터 DNS를 쓰고 브라우저는 보안 DNS를 별도로 켜면 Clash가 전체 도메인을 받지 못할 수 있습니다. 점검할 때 브라우저 DoH를 잠시 꺼서 같은 도메인이 시스템에서 Clash까지 하나의 이름 확인 경로만 지나게 하세요. 복구한 뒤 다시 켤지 결정합니다.
Fake-IP를 사용한다면 정상적인 가상 주소와 오래된 캐시를 먼저 구분하세요
Fake-IP 모드에서 도메인이 198.18.0.0/15 같은 주소로 확인되는 것은 보통 정상입니다. 애플리케이션이 먼저 가상 주소에 연결하면 Mihomo가 이를 도메인으로 복원해 규칙과 대조합니다. 198.18.x.x가 보인다는 사실만으로 DNS 오염을 뜻하지는 않습니다. 연결 페이지에서 원래 도메인이 유지되고 예상 정책에 일치하는지가 핵심입니다.
실제로 처리해야 할 문제는 설정 전환, 규칙 수정 또는 Redir-Host에서 Fake-IP로 변경한 뒤에도 시스템과 애플리케이션이 이전 결과를 유지하는 경우입니다. 먼저 테스트 애플리케이션을 닫고 시스템 DNS 캐시를 정리한 뒤 Mihomo 코어를 다시 시작해 재검증하세요. 기존 연결을 유지한 채 고급 모드를 연속으로 바꾸지 마세요.
NAS, 프린터, 라우터 관리 화면, 기업 내부 도메인이 실제 내부 네트워크 주소를 반환해야 한다면 현재 설정의 fake-ip-filter에 추가하거나 해당 내부 DNS가 처리하게 하세요. 로컬 도메인은 실제 LAN 주소로 계속 확인되고 공용 도메인은 연결 페이지에서 도메인으로 복원되어 올바르게 분리 라우팅되어야 합니다.
ipconfig /flushdns요청이 들어온 뒤 규칙, 노드, TUN 문제를 각각 나눠 처리하세요
요청이 DIRECT에 일치한 뒤 시간 초과됨
흔한 원인:구체적인 규칙보다 포괄적인 직접 연결 규칙이 먼저 일치함
해결 방법:최종 규칙 순서를 확인하고 정밀한 규칙을 GEOIP와 MATCH보다 앞에 두세요.
프록시 그룹에 일치하지만 dial timeout 발생
흔한 원인:현재 노드, 프로토콜 또는 원격 서버에 연결할 수 없음
해결 방법:DNS는 그대로 두고 정상 작동이 확인된 다른 노드를 고정해 비교하세요.
로컬 프록시에서 connection refused 발생
흔한 원인:포트가 수신 중이 아니거나 시스템 프록시 설정이 잘못됨
해결 방법:mixed-port, 프로세스 상태, 포트 점유 여부를 확인하세요.
TUN에서만 전체 연결이 끊김
흔한 원인:서비스 권한, 기본 경로, 가상 네트워크 어댑터 또는 다른 VPN 충돌
해결 방법:시스템 프록시로 돌아간 뒤 항목별로 확인하고 시스템 전체 네트워크 초기화는 실행하지 마세요.
마지막에는 '요청이 Clash에 들어와 PROXY에 일치했고 고정 노드가 dial timeout을 반환한다'처럼 구체적인 한 문장으로 문제를 설명할 수 있어야 합니다. '프로그램은 초록색인데 인터넷이 안 된다'는 표현으로는 부족합니다. 이 문장에 다음으로 처리할 계층이 이미 담겨 있습니다.