Clash 실행 로그 읽는 법: 흔한 오류 메시지 의미와 문제 진단 절차

로그가 문제 진단의 1차 자료인 이유

'웹페이지가 안 열려요', '구독이 안 돼요', '특정 앱이 연결이 안 돼요' 같은 문제를 만나면 많은 사람들이 일단 노드를 바꾸거나 클라이언트를 재시작하고, 몇 번 시도해도 안 되면 포기해 버립니다. 사실 이런 문제의 답은 대부분 로그에 이미 적혀 있습니다. Clash 코어(원본 Clash든 지금 더 널리 쓰이는 Clash Meta / mihomo 코어든)는 각 연결을 처리할 때마다 한 줄의 로그를 남깁니다: 어디서 온 트래픽인지, 어떤 규칙을 탔는지, 최종적으로 어디에 연결을 시도했는지, 연결이 성공했는지 실패했는지, 실패했다면 구체적인 원인이 무엇인지.

다시 말해 로그는 '네트워크가 안 된다'는 뭉뚱그린 현상을 구체적인 단계로 쪼개 보여줍니다: 로컬에서 요청 자체가 나가지 않았는지, DNS 해석이 실패했는지, 아니면 핸드셰이크 단계에서 대상이나 노드가 거부했는지. 로그를 읽는 법을 익히면 문제 진단이 '무작정 시도'에서 '단서 기반 추적'으로 바뀌면서 효율이 눈에 띄게 올라갑니다.

로그 레벨과 확인 방법

Clash의 로그는 몇 가지 레벨로 나뉘며, 낮은 순서대로 대략 debug, info, warning, error, silent입니다. 레벨이 낮을수록 기록되는 내용이 상세해집니다:

• debug: 거의 모든 내부 동작이 기록됩니다. 매 DNS 조회, 매 연결 시도까지 남기므로 난해한 문제를 추적할 때 가장 유용하지만 출력량이 매우 많습니다.
• info: 일상적인 사용에 추천되는 레벨로, 연결 성립, 규칙 매칭, 연결 종료 등 핵심 지점만 기록해 화면이 넘치지 않습니다.
• warning / error: 이상이 발생한 연결만 기록해 평소에는 조용하지만, 문제 진단 시 정보량이 부족한 편입니다.

대부분의 GUI 클라이언트는 로그 패널을 메인 화면의 사이드바나 하단 탭에 두며, 제목은 보통 '로그' 또는 'Logs'로 표시됩니다. 화면에서 레벨을 바로 전환할 수 있는 경우가 많습니다. 구체적인 문제를 조사할 때는 잠시 debug 레벨로 전환해 문제를 재현한 뒤 다시 info로 돌려놓는 것을 권장합니다. 장기간 과도한 로그 파일이 쌓이는 것을 방지할 수 있습니다.

흔한 로그 항목 하나씩 대조하기

로그 형식은 코어 버전에 따라 약간 다르지만 핵심 정보는 대체로 비슷합니다: 시간, 레벨, 프로토콜 종류, 소스 주소, 대상 주소, 매칭된 규칙과 정책, 그리고 성공/실패 결과. 아래에서 오류 유형별로 하나씩 설명합니다.

연결 계열 오류: connection refused / timeout

[TCP] 192.168.1.5:51234 --> example.com:443 match RuleSet(proxy) using 노드A
dial tcp 203.0.113.10:443: connect: connection refused

connection refused는 3방향 핸드셰이크 요청이 대상 측에서 명확히 거부되었다는 뜻으로, 보통 상대 포트에 리스닝 서비스가 없거나 노드 서버가 오프라인이거나 노드 자체에 장애가 발생했음을 의미합니다. i/o timeout(타임아웃)은 다릅니다. 요청은 나갔지만 거부도 응답도 받지 못한 상태로, 회선 혼잡, 대상 서버 무응답, 또는 노드가 위치한 네트워크가 속도 제한이나 차단을 당한 경우에 흔합니다. 둘의 차이는 중요합니다: 거부는 보통 노드를 바꿔야 하고, 타임아웃은 먼저 회선 품질을 의심해야 합니다.

DNS 해석 오류: no such host

dial tcp: lookup example.com: no such host

이 로그는 연결을 맺기 전 단계에서 나타나며, 도메인 해석 단계 자체가 실패해 노드에 연결을 시도하는 단계까지 가지 못했다는 뜻입니다. 흔한 원인은 DNS 서버가 사용 불가능하거나, 설정 파일의 nameserver가 잘못 적혀 있거나, 특정 DNS 모드가 함께 필요한 분기 규칙을 켰는데 fake-ip나 enhanced-mode를 함께 활성화하지 않은 경우입니다. 대부분의 도메인에서 이 오류가 나면 먼저 DNS 설정 자체를 확인하고, 특정 도메인만 오류가 난다면 해당 도메인이 일부 DNS 서버에서 실제로 해석 이상을 겪고 있을 가능성이 큽니다.

