Clash 노드 전체 timeout 해결 방법: 로컬 네트워크부터 원격 서버까지 점검 순서

1. 지연 시간 테스트 실패와 실제 프록시 연결 실패 구분하기

timeout은 작업이 제한 시간 안에 완료되지 않았다는 뜻입니다. 서버가 중단됐다고 단정할 수는 없습니다. 클라이언트의 지연 시간 테스트는 보통 노드를 통해 지정된 HTTP 또는 HTTPS 주소에 접속합니다. 도메인 확인, 서버 연결, 프로토콜 핸드셰이크, 테스트 사이트 접속 중 어느 단계에서든 멈추면 timeout이 표시될 수 있습니다.

먼저 노드 하나, 테스트 URL 하나, 앱 하나만 정해 두세요. 수십 개 연결이 동시에 시작되지 않도록 일괄 테스트는 잠시 중지합니다. 클라이언트 이름, 코어 이름과 버전, 현재 네트워크, 테스트 시각, 로그에 처음 나온 오류를 기록하세요. 이후에는 매번 조건 하나만 바꿔 테스트합니다.

2. 로컬 네트워크: 연결 끊김, 인증, 남은 프록시 설정부터 확인

확인 가능한 직접 연결 환경 만들기

1. 기존 설정을 기록해 둡니다. 클라이언트의 시스템 프록시와 TUN 모드를 끄고, 다른 VPN·가속기·프록시 프로그램도 종료합니다.
2. Windows 11에서 「설정」→「네트워크 및 인터넷」→「프록시」를 열어 수동 프록시나 자동 구성 스크립트가 남아 있는지 확인합니다. 조직에서 관리하는 기기라면 정책을 임의로 제거하지 말고 관리자에게 문의하세요.
3. macOS에서 「시스템 설정」→「네트워크」→현재 네트워크 연결→「세부사항」→「프록시」를 열어 HTTP, HTTPS, SOCKS 프록시가 종료된 로컬 프로그램을 가리키고 있지 않은지 확인합니다.
4. 호텔, 학교 또는 공용 Wi-Fi에 연결했다면 먼저 네트워크 인증을 완료하세요. 브라우저에 로그인 페이지가 나타나면 인증부터 처리하고 노드 설정은 그다음에 확인합니다.

클라이언트를 종료해도 시스템 프록시 설정은 남아 있을 수 있습니다. 시스템이 127.0.0.1:7890을 가리키는데 해당 포트에서 대기 중인 프로세스가 없다면 브라우저 연결은 실패합니다. 이는 로컬 진입점 문제이며 아직 원격 노드에 도달하지 않은 상태입니다.

프록시를 명시적으로 우회해 요청 테스트하기

Windows PowerShell에서는 curl.exe를 사용하세요. 구형 PowerShell에서 같은 이름의 명령 별칭으로 생기는 차이를 피할 수 있습니다. 아래 요청은 명시적 프록시를 우회하고 연결 timeout은 5초, 전체 제한 시간은 15초로 설정합니다. 이는 점검용 설정이며 실측 결과가 아닙니다.

curl.exe --noproxy "*" --connect-timeout 5 --max-time 15 -I https://www.example.com/

macOS와 Linux에서도 같은 매개변수를 사용하되 명령 이름을 curl로 바꾸면 됩니다. 예시 도메인은 요청 방법을 설명하기 위한 것이므로 현재 네트워크에서 직접 연결이 되는 것으로 확인된 사이트로 바꿔도 됩니다. TUN, 투명 게이트웨이 또는 상위 투명 프록시가 여전히 작동 중이라면 --noproxy로 이런 네트워크 계층의 트래픽 가로채기를 우회할 수 없습니다.

직접 연결도 실패한다면 먼저 네트워크 어댑터 주소, 기본 게이트웨이, 라우터의 인터넷 연결 상태를 확인하세요. 그다음 같은 컴퓨터를 휴대폰 핫스팟에 연결해 다시 테스트합니다. 핫스팟에서는 정상이고 기존 네트워크에서만 실패한다면 기존 네트워크의 DNS, 라우팅 또는 접속 정책 문제일 가능성이 높습니다. 이것만으로 특정 포트가 차단됐다고 단정할 수는 없습니다.

