이 글의 목차
프록시 앱에 “연결됨”이 표시되는 것은 문제 확인의 시작일 뿐입니다. 방금 접속한 대상에서 실제 결과가 돌아왔는지 확인해야 합니다. 웹페이지에서 즉시 프록시 오류가 나는 경우, 도메인 이름으로만 접속이 실패하는 경우, 가상 네트워크 어댑터를 켠 뒤 기기 전체가 연결되지 않는 경우는 점검 위치가 다릅니다. 구체적인 증상을 기록해 규칙, 노드, 시스템 설정을 한꺼번에 뒤섞어 바꾸지 않도록 하세요.
연결됨 표시만으로 요청 성공을 확인할 수는 없다
접속에 실패한 대상, 오류 원문, 현재 모드를 기록하고 아래 표에서 점검 항목을 선택하세요. 코어가 실행 중이라고 프록시 포트가 정상인 것은 아니며, 노드에 연결된다고 DNS가 정상인 것도 아닙니다. 각각 확인해야 합니다.
아래 시스템 프록시 비교와 포트 확인은 Windows/macOS에 적용됩니다. Android에서는 휴대폰 안내에 따라 VPN 권한과 앱별 설정부터 확인하세요. 연결 기록이 있다면 뒤에 나오는 DNS, 규칙, 노드 판단 방법도 참고할 수 있습니다.
증상별 첫 확인 지점
| 증상 | 먼저 확인할 항목 |
|---|---|
| 모든 사이트에서 즉시 프록시 연결 실패가 표시됨 | 시스템 프록시가 가리키는 로컬 주소와 포트 |
| 도메인은 열리지 않지만 IP로 직접 접속하면 응답함 | DNS 및 브라우저 보안 DNS |
| 국내 사이트는 정상이나 프록시가 필요한 사이트는 시간 초과됨 | 노드, 정책 그룹, 규칙 일치 결과 |
| 시스템 프록시는 정상이나 TUN을 켜면 전체 연결이 끊김 | 서비스, 가상 네트워크 어댑터, 기본 경로, 다른 VPN |
| 특정 애플리케이션만 실패함 | 해당 프로세스가 Clash에 들어오는지와 애플리케이션 자체 상태 코드 |
시스템 프록시, TUN, 직접 연결 비교
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를 끈 뒤 결과가 달라지면 이름 해석 경로를 확인하세요. 비교를 위해 브라우저 DoH를 잠시 끈 뒤 시스템과 Clash가 실제로 사용하는 해석 경로와 nameserver 접근 가능 여부를 확인합니다. 스위치 하나를 끈다고 양쪽 해석 설정이 자동으로 같아지지는 않습니다.
복구 후 브라우저의 별도 이름 해석을 다시 켤지 결정하세요. 라우터와 브라우저가 각각 이름을 해석하면 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 충돌
해결 방법:시스템 프록시로 돌아간 뒤 항목별로 확인하고 시스템 전체 네트워크 초기화는 실행하지 마세요.