Clash 실행 로그 보는 법: 자주 발생하는 오류와 단계별 진단

먼저 로그 출처와 실패 시각 확인하기

Clash 로그는 단순한 오류 목록이 아닙니다. 설정 불러오기, 포트 수신 대기, DNS 요청, 규칙 매칭, 아웃바운드 연결을 모두 기록합니다. 문제를 진단할 때는 세 가지부터 확인하세요. 요청이 코어에 들어왔는지, 어떤 정책으로 전달됐는지, 연결이 어느 단계에서 실패했는지입니다. 빨간 경고 한 줄만 보고 모든 노드를 바꾸면 포트 문제와 DNS 문제, 원격 서비스 장애를 혼동하기 쉽습니다.

이 문서는 Clash 또는 Clash Meta(현재 명칭 mihomo) 코어를 사용하는 클라이언트에 적용됩니다. 클라이언트와 코어 버전에 따라 로그 형식과 메뉴 이름이 다를 수 있습니다. 먼저 클라이언트의 ‘정보’ 화면에서 클라이언트 버전과 코어 버전을 확인한 다음 ‘로그’ 또는 ‘실행 로그’를 여세요. 구독 업데이트 로그, 클라이언트 UI 로그, 코어 실행 로그는 서로 다른 출처이므로 혼동하지 마세요.

실패가 발생한 현지 시각을 초 단위까지 기록하세요. 예: 14:32:10.
다운로드, 동영상 재생 등 지속적으로 네트워크를 사용하는 작업을 일시 중지하고, 화면의 이전 로그를 지운 다음 확인하려는 요청을 한 번만 실행하세요.
요청 전후 약 10초간의 로그를 보관하고 ‘연결’ 화면에서 대상 도메인, 대상 포트, 규칙, 실제 아웃바운드를 확인하세요.
현재 규칙, 전역, 직접 연결 중 어떤 모드인지와 시스템 프록시 및 TUN 활성화 여부를 기록하세요. 테스트할 때마다 한 항목만 변경하세요.

log-level 조정: 먼저 info, 필요할 때만 잠시 debug

일반적인 진단에는 info부터 사용하세요. 보통 연결 대상, 매칭된 규칙, 적용된 정책을 확인하기에 충분합니다. DNS 조회 과정, 정책 제공자 또는 연결 세부 정보가 불분명할 때만 잠시 debug로 전환하세요. silent는 로그를 끄므로 진단에 적합하지 않습니다. error나 warning은 성공한 연결과 규칙 정보를 생략할 수 있습니다.

설정 적용 여부 확인

클라이언트 설정에서 ‘로그 수준’을 찾으세요. 해당 항목이 없다면 클라이언트에서 지원하는 설정 편집 또는 오버라이드 기능을 통해 최상위 필드를 변경하세요. 아래는 코어 설정 값입니다. 경고 수준은 warning으로 입력해야 하며, UI의 약칭을 보고 설정 값을 추측하지 마세요.

# 최상위 설정; 진단이 끝나면 info로 복원
log-level: debug
mode: rule

저장한 뒤 클라이언트의 설정 다시 불러오기 기능을 사용하세요. 코어를 다시 시작해야 한다는 안내가 표시되면 그대로 따르고, 시작 과정에 오류가 없는지 확인하세요.
원격 구독을 업데이트하면 직접 편집한 내용이 덮어써질 수 있습니다. 클라이언트에서 지원하는 지속형 오버라이드 방식을 우선 사용하세요.
문제를 한 번 재현한 뒤 해당 시간대의 로그만 내보내면 됩니다. debug를 몇 시간씩 켜 둘 필요는 없습니다. 진단이 끝나면 info로 복원하세요.

디버그 로그에는 방문한 도메인, 로컬 주소, 노드 이름, 설정 경로가 포함될 수 있습니다. 외부에 제출하기 전에 구독 토큰, 인증 정보, 컨트롤 인터페이스 키, 개인 디렉터리 경로를 삭제하세요. 단, 오류 유형과 포트, 정책 간 관계는 진단에 필요한 단서이므로 비식별 처리 후에도 남겨 두세요.

연결 하나씩 대상, 규칙, 아웃바운드 확인하기

로그 전체의 첫 줄부터 추측하지 말고 대상 도메인이나 포트로 검색하세요. 웹페이지를 열면 메인 사이트 외에도 이미지, API, 분석 도메인에 요청이 동시에 발생할 수 있습니다. 따라서 실패 로그가 하나 있다고 해서 메인 페이지 연결이 실패한 것은 아닙니다. 아래는 단순화한 TCP 연결 예시입니다.

[TCP] 127.0.0.1:52144 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[Node-A]

