Clash 로그 확인 방법: 오류 메시지 해석과 문제 해결
로그 레벨과 로그 항목의 구조를 설명하고, dial tcp 시간 초과, DNS 조회 실패, 규칙 미일치 등 자주 발생하는 오류의 의미와 로그에서 설정을 추적하는 방법을 안내합니다.
실패가 어느 단계에서 발생했는지 먼저 확인한 뒤 설정을 바꾸세요. 빨간 로그가 보인다고 노드를 바꾸면 오히려 원인을 찾기 어려워질 수 있습니다. 로컬 포트가 열리지 않았거나, 도메인이 해석되지 않았거나, 규칙이 잘못된 출구를 선택했거나, 원격 핸드셰이크가 실패했을 수 있습니다. 모두 겉으로는 ‘웹페이지가 열리지 않음’으로 보이지만 해결 방법은 서로 다릅니다.
이 글은 Clash와 Clash Meta(현재 이름: mihomo) 코어를 대상으로 합니다. 클라이언트마다 로그 표시 방식이 다르고 같은 오류도 접두어가 달라질 수 있습니다. 아래 로그는 구조를 보여 주기 위한 예시이며 특정 기기에서 측정한 결과가 아닙니다. 문제를 해결할 때는 실제 발생 시각, 대상 주소, 사용된 출구를 기준으로 확인하세요.
1. 먼저 실패 기록을 빠짐없이 확보하기
클라이언트에서 ‘로그’ 또는 ‘Logs’ 페이지를 열고 검색어를 지우세요. 레벨 필터와 코어 로그 레벨 설정이 모두 있다면 둘을 구분해야 합니다. 필터는 이미 기록된 로그를 숨길 뿐, 코어가 출력하지 않은 디버그 정보를 나중에 복구하지는 못합니다. 평소에는 info를 사용하고, 문제가 재현되기 어려울 때만 잠시 debug로 바꾸세요.
- 클라이언트 이름과 버전, 코어 이름과 버전을 기록하세요. 클라이언트 버전과 코어 버전은 서로 다릅니다.
- 현재 설정 이름, 실행 모드, 시스템 프록시와 TUN의 활성화 상태를 확인하고 기기의 현재 시각도 기록하세요.
- 기존 로그는 보존하세요. 화면 표시를 지우거나 시작 위치를 메모한 다음 문제가 발생하는 웹사이트에 한 번만 접속하세요.
- 실패한 행과 앞뒤 약 10개 행을 복사하세요. 연결이 여러 개라면 대상 도메인, 포트, 원본 포트로 구분하고, 로그에서 서로 가까이 있다는 이유만으로 관련 있다고 판단하지 마세요.
2. 로그 레벨과 연결 정보 읽는 법
| 레벨 | 주요 기록 내용 | 문제 해결 시 활용 |
|---|---|---|
debug | DNS 조회와 연결 등 세부 처리 과정 | 문제를 짧게 재현한 뒤 원래 설정으로 복구 |
info | 시작 상태, 규칙 일치, 출구 선택 | 요청이 코어에 들어왔는지, 어떤 정책을 거쳤는지 확인 |
warning | 연결 실패 또는 복구 가능한 오류 | 대상 주소를 기준으로 현재 이용 중인 서비스에 영향이 있는지 확인 |
error | 심각한 실행 또는 로드 문제 | 설정 로드, 포트 리스닝, 리소스 초기화부터 확인 |
silent | 일반 로그 출력 억제 | 문제 재현 단계에는 적합하지 않음 |
이 이름들은 코어에서 흔히 사용하는 로그 레벨입니다. 클라이언트에 따라 warning이 WARN이나 한국어 레이블로 표시될 수 있습니다. 레벨은 기록의 중요도를 나타낼 뿐, 문제가 반드시 로컬에서 발생했다는 뜻은 아닙니다. 웹사이트의 백엔드 요청 시간 초과도 경고로 기록될 수 있습니다.
time="2026-09-11T10:20:30+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> example.com:443 match DomainSuffix(example.com) using PROXY[노드 A]"time: 기록된 시각입니다. 시스템 시간대와 비교해 이전 오류를 현재 요청의 오류로 착각하지 않도록 하세요.[TCP]: 연결에 사용된 전송 프로토콜입니다. UDP 요청에는 해당 프로토콜을 나타내는 표시가 붙습니다.127.0.0.1:53124: 이번 연결의 출발지입니다. 코어의 프록시 리스닝 포트가 아닙니다.example.com:443: 요청 대상입니다. 443은 보통 HTTPS에 사용되지만, 포트 번호만으로 애플리케이션 프로토콜을 단정할 수는 없습니다.match: 설정에서 의도한 규칙이 아니라 실제로 일치한 규칙입니다.using: 정책 그룹과 선택된 출구입니다. 그룹 이름이 PROXY여도 그룹에서 현재 선택한 항목이 반드시 프록시 노드인 것은 아닙니다.
이 로그는 코어가 연결에 규칙을 적용하고 출구를 선택했다는 뜻이지, 웹페이지 다운로드가 성공했다는 뜻은 아닙니다. 이후 연결, TLS 핸드셰이크, 애플리케이션 응답 단계에서 실패할 수 있습니다. 같은 접속에서 생성된 실패 기록도 함께 살펴보세요.
3. dial tcp 시간 초과: 어디에 연결하려는지 먼저 확인
dial tcp 203.0.113.10:443: i/o timeout
dial tcp 127.0.0.1:7890: connect: connection refused첫 번째 줄은 제한 시간 안에 TCP 연결을 맺지 못했다는 뜻입니다. 예시의 203.0.113.10은 문서용 예시 주소이므로 테스트에 사용하면 안 됩니다. 실제 로그에서 이 위치에는 웹사이트 IP나 프록시 서버 IP가 표시될 수 있으니 오류 접두어와 출구를 함께 확인해야 합니다. 프록시를 사용하는 경우 ‘연결 실패’가 항상 웹사이트 서버의 문제인 것은 아닙니다.
주소 유형별 확인 항목
- 주소가 프록시 서버인 경우: 같은 테스트 URL을 유지하고 노드 하나만 바꿔 보세요. 특정 노드에서만 계속 시간 초과가 발생하면 해당 노드의 주소와 포트, 서비스 상태부터 확인하세요. 먼저 전체 DNS 설정을 바꾸지는 마세요.
- 주소가 대상 웹사이트인 경우: 실제로 DIRECT 연결을 사용했는지 확인하세요. 중국 본토와 해외 규칙이 뒤바뀌면 프록시로 접속해야 하는 대상이 직접 연결될 수 있습니다.
- 주소가 로컬 루프백 주소인 경우: 로컬 프록시가 해당 포트에서 리스닝 중인지 확인하세요. 7890은 흔히 사용하는 설정값일 뿐이며 실제 값은 현재 설정과 클라이언트 화면을 기준으로 확인해야 합니다.
connection refused는 대개 연결이 명시적으로 거부됐다는 뜻입니다. 해당 포트에서 리스닝 중인 프로세스가 없거나 방화벽이 연결을 거부할 때 흔히 발생합니다. i/o timeout은 응답을 기다리다 제한 시간을 넘겼다는 뜻입니다. 두 오류를 같은 의미로 취급하지 말고, 한 번 시간 초과가 발생했다고 노드가 영구적으로 사용할 수 없다고 단정하지 마세요.
프록시를 명시한 요청으로 원인 범위 좁히기
혼합 프록시 포트가 실제로 7890인지 확인한 뒤 다음 명령을 실행하세요. Windows에서는 이전 PowerShell의 curl 별칭 문제를 피하려면 curl.exe를 사용하는 것이 좋습니다.
curl --noproxy "" -v --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/여기서 10초는 연결 단계의 제한 시간이고, 20초는 요청 전체의 제한 시간입니다. 네트워크 속도를 측정하는 값이 아닙니다. 명령에 로컬 프록시를 명시하면 브라우저의 결과와 비교하기 쉽습니다. 명령은 성공하지만 브라우저에서 실패한다면 브라우저 프록시 확장 프로그램, 시스템 프록시, 앱 자체의 네트워크 설정을 확인하세요. 로그에 해당 연결이 전혀 없다면 명령에 지정한 포트와 로그 필터부터 확인하세요.
4. DNS 조회 실패: 세 가지 도메인을 구분하기
DNS 오류가 발생하면 무엇을 조회하다 실패했는지 먼저 확인하세요. 대상 웹사이트의 도메인인지, 프록시 서버의 도메인인지, DNS 업스트림 자체의 도메인인지에 따라 실패 단계가 다릅니다. 프록시 서버 도메인을 해석하지 못했다면 연결 출구가 아직 준비되지 않은 상태이므로 웹사이트를 바꿔도 소용이 없습니다.
lookup example.com: no such host
lookup example.com: i/o timeoutno such host는 보통 도메인이 존재하지 않거나 리졸버가 도메인이 없다는 응답을 반환했을 때 발생합니다. i/o timeout은 조회에 대한 응답이 제때 도착하지 않은 경우에 가깝습니다. 실제 원인을 파악하려면 오류에 표시된 DNS 서버와 주변 로그도 확인해야 합니다. all DNS requests failed는 이번 조회에서 시도한 업스트림이 모두 실패했다는 뜻이며, 이것만으로 ‘모든 노드가 고장 났다’고 결론 내릴 수는 없습니다.
- 도메인 철자를 먼저 확인한 다음 현재 설정의
dns.enable,nameserver등의 필드를 살펴보세요. - DNS 업스트림에 연결할 수 있는지 확인하세요. 암호화 DNS를 사용한다면 업스트림 주소 조회, 연결, 인증서 검증도 필요합니다. UDP 53 포트만 확인해서는 충분하지 않습니다.
- mihomo 설정에서
proxy-server-nameserver를 사용한다면 프록시 노드 도메인 조회가 정상적으로 이뤄지는지도 확인하세요. 아직 준비되지 않은 프록시 출구에 의존하지 않도록 해야 합니다. - 업스트림 하나만 바꿔 같은 도메인을 조회하고 변경 전후 결과를 기록하세요. DNS, 노드, 규칙을 한꺼번에 바꾸지 마세요.
fake-ip 모드에서 198.18.0.0/16 범위의 합성 주소가 보이더라도 바로 DNS 변조로 단정하지 마세요. fake-ip 매핑, 트래픽이 코어로 돌아오는지, 도메인 정보가 규칙 매칭에 사용될 수 있는지를 이어서 확인해야 합니다.
5. 규칙 미일치: 실제 출구에서 규칙 적용 순서 역추적하기
‘규칙 미일치’는 명확한 오류 메시지라기보다 연결 로그에 예상과 다른 규칙이 표시되는 상황을 뜻하는 경우가 많습니다. 먼저 현재 모드가 Rule／규칙 모드인지 확인하세요. Global／전역 모드와 Direct／직접 연결 모드에서는 분기 규칙을 같은 방식으로 사용하지 않으므로 규칙 파일을 수정해도 기대한 변화가 나타나지 않을 수 있습니다.
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY이 부분은 규칙 적용 순서를 보여 주는 예시이며, 설정에 PROXY라는 정책 그룹이 정의돼 있다고 가정합니다. 규칙은 일반적으로 위에서 아래로 검사하며 처음 일치한 규칙의 정책을 사용합니다. MATCH는 나머지 연결을 처리하도록 마지막에 둬야 합니다. MATCH를 도메인 규칙보다 위에 두면 뒤에 있는 규칙은 연결을 처리할 수 없습니다.
MATCH 규칙에 일치해도 반드시 오류는 아닙니다
더 구체적인 규칙이 일치하지 않을 때 기본 규칙이 적용되는 것은 정상입니다. 특정 도메인이 전용 규칙에 일치해야 한다면 실제로 로드된 설정, 규칙 철자, 원격 규칙 세트의 로드 상태, 로그에 도메인 정보가 남아 있는지 확인하세요. 대상 IP만 확인되는 경우 도메인 규칙이 예상대로 적용되지 않을 수 있습니다. 스니핑으로 모든 연결의 도메인을 안정적으로 복원할 수 있는 것도 아닙니다.
DOMAIN은 정확히 일치하는 도메인에 사용하고,DOMAIN-SUFFIX는 도메인과 하위 도메인에 사용합니다. 전체 URL이나 경로를 넣지 마세요.RULE-SET에는 해당하는rule-providers이름이 필요하며, 규칙 세트의 유형 및 콘텐츠 형식과도 호환돼야 합니다.GEOSITE등의 기능은 코어에서 지원하는지 확인하세요. mihomo 설정을 구버전 Clash 코어에서도 모두 지원한다고 가정하면 안 됩니다.- 구독으로 생성된 설정을 수정하기 전에 클라이언트의 덮어쓰기 방식을 확인하세요. 임시 파일을 직접 수정하면 다음 구독 업데이트 때 변경 사항이 사라질 수 있습니다.
마지막으로 정책 그룹을 열어 실제로 선택된 항목을 확인하세요. 로그에 PROXY가 표시되더라도 그룹에서 현재 DIRECT를 선택했다면 최종 연결은 직접 연결입니다. 규칙 이름, 정책 그룹 이름, 실제 출구를 각각 구분해서 확인해야 합니다.
6. 리스닝, TLS, TUN 관련 흔한 오해
| 로그 또는 증상 | 우선 확인할 항목 |
|---|---|
address already in use | 충돌이 발생한 정확한 리스닝 주소와 포트, 두 번째 코어가 실행 중인지 여부 |
certificate has expired or is not yet valid | 시스템 날짜와 시간대, 인증 대상 서비스 인증서의 유효 기간 |
TLS handshake timeout | TCP 연결 후의 핸드셰이크 과정, 노드 매개변수, 네트워크 중간 장비 |
permission denied | 오류와 관련된 파일, 리스닝 동작, 가상 네트워크 어댑터 권한 |
| TUN 활성화 후에도 해당 연결 로그가 없음 | TUN이 정상적으로 생성됐는지, 라우팅이 적용됐는지, 앱이 트래픽 가로채기를 우회하는지 |
포트 충돌이 발생하면 Windows에서는 netstat -ano | findstr :7890으로 해당 포트의 리스닝 정보와 PID를 확인할 수 있습니다. macOS나 Linux에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN을 사용하세요. 프로세스가 무엇인지 확인한 뒤 중복 실행된 인스턴스를 종료하고, 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. 포트를 변경했다면 시스템 프록시와 테스트 명령의 포트도 함께 바꾸세요.
인증서 오류가 발생해도 인증서 검증을 끄는 방식으로 해결하려 하지 마세요. 먼저 시스템 시간을 맞춘 다음 오류가 구독 다운로드, DNS 업스트림, 프록시 서버, 대상 웹사이트 중 어디에서 발생했는지 확인하세요. 각 단계의 인증서는 서로 대체할 수 없습니다. 잘못된 위치를 수정하면 효과가 없을 뿐 아니라 연결 검증이 약해질 수 있습니다.
TUN은 트래픽을 가로채는 방식일 뿐, 노드 연결 불가나 인증서 만료를 자동으로 해결하지 않습니다. 먼저 TUN을 끄고 HTTP 프록시를 명시한 명령으로 코어의 출구를 테스트할 수 있습니다. 명시적 프록시 연결은 성공하고 TUN에서만 실패한다면 서비스 권한, 가상 네트워크 어댑터, 라우팅, DNS 트래픽 처리에 집중해 확인하세요. 이렇게 비교하면 클라이언트를 재설치하고 모든 규칙을 바꾸는 것보다 원인을 파악하기 쉽습니다.
7. 로그에서 설정을 역추적하는 기본 절차
- 코어가 실행 중인지 확인하세요. 설정이 정상적으로 로드됐는지, 프록시 포트가 리스닝 중인지 확인하세요. 시작 오류를 해결하기 전에는 웹사이트 규칙을 살펴볼 필요가 없습니다.
- 요청이 코어에 들어오는지 확인하세요. URL 하나를 정해 한 번 접속한 다음 해당 대상의 로그가 나타나는지 확인하세요. 로그 필터 때문에 기록이 보이지 않는 경우도 살펴보세요.
- 모드와 일치한 규칙을 확인하세요. Rule, Global, Direct 중 어떤 모드인지와 로그에 표시된 규칙을 기록하세요.
- 실제 출구를 확인하세요. 정책 그룹을 펼쳐 최종 노드 또는 DIRECT까지 확인하고 그룹 이름만 보고 판단하지 마세요.
- 실패 단계를 확인하세요. 도메인 조회, TCP 연결, TLS 핸드셰이크, 애플리케이션 응답 중 어느 단계에서 실패했는지 구분한 뒤 관련 설정 항목을 찾으세요.
- 한 번에 한 곳만 바꾸세요. 원본 설정을 보존하고 다시 로드한 뒤 새 연결을 만들어 같은 요청의 결과를 비교하세요. 기존 연결은 이전 출구를 계속 사용할 수 있습니다.
- 다시 테스트하고 로그 레벨을 원래대로 돌리세요. 같은 요청을 연속으로 몇 차례 반복해 문제가 해결됐는지 확인한 다음 debug를 info로 되돌리세요. 지나치게 상세한 접속 기록이 계속 쌓이지 않도록 해야 합니다.
설정 항목을 확인하려면 설정 항목 설명을 참고하세요. 커뮤니티에 문제를 문의할 때는 코어 버전, 민감 정보를 가린 설정 일부, 재현 절차, 해당 시간대의 로그를 함께 첨부하세요. ‘프록시가 안 돼요’라고만 적는 것보다 포트, 규칙, DNS 업스트림 중 어디에서 문제가 생겼는지 더 빠르게 좁힐 수 있습니다.