이 글은 v2rayN 또는 v2rayNG에서 노드 연결 시간이 초과되거나 프록시를 켠 뒤 웹페이지에 접속할 수 없고 지연 테스트가 모두 실패하는 경우에 적합합니다. 점검 후 로컬 네트워크 이상, 시스템 시간 오차, 만료된 구독 매개변수, 불일치하는 전송 계층 설정, 접속할 수 없는 노드 포트와 서버 장애를 구분해 설정 수정·구독 갱신·노드 교체 여부를 결정할 수 있습니다.
먼저 점검 순서를 고정하세요
연결에 실패했을 때 가장 혼란을 키우는 방법은 여러 설정을 동시에 바꾸는 것입니다. DNS를 변경하면서 구독을 다시 가져오고 전송 프로토콜까지 바꾸면, 연결이 회복되어도 실제 원인을 알 수 없습니다. 한 번에 하나의 변수만 변경하고, 변경 후 같은 노드를 다시 테스트하는 편이 안정적입니다.
전체 연결 경로는 단순히 ‘클라이언트에서 노드까지’로 끝나지 않습니다. 애플리케이션 요청은 먼저 로컬 프록시 포트로 들어간 뒤 V2Ray 또는 Xray 코어가 라우팅 규칙을 읽고 서버 도메인을 확인하며 원격 포트에 연결한 다음 프로토콜과 전송 계층 핸드셰이크를 완료합니다. 어느 한 단계라도 실패하면 화면에는 시간 초과로만 표시될 수 있습니다.
기기와 가장 가까운 지점부터 확인하는 것이 좋습니다. 먼저 일반 네트워크가 작동하는지 확인하고 시간과 로컬 프록시 포트를 점검한 뒤 노드 매개변수를 대조하고 마지막으로 서버 상태를 판단하세요. 이 순서라야 로컬 인터넷 끊김을 노드 장애로 오해하지 않고, 클라이언트를 반복해서 재설치하며 설정을 잃는 일도 줄일 수 있습니다.
프록시 일시 중지
시스템 프록시를 해제하거나 VPN 모드를 끄고 브라우저에서 자주 사용하는 웹사이트 두 곳을 열어 기기 자체의 인터넷 연결을 확인합니다.
시간 확인
시스템에서 날짜·시간·시간대 자동 설정을 켜고 한 번 수동 동기화하여 시간 오차를 60초 이내로 유지합니다.
포트 확인
로컬 SOCKS 또는 HTTP 수신 포트가 시스템 프록시와 일치하는지 확인하세요. 예를 들어 v2rayN에서 자주 사용하는 로컬 포트는 10808입니다.
단일 노드 테스트
노드 하나를 고정해 실제 연결 지연 테스트를 실행하고, 여러 노드의 일괄 결과로 단일 노드 재테스트를 대신하지 마세요.
구독 갱신
로컬 연결 경로가 정상일 때만 구독을 갱신한 뒤 기존 노드와 새 노드의 주소·포트·전송 매개변수를 비교합니다.
원격 상태 판단
같은 노드가 서로 다른 네트워크와 기기에서 계속 시간 초과될 때에만 원격 포트가 닫혔거나 서버를 사용할 수 없는지 추가로 확인합니다.
로컬 네트워크와 시스템 시간 확인
첫 단계는 프록시를 끈 상태에서 기본 네트워크를 확인하는 것입니다. 브라우저가 캐시된 페이지를 열 수 있다고 네트워크가 정상인 것은 아닙니다. 이전에 열어 보지 않은 페이지에 접속하거나 시스템 명령으로 도메인 확인을 직접 테스트하세요. Windows에서는 터미널에서 nslookup example.com을 실행하고, Linux와 macOS에서는 nslookup 또는 dig를 사용할 수 있습니다. 도메인을 확인할 수 없다면 노드 프로토콜이 아니라 현재 네트워크나 DNS부터 해결해야 합니다.
네트워크에서 원격 포트를 제한하는지도 확인해야 합니다. 가정용 네트워크라면 임시로 모바일 핫스팟으로 전환해 비교하고, 모바일 네트워크라면 고정 네트워크에서 다시 테스트하세요. 같은 노드가 네트워크 A에서는 시간 초과되고 네트워크 B에서는 연결된다면 클라이언트 설정에 근본적인 문제는 없을 가능성이 큽니다. 네트워크 출구, DNS 결과와 포트 도달 가능성을 중점적으로 확인하세요.
VMess 등의 프로토콜은 인증 과정에서 정확한 시스템 시간을 필요로 합니다. 기기 시간이 몇 분 정도 어긋나면 클라이언트가 TCP 연결까지는 완료해도 프로토콜 핸드셰이크 단계에서 실패할 수 있습니다. Windows 11 24H2에서는 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 시간 자동 설정과 시간대 자동 설정을 켠 다음 지금 동기화를 누르세요. Android 15에서는 「설정」→「시스템」→「날짜 및 시간」으로 이동해 네트워크 제공 시간 사용을 활성화합니다.
- 프록시를 꺼도 일반 웹사이트를 열 수 없음: 먼저 로컬 네트워크를 해결하고 노드 매개변수 점검은 보류하세요.
- 도메인 노드는 실패하지만 IP 노드는 연결됨: DNS 확인 결과와 네트워크 DNS를 우선 점검하세요.
- 고정 네트워크는 실패하고 모바일 핫스팟은 정상: 라우터 DNS, 접근 제어와 네트워크 출구 제한을 확인하세요.
- 모든 VMess 노드가 동시에 실패: 시스템 시간, UUID와 구독 갱신 시간을 확인하세요.
- 특정 포트만 실패: 원격 포트 상태를 확인하고 전체 설정을 바로 초기화하지 마세요.
오류:lookup server.example on 127.0.0.1:53: no such host
원인 및 해결:노드 도메인이 유효한 주소로 확인되지 않았습니다. 먼저 프록시를 끈 상태에서 도메인 확인 테스트를 실행하고 사용 가능한 DNS로 변경한 뒤 클라이언트 코어를 재시작하세요.
오류:dial tcp: i/o timeout
원인 및 해결:지정된 시간 안에 원격 주소와 포트에 연결하지 못했습니다. 다른 로컬 네트워크로 전환해 다시 테스트하고 구독에 저장된 서버 주소와 포트가 만료되지 않았는지 확인하세요.
오류:context deadline exceeded
원인 및 해결:연결 작업이 대기 시간을 초과했습니다. DNS, TCP 연결 수립 또는 전송 계층 핸드셰이크에서 발생할 수 있으므로 로그에서 이 줄과 가까운 주소·포트·단계를 함께 확인하세요. 마지막 줄만 보지 마세요.
결론: 반복 측정보다 네트워크 간 비교가 효과적입니다
같은 설정을 서로 독립된 두 네트워크에서 테스트한 결과가 지연 테스트 버튼을 열 번 연속 누른 결과보다 로컬 네트워크 제한과 노드 장애를 구분하는 데 유용합니다. 모바일 핫스팟에서 작동한다면 먼저 클라이언트 설정을 유지하고 기존 네트워크의 DNS와 포트 도달 가능성을 확인하세요.
노드와 전송 매개변수 확인
로컬 네트워크가 정상이라면 다음 단계는 노드를 하나씩 대조하는 것입니다. 프로토콜 이름이 같아도 설정을 서로 바꿔 쓸 수 있다는 뜻은 아닙니다. VMess에는 올바른 서버 주소·포트·사용자 ID·보안 설정·전송 매개변수가 필요하고, VLESS에는 사용자 ID·흐름 제어 옵션과 전송 계층 설정이 맞아야 합니다. 구독 갱신 후 서버에서 경로·호스트 이름·TLS 매개변수를 변경했다면 이전 설정이 목록에 남아 있어도 핸드셰이크를 완료하지 못할 수 있습니다.
기억에 의존해 노드를 다시 만들지 마세요. 현재 유효한 구독 또는 서버에서 제공한 설정을 기준으로 서버 주소·포트·프로토콜·전송 방식·TLS·SNI·Host·WebSocket 경로를 비교해야 합니다. 경로의 대소문자와 앞쪽 슬래시도 의미가 있으므로 /ray와 /Ray는 같은 값으로 볼 수 없습니다.
| 점검 항목 | 일반적인 증상 | 중점 확인 사항 |
|---|---|---|
| 서버 주소 | 확인 실패 또는 지속적인 시간 초과 | 도메인 철자, DNS 결과, 현재 서버를 계속 가리키는지 여부 |
| 원격 포트 | connection refused 또는 i/o timeout | 포트 번호, 서비스 수신 상태, 네트워크 출구 제한 |
| 사용자 ID | 연결 직후 빠르게 끊김 | 문자열 전체, 그룹화 위치, 이전 구독 값 사용 여부 |
| TLS 및 SNI | 핸드셰이크 실패 또는 인증서 이름 불일치 | TLS 활성화 여부, Server Name, 시스템 시간 |
| WebSocket | TCP 연결은 되지만 프록시 요청 실패 | Host, Path, 대소문자와 앞쪽 슬래시 |
| gRPC | 전송 계층 수립 실패 | serviceName, TLS 설정과 서버 설정의 일치 여부 |
v2rayN 7.x에서는 먼저 노드를 선택한 뒤 오른쪽 클릭 메뉴에서 서버를 확인하거나 편집할 수 있습니다. 코어를 확인하려면 「설정」→「매개변수 설정」→「Core 유형」으로 이동해 현재 프로토콜이 해당 코어에서 처리되는지 확인하세요. 수정 후에는 설정을 저장하고 코어를 재시작한 다음 현재 노드를 테스트해야 합니다. 창만 닫는다고 실행 중인 설정이 다시 로드되는 것은 아닙니다.
v2rayNG는 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용합니다. QR 코드나 클립보드로 가져오면 링크에 실제로 포함된 필드만 옮겨지며, 서버가 별도로 요구하는 전송 매개변수까지 자동으로 채워지지는 않습니다. 가져온 뒤 필드가 누락되었다면 다른 노드의 매개변수를 추측해 입력하지 말고 먼저 구독을 다시 갱신하세요.
오류:connection refused
원인 및 해결:대상 호스트가 해당 포트의 연결을 명확히 거부했습니다. 서비스가 수신 대기하지 않거나 포트가 변경된 경우가 흔합니다. 구독을 다시 갱신하고 원격 포트를 확인하세요. 여러 네트워크에서 같은 현상이 재현되면 서버 운영자에게 문의하세요.
오류:remote error: tls: handshake failure
원인 및 해결:TLS 협상이 완료되지 않았습니다. 시스템 시간, TLS 활성화 여부, SNI와 전송 방식을 확인하고 현재 노드 설정과 각 필드가 일치하는지 대조하세요.
오류:invalid user
원인 및 해결:서버가 현재 사용자 인증 정보를 받아들이지 않았습니다. 사용자 ID가 완전한지 확인하고 클라이언트가 구독 갱신 전의 이전 노드를 계속 사용하고 있지 않은지 점검하세요.
로컬 포트와 프록시 상태 확인
노드 자체가 정상이어도 로컬 프록시 포트가 잘못되면 웹페이지 시간 초과로 나타날 수 있습니다. 일반적인 설정에서는 v2rayN이 로컬 포트 10808을 수신 대기할 수 있으며 브라우저 확장 프로그램이나 시스템 프록시도 같은 포트를 가리켜야 합니다. 클라이언트를 10809로 바꿨는데 시스템 프록시가 여전히 10808에 연결되어 있다면 요청은 현재 코어에 들어가지 않습니다.
Windows에서는 터미널에서 netstat -ano | findstr :10808을 실행해 포트가 LISTENING 상태인지 확인하고 해당 PID를 기록하세요. Linux와 macOS에서는 lsof -nP -iTCP:10808 -sTCP:LISTEN을 실행할 수 있습니다. 포트가 수신 대기하지 않으면 코어가 시작되었는지 확인하세요. 다른 프로그램이 사용 중이라면 충돌 프로세스를 종료하거나 클라이언트의 수신 포트를 변경한 뒤 시스템 프록시도 함께 업데이트합니다.
Windows:
netstat -ano | findstr :10808
tasklist | findstr 4321
Linux / macOS:
lsof -nP -iTCP:10808 -sTCP:LISTEN
로컬 SOCKS 테스트:
curl --proxy socks5h://127.0.0.1:10808 https://example.com/socks5h의 h는 도메인 확인을 프록시 측에서 처리한다는 뜻입니다. 일반 브라우저는 실패하지만 위 명령으로 페이지 내용이 반환된다면 노드보다 브라우저 프록시 방식, 시스템 프록시 주소 또는 확장 프로그램 규칙을 우선 확인하세요. 명령도 시간 초과되면 클라이언트 로그에 해당 요청 기록이 생성되었는지 확인합니다.
수신 대기 확인
127.0.0.1:10808을 현재 클라이언트 프로세스가 수신 대기하는지 확인하고 프로세스 ID를 비교용으로 기록하세요.
포트 통일
클라이언트·시스템 프록시·브라우저 설정에서 동일한 포트를 사용해 10808과 10809를 혼용하지 마세요.
코어 재시작
매개변수를 저장한 뒤 코어를 재시작해 수신 포트와 라우팅 설정을 다시 불러옵니다.
요청 보내기
curl로 로컬 SOCKS 포트에 요청을 보내면서 로그에 새 연결 기록이 나타나는지 확인하세요.
실제 연결 지연으로 장애 구분
기본 연결성 테스트와 실제 연결 지연은 같은 것이 아닙니다. TCP 포트만 테스트하면 대상 포트에 연결할 수 있다는 사실만 확인할 수 있고 VMess·VLESS·TLS·WebSocket 또는 gRPC 핸드셰이크 성공 여부는 알 수 없습니다. 실제 연결 지연 테스트는 현재 프록시 경로를 통해 실제 요청을 보내므로 노드가 완전한 아웃바운드 연결을 제공하는지 판단하는 데 더 적합합니다.
v2rayN에서 노드 하나를 선택하고 오른쪽 클릭 메뉴의 「서버 실제 연결 지연 테스트」를 사용하세요. 테스트 전에 해당 노드 설정이 저장되었고 시스템 시간이 정상인지 확인해야 합니다. 세 번 연속 테스트하면 기본적인 판단이 가능합니다. 한 번 성공하고 두 번 실패했다면 경로 불안정일 수 있으며, 세 번 모두 10초 대기 후 시간 초과되었다면 다른 노드와 네트워크를 함께 비교해야 합니다.
지연 시간 숫자만으로 노드를 정렬하지 마세요. 180밀리초가 표시되더라도 세 번 연속 성공하는 노드가, 60밀리초가 가끔 표시된 뒤 두 번 시간 초과되는 노드보다 일반적으로 안정적입니다. 지연 테스트 중에는 대용량 파일 전송, 시스템 업데이트와 클라우드 드라이브 동기화를 일시 중지해 로컬 대역폭 포화로 인한 오판을 피하세요.
| 테스트 결과 | 초기 판단 | 다음 단계 |
|---|---|---|
| 단일 노드는 성공하지만 브라우저는 실패 | 노드 연결 경로는 기본적으로 사용 가능 | 시스템 프록시, 브라우저 프록시와 라우팅 규칙 확인 |
| 모든 노드가 동시에 시간 초과 | 로컬 네트워크·DNS·시간 문제 또는 구독 전체 만료 가능성 | 프록시를 끄고 네트워크를 확인한 다음 구독 갱신 |
| 노드 하나만 시간 초과 | 해당 노드의 매개변수 또는 서버 이상 | 같은 구독의 다른 노드와 비교하고 네트워크를 바꿔 재테스트 |
| TCP 연결은 되지만 실제 연결 시간 초과 | 프로토콜 또는 전송 계층 핸드셰이크 실패 | 사용자 ID, TLS, SNI, Host와 Path 대조 |
| 실제 연결은 성공하지만 속도가 비정상 | 경로 혼잡 또는 라우팅 품질 변동 | 시간대를 달리해 재테스트하고 다른 노드와 비교 |
결론: 성공률로 안정성 판단
같은 고정 네트워크에서 세 번 연속 실제 연결을 테스트하는 것이 한 번의 최저 지연보다 참고 가치가 높습니다. 세 번 모두 성공하고 로그에 재시도가 없다면 전체 프록시 경로가 구축된 것입니다. 같은 단계에서 계속 시간 초과될 때 해당 단계에 맞춰 처리하세요.
구독 갱신과 노드 교체 중 무엇을 선택할까
로컬 네트워크·시스템 시간·로컬 포트·클라이언트 프록시 상태가 모두 정상이면 구독을 갱신할 수 있습니다. v2rayN에서 먼저 「구독 그룹」에 저장된 주소가 현재 주소인지 확인한 다음 모든 구독 갱신을 실행하세요. 갱신이 끝나도 이전 그룹을 바로 삭제하지 말고, 같은 이름의 노드에서 서버 주소·포트·프로토콜·전송 매개변수가 바뀌었는지 비교하세요.
Android 클라이언트에서도 먼저 현재 구독을 갱신한 뒤 새로 생성된 노드 항목을 테스트해야 합니다. 수동으로 가져온 단일 노드는 구독 측 변경 사항을 자동으로 반영하지 않습니다. 서버에서 포트나 전송 경로를 변경했다면 이전 QR 코드와 링크에는 기존 값이 그대로 남습니다. 이때 이전 내용을 다시 스캔하는 것은 의미가 없으므로 현재 유효한 설정을 받아야 합니다.
- 갱신 후 새 노드가 추가되고 연결 가능함: 새 항목을 사용하고 만료된 이전 사본을 삭제하세요.
- 갱신에는 성공했지만 목록이 전혀 바뀌지 않음: 구독 갱신 시간과 그룹 주소가 올바른지 확인하세요.
- 구독 요청 자체가 시간 초과됨: 먼저 프록시를 끄고 직접 연결해 갱신한 다음 서비스 제공자가 요구하는 방식에 따라 프록시를 통한 갱신 여부를 결정하세요.
- 같은 구독에서 노드 하나만 실패함: 다른 사용 가능한 노드는 유지하고 장애 노드 정보만 따로 기록하세요.
- 모든 노드가 기기와 네트워크를 바꿔도 계속 실패함: 구독 만료 또는 원격 전체 점검일 수 있으므로 클라이언트 설정을 반복해서 수정하지 마세요.
노드 교체는 한 번의 우발적인 시간 초과가 아니라 재현 가능한 결과를 근거로 결정해야 합니다. 테스트 날짜·기기·네트워크·클라이언트·노드 이름·세 번의 실제 연결 결과·로그 오류를 간단히 기록해 두세요. 같은 노드가 Windows, Android와 두 종류의 네트워크에서 모두 연결을 완료하지 못하는데 같은 구독의 다른 노드는 정상이라면 단일 노드 장애라고 판단하기에 충분합니다.
클라이언트 재설치는 프로그램 파일 누락, 실행 불가, 설정 데이터베이스 손상과 같은 로컬 문제에만 적합합니다. 노드 시간 초과는 대개 네트워크·매개변수·원격 연결 경로에서 발생하므로 재설치해도 서버 주소·포트·시스템 시간·네트워크 제한은 바뀌지 않습니다. 점검 전에 기존 설정을 내보내거나 구독 그룹을 기록해 두면 재설치로 새로운 변수가 생기는 일을 막을 수 있습니다.
오류:failed to update subscription
원인 및 해결:클라이언트가 구독 내용을 정상적으로 가져오지 못했습니다. 구독 주소가 완전한지 확인하고 프록시를 끈 상태와 사용 가능한 노드를 켠 상태에서 각각 갱신을 시도한 뒤 응답 상태를 확인하세요.
오류:unexpected EOF
원인 및 해결:전체 응답을 읽기 전에 연결이 종료되었습니다. 경로 불안정, 전송 계층 불일치 또는 원격 측의 능동적인 연결 종료가 원인일 수 있습니다. 네트워크를 바꿔 다시 테스트하고 TLS와 전송 매개변수를 대조하세요.
재현 가능한 점검 기록 만들기
점검 기록에는 복잡한 도구가 필요하지 않지만 재현 가능해야 합니다. 최소한 운영체제 버전, 클라이언트 이름, 테스트 시간, 네트워크 유형, 노드 프로토콜, 로컬 포트와 오류 원문을 적으세요. 예를 들어 “Windows 11 24H2, v2rayN 7.x, 고정 네트워크, VMess, 127.0.0.1:10808, 실제 연결 테스트 세 번 모두 10초 후 시간 초과”라고 쓰는 편이 “노드를 사용할 수 없음”보다 진단에 훨씬 유용합니다.
로그를 공유할 때는 서버 주소, 사용자 ID, 구독 주소와 인증 정보를 가리고 오류 유형·시간·연결 단계만 남기세요. 로그의 첫 번째 이상 징후가 마지막의 “작업 실패”보다 원인에 가까운 경우가 많습니다. 한 번의 테스트가 시작된 지점부터 아래로 읽으며 DNS·연결·TLS·프로토콜 핸드셰이크에서 가장 먼저 발생한 오류를 찾으세요.
환경 기록
시스템 버전, 클라이언트, 네트워크 유형, 로컬 수신 포트와 테스트 시간을 적습니다.
노드 고정
노드 하나를 선택해 서버·프로토콜·포트·전송 방식을 저장하고 테스트 중간에 바꾸지 않습니다.
세 번 실행
실제 연결 테스트를 연속 세 번 완료하고 성공·시간 초과 또는 구체적인 오류를 기록하세요. 지연 시간 숫자만 옮겨 적지 마세요.
네트워크 전환
다른 독립 네트워크에서 같은 테스트를 반복하되 클라이언트 설정은 그대로 유지합니다.
결론 도출
차이를 바탕으로 로컬 네트워크·클라이언트 설정·노드 매개변수·서버 문제로 분류한 뒤 한 항목씩 수정합니다.