Clash 로그 확인 및 오류 해결 방법: 주요 오류 원인과 단계별 점검

요청을 한 번 재현한 뒤 관련 로그를 필터링하세요

Clash에서 페이지가 열리지 않는다고 해서 반드시 노드가 문제인 것은 아닙니다. 요청이 커널에 도달하지 않았거나 DNS 조회, 규칙 선택, 프록시 핸드셰이크, 대상 서버 응답 단계에서 멈췄을 수 있습니다. 문제를 해결하려면 빨간색 메시지만 보고 설정 전체를 바꾸기보다 마지막으로 성공한 단계를 찾아야 합니다.

이 글은 클래식 Clash와 Clash Meta(현 mihomo)에서 흔히 볼 수 있는 로그를 다룹니다. 커널, 버전, 클라이언트에 따라 항목과 표시 방식이 달라질 수 있으므로, 예시는 로그 구조를 설명하기 위한 것이며 모든 버전에서 같은 문구가 출력된다는 뜻은 아닙니다. 먼저 클라이언트의 ‘정보’ 또는 커널 정보 화면에서 클라이언트 버전과 커널 이름 및 버전을 확인하세요. 클라이언트 버전은 커널 버전을 대신하지 않습니다.

현재 설정을 복사해 보관하고 시스템 프록시, TUN, 실행 모드, 현재 선택된 정책 그룹을 기록합니다.
클라이언트의 ‘로그’ 화면을 엽니다. 메뉴 이름은 클라이언트마다 다를 수 있으니, 찾기 어렵다면 해당 클라이언트의 사용 설명서를 확인하세요.
다른 다운로드 작업을 일시 중지하고 현재 시간을 기록한 다음, 문제가 꾸준히 재현되는 주소 하나만 접속합니다.
요청 전후 약 10초간의 로그를 보관하고 대상 도메인, 대상 포트 또는 소스 연결 포트로 필터링합니다.

로그 레벨과 항목: 먼저 매칭된 규칙을 보고, 다음으로 실패 지점을 확인하세요

설정의 log-level은 로그 상세 수준을 정합니다. 평소에는 info를 사용하고, 원인을 찾기 어려운 문제를 재현할 때만 잠시 debug로 변경하세요. 변경한 설정을 적용하고 점검이 끝나면 원래대로 되돌려야 합니다. 디버그 정보가 지나치게 많으면 중요한 오류를 놓칠 수 있습니다.

log-level: info

설정값	용도	확인할 내용
`debug`	내부 처리 정보를 일시적으로 자세히 확인	시간과 대상 기준으로 필터링하고, 메시지를 하나씩 추측하지 않기
`info`	일반 연결 및 정책 선택 확인	매칭된 규칙, 실제 아웃바운드, 대상 주소 확인
`warning`	경고 및 그보다 심각한 메시지만 유지	같은 대상에서 연결 실패가 반복되는지 확인
`error`	일반 메시지 줄이기	트래픽이 커널에 들어왔는지 단독으로 판단하기 어려움
`silent`	일반 로그 출력 끄기	문제 해결 전에 확인 가능한 레벨로 되돌리기

설정값은 warning이지만 화면에는 WARN으로 표시될 수 있습니다. 화면에 표시된 약어를 설정값으로 착각하지 마세요. 로그 레벨이 오류의 영향 범위를 나타내는 것도 아닙니다. 경고 하나가 페이지 내부의 통계 요청에서 발생할 수도 있고, 잘못된 정책이 선택된 연결이 일반 정보 메시지로 표시될 수도 있습니다.

time="2026-08-06T10:20:30+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> www.example.com:443 match DomainSuffix(example.com) using 수동 선택[노드-A]"

time: 이벤트가 발생한 시각입니다. 여러 기기의 로그를 비교하기 전에 시간대와 시스템 시간을 확인하세요.
[TCP]: 연결 프로토콜입니다. UDP 요청은 별도로 확인해야 하며 TCP 테스트만으로 판단할 수 없습니다.
127.0.0.1:53124: 소스 주소와 임시 포트입니다. 프록시 수신 포트가 아닙니다.
www.example.com:443: 대상 호스트와 포트입니다. HTTPS는 보통 443 포트를 사용하지만 모든 앱이 기본 포트를 따르는 것은 아닙니다.
match: 이번 요청과 일치한 규칙입니다. using 뒤에는 보통 정책 그룹과 실제로 선택된 아웃바운드가 표시됩니다.

로그의 using은 아웃바운드가 선택되었다는 뜻이지, 연결이 성공했거나 웹페이지가 완전히 로드되었다는 뜻은 아닙니다. 같은 대상과 비슷한 시각의 로그에 연결 실패, 핸드셰이크 오류 또는 연결 종료가 있는지 계속 확인하세요.

