· 문제 해결 · 약 10분

V2Ray 노드 연결 시간 초과·접속 불가: PC 시간부터 전송 설정까지 점검하는 방법

노드 연결 시간 초과는 가까운 항목부터 점검하세요. 시스템 시간, 클라이언트 프록시 모드, 포트 점유, 전송 및 TLS 설정, 라우팅 규칙을 단계별로 확인하고 해결 방법을 안내합니다.

이 글 미리보기

설정을 가져온 뒤 연결 테스트가 시간 초과되거나 웹페이지가 열리지 않는 경우에 적합한 안내입니다. 먼저 로컬 프록시가 작동하는지 확인한 다음 원격 포트, 전송 및 TLS를 점검하고 마지막으로 라우팅과 DNS를 살펴봅니다. Windows용 v2rayN을 기준으로 한 번에 한 항목만 변경하고, 로그와 동일한 요청으로 결과를 확인하세요. 속도 테스트 실패만으로 노드가 작동하지 않는다고 단정하지 마세요.

1. 테스트 시간 초과와 연결 실패 구분하기

‘시간 초과’는 작업이 정해진 시간 안에 완료되지 않았다는 뜻일 뿐, 문제가 발생한 위치를 알려주지는 않습니다. 지연 시간 테스트, 구독 업데이트, 브라우저 접속은 서로 다른 요청 경로를 사용합니다. 구독 서버에 연결되지 않아도 이미 가져온 노드는 작동할 수 있고, 테스트 주소 응답이 느려도 모든 웹사이트에 접속할 수 없는 것은 아닙니다.

증상먼저 확인할 항목다음 단계
지연 시간 테스트만 시간 초과됨실제 웹페이지 접속 여부, 테스트 주소 연결 여부고정 URL로 프록시 요청 보내기
브라우저에서 접속할 수 없고 코어 로그에 요청이 없음시스템 프록시, 로컬 수신 포트, 브라우저 프록시 확장 프로그램로컬 프록시부터 테스트
로그에 원격 연결 시간 초과가 기록됨노드 도메인 DNS 조회, 원격 포트, 현재 네트워크원격 서버 연결 여부 확인
일부 웹사이트만 접속되지 않음라우팅 규칙 적용 여부, 대상 사이트, DNS해당 도메인의 아웃바운드 로그 확인

테스트 전에 현재 노드 이름, 클라이언트 버전, 사용 중인 코어와 테스트 시간을 기록하세요. v2rayN은 클라이언트 인터페이스이며 실제 연결은 코어가 담당합니다. 인터페이스가 열려 있어도 코어가 정상적으로 시작됐다는 뜻은 아닙니다. 버전은 ‘도움말’ → ‘정보’에서 확인할 수 있습니다. 메뉴 이름은 버전에 따라 다를 수 있으니 실제 화면에 표시된 내용을 기준으로 기록하세요.

2. 시스템 시간 맞추기 및 최소 테스트 환경 만들기

PC 날짜와 시간이 맞지 않으면 인증서 유효 기간을 잘못 판단하거나 VMess의 시간 기반 인증이 실패할 수 있습니다. VLESS는 같은 시간 인증 방식을 사용하지 않지만, TLS를 사용하는 경우 인증서의 시간 검증은 여전히 적용됩니다. 먼저 날짜와 시간을 동기화하고 모든 인증 오류를 프로토콜 문제로 단정하지 마세요.

  1. 시간 동기화

    Windows 11에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’을 열고 ‘시간 자동 설정’을 켭니다. ‘추가 설정’에서 ‘지금 동기화’를 선택하세요. 날짜와 시간대도 확인해야 합니다. 표시 시간대만 바꾸면 잘못된 시스템 시계가 바로잡히지 않습니다.

  2. 노드 고정하기

    v2rayN 노드 목록에서 대상 항목을 마우스 오른쪽 버튼으로 클릭하고 ‘활성 서버로 설정’을 선택하세요. 문제를 해결하는 동안 이 설정 하나만 사용하고 자동 전환은 끄세요. 요청마다 서로 다른 서버를 사용해 결과가 달라지는 일을 방지할 수 있습니다.

  3. 연결 경로 단순화하기

    먼저 v2rayN 메인 화면에서 ‘TUN 사용’을 끄고 트래픽을 가로채는 다른 프록시나 VPN 프로그램도 종료하세요. 이는 변수를 줄이기 위한 조치입니다. 로컬 프록시 테스트를 마친 뒤 TUN은 별도로 확인하세요.

  4. 한 번 재현하기

    로그 창을 열고 현재 시간을 기록한 다음 고정 URL 하나에만 접속하세요. 해당 요청 전후의 오류를 보관하세요. 노드를 여러 개 연달아 바꾸고 뒤섞인 로그만 보고 원인을 추측하지 마세요.

