Clash 실행 로그 보는 법: 자주 발생하는 오류 의미와 문제 해결 절차

먼저 로그가 어느 연결 구간을 기록하는지 확인하기

Clash, Clash Meta（mihomo）와 그래픽 클라이언트는 일반적으로 시스템 프록시, DNS, 규칙 매칭, 노드 연결, TUN 전달 및 구독 업데이트를 동시에 처리합니다. 로그에 error가 표시되었다고 해서 클라이언트 전체가 작동을 멈춘 것은 아닙니다. 한 연결이 실패했다고 해서 현재 노드를 완전히 사용할 수 없는 것도 아닙니다. 문제를 찾을 때는 먼저 오류가 어느 계층에 속하는지 확인한 다음 해당 설정을 점검해야 합니다.

일반적인 연결 로그에는 시간, 로그 레벨, 인바운드 유형, 대상 주소, 매칭된 규칙, 정책 그룹, 실제 노드와 오류 메시지가 포함됩니다. 클라이언트마다 표시 순서는 조금씩 다르지만 핵심 정보는 같습니다. 예를 들면 다음과 같습니다.

20:14:08 INF [TCP] 127.0.0.1:53142
--> api.example.com:443
match DomainSuffix(example.com)
using Proxy[HK-01]

20:14:13 ERR dial HK-01
198.51.100.20:443
dial tcp 198.51.100.20:443: i/o timeout

이 기록은 로컬 프로그램이 127.0.0.1에서 TCP 요청을 시작했고 대상이 api.example.com:443임을 보여 줍니다. 도메인은 접미사 규칙과 일치했으며 정책 그룹은 HK-01을 선택했습니다. 이후 Clash가 노드 서버 198.51.100.20:443에 연결하는 과정에서 시간 초과가 발생했습니다. 문제는 “로컬 장치에서 노드 서버까지”의 구간에 있으며, 대상 웹사이트가 접속을 거부한 것이 아닙니다.

로그에서 다음 다섯 가지 정보를 우선 확인하기

1. 발생 시각: 오류가 방금 수행한 작업과 일치하는지 확인합니다. 먼저 한 번 재현한 뒤 같은 분 안에 기록된 로그를 확인하세요.
2. 프로토콜 및 인바운드: TCP, UDP, HTTP, SOCKS 또는 TUN인지 확인합니다. 일부 문제는 UDP에만 영향을 주므로 웹페이지는 정상적으로 열릴 수 있습니다.
3. 대상 주소: 로그의 도메인 또는 IP가 노드 서버, 구독 주소, DNS 서버 또는 최종 웹사이트 중 무엇인지 확인합니다.
4. 규칙 및 정책: 어떤 규칙과 일치했는지, 정책 그룹이 최종적으로 DIRECT, REJECT 또는 특정 노드를 선택했는지 확인합니다.
5. 오류의 마지막 부분: Go 네트워크 오류는 보통 가장 구체적인 원인을 마지막에 표시합니다. 예를 들어 i/o timeout, connection refused 또는 no such host가 있습니다.

info, warning, error는 각각 무엇을 의미할까

로그 레벨은 이벤트의 심각도를 나타내며 처리 우선순위와 직접 일치하지는 않습니다. 백그라운드 상태 확인에서 발생한 error가 예비 노드 하나에만 영향을 줄 수 있고, info 레벨의 규칙 기록이 현재 웹사이트가 REJECT 규칙에 의해 차단되었음을 직접 보여 줄 수도 있습니다. 레벨은 대상 주소와 정책 결과를 함께 확인해야 합니다.

정상적인 로그에도 실패 기록은 나타날 수 있습니다

브라우저는 IPv4, IPv6, HTTP/3 및 일반 HTTPS를 동시에 시도할 수 있습니다. 한 경로의 연결이 실패하면 브라우저가 즉시 다른 경로로 전환할 수 있으므로 페이지는 계속 열릴 수 있습니다. 노드 상태 확인도 일정한 간격으로 테스트 주소에 접속합니다. 특정 노드에서 시간 초과가 발생했다는 것은 해당 확인이 완료되지 않았다는 뜻일 뿐, 현재 사용 중인 노드의 연결이 끊겼다는 의미는 아닙니다.