3. 시스템 시간과 DNS: 도메인 및 인증서 확인

시스템 시계 맞추기

TLS 인증서 검증에는 현재 시간이 사용되며 일부 프록시 인증에도 시간 조건이 있습니다. Windows 11에서 「설정」→「시간 및 언어」→「날짜 및 시간」을 열어 시간 자동 설정을 켜고 동기화를 실행하세요. macOS에서는 「시스템 설정」→「일반」→「날짜 및 시간」에서 날짜와 시간 자동 설정 여부를 확인합니다.

화면에 표시된 시간대뿐 아니라 날짜, 연도, 실제 시각도 확인하세요. 로그에 certificate has expired 또는 certificate is not yet valid가 나타나면 로컬 시계와 원격 인증서를 모두 확인합니다. 인증서 검증을 건너뛰도록 설정하지 마세요.

노드 도메인과 테스트 도메인을 따로 확인하기

• 노드 도메인 확인 실패: 코어가 서버 주소를 찾지 못해 프록시 연결을 시작할 수 없습니다.
• 테스트 도메인 확인 실패: 서버에 연결할 수 있더라도 지정된 테스트 요청은 완료되지 않을 수 있습니다.
• 코어와 시스템의 확인 결과가 다름: 시스템에서 조회에 성공해도 코어에 설정된 DNS 업스트림이 정상이라는 뜻은 아닙니다.

먼저 로그에서 확인에 실패한 도메인을 찾으세요. Windows에서는 Resolve-DnsName www.example.com, macOS 또는 Linux에서는 nslookup www.example.com을 실행하고, 예시 도메인을 로그에 나온 대상으로 바꿉니다. 시스템 조회 결과는 비교 자료일 뿐입니다. 코어에서 DNS resolve failed, 업스트림 연결 timeout, 조회 루프가 보고되는지도 확인하세요.

4. 테스트 주소: 숫자만 보지 말고 요청 대상 확인하기

클라이언트에서 현재 사용하는 테스트 URL을 확인하세요. UI 설정에서 가져올 수도 있고 설정의 url-test 정책 그룹이나 proxy-providers 상태 확인에서 가져올 수도 있습니다. 이 항목들이 같은 주소를 사용한다고 단정할 수 없습니다. UI에서 설정을 바꿔도 백그라운드 상태 확인은 이전 주소에 계속 접속할 수 있습니다.

응답이 짧고 주소가 안정적이며 현재 회선에서 접속 가능한 HTTPS 대상을 선택하세요. 204를 반환하는 주소는 연결 확인에 자주 쓰이지만, 204 응답을 받지 못한 모든 경우를 노드 장애로 보면 안 됩니다. 리디렉션, 인증 페이지, 사이트의 요청 제한, 클라이언트의 상태 코드 판정 방식도 결과에 영향을 줍니다.

같은 대상으로 두 가지 요청 테스트하기

아래 예시는 로컬 HTTP 프록시 포트로 대상 사이트에 접속합니다. 7890은 예시일 뿐이므로 클라이언트의 실제 HTTP 또는 mixed 수신 포트로 바꿔야 합니다. 먼저 현재 규칙이 이 요청을 테스트할 노드로 보내는지 확인하세요. 그렇지 않으면 요청이 성공해도 DIRECT가 선택된 것일 수 있습니다.

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://www.example.com/

1. 같은 대상에 직접 요청과 프록시 요청을 각각 보내고 오류 메시지를 저장합니다.
2. 클라이언트 연결 기록에서 대상 도메인, 적용된 규칙, 최종 아웃바운드 노드를 확인합니다.
3. 테스트 대상에만 문제가 있다면 노드는 그대로 두고 정상 작동이 확인된 다른 대상으로 바꿔 테스트합니다.
4. 5초 테스트는 실패하지만 15초 안에는 요청이 완료된다면 응답 지연의 단서로 기록하고 핸드셰이크와 패킷 손실을 확인하세요. timeout 값을 무작정 계속 늘리지는 마세요.

