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

한눈에 보기

노드 테스트가 시간 초과되거나 브라우저에서 웹페이지가 열리지 않고 구독 업데이트도 실패하는 경우에 참고할 수 있는 점검 목록입니다. 시간과 구독 상태를 먼저 확인한 뒤 로컬 리스닝 포트, 원격 포트, 핸드셰이크 설정을 점검하세요. 각 단계에서 확인 가능한 결과를 기록하면 클라이언트가 트래픽을 처리하지 못하는 경우, 네트워크 연결 불가, 프로토콜 설정 불일치를 구분할 수 있어 반복적인 재설치나 여러 설정의 동시 변경을 피할 수 있습니다.

먼저 세 가지 ‘시간 초과’를 구분하세요

시간 초과는 작업이 제한 시간 안에 완료되지 않았다는 뜻이지, 노드가 반드시 고장 났다는 의미는 아닙니다. 구독 업데이트, 노드 테스트, 브라우저 접속은 서로 다른 경로를 거칩니다. 구독 주소는 보통 HTTPS 인터페이스이고, 노드 연결에는 노드 자체의 주소와 포트, 인증 정보가 사용됩니다. 브라우저 접속에는 시스템 프록시나 TUN의 트래픽 처리가 필요합니다. 어떤 작업이 실패했는지 먼저 기록해야 다음 점검 방향을 정할 수 있습니다.

증상	우선 확인할 항목	이 결과만으로 단정할 수 없는 점
구독 업데이트 시간 초과	구독 도메인 확인, 인터페이스 연결 가능 여부, 업데이트 시 프록시 경유 여부	가져온 노드를 모두 사용할 수 없음
노드 테스트 시간 초과	테스트 유형, 원격 포트, 핸드셰이크 설정, 테스트 대상	로컬 시스템 프록시 오류가 원인이라고 단정할 수 없음
테스트는 성공했지만 웹페이지가 열리지 않음	시스템 프록시, 앱 프록시 설정, DNS, 라우팅 규칙	서버가 반드시 정상 또는 비정상이라고 단정할 수 없음

TCP 연결 테스트는 포트에 연결할 수 있는지만 확인하며 UUID, 비밀번호 또는 앱 데이터 교환을 검증하지 않습니다. 실제 연결 테스트는 더 많은 단계를 확인하지만 테스트 사이트에 접속할 수 있어야 합니다. 두 테스트의 결과를 같은 의미로 해석하면 안 됩니다. 문제를 점검할 때는 노드 하나, 대상 URL 하나, 테스트 방식 하나를 정하고 실패 시각과 코어 로그를 기록하세요. 서로 다른 테스트 결과를 섞어 하나의 결론을 내리지 마세요.

1단계: 시스템 시간과 구독 상태 확인

TLS 인증서에는 유효 시작 시각과 만료 시각이 있습니다. 기기 시간이 실제 시간과 크게 다르면 서버 인증서가 정상이어도 아직 유효하지 않거나 이미 만료된 것으로 판단될 수 있습니다. VMess의 일부 인증 절차도 시간에 영향을 받습니다. 표시된 시간대가 다르다고 반드시 문제가 있는 것은 아닙니다. 시스템에 기록된 실제 시간이 정확한지가 중요합니다.

시간 동기화

Windows 11에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’을 열고 ‘시간 자동 설정’을 켠 다음, ‘추가 설정’에서 ‘지금 동기화’를 선택하세요. 동기화에 실패하면 표시된 시각만 수동으로 바꾸지 말고 먼저 일반 네트워크 연결을 확인하세요.
요금제 확인

구독 제공업체의 계정 페이지에서 이용 기간, 남은 트래픽, 서비스 공지를 확인하세요. 구독 링크를 다운로드할 수 있다고 해서 계정의 연결 권한이 유효한 것은 아닙니다. 계정이 만료되지 않았더라도 기존 노드 주소가 계속 유효하다는 보장은 없습니다.
구독 그룹 업데이트

