V2Ray 노드 연결 시간 초과 해결법: 시스템 시간·포트·TLS 핸드셰이크 점검 순서

이 글의 핵심

v2rayN 노드 테스트 시간 초과, 브라우저에서 웹페이지가 열리지 않는 문제, 연결 표시는 되지만 접속되지 않는 v2rayNG 문제에 적용할 수 있습니다. 먼저 테스트 요청이 클라이언트를 통과하는지 확인한 뒤 시간, 로컬 리스닝, 서버 포트, 핸드셰이크 설정을 점검하세요. 한 번에 한 항목만 바꾸고 같은 대상으로 다시 테스트해야 시스템 프록시 문제를 노드 장애로 오인하지 않습니다.

1. 시간 초과가 발생한 구간부터 구분하기

화면에 표시되는 ‘시간 초과’는 결과일 뿐 원인은 아닙니다. 접속 과정에는 앱의 프록시 설정, 로컬 인바운드, 도메인 조회, 원격 연결, 프로토콜 핸드셰이크가 포함될 수 있습니다. 앞 단계가 완료되지 않으면 TLS 설정이 올바르더라도 해결되지 않습니다. 먼저 실패 시각, 노드 프로토콜, 서버 포트, 당시 시스템 프록시 또는 TUN 모드 사용 여부를 기록하세요.

앱 프록시 진입점 로컬 인바운드 리스닝 원격 주소 조회 서버 연결 프로토콜 및 핸드셰이크

v2rayN은 데스크톱 클라이언트이며, 실제 연결은 선택한 코어가 처리합니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 프로토콜, 클라이언트, 코어는 서로 다른 개념입니다. 문제를 진단할 때는 단순히 ‘V2Ray가 안 된다’고 기록하지 말고 실제 사용한 코어와 버전을 확인하세요.

브라우저에서만 실패하는 경우: 브라우저 프록시 확장 프로그램, 시스템 프록시, 분할 라우팅 규칙부터 확인하세요. 클라이언트를 바로 재설치할 필요는 없습니다.
모든 앱에서 같은 노드로 연결되지 않는 경우: 클라이언트 로그를 확인한 뒤 로컬 포트, 원격 주소, 핸드셰이크 순으로 점검하세요.
지연 시간 테스트만 실패하는 경우: 테스트 유형과 테스트 URL을 확인하세요. 테스트 대상에 연결할 수 없으면 정상 작동하는 노드도 시간 초과로 표시될 수 있습니다.
구독을 업데이트할 수 없는 경우: 이는 구독 주소에 접근하는 문제이며, 가져온 노드가 모두 작동하지 않는다는 뜻은 아닙니다.

2. 시스템 시간을 맞춘 뒤 핸드셰이크 재시도

시스템 날짜, 시간 또는 시간대가 잘못 설정되면 인증서 유효 기간 확인에 영향을 줄 수 있으며, VMess의 시간 기반 인증에도 문제가 생길 수 있습니다. VLESS는 VMess와 같은 시간 기반 인증을 사용하지 않지만 TLS를 활성화했다면 서버 인증서는 여전히 검증해야 합니다. 노드 프로토콜이 VLESS라는 이유로 시스템 시간 점검을 건너뛰지 마세요.

날짜와 시간 확인

Windows 11에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’을 열어 날짜와 현재 시간이 맞는지 확인하고 ‘자동으로 시간 설정’을 켜세요. 시간대는 현재 지역에 맞춰야 합니다. 작업 표시줄에 표시된 시각만 보고 시스템 시간이 정확하다고 판단하지 마세요.
시간 동기화 실행

같은 화면에서 ‘지금 동기화’를 클릭하세요. 동기화에 실패하면 현재 네트워크에서 시간 서버에 접근할 수 있는지 확인합니다. 절전 모드에서 복귀했거나 가상 머신 스냅샷을 복원한 경우, 메인보드 배터리에 문제가 생긴 경우에도 시간을 다시 확인하세요.
동기화 상태 확인

PowerShell을 열고 아래 조회 명령을 실행해 시간 원본과 마지막으로 동기화에 성공한 시각을 확인하세요. 다시 동기화하려면 두 번째 명령을 관리자 권한으로 실행합니다. 서비스가 시작되지 않았거나 사용할 수 있는 시간 데이터가 없다면 먼저 해당 안내에 따라 문제를 해결하세요.
요청 다시 보내기

시간을 바로잡은 뒤 클라이언트 연결을 중지했다가 다시 시작하고, 기존 노드와 테스트 대상으로 재검사하세요. Android에서는 시스템 설정에서 ‘날짜 및 시간’을 검색해 자동 시간을 켤 수 있습니다. 메뉴 위치는 기기와 시스템 버전에 따라 다릅니다.