처리할 필요가 있는지 판단하려면 세 가지 신호를 확인하세요. 같은 오류가 연속해서 발생하는지, 오류의 대상이 실제로 접속할 수 없는 서비스인지, 노드를 바꾸거나 특정 기능을 끈 직후 오류가 사라지는지입니다. 한 번만 발생하고 눈에 띄는 영향이 없는 백그라운드 오류는 우선 기록만 해 두고 여러 설정을 동시에 변경하지 않아도 됩니다.

dial tcp timeout: 제한 시간 안에 연결이 완료되지 않음

dial tcp ...: i/o timeout은 제한 시간 안에 TCP 연결이 수립되지 않았다는 뜻입니다. 오류에 표시된 주소가 노드 서버 IP라면 로컬 장치에서 노드까지의 네트워크를 우선 확인하고, 최종 웹사이트 주소라면 프록시 노드에서 대상 사이트까지의 경로를 확인하세요. timeout은 포트가 명확하게 거부된 경우와 다릅니다. 원격 측이 제한 시간 안에 사용할 수 있는 응답을 보내지 않은 상황입니다.

일반적인 원인

• 노드 서버가 일시적으로 오프라인이거나 노드 포트가 변경되었습니다.
• 현재 Wi-Fi, 모바일 네트워크 또는 상위 라우터에서 해당 서버에 도달할 수 없습니다.
• 방화벽이 특정 포트의 트래픽을 폐기하고 있습니다.
• IPv6 경로를 사용할 수 없지만 노드 도메인이 AAAA 레코드로 우선 조회됩니다.
• TUN 인터페이스 라우팅에 루프가 발생해 노드 연결이 다시 Clash로 전달됩니다.
• 노드에는 연결되지만 TLS 핸드셰이크 또는 이후 전송이 계속 시간 초과됩니다.

순서대로 네 가지를 비교 테스트하기

1. 클라이언트의 노드 목록에서 다른 노드로 전환한 뒤 같은 요청을 다시 실행하세요. 새 노드가 정상이라면 문제는 기존 노드 또는 해당 노드의 경로에 집중됩니다.
2. 네트워크를 바꿔 보세요. 예를 들어 가정용 Wi-Fi에서 휴대폰 핫스팟으로 전환합니다. 같은 노드가 다시 정상 작동한다면 라우터, 방화벽 및 현재 통신사 회선을 확인하세요.
3. TUN을 잠시 끄고 시스템 프록시만 유지한 뒤 같은 주소에 접속하세요. 시스템 프록시는 정상인데 TUN에서만 시간 초과가 발생한다면 라우팅, DNS 가로채기 및 인터페이스 선택을 중점적으로 확인합니다.
4. 시간 초과가 발생한 주소를 확인하세요. 노드 IP 시간 초과와 대상 도메인 시간 초과는 서로 다른 경로이므로 웹사이트 이름만 보고 판단하지 마세요.

Clash에서 자주 사용하는 로컬 프록시 포트로는 HTTP 포트 7890과 SOCKS 포트 7891이 있으며, mixed-port: 7890을 사용할 수도 있습니다. 이 숫자는 설정에 따라 변경될 수 있습니다. 문제를 확인하기 전에 클라이언트의 「설정」→「포트 설정」 또는 「설정」→「매개변수 설정」에서 실제 값을 확인하고, 시스템 프록시가 같은 포트를 사용하는지 점검하세요.

connection refused: 주소에는 도달했지만 포트가 연결을 거부함

connect: connection refused 또는 dial tcp ...: connect: connection refused는 일반적으로 데이터가 대상 호스트에 도달했지만 지정된 포트에서 서비스를 수신 대기 중인 프로세스가 없거나 방화벽이 적극적으로 거부 응답을 보냈다는 뜻입니다. timeout보다 빠르게 나타나는 경우가 많습니다.

ERR dial tcp 127.0.0.1:7890:
connect: connection refused

ERR dial tcp 203.0.113.8:443:
connect: connection refused

첫 번째 주소가 127.0.0.1:7890이라면 로컬 앱이 로컬 프록시 포트에 연결을 시도했지만 해당 포트에서 수신 대기 중인 서비스가 없다는 뜻입니다. Clash 코어가 시작되지 않았거나 포트가 다른 값으로 변경되었거나 클라이언트에서 SOCKS 포트만 활성화했을 수 있습니다. 두 번째 주소가 원격 IP라면 일반적으로 노드 포트 설정 오류, 노드 서비스 중지 또는 서버 방화벽의 적극적인 거부가 원인입니다.