v2rayN의 ‘구독 그룹’ 메뉴에서 해당 그룹을 업데이트하세요. ‘프록시를 사용하지 않고 구독 업데이트’와 ‘프록시를 사용해 구독 업데이트’ 옵션이 있다면 현재 네트워크 환경에 맞는 방법을 먼저 선택하세요. 작동하지 않는 노드에 의존해 업데이트하면 ‘연결해야 고칠 수 있는’ 상황이 반복될 수 있습니다.
노드 다시 선택

업데이트가 끝나면 해당 그룹의 노드를 다시 선택하고 코어에 새 설정이 적용됐는지 확인하세요. 서버 주소와 포트가 바뀌었는지도 살펴보세요. 버전에 따라 메뉴 이름이 조금 다를 수 있으므로 현재 버전의 그룹 업데이트 기능을 기준으로 확인하세요.

2단계: 로컬 포트와 트래픽 진입 경로 확인

먼저 코어가 정상적으로 시작됐는지 확인하고, 브라우저 요청이 코어로 전달되는지 살펴보세요. v2rayN 화면이 열려도 프록시 코어가 포트를 수신 중이라는 뜻은 아닙니다. ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 포트를 확인하세요. 버전에 따라 HTTP와 SOCKS 포트를 따로 쓰거나 혼합 포트를 사용할 수 있으므로 실제 설정과 시작 로그를 기준으로 판단해야 합니다.

10808

이 문서의 로컬 SOCKS 점검용 예시 포트

443

이 문서의 원격 TLS 점검용 예시 포트

15초

이 문서에서 단일 HTTP 테스트에 허용하는 최대 시간

위 숫자는 점검 예시일 뿐 모든 노드에 적용되는 고정 설정이나 실제 속도 측정값이 아닙니다. 아래 명령으로 Windows PowerShell에서 로컬 리스닝 포트와 해당 프로세스를 확인할 수 있습니다. 실제 포트가 10808이 아니라면 명령을 먼저 수정하세요. 결과가 표시되지 않으면 해당 시점에 TCP 포트가 열려 있지 않은 것이므로 코어 시작 로그부터 확인하세요.

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

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

다른 프로그램이 포트를 사용 중이라면 먼저 프로세스가 어떤 용도인지 확인한 뒤 해당 프로그램을 종료하거나 로컬 포트를 변경하세요. 포트를 바꾼 경우 앱의 프록시 설정도 함께 수정해야 합니다. 리스닝 상태가 정상임을 확인했다면 Windows에 기본 포함된 curl.exe에서 SOCKS 프록시를 명시해 브라우저 설정을 거치지 않고 테스트할 수 있습니다.

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://www.example.com/

socks5h는 대상 도메인 조회를 SOCKS 프록시에 맡겨 로컬 DNS 조회가 테스트에 미치는 영향을 줄입니다. 다만 노드 서버 주소 자체의 DNS 조회 문제까지 해결해 주지는 않습니다.
여기서 example.com은 공개된 예시 사이트이며 노드 서버 주소가 아닙니다. 대상 사이트에 접속할 수 없다면 정상 작동을 확인한 HTTPS 사이트로 바꾸세요.
HTTP 응답이 돌아오면 해당 요청이 프록시 경로를 통과한 것입니다. 403 같은 상태 코드도 응답을 받았다는 뜻일 뿐, 대상 사이트에서 접속을 허용했다는 의미는 아닙니다.
프록시를 명시한 테스트는 성공하지만 브라우저에서 실패한다면 시스템 프록시가 같은 포트를 가리키는지, 브라우저에 별도의 프록시 설정이 있는지 확인하세요.

3단계: DNS부터 원격 포트까지 차례로 확인

로컬 진입 경로가 정상이라면 서버 주소를 확인하세요. 도메인 조회 실패와 TCP 연결 실패는 서로 다른 단계입니다. 아래의 node.example.com은 실제로 존재하지 않는 예시 노드 도메인입니다. 실행 전에 구독에 표시된 실제 서버 주소로 바꾸고, 443도 실제 서버 포트로 수정해야 합니다.