w32tm /query /status
w32tm /resync

3. 로컬 포트가 실제로 리스닝 중인지 확인

시스템 프록시를 켰다고 코어가 정상적으로 시작된 것은 아닙니다. 시스템 프록시가 아무 프로세스도 리스닝하지 않는 포트를 가리키면 브라우저는 보통 즉시 연결 오류를 표시합니다. 다른 프로세스가 해당 포트를 사용 중이어도 클라이언트가 인바운드를 열지 못할 수 있습니다. 먼저 v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 포트와 인바운드 유형을 확인하세요. 메뉴 이름은 버전에 따라 다를 수 있으므로 현재 화면의 설정 항목을 기준으로 확인합니다.

127.0.0.1

내 컴퓨터의 루프백 주소이며 원격 노드 주소가 아닙니다

10808

아래 로컬 포트 예시는 설정값에 따라 달라집니다

443

일반적으로 TLS에 사용하는 서버 포트이며 필수값은 아닙니다

아래 예시는 로컬 포트 10808을 사용합니다. 첫 번째 명령은 리스닝 프로세스의 ID를 확인하고 두 번째 명령은 해당 프로세스를 조회합니다. 클라이언트에서 다른 포트를 설정했다면 명령의 숫자도 바꾸세요. 출력이 없으면 해당 포트에서 TCP 리스닝을 찾지 못한 것입니다.

Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
  ForEach-Object { Get-Process -Id $_.OwningProcess }

오류: Only one usage of each socket address (protocol/network address/port) is normally permitted.

원인: Windows에서 다른 프로세스나 중복 실행된 클라이언트가 로컬 포트를 사용 중일 때 흔히 발생합니다.

해결: 로그에 표시된 바인딩 주소와 포트를 확인한 뒤, 불필요한 중복 프로세스를 종료하거나 로컬 리스닝 포트를 변경하세요. 앱의 프록시 설정도 같은 포트로 업데이트해야 합니다.

확인 순서: 리스닝 여부를 확인한 다음 시스템 프록시 설정

로컬 포트가 리스닝 중이 아니라면 먼저 코어 시작 로그를 확인하세요. 포트가 리스닝 중이고 올바른 프로세스가 사용 중이라면 앱에서 HTTP, SOCKS 또는 혼합 인바운드 중 무엇을 사용하는지 확인합니다. SOCKS만 지원하는 포트를 HTTP 프록시로 지정하지 마세요.

4. DNS와 서버 포트를 따로 테스트

로컬 리스닝이 정상이라면 노드의 서버 주소를 확인하세요. 서버 주소는 연결을 설정하는 데 사용되고, TLS의 SNI는 핸드셰이크에서 서버 이름을 전달합니다. 두 값은 서로 다를 수 있습니다. 노드 편집 화면에서 서버 주소를 확인하고 구독 주소나 WebSocket 경로를 테스트에 사용하지 마세요.

아래 명령은 Windows PowerShell에서 실행합니다. 안내에 따라 서버 호스트 이름 또는 IP와 노드 설정에 지정된 원격 포트를 입력하세요. 입력 정보는 로컬 진단에만 사용됩니다. 개인 노드 정보가 포함된 전체 출력은 공개된 곳에 올리지 마세요.

$server = Read-Host "노드 서버 호스트 이름 또는 IP 입력"
$port = [int](Read-Host "노드 원격 포트 입력")

Resolve-DnsName -Name $server
Test-NetConnection -ComputerName $server -Port $port -InformationLevel Detailed

도메인 조회 실패: 철자, 구독 업데이트 여부, 현재 DNS의 정상 작동 여부를 확인하세요. 입력한 값이 IP라면 이후 포트 연결 결과를 중점적으로 확인하고, 도메인 조회 결과만으로 노드 상태를 판단하지 마세요.
TcpTestSucceeded : False: 서버가 온라인인지, 포트가 올바른지, 원격 방화벽에서 연결을 허용하는지, 현재 네트워크가 해당 연결을 제한하는지 확인하세요.
TcpTestSucceeded : True: 해당 TCP 연결이 성공했다는 뜻일 뿐 UUID, 전송 방식, TLS 또는 프록시를 통한 외부 연결이 정상이라는 뜻은 아닙니다.
도메인에 IPv4와 IPv6가 모두 설정된 경우: 실제 연결에 사용된 RemoteAddress를 확인하세요. 특정 주소 체계의 라우팅에 문제가 있으면 간헐적인 시간 초과가 발생할 수 있습니다. 차이가 확인된 경우에만 주소 선택 방식을 조정하세요.