필드	확인할 내용
`TCP` / `UDP`	전송 프로토콜을 구분하세요. 브라우저는 UDP 기반 HTTP/3을 사용할 수 있습니다.
`127.0.0.1:52144`	이 예시의 주소는 로컬 출발지와 임시 출발지 포트이며, 클라이언트의 프록시 수신 대기 포트가 아닙니다.
`www.example.com:443`	대상 호스트와 서비스 포트입니다. 이번 실패 작업과 관련된 대상인지 확인하세요.
`DomainSuffix`	매칭된 규칙 유형입니다. 규칙에 지정된 정책 이름도 확인하세요.
`Proxy[Node-A]`	예시 정책 그룹과 최종 노드입니다. 실제 로그에는 여러 단계의 정책 체인이 표시될 수 있습니다.

using DIRECT가 표시되면 규칙이 작동하지 않는다고 단정하지 말고, 먼저 예상한 경로인지 확인하세요. 연결 로그는 라우팅 선택을 보여 줄 뿐 원격 요청의 성공을 뜻하지 않습니다. 이후 오류, 연결 트래픽, 앱에서 나타난 결과도 함께 확인해야 합니다.

dial tcp timeout: 연결이 어느 구간에서 시간 초과됐는지 구분하기

dial tcp, i/o timeout, context deadline exceeded를 검색하면 보통 연결 또는 작업 대기 중 발생한 시간 초과를 확인할 수 있습니다. dial tcp는 TCP 연결 수립 단계를 가리키지만, 다른 시간 초과 문구는 DNS 조회, TLS 핸드셰이크, 프록시 프로토콜 통신 중에도 나타날 수 있습니다. 앞뒤에 표시된 대상 주소와 작업 설명을 반드시 확인하세요.

노드 주소와 웹사이트 주소부터 구분하기

프록시 노드 연결 시간 초과: 오류에 표시된 주소가 노드 서버와 노드 포트인지 확인하세요. 노드 도메인의 DNS 조회, 포트, 네트워크 연결 가능 여부, 구독 만료 여부를 점검한 뒤 같은 정책 그룹의 다른 사용 가능한 노드로 테스트하세요.
웹사이트 직접 연결 시간 초과: 연결 로그의 정책이 DIRECT이고 대상이 웹사이트 주소인지 확인하세요. 직접 연결 경로, 대상 서비스, 규칙 선택을 점검하고 노드 설정만 변경하지 마세요.
노드를 거친 뒤 웹사이트 접속 실패: 노드 연결은 수립됐지만 대상 요청이 실패한 상황입니다. 같은 노드로 다른 웹사이트에 접속해 보고, 같은 웹사이트를 다른 노드로 접속해 결과를 비교하면 문제가 대상 측인지 노드의 출구 경로인지 좁혀 볼 수 있습니다.

connection refused는 시간 초과와 다릅니다. 대상 포트에서 서비스가 대기 중이지 않는 경우처럼 연결이 명시적으로 거부됐을 수 있으며, 중간 장비가 거부했을 수도 있습니다. connection reset by peer는 연결이 초기화됐다는 뜻입니다. 이 문구 하나만으로 비밀번호 오류나 특정 네트워크 개입이라고 단정하지 마세요.

DNS 조회 실패: 두 가지 조회 경로 나눠 확인하기

DNS 오류는 적어도 ‘프록시 노드 도메인 조회 실패’와 ‘접속 대상 도메인 조회 실패’를 구분해야 합니다. 전자는 프록시 연결이 수립되기 전에 중단되는 원인이 될 수 있습니다. 후자는 현재 DNS 모드, 대상 도메인의 조회 경로, 업스트림 DNS 서버와 관련이 있습니다. 로그의 lookup, no such host, DNS resolve failed, 조회 시간 초과는 뒤에 표시된 도메인과 함께 확인하세요.

도메인 철자와 용도를 확인하세요. 실패한 도메인이 노드 서버 도메인이라면 노드 설정을 확인하고 해당 도메인이 여전히 유효한지 점검하세요.
오류 응답과 시간 초과를 구분하세요. no such host는 존재하지 않거나 사용 가능한 레코드가 없는 도메인에서 흔히 발생합니다. 조회 시간이 초과됐다면 업스트림 DNS 서버에 연결할 수 있는지, 전송 방식과 라우팅은 올바른지 확인하세요.
리졸버의 시작 의존성을 확인하세요. DoH 업스트림을 도메인으로 지정했다면 리졸버 자체의 도메인도 먼저 조회해야 합니다. mihomo의 default-nameserver, proxy-server-nameserver 등은 각각 용도가 다르므로 사용 중인 버전의 문서를 확인하세요. 주소를 임의로 서로 바꿔 사용하면 안 됩니다.
설정을 다시 불러온 뒤 새 연결을 만드세요. DNS 설정을 변경했다면 클라이언트에서 지원하는 방식으로 캐시를 지우거나 코어를 다시 시작하세요. 기존 연결도 앱에서 종료해 이전 결과가 판단에 영향을 주지 않도록 하세요.

