v2rayN 데스크톱 버전과 v2rayNG, v2flyNG 안드로이드 버전에서 발생하는 연결 시간 초과 문제를 다룹니다. 먼저 테스트가 어느 단계에서 실패하는지 확인한 뒤 시스템 시간, 로컬 리스닝, 요청 진입점을 살펴보세요. 이어 서버 주소, TLS 및 전송 매개변수를 확인하고 마지막으로 서버 리스닝과 방화벽을 점검합니다. 각 단계의 로그와 재테스트 결과를 기록하면 여러 설정을 한꺼번에 바꿔 원인을 놓치는 일을 피할 수 있습니다.
1. 테스트 시간 초과와 실제 연결 실패 구분하기
목록에 ‘시간 초과’가 표시된다고 해서 노드의 모든 기능을 사용할 수 없는 것은 아닙니다. TCP 연결 테스트는 TCP 연결을 수립할 수 있는지만 확인합니다. 프록시를 통해 테스트 사이트에 요청을 보내면 프로토콜 인증, TLS, 도메인 이름 확인, 대상 사이트의 응답까지 영향을 줍니다. 먼저 어떤 테스트를 실행했는지 기록하고, 서로 다른 테스트 결과를 같은 지표로 취급하지 마세요.
- 목록 테스트만 실패하는 경우: 해당 노드를 선택하고 정상 작동이 확인된 웹사이트에 접속하면서 클라이언트 로그를 확인하세요. 실제 접속이 성공한다면 테스트 URL과 테스트 요청의 라우팅을 우선 점검합니다.
- 테스트는 성공하지만 브라우저 접속이 실패하는 경우: 브라우저 요청이 로컬 프록시로 전달되는지, 브라우저 확장 프로그램에 별도의 프록시 설정이 있는지 먼저 확인하세요.
- 모든 노드가 동시에 실패하는 경우: 노드 매개변수를 하나씩 수정하기보다 코어 실행 여부, 시스템 시간, 현재 네트워크의 웹 로그인이 필요한지부터 확인하세요.
- 특정 노드만 실패하는 경우: 정상 작동하는 노드를 비교 대상으로 남겨 두고, 실패한 노드의 주소, 포트, 전송 설정 및 서버 상태를 중점적으로 확인하세요.
시작하기 전에 클라이언트 버전, 사용 중인 코어, 운영체제, 테스트 시간과 실패 로그 일부를 기록하세요. v2rayN 인터페이스는 버전에 따라 달라집니다. 아래 데스크톱 메뉴는 기존 Windows 인터페이스의 명칭을 기준으로 설명하므로 다른 인터페이스에서는 위치를 그대로 따르기보다 같은 이름의 설정 항목을 찾아보세요.
2. 시스템 시간과 기본 네트워크부터 확인하기
시스템 시간이 크게 어긋나면 TLS 인증서 유효 기간 판정에 문제가 생길 수 있고, VMess의 시간 관련 인증도 실패할 수 있습니다. VLESS에 VMess의 시간 조건을 그대로 적용할 수는 없지만 외부 연결에 TLS를 사용한다면 시스템 시간은 여전히 정확해야 합니다. 표시 시간대만 바꿔서는 실제 시간이 잘못된 문제를 해결할 수 없습니다.
-
시스템 시간 동기화
Windows에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 ‘자동으로 시간 설정’을 켠 다음 ‘지금 동기화’를 실행하세요. Android에서는 시스템 설정에서 ‘날짜 및 시간’을 검색하고 자동 시간 설정을 켭니다. 시스템마다 메뉴 이름과 위치가 다를 수 있습니다.
-
네트워크 연결 상태 확인
프록시 연결을 잠시 끊고 현재 네트워크에서 웹 로그인이 필요한지 확인하세요. 공용 네트워크의 인증 페이지가 표시되면 먼저 인증을 완료한 다음 클라이언트를 실행합니다. 기본 네트워크에 연결되지 않은 상태에서 노드를 반복해서 업데이트하지 마세요.
-
한 번만 조건을 바꿔 재테스트
노드와 설정은 그대로 두고 네트워크만 한 번 전환해 다시 테스트하세요. 같은 노드가 다른 네트워크에서 작동한다면 기존 네트워크의 DNS, 출구 정책 또는 접속 제한을 우선 살펴보세요. 그렇다고 해서 서버 문제라고 바로 단정할 수는 없습니다.
Windows에서는 터미널에서 시간 동기화 상태를 확인할 수도 있습니다. 아래 명령은 상태 조회용이며 노드 설정을 변경하지 않습니다. 시간 서비스가 실행 중이 아니라는 메시지가 나오면 시스템 시간 설정으로 돌아가 서비스와 동기화 상태를 확인하세요.
w32tm /query /status3. 로컬 리스닝과 앱 진입점 확인하기
서버에 연결 요청이 도달하기도 전에 로컬 코어 실행이 실패했을 수 있습니다. v2rayN의 기존 인터페이스에서는 보통 ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 설정을 확인하고, 메인 화면에서 시스템 프록시 상태를 확인합니다. 실제 인터페이스와 시작 로그를 기준으로 판단하세요. 일부 버전은 혼합 리스너를 사용하므로 버전마다 SOCKS와 HTTP 포트가 따로 있다고 가정하면 안 됩니다.
위 두 포트는 명령 예시에만 사용되며 특정 클라이언트 버전의 기본값을 뜻하지 않습니다. 실행하기 전에 자신의 설정에서 프로토콜 종류와 포트를 확인하세요. 로컬 SOCKS 리스너가 실제로 127.0.0.1:10808인 경우, Windows에서 먼저 리스닝 상태를 확인한 뒤 프록시를 명시해 요청을 보낼 수 있습니다:
Get-NetTCPConnection -LocalPort 10808 -State Listen
curl.exe -I --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 https://example.com/첫 번째 명령은 PowerShell에서 실행합니다. 리스닝 항목이 없다면 원격 인증서가 아니라 코어 시작 로그와 로컬 포트를 먼저 확인하세요. 두 번째 명령의 example.com은 예시 대상입니다. 실제 점검 시 정상 작동이 확인된 HTTPS 사이트로 바꿔도 됩니다. socks5h는 대상 도메인 이름 확인을 프록시 쪽에 맡긴다는 뜻입니다. 10초와 20초는 이 명령에 명시한 시간 초과 한도이며 속도 측정 결과가 아닙니다.
판단: 프록시를 명시하면 성공하는 경우, 앱 진입점부터 수정
명령에서 HTTP 응답을 받았는데도 브라우저로 같은 대상에 접속할 수 없다면 시스템 프록시, 브라우저 자체 프록시, 라우팅 규칙을 우선 확인하세요. HTTP 403 같은 상태도 응답을 받은 것이므로 연결 시간 초과와 혼동하면 안 됩니다.
- v2rayN: 시스템 프록시 설정은 해당 설정을 따르는 앱에만 적용됩니다. 프록시를 명시한 명령은 시스템 프록시 진입점을 우회하지만 코어의 라우팅 규칙까지 우회하지는 않습니다.
- v2rayNG, v2flyNG: Android VPN 연결 권한이 허용되어 있는지, 다른 VPN 연결이 현재 연결을 대체하지 않았는지 확인하세요. 앱별 프록시를 사용한다면 대상 앱이 프록시 적용 범위에 포함되는지도 확인합니다.
- 화면을 잠근 뒤에만 실패하는 경우: Android의 백그라운드 실행과 배터리 제한을 확인하고, 화면을 잠그기 전후에 연결 로그가 계속 기록되는지 살펴보세요. 백그라운드 프로세스가 종료되는 문제를 해결하려고 서버 포트부터 변경하지 마세요.
4. 서버 주소, DNS, 포트 확인하기
여기서 확인할 것은 ‘노드 서버 도메인을 확인할 수 있는지’이지, 브라우저가 최종 접속하려는 웹사이트의 도메인을 확인할 수 있는지가 아닙니다. 두 도메인은 서로 다른 경로로 확인될 수 있습니다. 서버 주소 오타, 만료된 도메인 레코드, 현재 네트워크에서 연결할 수 없는 IPv6 주소만 반환되는 경우 모두 노드 연결 시간 초과로 나타날 수 있습니다.
| 점검 항목 | 확인 방법 | 결과 해석 시 유의사항 |
|---|---|---|
| 서버 주소 | 노드 정보를 기준으로 도메인 철자, 공백, 포트를 확인합니다 | 주소 입력란에 전체 웹 URL이나 전송 경로를 넣는 경우는 일반적이지 않습니다 |
| 도메인 이름 확인 | Resolve-DnsName으로 노드 도메인을 조회하고 A 및 AAAA 레코드를 비교합니다 | 시스템의 도메인 이름 확인이 성공해도 코어에서 사용하는 경로까지 정상이라는 뜻은 아닙니다 |
| 원격 TCP | Test-NetConnection으로 실제 노드 주소와 포트를 테스트합니다 | TCP 연결 확인에만 유효하며 프로토콜 핸드셰이크나 UDP 사용 가능 여부는 증명하지 않습니다 |
| 네트워크 비교 | 같은 기기와 설정을 유지한 채 네트워크를 바꿔 재테스트합니다 | 네트워크만 변수로 바꾸고 DNS와 전송 매개변수는 동시에 변경하지 마세요 |
PowerShell에서 값을 입력받으면 예시 도메인을 실제 노드 주소로 착각하는 일을 방지할 수 있습니다. 여기의 443은 원격 서버가 실제로 해당 포트를 수신하는 노드에만 적용됩니다. 포트가 다르면 명령의 숫자를 바꾸세요.
$server = Read-Host "노드 서버 도메인을 입력하세요"
Resolve-DnsName $server
Test-NetConnection -ComputerName $server -Port 443TcpTestSucceeded : True는 해당 주소의 TCP 포트에 연결할 수 있다는 뜻일 뿐입니다. 노드가 CDN을 사용한다면 CDN 엣지까지 연결된 것만 확인했을 수 있으며 원본 서버까지 검증한 것은 아닙니다. 네트워크 장비가 ICMP에 응답하지 않을 수 있으므로 Ping 실패만으로 노드가 오프라인이라고 판단할 수 없습니다.
5. TCP 연결 후 TLS 및 전송 매개변수 확인하기
TCP 연결은 성공하지만 프록시 요청이 계속 실패한다면 프로토콜 인증과 핸드셰이크 매개변수를 살펴보세요. 신뢰할 수 있는 원본 노드 정보를 기준으로 확인하고, 경험에 따라 모든 노드를 같은 전송 방식으로 바꾸지 마세요. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 설정의 실행 가능 여부는 프로토콜, 기능, 코어 버전에 따라 달라지므로 가져오기에 성공했다는 이유만으로 호환된다고 판단할 수 없습니다.
- 프로토콜 및 인증 정보: VMess 또는 VLESS 유형이 올바른지, 사용자 ID와 암호화 및 흐름 제어 설정이 서버와 일치하는지 확인하세요. 구독을 업데이트한 뒤 서버 설정이 바뀌었다면 이전 노드가 로컬 목록에 남아 있을 수 있습니다.
- TLS: TLS 사용 여부, 서버 이름 SNI, 인증서 대상 도메인, 서버가 요구하는 ALPN을 확인하세요. 연결 주소를 IP로 바꾸더라도 올바른 TLS 서버 이름은 유지해야 합니다. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요.
- WebSocket: 경로와 Host를 확인하세요. 예를 들어 경로 앞의
/와 대소문자도 일치 여부에 영향을 줄 수 있습니다. 리버스 프록시에도 해당 경로와 프로토콜 업그레이드 전달 설정이 필요합니다. - gRPC: serviceName이 서버 설정과 일치하는지 확인하고, 리버스 프록시가 해당 HTTP/2 전달을 지원하는지 살펴보세요. WebSocket 전달 설정을 그대로 적용하면 안 됩니다.
- REALITY: 서버에서 제공한 공개 키, shortId, 서버 이름 등의 항목을 확인하고 클라이언트와 코어가 해당 설정을 지원하는지 확인하세요. 일반 TLS 노드처럼 취급하지 마세요.
오류: connection refused
원인: 연결이 명시적으로 거부된 상태로, 대상 포트에서 리스닝하지 않거나 방화벽이 연결을 거부하는 경우가 흔합니다. 해결: 로그에 나온 주소가 로컬인지 원격인지 먼저 확인한 뒤 로컬 코어 또는 원격 리스너를 점검하세요. 노드가 만료됐다고 바로 단정할 수는 없습니다.
오류: i/o timeout
원인: 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 끝나지 않은 상태입니다. 연결 시도, 핸드셰이크, 응답 수신 중에 발생할 수 있습니다. 해결: 앞뒤 로그를 함께 살펴 시간 초과가 발생한 대상을 확인한 뒤 포트 테스트와 네트워크 비교를 진행하세요. 이 한 줄만으로는 어느 쪽 문제인지 알 수 없습니다.
오류: x509: certificate has expired or is not yet valid
원인: 현재 시간이 인증서 유효 기간에 포함되지 않습니다. 기기 시간이 잘못됐거나 서버 인증서가 만료됐을 수 있습니다. 해결: 먼저 시스템 시간을 동기화하세요. 문제가 계속되면 서비스 관리자가 인증서 유효 기간과 배포 상태를 확인해야 합니다.
오류: websocket: bad handshake
원인: WebSocket 업그레이드 과정에서 예상한 응답을 받지 못했습니다. 경로, Host 또는 리버스 프록시 설정이 일치하지 않는 경우가 흔합니다. 해결: 노드 항목과 진입점 설정을 대조하고, 해당 요청이 올바른 전달 경로로 들어오는지 서버 측에서 확인하세요.
로그에 나타날 수 있는 오류 일부입니다. 실제 문구는 코어와 버전에 따라 달라집니다. 로그 상세 수준을 잠시 높인 뒤 실패를 한 번만 재현하고 해당 시간대의 기록을 저장하세요. 작업이 끝나면 로그 수준을 원래대로 돌려 장기간 기록이 과도하게 쌓이지 않도록 합니다.
6. 마지막으로 서버 리스닝과 전달 경로 확인하기
서버 관리 권한이 없다면 클라이언트 버전, 실패 시간, 오류 일부, 네트워크별 테스트 결과를 관리자에게 전달하면 됩니다. 문제 해결을 위해 관리자 비밀번호를 요청하거나 보내지 마세요. Linux 서버에 접근할 수 있다면 리스닝, 프로세스 로그, 호스트 방화벽, 클라우드 인바운드 규칙 순으로 확인하세요.
sudo ss -lntp
sudo ss -lnup첫 번째 명령은 TCP 리스닝을, 두 번째 명령은 UDP 리스닝을 확인합니다. 노드 설정에 사용된 실제 프로토콜과 포트를 확인해야 하며 모든 노드가 TCP와 UDP를 동시에 수신해야 하는 것은 아닙니다. 앞단에 리버스 프록시가 있다면 외부 포트는 프록시 프로세스가 수신하고 코어는 내부 로컬 포트만 수신할 수 있습니다. 이 구성 자체는 문제가 아닙니다.
- 리스닝 위치 확인: 리스닝 주소가 루프백 주소인지 외부 공개 주소인지, 포트가 클라이언트 설정과 일치하는지 확인하세요. 컨테이너 환경에서는 포트 매핑과 프로토콜 유형도 점검해야 합니다.
- 관련 로그 확인: 실제 서비스 이름으로 서비스 상태와 최근 로그를 조회하고, 설정 로드에 실패한 뒤 이전 프로세스가 계속 실행 중인 것은 아닌지 확인하세요. 클라이언트에서 재테스트할 때 같은 시간대에 연결 또는 핸드셰이크 기록이 남는지 살펴봅니다.
- 두 단계의 허용 규칙 확인: 호스트 방화벽과 클라우드 보안 그룹을 각각 확인하고 필요한 프로토콜과 포트만 허용하세요. 점검을 위해 방화벽 전체를 끄지 마세요.
- 전달 경로의 뒷부분 확인: 진입점에서 요청을 받았지만 502, 504 또는 핸드셰이크 오류가 반환된다면 리버스 프록시와 코어 사이의 연결, 경로 일치 여부, 인증서, 업스트림 대상의 연결 가능성을 이어서 확인하세요.
판단: 진입점에 요청이 있으면 전달 경로의 뒷부분을 확인
같은 시간대의 진입점 로그에서 요청을 확인할 수 있다면 무작정 로컬 리스닝 포트를 바꾸기보다 인증, 리버스 프록시, 아웃바운드 경로를 추적하세요. 로그가 없다고 해서 트래픽이 도달하지 않았다고 단정할 수도 없습니다. 로그 수준과 기록 위치도 확인해야 합니다.
7. 같은 조건으로 재테스트하고 결과 정리하기
설정을 하나 변경할 때마다 같은 노드, 같은 대상, 같은 테스트 방법으로 다시 확인하세요. 시간 초과 값을 늘리면 대기 한도만 바뀔 뿐, 잘못된 포트나 TLS 매개변수는 해결되지 않습니다. 작은 요청은 성공하지만 다운로드나 특정 사이트만 실패한다면 대상 사이트, 라우팅, DNS, 경로 MTU로 범위를 좁혀 보세요. 바로 클라이언트를 다시 설치하지 마세요.
- 기록할 내용: 실제 테스트 시간과 시간대, 클라이언트 및 코어 버전, 연결한 네트워크, 실패 단계, 가장 최근 변경 사항을 적어 두세요.
- 최소한의 증거: 시작 결과, 로컬 리스닝 결과, 원격 포트 테스트 결과, 실제 요청 한 건과 관련된 로그를 저장하세요.
- 공유 전 민감 정보 삭제: 구독 링크, 사용자 ID, 액세스 토큰, 노드 공유 정보를 삭제하세요. 서버 주소는 문제 확인에 필요한 신뢰할 수 있는 대화에서만 제공하세요.
- 효과 없는 변경 중단: 증거가 원격 리스닝이나 서버 설정 문제를 가리킨다면 현재 재현 가능한 상태를 유지해 관리자에게 전달하세요. 로컬 변수를 계속 추가하지 마세요.
점검을 마쳤다고 볼 수 있는 기준은 목록의 지연 시간이 정상으로 돌아오는 것만이 아니라, 요청이 같은 경로를 따라 안정적으로 응답을 받는 것입니다. 나중에 다시 시간 초과가 발생하면 기록을 바탕으로 달라진 부분을 비교하세요. 모든 설정을 처음부터 다시 시도하는 것보다 원인을 찾기 쉽습니다.