시간순으로 살펴본 뒤 오류 키워드를 확인하세요
요청은 한 번에 하나씩 재현하고, 관련 오류 중 가장 먼저 발생한 항목부터 찾으세요. ‘웹페이지가 열리지 않는다’는 문제는 트래픽 가로채기, 도메인 조회, 규칙 선택, 프록시 연결 또는 대상 서버 응답 단계에서 생길 수 있습니다. 로그의 마지막 시간 초과는 앞선 문제의 결과인 경우가 많습니다. timeout만 검색해 프록시 노드를 바꾸면 엉뚱한 부분을 수정할 수 있습니다.
Clash는 커널과 클라이언트 생태계를 통칭합니다. 구형 Clash 커널, Clash Meta(현 mihomo), 데스크톱 클라이언트에 따라 로그 형식과 제공 필드가 다를 수 있습니다. 클라이언트의 ‘로그’ 화면에는 보통 커널 실행 로그가 표시됩니다. 클라이언트 자체의 서비스 설치, 권한, 업데이트 오류는 별도의 앱 로그에 기록될 수 있습니다. 커널이 시작되지 않았다면 연결 로그가 비어 있는 것도 이상한 일이 아닙니다.
- 문제가 발생한 현지 시각(예:
14:32:10)과 대상 도메인, 사용한 프로그램을 함께 기록하세요. - 관련 없는 웹페이지와 다운로드 프로그램, 계속 네트워크에 연결되는 앱을 종료해 백그라운드 트래픽을 줄이세요.
- 로그 화면을 열고 기존 기록을 지우세요. 이 기능은 보통 화면 표시만 지우며 디스크의 로그 파일을 삭제하지는 않습니다.
- 대상 페이지를 한 번만 새로고침하고, 전후 약 10초간의 기록을 보관하세요.
- ‘커널에 전달됐는지 → DNS 조회 → 규칙 → 아웃바운드 → 앱 응답’ 순서로 확인하세요.
로그 레벨: 평소에는 info, 재현할 때는 debug
먼저 클라이언트의 ‘로그’ 화면에서 현재 기록을 확인하세요. 더 자세한 정보가 필요하면 클라이언트 설정에서 ‘로그 레벨’ 또는 Log Level을 찾으세요. 일부 클라이언트는 커널의 실행 로그 레벨을 직접 조정할 수 있지만, 화면 필터로 특정 행만 숨기는 경우도 있습니다. 이때는 커널 출력량이 바뀌지 않습니다. 레벨을 바꾼 뒤 요청을 다시 보내 새 디버그 로그가 나타나는지 확인하세요.
| 레벨 | 사용 상황 | 확인할 내용 |
|---|---|---|
silent | 문제 해결에 적합하지 않은 이유 | 출력이 억제되므로 연결이 있었는지 판단할 수 없음 |
error | 심각한 오류만 수집 | 시작 실패 등의 오류만 남아 정상적인 연결 흐름을 파악하기 어려움 |
warning | 이상 징후 확인 | 연결 실패, 시간 초과 및 관련 경고 |
info | 일상적인 점검 | 연결 대상, 규칙 매칭, 선택한 정책 등 일반 정보 |
debug | 짧은 시간 동안 문제 재현 | 더 자세한 DNS 조회 및 내부 처리 정보. 표시 내용은 버전에 따라 다름 |
실제로 적용되는 설정을 수정하세요
설정에서 로그 레벨을 지정할 수 있는 커널은 다음 최상위 필드를 사용할 수 있습니다. dns:나 tun: 아래에 들여쓰지 마세요. 클라이언트에서 구독을 관리한다면 클라이언트가 제공하는 오버라이드 또는 병합 설정 기능을 우선 사용하세요. 다운로드한 구독 파일을 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다.
log-level: debug저장한 뒤 클라이언트 안내에 따라 설정을 다시 불러오고, 실행 로그 레벨이 실제로 바뀌었는지 확인하세요. 문제를 해결한 뒤에는 info로 되돌리세요. 디버그 로그에는 방문한 도메인, 내부망 주소, 프록시 서버 정보가 포함될 수 있습니다. 장기간 보관하면 불필요한 로그가 쌓일 뿐 아니라 공유할 때 정보가 노출될 위험도 커집니다.
연결 로그: 대상, 규칙, 아웃바운드부터 확인
14:32:10 INF [TCP] 127.0.0.1:53124 --> example.com:443
match DomainSuffix(example.com) using DIRECT이 예시 로그에서는 최소 네 가지를 확인할 수 있습니다. 연결은 TCP이고, 로컬 출발 포트는 53124, 대상은 example.com:443이며, 도메인 접미사 규칙에 일치해 직접 연결을 선택했습니다. 출발 포트는 보통 앱에 임시로 할당된 포트이지 Clash 수신 포트가 아닙니다. 이 값만 보고 mixed-port를 수정하면 안 됩니다.
- 대상: 도메인이나 IP가 방금 실행한 작업과 일치하는지 확인하세요. 웹페이지는 이미지, 스크립트, 로그인 API도 요청하므로 첫 화면의 도메인만이 대상은 아닙니다.
- 규칙: 마지막에 표시된 정책 그룹 이름만 보지 말고, 일치한 규칙의 유형과 내용을 확인하세요.
- 아웃바운드:
DIRECT는 직접 연결,REJECT는 정책에 따른 거부입니다. 프록시 그룹 뒤에 실제로 선택된 프록시가 이어서 표시될 수 있습니다. - 결과: 연결 로그가 있다는 것은 커널이 해당 연결을 처리했다는 뜻입니다. TLS 핸드셰이크, 웹페이지 로드, 서비스 요청의 성공까지 의미하지는 않습니다.
관련 로그가 전혀 없다면
먼저 로그 필터가 적용되어 있는지 확인한 다음 트래픽 유입 경로를 점검하세요. 시스템 프록시는 해당 설정을 따르는 프로그램에만 적용됩니다. 앱에 프록시 주소를 별도로 입력했다면 현재 수신 주소와 포트(예: 127.0.0.1:7890)가 맞는지 확인하세요. 모든 클라이언트가 7890을 쓰는 것은 아닙니다. TUN 모드에서는 가상 네트워크 어댑터, 라우팅 가로채기, 필요한 권한이 적용됐는지도 확인해야 합니다.
브라우저가 기존 연결을 재사용하면 페이지를 새로고침해도 새 연결 로그가 남지 않을 수 있습니다. 브라우저를 완전히 종료한 뒤 다시 열거나 새 테스트 프로세스에서 요청을 보내면 더 명확한 로그를 얻기 쉽습니다. 일반 프록시 테스트에는 로그가 남는데 특정 프로그램에서만 계속 기록이 없다면 해당 프로그램의 트래픽 가로채기 방식을 먼저 확인하세요.
dial 오류: 연결 거부, 시간 초과, 경로 없음 구분하기
dial은 연결을 시도한다는 뜻입니다. 오류에 표시된 주소는 최종 대상일 수도 있고 프록시 서버나 DNS 업스트림일 수도 있습니다. 전체 오류 내용을 확인해 어디에 연결하려 했는지 파악한 뒤 웹사이트, 프록시 노드, 로컬 네트워크 중 무엇을 점검할지 결정하세요.
dial tcp 127.0.0.1:7890: connect: connection refused
dial tcp 192.0.2.10:443: i/o timeout
dial tcp [2001:db8::10]:443: connect: network is unreachable위 예시의 192.0.2.10과 2001:db8::10은 문서용 예시 주소이며 테스트할 수 있는 노드 주소가 아닙니다. 세 오류는 각각 상대 측의 연결 거부, 제한 시간 내 연결 미완료, 사용 가능한 네트워크 경로 없음에 해당하므로 해결 방법도 다릅니다.
connection refused: 주소와 수신 상태부터 확인
거부된 주소가 127.0.0.1:7890이라면 프록시 커널이 실행되지 않았거나 포트가 변경됐거나 프로그램이 이전 설정을 사용 중일 수 있습니다. Windows에서는 PowerShell로 TCP 수신 상태를 확인하고, macOS와 Linux에서는 터미널에서 수신 프로세스를 확인할 수 있습니다. 다음 명령은 조회만 하며 프로세스를 종료하지 않습니다.
# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen
# macOS / Linux, lsof 설치 필요
lsof -nP -iTCP:7890 -sTCP:LISTEN수신 중인 포트가 없으면 클라이언트에서 실행 상태를 확인하세요. 포트가 열려 있다면 해당 프로세스가 예상한 커널인지 확인하세요. 원격 프록시 주소가 연결을 거부한다면 구독에 등록된 서버 포트와 서비스 상태를 점검해야 합니다. 로컬 혼합 포트를 바꿔도 원격 서버의 거부 문제는 해결되지 않습니다.
i/o timeout: 어느 구간에서 시간 초과가 발생했는지 확인
시간 초과가 노드의 영구적인 장애를 뜻하지는 않습니다. 패킷 손실, 방화벽의 패킷 차단, 프록시 서버 연결 불가, 대상 사이트의 느린 응답 등 여러 원인이 있습니다. 대상은 그대로 두고 같은 정책 그룹의 다른 프록시로 바꾼 뒤 오류 주소와 발생 시간을 비교하세요. 모든 프록시에서 실패한다면 로컬 네트워크와 프록시 서버 도메인 조회를 이어서 확인하세요. DNS, TUN, 규칙을 한꺼번에 바꾸지는 마세요.
network is unreachable: 라우팅과 주소 체계 확인
오류 주소에 대괄호가 있으면 보통 IPv6 주소입니다. 사용할 수 있는 IPv6 경로가 없거나 VPN 라우팅이 충돌하거나 TUN 가로채기에 문제가 있으면 연결할 수 없습니다. 먼저 시스템 자체에서 같은 주소 체계의 주소에 접근할 수 있는지 확인한 뒤 라우팅 변경 사항을 살펴보세요. IPv6 오류 한 건만으로 요청 전체가 실패했다고 단정할 수는 없습니다. 뒤이어 IPv4 재시도가 있을 수 있으므로 주변 로그도 함께 확인하세요.
DNS 조회 시간 초과: 업스트림 오류와 연결 오류 구분
lookup example.com: i/o timeout
exchange failed: context deadline exceeded
lookup example.com: no such host예시 로그는 각각 조회 시간 초과, DNS 교환 기한 초과, 도메인 이름을 찾을 수 없는 문제를 나타낼 수 있습니다. 실제 로그에는 업스트림 주소, 조회 유형, 하위 연결 오류가 포함되기도 합니다. no such host는 시간 초과와 다릅니다. 먼저 도메인 철자를 확인한 뒤 응답 출처와 필터 설정을 점검하세요.
- 어디에서 조회하는지 확인: 시스템 DNS, 앱 자체 DoH, mihomo 내장 DNS 중 무엇을 사용하는지 확인하세요. 브라우저의 보안 DNS 설정이 경로에 영향을 줄 수 있고, TUN의 DNS 가로채기로 실제 요청 경로가 바뀔 수도 있습니다.
- 업스트림 연결 확인: 일반 DNS는 보통 UDP/TCP 53, DoT는 TCP 853, DoH는 일반적으로 HTTPS 443을 사용합니다. 포트에 연결된다는 것은 전송 계층에서 접근 가능하다는 뜻일 뿐, DNS 조회가 반드시 성공한다는 뜻은 아닙니다.
- 두 종류의 도메인 구분: 대상 웹사이트 도메인과 프록시 서버 도메인 모두 조회가 필요할 수 있습니다. 프록시 서버의 도메인을 조회하지 못하면 이후 프록시 연결도 실패합니다.
- 의존 관계 확인: 프록시를 통해서만 접근할 수 있는 DNS 업스트림이 아직 조회되지 않은 프록시 서버에 의존하면 시작 단계에서 순환 의존 문제가 생길 수 있습니다.
시스템 DNS 조회 결과는 비교용으로만 사용
nslookup example.com이 명령은 시스템 기본 DNS 경로의 결과를 확인하는 데 사용할 수 있지만, mihomo 내장 DNS가 정상이라는 증거는 아닙니다. TUN이나 DNS 가로채기가 적용되면 커널이 이 요청을 처리할 수도 있습니다. 같은 경로를 사용하는지 판단하려면 현재 설정과 로그의 업스트림 정보를 함께 확인해야 합니다. ‘시스템에서 조회되니 Clash DNS도 정상’이라고 단정할 수는 없습니다.
mihomo의 proxy-server-nameserver는 프록시 서버 도메인을 조회할 때 사용할 수 있고, default-nameserver는 DNS 서버 자체의 도메인을 조회하는 설정과 관련됩니다. 동작 방식과 지원 항목은 현재 커널 문서를 확인하세요. 구형 Clash 설정에서는 이 필드가 지원되지 않을 수 있으니 새 커널 예시 전체를 그대로 복사하지 마세요. respect-rules 등의 옵션을 사용할 때는 DNS 요청이 자기 자신에게 의존하는 프록시 경로로 규칙에 따라 전송되는지도 확인해야 합니다.
규칙 미일치: 모드, 순서, 대상 유형 확인
‘규칙 미일치’가 명시적인 오류 한 줄로 표시되는 것은 아닙니다. 로그에 Match 대체 규칙이 표시되거나 예상과 다른 아웃바운드가 선택되는 경우가 더 흔합니다. 먼저 클라이언트가 규칙 모드인지 확인하세요. 전역 모드와 직접 연결 모드에서는 일반적인 규칙 모드처럼 연결마다 아웃바운드를 선택하지 않습니다.
# 설정 예시: 전체 구독 설정이 아닙니다
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,DIRECT규칙은 순서대로 검사하며 먼저 일치한 규칙이 결과를 결정합니다. 위 예시에서는 특정 도메인 규칙을 대체 규칙 앞에 배치했습니다. MATCH를 앞에 두면 뒤의 일반 규칙은 연결을 처리할 기회가 없습니다. 예시에서는 내장 대상인 DIRECT만 사용합니다. 사용자 정의 정책 그룹 이름으로 바꾸려면 전체 설정의 proxy-groups에 해당 그룹을 정의해야 합니다.
- 도메인이 일치하지 않음:
DOMAIN은 지정한 도메인과 일치하고DOMAIN-SUFFIX는 접미사와 해당 하위 도메인에 일치합니다. 웹페이지가 로그인 도메인으로 리디렉션되면 기존 규칙 범위에 포함되지 않을 수 있습니다. - IP만 확인됨: 앱이 IP에 직접 연결하거나 도메인 정보가 보존되지 않으면 도메인 규칙이 매칭에 사용되지 않을 수 있습니다. 트래픽 스니핑으로 도메인을 복원할 수 있는지는 프로토콜, 설정, 커널 지원에 따라 달라지며 모든 연결에서 보장되지는 않습니다.
- 규칙 세트가 로드되지 않음: 시작하거나 설정을 다시 불러올 때 provider 다운로드 및 파싱 오류가 있었는지 확인하세요. 규칙 세트 형식은
behavior와 일치해야 합니다. 구독 다운로드가 성공해도 모든 규칙 세트가 정상적으로 로드된다는 뜻은 아닙니다. - 오버라이드가 병합되지 않음: 현재 활성화된 설정이 무엇인지 확인하세요. 다른 설정 파일을 편집했거나 병합 계층을 잘못 지정하면 규칙이 실행 설정에 반영되지 않을 수 있습니다.
- 정책 그룹 선택이 다름: 예상한 규칙에 일치했더라도 그룹 내 수동 선택, 자동 테스트 결과, 중첩 그룹의 대상이 바뀌어 잘못된 프록시를 사용할 수 있습니다.
검증할 때는 대상 도메인용 임시 규칙 하나만 추가해 관련된 포괄 규칙보다 앞에 두고, 설정을 다시 불러온 뒤 새 연결을 만드세요. 규칙 이름과 아웃바운드가 예상과 일치하는지 확인한 다음 실제 접속 문제가 해결됐는지 판단하세요. 규칙 작성법과 혼합 포트 안내는 설정 심화 안내에서 확인할 수 있습니다.
시간순으로 원인 찾기: 한 번에 변수 하나만 변경
아래는 문제 해결 기록 예시이며 실제 속도 측정 결과가 아닙니다. 14:32:10에 페이지를 새로고침해 예상한 정책 그룹에 연결됐고 14:32:15에 프록시 서버 연결 시간 초과가 발생했다고 가정해 보겠습니다. 우선 프록시 서버 경로를 확인하세요. 14:32:10에 프록시 서버 도메인 조회 오류가 먼저 발생했다면 DNS 조회가 더 이른 원인입니다.
| 관찰 결과 | 다음 단계 | 지금은 하지 말 것 |
|---|---|---|
| 대상 연결 기록이 없음 | 로그 필터, 시스템 프록시, 앱 프록시 또는 TUN 가로채기 확인 | 프록시 노드를 한꺼번에 변경 |
| 프록시 서버 도메인 조회 실패 | DNS 업스트림과 시작 단계의 의존 관계 확인 | 대상 웹사이트 규칙만 수정 |
| 대체 규칙 또는 잘못된 규칙에 일치 | 규칙 모드, 순서, 도메인, 실행 설정 확인 | 지연 시간만 보고 규칙이 맞다고 판단 |
| 예상한 아웃바운드 연결이 거부되거나 시간 초과 | 원격 주소와 포트를 확인하고 다른 프록시와 비교 | 모든 네트워크 설정을 동시에 초기화 |
| 연결은 됐지만 앱에서 여전히 실패 | TLS, HTTP 상태 코드, 앱 로그 확인 | 모든 실패를 DNS 문제로 단정 |
프록시를 명시한 요청으로 진입 경로 확인
현재 혼합 포트가 실제로 7890이라면 아래 요청으로 HTTP 프록시 진입 경로를 확인할 수 있습니다. Windows에서는 curl.exe를 사용하면 PowerShell 환경에 따라 발생할 수 있는 명령 별칭 차이를 피할 수 있습니다. macOS와 Linux에서는 보통 curl을 사용합니다.
# Windows
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com/
# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com/여기서 5초는 연결 단계 제한 시간, 15초는 전체 요청 제한 시간입니다. 이번 curl 테스트에만 적용되며 커널의 전역 시간 제한은 바뀌지 않습니다. -I는 응답 헤더를 요청합니다. 대상 서버가 403이나 405를 반환해도 프록시 오류라고 단정하지 말고 연결이 성립했는지와 응답 출처를 함께 확인하세요. 이 테스트는 로컬 HTTP 프록시를 명시적으로 사용하므로 다른 프로그램에 대한 TUN 가로채기가 정상인지까지 입증하지는 않습니다.
로그에 연결 처리 완료만 표시되는데 브라우저에서 인증서 오류나 로그인 오류가 계속 발생한다면 브라우저 개발자 도구의 네트워크 상태와 앱 오류를 추가로 확인하세요. Clash 실행 로그는 완전한 HTTP 패킷 캡처가 아니므로 서비스 API의 모든 응답 내용을 직접 보여 주지는 않습니다. 커널 로그로 전송 경로를 파악하고 앱 로그로 상위 계층의 원인을 확인하세요.
문제 해결 로그 공유: 전후 맥락은 보존하고 민감 정보는 가리기
유지관리자에게 전달할 자료는 양보다 재현 가능성이 중요합니다. 같은 요청 전후 약 10초의 로그와 현재 모드, 운영체제 버전, 클라이언트 버전, 커널 버전을 보관하고 시스템 프록시나 TUN 사용 여부를 알려 주세요. 클라이언트 버전과 mihomo 커널 버전은 각각 기록해야 하며, 한쪽을 다른 쪽 대신 적으면 안 됩니다.
- 실행한 작업과 예상 결과를 적으세요. 예: ‘대상 페이지를 열었을 때 지정한 도메인 규칙에 일치할 것으로 예상했지만 실제로는 MATCH가 선택됨.’
- 원격 문제와 로컬 문제를 구분할 수 있도록 전체 오류 내용, 규칙 유형, 주소 체계, 포트를 보존하세요.
- 구독 링크, 인증 정보, 컨트롤 인터페이스 키, 액세스 토큰을 삭제하세요.
- 프록시 서버, 사용자 이름, 내부망 주소는 일관된 익명 표기로 바꿀 수 있습니다. 같은 대상에는 항상 같은 표기를 사용하세요.
- 가장 최근에 변경한 내용과 변경 전후의 동일 요청 결과를 첨부하세요. 빨간색 오류 한 줄만 잘라 보내지 마세요.