상황을 먼저 기록하세요: 로그 시간, 요청 대상, 실제 사용 중인 코어

Clash에 ‘연결됨’이라고 표시되어도 보통 코어가 실행 중이거나 로컬 프록시가 활성화되었다는 뜻일 뿐, 모든 사이트에 연결된다는 의미는 아닙니다. 원인을 찾으려면 요청 경로를 따라가며 앱이 프록시를 사용하는지, 도메인이 조회되는지, 어떤 규칙과 정책이 적용되는지, 노드에 연결되는지, 원격 서버가 응답하는지 확인해야 합니다.

Clash, Clash Meta(현재는 보통 mihomo 코어로 유지 관리)와 각 GUI 클라이언트는 로그 형식이 조금씩 다릅니다. 아래 내용은 필드와 오류 메시지의 예시이며, 특정 버전의 로그를 그대로 옮긴 것이 아닙니다. 먼저 클라이언트의 ‘정보’ 또는 코어 정보 화면에서 코어 이름과 버전을 확인하고, 해당 코어의 설정 안내에 따라 점검하세요. GUI 클라이언트 버전만 기록해서는 안 됩니다.

  1. 재현 시간을 기록하세요: 14:32:10처럼 초 단위까지 적습니다. 로그 화면을 지우기 전에 중요한 오류를 저장하세요.
  2. 요청 범위를 좁히세요: 다운로드와 백그라운드 업데이트를 일시 중지하고 문제가 생긴 사이트 하나만 열어 여러 연결이 한꺼번에 섞이지 않게 하세요.
  3. 환경을 기록하세요: 운영체제, 클라이언트와 코어 버전, 규칙 또는 전역 모드, 시스템 프록시와 TUN 설정, 현재 정책 그룹과 노드를 적어 두세요.
  4. 한 번에 하나만 변경하세요: 설정을 바꿀 때마다 새 요청을 보내 같은 대상의 결과를 비교하세요. DNS, 노드, 규칙을 동시에 바꾸지 마세요.

로그 레벨 설정: 평소에는 info, 재현할 때만 잠시 debug

클라이언트 사이드바의 ‘로그’ 또는 ‘실행 로그’에서 출력 내용을 확인하세요. 로그 레벨 설정 메뉴의 이름과 위치는 클라이언트마다 다르며 설정이나 코어 설정에 있을 수 있습니다. 화면의 로그 필터가 코어 출력 레벨을 바꾸는 것은 아닙니다. ‘디버그’만 필터링해도 코어가 생성하지 않은 로그를 볼 수는 없습니다.

Clash와 mihomo에서 흔히 사용하는 최상위 설정 키는 log-level이며, silent, error, warning, info, debug를 지원합니다. 아래는 현재 설정에 합쳐야 하는 설정 예시이며, 단독으로 사용할 수 있는 구독 파일이 아닙니다:

# 최상위 필드이며 mode, rules와 같은 수준
log-level: debug

저장한 뒤 클라이언트 안내에 따라 설정을 다시 불러오거나 코어를 재시작하고, 새 설정이 적용되었는지 확인하세요. 구독 업데이트 시 직접 수정한 내용이 덮어써질 수 있습니다. 클라이언트에서 오버라이드나 설정 병합을 지원한다면 해당 기능을 우선 사용하세요. 문제를 재현한 뒤에는 info로 되돌리고, 디버그 로그를 계속 켜 두지 마세요.

연결 로그 읽기: 대상부터 확인한 뒤 규칙과 아웃바운드 확인

한 로그에 출발지 주소, 대상 도메인, 매칭된 규칙, 정책 그룹, 최종 노드, 오류 원인이 함께 표시될 수 있습니다. 읽는 순서가 중요합니다. 오류 직전의 DIRECT 또는 프록시 노드 이름을 확인하면 다음에 점검할 연결 구간을 파악할 수 있습니다.

# 필드 예시이며 고정된 로그 형식이 아닙니다
[TCP] 127.0.0.1:53124 --> example.com:443
match DomainSuffix(example.com)
using Proxy[노드 A]
error: dial tcp 203.0.113.10:443: i/o timeout