규칙 매칭 기록: 트래픽 경로 확인

[TCP] 10.0.0.8:60021 --> api.example.com:443 match DomainSuffix(example.com) using DIRECT

이런 로그는 오류가 아니라 '트래픽 경로 설명서'입니다. match 뒤에는 매칭된 구체적 규칙이, using 뒤에는 최종 사용된 정책(DIRECT 직접 연결, 특정 노드 또는 정책 그룹)이 표시됩니다. 프록시를 타야 할 사이트인데 로그에 using DIRECT가 보인다면, 규칙이 적용되지 않았거나 직접 연결 규칙보다 뒤쪽에 배치됐다는 뜻입니다. 반대로 직접 연결해야 할 국내(한국) 주소가 프록시를 타고 있다면 여기서 바로 발견할 수 있습니다. 규칙 매칭 기록은 '설정이 의도대로 동작하는지'를 판단하는 가장 직접적인 증거입니다.

TLS 및 핸드셰이크 계열 오류

remote error: tls: handshake failure
EOF

핸드셰이크 실패나 연결 중 EOF(상대가 연결을 먼저 종료)가 나타나는 것은, 노드의 전송 프로토콜 설정과 서버 측이 일치하지 않는 경우(예: TLS 파라미터, SNI 위장 도메인 불일치)나 노드 서버가 트래픽 정리 과정에서 연결을 오탐한 경우에 흔합니다. 이런 문제는 대개 로컬 설정 문제가 아니므로, 먼저 구독이나 노드 목록에서 다른 노드로 바꿔 확인해 보고, 여러 노드에서 같은 유형의 오류가 반복된다면 그때 로컬 설정 파일의 해당 프로토콜 필드 작성법을 점검하는 것을 권장합니다.

시간순으로 문제 좁히기: 요청 시작부터 데이터 반환까지

로그를 확보했다면 빨간 글자만 훑어보기보다 다음 시간 순서대로 살펴보는 것을 권장합니다:

1. 요청이 로컬에서 캡처됐는지.해당 연결의 기록이 로그에 나타나는지 확인합니다. 아예 기록이 없다면 시스템 프록시가 적용되지 않았거나 TUN 모드가 트래픽을 제대로 가로채지 못한 것일 수 있으며, 노드 문제가 아닐 가능성이 큽니다.
2. DNS 해석이 성공했는지.no such host 계열 기록이 있는지 확인합니다. 해석이 실패하면 이후 연결 단계는 애초에 일어나지 않습니다.
3. 규칙 매칭이 기대대로인지.match와 using 필드가 가리키는 정책이 의도한 것인지 확인합니다. 잘못된 정책 그룹을 탄 경우는 잘못된 노드를 탄 경우보다 놓치기 쉽습니다.
4. 연결이 성공적으로 성립됐는지.connection refused, timeout 또는 TLS 관련 오류가 있는지 확인합니다. 이 단계의 오류는 대체로 '노드 교체'인지 '회선 확인'인지로 이어집니다.
5. 연결 성립 후 정상적으로 종료됐는지.정상적인 접속이 끝나면 연결 종료 기록이 있어야 합니다. 연결이 오래 걸려 있으면서 종료 기록이 없다면, 네트워크 계층 문제가 아니라 대상 서비스의 응답이 느린 경우일 수 있습니다.

이 다섯 단계를 머릿속으로 짚어보면 '연결 안 됨'이라는 모호한 표현을, 하나의 구체적인 단계로 정확히 좁힐 수 있습니다.

흔한 상황 대조 요약표

진단 시 몇 가지 조언

로그를 '빨간색으로 표시된 곳이 곧 고장 난 곳'이라는 신호등처럼 보지 말고, 하나의 증거 사슬로 보는 것이 좋습니다. 여러 노드에서 동시에 같은 유형의 오류가 나타난다면 대체로 로컬 설정이나 DNS를 가리키고, 특정 노드에서만 문제가 생긴다면 대체로 그 노드 자체의 상태 문제입니다. 설정을 바꾸기 전에 먼저 로그를 보는 습관을 들이면 반복 시행착오에 드는 시간을 크게 줄일 수 있습니다.

로그에서 같은 유형의 오류가 계속 반복되고, 이미 로컬 설정과 네트워크 환경 문제를 배제했다면, 공식 빠른 시작 안내를 다시 한 번 따라가며 구독, DNS 모드, 규칙 설정이 모두 권장 기본 상태인지 확인해 보는 것도 좋습니다.