V2Ray 노드 시간 초과로 연결되지 않을 때: 네트워크·구독·설정을 순서대로 점검

이 글 한눈에 보기

노드 지연 테스트가 시간 초과되거나, 시작 후 웹페이지가 열리지 않거나, 구독 업데이트에 실패하거나, 로그에 timeout이 계속 표시될 때 유용한 안내입니다. 로컬 네트워크부터 시작해 시스템 시간, DNS, 구독 상태, 서버 주소와 포트, VMess 또는 VLESS 매개변수, 전송 계층 설정, 로컬 프록시 포트를 차례로 확인하여 연결 실패 원인을 검증 가능한 단계로 좁혀 갑니다.

먼저 시간 초과가 발생한 계층을 확인하세요

“노드 시간 초과”는 하나의 고장만을 의미하지 않습니다. 지연 테스트 실패는 테스트 대상이 응답하지 않았을 뿐일 수 있고, 코어 로그의 시간 초과는 대개 도메인 확인, TCP 연결 또는 TLS 핸드셰이크가 제한 시간 안에 완료되지 않았다는 뜻입니다. 노드가 연결된 것으로 표시되지만 웹페이지가 열리지 않는다면 시스템 프록시, 라우팅 규칙 또는 로컬 DNS가 트래픽을 제대로 처리하지 못하는 경우가 많습니다. 먼저 현상을 구분해야 이후 점검이 서로 방해되지 않습니다.

문제를 점검할 때는 테스트할 노드를 하나만 남기고, 시스템 프록시나 네트워크 필터링 규칙을 동시에 변경하는 다른 프로그램은 잠시 종료하세요. 열 개가 넘는 노드를 연속으로 바꾸면 매번 로그, DNS 캐시와 연결 상태가 달라집니다. 하나의 노드로 한 차례 테스트를 끝내야 문제가 노드 설정 오류인지, 모든 노드에 영향을 주는 로컬 네트워크 문제인지 판단할 수 있습니다.

5분

권장되는 시스템 시간 오차 상한

80 / 443

자주 사용하는 웹 전송 포트

10808

v2rayN에서 자주 사용하는 로컬 프록시 포트

3단계

네트워크·노드·클라이언트를 차례로 점검

지연 테스트 시간 초과: 먼저 코어 로그를 열고 실제로 웹페이지에 접속해 보세요. 테스트 결과만 보고 노드를 삭제하지 마세요.
시작 직후 오류 발생: 노드 필드, 포트 형식, 코어 유형 및 로컬 포트 사용 여부를 우선 확인하세요.
몇 초 후 시간 초과: DNS, 서버 포트 연결 가능 여부, TLS 및 전송 설정을 중점적으로 확인하세요.
연결됨으로 표시되지만 트래픽이 없음: 시스템 프록시, VPN 처리 상태, 라우팅 규칙 및 DNS 분할을 확인하세요.

1단계: 로컬 네트워크·시간·DNS 확인

먼저 클라이언트의 프록시 모드를 종료하고 현재 네트워크에서 자주 사용하는 웹사이트에 정상적으로 접속되는지 확인하세요. 직접 연결 자체가 불안정하면 V2Ray, Xray 또는 V2Fly 코어가 아웃바운드 연결을 설정할 때도 시간 초과가 발생합니다. 데스크톱에서는 유선, 무선 또는 모바일 핫스팟을 각각 테스트할 수 있고, Android에서는 무선 네트워크와 모바일 네트워크를 한 번씩 전환해 보세요. 특정 네트워크에서만 실패한다면 문제는 대개 구독이 아니라 라우터, DNS 또는 해당 네트워크의 포트 정책에 있습니다.

시스템 시간도 정확해야 합니다. VMess 인증 정보는 시간과 관련이 있으며 TLS 인증서 검증 역시 올바른 날짜와 시간대에 의존합니다. 시간이 몇 분만 어긋나도 인증 실패, 핸드셰이크 오류 또는 겉보기에는 일반적인 연결 시간 초과가 발생할 수 있습니다. Windows, macOS, Android 및 Linux에서 날짜·시간·시간대 자동 설정을 켜고, 동기화가 끝난 뒤 클라이언트를 완전히 종료했다가 코어를 다시 시작하세요.