Fake-IP 주소가 DNS 오류를 뜻하는 것은 아닙니다

Fake-IP를 사용하면 클라이언트가 앱에 설정된 주소 풀의 가상 주소를 반환할 수 있습니다. 흔한 예로 198.18.0.0/16 대역이 있습니다. 이 주소는 이후 연결을 도메인에 매핑하기 위한 것으로 웹사이트의 공인 IP 주소가 아닙니다. 이 주소가 보인다고 DNS 변조를 단정할 수는 없습니다. 해당 연결을 코어가 처리하는지, 도메인 매핑이 유효한지 확인하세요.

시스템 터미널에서 실행한 nslookup 결과가 코어에서 실제로 사용하는 조회 결과와 다를 수도 있습니다. 시스템 DNS, 브라우저의 보안 DNS, 코어 DNS, 원격 프록시의 DNS 조회는 서로 다른 경로를 사용할 수 있습니다. TUN 문제를 진단할 때는 설정에 enable: true가 입력돼 있는지만 보지 말고 DNS 가로채기와 라우팅이 실제로 적용됐는지 확인하세요.

규칙 미일치: 모드와 첫 번째 매칭 규칙부터 확인하기

규칙 모드에서는 규칙이 순서대로 적용되며 일반적으로 처음 매칭된 규칙이 아웃바운드를 결정합니다. 전역 모드에서는 일반 규칙 목록을 따라 각 연결의 정책을 선택하지 않고, 직접 연결 모드에서는 바로 연결합니다. 따라서 “도메인 규칙을 설정했는데 엉뚱한 노드를 사용한다”면 먼저 클라이언트가 rule 모드인지 확인하세요.

# 예시: Proxy는 설정에 존재하는 정책 이름이어야 합니다
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,DIRECT

이 예시에서는 example.com과 그 하위 도메인이 첫 번째 규칙에 매칭되고, 나머지 매칭되지 않은 연결은 MATCH,DIRECT로 처리됩니다. 더 넓은 범위를 다루는 규칙을 앞에 두면 뒤에 있는 세부 규칙이 매칭될 기회를 얻지 못할 수 있습니다. 확인할 때는 구독 원본 파일뿐 아니라 클라이언트에 최종 적용된 규칙도 살펴보세요.

로그에 IP만 표시됨: 앱이 코어의 DNS 조회를 우회하는지, 해당 연결에 도메인 정보가 남아 있는지 확인하세요. 도메인 규칙은 IP 주소만 보고 그 주소가 어떤 사이트에 속하는지 알아낼 수 없습니다.
최종 규칙에 매칭됨: 대상이 실제로 API 또는 CDN 하위 도메인인지 확인하고, 규칙 제공자가 정상적으로 로드됐는지와 업데이트 오류가 있었는지도 살펴보세요.
규칙은 맞지만 노드가 다름: 정책 그룹에서 현재 선택된 항목을 확인하세요. 자동 지연 테스트 그룹과 장애 조치 그룹은 각각의 로직에 따라 구성원을 선택할 수 있습니다.
변경 후에도 이전 정책으로 연결됨: 해당 연결을 종료한 다음 다시 시도하세요. 기존의 장시간 연결은 규칙을 다시 불러와도 즉시 새 경로로 라우팅되지 않을 수 있습니다.

mihomo의 도메인 스니핑은 지원되는 프로토콜과 설정 조건에서 도메인 정보를 보완할 수 있지만, 모든 암호화 연결에서 도메인을 알아낼 수 있는 것은 아닙니다. 스니핑 활성화를 모든 규칙 문제의 만능 해결책으로 여기지 마세요. 특정 사이트 때문에 모든 트래픽을 전역 모드로 계속 전환하는 것도 피해야 합니다.

연결 로그가 없을 때: 진입 포트와 트래픽 처리 방식 확인하기

앱에서는 오류가 나는데 코어에 관련 로그가 없다면 요청이 클라이언트에 들어왔는지부터 확인하세요. 시스템 프록시는 해당 설정을 따르는 앱에만 적용됩니다. 일부 명령줄 도구, 게임, 자체 프록시 설정이 있는 앱은 별도로 설정하거나 적절한 TUN으로 처리해야 합니다. 시스템 프록시를 활성화했다고 모든 TCP 및 UDP 트래픽이 코어를 거치는 것은 아닙니다.

프록시 진입점을 지정해 비교 테스트하기

로컬에서 실제 적용 중인 설정의 혼합 포트가 7890이라고 가정하면, 아래처럼 프록시를 명시해 요청할 수 있습니다. 이 포트는 예시이므로 반드시 클라이언트에 현재 표시된 수신 대기 포트로 바꾸세요. 포트가 0이거나 비활성화된 상태라면 그대로 사용할 수 없습니다.

