프록시 노드 시간 초과, 인터넷은 정상일 때: 구독 상태·DNS·연결 경로 점검 순서
로컬 연결, 구독 유효성, 노드 매개변수, DNS와 프록시 적용을 단계별로 점검해 테스트 주소 접근 불가와 실제 연결 실패를 구분하고 반복적인 재설치를 피하세요.
1. 지연 테스트 시간 초과와 실제 연결 실패 구분하기
브라우저에서 평소 이용하는 로컬 웹사이트가 열리는데 Clash 클라이언트에서 노드가 “시간 초과”로 표시될 수 있습니다. 이는 모순이 아닙니다. 로컬 인터넷 연결은 특정 직접 연결 경로가 정상이라는 것만 보여 줍니다. 노드 지연 테스트는 보통 프록시 서버, 프로토콜 핸드셰이크, 지정된 테스트 주소를 거칩니다. 어느 한 단계라도 실패하면 화면에는 같은 시간 초과 메시지로 표시될 수 있습니다.
클라이언트는 화면, 구독, 설정 관리를 담당하고, 코어는 프록시 연결, 규칙, DNS 등을 처리합니다. Clash와 Clash Meta(현재는 흔히 mihomo라고 부름)는 지원하는 필드와 동작이 다르며, 클라이언트마다 테스트 메뉴, 기본 URL, 시간 초과 기준도 완전히 같지 않습니다. 문제를 점검할 때는 애플리케이션 이름만 기억하지 말고 클라이언트 버전과 실제 실행 중인 코어 버전을 기록해야 합니다.
| 현상 | 우선 점검 | 아직 단정할 수 없는 결론 |
|---|---|---|
| 지연 테스트 시간 초과, 실제 웹페이지는 정상 | 테스트 URL, 예상 상태 코드, 테스트 기준 시간 | 노드가 이미 만료됨 |
| 노드 하나만 실패 | 해당 노드의 매개변수, 서비스 상태, 연결 경로 | 클라이언트 전체가 비정상 |
| 같은 구독의 모든 노드가 실패 | 계정 상태, 공통 매개변수, DNS 및 로컬 프록시 적용 | 반드시 재설치해야 함 |
| 브라우저는 정상, 특정 애플리케이션만 작동하지 않음 | 애플리케이션의 시스템 프록시 준수 여부와 UDP 사용 여부 | 모든 프록시 트래픽이 정상 |
2. 로컬 인터넷 연결 확인: 포털 인증과 프록시 잔여 설정 배제
먼저 현재 설정을 저장한 다음 클라이언트의 시스템 프록시와 TUN 적용을 끄세요. 다른 VPN이나 프록시 애플리케이션이 있다면 사용 권한을 확인한 후 종료합니다. 창을 닫는 것만으로 백그라운드 서비스가 중지되거나 시스템 프록시가 삭제되는 것은 아니므로 트레이 아이콘만 보지 말고 시스템 설정을 확인해야 합니다.
Windows에서 직접 연결 기준선 확인
- Windows 11의 「설정」→「네트워크 및 인터넷」→「프록시」를 열고 자동 설정 스크립트와 수동 프록시의 기존 상태를 기록하세요. 조직에서 배포한 설정은 임의로 변경하지 마세요.
- 평소 직접 연결되는 웹사이트 두 곳에 접속해 Wi-Fi가 호텔, 학교 또는 공용 핫스팟의 인증 페이지에 멈춰 있지 않은지 확인하세요. 라우터 관리 페이지가 열리는 것은 로컬 네트워크가 연결되어 있다는 것만 의미합니다.
- 「설정」→「시간 및 언어」→「날짜 및 시간」에서 날짜, 시간대와 시간 동기화가 정상인지 확인하세요. 시계가 크게 어긋나면 TLS 인증서 검증이 실패할 수 있습니다.
시스템에 curl이 설치되어 있다면 PowerShell에서 아래 직접 연결 요청을 실행할 수 있습니다. Windows에서는 curl.exe를 사용해 일부 PowerShell 환경에서 curl이 다른 명령으로 해석되는 일을 피하세요. macOS와 Linux에서는 명령어 이름을 curl로 바꾸면 됩니다.
curl.exe --noproxy "*" --connect-timeout 5 --max-time 15 -I https://example.com/--noproxy "*"는 curl이 설정된 명시적 프록시를 사용하지 않도록 하지만, 실행 중인 TUN, 투명 게이트웨이 또는 조직 네트워크 정책을 우회하지는 못합니다. 여기서 example.com은 예시 대상일 뿐이며 직접 연결이 확인된 주소로 바꿀 수 있습니다. 예시 사이트 하나에 접근할 수 없다고 해서 로컬 인터넷이 끊긴 것은 아닙니다. 5초는 연결 단계의 상한이고 15초는 이번 작업 전체의 상한이며, 둘 다 실제 지연 시간이 아닙니다.
3. 구독 상태 확인: 업데이트 성공이 노드 사용 가능을 의미하지는 않음
클라이언트에서 현재 사용하는 설정의 세부 정보를 열어 최근 업데이트 성공 여부, 노드 수가 예상과 일치하는지, 업데이트 후 실제로 이 설정으로 전환되었는지 확인하세요. 일부 클라이언트는 이전 설정을 계속 실행할 수 있으므로 “노드 목록이 남아 있다”는 사실만으로 방금 구독 업데이트가 성공했다고 볼 수 없습니다.
- 계정 상태: 구독 제공업체의 계정 페이지에서 유효 기간, 잔여 트래픽, 기기 또는 동시 접속 제한을 확인하세요. 클라이언트에 사용량 정보가 표시되지 않는다고 해서 트래픽이 충분하다고 판단해서는 안 됩니다.
- 응답 상태:
401또는403은 인증이나 접근 정책 문제를 의미합니다.429가 나오면 잦은 업데이트를 중단하고 기다리는 것이 일반적이며,5xx는 우선 서버 상태를 확인하세요. - 응답 내용: HTTP
200이어도 로그인 페이지나 오류 설명이 반환될 수 있습니다. 전체 YAML, 노드만 포함된 데이터, 단일 노드 공유 링크는 같은 가져오기 메뉴에서 처리되지 않을 수 있습니다. - 업데이트 경로: 일부 클라이언트에서는 구독 업데이트에 직접 연결 또는 프록시 사용을 선택할 수 있습니다. 업데이트에 필요한 노드가 이미 만료되었다면 “업데이트에는 프록시가 필요하지만 프록시에는 새 구독이 필요한” 순환이 발생할 수 있습니다.
클라이언트에 관련 설정이 명확히 제공되는 경우에만 구독 업데이트 경로를 바꿔 한 번 수동 업데이트하고 로그를 확인하세요. 업데이트 버튼을 연속해서 누르지 말고, 개인 구독 URL을 공개 온라인 변환 또는 진단 서비스에 붙여 넣지 마세요. URL의 토큰은 대개 접근 자격 증명입니다.
4. 노드 매개변수 확인: 포트 연결과 프로토콜 핸드셰이크 분리하기
실패한 노드 하나를 선택해 프로토콜, server, port와 인증 매개변수를 확인하세요. TLS, WebSocket 또는 gRPC를 사용하는 노드는 서비스 제공자가 지정한 서버 이름, 전송 유형, 경로 또는 서비스 이름도 확인해야 합니다. Reality 등의 확장 매개변수는 코어 지원이 필요하므로 다른 프로토콜의 필드를 임의로 가져와 사용해서는 안 됩니다.
먼저 노드 서버의 TCP 포트 확인
다음은 Windows PowerShell에서 대화형으로 확인하는 방법입니다. 실행할 때 현재 노드의 실제 서버 주소와 포트를 입력하세요. 서버 주소에는 호스트 이름 또는 IP만 입력하고 https:// 접두사나 구독 URL은 입력하지 않습니다.
$nodeHost = Read-Host "노드 server 주소 입력"
$nodePort = [int](Read-Host "노드 port 값 입력")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort -InformationLevel Detailed이 확인은 TUN 등의 적용을 끈 직접 연결 기준선에서 수행해야 합니다. 그렇지 않으면 결과가 기존 프록시를 거칠 수 있습니다. TcpTestSucceeded: True는 해당 TCP 연결이 성공적으로 수립되었다는 것만 증명하며, 비밀번호, UUID, TLS 또는 프록시 프로토콜이 올바르다는 뜻은 아닙니다. 결과가 False이면 주소 해석, 원격 수신 대기 상태, 중간 네트워크 제한을 계속 확인하세요.
UDP 노드를 일반적으로 검사하는 도구는 아닙니다. 예를 들어 QUIC 기반 프록시 프로토콜은 주로 UDP를 사용하므로 TCP 포트 테스트 실패만으로 사용할 수 없다고 판단할 수 없습니다. 마찬가지로 ping은 ICMP를 테스트합니다. 서버가 ICMP에 응답하지 않아도 프록시 서비스는 정상적으로 제공할 수 있습니다.
- 포트에는 연결되지만 로그에 인증 실패가 표시된다면 계정과 노드 매개변수를 확인하고, DNS는 아직 조정하지 마세요.
- 인증서 이름 불일치가 발생하면 서버 이름, 시스템 시간, 서버 인증서를 확인하세요. 인증서 검증을 끄는 것을 일반적인 해결 방법으로 사용하지 마세요.
- 특정 네트워크에서만 실패한다면 허용되는 경우 같은 기기에서 모바일 핫스팟으로 전환해 다시 테스트하고 차이를 기록하세요. 한 번의 네트워크 전환 결과만으로 통신사 제한이라고 단정하기에는 부족합니다.
5. DNS 점검: 노드 도메인과 대상 도메인을 따로 확인
프록시 연결에는 적어도 두 종류의 도메인이 관련될 수 있습니다. 하나는 노드 서버 자체의 도메인이고, 다른 하나는 브라우저가 접속하려는 대상 도메인입니다. 전자의 해석이 실패하면 연결이 아직 노드에 도달하지 못한 경우가 많습니다. 후자의 해석 방식은 프로토콜, DNS 설정, 트래픽이 코어로 들어오는 방식에 따라 달라집니다.
앞 단계의 PowerShell 창에서 다음 명령을 실행하면 시스템이 노드 도메인을 해석한 결과를 확인할 수 있습니다. server가 이미 IP 주소라면 이 단계는 건너뛰어도 됩니다.
Resolve-DnsName -Name $nodeHost -Type A
Resolve-DnsName -Name $nodeHost -Type AAAAAAAA 레코드가 없다고 반드시 이상인 것은 아니며, AAAA 레코드가 있다고 해서 현재 네트워크의 IPv6 경로가 사용 가능하다는 뜻도 아닙니다. 로그에 IPv6 주소로 연결을 시도하다 시간 초과가 발생하고 IPv4 경로는 정상이라면 IPv6 연결과 코어의 주소 선택 설정을 확인하세요. 곧바로 시스템 전체에서 IPv6를 영구적으로 비활성화하지는 마세요.
시스템에서는 정상적으로 해석되는데 코어에서는 왜 오류가 발생할까?
- 코어가 자체 DNS 처리를 활성화해 시스템과 다른 업스트림을 사용할 수 있으므로, 시스템 명령의 성공이 코어 로그를 대신할 수는 없습니다.
- 암호화된 DNS 업스트림 자체에 도메인 해석이나 프록시 경로가 필요할 수 있으며, 설정이 잘못되면 시작 의존성 순환이 발생할 수 있습니다.
- 규칙이나 오버라이드가 DNS 라우팅을 변경해 현재 실행 중인 설정이 구독 파일의 내용과 완전히 다를 수 있습니다.
일부 mihomo 버전은 노드 서버 도메인 해석에 사용할 업스트림을 지정하는 proxy-server-nameserver를 지원합니다. 사용할지는 실제 버전과 전체 DNS 설정을 함께 확인해야 합니다. 확인 없이 모든 Clash 설정에 추가해서는 안 됩니다. 필드 관계는 설정 종합 안내의 DNS 설명을 참고하세요.
DNS를 조정한 뒤에는 클라이언트가 지원하는 방식으로 설정을 다시 불러오고 테스트 연결을 새로 만드세요. Windows의 ipconfig /flushdns는 시스템 DNS 캐시만 지우며 브라우저 캐시, 코어 캐시, 기존 연결까지 함께 삭제하지는 않습니다.
6. 프록시 적용 확인: 로컬 포트로 시스템 설정 분리하기
노드와 DNS에 뚜렷한 이상이 없다면 애플리케이션 요청이 코어로 들어가는지 확인하세요. 시스템 프록시는 해당 설정을 따르는 애플리케이션에만 적용됩니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 인계하며 필요한 시스템 권한이 있고, 다른 VPN의 라우팅과 충돌할 수 있습니다. TUN을 켠다고 만료된 노드가 자동으로 복구되거나 모든 트래픽이 반드시 프록시로 들어가는 것은 아닙니다.
다음 명령은 현재 실행 중인 설정의 HTTP 또는 mixed 수신 주소가 127.0.0.1:7890이라고 가정합니다. 7890은 설명을 위한 예시이며 모든 클라이언트의 고정값이 아닙니다. 먼저 현재 설정이나 수신 정보에서 확인하세요. 해당 포트에 인증이 필요하다면 클라이언트 안내에 따라 로컬에서 자격 증명을 제공하고, 기록을 공유할 때는 민감한 내용을 삭제하세요.
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/이 명령은 브라우저가 시스템 프록시를 사용하는지와 관계없이 로컬 프록시에 명시적으로 연결합니다. 비어 있는 --noproxy 목록은 기존 프록시 우회 설정을 덮어쓰는 데 사용됩니다. 테스트할 때는 연결 기록에서 규칙 적중 여부와 최종 출구도 확인해야 합니다. 요청이 로컬 포트로 들어갔더라도 규칙에 따라 DIRECT로 전송될 수 있으므로 노드가 사용 가능하다는 직접적인 증거로 볼 수 없습니다.
| 관찰 결과 | 다음 단계 |
|---|---|
| 127.0.0.1:7890에 연결할 수 없음 | 수신 포트, 코어 실행 상태와 포트 점유 여부를 확인하고 원격 노드는 우선 점검하지 마세요. |
| 코어에 기록은 있지만 출구가 DIRECT로 표시됨 | 규칙과 정책 그룹을 확인하고 테스트 노드를 고정한 뒤 연결을 새로 만드세요. |
| 명시적 프록시는 성공하지만 브라우저는 실패 | 브라우저 프록시 확장 프로그램, 시스템 프록시, PAC와 애플리케이션 자체 DNS 설정을 확인하세요. |
| 시스템 프록시는 정상이고 TUN만 실패 | 가상 인터페이스, 서비스 권한, 라우팅과 다른 VPN의 충돌을 확인하세요. |
진단 중에는 전체 모드로 잠시 전환하고 테스트 노드를 명시적으로 선택할 수 있지만, 기존 모드를 기록한 뒤 테스트 후 규칙 모드로 되돌리세요. 기존 연결은 계속 이전 출구를 사용할 수 있으므로 전환 후 기존 테스트 연결을 닫고 새 요청을 보내야 합니다. 전체 모드를 장기간 사용해 규칙 설정 오류를 가리지 마세요.
7. 테스트 주소와 로그: 시간 초과가 발생한 단계 찾기
명시적 프록시로 실제 서비스 대상에 접속할 수 있는데 클라이언트의 지연 테스트만 시간 초과된다면 테스트 URL을 우선 확인하세요. 테스트 서비스 자체에 장애가 있거나 잦은 요청을 제한하거나 특정 출구에서 접근할 수 없을 수 있습니다. 일부 구현은 예상 HTTP 상태 코드도 확인합니다. 지연 표시가 빨간색이라는 이유만으로 설정 전체를 삭제하지 마세요.
한 번에 하나의 테스트 조건만 조정하기
- 현재 테스트 URL과 기준 시간을 기록하세요. 인터페이스에서 지원한다면 3000밀리초를 잠시 10000밀리초로 바꾼 뒤 같은 노드를 3회 테스트합니다. 이는 진단을 위한 설정일 뿐 권장 지연 기준이 아닙니다.
- 접근 권한이 있고 응답이 안정적인 소규모 HTTPS 대상으로 바꿔 비교하세요. 대상 변경의 목적은 테스트 측 장애를 구분하는 것이지 항상 성공을 반환하는 숫자를 고르는 것이 아닙니다.
- HEAD를 지원하지 않는 대상이라면 curl 명령의
-I를-o NUL로 바꿔 일반 GET을 보내고 응답 본문을 버리세요. macOS와 Linux에서는-o /dev/null을 사용합니다. - 코어 로그와 연결 기록을 함께 확인해 접속 도메인, 적용 규칙, 정책 그룹과 실제 노드가 일치하는지 확인하세요.
curl 종료 코드 7은 대개 연결을 수립하지 못했다는 뜻이고, 28은 작업 시간 초과, 60은 인증서 검증 실패와 관련됩니다. 이는 통일된 “노드 오프라인” 코드가 아닙니다. HTTP 프록시로 HTTPS에 접속할 때 출력되는 200 Connection established는 CONNECT 터널 단계가 성공했다는 뜻일 뿐이며, 이후 TLS와 대상 HTTP 응답도 확인해야 합니다.
로그의 lookup, dial tcp, handshake 같은 문맥은 단계 파악에 도움이 되지만 마지막 줄의 “timeout”만 잘라 보지 마세요. 같은 시간대의 기록을 보존하고 테스트 대상을 표시하세요. 로그 수준을 일시적으로 높였다면 불필요한 접속 기록이 장기간 쌓이지 않도록 즉시 원래대로 되돌리세요.
8. 설정 복원 및 피드백 체크리스트
점검을 마치면 기존 규칙 모드, DNS 설정과 적용 방식을 복원하고 자동 정책 그룹을 다시 활성화해야 하는지 확인하세요. 시간 초과를 늘리거나, 노드를 임시로 고정하거나, TUN을 일시 중지한 진단 조치를 최종 설정으로 그대로 사용하지 마세요. 최종 검증에는 새 웹페이지 연결과 기존에 실패했던 애플리케이션 시나리오를 각각 한 번 이상 포함해야 합니다.
- 환경: 운영체제, 아키텍처, 클라이언트 버전, 실제 코어 버전과 문제가 발생한 네트워크 유형.
- 범위: 모든 노드인지 특정 노드 하나인지, 모든 대상인지 특정 대상 하나인지, 시스템 프록시와 TUN의 동작이 다른지 여부.
- 증거: 정확한 테스트 시간, 사용한 포트, 적중한 규칙, 실제 출구와 민감 정보를 삭제한 오류 문맥.
- 수행한 작업: 구독 업데이트 시간, 계정 상태 확인, DNS 결과, 네트워크 전환 비교 결과와 원래 설정을 복원했는지 여부.
스크린샷이나 피드백을 보내기 전에 구독 URL, 토큰, 비밀번호, UUID와 공개하고 싶지 않은 서버 정보를 가리세요. 같은 노드가 여러 네트워크에서 모두 핸드셰이크를 완료하지 못한다면 구독 제공업체에 민감 정보를 삭제한 기록을 제출할 수 있습니다. 명시적 프록시는 정상인데 클라이언트 적용만 이상하다면 해당 클라이언트 프로젝트에 문의하는 편이 적절합니다. 실패가 발생한 계층에 맞는 유지보수 담당자를 찾는 것이 반복적인 재설치보다 실행 가능한 해결책을 얻기 쉽습니다.