V2Ray 노드 연결 시간 초과·연결 실패 해결: 단계별 점검 목록

1. 먼저 실패 단계 확인: 실행, 연결, 웹 요청

‘시간 초과’는 어떤 단계가 제한 시간 안에 완료되지 않았다는 뜻일 뿐, 서버가 반드시 오프라인이라는 의미는 아닙니다. 클라이언트 목록의 연결 테스트, 브라우저 요청, 구독 다운로드는 대상 주소와 라우팅, 시간 제한이 서로 다를 수 있습니다. 먼저 어떤 작업에서 실패했는지 기록한 뒤 점검할 계층을 정하세요.

데스크톱에서는 시스템 프록시 설정을 사용하는 앱만 시스템 프록시를 통해 로컬 진입점으로 연결됩니다. 명시적 프록시 테스트를 사용하면 이 불확실성을 배제할 수 있습니다. 안드로이드에 VPN 표시가 나타나면 VpnService가 실행 중이라는 뜻이지만, 원격 핸드셰이크나 대상 웹사이트 접속까지 성공했다는 의미는 아닙니다.

2. 시스템 시간과 로컬 네트워크 확인

먼저 시스템 시간이 자동으로 동기화되도록 설정하세요. VMess 인증은 시간에 의존하며 TLS도 기기의 시계를 기준으로 인증서 유효 기간을 확인합니다. 시간이 크게 어긋나면 서버 포트와 TCP 연결이 되더라도 이후 인증이 실패할 수 있습니다. 시간대를 수동으로 바꾸는 것은 시간 동기화와 다릅니다. 표시되는 시간대와 실제 시계의 정확성은 별개의 문제입니다.

1. Windows: ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 ‘시간 자동 설정’을 켜고 ‘지금 동기화’를 실행한 뒤 클라이언트를 다시 연결하세요.
2. 안드로이드: 시스템 ‘설정’의 ‘날짜 및 시간’에서 자동 시간 설정을 켜세요. 제조사에 따라 ‘시스템’이나 ‘추가 설정’에 있을 수 있으니 설정 검색을 이용해도 됩니다.
3. 기본 인터넷 연결 확인: 프록시를 일시 중지하고 평소 프록시 없이 접속되는 웹사이트를 열어 보세요. 공용 Wi-Fi에 로그인 페이지가 표시되면 먼저 인증을 완료한 뒤 클라이언트를 실행하세요.
4. 접속 네트워크를 한 번 바꿔 비교: 같은 기기, 같은 노드, 같은 테스트 대상을 사용해 Wi-Fi와 모바일 네트워크를 비교하세요. 노드와 네트워크를 동시에 바꾸면 원인을 구분할 수 없습니다.

특정 네트워크에서만 연결된다면 IPv6 지원 여부, 라우터 정책, 다른 VPN 사용 여부 등 네트워크별 차이를 우선 기록하세요. 시스템 방화벽을 무작정 끄지 마세요. 설정을 바꿔야 한다면 클라이언트의 아웃바운드 권한과 실제 차단 기록을 먼저 확인하세요.

3. 구독을 업데이트하고 현재 사용하는 노드 설정 확인

구독 업데이트 성공은 설정을 가져왔다는 뜻일 뿐, 구독에 포함된 모든 노드가 작동한다는 의미는 아닙니다. 반대로 구독 주소가 시간 초과되더라도 로컬에 저장된 노드가 모두 작동하지 않는 것은 아닙니다. 구독 다운로드와 노드 연결은 서로 다른 요청이므로 따로 확인해야 합니다.

1. v2rayN의 ‘구독 그룹’에서 대상 그룹을 확인한 뒤 해당 구독을 업데이트하세요. 메뉴 이름은 버전에 따라 달라질 수 있으므로 일반 업데이트와 프록시를 통한 업데이트를 구분하세요.
2. v2rayNG 또는 v2flyNG의 구독 설정에서 주소와 업데이트 결과를 확인하세요. 구독 사이트에 프록시를 통해 접속해야 한다면, 먼저 작동을 확인한 노드를 사용한 뒤 프록시를 통한 업데이트를 선택하세요.
3. 업데이트한 뒤 대상 노드를 다시 선택하고 서비스를 재시작하세요. 같은 이름의 메모만 보지 말고 편집 화면을 열어 서버 주소와 포트, 프로토콜이 실제로 변경됐는지 확인하세요.
4. 클라이언트 버전과 실제 코어의 이름 및 버전을 기록하세요. v2rayNG는 Xray 코어를 사용하고 v2flyNG는 V2Fly 코어를 사용하므로, 화면이 비슷하다고 해서 지원하는 필드까지 같다고 볼 수는 없습니다.

구독 응답이 로그인 페이지나 오류 페이지라면 반복해서 가져와도 해결되지 않습니다. 계정 상태와 구독 주소가 완전한지 확인하고 업데이트 로그에 파싱 실패가 기록됐는지 살펴보세요. 구독 주소를 ‘서버 주소’ 필드에 입력하거나, 단일 vmess:// 또는 vless:// 공유 링크를 정기적으로 가져오는 구독 주소처럼 사용하지 마세요.

4. 원격 포트와 로컬 수신 포트를 따로 테스트

원격 포트는 서버 연결에 사용하고, 로컬 수신 포트는 앱 요청을 받는 데 사용합니다. 두 포트를 혼동하면 안 됩니다. 아래에서는 원격 포트 443과 로컬 SOCKS 또는 혼합 진입점 10808을 예로 듭니다. 모든 설정의 기본값은 아니므로 실행 전에 실제 노드 및 클라이언트 설정을 확인하세요.

