V2Ray 노드 연결 시간 초과 해결: 시스템 시간·포트·전송 계층 점검 순서

이 글의 핵심

v2rayN은 실행되고 노드도 가져왔지만 지연 시간 테스트가 시간 초과되거나 브라우저에서 접속할 수 없는 경우를 다룹니다. 먼저 로컬 프록시 미실행, 원격 포트 연결 불가, 프로토콜 핸드셰이크 실패를 구분한 다음 시스템 시간, 로컬 리스닝, 방화벽, 전송 설정, 라우팅 및 DNS 순으로 확인하세요. 각 단계의 테스트 결과를 하나씩 기록하면 여러 설정을 동시에 바꾸는 일을 막을 수 있습니다.

1. 시간 초과가 발생하는 계층 확인하기

‘노드 시간 초과’는 하나의 고장만을 뜻하지 않습니다. TCP 지연 시간 테스트는 보통 원격 포트에 연결할 수 있는지만 확인합니다. 실제 연결 또는 사용 가능 여부 테스트는 프록시 프로토콜과 대상 사이트까지 거칩니다. 테스트 대상에 따라 결과도 달라질 수 있습니다. 따라서 TCP 테스트에 성공해도 VMess 또는 VLESS 인증에 성공했다는 뜻은 아니며, 특정 테스트 사이트에 접속하지 못해도 모든 트래픽이 차단된 것은 아닙니다.

앱 프록시 설정 로컬 포트 리스닝 원격 포트 연결 전송 계층 핸드셰이크 프로토콜 인증 대상 사이트 접속

먼저 노드 하나를 정해 고정 테스트 대상으로 삼고 테스트 시간, 서버 주소, 포트, 프로토콜, 전송 방식, 현재 코어를 기록하세요. v2rayN 메인 화면의 로그 영역을 열고 요청을 다시 보낸 다음, 같은 시각에 기록된 첫 오류를 찾습니다. 그 뒤에 이어지는 연결 종료 메시지는 앞선 오류의 결과인 경우가 많습니다.

모든 노드에서 동시에 실패: 먼저 시스템 시간, 로컬 코어, 네트워크 출구, 구독 전체의 작동 여부를 확인하세요.
특정 노드 하나만 실패: 해당 노드의 설정값, 서버 실행 상태, 계정 유효성을 먼저 확인하세요.
프록시 테스트는 성공하지만 브라우저에서 실패: 앱이 시스템 프록시를 사용하는지, 브라우저 확장 프로그램이 프록시 설정을 덮어쓰는지 먼저 확인하세요.
일부 사이트에서만 실패: 클라이언트를 재설치하기 전에 분할 라우팅 규칙, DNS, 대상 사이트 접속 가능성을 확인하세요.

2. 시스템 시간을 맞춘 뒤 연결 다시 시도하기

VMess 인증에는 시간 요소가 포함됩니다. 클라이언트와 서버의 시각 차이가 크면 인증에 실패할 수 있습니다. TLS 인증서 검증도 현재 시각에 의존하므로 연도나 날짜가 잘못되면 유효한 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판정될 수 있습니다. VLESS에 VMess의 시간 범위 검사를 그대로 적용할 수는 없지만, TLS와 같은 보안 계층을 사용할 때는 시스템 시간이 정확해야 합니다.

시스템 시간 동기화

Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 ‘자동으로 시간 설정’을 켠 다음 ‘지금 동기화’를 누르세요. macOS에서는 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 날짜와 시간 자동 설정을 켜세요.
실제 시각 확인

연월일과 현재 시각이 올바른지 확인하세요. 시간대는 표시 방식에 영향을 주며, 인증은 실제 타임스탬프를 기준으로 합니다. 표시 시간대를 서버 위치에 맞추는 것만으로 해결하려 하지 마세요. 컴퓨터가 절전 모드에서 깨어난 뒤 시간이 반복해서 어긋난다면 시스템 시간 서비스와 하드웨어 시계를 점검하세요.
노드 다시 불러오기

v2rayN에서 현재 노드를 다시 선택해 설정을 불러온 뒤 같은 연결 테스트를 실행하세요. 직접 서버를 관리한다면 서버의 시간도 확인해야 합니다. 클라이언트 시간만 바로잡아서는 서버의 큰 시간 오차를 해결할 수 없습니다.

3. 로컬 포트 확인하기: 10808과 10809는 실제 설정을 기준으로