여기서 53124는 앱이 이번 연결에 사용한 임시 출발지 포트이며, 시스템 프록시에 입력할 리스닝 포트가 아닙니다. example.com:443은 요청 대상이고 Proxy는 정책 이름입니다. 예시의 문서용 예약 주소 203.0.113.10은 설명을 위한 것으로 연결 테스트에 사용할 수 없습니다.

로그 단서먼저 확인할 사항관련 설정 또는 메뉴
새 연결 로그가 전혀 없음요청이 로컬 프록시로 들어왔는지시스템 프록시, mixed-port, TUN, 앱 설정
대상 도메인 조회 실패어느 조회 단계에서 실패했는지dns, 노드 도메인 조회, 시스템 리졸버
DIRECT로 매칭됨예상한 분기 동작인지mode, rules, 규칙 세트
프록시를 거친 뒤 시간 초과노드 연결인지 최종 대상 연결인지proxies, proxy-groups, 노드 서버 상태
리스닝 포트 시작 실패포트가 이미 사용 중인지mixed-port, port, socks-port, 제어 포트

dial timeout: 노드 연결 시간 초과와 대상 연결 시간 초과 구분하기

dial timeout, i/o timeout, context deadline exceeded는 작업이 제한 시간 안에 완료되지 않았다는 뜻이지만, ‘시간 초과’만으로 DNS 문제라고 단정할 수는 없습니다. 같은 줄의 주소와 앞뒤 로그를 확인하세요. 노드 서버 주소에서 실패했다면 먼저 로컬 장치와 노드 사이의 연결을 점검하고, 직접 연결 대상에서 실패했다면 직결 경로와 트래픽 분기 규칙을 확인하세요.

네 단계로 원인 좁히기

  1. 정책 그룹에서 다른 노드를 직접 선택한 뒤 같은 요청을 다시 보내세요. 다른 노드로 성공했다면 원래 노드나 해당 노드의 경로에 문제가 있을 가능성이 커집니다. 다만 이것만으로 프로토콜 자체가 문제라고 단정할 수는 없습니다.
  2. 다른 사이트에도 접속해 보세요. 한 사이트에서만 실패한다면 대상 사이트 상태, 출구 지역 제한, 노드에서 대상까지의 경로를 확인하세요.
  3. 노드는 그대로 두고 Wi-Fi에서 휴대폰 핫스팟으로 바꾸는 등 네트워크를 한 번 전환해 보세요. 결과가 달라지면 로컬 네트워크, 방화벽 또는 통신사 경로를 중점적으로 확인하세요.
  4. 노드 설정의 서버 주소, 포트, 프로토콜 매개변수를 대조해 보세요. 구독이 만료되었거나 서버 포트가 변경되어도 연결에 실패할 수 있습니다. 수정하기 전에 구독을 업데이트하고 계정 상태를 확인하세요.

지연 시간 테스트가 성공했다는 것은 테스트 대상에 해당 시점에 필요한 탐색 요청을 보낼 수 있었다는 뜻일 뿐, 스트리밍이나 파일 다운로드, UDP까지 사용할 수 있다는 의미는 아닙니다. 테스트 결과가 80ms라고 해서 웹페이지가 반드시 80ms 안에 열린다고 해석하지 마세요.

connection refused와 timeout은 다릅니다

connection refused는 보통 연결이 명시적으로 거부되었다는 뜻입니다. 대상 포트에서 서비스가 대기 중이지 않거나 방화벽이 거부 응답을 반환했을 수 있습니다. 주소가 127.0.0.1:7890이면 로컬 프록시가 해당 포트에서 대기 중인지 확인하세요. 노드 서버 주소라면 노드 포트와 서비스 상태를 확인하세요. 시간 초과 값을 무작정 늘려도 포트 거부 문제는 해결되지 않습니다.

DNS 조회 실패: 요청 도메인, 노드 도메인, 상위 DNS 서버 구분하기

no such host, lookup ... failed, DNS query timeout 등의 메시지는 DNS 조회 단계의 문제를 가리키지만, 무엇을 조회하다 실패했는지 더 확인해야 합니다. 대상 도메인에 접속하려면 DNS 조회가 필요하고, 프록시 서버를 도메인으로 지정한 경우에도 조회가 필요합니다. 암호화된 DNS의 상위 서버를 도메인으로 지정했다면 해당 서버 주소를 먼저 어떻게 조회할지도 고려해야 합니다.