Windows에서는 아래 PowerShell 명령을 실행한 뒤 서버의 도메인 또는 IP 주소와 포트를 입력하면 됩니다. 이 명령은 TCP 연결 여부만 테스트하며 VMess, VLESS, TLS 또는 REALITY 핸드셰이크의 정상 여부는 확인하지 않습니다. UDP 전송이 가능한지 판단하는 데도 사용할 수 없습니다.

$server = Read-Host "노드 서버 도메인 또는 IP 입력"
$port = [int](Read-Host "노드 포트 입력")
Test-NetConnection -ComputerName $server -Port $port -InformationLevel Detailed

• TcpTestSucceeded : True: 이번 TCP 핸드셰이크가 완료됐다는 뜻입니다. 프로토콜 설정을 계속 확인하세요. 노드가 정상 작동한다고 단정할 수는 없습니다.
• TcpTestSucceeded : False: 도메인 확인 결과와 포트, 네트워크 경로를 점검하세요. 서버에서 해당 포트를 수신하지 않거나 방화벽이 연결을 차단했을 수도 있습니다.
• 도메인이 여러 주소로 연결된다면 명령에서 실제로 사용한 RemoteAddress를 기록하세요. 한 번 연결에 성공했다고 해서 모든 IPv4 및 IPv6 주소에 접속할 수 있는 것은 아닙니다.

이어서 로컬 진입점을 테스트하세요. v2rayN의 ‘설정’ → ‘매개변수 설정’에서 수신 주소와 포트, 진입점 유형을 확인하세요. 버전에 따라 기본 설정 페이지에 있을 수 있습니다. 실제 포트가 10808이고 SOCKS를 지원한다면 터미널에서 아래와 같이 프록시를 명시한 요청을 실행하세요. Windows에서는 curl이 다른 명령으로 해석되는 구버전 PowerShell을 피하도록 curl.exe를 사용하세요.

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

여기서 10초와 20초는 진단을 위해 지정한 제한 시간이며 속도 측정 결과가 아닙니다. socks5h는 대상 도메인 확인을 프록시 측에서 처리하지만, 이 매개변수만으로 모든 DNS 요청의 최종 연결 경로를 알 수는 없습니다. 대상 웹사이트는 테스트용일 뿐입니다. 해당 사이트에 접속할 수 없다면 작동이 확인된 HTTPS 주소로 다시 테스트하세요.

5. 프로토콜, 전송 방식, TLS 설정 확인

포트 접속이 확인되면 서버에서 제공한 유효 설정과 항목별로 대조하세요. 주소와 포트가 같아도 설정까지 같은 것은 아닙니다. 수정 전에 기존 값을 저장하고 한 번에 하나만 바꾼 뒤 서비스를 재시작하세요. UUID, SNI, 경로를 한꺼번에 변경하면 비교 기준을 잃게 됩니다.

서버 주소는 연결 대상을 찾는 데 사용하고, TLS의 SNI는 핸드셰이크에서 서버 이름을 지정하며, WebSocket의 Host는 HTTP 요청에 사용합니다. 세 항목은 같을 수도, 다를 수도 있습니다. ‘통일’을 위해 억지로 하나의 도메인으로 바꾸면 안 됩니다. REALITY를 사용하는 경우 현재 클라이언트 및 코어 버전에 맞춰 필드 대응을 확인하고, 다른 버전의 JSON 필드 이름을 그대로 가져오지 마세요.

6. 요청 한 번을 보내고 코어 로그 대조

연속 속도 테스트를 멈추고 현재 로그 화면을 비운 다음 서비스를 시작해 요청을 한 번만 보내세요. 발생 시간, 선택한 노드, 대상 도메인, 마지막 전체 오류 체인을 기록하세요. 로그에 표시되는 ‘연결 실패’는 대개 요약 메시지이며, 실제 원인은 뒤이어 나오는 dial, lookup, tls 또는 bind 정보에 있는 경우가 많습니다.

v2rayN은 기본 창의 로그 영역에서 실행 및 연결 정보를 확인할 수 있고, 안드로이드 클라이언트는 메뉴의 로그 항목에서 확인할 수 있습니다. 위치는 버전에 따라 다릅니다. 로그 수준을 일시적으로 높였다면 점검 후 원래 설정으로 되돌리세요. 액세스 로그에 대상 도메인이 포함될 수 있으므로 공유 전에 민감 정보를 가리세요. 아래는 흔히 볼 수 있는 오류 예시이며, 오류마다 원인이 하나로 정해지는 것은 아닙니다.

로그에 EOF가 표시되면 연결에서 데이터 읽기가 끝났다는 뜻일 뿐, UUID 오류를 단독으로 증명하지는 않습니다. TCP 연결 이후인지, TLS 핸드셰이크 중인지, 전송 요청 단계인지 함께 확인해야 합니다. 계속 실패한다면 클라이언트 및 코어 버전, 오류 발생 시간, 민감 정보를 가린 오류 내역, 같은 노드를 다른 네트워크에서 테스트한 결과를 제공하세요. ‘시간 초과’ 화면 한 장만 보내는 것보다 문제 파악에 도움이 됩니다.

7. 여전히 연결되지 않을 때: 증상별 최종 점검

이 단계에서는 문제가 로컬 진입점, 원격 접속 가능 여부, 프로토콜 핸드셰이크 중 어디에 가까운지 파악했을 것입니다. 정상 작동이 확인된 설정은 유지하고 라우팅, DNS, 구독을 동시에 초기화하지 마세요. 아래 증상에 따라 최소한의 변경으로 범위를 좁혀 보세요.