연결 시간 초과: 프록시 서버와 대상 서버를 구분하세요

i/o timeout, context deadline exceeded 또는 timeout이 포함된 연결 오류는 어느 한 단계에서 대기 시간이 초과되었음을 뜻합니다. ‘시간 초과’라는 문구만으로는 로컬 네트워크, 노드 회선, 대상 사이트 중 어디가 문제인지 알 수 없습니다.

오류에 표시된 주소로 어느 구간에서 멈췄는지 확인하세요

프록시 서버 연결 시간 초과: 오류가 노드 설정에 지정된 서버 주소와 포트를 가리키는지 확인하세요. 해당한다면 먼저 노드에 연결할 수 있는지, 로컬 네트워크와 서버 포트가 정상인지 점검합니다.
대상에 직접 연결하다 시간 초과: 로그에 DIRECT가 표시되고 오류가 대상 IP의 443 포트를 가리킨다면, 우선 해당 연결이 원래 직접 연결되어야 하는지 규칙을 확인하세요.
핸드셰이크 또는 원격 읽기 시간 초과: TCP 연결은 성립했지만 이후 프로토콜 통신이 완료되지 않았을 수 있습니다. 노드 프로토콜, TLS 매개변수, 서버 상태를 추가로 확인해야 합니다.

여러 웹사이트를 열어 보는 것보다 같은 URL로 비교하는 편이 유용합니다. 다음 명령은 HTTP 혼합 포트 7890을 설정한 경우에 사용할 수 있습니다. Windows PowerShell에서는 curl.exe를 명시적으로 실행하고, macOS와 Linux에서는 curl을 사용하세요.

curl -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/
curl -I --connect-timeout 5 --max-time 15 --noproxy "*" https://example.com/

첫 번째 명령은 로컬 프록시 포트를 거치고, 두 번째 명령은 curl의 프록시 설정을 우회합니다. 다만 TUN이 라우팅을 계속 제어하면 두 번째 요청도 커널을 통과할 수 있습니다. 실제 직접 연결과 비교하려면 통제된 환경에서 TUN을 잠시 꺼야 합니다. 403 또는 405도 HTTP 응답이므로 네트워크 연결 실패와 동일하게 볼 수 없습니다.

DNS 조회 실패: 어디에서 조회하는지 먼저 확인하세요

no such host는 유효한 조회 결과를 받지 못했다는 뜻이지만, DNS 서버 장애만을 의미하지는 않습니다. 존재하지 않는 도메인, 상위 DNS의 부정 응답, 로컬 조회 경로 이상도 비슷하게 나타날 수 있습니다. 특히 lookup 뒤에 표시된 도메인이 중요합니다. 프록시 서버 도메인이라면 노드 연결 전에 실패한 것이고, 대상 웹사이트 도메인이라면 아웃바운드와 DNS 설정을 함께 확인해야 합니다.

포트를 지정해 커널 DNS를 테스트하세요

현재 활성화된 설정에 아래 DNS 구성이 실제로 포함되어 있다고 가정하고, 커널이 수신하는 1053 포트에 직접 질의할 수 있습니다. 상위 DNS 주소는 진단 예시일 뿐이므로 실제 네트워크에서 연결할 수 있는 주소를 선택하세요. 구독에 포함된 DNS 설정을 통째로 덮어쓰지 마세요.

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

# macOS / Linux: dig 설치 필요
dig @127.0.0.1 -p 1053 example.com A

# Windows: nslookup 대화형 모드에 들어간 다음 차례로 입력
nslookup
server 127.0.0.1
set port=1053
example.com
exit

조회 시간 초과: 먼저 커널에 해당 설정이 적용되었고 1053 포트가 수신 중인지 확인한 다음, 상위 DNS에 연결할 수 있는지 점검하세요.
NXDOMAIN 응답: 철자를 확인하고 존재 여부가 확인된 도메인으로 비교하세요. 존재하지 않는 도메인을 네트워크 장애로 오인하지 마세요.
Fake-IP 응답: 예를 들어 기본 주소 대역을 사용하는 설정에서 198.18.0.0/16 범위의 매핑 주소가 반환되는 것은 그 자체로 조회 실패가 아닙니다.
시스템 조회는 정상이고 커널 조회에 문제가 있는 경우: 커널 DNS의 상위 서버와 라우팅을 중점적으로 확인하세요. 반대라면 시스템 DNS가 실제로 의도한 경로를 사용하는지 살펴보세요.

