Clash Verge Rev 로그 확인 방법: 주요 오류와 원인 찾기
연결 시간 초과, DNS 조회 실패, 설정 파일 오류 등 로그에 자주 나타나는 문제를 설명하고, 로그 수준 변경과 키워드 검색으로 원인을 좁히는 방법을 안내합니다.
요청을 한 번 재현한 뒤 같은 시각의 로그를 확인하세요
Clash Verge Rev 로그를 보면 문제가 어느 단계에서 발생했는지 파악할 수 있습니다. 설정이 불러와졌는지, 도메인이 조회됐는지, 요청에 어떤 규칙이 적용됐는지, 프록시 노드에 연결할 수 있는지 확인하세요. 빨간색 오류가 표시되어도 모든 연결이 끊긴 것은 아닙니다. 실패 기록 하나만으로 구독이 만료됐다고 단정할 수도 없습니다. 먼저 어떤 동작에서 문제가 생겼는지 확인하고, 해당 시각 전후의 기록을 살펴보세요.
클라이언트 UI와 mihomo 코어는 담당하는 작업이 다릅니다. 구독 다운로드, UI 조작, 서비스 관리 관련 내용은 클라이언트 로그에 남을 수 있습니다. 프록시 연결, 규칙 매칭, DNS 처리는 주로 코어 로그에 기록됩니다. ‘구독 업데이트 실패’라면 먼저 업데이트 작업의 안내 메시지를 확인하고, ‘브라우저에서 웹페이지가 열리지 않음’이라면 코어의 연결 로그부터 살펴보세요.
- 사이드바에서 ‘로그’ 페이지를 열고 현재 시각을 기록하세요. 다른 다운로드나 속도 측정 작업은 잠시 중지합니다.
- 문제가 발생한 웹사이트 하나만 열어 새로고침하세요. 탭을 여러 개 동시에 열지 마세요.
- 로그에서 해당 시각의 대상 도메인, 포트, 오류 메시지를 찾으세요. 검색창이 있으면 키워드를 입력하고, 없다면 필요한 부분만 복사해 로컬 텍스트 편집기에서 검색합니다.
- ‘연결’ 페이지에서 대상 주소, 적용된 규칙, 프록시 체인을 확인하세요. 연결이 짧게 유지되면 금방 사라질 수 있으므로 이미 기록된 로그를 기준으로 판단합니다.
로그 수준 변경 방법: 평소에는 info, 문제를 찾을 때는 debug
로그 수준은 기록의 상세도를 정할 뿐, 연결 문제를 직접 해결하지는 않습니다. ‘로그’ 페이지 상단에서 로그 수준 선택 항목을 찾아보세요. 해당 기능이 있는 버전에서는 info에서 debug로 잠시 변경할 수 있습니다. UI에 필터만 있다면 ‘수신한 로그 필터링’과 ‘코어 로그 수준 변경’을 구분해야 합니다. 표시 필터만 바꿔서는 코어가 이전에 기록하지 않은 세부 정보가 추가로 나타나지 않습니다.
| 수준 | 기록 범위 | 사용 사례 |
|---|---|---|
silent | 로그 출력 안 함 | 현재 발생 중인 문제를 확인하기에는 적합하지 않음 |
error | 오류 | 명확한 실패만 확인하므로 사전 단서를 놓치기 쉬움 |
warning | 경고 및 오류 | 이상 상황을 확인할 수 있지만 일부 연결 과정은 표시되지 않음 |
info | 정보, 경고 및 오류 | 일상적인 사용 및 초기 원인 파악 |
debug | 디버그 세부 정보 추가 | DNS, 규칙 또는 연결 문제를 짧게 재현할 때 |
UI에 로그 수준 설정이 없는 경우
mihomo에서 사용하는 설정 항목은 최상위 log-level입니다. 설정 파일에서 변경해야 한다면 먼저 백업하세요. 현재 버전에서 지원하는 덮어쓰기 또는 병합 기능을 통해 아래 한 줄을 추가한 다음 설정을 다시 불러옵니다. 구독 업데이트 시 덮어쓰기될 원본만 수정하거나, 편집 후 설정이 자동으로 적용됐다고 가정하지 마세요.
log-level: debug문제를 재현한 뒤 더 자세한 로그가 나타나는지 확인해 설정이 적용됐는지 검증하세요. 문제 해결을 마치면 info로 되돌립니다. 디버그 로그에는 접속한 도메인, 내부 IP 주소, 프록시 이름이 포함될 수 있으므로 장시간 켜 두거나 전체 로그를 그대로 공개하지 마세요.
연결 시간 초과: 노드와 대상 웹사이트 중 어디서 발생했는지 확인
i/o timeout, context deadline exceeded, connect: connection timed out은 모두 작업이 제한 시간 안에 끝나지 않았다는 뜻이지만, 발생 지점은 서로 다를 수 있습니다. 오류 앞뒤에 dial tcp가 보이면 timeout이라는 문구만 보고 DNS를 바꾸지 말고, 연결을 시도한 IP 주소와 포트를 확인하세요.
dial tcp 203.0.113.10:443: i/o timeout
context deadline exceeded여기서 203.0.113.10은 문서용 예시 주소이며 실제 노드 연결 테스트에 사용할 수 없습니다. 실제 로그에 표시된 주소가 프록시 서버라면 내 PC에서 노드까지의 연결을 확인하세요. 요청에 DIRECT 규칙이 적용됐다면 해당 주소는 대상 웹사이트의 것일 수 있습니다. 프록시 체인이 여러 단계라면 어느 단계에서 실패했는지도 확인해야 합니다.
같은 대상을 기준으로 비교하기
- 노드 하나만 시간 초과되는 경우: 같은 정책 그룹에서 연결이 확인된 다른 노드로 바꾼 뒤 동일한 웹사이트에 접속해 보세요. 문제가 해결되면 기존 노드의 주소, 포트, 서버 상태 또는 네트워크 연결을 먼저 확인합니다.
- 여러 노드에서 모두 시간 초과되는 경우: 내 PC의 네트워크, 포털 로그인, 방화벽, 프록시 서버 주소의 DNS 조회 상태를 확인하세요. 여러 노드가 같은 도메인을 사용한다면 공통 진입점에 문제가 있을 수도 있습니다.
- 웹사이트 하나에서만 시간 초과되는 경우: 규칙과 외부 연결 경로를 확인하세요. 대상 서비스 장애, 외부 연결 제한, 라우팅 문제도 같은 증상을 일으킬 수 있습니다.
- 속도 측정은 성공하지만 웹페이지가 열리지 않는 경우: 속도 측정은 보통 설정된 테스트 URL에만 연결합니다. 임의의 웹사이트, UDP 트래픽 또는 모든 프로토콜이 정상 작동한다는 뜻은 아닙니다.
먼저 시간 초과 대기 시간을 크게 늘리지 마세요. 기다리는 시간만 길어질 뿐, 잘못된 노드 주소가 수정되거나 차단된 연결이 복구되지는 않습니다.
DNS 조회 실패: 주소를 찾지 못한 경우와 DNS 서버에 연결하지 못한 경우 구분
no such host, DNS resolve failed 또는 DNS 상위 서버 주소와 함께 표시되는 시간 초과가 발생하면 먼저 어떤 도메인의 조회가 실패했는지 확인하세요. 프록시 서버 도메인을 조회하지 못하면 여러 웹사이트가 한꺼번에 연결되지 않을 수 있습니다. 웹사이트 하나의 도메인에서 문제가 발생했다면 해당 도메인을 중심으로 확인하세요.
| 키워드 또는 증상 | 가능한 의미 | 우선 확인할 항목 |
|---|---|---|
no such host | 이번 조회에서 사용 가능한 결과를 얻지 못함 | 도메인 철자, 도메인 존재 여부, 현재 DNS 조회 경로 |
| DNS 요청 시간 초과 | 상위 DNS 서버가 제시간에 응답하지 않음 | DNS 서버 연결 가능 여부, 상위 서버로 연결되는 경로 |
connection refused | DNS 서버 주소 또는 포트에서 연결 거부 | 로컬 DNS 서비스 실행 여부, 수신 주소와 포트 |
| 프록시 서버 도메인만 조회 실패 | 프록시 연결을 설정하기 전 DNS 조회 단계에서 문제 발생 | 노드 도메인 조회와 프록시 간 의존 관계 |
시스템 DNS 테스트 결과가 코어 DNS 테스트 결과와 같지는 않습니다
시스템 명령으로 비교해 볼 수 있습니다. 아래 명령은 문서용 예시 도메인을 조회합니다.
nslookup example.com시스템 조회가 성공했다면 해당 명령이 이용한 DNS 경로에서 결과를 받았다는 뜻일 뿐입니다. mihomo는 별도의 dns.nameserver, 암호화 DNS, 도메인별 정책 또는 프록시 서버 전용 DNS 설정을 사용할 수 있으므로 결과를 그대로 서로 비교할 수는 없습니다. 브라우저의 보안 DNS도 별도의 조회 경로일 수 있습니다.
TUN을 사용 중이라면 DNS 가로채기가 예상한 트래픽을 처리하는지도 확인하세요. Fake-IP 모드에서는 연결 정보에 설정된 가상 주소 대역이 표시되어도 반드시 문제인 것은 아닙니다. 예를 들어 198.18.0.0/16은 Fake-IP 주소 풀로 자주 사용됩니다. 최종 연결 상태는 도메인 매핑 및 규칙과 함께 확인하세요. 주소만 보고 DNS 설정 전체를 삭제하지 마세요.
설정 파일 파싱 오류: 줄 번호와 들여쓰기를 확인한 뒤 필드 참조를 점검하세요
설정을 불러오지 못하는 문제는 보통 연결이 시작되기 전에 발생합니다. 흔한 메시지로는 yaml: line 12: did not find expected key, 필드 유형 불일치, 규칙에서 참조한 정책 그룹이 없는 경우 등이 있습니다. 이때 노드를 계속 바꿔도 해결되지 않습니다. 먼저 설정 파일이 정상적으로 파싱되고 코어 검증을 통과하도록 수정하세요.
들여쓰기 오류와 필드 유형 오류
# 잘못된 예시: nameserver의 들여쓰기 단계가 맞지 않음
dns:
enable: true
nameserver:
- 1.1.1.1
# 올바른 예시: 같은 단계의 필드를 맞추고 목록은 nameserver 아래에 배치
dns:
enable: true
nameserver:
- 1.1.1.1YAML 들여쓰기는 공백을 사용하고 Tab은 섞지 마세요. 줄 번호는 파서가 문제를 발견한 위치를 가리키는 경우가 많지만, 실제 오류는 바로 앞 줄에 있을 수 있습니다. 콜론 누락, 닫히지 않은 따옴표, 잘못된 목록 들여쓰기가 있는지 확인하세요. 오류가 표시된 줄뿐 아니라 앞뒤 몇 줄도 함께 살펴보세요.
- 필드 유형:
mixed-port: 7897에는 포트 번호를 입력해야 합니다. 목록 필드를 임의로 하나의 긴 문자열로 바꾸면 안 됩니다. - 이름 참조: 규칙에 지정된 정책 이름은 실제 프록시 또는 정책 그룹과 일치해야 합니다. 정책 그룹 이름을 바꿨다면
rules에서 참조하는 이름도 함께 확인하세요. - 규칙 제공자:
RULE-SET에서 참조하는 이름은rule-providers에 정의되어 있어야 합니다. 다운로드 실패와 이름이 정의되지 않은 문제는 서로 다릅니다. - 설정 출처: 구독을 업데이트한 뒤에만 실패한다면 오류 메시지와 이전 설정을 먼저 보존하세요. 구독 응답 내용에 문제가 있는지, 로컬 덮어쓰기 설정이 새 설정과 충돌하는지 확인합니다.
포트 연결 거부와 주소 사용 중: 오류에 표시된 주소의 위치를 확인하세요
connection refused는 연결이 명시적으로 거부됐다는 뜻입니다. 주소가 127.0.0.1:7897이라면 원격 노드가 아니라 내 PC의 프록시가 해당 포트에서 연결을 받고 있는지 확인하세요. 클라이언트에서 ‘설정’을 열어 현재 혼합 포트를 확인하고 코어가 정상 실행 중인지 살펴봅니다. 앱에 프록시 포트를 직접 입력했다면 해당 포트도 혼합 포트와 일치해야 합니다.
connect to 127.0.0.1:7897: connection refused
listen tcp 127.0.0.1:7897: bind: address already in use두 번째 오류는 해당 포트를 다른 프로세스가 사용 중이라는 뜻입니다. Windows에서는 터미널에서 아래 명령을 실행해 포트의 수신 정보와 PID를 확인할 수 있습니다.
netstat -ano | findstr :7897macOS와 lsof가 설치된 Linux에서는 같은 TCP 포트를 수신 중인 프로세스를 확인할 수 있습니다.
lsof -nP -iTCP:7897 -sTCP:LISTEN먼저 해당 프로세스가 무엇인지 확인하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. 클라이언트 혼합 포트를 7898로 변경한다면 브라우저 확장 프로그램, 터미널 환경 변수, 기타 수동 프록시 설정도 함께 업데이트해야 합니다. 시스템 프록시를 사용하는 앱은 시스템 프록시가 이전 포트를 계속 가리키지 않는지 다시 확인하세요.
연결 거부가 원격 노드 주소에서 발생했다면 노드 포트와 서버 상태를 확인하세요. 같은 오류 키워드라도 주소가 다르면 확인해야 할 대상이 달라집니다.
TLS 오류, 연결 재설정, TUN 문제 구분하기
TLS 인증서 및 핸드셰이크 오류
x509: certificate has expired or is not yet valid가 표시되면 먼저 시스템의 날짜, 시간, 시간대를 확인한 다음 서버 인증서의 유효 기간을 살펴보세요. certificate is valid for와 같은 메시지는 인증서 도메인이 일치하지 않는 문제일 수 있습니다. 노드 서버 주소, TLS 서비스 이름, 구독 매개변수를 확인하세요.
TLS handshake timeout은 인증서 오류와 같지 않습니다. 연결 차단, 패킷 손실, 원격 서버가 예상대로 응답하지 않는 상황에서도 발생할 수 있습니다. 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요. 모든 핸드셰이크 실패를 해결하지 못할 뿐 아니라 인증 기능을 약화시킵니다.
연결 재설정과 EOF
connection reset by peer는 상대방이나 네트워크 중간 장비가 연결을 재설정했다는 뜻입니다. EOF 및 unexpected EOF는 연결이 끝나 데이터를 읽지 못했다는 의미입니다. 대상 서버, 프록시 서버, 중간 네트워크에서 발생할 수 있으므로 이 키워드만으로 책임 소재를 판단할 수는 없습니다.
웹페이지를 닫거나 다운로드를 끝낸 뒤에만 기록되고 실제 이용에는 문제가 없다면 우선 지켜봐도 됩니다. 같은 주소에 접속할 때마다 즉시 실패한다면 대상, 사용한 노드, 발생 시각을 기록한 뒤 노드나 네트워크를 바꿔 비교해 보세요.
TUN 생성 실패와 권한 문제
가상 네트워크 인터페이스, 라우트 설정, 권한과 관련된 오류가 발생하면 먼저 클라이언트 서비스 모드가 정상인지, 현재 시스템에서 가상 네트워크 인터페이스를 만들 수 있는지 확인하세요. TUN은 네트워크 트래픽을 처리할 뿐, 노드 자체의 장애를 해결하지는 않습니다. 시스템 프록시는 정상인데 TUN만 실패한다면 가상 인터페이스, 라우팅, 다른 VPN과의 충돌을 중점적으로 확인하세요.
테스트할 때 TUN, DNS, 노드, 규칙을 동시에 바꾸지 마세요. 먼저 현재 설정을 기록하고 한 번에 하나씩만 변경합니다. 두 가지 트래픽 처리 방식을 자세히 알아보려면 클라이언트 사용 가이드를, 설정 항목의 의미를 확인하려면 고급 설정을 참고하세요.
키워드로 문제 범위를 좁히고 재현 가능한 기록을 남기세요
유용한 기록은 ‘어떤 동작이 실패했는지’와 ‘관련 로그가 무엇인지’를 연결해 줍니다. 전체 error 로그만 골라 보는 것보다 대상 도메인을 먼저 검색한 뒤 같은 시간대의 오류를 확인하는 편이 대개 더 효과적입니다. 백그라운드 상태 확인, 규칙 세트 업데이트, 다른 앱에서도 로그가 생성될 수 있으므로 모든 이상 현상을 현재 웹페이지 문제로 단정하지 마세요.
- 환경 기록: 운영체제, 실제 클라이언트 버전, 실제 mihomo 버전, 시스템 프록시와 TUN 사용 여부를 적어 두세요. 설치 시점으로 버전을 추정하지 말고 클라이언트에 표시된 정보를 확인합니다.
- 재현 절차 고정: 대상 URL, 발생 시각, 앱 이름, 구체적인 증상을 기록하세요. 예: ‘페이지가 계속 로딩됨’, ‘프록시 연결 실패 메시지가 바로 표시됨’.
- 주변 로그 보존: 처음 실패한 시점 전후로 관련 로그를 약 10~20줄 복사하세요. 시각, 오류 키워드, 포트, 규칙 정보를 포함합니다.
- 한 가지 조건만 비교: 노드만 바꾸거나 네트워크만 바꾸고 문제가 해결됐는지 기록하세요. 설정을 전부 다시 작성한 뒤 특정 스위치 하나가 효과가 있었다고 단정하지 마세요.
- 평소 설정으로 복구: 로그 수준을
info로 되돌리고 임시 테스트 설정을 취소한 뒤 정상 동작이 확인된 설정을 저장하세요.
문제 해결 순서는 다음과 같이 정리할 수 있습니다. 설정이 불러와졌는지 → 로컬 포트가 수신 중인지 → 도메인이 조회되는지 → 예상한 규칙이 적용되는지 → 노드와 대상에 연결되는지 확인하세요. 연결 과정에서 가장 먼저 실패한 단계를 해결한 다음 이후 오류를 살펴봅니다. 이렇게 하면 불필요한 설정 변경을 줄이고 한 번의 실패로 생긴 여러 로그를 각각 다른 문제로 오해하는 일을 막을 수 있습니다.