Resolve-DnsName node.example.com
Test-NetConnection node.example.com -Port 443 -InformationLevel Detailed

점검 결과	의미	다음 단계
도메인 조회 실패	원격 포트 연결 단계에 아직 도달하지 못함	주소 철자, DNS 연결 가능 여부, 도메인 만료 여부 확인
TcpTestSucceeded가 False	현재 네트워크에서 해당 TCP 포트에 연결하지 못함	원격 리스닝 상태, 방화벽, 네트워크 경로, 포트 입력 오류 확인
TcpTestSucceeded가 True	TCP 3방향 핸드셰이크 성공	TLS, 전송 방식, 프로토콜 인증 설정을 계속 확인

Ping에 실패해도 서버가 ICMP 요청에 응답하지 않는 경우가 있으므로 노드가 고장 났다고 단정할 수 없습니다. 반대로 Ping에 성공해도 서버 포트가 열려 있다는 뜻은 아닙니다. 위 TCP 점검은 TCP를 사용하는 노드에만 적용됩니다. UDP 전송은 이 결과로 판단할 수 없습니다. 도메인에서 IPv4와 IPv6 주소가 모두 반환된다면 실제 연결에 어느 주소 체계가 사용됐는지도 확인하세요.

결론: 네트워크를 바꿀 때는 변수 하나만 변경하세요

같은 기기, 같은 노드, 같은 포트를 유지한 채 기존 네트워크와 모바일 핫스팟에서 각각 테스트하세요. 기존 네트워크에서만 실패한다면 해당 네트워크의 경로와 정책부터 확인하세요. 두 네트워크에서 모두 실패하면 프로토콜을 바로 바꾸지 말고 서버 상태와 설정을 점검하세요.

로컬 방화벽이 현재 코어 프로세스의 외부 연결을 차단하는지 확인하세요. 특히 업데이트 후 프로그램 경로가 달라졌다면 살펴볼 필요가 있습니다. 서버에서는 클라우드 방화벽이나 보안 그룹, 시스템 방화벽, 실제 리스닝 포트를 각각 확인해야 합니다. 모든 방화벽을 끄는 방식은 장기적인 해결책이 아닙니다. 로컬 프록시는 보통 루프백 주소에서만 수신하도록 설정해 인증되지 않은 진입 경로가 LAN에 열리지 않게 해야 합니다.

4단계: TLS, 전송 방식, 인증 설정 확인

원격 포트에 연결되는데도 실패한다면 이제 ‘연결할 수 있는가’가 아니라 ‘양쪽이 같은 프로토콜을 사용하고 있는가’를 확인해야 합니다. VLESS와 VMess는 프록시 프로토콜이고 TCP, WebSocket, gRPC 등은 전송 계층 설정입니다. TLS와 REALITY는 전송 보안과 관련됩니다. 다른 기존 설정은 그대로 둔 채 프로토콜 이름만 바꾸면 새로운 핸드셰이크 오류가 발생할 수 있습니다.

설정 항목	확인할 내용	자주 하는 실수
프로토콜 및 인증	VMess 또는 VLESS, UUID, 서버에서 요구하는 기타 인증 설정	포트가 열려 있으니 인증도 정상일 것이라고 생각함
TLS serverName	서버에서 요구하는 SNI와 인증서에 포함된 도메인	연결 주소, SNI, HTTP Host를 모두 같은 값으로 설정함
WebSocket	path, Host, 리버스 프록시 전달 규칙	경로 앞의 슬래시를 빠뜨리거나 이전 경로를 그대로 사용함
gRPC	serviceName, TLS, 리버스 프록시의 HTTP/2 지원 여부	WebSocket의 path를 serviceName으로 그대로 사용함
REALITY	서버에서 지정한 serverName, 공개 키, shortId, 적용 가능한 flow	일반 TLS 인증서 테스트를 REALITY 인증 확인 대신 사용함