일반적인 nslookup example.com은 보통 시스템에 설정된 DNS를 조회하므로 커널 DNS가 정상이라는 근거가 되지 않습니다. DoH 또는 DoT를 사용하는 경우 상위 서버 도메인의 부트스트랩 조회, TLS 인증, 연결 경로도 고려해야 합니다. mihomo의 DNS 확장 항목 중에는 클래식 Clash에서 지원되지 않는 것도 있으므로 추가하기 전에 현재 커널의 지원 범위를 확인하세요. 항목 설명은 DNS 설정 가이드를 참고하세요.

포트 충돌 및 연결 거부: 커널이 실제로 수신 중인지 먼저 확인하세요

bind: address already in use는 보통 시작 또는 재시작 과정에서 발생하며, 로컬 주소와 포트를 다시 바인딩할 수 없다는 뜻입니다. 클라이언트 두 개가 동시에 실행 중이거나 이전 커널 프로세스가 종료되지 않은 경우가 흔합니다. 오류가 프록시 포트, DNS 포트, 컨트롤 인터페이스 중 어디에 해당하는지 먼저 확인하고 모든 포트를 무작정 바꾸지 마세요.

mixed-port: 7890
external-controller: 127.0.0.1:9090

위 설정에서 7890은 혼합 프록시 인바운드 포트이고 9090은 컨트롤 인터페이스 포트입니다. 컨트롤 인터페이스는 HTTP 프록시 진입점이 아니므로 브라우저 프록시를 9090으로 지정해도 원하는 대로 작동하지 않습니다. 다음 명령은 프로세스를 종료하지 않고 조회만 합니다.

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'

포트에 연결된 PID와 프로그램 이름을 확인하고, 중복 실행 중인 클라이언트를 정상적으로 종료하세요.
7891로 변경한다면 시스템 프록시, 브라우저 확장 프로그램, 명령줄 프록시 설정도 함께 바꾸세요.
커널을 다시 시작해 바인딩 오류가 없는지 확인한 다음, 지정한 프록시 포트로 curl 테스트를 실행하세요.

connection refused는 포트 충돌과 다릅니다. 대상 포트에서 서비스를 수신하고 있지 않을 때 흔히 발생하는 연결 거부를 의미합니다. 거부된 주소가 127.0.0.1:7890이라면 로컬 커널을 먼저 확인하고, 노드 서버 주소라면 서버 포트와 서비스 상태를 점검하세요. 로컬 접속 문제를 해결하겠다며 수신 주소를 임의로 모든 네트워크 인터페이스로 확대하지 마세요.

규칙 미일치: 모드, 순서, 최종 아웃바운드를 확인하세요

Clash의 규칙 모드는 rules를 위에서 아래로 확인하며, 먼저 일치한 규칙이 정책을 결정합니다. 목록에 올바른 규칙이 있어도 실제로 적용된다는 보장은 없습니다. 전역 모드에서는 같은 규칙 목록을 순서대로 적용해 아웃바운드를 선택하지 않으므로, 문제를 점검하기 전에 현재 실행 모드를 확인하세요.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,수동 선택

이 예시는 설정에 ‘수동 선택’이라는 정책 그룹이 이미 정의되어 있다고 가정합니다. www.example.com에 접속하면 첫 번째 규칙이 적용되고, 다른 규칙과 일치하지 않는 요청은 마지막의 MATCH로 전달됩니다. MATCH를 첫 번째 규칙으로 두면 이후 규칙은 매칭될 기회가 없습니다.

네 가지 항목을 확인하세요

실제로 불러온 설정 확인: 구독 파일, 로컬에서 편집한 파일, 클라이언트가 실행 중인 설정이 서로 다를 수 있습니다. 편집기에서 저장만 한 것이 아니라 변경 사항이 적용되었는지 확인하세요.
도메인을 확인할 수 있는지 점검: 앱이 IP에 직접 연결하고 커널에서 도메인 정보를 복원하지 못하면 DOMAIN-SUFFIX 규칙이 적용되지 않을 수 있습니다. 스니핑이 도움이 될 수 있지만 모든 연결에서 도메인을 복원할 수 있는 것은 아닙니다.
룰셋 상태 확인: RULE-SET을 사용한다면 먼저 규칙 프로바이더가 다운로드되고 정상적으로 파싱되었는지 확인한 다음, 참조 이름과 규칙 순서를 점검하세요.
정책 그룹에서 실제로 선택된 항목 확인: 로그에 그룹 이름이 올바르게 표시되더라도 그룹 안에서 DIRECT나 다른 노드가 선택되면 예상과 다른 결과가 나올 수 있습니다.

