Clash 실행 로그 읽는 법: info/warning/error 레벨과 주요 에러 메시지 정리

로그 레벨이란 무엇이고, 먼저 어떻게 설정해야 할까

Clash 코어(원조 Clash든 Mihomo, 즉 Clash Meta든 상관없이)는 동일한 로그 레벨 체계를 사용합니다. 자세한 순서대로 debug, info, warning, error, silent가 있죠. 설정 파일에서는 log-level 항목이 이를 담당하며, 대부분의 클라이언트도 설정 화면에서 동일한 이름의 스위치를 제공합니다. 평소에는 info로 두고 연결이 정상적으로 이루어지는지 지켜보다가, 실제 문제가 생겼을 때만 잠시 debug로 바꿔 상세한 핸드셰이크 과정을 확인하는 것을 추천합니다. 문제를 해결한 뒤에는 다시 원래대로 되돌려두세요. debug 레벨은 로그량이 매우 많아서 계속 켜두면 디스크 용량을 잡아먹고 로그를 읽기도 힘들어집니다.

log-level: info
# 문제를 진단할 때만 잠시 이렇게 변경
log-level: debug

네 가지 레벨의 의미는 임의로 나눈 게 아니라 각자 역할이 분명합니다. 이걸 정확히 알아두면 어떤 로그가 신경 써야 할 대상인지 빠르게 판단할 수 있습니다:

debug: 가장 세밀한 단계로, DNS 해석 과정, 핸드셰이크 절차, 연결 풀 상태 등을 모두 담고 있어 정상 동작 중에도 로그가 매우 많이 쌓입니다.
info: 각 연결이 어떤 규칙에 매칭됐는지, 어떤 노드를 사용했는지, 목적지 주소가 무엇인지를 기록합니다. 평소 상태를 지켜보기에 가장 적합한 레벨입니다.
warning: 이상이 발생했지만 코어가 스스로 대응을 시도하고 있는 상태를 뜻합니다. 예를 들어 특정 노드의 상태 확인(health check)이 실패했지만 다른 노드가 여전히 사용 가능한 경우입니다.
error: 명확한 실패 결과로, 연결이 성립되지 않았다는 뜻입니다. 대부분 직접 개입해서 해결해야 합니다.

클라이언트 GUI의 로그 패널은 보통 레벨별로 색을 구분해서 보여줍니다. warning은 노란색, error는 빨간색으로 표시되는 경우가 많은데, 이는 디자인 시스템에서 상태 색상을 활용하는 방식과 같은 맥락입니다. 다만 색은 우선순위를 알려주는 표시일 뿐이고, 실제 원인은 텍스트 내용을 봐야 정확히 알 수 있습니다.

연결 관련 에러 메시지 하나씩 짚어보기

이 부류의 로그는 코어가 목적지 서버 또는 프록시 노드와 TCP/UDP 연결을 맺으려 시도하는 단계에서 나타납니다. "연결이 되냐 안 되냐"를 확인할 때 가장 먼저 봐야 할 부분입니다.

dial tcp timeout

코어가 연결을 시도했지만 제한 시간 안에 아무 응답도 받지 못했다는 뜻입니다. 흔한 원인은 세 가지입니다. 첫째, 목적지 서버 자체의 응답이 느리거나 서버가 다운된 경우. 둘째, 선택한 프록시 노드에서 목적지 서버까지 가는 경로에 패킷 손실이 있는 경우. 셋째, 로컬 환경과 프록시 서버 사이의 네트워크 자체가 막혀 있는 경우(노드 서버가 만료됐거나 차단된 경우 등). 확인 순서는 먼저 같은 프록시 그룹 안의 다른 노드로 바꿔서 같은 목적지에 다시 접속해보는 것을 추천합니다. 노드를 바꾸자마자 바로 정상화되면 그 노드 자체의 문제이고 로컬 설정과는 무관하다는 뜻입니다. 반대로 어떤 노드로 바꿔도 계속 타임아웃이 발생하면, 로컬에서 프록시 서버 출구까지의 기본적인 연결 상태를 점검해야 합니다.

connection refused

이 에러는 timeout과는 다릅니다. 상대측이 연결 요청을 명확히 거부했다는 뜻으로, 네트워크 경로 자체는 문제없이 통한다는 것을 의미합니다. 다만 목적지 포트에서 서비스가 리스닝하고 있지 않거나, 방화벽이 (패킷을 버리는 게 아니라) 적극적으로 거부하고 있는 상황입니다. 로그에서 이 에러가 127.0.0.1과 로컬 포트를 가리키고 있다면, 대개 코어 자체가 정상적으로 리스닝을 시작하지 못했거나 mixed 포트 설정을 바꾼 뒤 클라이언트 화면이 제대로 갱신되지 않은 경우입니다. mixed-port 설정값과 해당 포트에 프로세스가 실제로 리스닝 중인지 확인해볼 필요가 있습니다.

no route to host

이건 네트워크 계층 에러로, 시스템 라우팅 테이블에 해당 목적지 IP로 가는 경로가 없다는 뜻입니다. TUN 모드를 켠 상태에서 라우팅 테이블이 잘못 기록되거나 시스템 기존 라우팅과 충돌하면 이 로그가 자주 나타납니다. TUN 서비스를 한 번 재시작하거나, 다른 네트워크 도구가 동시에 기본 라우팅을 가져가고 있는지 확인하면 대부분 해결됩니다.

i/o timeout과 EOF