로컬 포트 거부 시 확인할 위치

• 클라이언트 상태 페이지에서 코어가 실행 중인지, 시작 실패 상태에 머물러 있지 않은지 확인합니다.
• 「설정」→「포트 설정」으로 이동해 HTTP, SOCKS 및 Mixed Port의 실제 숫자를 확인합니다.
• 브라우저 또는 앱의 수동 프록시 설정에서 주소를 127.0.0.1로 지정하고 포트를 Clash가 현재 수신 대기 중인 값과 일치시킵니다.
• 설정에 mixed-port: 7890이 있다면 HTTP와 SOCKS 클라이언트 모두 해당 포트에 연결할 수 있습니다. 7891이 반드시 활성화되어 있다고 가정하지 마세요.
• 로그 앞부분에 bind: address already in use가 표시되는지 확인하세요. 다른 프로세스가 포트를 사용 중이어서 코어가 수신 대기할 수 없다는 뜻입니다.

원격 포트가 연결을 거부할 때의 처리 방법

먼저 구독을 업데이트한 뒤 노드 서버 주소와 포트가 변경되었는지 확인하세요. 하나의 노드에서만 오류가 발생하면 노드를 바꾸고 해당 항목을 기록합니다. 같은 구독의 모든 노드가 거부된다면 구독 만료 여부, 설정이 이전 서버를 계속 참조하는지, 네트워크가 투명 게이트웨이를 통해 연결을 변조하는지 확인하세요.

DNS 조회 실패: 도메인 문제와 연결 문제를 먼저 구분하기

자주 발생하는 DNS 오류로는 no such host, DNS request failed, server misbehaving, context deadline exceeded가 있습니다. DNS 실패는 도메인을 IP로 변환하는 단계에서 발생합니다. 로그에 198.51.100.20:443처럼 명확한 IP에 연결 중이라고 이미 표시되었다면, 이후의 timeout은 일반적으로 해당 연결의 도메인 조회 실패가 아닙니다.

세 가지 DNS 장애를 나누어 처리하기

mihomo의 DNS 설정에서는 노드 도메인 조회에 사용할 기본 서버와 일반 조회를 처리할 nameserver를 구분할 수 있습니다. 다음은 구조를 이해하기 위한 간단한 예시이며, 실제 주소는 현재 네트워크 환경에 맞게 조정해야 합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

default-nameserver에는 IP 주소를 사용하며, 주로 DoH 서버 또는 프록시 노드 자체의 도메인을 조회하는 데 사용합니다. “DNS 서버를 조회하려면 먼저 DNS 서버를 조회해야 하는” 의존성 루프를 피하기 위한 설정입니다. listen: 0.0.0.0:1053은 Clash DNS의 수신 주소이며, 시스템이 모든 조회를 자동으로 해당 포트로 보낸다는 뜻은 아닙니다. TUN 모드에서는 일반적으로 DNS 가로채기 설정도 필요합니다.

Fake-IP 모드에서 나타나는 특수한 현상

Fake-IP는 앱에 매핑된 주소를 반환하고 Clash 내부에는 원래 도메인을 유지하여 규칙 매칭에 사용합니다. 로그에 198.18.0.0/16 범위의 주소가 보인다면 일반적으로 매핑 결과이므로 실제 웹사이트 서버로 보면 안 됩니다. 특정 LAN 장치, 게임 또는 기업용 앱이 Fake-IP와 호환되지 않는다면 도메인별 필터를 설정하거나 redir-host 모드와 비교 테스트를 진행하세요. 매핑 주소가 나타났다는 이유만으로 DNS가 손상되었다고 판단하지 마세요.

TLS, EOF 및 context deadline exceeded 확인 방법

TLS handshake timeout