3. 시스템 프록시와 로컬 수신 포트 확인하기

먼저 v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트 항목을 찾아 실제 포트 번호와 프로토콜을 확인하세요. 아래 예시는 127.0.0.1:10808 SOCKS 주소를 사용하며 모든 버전이나 설치 환경에서 같은 포트를 쓴다는 뜻은 아닙니다. PC의 포트 번호가 다르면 명령도 그에 맞게 바꾸세요.

10808
이 글에서 예시로 사용한 로컬 SOCKS 포트
443
HTTPS에서 자주 쓰는 포트이며, 노드의 고정 포트는 아님
15초
아래 진단 요청의 최대 대기 시간

Windows PowerShell에서 아래 두 명령을 실행하세요. 첫 번째 명령은 수신 상태와 프로세스 ID를 확인합니다. 두 번째 명령은 앱이 시스템 프록시를 사용하는지와 관계없이 로컬 SOCKS를 통해 직접 요청을 보냅니다. example.com은 테스트용 예시 사이트입니다. 요청이 한 번 실패하면 정상 작동을 확인한 다른 URL로 다시 테스트하세요.

netstat -ano | findstr ":10808"
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 15 -I https://example.com/

명령이 성공하면 v2rayN 하단의 ‘시스템 프록시’ 메뉴에서 ‘시스템 프록시 자동 설정’을 선택한 다음 브라우저에서 다시 접속하세요. Windows의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 프록시 주소와 포트도 확인할 수 있습니다. 이때 포트는 클라이언트의 HTTP 또는 혼합 프록시 주소와 일치해야 합니다. SOCKS만 지원하는 포트를 임의로 입력하지 마세요.

결론: 먼저 로컬 프록시가 작동하는지 확인하세요

로컬 프록시 주소를 명시한 요청은 성공하지만 브라우저에서는 실패한다면, 먼저 앱의 프록시 설정을 바로잡으세요. 노드의 UUID, TLS 또는 전송 경로를 계속 변경할 필요는 없습니다.

4. 로그에서 DNS 오류, 연결 거부, 시간 초과 구분하기

로컬 프록시가 정상이라면 코어가 원격 서버에 연결할 때 발생한 오류를 확인하세요. 아래는 자주 보이는 로그 예시이며, 실제 접두사와 접미사는 코어와 운영체제에 따라 달라질 수 있습니다. 오류 한 줄만으로는 원인을 확정할 수 없으니 대상 주소와 발생 시간을 함께 확인하세요.

no such host

원인: 관련 도메인을 조회하지 못한 상태입니다. 노드 도메인일 수도 있고 대상 웹사이트 도메인일 수도 있습니다.

해결: 먼저 로그에 표시된 도메인이 무엇인지 확인하고 철자와 PC의 DNS 설정을 점검하세요. DNS 조회 실패만 보고 노드 전체를 교체하지 마세요.

connection refused

원인: 연결이 명시적으로 거부됐습니다. 대상 포트에서 서비스가 실행 중이지 않거나 연결을 거부할 때 흔히 발생합니다.

해결: 원격 포트와 서비스 상태를 확인하세요. 오류에 표시된 주소가 로컬 루프백 주소라면 로컬 수신 설정을 다시 확인하세요.

i/o timeout

원인: 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 끝나지 않았습니다. 네트워크 경로, 방화벽, 서버 부하 또는 후속 핸드셰이크가 원인일 수 있습니다.