REALITY는 Xray 생태계의 기능이므로 해당 설정을 V2Fly 코어에서 그대로 사용할 수 없습니다. Android에서는 v2rayNG가 Xray 코어를, v2flyNG가 V2Fly 코어를 사용합니다. 선택하기 전에 사용 중인 코어 버전이 프로토콜과 각 설정 항목을 지원하는지 확인하세요. 데스크톱 v2rayN도 클라이언트 이름만 보지 말고 현재 실행 중인 코어와 로그를 확인해야 합니다.

일반 TLS 노드라면 OpenSSL이 설치된 Linux 또는 macOS 터미널에서 인증서와 TLS 핸드셰이크를 따로 확인할 수 있습니다. 아래의 두 도메인은 모두 존재하지 않는 예시이므로 실제 연결 주소와 서버에서 요구하는 SNI로 각각 바꿔야 합니다.

openssl s_client -connect node.example.com:443 -servername tls.example.com -verify_hostname tls.example.com -verify_return_error < /dev/null

이 명령은 VMess 또는 VLESS 인증, WebSocket 경로, gRPC 서비스 이름을 확인하지 않습니다.
인증서 검증에 실패하면 시스템 시간, 도메인 일치 여부, 인증서 체인을 먼저 확인하세요. 인증서 검증을 계속 꺼 두는 방식으로 문제를 숨기지 마세요.
REALITY는 전용 설정값이 일치해야 합니다. 일반 TLS 도구에서 응답을 받았더라도 REALITY 노드가 작동한다는 증거는 아닙니다.
연결 주소에 IP를 사용하더라도 serverName에는 별도의 도메인이 필요할 수 있습니다. 구체적인 설정은 서버 구성을 확인하세요.

5단계: 로그 원문으로 문제 지점 찾기

코어를 다시 시작한 뒤 실패하는 요청을 한 번만 발생시키고 해당 시점 전후의 로그를 확인하세요. 오류 문구는 운영체제와 코어 버전에 따라 달라질 수 있으므로 연결 주소, 대상 포트, 아웃바운드 태그가 포함된 앞뒤 내용도 함께 살펴봐야 합니다. 다음은 흔히 볼 수 있는 오류 일부이며 모든 환경의 전체 로그 형식을 나타내지는 않습니다.

오류: bind: address already in use

원인: 로컬 리스닝 주소와 포트를 이미 다른 프로세스가 사용 중이어서 코어가 포트를 열지 못했습니다.

해결 방법: 포트 조회 명령으로 해당 프로세스를 확인하고 충돌을 해결한 뒤 코어를 다시 시작하세요. 포트를 변경했다면 시스템 프록시와 앱 설정도 함께 업데이트해야 합니다.

오류: no such host

원인: 도메인 조회에 실패했습니다. 노드 도메인일 수도 있고 요청 대상의 도메인일 수도 있습니다.

해결 방법: 먼저 로그에서 조회에 실패한 도메인을 확인한 다음 철자와 해당 DNS 경로를 점검하세요. 대상 도메인 조회 실패를 서버 중단으로 오해하지 않도록 주의하세요.

오류: connect: connection refused

원인: 연결 요청이 명시적으로 거부됐습니다. 해당 포트에서 서비스가 수신 대기 중이지 않거나 방화벽이 연결을 거부하는 경우가 흔합니다.

해결 방법: 구독에 표시된 포트를 확인하세요. 서버 관리 권한이 있다면 리스닝 상태와 방화벽을 점검하고, 권한이 없다면 민감 정보를 삭제한 점검 결과를 제공업체에 전달하세요.

오류: i/o timeout

원인: 연결 또는 읽기·쓰기 단계에서 대기 시간이 초과됐습니다. 이 메시지만으로는 네트워크, 핸드셰이크, 대상 응답 중 어디서 발생했는지 알 수 없습니다.

해결 방법: 앞뒤 로그로 시간 초과가 발생한 단계를 확인하세요. 원격 TCP 포트를 먼저 테스트하고 핸드셰이크 설정을 점검한 뒤 다른 네트워크에서 변수를 하나씩 바꿔 재테스트하세요.

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