TLS handshake timeout은 TCP 연결은 이미 수립되었을 수 있지만 제한 시간 안에 TLS 핸드셰이크가 완료되지 않았다는 뜻입니다. 일반적인 원인은 패킷 손실, 노드 과부하, 중간 장비의 간섭 및 부적절한 MTU입니다. 먼저 노드와 네트워크를 바꿔 보세요. TUN에서만 발생한다면 일반적인 1500에서 1400 또는 1280으로 MTU를 조정해 한 번에 하나씩 테스트할 수 있습니다. MTU, DNS와 프록시 프로토콜을 동시에 바꾸면 어떤 항목이 효과를 냈는지 판단할 수 없으므로 피하세요.

x509 certificate 오류

x509: certificate has expired는 인증서가 만료되었다는 뜻입니다. x509: certificate is valid for ...는 인증서 도메인과 연결 대상이 일치하지 않는다는 뜻이고, certificate signed by unknown authority는 현재 환경이 인증서 체인을 신뢰하지 않는다는 뜻입니다. 먼저 시스템 날짜, 시간 및 시간대가 정확한지 확인한 다음 노드 도메인, SNI 또는 server name 설정을 점검하세요. 인증서 검증을 무작정 끄면 설정 오류를 가릴 수 있으므로 장기적인 해결 방법으로 적합하지 않습니다.

EOF 및 unexpected EOF

EOF는 연결 상대가 데이터 스트림을 종료했다는 뜻입니다. 한 번 발생한 EOF는 서비스가 정상적으로 연결을 종료한 결과일 수 있지만, 매 요청마다 같은 단계에서 발생한다면 프로토콜 매개변수, 노드 서비스 상태 또는 중간 네트워크 장비를 확인해야 합니다. unexpected EOF는 예상한 데이터 읽기가 끝나기 전에 연결이 중단되었다는 의미가 더 강합니다. 노드를 바꿔 보는 것이 가장 빠른 비교 방법입니다.

context deadline exceeded

이는 일반적인 작업 시간 초과 안내만 보여 주므로, 이것만으로는 DNS, 노드 다이얼, 상태 확인 또는 구독 다운로드 중 어디에서 발생했는지 알 수 없습니다. 같은 줄 앞부분의 작업 이름과 앞뒤 5~10줄의 로그를 확인해야 합니다. proxy provider 직후에 나타나면 구독 또는 provider 업데이트 시간 초과일 가능성이 높고, DNS 요청 직후라면 상위 DNS를 확인해야 하며, 노드 주소 뒤에 나타나면 연결 시간 초과로 처리하세요.

포트 점유, 설정 오류 및 코어 시작 실패

로그 창에 몇 줄만 표시된 뒤 클라이언트가 중지된다면 문제는 대개 노드 품질이 아니라 코어가 시작을 완료하지 못한 데 있습니다. 설정 구문 오류와 수신 포트 충돌이 가장 흔한 두 가지 원인입니다.

address already in use

listen tcp 127.0.0.1:7890:
bind: address already in use

이미 다른 프로세스가 7890을 사용 중이라는 뜻입니다. 다른 프록시 클라이언트, 이전에 종료되지 않은 코어 프로세스 또는 로컬 개발 서비스가 원인일 수 있습니다. 먼저 다른 프록시 프로그램을 완전히 종료한 뒤 클라이언트를 다시 시작하세요. 그래도 충돌이 계속되면 「설정」→「포트 설정」에서 Mixed Port를 임시로 7892로 바꾸고 시스템 프록시 포트도 같은 숫자로 변경합니다. Clash 포트만 바꾸고 시스템 프록시를 갱신하지 않으면 브라우저가 계속 이전 포트에 접속해 connection refused가 발생합니다.

설정 파싱 오류

YAML은 들여쓰기와 데이터 형식에 민감합니다. 로그에 yaml: line 42: did not find expected key처럼 구체적인 줄 번호가 표시될 수 있습니다. 먼저 해당 줄과 바로 윗줄을 확인하고, 들여쓰기에 공백을 사용했는지, 콜론 뒤에 공백이 있는지, 목록 항목이 -으로 시작하는지 점검하세요. 정책 그룹에서 참조하는 노드 이름도 실제 이름과 일치해야 합니다.

mixed-port: 7890
mode: rule

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - HK-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,Proxy

구독 업데이트 직후 시작에 실패한다면 먼저 클라이언트의 「설정」→「프로필」에서 이전에 정상 작동하던 설정으로 되돌린 뒤 새 설정의 구문을 검사하세요. 문제가 확인되지 않은 설정을 한 번에 여러 곳 수정하지 마세요. 한 번에 하나만 변경하고 저장, 다시 로드한 뒤 첫 번째 error를 확인합니다.