curl -I는 HEAD 요청을 사용하지만 일부 클라이언트의 탐색 요청은 GET입니다. 대상이 HEAD를 지원하지 않으면 -I를 빼고 -o NUL(Windows) 또는 -o /dev/null(macOS, Linux)을 사용해 응답 본문을 버리세요. 비교할 때는 요청 방식을 동일하게 맞춰야 합니다.

5. 로컬 포트, 규칙, TUN: 트래픽이 테스트 노드를 실제로 통과하는지 확인

먼저 명시적 프록시 진입점 확인하기

Windows에서는 아래 명령으로 예시 포트가 대기 중인지 확인할 수 있습니다. 결과가 비어 있다면 클라이언트에서 코어가 시작됐는지, 설정이 정상적으로 불러와졌는지, 다른 프로그램이 포트를 사용 중인지 확인하세요.

Get-NetTCPConnection -State Listen -LocalPort 7890

macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN, Linux에서는 ss -lntp로 대기 중인 포트를 확인할 수 있습니다. 포트가 있다는 사실만으로는 충분하지 않습니다. 해당 프로세스가 현재 클라이언트의 코어인지 확인하세요. HTTP 프록시 요청을 제어 인터페이스 포트로 보내지 마세요. 제어 인터페이스는 프록시 트래픽 진입점이 아닙니다.

연결 기록에서 적용된 정책 확인하기

• 규칙 모드: 대상에 적용된 규칙과 정책 그룹을 확인해 최종 경로가 DIRECT, REJECT 또는 다른 노드로 지정되지 않았는지 확인합니다.
• 자동 선택 그룹: 점검 중에는 특정 노드 하나를 고정해 자동 전환으로 결과가 섞이지 않도록 합니다.
• 체인 프록시: 중간 경로 중 한 곳만 실패해도 최종 요청이 timeout될 수 있습니다. 먼저 단일 홉 연결로 단순화해 비교하세요.

명시적 HTTP 프록시는 정상인데 TUN을 켠 뒤에만 실패한다면 라우팅, DNS 가로채기, 권한, 다른 VPN과의 충돌을 중점적으로 확인하세요. TUN은 트래픽이 코어에 들어오는 방식을 바꾸지만 잘못된 비밀번호나 원격 포트 연결 문제를 해결하지는 않습니다. 로그와 설정 사본을 먼저 저장한 뒤 하나씩 확인하고, 기본 경로를 가로채는 도구를 여러 개 동시에 켜지 마세요.

게임, 음성 통화, QUIC 요청만 실패한다면 UDP 지원을 별도로 확인하세요. 브라우저에서 TCP 접속에 성공해도 노드 프로토콜, 서버, 로컬 네트워크가 모두 UDP를 허용한다는 뜻은 아닙니다. 앱에서 QUIC을 잠시 끈 뒤 정상화되더라도 UDP 경로 문제의 단서일 뿐입니다.

6. 프로토콜 설정과 원격 서버: 연결 가능 여부부터 핸드셰이크까지 확인

현재 코어가 노드 프로토콜을 지원하는지 먼저 확인하기

Clash 설정 형식이 비슷하다고 해서 모든 코어가 같은 프로토콜과 필드를 지원하는 것은 아닙니다. mihomo 설정을 사용한다면 클라이언트 UI 버전만 기록하지 말고 실제 코어 이름과 버전을 확인하세요. 로그에 지원하지 않는 프록시 유형, 알 수 없는 필드, 설정 파싱 오류가 나타나면 네트워크 테스트보다 호환성 문제를 먼저 해결합니다.

신뢰할 수 있는 원본 구독에서 설정을 다시 받아 계정 트래픽, 만료 상태, 노드 목록이 바뀌었는지 확인하세요. server, port, 프로토콜 유형, 인증 필드를 하나씩 점검합니다. TLS 또는 WebSocket을 사용한다면 servername, 경로, Host도 확인하세요. REALITY를 사용한다면 공개 키, short ID 등 서비스 제공자가 안내한 매개변수도 확인해야 합니다.