curl -v --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

Windows PowerShell에서는 일부 환경의 명령 별칭 차이를 피하기 위해 명령 앞부분을 curl.exe로 바꿀 수 있습니다. 명령을 실행하면서 로그도 함께 확인하세요. 요청은 코어에 들어오지만 브라우저 요청은 들어오지 않는다면 브라우저 프록시 설정, 확장 프로그램, 연결 재사용을 먼저 점검하세요. 127.0.0.1:7890에 연결할 수 없다는 메시지가 바로 나타나면 코어 실행 여부, 포트 번호, 수신 대기 상태를 확인하세요.

address already in use: 수신 주소나 포트가 이미 사용 중입니다. 프록시 클라이언트 두 개가 동시에 실행 중인지 확인하고, 충돌하는 서비스를 중지하거나 수신 포트를 변경한 뒤 진입점 설정도 함께 업데이트하세요.
permission denied / operation not permitted: 로그의 앞뒤 내용을 확인해 TUN, 라우팅 작업 또는 파일 접근 권한 문제인지 살펴보고, 클라이언트 안내에 따라 필요한 권한을 부여하세요.
authentication failed: 오류가 로컬 진입점 인증, 프록시 노드 인증, 구독 다운로드 인증 중 어느 단계에서 발생했는지 확인하세요. 각 단계의 인증 정보를 혼용하지 마세요.
TUN 시작 실패: 가상 네트워크 어댑터 생성, 라우트 설치, 권한 확인 과정에서 발생한 첫 오류를 살펴보세요. 다른 VPN이 라우팅을 변경하는 상황에서 무작정 테스트를 계속하지 마세요.

이 curl 테스트는 프록시를 명시한 HTTP 진입점과 해당 요청 경로를 주로 확인합니다. 이 결과만으로 TUN, UDP 또는 모든 앱이 정상이라고 판단할 수는 없습니다. 클라이언트에 TUN 자동 라우팅 등의 설정이 있다면 실제 라우팅 상태도 함께 확인하세요.

재현 절차와 진단 기록을 일정하게 유지하기

유용한 장애 기록은 빨간 글씨 수십 줄이 담긴 스크린샷만 제공하는 것이 아니라, 다른 담당자가 같은 작업을 다시 수행할 수 있게 해 줍니다. 아래 순서대로 한 차례 진단하고, 각 단계를 확인한 뒤 다음 단계로 넘어가세요.

코어 시작: 설정이 정상적으로 불러와졌는지, 필요한 포트가 수신 대기 중인지, 코어가 계속 재시작되지는 않는지 확인하세요.
요청 유입: 프록시를 명시한 테스트나 앱의 연결 기록으로 대상 요청이 코어에 보이는지 확인하세요.
DNS 조회 완료: 노드 도메인과 대상 도메인을 구분해 DNS 단계에서 실패한 것이 아닌지 확인하세요.
예상한 라우팅: 매칭된 규칙, 정책 그룹, 최종 노드를 기록하고 필요하면 기존 연결을 종료한 뒤 다시 테스트하세요.
아웃바운드 비교: 같은 대상에 다른 노드를 사용하고, 같은 노드로 다른 대상을 테스트하세요. 한 번에 조건 하나만 변경하세요.
설정 복원: debug를 info로 되돌리고 진단용 임시 규칙을 제거한 뒤, 자주 사용하는 앱의 연결 상태를 확인하세요.

문제를 신고할 때 함께 제공할 정보

운영체제 버전, 클라이언트와 코어의 전체 버전, 사용한 프록시 진입점과 포트, 아웃바운드 모드, TUN 상태, 실패 시각, 비식별 처리한 관련 로그를 기록하세요. “브라우저에서 도메인 접속은 실패하지만 프록시를 명시한 curl은 성공”처럼 설명하면 “갑자기 네트워크가 안 돼요”보다 원인을 찾기 쉽습니다. “노드 하나만 실패하고 같은 그룹의 다른 노드는 성공”이라고 덧붙이면 노드 설정이나 노드의 네트워크 경로까지 범위를 좁힐 수 있습니다.

연결이 수립된 로그가 있는데도 앱에서 인증서, 로그인, HTTP 상태 오류가 발생한다면 애플리케이션 계층을 추가로 확인하세요. 시스템 시각 오류, 서버가 반환한 403, 계정 상태, 인증서 신뢰 문제는 규칙 순서를 바꿔 해결할 수 없습니다. 진단의 목표는 문제가 발생한 계층을 확인하고 같은 작업을 한 번 더 수행해 해결 여부를 검증하는 것입니다. 로그 화면에서 경고를 모두 없애는 것이 목표는 아닙니다.