i/o timeout은 대개 연결이 이미 성립된 이후, 데이터를 주고받는 단계에서 나타납니다. 연결 자체는 성공했지만 전송 중에 끊긴 경우로, 노드의 대역폭이 부족하거나 장시간 연결이 중간 네트워크 장비에 의해 강제로 끊겼을 때 흔히 발생합니다. EOF는 상대방이 먼저 연결을 종료했다는 뜻으로, 가끔 한두 번 나타나는 정도면 신경 쓰지 않아도 되지만 특정 노드에서 자주 반복된다면 해당 노드를 프록시 그룹에서 잠시 제외하는 것도 고려해볼 만합니다.

규칙 매칭 로그, 어떻게 읽어야 할까

info 레벨에서는 새 연결이 생길 때마다 규칙 매칭 결과가 한 줄씩 출력됩니다. 형식은 대략 "매칭된 규칙 유형 + 사용된 정책" 순서입니다. 이 로그 자체는 에러가 아니지만, "이 사이트가 왜 프록시를 안 타는지" 또는 "왜 속도가 이상한지"를 알아낼 핵심 단서가 됩니다.

[TCP] example.org:443 match DomainSuffix(example.org) using PROXY
[TCP] cn.example.com:443 match GEOIP(CN) using DIRECT
[TCP] 10.0.0.5:8080 match Match() using REJECT

첫 번째 줄은 이 연결이 도메인 접미사 규칙에 매칭되어 PROXY 정책 그룹을 사용했다는 뜻입니다. 두 번째 줄은 목적지 IP가 중국 본토 주소로 판별되어 GEOIP 규칙에 따라 직접 연결(direct)됐다는 뜻입니다. 세 번째 줄은 어떤 구체적인 규칙에도 매칭되지 않아 최종 기본 규칙인 MATCH로 떨어졌고, 이 기본 규칙의 정책이 REJECT라서 바로 차단됐다는 뜻입니다. 정상적으로 접속돼야 할 연결이 대부분 기본 규칙으로 떨어져 차단되고 있다면, 규칙 목록의 순서에 문제가 있거나 기본 규칙을 DIRECT로 적어야 하는데 실수로 REJECT로 적어놓은 경우가 많습니다. 설정 파일에서 rules 항목의 맨 마지막 줄을 확인해보면 대부분 원인을 바로 찾을 수 있습니다.

주의

규칙은 위에서 아래로 순서대로 매칭되며, 한 번 매칭되면 그 아래 규칙은 더 이상 보지 않습니다. 프록시를 타야 할 도메인이 앞쪽의 더 넓은 범위의 규칙에 걸려 직접 연결로 처리돼버렸다면, 로그의 match 정보를 보면 어떤 규칙이 작동했는지 추측할 필요 없이 바로 확인할 수 있습니다.

노드 및 프록시 그룹 관련 경고

단일 연결의 에러 외에도 Clash는 주기적으로 프록시 그룹의 상태 확인(health check) 결과를 출력합니다. 이런 로그는 대개 warning 레벨이며, 연결이 완전히 실패했다는 뜻은 아니지만 눈여겨볼 필요가 있습니다.

health check failed / url-test 타임아웃: 프록시 그룹에 자동 속도 측정(url-test 또는 fallback 타입)이 설정된 경우, 특정 노드가 정해진 시간 안에 테스트 주소로의 요청을 완료하지 못하면 코어가 해당 노드를 사용 불가로 표시하고 잠시 건너뛴 뒤 다음 검사 주기에 다시 시도합니다. 가끔 한두 번 나타나는 건 정상적인 변동입니다.
all proxies unavailable / no proxy available: 프록시 그룹 안의 모든 노드가 사용 불가로 판정된 상태로, 이 경우 해당 그룹의 모든 연결이 실패합니다. 원인은 구독 노드가 전체적으로 만료됐을 수도 있고, 테스트 주소 자체가 현재 네트워크 환경에서 접속되지 않아 모든 노드가 실패한 것으로 잘못 판정됐을 수도 있습니다. 먼저 그룹 안의 특정 노드로 수동으로 전환해서 직접 테스트해보세요. 수동으로는 연결이 잘 된다면 속도 측정 로직이 오판한 것이므로 테스트 주소나 검사 간격을 조정하면 됩니다.
proxy group has no selected proxy: 정책 그룹 안에 선택 가능한 노드가 하나도 없는 상태로, 대개 구독을 파싱한 결과 노드 목록이 비어 있는 경우입니다. 구독 관리 화면으로 돌아가 노드 수와 필터링 규칙이 노드를 전부 걸러내고 있지는 않은지 확인해보세요.

DNS 관련 로그와 해결 방법

연결 문제처럼 보이지만 실제로는 DNS 해석 실패가 원인인 경우도 적지 않습니다. 로그에 could not resolve host가 나오거나 해석 속도가 비정상적으로 느리다면, 먼저 설정 파일의 dns 항목이 켜져 있는지, 사용 중인 상위 DNS 서버에 접속이 가능한지 확인하세요. fake-ip 모드를 켠 상태에서 일부 앱이 가상 IP를 제대로 처리하지 못하면 로그상 목적지 주소가 이상해 보이는 형태로 나타날 수 있습니다. 이럴 때는 보통 fake-ip-filter에 해당 도메인을 예외로 추가해서, 이 트래픽만 가상 주소 대신 실제 IP로 해석되도록 처리해야 합니다.

전체적인 해결 순서는 세 단계로 정리할 수 있습니다. 먼저 레벨을 보고 심각도를 판단하세요. error일 때만 즉시 손을 봐야 합니다. 다음으로 에러 텍스트를 보고 네트워크 계층 문제(timeout, refused, no route)인지 로직 계층 문제(match, health check)인지 구분하세요. 마지막으로 로그에 나온 목적지 주소와 노드 이름을 참고해서, "프록시 전체가 고장 났다"는 식으로 뭉뚱그리지 말고 문제를 특정 노드, 특정 규칙, 특정 로컬 네트워크 구간으로 좁혀서 파악하세요.