직접 연결 확인
먼저 클라이언트 연결을 끊고 시스템 프록시를 끈 다음 브라우저에서 자주 사용하는 웹사이트 두 곳을 열어 보세요. 페이지도 자주 로딩 상태에서 멈춘다면 노드를 계속 수정하지 말고 로컬 네트워크부터 해결하세요.
시간 동기화
시스템 날짜 및 시간 설정에서 자동 동기화를 켜고 날짜, 시간대 및 현재 분이 정확한지 확인하세요. 동기화가 끝나면 v2rayN, v2rayNG 또는 v2flyNG를 다시 시작하세요.
도메인 확인
데스크톱 터미널에서 도메인 조회 명령을 실행하여 노드 도메인이 IP 주소를 반환하는지 확인하세요. 계속 시간 초과가 발생하면 먼저 시스템 DNS를 변경한 뒤 DNS 캐시를 삭제하세요.
포트 테스트
Windows에서는 PowerShell의 Test-NetConnection으로 서버 포트를 확인하고, macOS와 Linux에서는 nc로 TCP 연결 테스트를 진행할 수 있습니다. 포트에 연결할 수 있어야 코어가 프로토콜 핸드셰이크를 계속 진행할 수 있습니다.
네트워크 변경
신뢰할 수 있는 다른 네트워크에서 같은 노드를 다시 테스트하세요. 새 네트워크에서 연결된다면 클라이언트 설정은 유지하고 원래 네트워크의 라우터, DNS 및 방화벽 규칙을 점검하세요.

nslookup server.example
Test-NetConnection server.example -Port 443
nc -vz server.example 443

명령어의 도메인과 포트는 노드의 실제 값으로 바꿔야 합니다. 도메인 조회 성공은 DNS 결과가 있다는 뜻일 뿐 포트가 열려 있다는 의미는 아닙니다. TCP 테스트 성공 역시 기본 연결을 수립할 수 있다는 뜻일 뿐 UUID, TLS, WebSocket 경로 등 애플리케이션 계층 매개변수가 올바르다는 보장은 없습니다. 두 항목이 모두 성공했는데도 시간 초과가 발생할 때 프로토콜 설정을 점검하세요.

오류: failed to find an available destination

원인과 해결 방법: 아웃바운드 서버 주소를 확인할 수 없거나 사용 가능한 대상이 없습니다. 도메인 철자를 확인하고 시스템 DNS를 변경한 뒤 캐시를 삭제하고 코어를 다시 시작하세요.

오류: dial tcp: lookup server.example: i/o timeout

원인과 해결 방법: 제한 시간 안에 DNS 조회 결과가 반환되지 않았습니다. 먼저 직접 연결 네트워크를 테스트한 다음 로컬 DNS, 라우터의 상위 DNS 및 클라이언트 DNS 설정을 확인하세요.

오류: context deadline exceeded

원인과 해결 방법: 연결 또는 핸드셰이크가 대기 시간을 초과했습니다. 시스템 시간이 정확한지 확인하고 대상 도메인 확인과 포트 연결 가능 여부를 각각 검증하세요.

2단계: 구독·노드 주소·포트 확인

로컬 네트워크가 정상이라면 구독이 아직 유효한지 확인하세요. 구독 업데이트 성공은 모든 노드를 사용할 수 있다는 뜻이 아니라 클라이언트가 구독 내용을 가져와 해석했다는 의미입니다. 반대로 구독 업데이트 실패가 기존 노드의 즉시 만료를 뜻하지도 않습니다. 구독 서버에 일시적으로 연결할 수 없었을 수 있습니다. 점검할 때는 “노드 목록 가져오기”와 “특정 노드 연결”을 별개의 작업으로 구분하세요.

먼저 구독 그룹에서 한 번 업데이트를 실행하고 노드 수, 이름 및 업데이트 시간이 바뀌었는지 확인하세요. 업데이트 후 노드가 갑자기 0개가 되었다면 빈 결과로 기존 목록을 덮어쓰지 마세요. 구독 주소가 완전히 복사되었는지, 유효 기간이 끝났는지, 링크의 쿼리 매개변수가 복사 과정에서 잘리지 않았는지 확인하세요. 구독 주소는 민감한 설정이므로 공개 로그나 공개 페이지에 붙여 넣지 마세요.

점검 항목	정상적인 상태	이상 발생 시 조치
구독 업데이트 시간	업데이트 완료 후 현재 시간이 표시됨	구독 주소 전체를 다시 복사하고 네트워크와 구독 유효 기간을 확인
서버 주소	도메인 철자가 완전하며 프로토콜 접두사나 공백이 없음	구독 원본 기록과 한 글자씩 대조하고 도메인을 임의로 수정하지 않음
서버 포트	1~65535 범위이며 서버 측 설정과 일치	불필요한 공백을 삭제하고 로컬 포트를 서버 포트에 입력하지 않았는지 확인
노드 프로토콜	VMess 또는 VLESS 유형이 원본 설정과 일치	프로토콜 이름만 바꾸지 말고 노드 매개변수 전체를 다시 가져오기
TLS 표시	활성화 상태와 서버 이름이 노드 설명과 일치	SNI, 전송 계층 보안 설정 및 대상 도메인 확인

