먼저 어떤 로그를 보고 있는지 확인하기

Clash 클라이언트에는 일반적으로 그래픽 인터페이스와 프록시 코어가 함께 포함됩니다. 인터페이스는 설정 가져오기, 노드 전환, 옵션 변경을 담당하고, Clash Meta（mihomo） 같은 코어는 포트 수신, DNS 해석, 규칙 매칭 및 연결 수립을 담당합니다. 네트워크 문제를 진단할 때 실제로 중요한 것은 설치 기록이나 인터페이스 충돌 보고서가 아니라 코어 실행 로그인 경우가 많습니다.

일반적인 로그 한 줄에는 시간, 레벨, 연결 출처, 대상 주소, 매칭된 규칙과 최종 출구가 표시됩니다. 클라이언트마다 형식은 조금씩 다르지만 정보의 의미는 대체로 같습니다. 예를 들면 다음과 같습니다.

2026-06-02 14:32:18 INFO [TCP] 127.0.0.1:51842
--> api.example.com:443
match DomainSuffix(example.com) using Proxy[Node-A]

이 기록은 로컬 포트 51842에서 TCP 연결을 시작했고, 대상은 api.example.com:443이며, 설정의 DOMAIN-SUFFIX,example.com 규칙이 매칭되었음을 의미합니다. 연결은 최종적으로 Proxy라는 정책 그룹에 전달되었고, 그룹 안에서는 실제로 Node-A가 사용되었습니다. 이를 통해 트래픽이 Clash에 들어왔고 규칙과 출구 선택 결과를 확인할 수 있지만, 대상 사이트가 정상적인 콘텐츠를 반환했다는 사실까지 단독으로 증명할 수는 없습니다.

인터페이스 로그와 코어 로그의 차이

  • 코어 로그: TCP, UDP, DNS, 규칙 매칭, 프록시 핸드셰이크 및 TUN 인바운드 정보를 포함하며 연결 문제를 진단하는 핵심 근거입니다.
  • 인터페이스 로그: 설정 저장, 트레이 조작, 창 로딩, 업데이트 확인 등의 이벤트를 기록하며 클라이언트가 시작되지 않거나 버튼이 반응하지 않을 때 유용합니다.
  • 서비스 로그: 일부 Windows 클라이언트는 TUN을 제어하거나 권한을 높이기 위해 시스템 서비스를 설치합니다. 서비스 시작에 실패했다면 서비스 로그도 함께 확인해야 합니다.
  • 구독 업데이트 기록: 원격 설정 요청이 200, 401, 403, 404를 반환했는지 또는 시간 초과가 발생했는지 확인하는 데 사용하며, 일반적인 프록시 연결 로그와는 다릅니다.

로그 레벨 선택 방법

Clash 설정의 log-level은 코어가 출력하는 로그의 양을 제어합니다. mihomo 1.19.x에서 자주 사용하는 레벨은 silent, error, warning, info, debug입니다. 일부 그래픽 클라이언트는 warning을 Warn으로 줄여 표시하거나 레벨을 「코어 설정」 안에 배치합니다.

레벨 주요 내용 적용 상황
silent 일반 출력 중지 장기간 실행하면서 상태를 확인할 필요가 없을 때 사용하며, 문제 진단에는 적합하지 않습니다
error 명확히 실패한 작업 코어에서 심각한 오류가 계속 발생하는지 확인
warning 경고 및 오류 설정 호환성, DNS 이상 및 리소스 로딩 문제 확인
info 연결, 규칙 매칭 및 일반 상태 처음 연결 실패나 규칙 미적용을 진단할 때 우선 사용
debug 더 자세한 해석, 다이얼링 및 내부 처리 정보 Info로 원인을 찾지 못할 때 잠시 활성화

대부분의 문제는 먼저 Info를 사용하면 충분합니다. Debug는 몇 분 만에 수천 줄까지 늘어날 수 있고, 브라우저 백그라운드 연결이 실제 실패 요청을 가릴 수 있습니다. 재현 직전에만 활성화하고 테스트가 끝나면 즉시 Info로 되돌리는 것이 좋습니다.

YAML을 직접 편집한다면 최상위에 다음과 같이 설정할 수 있습니다.

log-level: info