Windows에서는 먼저 nslookup example.com을 실행하고, macOS 또는 Linux에서는 해당 도구를 설치한 뒤 dig example.com을 실행할 수 있습니다. 이 명령은 보통 시스템의 DNS 조회 경로를 확인하며 Clash 내장 DNS를 거치지 않을 수 있습니다. 시스템 DNS 조회와 코어의 DNS 조회는 각각 확인해야 합니다.

Fake-IP 주소만으로 DNS 오류라고 판단할 수 없습니다

Fake-IP 모드에서는 앱에 가상 주소가 반환되는 것이 정상일 수 있습니다. 흔히 사용하는 설정은 198.18.0.0/16 범위이며, 실제 웹사이트의 공인 IP 주소와 다릅니다. 이 주소를 보고 바로 노드를 바꾸기보다 이후 연결이 코어로 들어오고 도메인 매핑이 복원되는지 확인하세요.

DNS 모드를 바꾼 뒤 문제가 생겼다면 먼저 앱 연결을 다시 설정하고, 필요한 경우 시스템 DNS 캐시를 비우세요. 모든 도메인을 곧바로 fake-ip-filter에 추가하지 말고, 실제로 호환성 문제가 있는 도메인 하나로 확인한 뒤 필요한 범위만 조정하세요. 필드 설명은 DNS 설정 안내와 Fake-IP 설명을 참고하세요.

규칙 미매칭: 모드, 순서, 도메인 정보 확인하기

‘원하는 노드를 거치지 않았다’고 해서 반드시 오류 로그가 생기는 것은 아닙니다. 요청이 앞쪽의 직접 연결 규칙에 정상적으로 매칭되었거나, 전역 모드여서 예상한 규칙 목록에 따라 분기되지 않았을 수 있습니다. 먼저 실행 모드를 확인한 다음 연결 로그에서 실제 적용된 규칙과 정책을 살펴보세요.

# 트래픽 분기 예시; Proxy는 설정에 이미 있는 정책 이름이어야 합니다
mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

규칙은 위에서 아래 순서로 매칭되며, 하나에 매칭되면 이후 규칙은 확인하지 않습니다. MATCH,DIRECT를 첫 줄에 두면 아래의 도메인 규칙은 적용되지 않습니다. 예시의 Proxy는 내장 예약 이름이 아니므로 설정에 이미 등록된 프록시 또는 정책 그룹 이름과 정확히 일치해야 합니다.

  1. 규칙 모드를 확인하세요: 전역 모드에서는 보통 전역 정책에 따라 아웃바운드가 결정되고, 직접 연결 모드에서는 예상한 프록시 정책을 우회합니다. 모드 설정은 프록시 모드 설정을 참고하세요.
  2. 현재 설정을 확인하세요: 수정한 설정이 실제 사용 중인 설정인지, 구독을 새로고침한 뒤에도 사용자 규칙이 유지되는지 확인하세요.
  3. 규칙 세트 상태를 확인하세요: RULE-SET을 사용한다면 해당 프로바이더가 정상적으로 로드되었는지, 이름과 콘텐츠 형식이 선언과 일치하는지 확인하세요.
  4. 도메인 정보를 확인하세요: 앱이 IP 주소에 직접 연결하면 도메인 규칙이 매칭되지 않을 수 있습니다. 스니핑으로 일부 상황에서 도메인 정보를 보완할 수 있지만, 모든 연결의 도메인을 복원할 수 있는 것은 아닙니다.
  5. 연결을 새로 설정하세요: 기존 장기 연결은 이전 아웃바운드를 계속 사용할 수 있습니다. 관련 페이지나 앱 연결을 닫고 다시 테스트해 이전 연결을 새 규칙의 결과로 착각하지 않도록 하세요.

시작 및 권한 오류: 포트 충돌, 설정 오류, TUN

address already in use: 먼저 포트를 사용 중인 프로세스 확인하기

코어 시작 시 bind: address already in use 오류가 발생하면 어떤 포트가 사용 중인지 먼저 확인하세요. 프록시 포트, DNS 리스닝 포트, 제어 인터페이스 포트 중 하나일 수 있습니다. 아래 명령은 7890을 예시로 사용합니다. 실제 포트는 현재 설정을 따르며 클라이언트마다 기본값이 다를 수 있습니다.