TUN 모드 로그에서 중점적으로 확인할 부분

TUN 모드는 시스템 프록시보다 더 넓은 범위의 트래픽을 처리하므로 UDP, LAN, 시스템 서비스와 프록시 설정을 따르지 않는 앱의 연결까지 로그에 나타납니다. TUN을 켠 뒤 로그 양이 크게 늘어나는 것은 정상입니다. 실제로 주의할 항목은 지속적인 재시도, 라우팅 루프, 인터페이스 생성 실패 및 DNS 가로채기 오류입니다.

일반적인 TUN 문제

• operation not permitted: 인터페이스 생성 또는 라우팅 변경에 필요한 권한이 부족합니다. 클라이언트 권한과 TUN 서비스 설치 상태를 확인하세요.
• network is unreachable: 현재 라우팅 테이블에 대상까지 연결할 수 있는 경로가 없습니다. 사용할 수 없는 IPv6 또는 잘못된 인터페이스 선택에서 흔히 발생합니다.
• device or resource busy: TUN 장치를 다른 인스턴스 또는 다른 VPN이 사용 중입니다.
• 연결 루프: 노드 서버 트래픽이 다시 TUN으로 들어가 로그에 같은 대상이 빠르게 반복됩니다. 자동 라우팅, 인터페이스 감지 및 노드 주소 제외 로직을 확인하세요.
• UDP timeout: 게임, 음성 통화 또는 QUIC에만 영향을 줄 수 있으며 일반 TCP 웹페이지에는 영향을 주지 않을 수 있습니다.

시스템 프록시와 TUN을 나누어 테스트하기

1. 현재 설정을 기록하고 규칙 모드, 노드 및 DNS 설정이 변하지 않았는지 확인합니다.
2. TUN을 끄고 시스템 프록시만 켠 상태에서 브라우저와 구독 업데이트를 테스트합니다.
3. TUN을 다시 켜고 시스템 프록시를 끈 다음 같은 대상에 접속해 테스트합니다.
4. TUN에서만 실패한다면 인터페이스 권한, 자동 라우팅, MTU, DNS 가로채기 및 다른 VPN을 확인합니다.
5. 두 모드 모두 실패한다면 노드, DNS, 규칙 및 로컬 포트를 다시 점검합니다.

Android에서는 시스템 VPN 권한을 다른 VPN 앱이 사용하고 있지 않은지 확인하고, 시스템 「설정」→「앱」→「Clash 클라이언트」→「배터리」에서 필요한 백그라운드 실행 정책을 허용하세요. Windows에서 TUN 인터페이스 생성에 실패하면 클라이언트 서비스 모드 또는 관리자 권한을 확인해야 합니다. macOS에서는 시스템 설정의 네트워크 확장 권한 상태를 확인하세요.

규칙은 올바르게 매칭되지만 웹사이트에 접속할 수 없음

로그에 match, using 또는 규칙 이름이 표시되는 것은 Clash가 정책을 선택했다는 뜻일 뿐, 이후 연결이 성공했다는 의미는 아닙니다. 같은 연결 뒤에 dial, TLS 또는 DNS 오류가 이어지는지 계속 확인해야 합니다.

먼저 정책 결과를 확인하기

• DIRECT에 매칭됨: 프록시를 거치지 않고 연결합니다. 대상에 노드 연결이 필요하다면 규칙 순서와 도메인 매칭 방식을 확인하세요.
• REJECT에 매칭됨: Clash가 규칙에 따라 연결을 적극적으로 차단합니다. 광고 필터 또는 사용자 지정 규칙이 잘못 매칭되었는지 확인하세요.
• 정책 그룹에 매칭됨: 그룹 이름만 보지 말고 정책 그룹에서 실제로 선택된 노드를 확인하세요.
• MATCH에 매칭됨: 앞의 구체적인 규칙과 일치하지 않아 최종 기본 정책으로 들어갔습니다.

Clash 규칙은 위에서 아래 순서로 매칭되며, 일반적으로 처음 일치한 뒤에는 추가 검사를 중단합니다. 구체적인 도메인 규칙은 범위가 넓은 규칙보다 앞에 배치하고 MATCH는 마지막 기본 규칙으로 사용하세요. 예를 들면 다음과 같습니다.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