Clash Verge Rev 2.3.x를 예로 들면 「설정」→「Clash 설정」→「로그 레벨」을 연 뒤 Info를 선택합니다. 기록을 확인하려면 「로그」로 이동하세요. 세부 버전에 따라 메뉴가 「코어 로그」 또는 「실행 로그」로 표시될 수 있습니다. 인터페이스에서 변경한 내용이 적용되지 않으면 현재 설정이 구독으로 관리되는지, 설정 전환 후 클라이언트가 로컬 매개변수를 덮어쓰는지 확인하세요.

한 줄의 기록에서 연결 경로 분석하기

로그를 읽을 때 빨간색 Error만 검색하지 마세요. 웹페이지가 열리지 않는 많은 문제는 일반 Info 기록으로 나타납니다. 코어가 요청을 정상적으로 받았지만 이후 다이얼링 단계에서 시간 초과가 발생했을 수 있기 때문입니다. 더 효과적인 방법은 「인바운드, 대상, 규칙, 정책, 결과」의 다섯 항목을 순서대로 읽는 것입니다.

  1. 인바운드 출처: 요청이 HTTP, SOCKS, Mixed 또는 TUN에서 들어왔는지 확인합니다. 흔한 로컬 수신 주소는 127.0.0.1이며, Mixed 포트는 보통 7890으로 설정됩니다.
  2. 대상 주소: 대상이 도메인인지 IP인지, 포트가 80, 443, 53 또는 애플리케이션의 사용자 지정 포트인지 확인합니다.
  3. 규칙 매칭: Domain, DomainSuffix, GeoIP, IPCIDR, RuleSet 또는 최종 Match를 식별합니다.
  4. 정책 출구: 트래픽이 DIRECT, REJECT로 처리되는지, 아니면 특정 프록시 그룹과 노드로 전달되는지 확인합니다.
  5. 연결 결과: 같은 시각 전후에 timeout, refused, TLS, DNS 또는 EOF가 나타나는지 계속 확인합니다.

시스템 프록시가 트래픽을 가로채지 못하는지 확인하는 방법

로그를 지운 뒤 이전에 열지 않았던 웹사이트에 접속하세요. 로그에 TCP 또는 UDP 연결이 전혀 추가되지 않는다면 문제는 보통 요청이 코어에 들어오기 전에 발생한 것입니다. 먼저 시스템 프록시가 켜져 있는지 확인하고, 애플리케이션이 시스템 프록시를 우회하지 않는지도 점검하세요. Windows에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 상태를 확인할 수 있습니다. 일반적인 HTTP 프록시 주소는 127.0.0.1:7890이지만 실제 포트는 클라이언트에 표시된 값을 사용하세요.

브라우저에 별도의 프록시 확장 프로그램이 있다면 확장 프로그램의 포트도 Clash가 현재 수신 중인 포트와 일치해야 합니다. 로그가 비어 있는데 노드만 계속 바꾸는 것은 의미가 없습니다. 노드에 요청 자체가 도달하지 않았기 때문입니다. TUN 모드를 사용한다면 로그에 TUN 인바운드 시작 기록이 나타나는지 확인하고 가상 네트워크 어댑터가 생성되었는지도 점검하세요.

규칙이 잘못 매칭되었는지 확인하는 방법

대상이 로그에 나타나지만 예상과 다른 출구를 사용한다면 match 뒤에 표시된 규칙에 주목하세요. 원래 프록시를 사용해야 하는 대상이 다음과 같이 표시될 수 있습니다.

INFO [TCP] 198.18.0.1:42116 --> service.example.com:443
match GeoIP(CN) using DIRECT

198.18.0.1은 Fake-IP 매핑 주소일 수 있으며 실제 서버가 해당 주소에 있다는 뜻은 아닙니다. 핵심은 최종적으로 GeoIP에 매칭되어 DIRECT로 처리되었다는 점입니다. 도메인 규칙이 우선 매칭되어야 한다면 규칙 순서, 규칙셋의 정상 로딩 여부, 도메인이 너무 일찍 IP로 해석되었는지를 확인하세요. Clash 규칙은 위에서 아래 순서로 매칭되며 첫 번째 규칙이 매칭되면 이후 규칙은 검사하지 않습니다.

자주 발생하는 오류의 의미

i/o timeout 및 context deadline exceeded

