1. 노드 속도 측정 실패와 실제 연결 실패 구분하기
Clash에서 Timeout은 특정 작업이 제한 시간 안에 끝나지 않았다는 뜻일 뿐, 노드가 사용할 수 없게 됐다는 의미는 아닙니다. 노드 지연 시간 측정은 보통 노드를 통해 테스트 URL에 요청을 보내는 방식이므로, 서버까지의 네트워크 지연뿐 아니라 요청 경로 전체를 측정합니다. 테스트 사이트에 접속할 수 없거나 도메인 이름 확인에 실패하거나 TLS 핸드셰이크에 문제가 있어도 시간 초과가 발생할 수 있습니다.
이 글에서는 Clash Verge Rev와 mihomo 커널을 사용하는 경우를 예로 듭니다. 먼저 ‘프록시’ 페이지에서 현재 실행 모드와 대상 정책 그룹, 선택된 노드를 확인합니다. 그런 다음 ‘연결’과 ‘로그’ 페이지를 열어 오류가 발생한 시점의 기록을 보관하세요. 버전에 따라 화면 이름이 다를 수 있으므로 실제 포트와 설정값을 기준으로 확인해야 합니다.
- 노드 하나만 실패하는 경우: 해당 노드의 주소, 포트, 프로토콜 설정과 서버 상태를 먼저 확인하세요.
- 모든 노드가 실패하는 경우: 로컬 연결 지점, 구독 계정, DNS, 현재 네트워크부터 확인하세요. 노드 설정을 한꺼번에 바꾸지는 마세요.
- 속도 측정은 실패하지만 웹사이트는 열리는 경우: 테스트 URL과 시간 초과 기준을 확인하세요. 측정 결과의 색상만 보고 노드를 삭제하지 마세요.
- 속도 측정은 정상이지만 웹사이트가 열리지 않는 경우: 앱 트래픽이 커널로 전달되는지, 어떤 규칙과 정책 경로가 적용되는지 확인하세요.
2. 시스템 프록시, 수신 포트, 로컬 연결 확인하기
요청이 커널로 전달되는지 확인하기
먼저 ‘설정’에서 ‘시스템 프록시’ 상태와 현재 프록시 포트를 확인한 뒤, 운영체제의 네트워크 설정에 실제로 입력된 주소를 살펴보세요. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’에서 확인할 수 있습니다. 일반적인 로컬 프록시 주소는 127.0.0.1이며, 포트는 클라이언트가 실제로 수신 중인 포트와 일치해야 합니다.
포트가 반드시 7890 또는 7897이라고 단정하지 마세요. 아래에서는 현재 설정이 mixed-port: 7897인 경우를 예로 듭니다. mixed-port는 HTTP와 SOCKS 요청을 모두 받는 혼합 프록시 포트입니다. Windows PowerShell에서 다음 명령을 실행할 수 있습니다.
Get-NetTCPConnection -LocalPort 7897 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
curl.exe --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/macOS 또는 Linux에서는 다음 명령으로 같은 연결 지점을 확인할 수 있습니다. 설정된 포트가 다르면 명령의 숫자를 먼저 바꾸세요.
lsof -nP -iTCP:7897 -sTCP:LISTEN
curl --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/- 로컬 포트 연결에 즉시 실패하는 경우: 커널이 실행되지 않았거나 실제 포트가 다를 수 있습니다. 원격 노드를 확인하기 전에 로컬 수신 상태부터 해결하세요.
- 로그에 address already in use가 표시되는 경우: 다른 프로세스가 포트를 사용 중입니다. 프로세스 이름을 확인하고 중복 실행된 프록시 클라이언트를 종료하거나, 클라이언트에서 포트를 바꾼 뒤 시스템 프록시 설정을 다시 동기화하세요.
- 명령은 성공하지만 브라우저에서는 연결되지 않는 경우: 브라우저 프록시 확장 프로그램, 별도 프록시 설정, 캐시된 기존 연결을 확인하세요. 기존 연결을 닫고 다시 시도하세요.
이 curl 명령은 요청이 로컬 프록시로 전달되는지만 확인하며, 규칙에 따라 원격 노드가 선택됐다는 뜻은 아닙니다. 요청이 DIRECT로 처리될 수도 있으므로 ‘연결’ 페이지에서도 확인해야 합니다. HTTP 응답이 왔다고 해서 대상 서비스까지 정상이라는 의미는 아니지만, 요청이 응답 단계까지 진행됐다는 점은 확인할 수 있습니다.
TUN과 시스템 프록시를 따로 확인하기
시스템 프록시는 운영체제 설정을 따르는 앱에만 영향을 줍니다. 반면 TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 처리합니다. TUN을 켰을 때만 문제가 생기면 기존 설정을 기록한 다음 TUN을 끄고, 시스템 프록시와 위의 명시적 프록시 명령으로 기본 상태를 확인하세요. 기본 상태에서 정상이라면 TUN의 서비스 권한과 라우팅을 살펴보고 다른 VPN과 충돌하는지도 확인하세요.
설정을 바꾸기 전에 구성 파일을 백업하세요. 문제를 확인하는 대신 시스템 방화벽을 계속 꺼 두거나, 용도를 모른 채 가상 네트워크 인터페이스를 삭제하지 마세요. 회사 장비의 라우팅과 보안 정책은 먼저 관리자에게 확인해야 합니다.
3. 구독 업데이트, 계정 상태, 현재 설정 확인하기
‘설정’ 페이지에서 오래된 로컬 설정이 아니라 의도한 구독을 사용 중인지 확인하세요. 해당 구독을 한 번 업데이트하고 결과를 확인합니다. 구독 다운로드 성공은 설정 파일을 가져왔다는 뜻일 뿐, 계정에 잔여 트래픽이 있거나 모든 노드가 온라인 상태라는 뜻은 아닙니다. 새 설정이 현재 활성 설정으로 적용됐는지도 별도로 확인해야 합니다.
- 서비스 제공업체 계정에서 만료일과 잔여 트래픽, 동시 연결 제한을 확인하세요. 트래픽 정보가 표시되지 않으면 계정 관리 페이지의 내용을 기준으로 판단하세요.
- 업데이트 전후의 노드 수와 이름을 비교해 서비스 제공업체가 노드 주소나 프로토콜을 변경했는지 확인하세요.
- 설정이 활성화됐는지 확인한 다음 ‘프록시’ 페이지에서 정책 그룹의 선택 항목을 다시 확인하세요.
- 업데이트에 실패했다면 구독 요청의 HTTP 오류, 다운로드 시간 초과, 설정 파싱 오류를 구분하세요. 이 모두를 노드 시간 초과로 묶어 부르지 마세요.
HTTP 401 또는 403은 인증 정보 만료, 접근 제한, 계정 상태와 관련이 있을 수 있으므로 서비스 제공업체의 안내와 함께 확인해야 합니다. YAML 파싱 오류는 대개 커널이 설정을 불러오기 전에 발생합니다. 이때는 반복해서 속도를 측정할 것이 아니라 구독 내용이나 호환성 문제를 해결해야 합니다.
4. DNS 확인하기: 노드 도메인과 대상 도메인 구분
프록시 연결에는 최소 두 종류의 DNS 조회가 관여할 수 있습니다. 하나는 노드 서버의 도메인이고, 다른 하나는 접속하려는 웹사이트의 도메인입니다. 노드 도메인 조회에 실패하면 커널이 원격 서버 주소를 알아내지 못합니다. 웹사이트 도메인 조회에 실패하면 노드는 정상이어도 특정 사이트에 접속할 수 없습니다. 로그에 표시된 구체적인 도메인은 막연히 ‘DNS 문제’라고 하는 것보다 훨씬 유용한 단서입니다.
먼저 시스템 DNS 조회를 확인하고 커널 DNS를 살펴보기
Windows에서는 Resolve-DnsName example.com, macOS 또는 Linux에서는 nslookup example.com을 실행해 시스템 DNS 조회 결과를 확인할 수 있습니다. 실제 노드를 확인할 때는 구독 설정의 서버 필드에 해당하는 도메인을 사용하세요. 인증 정보가 포함된 구독 링크를 노드 도메인으로 사용하면 안 됩니다.
이 명령은 기본적으로 시스템 DNS 조회 경로를 확인하며 mihomo 내부 DNS가 정상이라는 점까지 증명하지는 않습니다. 설정에서 dns.enable을 활성화했다면 실제 설정의 nameserver, proxy-server-nameserver와 관련 정책도 확인하세요. 후자는 노드 도메인 조회에 사용할 업스트림 서버를 지정합니다. DoH를 사용한다면 DoH 서버 도메인의 최초 조회 방법도 고려해야 합니다.
- 로그에 lookup 또는 no such host가 표시되는 경우: 도메인 철자와 업스트림 DNS 연결 상태를 확인하고, 시스템 DNS와 커널 DNS 중 어느 쪽에서 실패했는지 구분하세요.
- 주소가 조회됐는데도 시간 초과가 발생하는 경우: 해당 주소와 포트의 연결을 계속 확인하세요. 모든 시간 초과를 DNS 탓으로 돌리면 안 됩니다.
- 198.18.0.0/16 주소가 표시되는 경우: Fake-IP 모드에서는 정상적인 매핑일 수 있습니다. 주소만 보고 조회 오류라고 판단하지 말고 요청이 커널을 통해 처리되는지 확인하세요.
공개 DNS 주소를 한꺼번에 많이 추가하지 마세요. 기존 설정을 유지한 채 업스트림 서버에 현재 네트워크에서 접속할 수 있는지 확인하세요. DNS 요청은 프록시를 거쳐야 하는데 노드 시작에 같은 경로의 DNS 조회가 필요하면 순환 의존성이 생길 수 있습니다. DNS와 트래픽 분배의 기본 개념은 프로토콜 가이드에서 확인할 수 있습니다.
5. 로그 단계별로 연결이 끊긴 지점 찾기
‘로그’ 페이지를 열고 재현하기 전에 화면을 지우거나 시간을 기록한 다음 요청을 한 번만 보내세요. 일반 로그만으로 부족하면 로그 수준을 잠시 debug로 바꿔도 됩니다. 확인이 끝나면 info로 되돌려 불필요한 로그가 계속 쌓이지 않게 하세요. 로그에는 접속 도메인과 서버 주소가 포함될 수 있으므로 공유 전에 민감 정보를 가려야 합니다.
| 로그 단서 | 가능한 단계 | 다음 조치 |
|---|---|---|
connection refused | 연결이 명시적으로 거부됨 | 오류가 발생한 주소를 확인하세요. 로컬 주소라면 수신 상태를, 원격 주소라면 서버와 포트를 점검하세요. |
i/o timeout | 네트워크 작업 시간 초과 | 주변 로그를 확인해 DNS, TCP, TLS, 읽기·쓰기 중 어느 단계에서 발생했는지 판단하세요. |
network is unreachable | 라우팅 또는 주소 체계 | 기본 경로, IPv6 연결 가능 여부, VPN 라우팅 충돌을 확인하세요. |
x509 관련 오류 | 인증서 검증 | 시스템 시간, 인증서 이름, SNI, 서버 인증서 설정을 확인하세요. |
EOF 또는 connection reset | 연결이 예상보다 일찍 종료됨 | 프로토콜 설정, 서버 로그, 중간 네트워크 장비를 확인하세요. |
오류 한 줄만으로는 원인을 확정하기 어렵습니다. 예를 들어 EOF는 프로토콜이 맞지 않을 때뿐 아니라 원격 서버가 연결을 끊을 때도 발생할 수 있습니다. 마지막의 ‘요청 실패’ 메시지가 아니라 관련 오류가 처음 나타난 시점을 찾는 것이 중요합니다. 설정을 불러오는 단계에서 모든 요청이 실패한다면 네트워크를 분석하기 전에 설정 오류부터 해결하세요.
6. 노드 프로토콜 설정과 원격 포트 확인하기
로컬 연결 지점과 구독, DNS가 정상이라면 노드의 server, port, 프로토콜 유형을 확인하세요. TCP 포트 검사로 확인할 수 있는 것은 연결이 성립하는지뿐이며, 인증이나 암호화, 프록시 전달이 성공했는지는 알 수 없습니다. Windows에서는 실제 서버와 포트를 지정해 Test-NetConnection으로 TCP 연결을 확인할 수 있습니다. UDP 프로토콜은 같은 결과로 판단할 수 없습니다.
- Shadowsocks: 암호화 방식과 비밀번호, 플러그인 요구 사항을 확인하세요. 암호화 방식 이름은 서버 설정과 일치해야 합니다.
- VMess / VLESS: UUID와 전송 방식, TLS 관련 설정을 확인하세요. VLESS의 flow 등 필드는 서버 설정과 일치해야 합니다.
- TLS / WebSocket: SNI, Host, 경로를 확인하세요. 서버 연결 주소와 TLS 이름, HTTP Host는 서로 다를 수 있으므로 모두 같은 IP로 바꾸면 안 됩니다.
- REALITY: 서비스 제공업체가 안내한 공개 키, short-id, server-name 등의 매개변수를 확인하세요. 서버 주소만 복사해서는 안 됩니다.
- Hysteria2 / TUIC: 일반적으로 UDP를 사용합니다. 같은 네트워크에서 TCP 노드는 되는데 이 노드들만 실패한다면 네트워크가 UDP를 제한하는지, 로컬 보안 정책이 차단하는지 확인하세요.
인증서 오류가 발생하면 먼저 시스템 날짜와 시간, 시간대를 동기화한 뒤 서버 인증서와 이름이 일치하는지 확인하세요. 인증서 검증을 건너뛰는 설정을 장기적인 해결책으로 삼지 않는 것이 좋습니다. 커널에서 지원하지 않는 필드가 설정에 있다면 클라이언트와 커널의 실제 버전을 기록하고 서비스 제공업체의 안내에 따라 호환성을 확인하세요. 화면에 표시된 클라이언트 버전만으로 모든 프로토콜을 지원한다고 판단하면 안 됩니다.
7. 규칙 적용과 교차 테스트로 마무리하기
마지막으로 ‘연결’ 페이지로 돌아가 대상 웹사이트를 다시 열고 적용된 규칙과 정책 그룹, 최종 노드를 확인하세요. Rule 모드에서는 일부 요청이 DIRECT로 처리되는 것이 정상일 수 있습니다. REJECT는 규칙에 의해 요청이 거부됐다는 뜻이지 노드 시간 초과가 아닙니다. 정책 그룹 안에 자동 선택 그룹이 중첩될 수도 있으므로 바깥 그룹을 선택했다고 해서 특정 노드가 고정된 것은 아닙니다.
변경 범위를 늘리지 않도록 최소한의 조건으로 비교하기
- 같은 노드와 같은 대상을 유지한 채 시스템 프록시 요청과 명시적 프록시 요청을 비교해 앱 트래픽이 제대로 전달되는지 확인하세요.
- 규정을 준수하고 허용된 네트워크 환경에서 현재 네트워크와 휴대폰 핫스팟을 비교하세요. 한 네트워크에서만 실패한다면 해당 네트워크의 DNS, 포트, UDP 제한을 먼저 확인하세요.
- 네트워크는 그대로 두고 정상 작동이 확인된 다른 노드로 바꿔 보세요. 특정 노드만 실패한다면 해당 노드와 오류 발생 시간을 서비스 제공업체에 전달하세요.
- 규칙의 영향을 잠시 배제하기 위해 Global 모드를 사용했다면 테스트 후 원래 모드로 되돌리고 연결 경로를 다시 확인하세요.
지원팀에 문의할 때는 운영체제와 클라이언트, 커널 버전, 오류 발생 시각과 시간대, 노드 프로토콜, TUN 사용 여부, 민감 정보를 가린 로그, 두 가지 비교 테스트 결과를 함께 보내세요. 속도 측정 화면이 전부 빨갛게 나온 스크린샷만 보내면 안 됩니다. 요청이 어느 단계에서 실패했는지 알 수 없기 때문입니다.