5. TLS, 전송 방식, 인증 순으로 확인

원격 TCP 포트에 연결할 수 있는데도 프록시가 작동하지 않는다면 핸드셰이크 설정을 확인하세요. 포트가 둘 다 443이라는 이유만으로 설정까지 같다고 판단하지 마세요. 같은 포트에서도 서로 다른 서비스를 제공할 수 있으며, 리버스 프록시는 이름, 경로 또는 서비스 이름을 기준으로 트래픽을 전달할 수 있습니다.

점검 항목	세부 필드	흔한 오해와 해결 방법
TLS	보안 유형, SNI, 인증서 이름	SNI는 서버 설정에 맞춰 입력해야 합니다. 인증서가 적용되는 이름과 서버 IP는 다를 수 있으므로 서로 바꿔 입력하지 마세요.
전송 방식	TCP、WebSocket、gRPC	클라이언트와 서버의 설정이 일치해야 합니다. 전송 방식을 바꾸는 것은 모든 시간 초과 문제에 통하는 해결책이 아닙니다.
WebSocket	Host, 경로	경로의 첫 슬래시, 대소문자, 접미사가 리버스 프록시 라우팅에 영향을 줄 수 있습니다. Host를 SNI와 같은 값으로 간주해서는 안 됩니다.
gRPC	serviceName、ALPN	서비스 이름은 서버 설정과 일치해야 합니다. TLS 기반 HTTP/2를 사용한다면 서버에서 h2를 올바르게 협상해야 합니다.
프로토콜 인증	UUID, 비밀번호, flow	실제 프로토콜에 맞춰 인증 정보를 확인하세요. VLESS의 flow 설정은 클라이언트와 서버에서 일치해야 합니다.
REALITY	공개 키, shortId, serverName	REALITY는 별도의 핸드셰이크 매개변수를 사용하므로 일반 TLS 인증서 문제로만 처리할 수 없습니다.

구독으로 가져온 노드라면 먼저 현재 설정을 저장한 뒤 해당 구독을 업데이트하고 변경 사항을 비교하세요. 수동으로 수정한 노드는 다음 업데이트 때 설정이 덮어써질 수 있으므로 변경한 항목을 기록해 두세요. 한 번의 테스트에서 SNI, 전송 방식, 서버 주소를 동시에 바꾸지 마세요. 문제가 해결되더라도 원인을 알 수 없게 됩니다.

오류: x509: certificate has expired or is not yet valid

원인: PC 시간이 잘못되었거나 서버 인증서의 유효 기간이 아닙니다.

해결: 먼저 PC 시간을 바로잡고, 서버 관리자에게 인증서 유효 기간과 서버에 올바르게 배포되었는지 확인해 달라고 요청하세요.

오류: remote error: tls: handshake failure

원인: 상대 서버가 TLS 핸드셰이크를 거부했습니다. SNI, 프로토콜 협상, 서버 설정 등이 원인일 수 있지만 이 로그만으로 원인을 하나로 단정할 수는 없습니다.

해결: TLS 필드를 하나씩 대조하고, 같은 시각의 서버 로그를 확인해 연결이 거부된 이유를 파악하세요.

오류: websocket: bad handshake

원인: 예상한 WebSocket 업그레이드 응답을 받지 못했습니다. 경로, Host, 리버스 프록시 전달 설정이 일치하지 않을 때 흔히 발생합니다.

해결: 노드의 WebSocket 설정을 확인한 다음, 서버에서 업그레이드 요청이 올바른 인바운드로 전달되는지 점검하세요.

6. 동일한 요청으로 프록시 경로 검증

설정을 점검한 뒤 고정된 대상으로 요청을 보내세요. 아래 명령은 로컬 인바운드의 10808 포트가 SOCKS 연결을 받는 것으로 확인된 경우에 사용할 수 있습니다. 포트가 다르면 실제 설정에 맞게 바꾸세요. socks5-hostname은 대상 호스트 이름을 프록시에서 조회하므로, PC의 대상 사이트 DNS 조회 문제가 이번 테스트에 섞이지 않습니다.

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

여기서 10초와 20초는 진단 명령에 설정된 연결 시간 및 전체 제한 시간이며 노드 성능 기준이 아닙니다. 정상적인 HTTP 응답 헤더를 받았다면 이번 요청은 로컬 SOCKS 인바운드를 통해 전달된 것입니다. 성공이 아닌 상태 코드가 반환되더라도 프록시 실패라고 단정할 수 없으므로 응답 내용을 확인하세요. 실패하면 같은 시각의 코어 로그를 바로 확인합니다.