포트는 가장 자주 잘못 입력되는 항목입니다. 서버 포트는 원격 서버가 수신하는 포트로 443이 그 예입니다. 로컬 프록시 포트는 클라이언트가 현재 기기에서 수신하는 포트이며 v2rayN에서는 10808을 자주 사용합니다. 두 포트의 용도는 완전히 다릅니다. 노드의 서버 포트에 10808을 입력하면 지속적인 시간 초과나 connection refused가 발생하는 경우가 많습니다.

같은 구독의 모든 노드에서 시간 초과 발생: 구독 상태, 로컬 네트워크, DNS 및 클라이언트 코어를 우선 확인하세요.
특정 노드 하나에서만 시간 초과 발생: 해당 노드의 주소, 포트, 프로토콜 매개변수 및 서버 상태를 우선 확인하세요.
구독 업데이트는 시간 초과되지만 기존 노드는 사용 가능: 구독 가져오기 방식을 확인하고, 연결이 수립된 뒤 클라이언트 옵션에서 프록시를 통한 업데이트를 시도하세요.
업데이트 후 새 노드는 사용할 수 없고 기존 노드는 사용 가능: 새 노드와 기존 노드의 TLS, 전송 방식, 서버 이름 및 경로 필드를 비교하세요.

오류: dial tcp server.example:443: i/o timeout

원인과 해결 방법: 클라이언트가 대기 시간 안에 원격 443 포트에 연결하지 못했습니다. 포트 테스트 명령으로 다시 확인하고 네트워크를 바꿔 로컬 외부 연결 제한을 배제하세요.

오류: connect: connection refused

원인과 해결 방법: 원격 호스트가 연결을 명시적으로 거부했습니다. 포트가 잘못되었거나 서비스가 해당 포트에서 수신 대기하지 않는 경우가 흔합니다. 구독에서 다시 가져오고 포트를 추측해 바꾸지 마세요.

3단계: VMess·VLESS 및 전송 매개변수 항목별 확인

노드 주소와 포트에 연결할 수 있다면 시간 초과는 대개 프로토콜 핸드셰이크나 전송 계층에서 발생합니다. VMess와 VLESS는 모두 클라이언트 필드와 서버 설정이 정확히 일치해야 하지만 인증 방식과 사용할 수 있는 필드는 다릅니다. 프로토콜 유형은 이름을 바꿔 서로 변환할 수 없습니다. 구독에 VLESS가 지정되어 있다면 VLESS를 유지하고 사용자 식별자, 암호화 옵션, 흐름 제어 및 전송 매개변수를 원본 설정과 대조하세요.

매개변수를 확인할 때는 기억에 의존해 수동으로 채우기보다 구독에서 다시 가져오는 것이 좋습니다. 수동 설정에서 자주 빠지는 항목은 TLS 서버 이름, WebSocket 경로, HTTP Host, gRPC serviceName, Reality 공개 키 및 shortId입니다. 필드 하나만 일치하지 않아도 TCP 연결 후 핸드셰이크 단계에서 멈출 수 있습니다.

프로토콜 확인
노드 편집 페이지를 열어 유형이 VMess인지 VLESS인지 확인하세요. 프로토콜 드롭다운만 수정하지 마세요. 유형이 맞지 않으면 해당 복사본을 삭제하고 전체 구독에서 다시 가져와야 합니다.
사용자 식별자 확인
UUID를 한 글자씩 대조하고 앞뒤 문자와 하이픈을 주의해서 확인하세요. 복사할 때 공백이나 줄바꿈이 포함되지 않도록 하며, VMess는 구독에 지정된 추가 매개변수도 유지해야 합니다.
전송 계층 일치 확인
TCP, WebSocket, gRPC 등 전송 방식이 원본 설정과 일치하는지 확인하세요. WebSocket은 경로와 Host를, gRPC는 serviceName을 중점적으로 확인해야 합니다.
보안 계층 확인
TLS 또는 Reality의 활성화 상태를 확인하세요. TLS는 서버 이름을, Reality는 공개 키, shortId 및 지문 옵션을 추가로 대조해야 합니다.
라우팅 원상 복구
일시적으로 클라이언트 기본 라우팅 규칙을 사용해 다시 테스트하세요. 기본 규칙에서는 작동하지만 사용자 지정 규칙에서 실패한다면 도메인 규칙, IP 규칙 및 아웃바운드 태그 참조를 점검하세요.