해결: 먼저 연결을 시작하는 단계에서 발생했는지 핸드셰이크 단계에서 발생했는지 확인하세요. 같은 설정으로 다른 네트워크에서도 테스트해 보세요. 이 오류만으로 계정이 만료됐다고 단정하지 마세요.

address already in use

원인: 코어가 사용하려는 로컬 주소와 포트를 다른 프로세스가 이미 사용 중입니다.

해결: PID로 포트를 점유한 프로그램을 찾고 중복 실행을 종료하세요. 또는 로컬 포트를 바꾼 뒤 앱의 프록시 설정도 함께 수정하세요.

서버 주소와 포트를 알고 있다면 PowerShell의 Test-NetConnection으로 TCP 연결을 확인할 수 있습니다. 아래는 명령 형식의 예시일 뿐이며, example.com:443은 실제 노드 주소가 아닙니다. 진단할 때는 구독 제공자가 안내한 서버와 포트로 바꾸세요.

Test-NetConnection -ComputerName example.com -Port 443

TcpTestSucceeded: True는 TCP 연결이 성립했다는 뜻일 뿐, TLS, VMess 또는 VLESS 인증이 성공했다는 뜻은 아닙니다. UDP 기반 전송은 이 TCP 검사로 데이터 연결을 확인할 수도 없습니다. 같은 설정이 모바일 핫스폿에서는 작동하지만 현재 네트워크에서는 실패한다면 네트워크 제한을 우선 점검하세요. 다만 한 번의 네트워크 비교만으로 결론 내리지 말고 서버 로그도 함께 확인해야 합니다.

5. 전송 및 TLS 설정을 항목별로 비교하기

원격 포트에 연결되지만 핸드셰이크가 실패한다면 노드 편집 창을 열고 제공받은 원본 설정과 각 항목을 비교하세요. 포트가 443이라고 해서 TLS를 반드시 켜야 하는 것은 아닙니다. 오류를 없애려고 인증서 검증을 함부로 끄지 마세요.

확인 항목일치해야 하는 설정자주 하는 실수
프로토콜 및 인증VMess 또는 VLESS, UUID 및 설정에서 요구하는 기타 인증 정보프로토콜 이름만 바꾸고 다른 프로토콜의 설정 항목은 그대로 둠
주소 및 포트서버 주소와 원격 수신 포트로컬 포트 10808을 원격 포트로 입력함
WebSocket전송 방식, 경로, Host경로 앞의 슬래시를 빠뜨리거나 Host를 SNI로 간주함
gRPC전송 방식, serviceName 및 서버가 요구하는 TLS 설정serviceName에 WebSocket 경로처럼 임의로 슬래시를 추가함
TLS사용 여부, serverName/SNI, 인증서 신뢰 및 유효 기간연결 주소를 IP로 바꾸면서 SNI도 IP로 변경함
REALITYserverName, 공개 키, shortId, fingerprint, flow 등 함께 설정해야 하는 항목일반 TLS 설정으로 간주해 서로 다른 설정의 값을 섞음

x509: certificate has expired or is not yet valid

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

해결: 먼저 시스템 시간을 동기화하세요. 시간이 올바른데도 문제가 계속되면 서비스 제공자에게 인증서 설치 상태와 갱신 여부를 확인해 달라고 요청하세요.

websocket: bad handshake

원인: WebSocket 업그레이드 핸드셰이크가 예상한 응답을 받지 못했습니다. 경로, Host 또는 리버스 프록시 규칙이 일치하지 않을 때 흔히 발생합니다.

해결: 원본 설정을 기준으로 경로와 Host를 복원하고, 서버에서 해당 사이트의 프록시 전달 규칙을 확인하도록 요청하세요.

VMess와 VLESS는 프록시 프로토콜이고 WebSocket과 gRPC는 전송 방식이며 TLS는 보안 계층입니다. 서로 바꿔 쓸 수 있는 항목이 아닙니다. 구독을 업데이트한 뒤 설정 항목이 누락된 것처럼 보인다면 노드 설정을 직접 조합하지 말고 제공자가 확인한 설정을 다시 가져오세요. 사용 중인 코어가 해당 조합을 지원하는지도 확인해야 합니다.