로컬 curl은 성공하지만 브라우저에서 실패하는 경우: 브라우저 확장 프로그램이 시스템 프록시를 덮어쓰는지, 시스템 프록시 주소와 포트가 올바른지 확인하세요.
브라우저는 되지만 터미널에서 실패하는 경우: 터미널 프로그램이 시스템 프록시 설정을 읽지 않을 수 있습니다. 먼저 프록시 매개변수를 명시해 테스트한 뒤 환경 변수를 확인하세요.
v2rayNG는 연결되지만 앱에서 실패하는 경우: Android VPN 권한, 앱별 프록시 목록, 다른 VPN 연결이 실행 중인지 확인하세요.
일부 도메인에서만 실패하는 경우: 분할 라우팅 규칙 적용 여부, 대상 DNS, 대상 사이트 상태를 확인하세요. 라우팅 규칙 때문에 직접 연결에 실패한 것을 노드 전체의 시간 초과로 오인하지 마세요.

TUN 또는 복잡한 라우팅을 사용 중이라면 테스트 요청이 실제로 어떤 아웃바운드 경로를 사용하는지도 확인하세요. 로컬 프록시를 명시하면 앱이 시스템 프록시를 읽는지 여부는 구분할 수 있지만 클라이언트 내부의 분할 라우팅 규칙까지 자동으로 우회하지는 않습니다. 라우팅 규칙 우선순위를 확인하려면 라우팅 분할 안내를 참고하세요.

7. 교차 테스트 후 원격 장애 여부 판단

로컬 리스닝, 시스템 시간, 원격 주소, 핸드셰이크 설정을 모두 확인했다면 범위를 좁혀 교차 테스트하세요. 같은 기기와 노드를 유지한 채 허용된 다른 네트워크에서 시도하고, 이어서 같은 네트워크에서 정상 작동이 확인된 다른 노드를 테스트합니다. 한 번에 조건 하나만 바꿔야 결과를 해석할 수 있습니다.

오류: i/o timeout

원인: 읽기 또는 쓰기 작업이 제한 시간 안에 완료되지 않았습니다. 연결, 핸드셰이크, 전송 단계에서 발생할 수 있으므로 앞뒤 로그를 함께 확인해 위치를 파악해야 합니다.

해결: 로그에 표시된 대상 주소가 원격 노드인지 최종 웹사이트인지 먼저 확인하고 해당 구간에서 포트 테스트 또는 교차 검증을 진행하세요.

오류: connection refused

원인: 대상 포트에서 리스닝 중인 서비스가 없거나 연결이 적극적으로 거부된 상태입니다. 응답이 오랫동안 없는 시간 초과와는 다른 오류입니다.

해결: 연결이 거부된 곳이 로컬 인바운드인지 원격 포트인지 확인하고, 해당 위치에 따라 코어 시작 상태 또는 서버 리스닝 및 방화벽 정책을 점검하세요.

확인 순서: 재현 가능한 문제 구간으로 범위 좁히기

같은 노드가 다른 네트워크에서 정상 작동한다면 기존 네트워크 경로를 우선 점검하세요. 같은 네트워크에서 노드 하나만 실패한다면 해당 노드 설정과 원격 상태를 먼저 확인하세요. 두 결과 모두 원인을 좁히기 위한 단서일 뿐이므로 로그로 확인해야 합니다. 속도 제한이나 차단 문제라고 바로 단정하지 마세요.

환경 기록: 운영체제, 클라이언트 버전, 실제 코어와 버전, 시스템 프록시 또는 TUN 모드 사용 여부.
증상 기록: 실패 시각, 테스트 방법, 모든 앱에서 실패하는지 여부, 최근 변경한 설정 항목.
필요한 로그만 제출: 실패 전후 몇 줄만 남기고 구독 토큰, UUID, 비밀번호, 개인 서버 정보는 가리세요.
진단 설정 복구: 문제 해결 후 평소 로그 수준으로 되돌리고 임시 프록시 환경 변수를 해제한 뒤 더 이상 필요하지 않은 테스트 규칙을 삭제하세요.

원인을 찾지 못했다면 문제 해결 안내의 진단 절차를 따라 계속 확인하세요. 어떤 구간에서 어떤 오류가 발생하며 어떻게 재현되는지 파악하는 편이 구독 업데이트, 코어 변경, 클라이언트 재설치를 반복하는 것보다 문제 해결에 도움이 됩니다.