오류: invalid user

원인과 해결 방법: 서버가 현재 사용자 정보를 인식하지 못했습니다. 노드를 다시 가져오고 UUID, 프로토콜 유형 및 계정 유효 기간을 확인하세요. 인증 필드를 수동으로 수정하지 마세요.

오류: remote error: tls: handshake failure

원인과 해결 방법: TLS 핸드셰이크 매개변수가 일치하지 않습니다. 시스템 시간, 서버 이름, 대상 도메인 및 노드가 요구하는 보안 설정을 확인하세요.

오류: websocket: bad handshake

원인과 해결 방법: 원격 서버가 WebSocket 요청을 예상한 방식으로 수락하지 않았습니다. 경로, Host, TLS 상태 및 서버 포트가 구독 내용과 완전히 일치하는지 확인하세요.

오류: failed to dial to serviceName

원인과 해결 방법: gRPC 서비스 이름 또는 대상 설정이 일치하지 않습니다. 구독 원문을 기준으로 serviceName을 확인하고 WebSocket 경로 필드를 잘못 함께 사용하지 않았는지 점검하세요.

라우팅 분할도 노드 장애와 비슷한 현상을 만들 수 있습니다. 예를 들어 사용자 지정 규칙이 대상 도메인을 존재하지 않는 아웃바운드 태그로 보내거나, DNS 조회는 직접 연결로 처리하면서 대상 연결은 프록시로 보내면 일부 웹사이트가 계속 로딩될 수 있습니다. 가장 효과적인 확인 방법은 잠시 기본 라우팅으로 돌아가 같은 웹사이트를 테스트하는 것입니다. 기본 규칙이 성공하면 도메인, IP 및 규칙 세트를 그룹별로 다시 적용하세요.

4단계: 클라이언트 코어·로그·로컬 프록시 확인

설정 필드가 모두 올바르다면 클라이언트 실행 계층을 계속 확인하세요. v2rayN은 주로 Windows 데스크톱 환경에서 사용되며, 일반적인 버전의 인터페이스에서는 「설정」→「매개변수 설정」에서 로컬 포트와 Core 유형을 확인할 수 있습니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 노드를 가져온 뒤에는 클라이언트가 프로토콜에 맞는 호환 코어를 선택하도록 하고, 차이를 잘 모르는 상태에서 Core 유형을 강제로 변경하지 마세요.

v2rayN 7.x의 일반적인 설정을 예로 들면 로컬 mixed 또는 SOCKS 수신 포트로 10808을 사용할 수 있으며 HTTP 포트는 설정에 따라 인접한 포트로 배정될 수 있습니다. 구체적인 값은 「설정」→「매개변수 설정」에 현재 표시되는 값을 기준으로 하세요. 브라우저나 시스템 프록시가 여전히 이전 포트를 가리키고 있다면 코어가 연결에 성공했더라도 웹페이지 트래픽은 현재 클라이언트를 통과하지 않습니다.

7.x

이 글에서 다루는 v2rayN의 주요 인터페이스 세대

127.0.0.1

자주 사용하는 로컬 프록시 수신 주소

10808

중점적으로 확인할 일반적인 로컬 포트

v2rayN: 「설정」→「매개변수 설정」으로 이동해 로컬 수신 포트를 확인한 다음 시스템 프록시가 같은 포트를 가리키는지 점검하세요.
v2rayNG: 「설정」→「매개변수 설정」으로 이동해 로컬 프록시 포트, 도메인 전략 및 DNS 옵션을 확인하세요. 변경 후에는 먼저 연결을 중지한 다음 다시 시작하세요.
v2flyNG: 구독 업데이트 후 현재 선택된 노드가 여전히 유효한지 확인하고 실행 로그를 통해 실패가 주소 확인, 연결 수립 또는 프로토콜 핸드셰이크 중 어디에서 발생했는지 판단하세요.
Windows: 로그에 address already in use가 표시되면 같은 포트를 사용하는 프로그램을 종료하거나 매개변수 설정에서 사용 중이지 않은 포트로 변경하세요.
macOS 및 Linux: 시스템 네트워크 설정이나 터미널에서 프록시 주소, 포트 및 환경 변수를 확인하여 이전 프록시 값이 계속 적용되지 않도록 하세요.

Windows:
netstat -ano | findstr 10808

macOS / Linux:
lsof -i :10808