6. 라우팅, DNS, TUN 확인하기

같은 노드로 일부 웹사이트에만 접속할 수 없다면 모든 요청이 실패하는 경우보다 트래픽 분기를 주의 깊게 확인해야 합니다. v2rayN 하단의 라우팅 선택과 시스템 프록시는 서로 다른 기능입니다. 시스템 프록시는 앱이 요청을 보낼 위치를 정하고, 코어 라우팅은 요청을 받은 뒤 어떤 아웃바운드로 보낼지 결정합니다. 앱이 로컬 프록시를 우회하면 코어의 규칙을 바꿔도 적용되지 않습니다.

로컬 프록시가 정상 작동하는 것을 확인한 다음 ‘TUN 사용’을 켜고 시스템 프록시를 사용하지 않는 앱을 테스트하세요. TUN은 가상 네트워크 어댑터, 라우팅, DNS 가로채기를 사용할 수 있으며 관련 권한이 필요할 수도 있습니다. TUN을 켜자마자 인터넷 연결이 끊기면 먼저 TUN을 끄고 네트워크가 복구되는지 확인하세요. 그런 다음 권한, 다른 VPN의 라우팅, 가상 어댑터 충돌을 살펴보고 전송 설정은 동시에 바꾸지 마세요.

결론: 같은 요청으로 TUN 문제 구분하기

같은 노드가 로컬 프록시를 명시적으로 사용하면 작동하지만 TUN을 켠 뒤에만 실패한다면 원격 프로토콜을 바꾸기보다 가상 네트워크 어댑터, 라우팅, DNS 가로채기를 확인하세요.

7. 자주 묻는 질문과 점검을 멈춰도 되는 경우

지연 시간 테스트는 전부 시간 초과인데 웹페이지는 열립니다. 노드를 바꿔야 하나요?

아직 바꿀 필요는 없습니다. 웹페이지가 실제로 프록시를 통해 접속되는지 확인한 다음 테스트 주소, 테스트 방식, 시간 초과 설정을 점검하세요. 같은 URL에 반복해서 접속해 실제 상태를 확인하고 단일 테스트 결과만으로 연결 여부를 판단하지 마세요.

구독 업데이트가 시간 초과됩니다. 프록시를 통한 업데이트를 켜야 하나요?

먼저 구독 URL이 유효한지, 현재 사용할 수 있는 프록시가 있는지 확인하세요. 구독 서버에 직접 연결하면 실패하지만 프록시로는 접속할 수 있다면 해당 프록시 업데이트 방식을 선택하세요. 사용할 수 있는 노드가 하나도 없을 때 프록시 업데이트를 강제하면 반복적으로 실패할 수 있습니다.

PC에서는 연결되는데 Android에서 같은 설정으로 연결되지 않나요?

먼저 두 기기를 같은 네트워크에 연결하고 시간, 활성 설정, 로그를 비교하세요. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용하므로 설정 지원 여부는 각 코어를 기준으로 확인해야 합니다. Xray 전용 기능을 사용하는 설정은 공유 링크를 가져오는 데 성공했다는 이유만으로 호환된다고 판단하지 마세요.

시간 초과를 5초에서 30초로 늘리면 해결되나요?

응답이 느린 경우 기다리는 시간만 늘어날 수 있습니다. 잘못된 포트, 인증 정보, 인증서 문제는 해결되지 않습니다. 먼저 동일한 최대 대기 시간으로 변경 전후를 비교하세요. 요청이 결국 실패한다면 로그에서 실패 단계를 계속 확인해야 합니다.

로컬 포트가 정상이고 설정을 원본과 대조했으며 시스템 시간도 올바른데, 같은 노드가 서로 다른 두 네트워크에서 동일한 단계에서 계속 실패한다면 무작위로 설정을 바꾸는 일을 멈춰도 됩니다. 이때는 개인정보를 가린 발생 시간, 코어 버전, 오류 로그 일부, 원격 포트 테스트 결과를 서비스 제공자에게 전달하세요. DNS를 계속 임의로 바꾸는 것보다 효과적입니다.

v2rayN 다운로드운영체제에 맞는 설치 파일을 선택하세요