두 메시지 모두 시간 초과를 의미하지만 발생한 단계는 다를 수 있습니다. 노드 주소 연결이 시간 초과되면 노드 오프라인, 포트 접근 불가, 네트워크 차단 또는 UDP 미지원이 원인일 수 있습니다. 대상 사이트 연결이 시간 초과되면 노드에서 대상까지의 경로에 문제가 있을 가능성이 있습니다. 먼저 오류에 표시된 주소를 확인하세요. 노드 서버 IP와 노드 포트라면 지연 시간 테스트를 통과한 다른 노드로 전환하고, 대상 도메인의 443 포트라면 DIRECT와 프록시 출구를 비교하세요.

지연 시간 테스트에서 80ms가 나왔다고 해서 노드가 반드시 정상 작동하는 것은 아닙니다. 일부 테스트는 고정 URL만 접속하며, 실제 웹사이트 이용에는 DNS, TLS, 대상 서버 정책도 영향을 줍니다. 세 번 연속 테스트해 결과가 80ms, 450ms, 시간 초과 사이에서 크게 변한다면 노드 경로 자체가 불안정한 것입니다.

connection refused

connect: connection refused는 대상 호스트가 연결을 명시적으로 거부했다는 뜻이며, 일반적으로 시간 초과보다 빠르게 반환됩니다. 거부 대상이 127.0.0.1:7890이라면 애플리케이션이 로컬 프록시 포트에 연결하려 했지만 해당 포트를 수신 중인 프로세스가 없다는 의미입니다. 코어가 시작되지 않았거나 포트가 변경되었을 수 있습니다. 원격 노드 포트가 거부되었다면 서버 프로세스 중지, 포트 변경 또는 구독에 포함된 노드 정보 만료가 흔한 원인입니다.

Windows에서는 netstat -ano | findstr 7890을 실행해 포트를 확인할 수 있습니다. macOS 또는 Linux에서는 lsof -i :7890을 실행하세요. LISTEN 기록이 없다면 먼저 코어 실행을 복구하고 규칙 확인은 나중에 진행하면 됩니다.

no such host, server misbehaving 및 DNS 시간 초과

no such host는 일반적으로 도메인에서 사용 가능한 DNS 해석 결과를 얻지 못했다는 뜻입니다. 도메인 오타, 업스트림 DNS의 NXDOMAIN 응답, 또는 Clash가 설정된 nameserver에 접근하지 못한 경우가 원인일 수 있습니다. server misbehaving은 DNS 업스트림의 비정상 응답이나 요청 과정 중단에서 자주 발생합니다. 로그에 lookup, exchange failed, deadline exceeded가 함께 나타난다면 노드나 규칙보다 DNS를 우선 점검해야 합니다.

먼저 설정의 DNS 활성화 여부와 수신 주소를 다음과 같이 확인할 수 있습니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

여기서 1053은 Clash DNS 수신 포트이며 브라우저 프록시 포트가 아닙니다. 시스템이나 다른 프로그램이 이 포트로 DNS 요청을 보내야 한다면 포트가 사용 중이 아닌지도 확인해야 합니다. DoH를 사용할 때는 DoH 도메인 자체의 최초 해석 문제도 고려하세요. 필요한 경우 default-nameserver에 직접 접근 가능한 IP형 DNS를 지정할 수 있습니다.

TLS handshake timeout 및 인증서 관련 메시지

TLS handshake timeout은 TCP 연결은 이미 수립되었지만 제한 시간 안에 TLS 핸드셰이크가 완료되지 않았다는 뜻입니다. 노드 품질, 대상 사이트의 느린 응답, 중간 네트워크의 패킷 손실 또는 시스템 시간 오류가 원인일 수 있습니다. 먼저 시스템 날짜, 시간대와 자동 시간 동기화를 확인한 뒤 노드를 바꿔 다시 테스트하세요. 하나의 도메인만 실패한다면 대상 사이트나 해당 도메인의 경로에 문제가 있을 가능성이 더 큽니다.

x509, certificate signed by unknown authority 또는 도메인 불일치 메시지는 인증서 검증 실패를 의미합니다. 장기적인 해결책으로 인증서 검증을 바로 끄지 마세요. 시스템 시간, 로컬 패킷 캡처 프로그램, 기업 네트워크 인증서와 노드의 응답 내용을 확인해 연결이 잘못된 서버로 리디렉션되지 않았는지 점검해야 합니다.

EOF, connection reset by peer 및 broken pipe