로그 수준은 연결 오류를 확인할 수 있는 정도로 유지하면 됩니다. 마지막에 반복되는 시간 초과보다 첫 번째 오류를 중점적으로 읽으세요. 첫 오류에는 대개 대상 도메인, 포트 및 실패 단계가 포함되어 있고, 이후 여러 오류는 브라우저 리소스 요청으로 인한 연쇄 결과일 수 있습니다. 한 차례 테스트를 마친 뒤 로그를 지우고 웹페이지 하나만 열면 내용을 더 쉽게 판단할 수 있습니다.

오류: bind: address already in use

원인과 해결 방법: 로컬 수신 포트가 다른 프로세스에서 사용 중입니다. 현재 포트(예: 10808)를 점유한 프로세스를 확인하고 충돌하는 프로그램을 종료하거나 클라이언트 수신 포트를 변경하세요.

오류: proxy connection ended unexpectedly

원인과 해결 방법: 로컬 프록시 연결이 예기치 않게 조기에 종료되었습니다. 코어가 계속 실행 중인지, 시스템 프록시 포트가 일치하는지 확인하고 바로 앞 로그에서 실제 원인을 찾으세요.

오류: no route for domain

원인과 해결 방법: 사용자 지정 라우팅에 대상에 적용할 수 있는 아웃바운드가 없습니다. 기본 라우팅으로 복구해 다시 테스트한 뒤 규칙에 연결된 아웃바운드 태그를 확인하세요.

자주 묻는 질문과 고정 점검 순서

앞선 점검 항목이 많다면 처리 순서를 한 문장으로 줄일 수 있습니다. 먼저 직접 연결을 확인하고, 시간과 DNS를 점검한 다음 구독과 포트를 확인하세요. 이후 프로토콜과 전송 매개변수를 점검하고 마지막으로 로컬 프록시와 라우팅을 확인합니다. 각 단계에는 “도메인은 확인되지만 443 포트에 연결할 수 없음”처럼 명확한 결론을 남겨야 하며, “여전히 안 됨”처럼 막연하게 기록해서는 안 됩니다.

속도 테스트는 시간 초과지만 웹페이지는 열립니다. 처리해야 하나요?

실제 연결 결과를 우선 기준으로 삼으세요. 일부 지연 테스트 대상은 연결할 수 없거나 테스트 방식이 실제 트래픽과 다를 수 있습니다. 실행 로그를 열고 웹사이트 두 곳에 접속했을 때 연결이 안정적이고 연속 오류가 없다면 속도 테스트 시간 초과만으로 설정을 다시 만들 필요는 없습니다.

구독 업데이트가 계속 시간 초과되면 어떻게 해야 하나요?

먼저 구독 주소가 완전히 복사되었고 아직 유효한지 확인하세요. 기존 노드에 연결할 수 있다면 구독 설정에서 프록시를 통한 업데이트를 선택한 후 다시 시도하세요. 모든 노드를 사용할 수 없다면 먼저 직접 연결 네트워크에서 구독 주소에 접속할 수 있는지 확인하세요.

모바일 네트워크로 바꾸면 연결됩니다. 무엇을 의미하나요?

대개 노드 설정은 기본적으로 사용할 수 있고 문제는 원래 네트워크의 DNS, 라우터, 방화벽 또는 포트 정책에 집중되어 있다는 뜻입니다. 현재 노드는 유지한 채 원래 네트워크에서 도메인 확인과 서버 포트를 각각 테스트하세요.

노드는 연결됨으로 표시되는데 브라우저에서 웹페이지가 열리지 않아요.

시스템 프록시가 켜져 있는지 확인하고 프록시 주소가 127.0.0.1인지, 포트가 클라이언트 매개변수 설정과 일치하는지 확인하세요. 그런 다음 기본 라우팅으로 복구하여 사용자 지정 분할 규칙이 트래픽을 잘못된 아웃바운드로 보냈는지 확인하세요.

여러 노드가 갑자기 동시에 시간 초과됩니다. 무엇부터 바꿔야 하나요?

노드를 하나씩 편집하지 마세요. 먼저 직접 연결 네트워크, 시스템 시간 및 DNS를 확인한 다음 구독을 한 번 업데이트하고 코어를 다시 시작하세요. 여러 노드가 동시에 실패한다면 개별 노드 매개변수보다 로컬 환경이나 구독 상태를 먼저 점검하는 것이 좋습니다.

점검을 마친 뒤에는 최종적으로 유효한 설정을 보관하고 테스트 중 임시로 추가한 중복 노드, 이전 프록시 포트 및 지나치게 넓은 라우팅 규칙을 제거하세요. 이후 다시 시간 초과가 발생하면 네트워크, 시간, 구독 업데이트 시각 및 첫 번째 로그 오류를 바로 비교할 수 있어 더 적은 단계로 변경 지점을 찾을 수 있습니다.