v2rayN은 클라이언트 인터페이스이며, 실제로 포트를 열고 연결을 전달하는 것은 실행 중인 코어입니다. 코어가 시작되지 않으면 인터페이스에 노드 목록이 남아 있어도 앱이 로컬 프록시 포트에 접속할 때 바로 실패할 수 있습니다. 버전과 설정에 따라 포트의 의미가 다를 수 있습니다. 흔히 쓰이는 설정은 10808을 사용하며, 이전 설정에서는 SOCKS 포트 10808과 HTTP 포트 10809를 따로 사용할 수 있습니다. 혼합 인바운드를 지원하는 설정은 하나의 포트로 두 종류의 요청을 모두 받을 수 있습니다.

‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 포트와 주소를 확인하세요. 항목 이름은 현재 버전에 따라 다를 수 있습니다. 그런 다음 로그에 리스닝 성공 기록이 있는지 살펴보세요. 온라인 안내만 보고 브라우저에 10809를 입력하거나, 로컬 프록시 포트를 원격 서버 포트 항목에 잘못 입력하지 마세요.

운영체제	확인 명령	확인할 항목
Windows PowerShell	`Get-NetTCPConnection -State Listen -LocalPort 10808`	리스닝 기록이 있는지, OwningProcess가 예상한 코어 프로세스인지 확인
Windows 프로세스 조회	`Get-Process -Id 1234`	1234를 앞 단계에서 확인한 프로세스 번호로 바꾸세요
macOS 터미널	`lsof -nP -iTCP:10808 -sTCP:LISTEN`	리스닝 프로세스와 포트를 확인하세요. 출력이 없으면 코어 로그를 추가로 확인하세요

포트를 다른 프로그램이 사용 중이라면 먼저 해당 프로세스를 확인하고, 정체를 모르는 시스템 서비스를 바로 종료하지 마세요. 중복 실행된 클라이언트를 종료하거나 로컬 포트를 비어 있는 포트로 바꾼 뒤 앱의 프록시 설정도 함께 변경할 수 있습니다. 이 컴퓨터에서만 사용할 경우 보통 127.0.0.1에 바인딩하면 충분하며, 문제 해결을 위해 LAN 접속을 허용할 필요는 없습니다.

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

Windows에서는 명령 별칭 차이를 피하려면 curl.exe를 사용할 수 있습니다. 위 명령은 해당 포트에서 SOCKS를 지원하는 경우에만 사용할 수 있으며, socks5h는 대상 도메인의 처리를 프록시에 맡긴다는 뜻입니다. HTTP 인바운드만 사용하는 경우 프록시 주소를 http://127.0.0.1:10809로 바꾸고 실제 포트를 사용하세요. HTTP 응답을 받았다면 해당 요청의 프록시 연결 경로가 완료된 것입니다. 403 응답이 오더라도 연결 시간 초과와는 구분해서 처리해야 합니다.

4. Ping 대신 원격 포트와 방화벽 확인하기

서버에서 ICMP를 차단할 수 있으므로 Ping에 실패해도 프록시 서비스에 연결할 수 없다는 뜻은 아닙니다. 반대로 Ping에 성공해도 프록시 포트가 리스닝 중이라는 뜻은 아닙니다. TCP 기반 연결이라면 노드에 실제로 설정된 서버 주소와 포트를 테스트하세요. 아래 도메인은 명령 형식을 보여 주기 위한 예시입니다. 실행할 때는 노드 설정의 실제 주소로 바꾸고 포트도 실제 값으로 지정하세요.

# Windows PowerShell: TCP 포트 테스트
Test-NetConnection -ComputerName example.com -Port 443

# macOS: TCP 포트 테스트
nc -vz -G 10 example.com 443

포트 테스트 성공: 이번 TCP 연결이 성립했다는 뜻입니다. 이어서 TLS, 전송 방식, 프로토콜 인증을 확인하세요. 노드가 완전히 작동한다는 의미는 아닙니다.
즉시 연결 거부: 서비스가 리스닝하지 않거나 포트가 잘못되었거나 방화벽이 연결을 적극적으로 거부했을 수 있습니다. 서버 관리자가 프로세스, 리스닝 포트, 인바운드 규칙을 확인해야 합니다.
대기 후 시간 초과: 패킷 손실, 네트워크 출구 제한, 서버 방화벽 또는 보안 그룹의 패킷 차단이 원인일 수 있습니다. 다른 네트워크에서도 테스트해 보세요.
UDP 전송을 사용하는 경우: TCP 테스트로 UDP를 확인할 수는 없습니다. 해당 코어 로그와 서버 기록을 함께 살펴보세요.