EOF는 데이터 스트림이 예상보다 일찍 종료되었다는 뜻입니다. 한 번만 나타났다고 반드시 장애인 것은 아니며, 브라우저가 요청을 취소할 때도 EOF가 발생할 수 있습니다. connection reset by peer는 원격 측이 연결을 능동적으로 초기화했다는 뜻이고, broken pipe는 로컬에서 계속 쓰려 했지만 상대 연결이 이미 닫혔다는 뜻입니다. 페이지를 닫을 때만 나타난다면 무시해도 되지만, 접속할 때마다 1~2초 안에 반복된다면 노드를 바꾸고 QUIC를 끈 뒤 다시 시도하며 대상이 현재 출구 IP를 제한하는지 확인하세요.

현상별로 노드·규칙·DNS 진단하기

노드 지연 시간은 정상인데 웹페이지가 열리지 않을 때

  1. 로그 레벨을 Info로 설정하고 기존 기록을 삭제합니다.
  2. HTTPS 웹사이트 하나만 방문하고 대상 도메인과 작업 시간을 기록합니다.
  3. 로그에 대상 도메인이 나타나는지 확인하고 실제로 사용된 정책 그룹과 노드를 확인합니다.
  4. 같은 분 안에 발생한 timeout, TLS, reset, EOF를 검색합니다.
  5. 동일한 규칙을 고정한 채 다른 노드로 다시 테스트하여 여러 변수를 동시에 바꾸지 않습니다.
  6. 모든 노드에서 실패한다면 DIRECT로 전환해 비교하고 DNS 해석 결과도 확인합니다.

노드를 바꾼 직후 정상으로 돌아온다면 문제는 기존 노드나 해당 노드의 상위 경로에 집중됩니다. 모든 노드가 해석 단계에서 실패한다면 DNS를 우선 확인하세요. 로그에 DIRECT가 표시되는데 프록시가 예상되었다면 규칙 순서나 정책 그룹 선택을 점검해야 합니다.

특정 애플리케이션만 연결되지 않을 때

브라우저는 정상인데 특정 애플리케이션에서 로그가 전혀 생성되지 않는다면 해당 애플리케이션이 시스템 프록시를 사용하지 않는 경우가 많습니다. 일부 게임, 명령줄 도구와 스토어 앱은 직접 연결을 수립하므로 이때는 TUN 모드를 활성화해 더 많은 트래픽을 가로챌 수 있습니다. 활성화 후에는 TUN 장치가 시작되었는지, 경로가 등록되었는지, 권한 오류가 발생하지 않았는지 확인하세요.

애플리케이션에서 로그는 생성되지만 UDP가 계속 실패한다면 선택한 노드가 UDP를 지원하는지, 정책 그룹이 UDP를 허용하는지 확인하세요. TUN의 MTU도 특정 네트워크에 영향을 줄 수 있습니다. 기본값에서 단편화 문제가 발생한다면 클라이언트가 지원하는 범위 안에서 1500에서 1400으로 낮춰 한 번 비교 테스트할 수 있지만, 증상 근거 없이 반복해서 변경해서는 안 됩니다.

규칙 모드가 적용되지 않지만 전역 모드에서는 정상일 때

이런 경우는 대개 규칙 매칭과 관련이 있습니다. 전역 모드는 대부분의 규칙 판단을 우회하고 선택한 프록시 그룹을 직접 사용하므로, 노드가 최소한의 연결 능력을 갖추었다는 사실을 확인할 수 있습니다. 규칙 모드로 돌아간 뒤 대상 도메인을 검색하고 매칭 항목을 확인하세요. MATCH,DIRECT에 도달했다면 마지막 규칙을 점검하고, 만료된 규칙셋에 매칭되었다면 규칙 제공자의 다운로드 실패 여부를 확인하세요.

규칙셋 로딩 문제에는 HTTP 404, 403, 시간 초과 또는 YAML 해석 오류가 함께 나타나는 경우가 많습니다. 원격 주소를 수정한 뒤 클라이언트에서 「설정」→「업데이트」 또는 해당 규칙셋 업데이트 작업을 실행하고, 로그에 로딩 성공 기록이 나타나는지 확인하세요. 정책 그룹 이름만 바꾸고 규칙 참조를 업데이트하지 않으면 규칙이 존재하지 않는 정책을 가리키게 됩니다.

TUN 모드 로그에서 추가로 확인할 항목