규칙 변경을 테스트할 때는 새 연결을 만드세요. 기존에 열린 연결은 이전 아웃바운드를 계속 사용할 수 있으므로 페이지를 새로고침해도 모든 연결이 다시 만들어지는 것은 아닙니다. 테스트 앱을 종료했다가 다시 열거나, 영향 범위를 파악한 뒤 관련 연결을 닫을 수 있습니다. 전체 항목은 설정 전체 가이드에서, 구독 업데이트 방법은 구독 사용 안내에서 확인하세요.

TLS, 인증, TUN 오류: 서로 다른 네트워크 문제로 뭉뚱그리지 마세요

로그 단서	우선 확인할 항목	바로 시도하면 안 되는 조치
`x509: certificate has expired`	시스템 시간, 서버 인증서 유효 기간	인증서 검증을 바로 건너뛰기
`certificate is valid for`	연결 도메인, 인증서 이름, 노드 TLS 매개변수	로컬 프록시 포트만 변경하기
`authentication failed`	오류가 발생한 프로토콜, 계정 및 비밀번호, 구독 상태	DNS를 계속 바꾸기
`permission denied`	오류 전문에 나온 리소스 경로, 권한, 서비스 실행 상태	맥락을 확인하지 않고 설정 삭제하기

TLS 오류는 먼저 노드 핸드셰이크와 대상 웹사이트 핸드셰이크 중 어디에서 발생했는지 구분해야 합니다. 노드에서 TLS를 사용하는 경우 서버 주소, SNI, 인증서 이름이 서버 설정과 일치해야 합니다. 시스템 시간이 크게 어긋나도 인증에 실패할 수 있습니다. 인증서 검증을 끄면 보안 수준이 달라지므로 일반적인 해결 방법으로 사용하지 마세요.

TUN 오류는 가상 인터페이스 생성, 라우팅 설정, DNS 처리 단계에서 자주 발생합니다. Windows에서는 클라이언트 서비스 모드와 필요한 권한을 확인하고, Linux에서는 /dev/net/tun이 있는지와 프로세스 권한을 확인하세요. macOS에서는 클라이언트가 요구하는 시스템 권한을 살펴보세요. 설정 항목 이름은 클라이언트마다 다르므로 다른 클라이언트의 메뉴 경로를 그대로 따르지 마세요.

프록시 포트를 지정한 curl은 성공하지만 TUN을 켠 뒤에도 앱이 실패한다면 노드를 계속 바꾸기보다 라우팅, DNS 처리, 다른 VPN 또는 보안 소프트웨어와의 충돌을 중점적으로 확인하세요. 추가 설정은 TUN 설정 가이드를 참고하세요. TUN이 트래픽을 처리한다고 해서 모든 트래픽이 프록시를 통과하는 것은 아닙니다. 최종 경로는 실행 모드와 규칙에 따라 달라집니다.

마무리 점검: 같은 요청으로 해결 여부 확인

수정한 뒤 처음 기록한 URL로 다시 테스트하세요. 앱의 동작과 로그 경로를 함께 확인해야 복구 여부를 판단할 수 있습니다. 페이지가 완전히 로드되는지, 예상한 규칙과 노드가 선택되는지, 같은 오류가 반복되지 않는지 확인하세요. 노드 지연 시간 테스트에서 밀리초 값이 표시되는 것만으로는 DNS, 대상 사이트, 앱 프로토콜이 모두 정상이라는 뜻이 아닙니다.

커널이 시작되지 않음: 설정 문법, 포트, 권한 문제부터 해결하세요.
요청 로그가 없음: info 레벨에서 문제를 재현하고 시스템 프록시, 앱 자체 프록시, TUN 적용 범위를 확인하세요.
조회 오류 발생: 노드 도메인과 대상 도메인을 구분하고 시스템 DNS와 커널 DNS를 각각 테스트하세요.
연결 오류 발생: 오류 주소를 기준으로 로컬 진입점, 프록시 서버, 대상 서버를 구분하세요.
연결은 성공했지만 경로가 예상과 다름: 실행 모드, 규칙 순서, 정책 그룹 선택, 기존 연결을 확인하세요.
문제 해결 완료: 평소 사용하는 로그 레벨로 되돌리고 효과가 있었던 변경 사항과 재현 절차를 기록해 두세요.

유효한 문제 해결 기록에는 ‘어떤 요청이 어떤 규칙을 거쳐 어느 단계에서 실패했는지’가 담겨야 합니다. 이 순서대로 범위를 좁히면 설정을 한꺼번에 바꾸는 것보다 원인을 찾기 쉽고, 구독 업데이트나 클라이언트 업그레이드 후에도 다시 확인하기 편합니다.