MATCH,DIRECT가 목록 앞부분에 있으면 뒤의 도메인 규칙은 예상대로 실행되지 않습니다. 수정한 뒤 설정을 다시 로드하고 새 연결이 대상 규칙과 매칭되는지 로그에서 확인하세요. 이미 수립된 연결은 기존 정책을 계속 사용할 수 있으므로 테스트할 때 해당 앱을 종료하거나 기존 연결이 끝날 때까지 기다려야 합니다.

반복해서 실행할 수 있는 로그 문제 해결 절차

효율적인 문제 해결은 설정, 노드, DNS와 네트워크를 동시에 바꾸는 것이 아니라 비교 테스트에 달려 있습니다. 다음 절차는 웹페이지 접속 불가, 구독 업데이트 실패, 노드 속도 테스트 시간 초과 및 TUN 네트워크 불가와 같은 일반적인 문제에 사용할 수 있습니다.

1. 환경 기록: 클라이언트 버전, 코어 유형, 현재 네트워크, 프록시 모드, TUN 활성화 여부 및 실제 수신 포트를 기록합니다.
2. 로그 비우기: 「로그」 또는 「설정」→「로그」로 이동해 레벨을 info로 설정하고, 더 자세한 정보가 필요할 때만 일시적으로 debug로 전환합니다.
3. 한 번만 재현: 명확한 작업 하나를 실행하고 정확한 시각을 기록합니다.
4. 대상 찾기: 도메인, IP, 포트 또는 정책 그룹 이름으로 기록을 필터링합니다.
5. 계층 확인: 실패가 로컬 포트, DNS, 규칙, 노드 다이얼, TLS, 대상 서비스 또는 TUN 라우팅 중 어디에서 발생했는지 판단합니다.
6. 한 번 비교: 노드, 네트워크, TUN 상태 또는 DNS 상위 서버처럼 변수 하나만 변경합니다.
7. 결과 검증: 로그를 다시 비우고 재현하여 기존 오류가 사라졌으며 새로운 오류로 바뀌지 않았는지 확인합니다.

로그를 제출하기 전에 정리해야 할 정보

클라이언트 유지 관리자, 구독 제공업체 또는 네트워크 관리자에게 문의할 때는 “연결 실패” 화면 한 장보다 전체 환경 정보가 훨씬 유용합니다. 클라이언트 이름과 버전, mihomo 코어 버전, 운영체제 버전, 프록시 모드, TUN 상태, 장애 발생 시각, 재현 단계 및 관련 로그 일부를 함께 제공하는 것이 좋습니다.

로그에는 접속 도메인, 노드 이름, 서버 IP, 로컬 LAN 주소 및 설정 경로가 포함될 수 있습니다. 공유하기 전에 구독 URL, 인증 정보, 사용자 이름, 비밀번호와 액세스 토큰을 숨기세요. 오류 전후의 맥락을 모두 삭제하지 말고 대상 연결 전후 10~20줄을 남기면 일반적으로 규칙 선택과 실패 단계를 판단하기에 충분합니다.

문의에 적합한 간단한 형식

클라이언트: 이름 및 버전
코어: mihomo 버전
시스템: 운영체제 이름 및 버전
모드: Rule / TUN 활성화
포트: mixed-port 7890
현상: 브라우저에서 지정한 도메인 접속 시 시간 초과
시간: 20:14:08
비교: 노드를 바꾼 뒤 복구됨
오류: dial tcp ...: i/o timeout

로그 문제 해결의 핵심은 먼저 연결 단계를 식별한 뒤 변수 하나만 비교하는 것입니다. timeout은 제때 완료되지 않았음을, refused는 포트가 명확하게 거부했음을 가리키며, DNS 오류는 도메인 조회 단계에서 발생합니다. 규칙 로그는 정책 선택만 보여 주고 TUN 오류는 권한과 라우팅을 추가로 확인해야 합니다. “로컬 앱 → Clash 인바운드 → DNS 및 규칙 → 노드 → 대상 서비스” 경로를 따라 각 구간을 검증하면 대개 문제를 조작 가능한 설정 항목이나 네트워크 구간 하나로 좁힐 수 있습니다.