웹페이지가 열리지 않을 때 포트, DNS, 프록시 노드를 계속 바꾸기 전에 로그부터 확인하세요. Clash 로그로는 세 가지를 확인할 수 있습니다. 요청이 코어에 들어왔는지, 어떤 규칙에 따라 어디로 전달됐는지, 연결이 어느 단계에서 실패했는지입니다. 이 순서대로 살펴보면 오류 문구 전체를 검색하는 것보다 원인을 좁히기 쉽습니다.
이 글은 Clash 계열 클라이언트와 Clash Meta(현 mihomo)의 일반적인 문제 해결 절차를 다룹니다. 코어와 버전, GUI에 따라 로그 형식은 다를 수 있습니다. 아래 로그는 개인정보를 제거한 설명용 예시이며, 도메인과 주소는 실제로 사용할 수 있는 서비스가 아닙니다. 영어 오류 키워드 하나만으로 노드에 문제가 있다고 단정하지 마세요.
1. 코어 로그를 열고 실패 기록 전체를 보관하세요
클라이언트에는 ‘앱 로그’, ‘코어 로그’, ‘연결’ 페이지가 각각 있을 수 있습니다. 앱 로그에는 화면 실행, 설정 다운로드, 서비스 관리 등이 기록되고, 코어 로그에는 규칙 매칭, DNS 조회, 프록시 연결 등이 기록됩니다. 연결 페이지에서는 현재 활성화된 연결과 프록시 체인을 확인할 수 있습니다. 각 페이지의 정보는 서로 보완하는 별개의 기록입니다.
최소한의 조작으로 한 번 재현하기
- 클라이언트의 ‘로그’ 또는 ‘코어 로그’ 페이지를 열고 현재 시각, 활성화된 설정 파일, 프록시 모드를 기록하세요. 메뉴 이름은 사용 중인 클라이언트에 따라 다를 수 있습니다.
- 코어 로그 레벨이
info인지 확인하세요. 필요한 정보가 부족하다면 일시적으로debug로 바꾸고 설정을 적용한 다음 문제를 다시 재현합니다. - 백그라운드에서 계속 인터넷에 연결하는 다른 앱을 닫고, 문제가 발생한 페이지 하나만 여세요. 클릭한 시각(예:
14:32:08)을 기록하고 이후 약 10초 동안 로그를 살펴봅니다. - 오류 행과 그 앞뒤 5~10행을 보관하세요. 진단을 마치면
info로 되돌려 디버그 로그가 장시간 쌓이지 않도록 합니다.
# 현재 설정의 최상위 항목에 병합하고, 같은 이름의 필드를 중복해서 추가하지 마세요
log-level: info구독 관리 기능으로 설정을 관리하는 경우 다운로드된 파일을 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다. 클라이언트에서 제공하는 덮어쓰기 또는 병합 기능을 우선 사용하세요. 파일을 직접 편집해야 한다면 먼저 백업한 뒤 다시 불러오기가 정상적으로 됐는지 확인합니다. 설정 파싱에 실패했다면 새 설정이 적용되지 않았을 수 있습니다.
2. 로그 레벨과 각 행의 필드 읽기
로그 레벨은 기록의 중요도를 나타내며 네트워크 품질 점수가 아닙니다. 백그라운드 앱의 재시도로 발생한 warning이 현재 웹페이지 오류와 관련이 없을 수도 있습니다. 반대로 info만 기록됐다고 해서 페이지가 정상적으로 로드됐다는 뜻은 아닙니다.
| 레벨 | 주요 기록 내용 | 진단에 활용하는 방법 |
|---|---|---|
debug | 상세한 DNS, 연결 및 내부 처리 정보 | 복잡한 오류를 짧게 재현할 때 사용합니다. 민감한 정보는 가리세요. |
info | 일반적인 실행 상태, 연결 및 규칙 기록 | 일상적인 문제 해결의 출발점 |
warning | 연결 실패, 조회 오류 등의 경고 | 시각과 대상 정보를 바탕으로 관련성을 판단하세요. |
error | 심각한 실행 또는 설정 문제 | 코어 실행이나 포트 수신에 영향을 주는지 먼저 확인하세요. |
silent | 로그 출력 억제 | 문제 원인을 파악할 단서를 수집하기에 적합하지 않습니다. |
로그 한 줄을 다섯 부분으로 나눠 읽기
time="2026-09-15T14:32:08+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> www.example.com:443 match DomainSuffix(example.com) using 웹 프록시[노드 A]"- 시각:
14:32:08+08:00은 방금 한 조작과 로그를 연결하는 데 사용합니다. 기기 간 시각을 비교할 때는 시간대도 확인하세요. - 프로토콜:
[TCP]는 해당 연결이 TCP를 사용한다는 뜻입니다. 이 기록만으로 UDP도 정상이라고 판단할 수는 없습니다. - 출발지:
127.0.0.1:53124는 로컬 출발지 주소와 임시 포트입니다.53124는 프록시 설정에 입력해야 하는 수신 포트가 아닙니다. - 대상:
www.example.com:443은 접속 대상과 대상 포트입니다. 오류 메시지에 표시된 최종 연결 대상 노드 주소와 다를 수 있습니다. - 매칭 규칙과 출구:
DomainSuffix(example.com)은 매칭된 규칙이고,웹 프록시[노드 A]는 정책 그룹과 선택된 노드를 나타냅니다.
이러한 정보 행은 코어가 연결을 어떻게 처리했는지 보여줄 뿐, TLS 핸드셰이크와 로그인, 페이지 리소스 로딩까지 완료됐다는 뜻은 아닙니다. 다음 행에 시간 초과나 핸드셰이크 오류가 이어진다면 계속 확인하세요. ‘프록시 규칙에 매칭됨’이라는 행에서 멈추면 안 됩니다.
3. dial tcp timeout: 어느 구간에서 시간이 초과됐는지 확인하기
level=warning msg="[TCP] dial 웹 프록시 (match DomainSuffix/example.com) 127.0.0.1:53124 --> www.example.com:443 error: dial tcp 203.0.113.20:443: i/o timeout"dial tcp는 TCP 연결을 시도한다는 뜻이고, i/o timeout은 어떤 단계에서 대기 시간이 제한을 초과했다는 뜻입니다. 로그에 connect: connection timed out으로 표시되거나 상위 오류인 context deadline exceeded로 나타날 수도 있습니다. 대기 중 연결이 실패했다는 점은 알 수 있지만, 원인이 DNS인지 원격 서비스인지 로컬 방화벽인지는 이 문구만으로 판단할 수 없습니다.
마지막에 표시된 IP와 포트를 확인하세요
예시에서 대상은 www.example.com:443이지만 실제 연결 시도 주소는 203.0.113.20:443입니다. 이 주소가 노드의 server와 port에 해당한다면 컴퓨터에서 노드까지의 구간을 먼저 확인하세요. 현재 DIRECT로 연결 중이라면 대상 사이트까지의 직접 연결 경로를 살펴봐야 합니다. 프록시를 연쇄로 사용하는 경우 실제 프록시 체인을 기준으로 중간 홉도 확인해야 합니다.
- 노드 설정 확인:구독이 만료되지 않았는지, 노드 도메인과 포트 및 프로토콜이 서버 설정과 일치하는지 살펴보세요. 웹사이트의
443을 노드 포트로 착각하지 마세요. - 한 번에 변수 하나만 변경:규칙과 DNS는 그대로 두고 정상 작동이 확인된 다른 노드로 바꾼 다음 같은 대상에 접속해 보세요.
- 네트워크 비교:가능하다면 휴대전화 핫스팟으로 전환해 보세요. 특정 Wi-Fi에서만 같은 노드의 연결 시간이 초과된다면 해당 네트워크의 외부 연결 제한을 우선 확인하세요.
- 로컬 네트워크 경로 확인:방화벽, 다른 VPN, 가상 네트워크 어댑터, TUN 라우팅 간의 충돌을 살펴보세요. 처음부터 모든 보안 기능을 끄지는 마세요.
Windows에서는 PowerShell의 Test-NetConnection으로 TCP 연결 가능 여부를 확인할 수 있습니다. 아래 주소는 문서용 예시이므로 실제 테스트에는 노드 설정의 호스트와 포트를 사용하세요. 예시 주소 자체를 테스트하지 마세요.
Test-NetConnection -ComputerName 203.0.113.20 -Port 443TcpTestSucceeded가 참이면 해당 테스트에서 TCP 연결이 성공했다는 뜻일 뿐입니다. 프록시 프로토콜이나 인증 정보, UDP 전달 여부까지 확인해 주지는 않습니다. 노드 지연 시간 테스트도 마찬가지입니다. 테스트용 사이트에 연결된다고 해서 모든 서비스 도메인에 접속할 수 있는 것은 아닙니다.
4. connection refused: 거부된 포트가 로컬인지 원격인지 확인하기
dial tcp 127.0.0.1:7890: connect: connection refusedconnection refused는 대개 연결 요청이 명확히 거부됐다는 뜻입니다. 해당 포트에서 서비스가 대기 중이지 않거나 방화벽이 연결을 적극적으로 차단했을 수 있습니다. 응답이 늦게 오지 않는 시간 초과와 달리, 거부는 보통 더 빠르게 반환됩니다.
주소가 127.0.0.1이라면 프록시 수신 상태를 확인하세요
브라우저나 명령줄 또는 다른 앱에서 오류가 발생했고 주소가 127.0.0.1:7890이라면 코어가 실행 중인지, 실제 수신 포트가 7890인지 먼저 확인하세요. 클라이언트 포트가 7897로 바뀌었는데 시스템 프록시에는 이전 포트가 남아 있을 수 있습니다. 출발지의 임시 포트로 여기에 표시된 포트를 바꾸지 마세요.
# 현재 설정에 사용할 수 있는 관련 필드 예시입니다. 포트는 앱 설정과 일치해야 합니다.
mixed-port: 7890
allow-lan: falsemixed-port는 HTTP와 SOCKS5 프록시 연결을 모두 받습니다. 앱에 프록시를 설정할 때는 포트가 혼합형이어도 올바른 프로토콜을 선택해야 합니다. Windows에서는 수신 상태를 확인하고, macOS와 Linux에서는 해당 플랫폼의 포트 확인 명령을 사용할 수 있습니다.
# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen
# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN
# Linux
ss -lntp 'sport = :7890'주소가 원격 노드라면 서버 수신 상태와 구독을 확인하세요
거부된 주소가 노드 IP와 포트라면 서버에서 해당 포트를 계속 열어 두고 있는지, 포트가 바뀌었는지, 구독이 최신인지 확인하세요. 로컬의 mixed-port를 계속 수정해도 원격 포트 거부는 해결되지 않습니다. 시작 로그에 address already in use가 표시된다면 로컬 포트를 다른 프로세스가 사용 중인 것입니다. 먼저 포트를 점유한 프로세스를 찾은 뒤 해당 서비스를 중지할지 포트를 변경할지 결정하세요.
5. DNS 조회 실패: 대상 도메인과 노드 도메인 구분하기
lookup www.example.com: no such host
dns resolve failed: all DNS requests failed
read udp 192.168.1.8:53012->192.168.1.1:53: i/o timeoutno such host는 시스템 리졸버가 이름을 찾지 못했을 때 자주 표시되지만, 도메인 철자와 DNS 업스트림, 반환된 결과를 함께 확인해야 합니다. all DNS requests failed는 여러 오류를 요약한 메시지이므로 앞서 발생한 구체적인 실패 원인을 더 찾아보세요. UDP 53 포트 시간 초과는 해당 DNS 서버로 보낸 조회 요청이 제때 응답을 받지 못했다는 뜻입니다.
세 단계로 DNS 조회 경로 확인하기
- 어떤 도메인의 조회가 실패했나요:웹사이트 도메인이라면 해당 사이트 접속에 영향을 줍니다. 노드의
server도메인이라면 프록시 터널 자체가 만들어지지 않을 수 있습니다. 두 경우의 해결 순서는 다릅니다. - 어디에서 조회하나요:코어의
dns기능이 활성화되어 있는지, 앱이 자체 보안 DNS를 사용하는지, 시스템 DNS 요청이 TUN에서 처리되는지 확인하세요. - 업스트림에 연결할 수 있나요:일반 DNS, DoH, DoT는 네트워크 경로가 서로 다릅니다. DoH가 HTTPS를 사용하더라도 현재 네트워크에서 반드시 연결되는 것은 아닙니다.
시스템 명령 nslookup www.example.com은 일반적으로 시스템에서 지정한 DNS 서버에 질의합니다. 명령이 성공해도 해당 조회 경로가 작동한다는 뜻일 뿐, Clash 코어 DNS나 브라우저 자체 DoH도 정상이라는 증거는 아닙니다. 비교 테스트에서는 IP 반환 여부뿐 아니라 어떤 서버로 조회했는지도 기록하세요.
Fake-IP 모드에서 앱이 198.18.0.0/16 범위의 매핑 주소를 받는 것은 정상일 수 있습니다. 정확한 범위는 fake-ip-range 설정에 따라 달라집니다. 주소가 공인 IP처럼 보이지 않는다는 이유만으로 조회 오류라고 단정하거나, 매핑 주소만으로 공용 인터넷 연결 여부를 판단하지 마세요.
DNS를 변경한 뒤에도 앱과 시스템, 코어에 각각 캐시가 남아 있을 수 있습니다. 클라이언트에서 지원하는 방법으로 관련 캐시를 지우고 기존 연결을 종료한 뒤 다시 테스트하세요. 기존 캐시의 조회 결과만으로 새 설정이 적용됐다고 판단하지 마세요.
6. 규칙 매칭 결과로 역추적하기: 요청이 잘못된 경로로 나가는 이유
규칙 모드에서는 보통 rules를 위에서 아래로 확인해 매칭된 정책을 적용합니다. 글로벌 모드라면 글로벌 정책 선택을 확인하고, 직접 연결 모드라면 일반 프록시 규칙이 규칙 모드처럼 요청을 처리할 것이라고 기대하지 마세요. 진단에 앞서 현재 모드를 확인해 적용되지 않는 설정을 반복해서 수정하지 않도록 합니다.
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,웹 프록시
- GEOIP,LAN,DIRECT
- MATCH,웹 프록시이 예시를 사용하려면 기존 proxy-groups에 ‘웹 프록시’라는 정책 그룹이 있어야 하며, 코어가 해당 규칙을 지원해야 합니다. 이는 규칙 일부일 뿐 완성된 설정이 아닙니다. MATCH는 최종 대체 규칙이므로 우선 적용할 규칙 뒤에 배치해야 합니다.
규칙, 정책 그룹, 최종 노드 순서로 확인하세요
- 규칙이 매칭됐나요:
example.com에 접속하려 했는데MATCH가 표시된다면 실제 도메인과 하위 도메인, 규칙 순서, 설정을 다시 불러왔는지 확인하세요. - 매칭 결과가 적절한가요:
DIRECT가 표시된다면 노드 문제라고 단정하기 전에 더 위에 있는 직접 연결 규칙이 먼저 적용됐는지 살펴보세요. - 정책 그룹이 올바르게 선택됐나요:같은 그룹에서도
DIRECT나 다른 그룹, 특정 노드를 선택할 수 있습니다. 자동 지연 시간 테스트나 장애 조치 그룹은 출구가 동적으로 바뀔 수도 있습니다. - 일부 리소스만 실패하나요:메인 페이지와 이미지, 로그인 API가 서로 다른 도메인을 사용할 수 있습니다. 주소창의 도메인만 확인하면 실제 오류가 난 리소스를 놓칠 수 있습니다.
예를 들어 메인 페이지는 ‘웹 프록시’를 사용하지만 로그인 API는 직접 연결 규칙에 매칭되면 페이지는 열려도 로그인이 계속 진행 중인 것처럼 보일 수 있습니다. 로그인 시각에 맞춰 해당 요청의 대상 도메인을 찾고, 필요하다면 브라우저 개발자 도구의 ‘네트워크’ 탭에서 실패한 요청을 확인한 뒤 로그를 살펴보세요.
글로벌 모드로 잠시 전환해 비교할 수는 있지만, 이것이 최종 해결책은 아닙니다. 글로벌 모드에서는 작동하고 규칙 모드에서만 실패한다면 규칙과 DNS 경로를 계속 확인하세요. 설정을 변경한 뒤 기존 연결을 종료하고 다시 시도해야 합니다. 이미 열린 연결은 이전 출구를 계속 사용할 수 있어 규칙을 바꿔도 자동으로 다시 연결되지 않습니다.
7. TLS, UDP 및 설정 오류 추가 점검
| 로그 키워드 | 우선 확인할 항목 | 피해야 할 성급한 판단 |
|---|---|---|
x509: certificate | 시스템 시간, 인증서 유효 기간, 노드 서버 이름 및 TLS 설정 | 인증서 검증 비활성화를 일반적인 해결 방법으로 사용하지 마세요. |
TLS handshake timeout | TCP 연결 이후의 경로, 서버 응답 및 TLS 매개변수 | 도메인 조회가 반드시 실패했다는 뜻은 아닙니다. |
EOF / connection reset by peer | 어느 쪽에서 먼저 연결을 종료했는지, 프로토콜 매개변수와 서버 로그를 확인하세요. | 한 줄의 로그만으로 인증 정보 문제인지 네트워크 간섭인지 판단할 수 없습니다. |
[UDP] 관련 시간 초과 | 노드의 UDP 지원 여부, TUN 라우팅, 외부 네트워크 제한 | TCP 속도 테스트가 통과해도 UDP가 정상이라는 뜻은 아닙니다. |
yaml: unmarshal errors | 오류 행 주변의 들여쓰기, 필드 형식, 중복 키 및 코어 호환성 | 설정을 불러오지 못했다면 노드를 바꿔도 대개 해결되지 않습니다. |
설정의 udp: true를 사용해도 UDP를 지원하지 않는 서버에 해당 기능이 생기지는 않습니다. 게임이나 음성 통화에 문제가 있다면 클라이언트 진입 경로부터 노드 프로토콜과 서버, 외부 네트워크까지 전체 경로를 확인하세요. 브라우저가 QUIC을 사용하는 경우에도 UDP 관련 로그가 나타날 수 있으므로 TCP 연결 성공만으로 모든 현상을 설명할 수는 없습니다.
노드 핸드셰이크에서 인증서 오류가 발생했다면 노드의 서버 이름과 프로토콜 매개변수를 확인하세요. 구독 업데이트 중에 발생했다면 구독 사이트와 시스템 신뢰 체인을 살펴봐야 합니다. 두 오류 모두 x509가 포함될 수 있지만 연결 단계는 서로 다릅니다.
8. 문제 해결 정보 제출하기: 앞뒤 맥락을 남기고 민감한 내용은 가리기
유용한 문제 해결 기록은 길 필요가 없지만, 조작과 연결을 서로 연결해 볼 수 있어야 합니다. ‘시간 초과가 발생했습니다’라고만 쓰기보다는 다음 정보를 제공하면 원인을 더 정확히 파악할 수 있습니다.
- 환경:운영체제와 클라이언트 버전, 코어 이름과 전체 버전 번호를 적으세요. ‘정보’ 화면이나 시작 로그에서 복사하고 ‘최신 버전’이라고만 쓰지 마세요.
- 진입 경로:시스템 프록시 또는 TUN 사용 여부, 현재 모드, 로컬 수신 포트, 문제가 한 앱에서만 발생하는지 모든 앱에서 발생하는지 적으세요.
- 재현 정보:조작 시각과 실패한 기능, 당시 선택된 정책 그룹 및 노드를 기록하고, 직전에 구독이나 설정을 업데이트했는지도 알려 주세요.
- 증거:관련 로그의 앞뒤 내용, 규칙 매칭 기록, 노드나 네트워크를 바꾼 뒤 비교한 결과를 제공하세요.
최종 재테스트도 같은 순서로 진행하세요. 요청이 코어에 들어오는지 확인하고, 규칙과 출구가 예상대로인지 살펴본 다음 DNS 조회와 연결, 앱 수준 요청이 완료되는지 확인합니다. 한 번에 한 항목만 바꾸고 결과를 기록하세요. 그래야 실제로 해결된 것인지 우연히 복구된 것인지 구분하고, 구독 업데이트 후에도 정상 작동하는 설정을 더 빨리 찾을 수 있습니다.