도메인 모양만 보고 이런 매개변수를 추측해서는 안 됩니다. 노드 도메인을 IP로 바꾸면 TLS SNI, 인증서 검증, 서버의 트래픽 분기 결과가 달라질 수 있습니다. TCP 연결에 성공해도 전체 프로토콜 연결이 성립했다는 뜻은 아닙니다.

포트 확인 결과는 일부 근거로만 활용하기

Windows에서는 Test-NetConnection으로 서버의 TCP 포트를 확인할 수 있습니다. 아래 변수를 실제 설정의 서버 주소와 포트로 바꾼 뒤 실행하세요. 예시의 443은 모든 노드에서 사용하는 공통 포트가 아닙니다.

$server = Read-Host "노드 server 주소 입력"
$port = [int](Read-Host "노드 port 입력(예: 443)")
Test-NetConnection -ComputerName $server -Port $port

• TCP 연결 성공: TCP 연결이 성립했다는 것만 확인할 수 있습니다. 인증, TLS, WebSocket, 프록시 전달의 성공 여부는 증명하지 않습니다.
• TCP 연결 실패: 라우팅, 접속 정책, 서버 미수신 또는 주소 오류가 원인일 수 있습니다. 한 번의 결과만으로 책임 주체를 단정할 수 없습니다.
• UDP 프로토콜: Hysteria2, TUIC 등 UDP 기반 연결은 TCP 포트 확인 결과로 사용 가능 여부를 판단할 수 없습니다.
• ping 실패: 대상이 ICMP 응답을 보내지 않을 수 있으므로 프록시 포트를 사용할 수 없다고 단정할 수 없습니다.

같은 노드가 서로 다른 두 네트워크에서 모두 실패하고 설정과 계정 상태도 확인됐다면 서비스 제공자에게 수신 포트, 방화벽, 인증서, 서버 실행 상태를 문의하세요. 여러 노드가 같은 진입 도메인이나 중계 경로를 공유한다면 모두 실패해도 각 원격 서버가 동시에 고장 난 것이 아니라 공통 의존성에 문제가 있을 수 있습니다.

7. 로그로 마무리하기: 전체 실패 화면만 캡처하지 말고 최초 오류를 보존하세요

로그 수준을 일시적으로 debug로 높이고 기존 기록을 지운 뒤 실패를 한 번만 재현하세요. 요청 시작부터 오류가 발생할 때까지의 전체 맥락을 확인합니다. 대상 도메인, 선택된 노드, 조회 결과, 핸드셰이크 단계가 포함되어야 합니다. 점검이 끝나면 로그 수준을 원래대로 되돌려 불필요하게 많은 기록이 쌓이지 않도록 하세요.

한 차례 점검을 마쳤다고 볼 수 있는 기준

1. 프록시를 끈 상태에서 로컬 직접 연결이 정상인지 확인했습니다.
2. 노드 하나를 고정하고 실제 접속과 지연 시간 테스트를 각각 확인했습니다.
3. 시스템 시간, 노드 도메인 조회, 로컬 수신 포트를 확인했습니다.
4. 연결 기록에서 적용된 규칙과 최종 아웃바운드를 확인했습니다.
5. 다른 네트워크에서도 비교했거나, 아직 비교할 수 없는 이유를 기록했습니다.
6. 실패가 발생한 단계를 찾고 추가 점검에 사용할 비식별 처리 로그를 정리했습니다.

이 순서대로 점검하면 ‘모든 노드 timeout’ 문제의 원인을 로컬 진입점, DNS, 테스트 대상, 프로토콜 핸드셰이크, 원격 경로 중 한 계층으로 좁힐 수 있습니다. 설정 용어를 확인하려면 개념 빠른 참조를, 시스템 프록시와 규칙 설정을 더 살펴보려면 문제 해결 가이드를 확인하세요.