로컬 방화벽에서는 코어 프로그램의 아웃바운드 권한을 우선 확인하세요. 다른 기기와 프록시를 공유할 때만 로컬 프록시 인바운드 규칙을 추가로 확인하면 됩니다. 문제 해결을 위해 방화벽 전체를 장시간 끄지 마세요. 기업 네트워크의 제한은 네트워크 관리자에게 규칙에 따라 확인을 요청해야 합니다. 서버 측에서는 클라우드 플랫폼의 보안 그룹과 운영체제 방화벽을 모두 확인하세요. 둘 중 하나라도 포트를 허용하지 않으면 시간 초과가 발생할 수 있습니다.

결론: 먼저 다른 네트워크에서 교차 테스트

같은 노드와 설정을 그대로 두고 컴퓨터의 네트워크만 Android 휴대전화 핫스팟으로 바꿔 다시 테스트하세요. 기존 네트워크에서는 시간 초과가 발생하지만 핫스팟에서는 연결된다면 기존 네트워크의 출구, DNS 또는 포트 정책을 먼저 살펴보세요. 노드, 코어, 라우팅을 동시에 바꾸는 것보다 원인을 좁히기 쉽습니다.

5. 전송 계층 설정 대조하기: 포트가 열려 있어도 핸드셰이크는 실패할 수 있습니다

VMess와 VLESS는 프록시 프로토콜이고 WebSocket과 gRPC 등은 전송 방식이며 TLS는 보안 계층입니다. 서로 다른 설정 계층이므로 대체해서 사용할 수 없습니다. 링크를 가져온 뒤에도 주요 항목을 확인해야 합니다. 특히 리버스 프록시나 중계 서버를 거치는 노드는 연결 주소, TLS 검증 도메인, HTTP Host가 서로 다를 수 있습니다.

확인 항목	일치해야 하는 설정	자주 하는 실수
프로토콜 및 인증 정보	VMess 또는 VLESS 유형, UUID, 서버에서 요구하는 관련 매개변수	프로토콜 이름만 바꾸고 다른 유형 노드의 설정을 그대로 사용
TLS 및 SNI	TLS 사용 여부, 검증 도메인, 인증서 적용 범위	연결 주소를 IP로 바꾸면서 필요한 SNI까지 삭제
WebSocket	전송 방식, 경로, Host, 리버스 프록시 규칙	`/ray`와 `/ray/`를 혼용하거나 경로의 대소문자가 다름
gRPC	서비스 이름과 서버에서 요구하는 HTTP/2 및 TLS 설정	WebSocket 경로를 서비스 이름에 그대로 입력
VLESS 보안 매개변수	서버가 지정한 flow, REALITY 사용 시 공개 키·shortId·serverName 등	다른 노드의 보안 매개변수를 복사하거나 보안 계층을 임의로 변경

구독이 업데이트되었다면 먼저 ‘구독 그룹’ 메뉴에서 해당 그룹을 업데이트한 뒤 노드를 다시 선택하세요. 수동 편집한 기존 노드에는 만료된 포트, 경로, 인증 정보가 남아 있을 수 있습니다. ‘특정 코어 사용’을 모든 노드와 호환된다는 뜻으로 받아들이지 마세요. 현재 Xray-core 등 실제 실행 중인 코어가 해당 노드의 기능을 지원하는지 확인하고, 클라이언트에서 제공하는 호환 코어를 우선 사용하세요.

오류: bind: address already in use

원인: 로컬 리스닝 주소와 포트를 다른 프로세스가 사용 중이어서 현재 코어가 바인딩하지 못합니다.

해결: 포트를 점유한 프로세스를 확인하고 중복 인스턴스를 종료하거나 로컬 포트를 변경한 다음 앱의 프록시 포트도 함께 수정하세요.

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

원인: 컴퓨터의 시간이 잘못되었거나 서버 인증서의 유효 기간이 실제로 만료되었을 수 있습니다.

해결: 먼저 시간을 동기화하세요. 시간이 정확한데도 같은 오류가 발생하면 관리자에게 인증서 갱신과 실제로 전달되는 인증서 체인을 확인해 달라고 요청하세요.

오류: websocket: bad handshake

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

