클라이언트에 ‘연결됨’이 표시되고 노드 옆에 지연 시간이 나타나도 Clash 코어가 실행 중이거나 테스트 요청에 응답했다는 의미일 뿐입니다. 브라우저에서 웹페이지가 열리려면 애플리케이션 트래픽이 수신 포트로 들어오고, 규칙이 올바른 출구를 선택하며, DNS가 사용 가능한 결과를 반환하고, 선택한 노드가 실제 TLS 연결을 완료해야 합니다. 점검할 때는 여러 설정을 연속으로 바꾸지 말고 트래픽 유입 지점부터 단계적으로 확인하세요.
1단계: 네트워크 장애와 프록시 경로 장애 구분
먼저 Clash를 창만 닫지 말고 완전히 종료하세요. 시스템 프록시가 꺼진 상태로 복원됐는지 확인한 다음 로컬 네트워크와 일반 웹사이트에 접속합니다. 직접 연결에서도 웹페이지가 열리지 않는다면 문제는 대개 Wi-Fi, 유선 네트워크, 라우터, 인증 포털 또는 통신사 연결에 있습니다. 이 경우 Clash 설정을 계속 수정하지 마세요.
기본 테스트 3가지 실행
- 라우터 관리 주소(예:
192.168.1.1)를 엽니다. 페이지가 열리면 기기와 로컬 네트워크 게이트웨이 사이의 경로는 정상입니다. - 터미널에서
ping 1.1.1.1을 실행합니다. 일부 네트워크는 ICMP를 차단하므로 시간 초과만으로 인터넷 연결이 끊겼다고 단정할 수는 없습니다. 다만 지속적으로 응답이 오면 기본 IP 경로가 사용 가능하다는 뜻입니다. nslookup example.com을 실행합니다. IP 주소에는 접근할 수 있지만 도메인 조회가 시간 초과된다면 먼저 시스템 DNS 또는 라우터 DNS를 점검하세요.
호텔, 공항, 학교 네트워크는 웹페이지에서 인증을 요구하는 경우가 많습니다. 이런 네트워크에 연결한 뒤에는 프록시를 잠시 끄고 일반 HTTP 페이지에 접속해 인증 포털을 띄우세요. 인증을 완료한 후 Clash를 시작합니다. 인증 전에는 노드 지연 시간이 표시되더라도 이후 HTTPS 요청이 게이트웨이에 의해 차단될 수 있습니다.
2단계: 시스템 프록시가 실제로 Clash 포트를 가리키는지 확인
‘시스템 프록시’는 운영체제의 프록시 설정을 따르는 브라우저와 애플리케이션의 트래픽을 Clash로 보냅니다. 코어는 실행 중인데 시스템 프록시가 꺼져 있으면 로그에 브라우저의 새 연결이 보이지 않고 웹페이지도 계속 직접 연결됩니다. Clash Verge Rev 2.x에서는 「설정」→「시스템 설정」→「시스템 프록시」에서 확인하고, 구버전 Clash for Windows 0.20.39에서는 메인 화면의 System Proxy를 확인합니다. 클라이언트마다 문구는 조금씩 다르지만 최종적으로 로컬 루프백 주소와 실제 수신 포트가 입력되어야 합니다.
수신 주소와 포트 확인
일반적인 설정은 HTTP와 SOCKS5 요청을 모두 받는 mixed-port: 7890입니다. port: 7890과 socks-port: 7891을 별도로 사용하는 구성도 있습니다. 이는 흔한 예시일 뿐이므로 현재 설정과 클라이언트 설정 화면에 표시된 포트를 기준으로 확인해야 합니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infomacOS 15에서는 「시스템 설정」→「네트워크」→ 현재 네트워크 인터페이스 →「세부사항」→「프록시」에서 웹 프록시와 보안 웹 프록시를 확인할 수 있습니다. 서버는 보통 127.0.0.1이어야 하며 포트는 Clash의 HTTP 또는 혼합 포트와 일치해야 합니다. Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시를 확인합니다. 이미 종료한 다른 클라이언트의 포트가 남아 있으면 브라우저 요청이 바로 실패할 수 있습니다.
브라우저를 거치지 않고 로컬 프록시 테스트
혼합 포트가 7890이라고 가정하고 macOS 또는 Linux 터미널에서 실행합니다:
curl -I -x http://127.0.0.1:7890 https://cp.cloudflare.com/generate_204
curl -I --socks5-hostname 127.0.0.1:7890 https://example.comWindows PowerShell에서는 명령 별칭에 따른 매개변수 차이를 피하기 위해 curl.exe를 명시적으로 호출합니다:
curl.exe -I -x http://127.0.0.1:7890 https://cp.cloudflare.com/generate_204127.0.0.1 연결이 즉시 거부되면 포트가 수신 대기 중이 아니거나, 포트 입력이 잘못됐거나, 코어가 중지된 상태입니다. 요청이 로그에 들어온 뒤 시간 초과된다면 로컬 진입점은 정상이며 노드, DNS, 규칙을 계속 확인해야 합니다.
3단계: 포트 충돌과 코어 시작 오류 배제
여러 프록시 클라이언트를 동시에 실행할 때 가장 흔한 충돌은 모두 7890 포트를 사용하려는 경우입니다. 화면의 프로세스는 정상적으로 보일 수 있지만 코어 로그에는 address already in use, bind failed 또는 수신 실패 메시지가 나타납니다. 이때 시스템 프록시가 127.0.0.1:7890을 가리켜도 해당 포트는 다른 프로그램이 사용 중일 수 있습니다.
포트 사용 프로세스 확인
macOS와 Linux에서는 다음 명령을 실행합니다:
lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTENWindows에서는 PowerShell에서 다음 명령을 실행합니다:
Get-NetTCPConnection -State Listen -LocalPort 7890
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 7890).OwningProcess7890은 일반적으로 프록시 진입 포트이고, 9090은 외부 제어 인터페이스에 사용됩니다. 용도가 다르므로 시스템 프록시에 제어 포트를 잘못 입력하지 마세요. 충돌을 확인했다면 이전 프로세스를 종료하거나 현재 설정의 혼합 포트를 7897과 같이 변경한 뒤 시스템 프록시도 함께 업데이트합니다. YAML만 수정하고 운영체제의 프록시 설정을 바꾸지 않으면 포트 불일치가 새로 발생합니다.
4단계: 노드가 실제 웹 요청을 처리할 수 있는지 확인
지연 시간 테스트가 완전한 사용 가능성을 의미하지는 않습니다. 클라이언트는 테스트 URL에 작은 HTTP 요청 하나만 보낼 수 있지만 웹페이지 로딩에는 DNS, TLS 1.3, HTTP/2, 여러 도메인과 지속적인 데이터 전송이 포함됩니다. 노드에 82 ms가 표시되어도 패킷 손실, 출구 혼잡, 인증서 핸드셰이크 중단 또는 대상 사이트의 제한이 있을 수 있습니다.
출구 노드를 순서대로 전환
- 프록시 모드를 일시적으로 「전역」으로 설정하고 특정 노드를 하나 선택하세요. 자동 정책 그룹은 선택하지 마세요.
https://cp.cloudflare.com/generate_204에 접속합니다. 정상적인 결과는 대개 HTTP204입니다.- 단일 사이트의 점검으로 잘못 판단하지 않도록 서로 다른 네트워크 사업자의 웹사이트 두 곳을 추가로 열어 보세요.
- 다른 지역이나 다른 회선을 사용하는 노드로 바꿔 테스트를 반복합니다. 한 노드만 실패한다면 우선 노드 측 문제로 판단할 수 있습니다.
모든 노드가 연결 단계에서 시간 초과된다면 구독 만료 여부, 노드 도메인 해석 가능 여부, 기기 시간의 정확성, 현재 네트워크의 프로토콜 제한 여부를 확인하세요. 시스템 시간이 몇 분만 어긋나도 TLS 인증서 검증이 실패할 수 있습니다. macOS에서는 「시스템 설정」→「일반」→「날짜 및 시간」에서 자동 설정을 켜고, Windows 11에서는 「설정」→「시간 및 언어」→「날짜 및 시간」에서 즉시 동기화를 실행하세요.
로그의 connection refused는 대개 원격 포트가 연결을 거부했다는 뜻이고, i/o timeout은 경로 시간 초과에 가깝습니다. TLS handshake timeout은 TCP 연결 후 암호화 핸드셰이크가 제때 완료되지 않았다는 의미입니다. 세 메시지는 서로 다른 장애 계층을 가리키므로 모두 클라이언트 문제로 단정해서는 안 됩니다.
5단계: 규칙 매칭과 프록시 그룹 선택 확인
규칙 모드에서는 요청이 Clash에 들어온 뒤에도 DIRECT, REJECT 또는 잘못된 정책 그룹으로 배정될 수 있습니다. 대표적인 현상은 중국 본토 웹사이트는 정상인데 특정 해외 사이트만 실패하거나, 홈페이지는 열리지만 이미지·로그인 API·인증 코드가 로드되지 않는 경우입니다. 웹페이지는 여러 도메인에 의존하므로 주소 표시줄의 도메인만 봐서는 전체 규칙 적용 여부를 확인할 수 없습니다.
연결 기록으로 실제 출구 확인
클라이언트의 「연결」 또는 Connections 페이지를 열고 대상 웹페이지를 새로 고친 다음, 도메인에 적용된 규칙과 규칙 페이로드, 프록시 경로를 확인하세요. mihomo 코어는 보통 매칭된 규칙 유형과 최종 경로를 다음과 같이 기록합니다:
example.com
Rule: DomainSuffix
Payload: example.com
Chains: Proxy Group → Singapore 01대상 요청이 MATCH → DIRECT에 매칭됐다면 앞선 규칙이 해당 도메인을 포함하지 않는다는 뜻입니다. 프록시 그룹에 매칭됐지만 현재 그룹에서 실패한 노드를 선택하고 있다면 프록시 그룹으로 들어가 노드를 다시 선택하세요. REJECT에 매칭됐다면 광고 차단 또는 개인정보 보호 규칙에 해당하는지 먼저 확인하고 규칙 그룹 전체를 바로 삭제하지 마세요.
전역 모드로 임시 전환했을 때 정상으로 돌아온다면 원인은 대체로 규칙이나 정책 그룹으로 좁혀집니다. 수정할 때는 전역 모드를 계속 유지하기보다 정확한 DOMAIN, DOMAIN-SUFFIX 또는 적절한 규칙 세트를 추가하세요. 예시는 다음과 같습니다:
rules:
- DOMAIN,api.example.com,PROXY
- DOMAIN-SUFFIX,example.com,PROXY
- MATCH,DIRECT규칙은 위에서 아래 순서로 매칭되며 첫 번째로 일치한 뒤에는 보통 더 진행하지 않습니다. 범위가 넓은 DOMAIN-SUFFIX 또는 GEOIP 규칙을 잘못 배치하면 뒤의 세부 규칙보다 먼저 요청을 가로챌 수 있습니다. 수정 후에는 Profile을 다시 불러오고 연결 기록에서 새 규칙이 실제로 적용됐는지 확인하세요.
6단계: DNS 오염, Fake-IP와 IPv6 문제 확인
IP 주소에는 접근할 수 있지만 도메인이 열리지 않거나 브라우저가 ‘호스트 확인 중’ 상태에 오래 머문다면 DNS를 확인해야 합니다. Clash Meta, 즉 mihomo는 보통 fake-ip 또는 redir-host 두 가지 향상 모드를 사용합니다. Fake-IP는 예약 주소 대역에서 매핑 주소를 반환한 뒤 코어가 도메인을 복원합니다. 애플리케이션 트래픽이 Clash를 거치지 않는데 Clash의 Fake-IP 결과를 사용하면 요청이 실제 대상에 도달하지 못할 수 있습니다.
시스템 DNS와 프록시 DNS 비교
nslookup example.com
dig example.com
curl -v -x http://127.0.0.1:7890 https://example.comnslookup 결과가 198.18.0.0/16 대역의 주소라면 일반적으로 Fake-IP 매핑이며 실제 공인 IP를 의미하지 않습니다. 이때 시스템 프록시 또는 TUN이 여전히 작동하는지 확인하세요. Clash를 끄기 전에는 시스템 프록시를 먼저 끄고 클라이언트가 관리하는 DNS 설정을 정리해야 합니다. 그렇지 않으면 시스템이 이미 수신을 중지한 로컬 DNS 포트로 계속 질의할 수 있습니다.
mihomo 설정에서는 별도의 기본 리졸버를 사용해 업스트림 DNS 도메인을 처리하고, 암호화 DNS를 통해 기존 UDP 질의가 간섭받을 가능성을 낮출 수 있습니다. 예시 필드는 다음과 같으며, 실제 서버는 사용 중인 네트워크에서 테스트해 선택하세요:
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
default-nameserver:
- 223.5.5.5
- 1.1.1.1
nameserver:
- https://dns.alidns.com/dns-query
- https://1.1.1.1/dns-query문제가 IPv6를 지원하는 일부 웹사이트에서만 발생한다면 설정의 IPv6 기능을 잠시 끄고 비교 테스트를 진행하세요. 기기에 IPv6 주소가 할당됐지만 네트워크 출구가 불안정하면 애플리케이션이 사용 불가능한 AAAA 결과를 먼저 시도하고 시간 초과 후 IPv4로 전환할 수 있습니다. 원인을 확인한 뒤에는 모든 시간 초과를 DNS 오염으로 돌리기보다 라우터나 상위 IPv6 경로를 수정해야 합니다.
7단계: TUN 모드를 켜도 인터넷이 되지 않을 때
TUN 모드는 가상 네트워크 인터페이스를 만들어 시스템 프록시를 따르지 않는 애플리케이션과 일부 UDP 트래픽까지 처리합니다. 이를 위해 시스템 서비스, 관리자 권한, 라우팅 테이블과 DNS 하이재킹이 함께 작동해야 합니다. 화면의 스위치가 켜져 있어도 가상 인터페이스와 라우팅이 정상적으로 생성됐다는 뜻은 아닙니다.
TUN 고유의 문제인지 먼저 확인
- TUN을 끄고 시스템 프록시만 켭니다.
- 브라우저로 테스트 페이지에 접속하고 연결 기록을 확인합니다.
- 시스템 프록시에서는 인터넷이 되지만 TUN을 켜면 전체 네트워크가 끊긴다면 서비스 설치, 가상 네트워크 어댑터, 라우팅 충돌과 방화벽을 중점적으로 확인하세요.
- 두 모드 모두 실패한다면 포트, 노드와 DNS 단계로 돌아가세요. TUN 서비스를 반복해서 재설치하지 마세요.
Clash Verge Rev와 같은 클라이언트에서는 「설정」→「서비스 모드」 또는 「설정」→「시스템 설정」에서 서비스 상태를 확인할 수 있습니다. 클라이언트 업그레이드 후 서비스 버전과 화면 프로그램의 버전이 일치하지 않는다면 먼저 서비스를 중지한 다음 클라이언트가 제공하는 서비스 관리 메뉴에서 다시 설치하세요. Windows에서는 「장치 관리자」→「네트워크 어댑터」에서 가상 어댑터 상태를 확인하고, 다른 VPN·가상 머신 네트워크·보안 소프트웨어가 동시에 라우팅을 변경하고 있지 않은지도 점검해야 합니다.
macOS에서는 route -n get default로 기본 경로를 확인하고 ifconfig로 가상 인터페이스가 존재하는지 확인할 수 있습니다. Windows에서는 route print와 Get-NetAdapter를 실행합니다. 클라이언트를 종료한 뒤에도 가상 경로가 남아 있다면 관련 서비스를 재시작하거나 운영체제를 재부팅한 후 다시 테스트하세요. 대상 네트워크를 정확히 모르는 상태에서 라우팅을 일괄 삭제하지 마세요.
마지막 단계: 로그 결과로 분류하고 바로 재설치하지 않기
클라이언트를 재설치해도 프로그램 파일만 교체될 뿐, 사용할 수 없는 노드·잘못된 구독 규칙·시스템에 남은 프록시·상위 DNS 문제까지 자동으로 해결되지는 않습니다. 앞선 단계별 테스트를 마치면 장애 범위를 명확히 좁힐 수 있습니다. 다음 결과와 대응 방향으로 최종 확인을 진행하세요.
| 관찰 결과 | 주요 원인 범위 | 다음 조치 |
|---|---|---|
| Clash를 종료해도 직접 연결이 되지 않음 | 로컬 네트워크 또는 시스템 네트워크 설정 | 게이트웨이, 인증 포털, 시스템 DNS와 라우터 확인 |
| 127.0.0.1:7890 접속이 거부됨 | 코어 또는 수신 포트 | 포트, 코어 로그와 포트를 사용 중인 프로세스 확인 |
| 프록시 요청이 로그에 들어온 뒤 시간 초과됨 | 노드 또는 상위 네트워크 경로 | 프로토콜, 지역 또는 회선이 다른 노드로 변경 |
| 전역 모드는 정상인데 규칙 모드가 실패함 | 규칙과 정책 그룹 | Connections에서 매칭 규칙과 최종 경로 확인 |
| IP에는 접근되지만 도메인 조회가 실패함 | DNS | 로컬 DNS 수신 상태, Fake-IP와 상위 리졸버 확인 |
| 시스템 프록시는 정상인데 TUN 모드에서 네트워크가 끊김 | 서비스, 가상 인터페이스 또는 라우팅 | 서비스 권한, 어댑터 상태와 라우팅 충돌 확인 |
가장 효율적인 점검 순서는 직접 연결 확인, 로컬 프록시 포트 검증, 노드·규칙·DNS 확인, 마지막으로 TUN 점검입니다. 각 단계에서 터미널 결과와 클라이언트 연결 로그를 함께 확인하세요. 요청이 어느 계층에서 사라지는지만 알아도 목적 없이 노드를 바꾸거나 설정을 초기화하고 클라이언트를 반복 설치하는 일을 피할 수 있습니다.