v2rayN에서 노드 연결이 시간 초과되거나 브라우저에서 웹페이지가 열리지 않는 경우, 또는 Android 클라이언트를 실행해도 접속할 수 없는 경우에 유용합니다. 네트워크 경로를 7단계로 나눠 각 단계에서 한 가지 조건만 바꾸고, 포트 테스트와 프록시 지정 요청, 로그를 이용해 로컬 설정·서버 연결·프로토콜 설정 문제를 구분합니다. 모든 문제를 ‘노드 장애’로 단정하지 마세요.
1단계: 로컬 네트워크와 테스트 결과 확인
먼저 클라이언트를 종료하거나 프록시 연결을 해제한 뒤, 평소에 직접 접속할 수 있는 웹사이트를 열어 보세요. Windows에서는 v2rayN 트레이 메뉴에서 「시스템 프록시」→「시스템 프록시 해제」를 선택합니다. TUN을 사용 중이라면 TUN도 꺼야 합니다. 시스템 프록시만 해제해도 가상 네트워크 어댑터의 트래픽 처리는 계속될 수 있습니다. Android에서는 v2rayNG 또는 v2flyNG 연결을 먼저 중지한 다음 Wi-Fi나 모바일 데이터 연결을 확인하세요.
노드 목록에 표시되는 지연 시간은 모두 같은 기준으로 측정되지 않습니다. TCP 테스트는 주로 서버 포트에 연결할 수 있는지 확인하고, 실제 지연 시간 테스트에는 프록시 프로토콜과 테스트 URL, 원격 서버의 응답도 영향을 줍니다. TCP 테스트에 값이 나와도 인증 성공을 의미하지 않으며, 테스트 URL이 시간 초과되어도 서버가 반드시 오프라인인 것은 아닙니다. 클라이언트에 연결이 시작된 것으로 표시되는 것은 대개 로컬 서비스나 VPN 인터페이스가 만들어졌다는 뜻입니다.
- 직접 연결도 실패하는 경우: 무선 네트워크와 라우터, 네트워크 로그인 페이지부터 확인하세요. 노드 설정은 아직 변경하지 마세요.
- 같은 노드가 다른 네트워크에서는 작동하는 경우: 사용이 허가된 다른 네트워크에서 다시 테스트하고, 기존 네트워크와 서버 간 연결 상태를 중점적으로 확인하세요.
- 특정 웹사이트 하나만 열리지 않는 경우: 테스트 대상을 두 곳 더 바꿔 해당 사이트 자체의 장애인지, 특정 라우팅 규칙의 문제인지 확인하세요.
- 모든 노드가 동시에 실패하는 경우: 우선 로컬 프록시 연결 지점과 시스템 시간, 코어 실행 상태를 확인하세요. 여러 노드가 같은 서버를 공유할 수도 있으므로 노드 개수만으로 원인을 단정할 수 없습니다.
2단계: 시스템 시간 동기화로 인증서 및 인증 오류 확인
시스템 시계가 정확하지 않으면 인증서 유효 기간을 잘못 판단하거나 일부 프로토콜의 인증에 문제가 생길 수 있습니다. 표시되는 시간대가 다르다고 해서 반드시 문제가 있는 것은 아닙니다. 기기에 설정된 실제 시간이 정확한지가 중요합니다. 시계를 몇 분 앞당기는 것은 해결 방법이 아닙니다.
-
시간 설정 열기
Windows 11에서 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 「시간 자동 설정」을 켭니다. 「추가 설정」에서 「지금 동기화」를 클릭하세요.
-
동기화 결과 확인
연월일과 현재 시간이 맞는지 확인하고 동기화가 성공했는지 살펴보세요. 동기화에 실패하면 먼저 직접 연결로 전환한 뒤 다시 시도하세요. 계속 동기화되지 않는다면 Windows 시간 서비스나 기기 관리 정책을 확인해야 합니다.
-
재시작 후 다시 테스트
Android에서는 시스템의 「날짜 및 시간」 설정에서 네트워크 제공 시간 사용을 켜세요. 메뉴 경로는 시스템마다 다를 수 있습니다. 설정을 마친 뒤 클라이언트 연결을 중지했다가 다시 시작하고, 같은 노드와 URL로 테스트하세요.
오류: x509: certificate has expired or is not yet valid
가능한 원인: 기기의 시간이 정확하지 않거나 서버 인증서의 유효 기간이 만료되었거나 아직 시작되지 않았습니다.
해결 방법: 먼저 시간을 동기화하세요. 시간이 정확한데도 오류가 계속되면 서비스 제공자에게 인증서를 확인해 달라고 요청하세요. 인증서 검증을 끄는 방식으로 문제를 우회하지 마세요.
3단계: 시스템 프록시, TUN, 로컬 수신 포트 확인
시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 영향을 줍니다. TUN은 가상 네트워크 어댑터로 트래픽을 처리하며 권한과 라우팅, DNS 설정의 영향도 받습니다. 문제를 확인할 때는 먼저 TUN을 끄고 로컬 프록시 연결 지점 하나만 테스트하는 것이 좋습니다. 연결에 성공한 뒤 원래 사용하던 트래픽 처리 모드를 다시 설정하세요. 이렇게 하면 ‘코어가 외부로 연결되지 않는 문제’와 ‘앱 요청이 프록시로 전달되지 않는 문제’를 구분할 수 있습니다.
v2rayN 7.x의 일반적인 화면을 기준으로 「설정」→「매개변수 설정」에서 로컬 수신 설정을 확인한 뒤, 트레이 메뉴의 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택해 시스템 프록시를 켭니다. 버전에 따라 메뉴 그룹 이름이 달라질 수 있으므로 현재 화면에 표시된 포트와 연결 유형을 기준으로 확인하세요. 10808은 흔히 사용하는 로컬 포트지만, 일부 이전 설정에서는 SOCKS 포트가 10808, HTTP 포트가 10809일 수 있습니다. 포트 번호만으로 프로토콜 유형을 판단할 수는 없습니다.
| 확인 위치 | 확인할 내용 | 문제가 있을 때 조치 |
|---|---|---|
| 클라이언트 수신 설정 | HTTP, SOCKS 또는 혼합 연결 지점의 실제 포트 | 연결 유형에 맞는 테스트 명령을 사용하고 이전 포트를 그대로 사용하지 않기 |
| 브라우저 프록시 설정 | 시스템 설정을 따르는지, 별도의 프록시가 설정되어 있는지 | 충돌하는 별도 설정을 일시적으로 제거 |
| TUN 설정 | 문제 확인 중에 실제로 꺼져 있는지 | 일반 프록시부터 테스트한 뒤 TUN을 별도로 확인 |
| 로컬 보안 정책 | 코어 실행이나 외부 연결을 차단하는지 | 차단 기록을 확인하고 보안 시스템 전체를 끄지 않기 |
다음은 Windows 터미널에서 프록시를 명시해 테스트하는 예시입니다. 포트는 반드시 클라이언트의 실제 수신 포트로 바꾸세요. HTTP 명령은 HTTP 또는 혼합 연결 지점에서, SOCKS 명령은 SOCKS 또는 혼합 연결 지점에서 사용합니다. --socks5-hostname은 대상 도메인의 DNS 조회를 프록시 서버에 맡깁니다. 두 명령은 진단을 위한 예시이며, 실제 테스트 결과가 아닙니다.
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com
curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com결론: 프록시 지정 테스트에 성공하면 브라우저를 확인하세요
프록시를 명시한 요청에서 대상 사이트의 HTTP 응답을 받았는데 브라우저에서는 여전히 접속할 수 없다면, 노드를 바꾸기 전에 브라우저 연결 지점과 시스템 프록시 설정부터 확인하세요. 127.0.0.1의 포트에 연결할 수 없다는 메시지가 나오면 수신 포트나 코어 실행 문제를 먼저 해결해야 합니다.
4단계: 노드 주소, 포트, 인증 정보 확인
로컬 연결 지점이 정상이라면 현재 사용하는 노드를 선택해 편집 창을 열고 서비스 제공자가 안내한 전체 설정과 대조하세요. 먼저 서버 주소와 원격 포트를 확인한 다음 프로토콜과 UUID 또는 해당 인증 정보를 점검합니다. 서버 포트와 로컬 수신 포트는 서로 다릅니다. 로컬 연결 지점은 10808이고 서버 포트는 443일 수 있지만, 포트가 443이라고 해서 노드가 TLS를 사용한다는 뜻은 아닙니다.
- 주소: 서버 항목에는 도메인이나 IP를 입력해야 합니다. 웹페이지 전체 URL을 잘못 붙여넣지 말고, 앞뒤 공백도 제거하세요.
- 포트: 서버 설정과 일치해야 합니다. 흔히 사용하는 설정이
443이라는 이유만으로 포트를 임의로443으로 바꾸지 마세요. - 프로토콜: VMess와 VLESS는 인증 및 보안 설정이 다릅니다. 드롭다운에서 프로토콜 이름만 바꿔 노드를 변환할 수는 없습니다.
- 구독: 제공자가 서버 주소나 인증 정보를 변경했다면 기존 구독 그룹을 업데이트하고, 갱신된 노드를 직접 선택하세요.
- 코어 호환성: v2rayNG는 Xray 계열 코어를 사용하고 v2flyNG는 v2fly 계열 코어를 사용합니다. 예를 들어 REALITY는 Xray 관련 기능이므로 코어마다 동일한 설정을 지원한다고 가정해서는 안 됩니다.
서버 TCP 포트만 확인하려면 Windows PowerShell에서 Test-NetConnection을 실행하세요. 아래는 example.com과 443을 사용한 명령 형식 예시입니다. 실제 테스트에는 자신의 서버 주소와 포트를 입력해야 합니다. 결과의 TcpTestSucceeded : True는 TCP 연결 성공만 의미하며 프록시 인증이나 TLS는 확인하지 않습니다.
Test-NetConnection -ComputerName example.com -Port 443오류: connect: connection refused
가능한 원인: 대상 포트에서 연결을 수신하지 않거나 중간 장비가 연결을 거부했을 수 있습니다. 대상이 로컬 주소라면 로컬 코어가 실행되지 않았을 수도 있습니다.
해결 방법: 오류 메시지에 표시된 대상 주소를 확인한 다음 해당 포트를 점검하세요. 원격 포트가 올바른데도 연결이 거부된다면 서비스 제공자에게 서버 상태를 확인해 달라고 요청하세요.
5단계: 전송 방식, TLS, REALITY 관련 설정 확인
TCP 연결은 되지만 실제 요청이 실패한다면 전송 계층을 확인하세요. 전송 방식은 서버 설정과 일치해야 합니다. WebSocket을 사용한다면 경로와 Host가 리버스 프록시의 라우팅에 영향을 줄 수 있고, gRPC를 사용한다면 서비스명이 일치해야 합니다. 다른 노드의 경로와 Host, 서비스명을 ‘일단 시험 삼아’ 복사하지 마세요. 추적하기 어려운 변수가 추가됩니다.
| 설정 유형 | 주요 항목 | 구분해야 할 개념 |
|---|---|---|
| WebSocket | 전송 유형, 경로, Host | Host와 연결 주소는 다를 수 있으므로 제공된 값을 그대로 입력 |
| gRPC | 전송 유형, serviceName | 서비스명은 임의의 메모가 아니며 대소문자도 일치해야 함 |
| TLS | 서버 이름, 인증서 검증, ALPN | SNI는 핸드셰이크에 사용되므로 대상 웹사이트 도메인으로 임의 변경할 수 없음 |
| REALITY | serverName, 공개 키, shortId, flow | 클라이언트 공개 키는 서버의 키 설정과 일치해야 하며 flow는 노드 요구 사항에 맞게 입력 |
TLS의 서버 이름은 일반적으로 핸드셰이크 대상과 인증서 이름 검증에 모두 영향을 줍니다. REALITY는 서로 맞물리는 설정값이 필요하므로 보안 유형만 REALITY로 바꿔서는 안 됩니다. 가져온 설정에서 항목이 누락되었다면 현재 클라이언트와 코어 버전이 해당 설정을 지원하는지 먼저 확인하고 다운로드 페이지에서 호환되는 버전을 선택하세요. 필드 불일치를 감추려고 보안 검사를 끄지 마세요.
오류: tls: handshake failure
가능한 원인: 서버가 핸드셰이크를 거부했을 수 있으며 SNI, TLS 설정 또는 앞단 서비스와 관련이 있을 수 있습니다. 이 문구만으로는 어떤 항목이 문제인지 판단할 수 없습니다.
해결 방법: 노드의 원래 설정과 보안 유형 및 서버 이름을 대조하고, 해당 오류가 발생하기 직전의 로그를 확인하세요. TLS 설정을 무작위로 변경하지 마세요.
오류: x509: certificate signed by unknown authority
가능한 원인: 인증서 체인이 불완전하거나 시스템 신뢰 저장소에 문제가 있거나, 연결 중 인증서가 교체되었을 수 있습니다.
해결 방법: 로컬 인증서 신뢰 환경과 서버 인증서 체인을 확인하세요. 필요하면 관리자나 서비스 제공자에게 문의하고, 인증서 검증 건너뛰기를 바로 활성화하지 마세요.
6단계: 노드 도메인 조회와 대상 도메인 조회 구분
DNS 문제는 적어도 두 단계로 나뉩니다. 클라이언트가 먼저 노드 서버의 주소를 찾아야 하고, 프록시 연결이 성립한 뒤에는 대상 웹사이트의 주소도 조회해야 합니다. 첫 단계에서 실패하면 노드에 연결할 수 없습니다. 두 번째 단계에서 실패하면 노드 테스트는 성공하지만 웹페이지가 열리지 않을 수 있습니다. 라우팅 규칙이 도메인이나 조회된 IP에 따라 달라질 수 있으므로 DNS를 바꾼 뒤의 변화가 조회 단계에만 영향을 준다고 단정할 수는 없습니다.
-
노드 도메인 조회
Windows에서
Resolve-DnsName을 실행해 실제 노드 도메인을 조회하세요. 결과가 있는지, 조회 오류가 없는지 확인합니다. DNS 조회에 성공해도 서버 포트에 연결할 수 있다는 뜻은 아닙니다. -
기존 설정 보존
현재 클라이언트의 DNS 및 라우팅 설정을 기록한 다음 한 항목씩 변경하세요. DNS 서버를 바꾸고 TUN을 켜고 라우팅까지 동시에 변경하면 어떤 설정이 결과에 영향을 줬는지 알 수 없습니다.
-
라우팅 규칙 적용 확인
로그에서 대상 요청이 프록시와 직접 연결 중 어느 경로로 처리되는지 확인하세요. 특정 도메인 유형만 실패한다면 부적절한 출구로 분기되는지 점검하고, 기존 규칙을 복원해 결과를 비교하세요.
-
캐시 삭제 후 재테스트
시스템 DNS를 변경했다면
ipconfig /flushdns를 실행한 다음 클라이언트 연결을 다시 시작하세요. 브라우저에 별도의 DNS 캐시나 보안 DNS 설정이 있을 수 있으므로 따로 확인해야 합니다.
Resolve-DnsName example.com
ipconfig /flushdns명령에 나온 example.com은 사용법을 보여 주기 위한 예시입니다. 노드 도메인을 확인된 IP로 잠시 바꿔 비교하더라도 TLS 서버 이름은 올바른 값으로 유지하고, 서비스 제공자가 해당 연결 방식을 허용하는지 확인해야 합니다. 동적 주소나 앞단 서비스를 사용하는 노드에는 IP를 고정해 입력하지 않는 것이 좋습니다. 설정에 관한 자세한 내용은 DNS 설정 안내를 참고하세요.
오류: no such host
가능한 원인: 로그에 표시된 도메인을 조회하지 못했습니다. 철자가 틀렸거나 DNS 레코드가 만료되었거나 DNS 서버가 존재하지 않는다는 결과를 반환했을 수 있습니다.
해결 방법: 오류에 표시된 도메인이 노드인지 대상 웹사이트인지 먼저 확인한 뒤, 해당 도메인과 이를 조회하는 DNS 설정을 각각 점검하세요.
7단계: 코어 로그 확인 및 한 번에 하나씩 재테스트
앞의 여섯 단계를 확인해도 원인을 찾지 못했다면 코어 로그를 살펴보세요. v2rayN은 관리 인터페이스이며 실제 프록시 처리는 선택한 코어가 담당합니다. 인터페이스가 실행 중이라고 해서 코어가 설정을 정상적으로 불러왔다는 뜻은 아닙니다. 먼저 시작 단계에서 설정 구문 오류나 포트 점유, 프로세스 종료가 있었는지 확인한 다음 요청을 한 번 보낸 뒤의 로그를 살펴보세요. 연결 버튼을 반복해서 누르면 중복 기록만 늘어납니다.
- 로그 수준: 현재 버전의 매개변수 설정에서 「로그 수준」 또는
loglevel항목을 찾아 필요한 경우 잠시info로 설정하세요. 더 자세한 정보가 필요하면 짧은 시간 동안debug를 사용하고, 문제 확인이 끝나면 원래 수준으로 되돌리세요. - 재현 시간대: 테스트 시간을 기록하고 연결을 시작한 뒤 테스트 URL 하나만 여세요. 하루 전체 로그를 캡처하는 대신 해당 요청 직전과 직후의 로그를 보관하세요.
- 확인할 대상: 실패 지점이 로컬 수신, 노드 연결, TLS 핸드셰이크, 도메인 조회, 대상 웹사이트 응답 중 어디인지 확인한 뒤 해당 단계로 돌아가 해결하세요.
- 문의 시 제공할 정보: 클라이언트 버전, 코어 버전, 네트워크 유형, 오류 발생 시각, 필요한 부분을 비식별 처리한 로그를 제공하세요. 구독 링크와 UUID, 인증 정보, 개인 주소는 가려야 합니다.
오류: address already in use
가능한 원인: 다른 프로세스가 로컬 수신 주소와 포트를 사용 중이거나 코어가 중복 실행되었을 수 있습니다.
해결 방법: 중복 실행된 프로세스를 종료하고 포트 점유 상태를 확인하세요. 수신 포트를 변경해야 한다면 시스템 프록시나 앱의 포트 설정도 함께 업데이트해야 합니다.
오류: i/o timeout
가능한 원인: 네트워크 작업이 제한 시간 안에 끝나지 않았습니다. DNS 조회, 연결 수립, 데이터 읽기 단계 중 어디서든 발생할 수 있으므로 이 문구만으로 노드 장애를 단정할 수 없습니다.
해결 방법: 앞뒤 로그의 대상 주소와 작업 단계를 함께 살펴보고 DNS, 서버 포트 또는 원격 응답을 각각 확인하세요.
오류: context deadline exceeded
가능한 원인: 테스트나 요청 전체가 제한 시간에 도달했습니다. 하위 연결이 실패했을 수도 있고 테스트 대상이 응답하지 않았을 수도 있습니다.
해결 방법: 먼저 테스트 대상을 바꾸고 하위 단계의 오류를 확인하세요. 시간 제한을 늘리는 것은 응답이 느린지 판단할 때만 유용하며 잘못된 설정을 고쳐 주지는 않습니다.
설정을 수정한 뒤에는 네트워크와 대상, 모드를 그대로 유지하고 요청을 연속 3회 보낸 다음 브라우저에서 실제 접속도 확인하세요. 일반 프록시는 작동하지만 TUN에서만 문제가 생기면 TUN 설정 문제 해결을 별도로 진행하세요. 서버 포트에 계속 연결할 수 없고 다른 네트워크에서도 같은 문제가 발생한다면 로컬 TLS나 DNS를 더 변경하기보다 서비스 제공자에게 서버 상태를 확인하세요.
결론: 실패한 단계에 따라 다음 조치 선택
로컬 연결 지점에서 실패하면 수신 설정을 확인하고, 원격 연결 수립에 실패하면 주소와 네트워크를 확인하세요. 핸드셰이크에서 실패하면 관련 설정값을 대조하고, 대상 도메인 조회가 실패하면 DNS와 라우팅을 살펴보세요. 매번 한 항목만 변경하고 결과를 기록해야 유효한 근거를 남기고, 개선되지 않았을 때 기존 설정으로 되돌리기도 쉽습니다.