# Windows: 리스닝 포트와 프로세스 ID 확인
netstat -ano | findstr :7890

# macOS: TCP 리스닝 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: TCP 리스닝 소켓 확인
ss -ltnp 'sport = :7890'

프로세스가 무엇인지 확인한 뒤 중복 실행 중인 클라이언트를 종료하거나 로컬 리스닝 포트를 변경하세요. mixed-port를 7890에서 7891로 바꾸면 시스템 프록시와 앱 내 프록시 설정도 함께 업데이트해야 합니다. 프로세스 ID만 보고 정체를 모르는 시스템 서비스를 바로 종료하지 마세요.

YAML 및 정책 참조 오류: 먼저 설정이 로드되도록 확인하기

yaml: line ...은 대개 문법이나 구조에 문제가 있다는 뜻입니다. 들여쓰기에는 공백을 사용하고 Tab은 사용하지 마세요. 특수 문자가 포함된 값은 YAML 규칙에 맞게 따옴표로 감싸야 합니다. 표시된 줄은 파서가 더 진행할 수 없었던 위치일 뿐 실제 오류는 바로 앞 줄에 있을 수도 있습니다. 존재하지 않는 정책이나 잘못된 규칙 세트 이름은 설정 참조 오류이므로 네트워크를 재시작해도 해결되지 않습니다.

TUN permission denied: 시스템 권한과 트래픽 가로채기 범위 확인하기

TUN 생성 실패는 관리자 권한, 클라이언트의 서비스 모드, 운영체제의 VPN 권한과 관련이 있을 수 있습니다. Windows에서는 서비스와 관리자 권한 실행 여부를 확인하고, Android에서는 VPN 연결 요청을 승인했는지 확인하세요. 구체적인 절차는 클라이언트 안내를 따르세요. TUN을 켰다고 모든 트래픽이 자동으로 프록시를 통과하는 것은 아닙니다. 라우팅, 제외 항목, 기존 VPN에 따라 가로채기 결과가 달라집니다.

일반 명시적 프록시는 작동하지만 TUN은 작동하지 않는다면 노드와 설정을 그대로 둔 채 트래픽 처리 방식만 바꿔 비교하세요. 그러면 구독이나 노드뿐 아니라 가상 인터페이스, 라우팅, DNS 가로채기에서 문제가 발생했는지 좁힐 수 있습니다.

수정 결과 확인하기: 같은 요청으로 전후 비교

로그가 줄었다고 문제가 해결된 것은 아닙니다. 수정 후에는 같은 대상, 같은 네트워크, 같은 노드로 다시 테스트해 요청이 예상한 정책으로 전달되고 앱 수준의 응답까지 받는지 확인하세요. 브라우저는 페이지를 캐시할 수 있으므로 새 요청을 보내는 것이 좋습니다. 터미널에서는 로컬 프록시를 명시적으로 지정해 환경 변수의 영향을 차단할 수 있습니다.

# 로컬 mixed-port가 7890일 때 HTTP 프록시 테스트
# Windows에서는 curl을 curl.exe로 입력할 수 있습니다
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

# mixed-port 또는 SOCKS 포트가 7890일 때 SOCKS 테스트
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

socks5h는 도메인 조회를 SOCKS 프록시에 맡긴다는 뜻으로, 로컬 DNS 조회 경로와 구분해 테스트할 때 유용합니다. 테스트 결과 HTTP 403 등의 응답을 받았다면 어떤 HTTP 엔드포인트에서는 응답이 도착했다는 뜻입니다. 다만 대상 사이트의 정책으로 계속 차단될 수 있으며, 연결을 맺기 전에 시간 초과가 발생한 경우와는 다른 문제입니다.

문제를 계속 신고해야 한다면 최소한의 기록을 정리하세요. 운영체제와 코어 버전, 재현 절차와 시간, 민감 정보를 가린 로그, 관련 설정 일부, 이미 시도한 단일 항목별 비교 결과가 필요합니다. 화면 전체를 캡처하는 것보다 이 정보가 DNS, 규칙, 리스닝 포트, 노드 연결 중 어느 구간에 문제가 있는지 찾는 데 도움이 됩니다.