TUN 모드는 시스템 네트워크 계층에서 트래픽을 수신하므로 로그에 가상 네트워크 어댑터, 라우팅, DNS 가로채기 및 인터페이스 선택 정보가 나타날 수 있습니다. 코어가 시작된 뒤에도 TUN 장치가 생성되지 않는다면 권한 부족, 시스템 서비스 미실행, 가상 네트워크 어댑터 충돌 또는 다른 VPN의 라우팅 점유가 흔한 원인입니다.

  • 시작하자마자 권한 오류가 발생함: 클라이언트 서비스 상태를 확인하고 운영체제의 요구 사항에 따라 관리자 권한을 부여하세요.
  • 시작은 성공했지만 전체 네트워크가 끊김: 기본 인터페이스 인식, DNS 가로채기 대상 및 라우팅 등록이 정상인지 확인하세요.
  • 로컬 네트워크 장치에 접근할 수 없음: 사설 네트워크 대역이 잘못 프록시로 전달되고 있지 않은지 확인하세요. 흔한 대역은 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12입니다.
  • 일부 UDP 애플리케이션에 문제가 발생함: 노드 프로토콜이 UDP를 지원하는지 확인하고 시간 초과 또는 네트워크 연결 불가 메시지가 나타나는지 살펴보세요.
  • 종료 후 네트워크가 복구되지 않음: 먼저 코어를 완전히 종료한 뒤 시스템 프록시, DNS 및 기본 라우팅에 이전 값이 남아 있는지 확인하세요.

사용 가능한 장애 기록 정리하기

설정 제공자나 클라이언트 프로젝트에 피드백할 때는 전체 화면 캡처보다 정리된 텍스트가 더 효과적인 경우가 많습니다. 코어 버전, 클라이언트 버전, 운영체제, 발생 시간, 프록시 모드, 대상 도메인, 매칭된 정책과 연속으로 발생한 오류 행을 남기는 것이 좋습니다. mihomo 코어 버전은 클라이언트의 「정보」 또는 「코어」 페이지에서 확인할 수 있으며, 예를 들어 mihomo v1.19.x처럼 표시됩니다. 클라이언트 버전도 세부 버전까지 정확히 적어야 합니다.

제출하기 전에 구독 주소, 인증 매개변수, 노드 서버 자격 증명과 로컬 네트워크 장치 이름을 삭제하세요. 공용 대상 도메인, 오류 유형과 규칙 이름은 보통 남겨야 요청이 어느 단계에서 실패했는지 판단할 수 있습니다. 다음 형식으로 정리하면 됩니다.

시스템: Windows 11 24H2
클라이언트: Clash Verge Rev 2.3.x
코어: mihomo 1.19.x
모드: Rule + TUN
발생 시간: 2026-06-02 14:32
현상: 브라우저에서 대상 도메인 접속 시 계속 시간 초과
매칭: DomainSuffix → Proxy → Node-A
오류: dial tcp 203.0.113.10:443: i/o timeout
비교: Node-B로 전환한 후 연결 복구

이 기록만으로도 범위를 Node-A 또는 해당 경로로 좁힐 수 있으므로 몇 분간의 모든 백그라운드 연결을 첨부할 필요는 없습니다. 문제가 DNS와 관련 있다면 nameserver 유형, Fake-IP 또는 Redir-Host 모드, 조회 실패 메시지만 추가하면 됩니다.

로그 문제 해결 순서 요약

안정적인 진단 순서는 먼저 트래픽이 Clash에 들어왔는지 확인하고, 다음으로 대상과 포트를 확인한 뒤 매칭된 규칙, 정책 그룹과 실제 노드를 확인하고, 마지막으로 바로 뒤따르는 오류를 읽는 것입니다. 로그가 비어 있으면 시스템 프록시 또는 TUN 가로채기를 점검하고, 출구가 잘못되었으면 규칙을 확인하세요. lookup 또는 no such host가 나타나면 DNS를 점검하고, timeout·refused·TLS·reset이 나타나면 노드나 원격 경로를 판단합니다.

Info 레벨은 대부분의 상황에 적합하며, Debug는 핵심 세부 정보가 부족할 때만 잠시 활성화하세요. 재현이 끝나면 원래 설정으로 복원하고 시간과 버전 정보가 포함된 간결한 로그를 보관하세요. 이렇게 하면 감으로 설정을 반복해서 바꾸는 일을 줄이고 문제가 클라이언트, 규칙, DNS, 노드 또는 대상 웹사이트 중 어디에 있는지 더 빠르게 판단할 수 있습니다.