해결: 경로와 Host를 정확히 대조하고, 서버 관리자에게 인바운드 응답 상태와 업그레이드 요청 전달 설정을 확인해 달라고 요청하세요.

오류: context deadline exceeded

원인: 작업이 제한 시간 안에 완료되지 않았다는 뜻입니다. 이 메시지만으로 인증, DNS, 네트워크 중 어느 단계에서 문제가 발생했는지는 알 수 없습니다.

해결: 오류 전후의 연결 대상과 기록을 확인하고 로컬 리스닝 및 원격 포트 테스트 결과를 함께 살펴 시간 초과가 발생한 계층을 찾으세요.

6. 프록시 연결이 정상이라면 시스템 프록시, DNS, 라우팅 확인하기

프록시를 명시한 curl 요청은 성공하는데 브라우저에서 접속할 수 없다면 v2rayN 트레이 메뉴의 ‘시스템 프록시’에서 ‘시스템 프록시 자동 설정’을 선택한 뒤 브라우저가 별도의 프록시 설정을 사용하는지 확인하세요. 시스템 프록시는 해당 설정을 따르는 앱에만 영향을 주며 모든 네트워크 트래픽을 가로채지는 않습니다. 문제 해결 초기에는 가상 네트워크 인터페이스, 라우팅, 권한이라는 변수를 추가하지 않도록 TUN을 동시에 켜거나 전환하지 마세요.

라우팅 규칙 확인: 로그에서 실패한 요청에 어떤 아웃바운드가 적용되었는지 확인하세요. 규칙에 따라 대상이 직접 연결로 전달되면 노드가 정상이더라도 접속에 실패할 수 있습니다.
DNS 조회 위치 구분: 원격 노드 주소는 먼저 조회되어야 합니다. SOCKS를 통해 대상 사이트의 원격 DNS 조회가 성공해도 로컬에서 노드 도메인을 정상적으로 조회한다는 뜻은 아닙니다.
IP 주소 계열 비교: 도메인 조회 결과에 IPv4와 IPv6가 모두 있다면 한쪽 주소 계열에서만 실패하는지 확인하세요. 시스템 전체에서 IPv6를 끄는 것을 첫 단계로 삼지 마세요.
테스트 대상 확인: 사용 가능 여부를 확인하는 테스트 주소 자체가 일시적으로 장애를 겪거나 요청을 제한할 수 있습니다. 접속이 가능한 HTTPS 대상 두 곳을 함께 확인하고, 단일 속도 측정값에만 의존하지 마세요.

7. 재현 기록을 정리한 뒤 노드 변경 여부 결정하기

문제 해결은 ‘재시작하니 되는 것 같다’가 아니라 반복 가능한 테스트 결과로 마무리해야 합니다. 연결이 복구되면 같은 요청을 두 번 더 테스트하고 로그에 핸드셰이크 또는 리스닝 오류가 계속 기록되지 않는지 확인하세요. 특정 노드에서만 실패하고 로컬 포트, 시스템 시간, 네트워크 교차 테스트가 모두 정상이라면 노드 서비스 제공업체에 문의하세요.

운영체제 버전, v2rayN 버전, 실제 실행 중인 코어의 이름과 버전을 기록하세요. 버전은 현재 프로그램 정보에서 확인하고 설치 파일 이름만으로 추측하지 마세요.
문제가 발생한 시각, 기존 네트워크와 핫스팟의 비교 결과, TCP 테스트와 프록시를 명시한 요청 각각의 성공 여부를 기록하세요.
같은 요청의 전후에 기록된 필요한 로그를 제공하되 구독 링크, UUID, 액세스 토큰, 개인 네트워크 정보는 숨기고 전체 설정을 공개하지 마세요.
각 변경 전후의 결과를 기록하세요. 한 번에 매개변수 하나만 변경하고, 효과가 없는 변경은 원래대로 되돌린 뒤 다음 테스트를 진행하세요.

전체 점검 순서는 시간 동기화, 코어 리스닝 확인, 원격 포트 테스트, 전송 및 인증 설정 대조, 마지막으로 앱 프록시·DNS·라우팅 확인입니다. 이 순서대로 진행하면 ‘모든 노드 시간 초과’ 문제를 범위가 분명한 원인으로 나눌 수 있고, 클라이언트를 반복해서 바꾸느라 실제 단서를 놓치는 일도 줄일 수 있습니다.