원인: 인증서 유효기간 검증에 실패했습니다. 기기 시간이 잘못됐거나 서버 인증서가 실제로 만료됐을 수 있습니다.

해결 방법: 먼저 시스템 시간을 동기화하세요. 시간이 정확한데도 오류가 계속되면 서버 관리자가 인증서를 갱신하고 인증서 체인을 확인해야 합니다.

로그 수준을 높여야 한다면 짧은 시간 동안 재현할 때만 활성화하고 작업이 끝나면 원래대로 되돌리세요. 상세 로그에는 대상 도메인과 연결 정보가 포함될 수 있고 디스크 쓰기도 늘어납니다. 공개적으로 도움을 요청할 때는 작업 시각, 클라이언트와 코어 버전, 실패 단계, 오류 원문을 남기고 전체 설정 파일은 올리지 않는 것이 좋습니다.

자주 묻는 질문과 마무리 점검

구독 업데이트는 성공했는데 노드가 계속 시간 초과되는 이유는 무엇인가요?

구독 다운로드와 노드 연결은 서로 다른 경로를 사용합니다. 먼저 계정이 유효한지 확인한 다음 새 노드가 선택됐는지 점검하세요. 원격 포트 테스트로 네트워크 연결 불가와 핸드셰이크 실패를 구분할 수 있습니다. 설정을 받았다는 사실만으로 실제 연결이 검증된 것은 아닙니다.

테스트 결과는 있는데 브라우저에서 페이지가 열리지 않으면 어떻게 하나요?

먼저 이 문서의 curl.exe 명시적 프록시 명령으로 같은 대상에 접속해 보세요. 성공하면 시스템 프록시가 켜져 있는지, 포트가 일치하는지, 브라우저에 별도 프록시 설정이 있는지 확인하세요. 일부 사이트만 실패한다면 해당 사이트의 라우팅 규칙과 DNS를 살펴보세요. 모든 노드를 바로 바꿀 필요는 없습니다.

시간 초과 시간을 늘리면 해결되나요?

실제 연결이 느리지만 결국 완료되는 경우에만 대기 시간을 늘리는 것이 의미가 있습니다. 포트 오류, UUID 불일치, 인증서 도메인 오류는 몇 초 더 기다린다고 해결되지 않습니다. 먼저 실패 단계를 찾고 테스트 제한 시간을 조정할지 결정하세요.

TUN을 켠 뒤 인터넷이 끊기면 어디를 확인해야 하나요?

먼저 TUN을 끄고 로컬 SOCKS 명시적 프록시로 기본 노드 연결을 확인하세요. 기본 연결이 정상이라면 TUN에 필요한 권한, 라우팅 처리, DNS 설정을 점검하세요. 같은 노드를 바꾸면서 TUN과 시스템 프록시를 번갈아 전환하면 동일한 문제를 재현하기 어렵습니다.

결론: ‘시간 초과’ 화면보다 실패 단계를 기록하세요

‘시간 및 계정 → 로컬 리스닝 → 도메인 및 포트 → TLS 및 전송 → 앱 트래픽 처리’ 순서로 결과를 기록하세요. 처음으로 실패가 확인된 단계가 다음에 해결해야 할 지점입니다. 수정한 뒤에는 그 단계부터 다시 테스트하고 브라우저에서 실제로 접속되는지도 확인하세요.

수정이 끝나면 임시로 변경한 로그 수준과 테스트 설정을 원래대로 복구하고 로컬 진입 경로가 필요한 범위에만 열려 있는지 확인하세요. 문제가 계속된다면 사이트의 연결 문제 해결 안내를 참고하세요. 구독 업데이트 경로 문제는 구독 관리 안내에서 확인할 수 있습니다. 문의할 때 이미 완료한 점검 내용을 구체적으로 적으면 불필요한 추가 질문과 무관한 설정 변경을 줄일 수 있습니다.