구독을 가져왔는데 노드가 시간 초과로 표시되거나, 클라이언트에는 연결됨으로 나오지만 웹페이지가 열리지 않을 때 참고하세요. 먼저 코어 실행과 로컬 포트 수신 상태를 확인하고, 트래픽이 프록시를 통과하는지 살펴본 다음 구독, 시스템 시간, 전송 설정, 서버 순으로 점검합니다. 한 번에 한 항목만 바꾸고 같은 대상으로 다시 테스트해 로컬 문제를 노드 장애로 오판하지 않도록 합니다.
1. 포트 연결과 프록시 사용 가능 여부 구분하기
‘시간 초과’는 정해진 시간 안에 특정 단계가 완료되지 않았다는 뜻일 뿐, 서버가 중단됐다는 의미는 아닙니다. 브라우저 요청은 보통 앱의 프록시 설정, 로컬 인바운드 포트, 라우팅 규칙, 원격 연결, 프로토콜 핸드셰이크, 대상 웹사이트를 거칩니다. 어느 한 단계에서든 문제가 생기면 페이지가 계속 로드되는 것처럼 보일 수 있습니다.
TCPing은 TCP 포트에 연결할 수 있는지 주로 확인합니다. 실제 연결 테스트는 프록시 프로토콜과 테스트 주소까지 거칩니다. TCPing에 성공해도 VMess 또는 VLESS 인증이 올바르다는 뜻은 아니며, 실제 연결 테스트에 실패해도 테스트 주소에 접근할 수 없는 경우가 있습니다. 노드를 바꾸기 전에 어느 단계에서 실패했는지 먼저 기록하세요.
- 코어가 시작되지 않음: 설정 로드, 권한 또는 포트 충돌부터 해결하세요. 이 상태에서는 속도 테스트 결과가 의미 없습니다.
- 포트에 연결되지만 실제 연결은 실패: 프로토콜 인증, TLS, 전송 설정, 테스트 대상을 중점적으로 확인하세요.
- 실제 연결은 성공하지만 브라우저는 실패: 시스템 프록시, 앱 프록시, 해당 요청을 라우팅 규칙이 처리하는지 확인하세요.
2. 로컬 포트: 코어가 실제로 수신 중인지 확인
v2rayN 창이 열려 있다고 해서 코어가 정상적으로 실행 중인 것은 아닙니다. 먼저 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트를 확인한 뒤 기본 화면에서 로그를 살펴보세요. 버전에 따라 메뉴 이름이 조금씩 다를 수 있으므로 현재 화면에 표시된 SOCKS, HTTP 또는 혼합 수신 유형을 기준으로 확인하세요. 다른 안내서의 포트 번호를 그대로 따라 입력하지 마세요.
아래 예시는 Windows의 로컬 포트 10808을 기준으로 합니다. PowerShell에서 명령을 실행해 조회하세요. 해당 포트의 수신 기록이 표시되어야 프로그램이 포트를 사용 중인 것입니다. 이때 현재 실행 중인 코어가 해당 프로그램인지도 확인해야 합니다.
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
netstat -ano | findstr :10808
첫 번째 명령에서 프로세스 ID가 나오면 Get-Process -Id 프로세스 번호로 어떤 프로세스인지 확인할 수 있습니다. 두 번째 명령에는 연결 기록이 표시될 수도 있으므로 LISTENING 행을 확인하세요. 포트 번호만 보고 정체를 알 수 없는 프로세스를 종료하지 마세요. 클라이언트가 중복 실행됐거나 이전 코어 프로세스가 남아 있는지 먼저 확인하세요.
오류: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
원인: Windows에서 다른 프로세스가 수신 포트를 사용 중입니다. 해결: 프로세스를 확인한 뒤 중복 실행을 종료하거나 클라이언트의 로컬 포트를 변경하고, 수동 프록시 설정도 같은 포트로 수정하세요.
오류: bind: address already in use
원인: 해당 주소와 포트를 이미 다른 프로세스가 수신 중입니다. 코어를 중복 실행한 경우가 흔합니다. 해결: 먼저 프록시를 중지하고 중복 실행된 프로세스를 종료하세요. 다시 시작한 뒤 새 로그에 같은 오류가 나타나는지 확인하세요.
Android의 v2rayNG에서는 먼저 중지를 누른 다음 연결을 다시 시작하고 ‘메뉴’ → ‘로그’를 확인하세요. 시스템에서 VPN 연결 권한을 요청하면 허용해야 트래픽을 처리할 수 있습니다. 시스템 VPN을 사용하는 다른 앱을 동시에 실행하면 연결을 서로 대체할 수 있습니다. 알림 영역에 아이콘이 표시된다고 해서 원격 노드까지 사용 가능한 것은 아닙니다.
3. 프록시 적용: 브라우저 요청이 로컬 인바운드로 들어오는지 확인
로컬 수신이 정상이라면 다음으로 시스템 프록시를 확인하세요. v2rayN에서는 트레이 아이콘을 마우스 오른쪽 버튼으로 클릭해 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 선택할 수 있습니다. Windows에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동해 수동 프록시 주소와 포트가 현재 클라이언트 설정과 일치하는지 확인하세요. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 확인합니다.
-
테스트할 노드 선택
v2rayN 기본 화면에서 테스트할 서버를 활성 서버로 지정하세요. v2rayNG에서는 대상 구성을 선택한 뒤 다시 연결합니다. 속도 테스트 목록의 결과를 현재 활성 연결 결과로 착각하지 마세요.
-
프록시 모드 확인
먼저 시스템 프록시로 브라우저 연결을 확인하고, 그다음 TUN을 고려하세요. TUN이 이미 켜져 있다면 변수를 줄이기 위해 잠시 끄세요. v2rayNG의 VPN 모드에서는 앱이 우회 목록에 포함됐는지도 확인해야 합니다.
-
요청 한 번 보내기
로그 표시를 지운 다음 고정된 HTTPS 페이지에 접속하고 해당 도메인의 요청 기록이 나타나는지 확인하세요. 필요하면 로그 수준을 일시적으로 높여 원인을 찾고, 점검이 끝나면 평소 설정으로 되돌리세요.
-
라우팅 경로 비교
요청이 코어로 들어왔는데도 직접 연결된다면 현재 라우팅 규칙을 확인하세요. 같은 페이지에서 전체 프록시 모드로 잠시 전환해 테스트한 뒤, 확인이 끝나면 기존 분할 라우팅 규칙으로 복원하세요. 노드를 동시에 바꾸지는 마세요.
명령줄에서는 시스템 프록시 설정을 거치지 않고 로컬 진입점을 직접 테스트할 수도 있습니다. 아래 방법은 10808에서 실제로 SOCKS 서비스를 제공하는 경우에만 사용할 수 있습니다. HTTP 전용 포트라면 해당 HTTP 프록시 옵션을 사용하세요. Windows에서는 일부 PowerShell 환경의 명령 별칭이 결과에 영향을 주지 않도록 curl.exe를 사용하세요.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
결론: 명시적 프록시는 성공한다면 프록시 적용 설정부터 확인
이 명령으로 HTTP 응답 헤더를 받을 수 있지만 같은 웹사이트가 브라우저에서 열리지 않는다면 브라우저 자체 프록시, 확장 프로그램 설정, 시스템 프록시를 우선 확인하세요. 이 단계에서는 UUID, TLS, 서버 포트를 바꾸지 마세요.
4. 구독 유효기간: 업데이트 성공이 노드 사용 가능을 뜻하지는 않습니다
구독 주소는 설정을 배포하는 역할을 할 뿐 프록시 서버 자체가 아닙니다. 구독 요청에 성공했다는 것은 파싱 가능한 내용을 가져왔다는 뜻일 뿐입니다. 트래픽 한도, 유효기간, 노드 이전, 서버 장애에 따라 연결이 달라질 수 있습니다. 반대로 구독 업데이트에 실패해도 기존 노드는 계속 작동할 수 있으므로 두 가지를 따로 테스트해야 합니다.
- v2rayN: ‘구독 그룹’에서 업데이트할 그룹이 맞는지 확인한 다음 ‘프록시를 사용하지 않고 구독 업데이트’를 실행하세요. 현재 네트워크에서 구독 서버에 접속할 수 없지만 사용할 수 있는 노드가 있다면 ‘프록시를 사용하여 구독 업데이트’를 선택할 수 있습니다. 메뉴 이름은 사용 중인 버전에 따라 다를 수 있습니다.
- v2rayNG: 사이드 메뉴에서 ‘구독 그룹 설정’으로 이동해 주소를 확인하고, 기본 화면으로 돌아와 ‘구독 업데이트’를 실행하세요. 업데이트에 프록시가 필요하다면 활성 노드가 작동하는지 먼저 확인하고, 설정에서 구독 업데이트 프록시 관련 옵션도 살펴보세요.
- 서비스 계정: 서비스 제공업체에서 계정 만료일, 남은 트래픽, 점검 공지를 확인하세요. 서버 메모에 ‘사용 가능’이라고 적혀 있다는 이유만으로 계정 상태 확인을 건너뛰지 마세요.
- 설정 비교: 업데이트 후 노드를 다시 선택하고 원격 주소, 포트, 전송 유형이 바뀌었는지 확인하세요. 이전 설정을 캡처해 보관할 때는 인증 정보를 가려야 합니다.
5. 시스템 시간과 전송 설정: 로그를 보며 항목별 확인
시스템 시간이 크게 어긋나면 인증서 유효기간 확인에 문제가 생길 수 있고 VMess 시간 검증에도 영향을 줄 수 있습니다. Windows에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 자동 설정을 켜고 동기화를 실행하세요. Android에서는 시스템 설정에서 ‘날짜 및 시간’을 검색해 자동 설정을 켜세요. 표시되는 시간대가 다르다고 반드시 시계가 틀린 것은 아니므로 실제 날짜와 시간이 정확한지 확인해야 합니다.
이어서 서비스 제공업체가 안내한 전체 설정을 확인하세요. V2Ray는 프로토콜 및 프록시 코어 생태계에서 사용하는 이름이고, v2rayN은 클라이언트입니다. 모든 노드가 임의의 코어와 전송 방식에서 작동하는 것은 아닙니다. v2rayNG는 Xray 코어를 사용합니다. v2flyNG에서 같은 문제가 재현된다면 v2fly 코어의 지원 범위에 맞춰 설정을 확인해야 하며, 노드 이름만 비교해서는 안 됩니다.
| 확인할 항목 | 흔한 설정 불일치 | 해결 방법 |
|---|---|---|
| 주소 및 원격 포트 | 이전 도메인, 이전 포트 또는 원격 포트 자리에 로컬 포트를 입력 | 최신 구독을 다시 가져오고 서비스 제공업체의 안내와 비교 |
| VMess / VLESS 인증 정보 | 만료된 UUID, 잘못 복사된 값 또는 잘못 선택한 프로토콜 | 전체 설정을 다시 가져오고 다른 노드의 인증 정보를 가져다 쓰지 마세요 |
| TLS 및 SNI | 서버 이름 불일치, 인증서 만료 또는 시스템 시간 오류 | serverName과 인증서 도메인을 확인하고 인증서 검증을 유지하세요 |
| WebSocket | path 또는 Host가 서버 설정과 불일치 | 경로, 대소문자, Host를 한 글자씩 확인하고 임의로 슬래시를 추가하지 마세요 |
| gRPC | serviceName 또는 전송 유형 오류 | 원래 설정에 맞게 서비스 이름과 TLS 설정을 복원하세요 |
| VLESS + REALITY | 공개 키, shortId, serverName 또는 flow 불일치 | 전체 매개변수와 코어 지원 여부를 확인하고 일반 TLS 설정을 그대로 적용하지 마세요 |
오류: x509: certificate has expired or is not yet valid
원인: 클라이언트 시간이 잘못됐거나 서버 인증서가 유효기간을 벗어났습니다. 해결: 먼저 시스템 시간을 동기화하세요. 시간이 정확하다면 서비스 제공업체에 인증서 문제를 알리세요. 인증서 검증을 끄는 방법은 해결책이 아닙니다.
오류: websocket: bad handshake
원인: WebSocket 업그레이드 요청이 예상한 응답을 받지 못했습니다. 경로, Host, 리버스 프록시 또는 서버 설정이 맞지 않을 수 있습니다. 해결: 최신 구독 설정과 항목별로 대조한 뒤 서버 관리자에게 전달 설정을 확인해 달라고 요청하세요.
오류: i/o timeout
원인: 특정 네트워크 읽기 또는 쓰기 작업이 시간 초과됐습니다. 이 로그 한 줄만으로 서버, DNS, 대상 웹사이트 중 어디가 문제인지 알 수는 없습니다. 해결: 앞뒤 로그를 함께 확인해 대상 주소와 실패 단계를 파악한 뒤, 다른 네트워크에서 같은 노드로 교차 테스트하세요.
6. 네트워크와 서버: 교차 테스트로 문제 범위 좁히기
로컬 점검을 마친 뒤 원격 측을 확인하세요. Windows에서는 아래 명령으로 원격 TCP 연결을 테스트할 수 있습니다. example.com을 노드 서버 도메인으로, 443을 설정에 지정된 실제 원격 포트로 바꾸세요. 연결 확인을 위한 예시일 뿐, 사용할 수 있는 노드 설정은 아닙니다.
Resolve-DnsName example.com
Test-NetConnection -ComputerName example.com -Port 443
DNS에서 주소를 찾았다고 결과가 반드시 올바른 것은 아니며, TCP 테스트에 성공해도 프록시 인증이 통과한 것은 아닙니다. 로그에 도메인 확인 실패가 명확히 표시된다면 시스템 DNS, 클라이언트 DNS, 실제로 사용 중인 DNS 조회 경로를 확인하세요. 시간 초과가 보인다고 DNS, 라우팅, 전송 프로토콜을 한꺼번에 바꾸지는 마세요.
- 같은 기기에서 네트워크 변경: Wi-Fi와 모바일 데이터를 이용해 같은 노드와 같은 대상에 접속해 보세요. 한 네트워크에서만 실패한다면 해당 네트워크의 외부 연결 제한, DNS 또는 연결 경로 문제를 우선 확인하세요.
- 같은 네트워크에서 노드 변경: 다른 노드에 연결된다고 해서 원래 노드 또는 해당 경로에 문제가 있다고 범위를 좁힐 수는 있지만, 원래 서버가 중단됐다고 단정할 수는 없습니다.
- 같은 노드를 다른 기기에서 테스트: 데스크톱에서는 작동하지만 Android에서 실패한다면 서버 설정부터 바꾸지 말고 설정 내용, 앱 우회 목록, 시스템 시간, 코어 지원 여부를 비교하세요.
- 특정 웹사이트에서만 실패: 해당 도메인의 라우팅 결과와 대상 사이트 상태를 확인하세요. 다른 사이트는 프록시로 열 수 있다면 먼저 대상 사이트 문제로 살펴보세요.
결론: 기기와 네트워크를 바꿔도 실패하면 서버 측 점검 요청
최신 설정이 서로 다른 두 기기와 두 네트워크에서 모두 실패하지만 다른 노드는 정상이라면, 민감 정보를 가린 로그를 제출해 서버 관리자에게 수신 포트, 방화벽, 인증서, 리버스 프록시, 외부 연결을 확인해 달라고 요청하세요. 클라이언트를 반복해서 재설치해도 이 단계의 문제는 대개 해결되지 않습니다.
7. 자주 묻는 질문과 문의 시 확인할 내용
TCPing에는 결과가 나오는데 실제 연결은 왜 시간 초과되나요?
TCPing은 포트에 연결할 수 있다는 것만 확인합니다. 실제 연결 테스트 중 코어 로그를 확인한 뒤 프로토콜 인증 정보, TLS, 전송 설정, 테스트 주소를 점검하세요. 브라우저나 명시적 프록시 명령으로 다른 고정 대상에 접속해 테스트 대상과 노드 중 어디에 문제가 있는지 구분하세요.
v2rayNG에는 연결됨으로 표시되는데 모든 앱이 열리지 않아요. 어떻게 해야 하나요?
먼저 선택한 설정이 맞는지 확인하고 로그에 외부 연결 오류가 있는지 살펴보세요. 그다음 앱별 프록시 설정에서 대상 앱이 제외됐는지 확인합니다. 다른 VPN 연결 앱을 잠시 중지하고 다시 연결한 뒤 Wi-Fi와 모바일 데이터에서 각각 테스트하세요.
시간 초과 문제를 해결하려면 TUN을 바로 켜야 하나요?
그럴 필요 없습니다. TUN은 더 많은 앱의 트래픽을 처리하는 기능이며, 잘못된 UUID, 원격 포트, 서버 인증서를 고쳐 주지는 않습니다. 먼저 로컬 프록시 진입점과 노드가 작동하는지 확인한 다음 시스템 프록시를 따르지 않는 앱을 점검하세요.
재시작하면 잠시 연결되다가 다시 끊깁니다. 어떻게 해야 하나요?
연결이 끊기는 시간을 기록하고 절전 모드, 네트워크 전환, 배터리 제한, 코어 프로세스 중복 실행과 관련이 있는지 확인하세요. Android에서는 ‘설정’ → ‘앱’ → ‘v2rayNG’에서 배터리 및 백그라운드 실행 권한을 확인하세요. 메뉴와 옵션은 기기의 시스템에 표시된 내용을 기준으로 조정하면 됩니다.
서비스 제공업체에 문의할 때는 실패 시간과 시간대, 클라이언트 및 코어 버전, 운영체제, 네트워크 유형, 테스트 대상, 실패 전후의 일부 로그를 준비하세요. 전체 구독 링크, UUID 또는 접근 token이 포함된 화면 캡처는 보내지 마세요. 서버 주소와 개인 IP도 공개 범위에 맞춰 가려야 합니다.
- 로컬 포트 수신이 정상인지, 명시적 프록시 요청이 성공하는지 알려 주세요.
- 구독 업데이트 여부와 계정 유효 여부, 최근 설정을 변경했는지 알려 주세요.
- 같은 노드에서 네트워크를 바꾼 결과와 같은 네트워크에서 노드를 바꾼 결과를 알려 주세요.
- 문제를 해결한 뒤 기존 테스트 대상으로 다시 확인하고, 임시로 변경한 로그 수준과 라우팅 모드를 원래대로 복원하세요.