먼저 로그 출처와 요청 시간을 확인하세요
Clash 로그는 커널이 연결을 처리하는 과정을 기록합니다. 브라우저 페이지를 종합적으로 진단하는 보고서는 아닙니다. 웹페이지가 열리지 않는 원인은 앱에서 프록시를 사용하지 않는 경우, 규칙 선택, 도메인 조회, 노드 연결, 원격 서버 응답 등 여러 단계에서 발생할 수 있습니다. 오류가 어느 단계에서 생겼는지 먼저 찾고 해당 설정을 수정하는 편이, 빨간 오류 메시지만 보고 클라이언트를 재설치하는 것보다 효과적입니다.
Clash는 커널과 관련 클라이언트를 통칭할 때 흔히 쓰는 이름이며, Clash Meta는 이후 mihomo라는 이름으로 개발을 이어가고 있습니다. 커널, 데스크톱 클라이언트, 인터페이스 버전에 따라 로그 항목과 메뉴 이름이 다를 수 있습니다. 이 글의 로그는 구조를 설명하기 위한 예시이며 실제 네트워크 테스트 결과가 아닙니다. 예시에 나온 포트를 현재 기기의 설정값으로 사용해서도 안 됩니다.
- 클라이언트 사이드바에서 ‘로그’ 또는 ‘Logs’를 여세요. 로그 페이지가 없다면 ‘설정’에서 로그 디렉터리나 커널 로그 메뉴를 찾으세요.
- 현재 시각, 사용 중인 설정 이름, 실행 모드, 정책 그룹에서 실제로 선택된 노드, 시스템 프록시와 TUN의 활성화 여부를 기록하세요.
- 화면의 기존 로그를 지운 다음 문제가 발생하는 페이지 하나만 여세요. 약 10초 기다린 뒤 스크롤을 멈추거나 해당 구간의 로그를 내보내세요.
- 대상 도메인, 대상 포트, 시간으로 로그를 필터링하세요. 자동 업데이트, 연결 테스트, 웹 요청이 같은 창에 섞여 있으므로 마지막 오류 한 줄만 봐서는 안 됩니다.
로그 수준 설정: 먼저 info를 사용하고 필요할 때만 debug로 전환
자주 쓰이는 로그 수준은 silent, error, warning, info, debug입니다. 평소 문제를 확인할 때는 연결과 규칙 매칭 정보를 볼 수 있는 info를 사용하세요. DNS 조회, 연결 시도, 커널 내부 동작을 자세히 확인해야 할 때만 잠시 debug를 켜세요.
| 수준 | 확인할 수 있는 내용 | 사용 권장 사항 |
|---|---|---|
| error | 커널이 오류로 분류한 이벤트 | 정보가 적어 첫 문제 해결의 유일한 근거로 삼기 어렵습니다 |
| warning | 경고 및 그보다 심각한 이벤트 | 일부 실패를 찾을 수 있지만 연결 맥락이 충분하지 않습니다 |
| info | 일반 연결, 규칙 선택, 경고와 오류 | 문제를 처음 재현할 때 사용하세요 |
| debug | 더 자세한 내부 처리 기록 | 문제 재현 구간에서만 사용하고 확인이 끝나면 info로 되돌리세요 |
| silent | 일반 로그 출력을 끕니다 | 문제 해결 중에는 사용하지 마세요 |
설정 변경 위치와 덮어쓰기
인터페이스에 ‘설정’ → ‘로그 수준’ 메뉴가 있다면 먼저 여기서 변경하세요. 커널 설정을 직접 관리하는 경우 현재 적용 중인 YAML의 최상위 수준에 다음 항목을 설정할 수 있습니다. 이 항목은 dns나 tun의 하위 항목이 아닙니다.
log-level: info저장한 뒤 클라이언트에서 지원하는 방식으로 설정을 다시 불러오고 로그를 확인하세요. 일부 클라이언트는 설정 덮어쓰기나 병합, 실행 중 매개변수로 로그 수준을 제어하며, 구독 업데이트가 직접 수정한 파일을 덮어쓸 수도 있습니다. 디스크에 저장된 파일만 보고 적용 여부를 판단하지 말고 인터페이스와 실제 로그 출력을 함께 확인하세요. 문제 해결이 끝나면 info로 되돌려 요청 기록이 불필요하게 쌓이지 않도록 하세요.
연결 로그 읽는 법: 대상, 규칙, 출구와 오류 흐름
시간을 먼저 확인하고 요청 대상, 적용된 규칙과 실제 출구, 마지막으로 오류 흐름을 살펴보세요. 아래는 단순화한 구조 예시이며 실제 로그는 항목 순서나 줄바꿈 방식이 다를 수 있습니다.
[warning] [TCP] 127.0.0.1:53124 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[노드 A]
error: dial tcp 192.0.2.10:443: i/o timeout127.0.0.1:53124는 커널이 확인한 연결의 출발점입니다. 53124는 임시 출발지 포트이며 시스템 프록시에 입력할 리스닝 포트가 아닙니다.www.example.com:443은 요청 대상입니다. 443은 HTTPS에 흔히 사용되는 포트지만, 포트 번호만으로 웹사이트 인증서가 정상인지 판단할 수는 없습니다.match뒤의 내용으로 어떤 규칙이 적용됐는지 확인할 수 있습니다. 규칙 모드에서는 일반적으로 순서대로 매칭되며, 앞에서 먼저 적용된 규칙이 이후 연결 경로에 영향을 줍니다.using Proxy[노드 A]는 이번 연결에 사용된 정책과 노드를 나타냅니다. 정책 그룹 이름은 노드 서버 주소가 아니므로 실제로 선택된 구성원도 확인해야 합니다.dial tcp뒤의 주소는 이번 연결 시도 대상입니다. 직접 연결이면 웹사이트 주소일 수 있고, 프록시를 통하면 노드 주소일 수 있으므로 오류 흐름 전체를 함께 살펴보세요.
예시의 192.0.2.10은 문서용 주소이므로 설정에 입력하면 안 됩니다. DIRECT가 표시되는데 노드를 통해 접속하려던 경우에는 규칙과 모드를 먼저 확인하세요. REJECT가 표시되면 노드 장애로 단정하지 말고 차단 규칙부터 살펴보세요.
dial timeout과 i/o timeout: 어느 구간에서 시간이 초과됐는지 확인
dial timeout과 connect: connection timed out은 보통 제한 시간 내에 연결을 수립하지 못했다는 뜻입니다. i/o timeout은 범위가 더 넓어 연결이 수립된 뒤 읽기나 쓰기 단계에서 발생할 수도 있습니다. 둘 다 응답을 기다리다 시간이 초과됐다는 의미이지, 곧바로 ‘노드가 작동하지 않는다’거나 ‘DNS가 오염됐다’는 뜻은 아닙니다.
실패 범위를 기준으로 원인을 좁히세요
- 특정 웹사이트 하나만 실패하는 경우: 같은 노드로 접속할 수 있다고 알고 있는 다른 사이트를 열어 보세요. 실패한 도메인에 다른 규칙이 적용됐는지, 직접 연결로 처리됐는지 확인하세요.
- 같은 노드에서 여러 웹사이트가 실패하는 경우: 같은 정책 그룹에서 다른 노드로 바꾼 뒤 같은 요청을 다시 보내세요. 기존 노드에서만 실패한다면 해당 노드의 주소, 포트, 서비스 상태를 중점적으로 확인하세요.
- 모든 노드에서 실패하는 경우: 먼저 로컬 네트워크가 정상인지 확인한 다음 노드 도메인 조회, 방화벽, 상위 네트워크 제한, 구독 만료 여부를 살펴보세요.
- TUN 모드에서만 실패하는 경우: 같은 설정과 노드를 유지한 채 시스템 프록시 모드로 비교해 보세요. 프록시 모드에서는 정상인데 TUN에서만 문제가 생긴다면 라우팅, DNS 가로채기, 다른 VPN과의 충돌을 확인하세요.
Windows에서는 PowerShell에서 Test-NetConnection -ComputerName 노드 도메인 -Port 노드 포트를 실행할 수 있습니다. 두 한국어 값을 현재 설정에 있는 실제 값으로 바꿔야 합니다. 이 TCP 테스트는 TCP를 사용하는 엔드포인트에만 유효합니다. 결과만으로 UDP 기반 프로토콜의 정상 여부를 판단할 수 없으며, 포트 연결에 성공해도 인증, TLS, 애플리케이션 요청까지 성공한다는 뜻은 아닙니다.
처음부터 제한 시간을 늘리지 마세요. 더 오래 기다려도 잘못된 주소, 중단된 서비스, 연결되지 않는 네트워크 경로는 해결되지 않습니다. 먼저 로그에서 어느 엔드포인트의 응답이 지연됐는지 확인한 뒤 제한 시간 설정을 조정할지 판단하세요.
connection refused: 로컬 포트와 원격 포트 구분하기
connection refused는 연결 시도가 거부됐다는 뜻입니다. 해당 주소와 포트에서 서비스가 리스닝 중이지 않거나 네트워크 장비가 연결을 차단했을 때 흔히 발생합니다. 응답 없이 기다리다 시간이 초과된 경우와는 다릅니다. 먼저 거부된 주소가 127.0.0.1인지 노드 서버 주소인지 확인하세요.
로컬 127.0.0.1:7890 연결이 거부된 경우
7890은 흔히 예시로 쓰이는 프록시 포트일 뿐, 모든 클라이언트의 고정 포트는 아닙니다. 앱이 로컬 7890에 연결하다 거부됐다면 클라이언트 ‘설정’에서 포트 또는 혼합 포트 설정을 열어 커널이 실행 중인지, 실제 리스닝 포트가 변경됐는지 확인하세요. 커널 로그에서 포트 바인딩 실패가 먼저 발생했는지도 살펴보세요.
# Windows: 로컬 7890이 리스닝 중인지 확인
netstat -ano | findstr ":7890"
# macOS / Linux: TCP 7890을 리스닝하는 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTENWindows에서는 로컬 주소 열과 LISTENING 상태를 함께 확인해야 합니다. 출력에 ‘7890’이 있다는 이유만으로 프록시가 실행 중이라고 단정하지 마세요. 포트를 사용 중인 프로세스를 찾으면 먼저 어떤 프로그램인지 확인하고, 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요.
원격 노드 포트 연결이 거부된 경우
노드 주소에서 연결이 거부됐다면 구독에 포함된 서버 주소와 포트가 유효한지 확인하고 구독을 새로고침한 뒤 다시 시도하세요. HTTP 프록시 인증 정보가 잘못된 경우에는 407 Proxy Authentication Required 같은 응답이 나타날 수 있으므로 모든 거부를 비밀번호 문제로 돌려서는 안 됩니다. 노드 포트 연결에 성공한 뒤에도 프로토콜과 인증을 별도로 확인해야 합니다.
DNS 조회 실패: 대상 도메인과 노드 도메인을 구분하세요
no such host, lookup ... failed, DNS resolve failed는 모두 DNS 조회 단계의 오류입니다. 다만 조회에 실패한 대상은 접속하려는 웹사이트일 수도 있고 노드 서버일 수도 있습니다. 노드 도메인을 조회하지 못하면 웹사이트 DNS 설정이 올바르더라도 노드에 먼저 연결할 수 없습니다.
- 대상 웹사이트 조회 실패: 현재 적용 중인 설정의
dns항목, DNS 서버 연결 상태, 직접 연결과 프록시 경로에서 사용하는 조회 정책을 확인하세요. - 노드 도메인 조회 실패: mihomo에
proxy-server-nameserver가 설정돼 있는지, 노드에 연결하기 전에도 해당 DNS 서버를 사용할 수 있는지 확인하세요. - DoH 서버에 연결할 수 없는 경우: DoH 주소와 호스트 이름의 초기 DNS 조회, 연결 경로를 확인하세요. ‘노드 연결에 DNS가 필요한데 DNS 연결에는 아직 연결되지 않은 노드가 필요하다’는 순환 의존이 생기지 않도록 해야 합니다.
- TUN에서만 실패하는 경우: TUN의 DNS 가로채기 설정, 시스템의 현재 DNS 설정, 다른 VPN이 네트워크 설정을 동시에 변경하는지 확인하세요.
시스템 DNS 조회가 정상이어도 커널 DNS 조회까지 정상이라는 뜻은 아닙니다
nslookup www.example.com을 실행하면 시스템에서 사용하는 DNS 서버의 응답을 확인할 수 있지만, 이 조회가 mihomo 내장 DNS를 거치는 것은 아닙니다. 브라우저에서 보안 DNS를 사용하면 다른 경로로 조회할 수도 있습니다. 따라서 ‘nslookup 결과가 있다’는 사실만으로 커널이 실제 사용하는 DNS 서버까지 정상이라고 판단할 수는 없습니다.
fake-ip 모드에서는 설정된 Fake IP 대역의 가상 주소가 나타나는 것이 정상일 수 있습니다. 예를 들어 198.18.0.0/16은 흔히 사용되는 대역입니다. 이런 주소가 보인다고 DNS 하이재킹으로 단정하지 마세요. 연결이 올바른 커널 라우팅으로 돌아오는지, 실제 상위 DNS 조회나 노드 연결에서 실패하는지 계속 확인하세요. 자세한 점검 위치는매뉴얼의 DNS 문제 해결을 참고하세요.
인증서, 포트 바인딩, TUN 권한 오류
| 로그 키워드 | 의미와 먼저 확인할 항목 |
|---|---|
x509: certificate has expired or is not yet valid | 운영체제의 날짜, 시간, 시간대를 확인한 뒤 오류가 발생한 웹사이트, 노드, 구독 엔드포인트를 확인하세요 |
certificate signed by unknown authority | 인증서 신뢰 체인, 기업 네트워크의 트래픽 차단, 노드 인증서 설정을 확인하세요. 인증서 검증을 바로 끄지는 마세요 |
bind: address already in use | 리스닝 포트나 주소 충돌입니다. 혼합 포트, DNS 리스닝 포트, 제어 포트를 확인하세요 |
permission denied / operation not permitted | 앞서 나온 로그와 함께 설정 파일 권한, 네트워크 장치 생성 권한, 라우팅 권한 중 무엇이 부족한지 확인하세요 |
connection reset by peer / EOF | 연결이 재설정됐거나 읽기가 종료된 경우입니다. 프로토콜 단계와 재현 범위를 확인해야 하며 비밀번호 오류로 단정할 수 없습니다 |
TLS 오류가 발생하면 먼저 어떤 대상과의 연결인지 확인하세요. 커널에 표시된 인증서 오류는 노드 핸드셰이크, 구독 다운로드, DNS over HTTPS 요청에서 발생했을 수 있으며 브라우저에서 접속한 웹사이트와 무관할 수도 있습니다. 일반적인 프록시 방식으로 HTTPS를 전달하는 경우 웹사이트 인증서의 최종 검증은 대체로 브라우저가 수행합니다.
TUN 생성이나 라우팅 권한 오류가 발생하면 클라이언트 ‘설정’에서 서비스 모드, 권한 또는 TUN 관련 메뉴를 열고 클라이언트 안내에 따라 서비스를 설치하거나 권한을 부여하세요. Windows 데스크톱 클라이언트는 설치된 백그라운드 서비스가 필요할 수 있고, Linux에서는 TUN 장치와 네트워크 관리 권한이 필요한 경우가 많습니다. 필요한 조치는 클라이언트마다 다르므로 모든 오류를 해결하려고 항상 관리자 권한으로 실행하는 방식은 권장하지 않습니다.
리스닝 포트를 변경했다면 시스템 프록시, 터미널 프록시 환경 변수, 브라우저 확장 프로그램의 수동 설정도 함께 바꾸세요. 커널이 정상적으로 시작돼도 앱이 이전 포트를 사용하면 로컬 연결 오류가 계속 발생합니다.
정해진 순서로 재현하고 로그를 비식별 처리하세요
한 번에 변수 하나만 바꾸고 같은 도메인에 같은 방식으로 접속해 재현하세요. 구독을 업데이트하고 노드를 바꾸고 DNS와 TUN까지 동시에 변경하면 접속이 복구돼도 원인을 알 수 없습니다.
- 원래 설정을 백업하고 문제가 발생한 시각과 실제 오류 로그를 기록하세요.
- 요청이 커널에 들어오는지 확인한 뒤 규칙이 예상한 출구를 선택했는지 확인하세요.
- 로그에 따라 DNS 조회, 연결 시도, 인증, TLS를 각각 확인하세요. 단계가 다른 원인을 넘겨짚지 마세요.
- 설정 하나를 변경한 뒤 다시 불러오고, 같은 요청의 새 로그를 확인해 오류가 사라졌는지 달라졌는지 살펴보세요.
- 평소 로그 수준으로 되돌린 뒤 브라우저와 자주 쓰는 터미널 프로그램에서 모두 확인하세요. 한 가지 프록시 경로만 해결된 것은 아닌지 점검해야 합니다.
유지관리자에게 문제를 제보할 때는 클라이언트 이름, 클라이언트와 커널의 실제 버전, 운영체제, 실행 모드, TUN 활성화 여부, 재현 절차, 관련 로그 앞뒤 약 20줄을 제공하세요. 버전은 ‘정보’ 메뉴나 커널 시작 로그에서 확인하고 클라이언트 버전을 커널 버전으로 착각하지 마세요.
전송하기 전에 구독 링크, 액세스 토큰, 프록시 비밀번호, 제어 API 키, 개인 정보를 드러낼 수 있는 도메인과 IP 주소를 삭제하세요. 비식별 처리 후에도 판단에 필요한 항목 구조, 포트, 오류 유형, 규칙 관계는 남겨 두세요. 구독 파일 전체를 공개하거나 인증서 검증을 끄고 방화벽을 장기간 비활성화해 원래 문제를 덮어서는 안 됩니다.