노드 지연 시간이 40ms라고 해서 150ms인 노드보다 웹페이지가 반드시 빨리 열리는 것은 아닙니다. 구독을 가져온 뒤 노드를 고르거나 테스트 시간 초과 원인을 찾으려는 사용자를 위해, 포트 연결 여부·프록시 요청 성공 여부·지속 전송 성능을 구분하는 방법을 설명합니다. 동일한 테스트 대상과 단일 노드 재검사, 로그 확인을 함께 활용해 숫자 하나만으로 전체 경로를 판단하지 마세요.
V2Ray 속도 테스트 세 가지는 각각 어디까지 측정할까
v2rayN은 데스크톱 GUI 클라이언트이고, v2rayNG는 Xray 코어를 사용하는 안드로이드 클라이언트입니다. 화면에 표시되는 테스트는 클라이언트가 실행하지만, 실제 연결에는 코어와 노드 설정, 대상 웹사이트도 영향을 줍니다. 버전에 따라 메뉴 이름과 측정 구간, 시간 초과 기준이 다를 수 있으므로 같은 열의 숫자끼리는 비교해도 클라이언트가 다른 결과를 단순 순위로 비교하기는 어렵습니다.
TCPing: 포트 연결 여부 확인
노드 주소의 TCP 포트에 연결을 시도하고 TCP 연결이 성립되는 시간을 측정합니다. VMess, VLESS, Trojan 인증 정보는 확인하지 않으며, 원격 서버에서 대상 웹사이트에 접속할 수 있는지도 알 수 없습니다.
용도: 여러 노드의 초기 점검, 포트 연결 거부나 시간 초과 원인 확인
실제 연결 지연: 프록시 사용 가능 여부 확인
권장노드 설정을 사용해 지정된 테스트 주소로 요청을 보내며, 프록시 연결과 대상 서버의 응답까지 확인합니다. 테스트에 성공했다면 해당 경로를 사용할 수 있다는 뜻으로, 포트만 확인하는 것보다 일상적인 웹 접속에 가까운 결과입니다.
용도: 평소 사용할 노드 선택, 프로토콜 설정과 프록시 출구 확인
다운로드 속도 테스트: 지속 처리량 확인
노드를 통해 테스트 파일을 내려받고, 수신 데이터량을 걸린 시간으로 나누어 속도를 계산합니다. 결과는 테스트 서버, 연결 수, 속도 제한 정책, 로컬 대역폭에도 영향을 받습니다.
용도: 대용량 파일을 받기 전 대역폭 비교, 지연 시간이 긴 노드의 처리량이 더 나은지 확인
여기서 ‘권장’은 일반적인 노드 선택 시 실제 연결 지연을 우선 참고하라는 뜻이지, 이 테스트 하나로 모든 것을 판단하라는 뜻은 아닙니다. 동영상 재생에는 지속 처리량과 변동 폭이 중요하고, 실시간 조작에는 응답 시간이 중요합니다. 실제 앱은 테스트 요청과 다른 경로를 사용할 수도 있습니다.
TCPing은 빠른데 실제 연결은 왜 시간 초과될까
TCPing은 기존의 ICMP ping과 다릅니다. 노드 설정에 TCP 포트 443을 사용한다고 가정하면, TCPing 성공은 보통 이 기기에서 해당 주소의 포트로 TCP 연결을 맺을 수 있다는 뜻에 그칩니다. 포트 뒤에는 프록시 서버뿐 아니라 앞단 전달 서버나 다른 프로그램이 대기 중일 수도 있습니다. 설정이 실제로 작동하는지는 프로토콜 통신까지 확인해야 알 수 있습니다.
- 서버 포트를 확인하세요. 구독에 기록된 포트를 테스트해야 합니다. 익숙하다는 이유로 무조건 443을 확인하면 안 됩니다. 포트가 변경됐는데 구독 정보가 갱신되지 않았다면 이전 포트의 결과는 참고할 수 없습니다.
- 프로토콜과 보안 설정을 확인하세요. VLESS 사용자 ID, TLS 서버 이름, REALITY 공개 키와 짧은 ID 등이 잘못된 경우 TCP 연결 이후에야 문제가 드러날 수 있습니다.
- 전송 계층 설정을 확인하세요. WebSocket 경로나 HTTP 호스트명이 서버 설정과 다르면 기본 포트 연결은 성공해도 이후 프록시 요청이 실패할 수 있습니다.
- 테스트 방식이 적합한지 확인하세요. UDP를 주로 사용하는 전송 방식은 TCP 포트 탐색만으로 작동 여부를 판단할 수 없습니다. TCPing 실패가 모든 유형의 프록시 전송 실패를 뜻하지는 않습니다.
마찬가지로 TCPing은 패킷 손실률을 측정하지 않습니다. 연결을 5회 시도해 모두 성공했더라도 그 5회가 성공했다는 뜻일 뿐, 경로의 패킷 손실이 0이라고 단정할 수는 없습니다. 다시 측정할 때는 성공 결과와 실패 횟수를 함께 기록하세요.
실제 연결 지연에는 무엇이 포함될까? 측정값이 매번 달라지는 이유
실제 연결 테스트는 프록시 설정을 사용해 테스트 URL에 접속합니다. HTTPS 대상에 요청을 보내는 과정에는 로컬 또는 원격 DNS 조회, 노드 연결, 프록시 인증, 대상의 TLS 핸드셰이크와 응답 대기 등이 포함될 수 있습니다. 어떤 과정이 측정 시간에 포함되는지는 클라이언트 구현, 연결 재사용 여부, DNS 캐시 유무에 따라 달라집니다.
따라서 실제 연결 지연은 ‘노드와 사용자 사이의 순수 네트워크 왕복 시간’도, 웹페이지 전체 로딩 시간도 아닙니다. 작은 응답을 반환하는 테스트 페이지는 데이터가 거의 필요하지 않습니다. 실제 웹페이지에서는 스크립트와 이미지, 다른 도메인의 리소스도 불러오므로 체감 속도가 다를 수 있습니다.
- 테스트 대상을 동일하게 유지하세요. 노드를 비교할 때 같은 URL을 사용하세요. 테스트 주소의 지역이나 CDN, 응답 방식이 바뀌면 결과는 더 이상 노드 차이만 반영하지 않습니다.
- 응답이 예상한 형식인지 확인하세요. 일부 테스트는 상태 코드나 유효한 응답을 확인합니다. 리디렉션, 인증 페이지, 대상 사이트의 속도 제한 때문에 테스트가 실패할 수 있습니다.
- 첫 결과와 이후 결과를 모두 기록하세요. 첫 연결은 더 느릴 수 있으며, 이후에는 DNS 캐시, 세션 재개, 연결 재사용으로 시간이 줄어들 수 있습니다. 가장 빠른 결과 하나만 골라서는 안 됩니다.
- 테스트 경로를 확인하세요. 실제 연결 테스트는 지정된 노드를 검사하지만, 탐색 설정과 DNS 처리 방식은 버전에 따라 다를 수 있습니다. 로그를 함께 확인하고, 브라우저에서 테스트 페이지를 직접 열어 프록시 테스트를 대신하지 마세요.
결론: 테스트 URL을 고정한 뒤 노드를 비교하세요
같은 노드가 테스트 주소 하나에서만 실패하면, 먼저 직접 접속 가능한 다른 소규모 HTTPS 응답 주소로 바꿔 다시 테스트하세요. 주소를 바꾼 뒤 성공한다면 노드를 바로 삭제하기보다 원래 주소의 DNS 조회와 응답, 접속 제한을 확인하세요.
다운로드 속도 MB/s와 Mbps 변환 방법
지연 시간은 밀리초로, 처리량은 보통 MB/s 또는 Mbps로 표시하며 두 단위 사이에 직접적인 환산 관계는 없습니다. 지연 시간이 180ms인 노드가 12MB/s로 계속 전송할 수도 있고, 60ms인 노드의 속도가 2MB/s에 그칠 수도 있습니다. 전자는 지연 시간에 민감한 작업에 적합하지 않을 수 있고, 후자는 대용량 파일 다운로드에 불리할 수 있습니다.
다음은 단위 환산 예시이며, 이 사이트의 실측 결과나 회선 성능을 보장하는 수치가 아닙니다. 십진 단위 기준으로 1바이트는 8비트입니다. 화면에 MiB/s라고 표시된다면 이진 단위로 별도 계산해야 합니다.
명목상 100Mbps인 인터넷 회선은 이론적으로 12.5MB/s에 해당합니다. 실제 사용 시에는 프로토콜 오버헤드와 네트워크 변동이 발생합니다. 다운로드 테스트의 병목은 노드가 아니라 테스트 서버일 수도 있습니다. 단일 연결과 다중 연결 테스트 결과도 구분해서 봐야 합니다.
- 로컬 대역폭을 함께 사용하지 않도록 백그라운드 다운로드와 시스템 업데이트, 클라우드 동기화를 먼저 일시 중지하세요.
- 후보 노드를 하나씩 테스트하세요. 여러 다운로드 테스트를 동시에 실행하면 대역폭을 나눠 쓰게 됩니다.
- 속도 테스트 전에 데이터 사용량을 확인하세요. 오래 테스트하면 실제 데이터가 소모되며, 안드로이드 기기에서 모바일 네트워크를 사용할 때는 특히 주의해야 합니다.
- 시작 순간의 최고 속도만 보지 말고 안정적으로 유지되는 구간을 확인하세요. 그런 다음 실제로 사용할 다운로드 서비스에서도 속도를 확인하세요.
v2rayN과 v2rayNG에서 다시 측정하는 순서
먼저 클라이언트와 코어 버전을 기록한 다음 테스트 설정을 확인하세요. v2rayN에서는 ‘설정’ → ‘매개변수 설정’에서 현재 버전에 제공되는 속도 테스트 관련 항목을 찾아 테스트 주소와 시간 초과 설정을 확인할 수 있습니다. 메뉴 위치는 버전에 따라 다릅니다. 더 낮은 수치를 얻으려고 테스트 조건을 자주 바꾸지 마세요.
재측정 방법: 소수의 노드를 먼저 추린 뒤 실제 앱에서 확인
데스크톱: v2rayN
- 서버 목록에서 후보 노드 3개를 선택하고, 마우스 오른쪽 버튼 메뉴에서 TCPing, 실제 연결 지연, 다운로드 속도 테스트 항목을 찾으세요.
- 먼저 실제 연결을 테스트하세요. 후보 노드마다 5회씩 측정해 실패 횟수와 중앙값을 기록합니다.
- 안정적인 후보를 하나씩 짧게 다운로드 테스트한 다음, 활성 서버로 설정해 웹 접속을 확인하세요.
안드로이드: v2rayNG
- 메인 화면 메뉴에서 실제 연결 테스트를 찾으세요. 노드 하나만 확인하려면 대상 설정을 선택하고 서비스를 시작합니다.
- 시스템 VPN 연결이 설정되었는지 확인한 다음 실제 앱을 열어 테스트하세요. 내장 테스트 성공이 모든 앱의 트래픽이 프록시를 통과한다는 뜻은 아닙니다.
- Wi-Fi와 모바일 네트워크를 바꿔 각각 결과를 기록하세요. 서로 다른 네트워크에서 측정한 값을 한데 묶어 순위를 매기지 마세요.
버전에 따라 세 가지 테스트가 모두 내장되어 있지 않을 수 있습니다. 다운로드 속도 테스트 메뉴가 없다면 트래픽이 현재 노드를 통과하는지 확인한 뒤 실제 파일을 내려받아 테스트하세요. 이름이 똑같은 버튼을 찾을 필요는 없습니다.
예를 들어 실제 연결 결과가 142, 149, 151, 158, 410ms로 5회 측정되면 중앙값은 151ms입니다. 다만 410ms로 크게 변동한 결과도 기록할 만합니다. 5회 중 2회가 시간 초과됐다면 나머지 3회만 평균 내고 안정적이라고 판단해서는 안 됩니다. 구독 노드를 바꾼 뒤에는 활성 노드가 실제로 바뀌었는지도 확인하세요. 새 노드를 측정했지만 브라우저는 이전 연결을 재사용하는 상황을 방지할 수 있습니다.
속도 테스트는 성공했는데 웹페이지가 열리지 않을 때: 경로별 점검
클라이언트 내장 테스트와 브라우저 연결은 각각 따로 확인해야 하는 경로입니다. 내장 테스트는 전용 테스트 방식으로 요청을 보낼 수 있지만, 브라우저는 시스템 프록시나 앱의 프록시 설정 또는 TUN 연결에 의존합니다. 시스템 프록시는 트래픽이 클라이언트로 들어오는 방식을, 라우팅 분기는 유입된 트래픽이 사용할 출구를 결정합니다.
- 로컬 연결 설정을 확인하세요. 예를 들어 현재 HTTP 프록시 주소가
127.0.0.1:10809라면 앱에서도 실제로 대기 중인 이 주소를 사용해야 합니다. 10809는 예시일 뿐 모든 버전의 기본 포트가 아니며, SOCKS 포트를 HTTP 포트로 입력해서도 안 됩니다. - 라우팅 규칙을 확인하세요. 테스트 주소가 프록시를 사용한다고 해서 실제 서비스의 도메인도 프록시를 사용한다는 뜻은 아닙니다. 도메인이 직접 연결 규칙에 해당하는지, 안드로이드 앱별 설정에서 대상 앱이 제외되어 있지 않은지 확인하세요.
- DNS를 확인하세요. 노드 서버 주소와 실제 서비스 도메인 모두 DNS 조회가 필요합니다. 로그에서 조회 오류와 연결 대상을 비교하세요. 브라우저에서 특정 도메인이 조회된다는 이유만으로 모든 DNS 문제를 배제할 수는 없습니다.
- 원격 서버와 대상 서비스를 확인하세요. 간단한 응답을 반환하는 테스트 사이트에 접속된다고 해서 모든 웹사이트에 접속할 수 있는 것은 아닙니다. 특정 서비스만 실패한다면 해당 서비스의 지역 제한과 출구 제한, 구체적인 오류 메시지를 확인하세요.
원인을 찾을 때는 한 번에 하나씩만 변경하고 변경 전후 결과를 저장하세요. 노드와 라우팅, DNS, 시스템 프록시를 한꺼번에 초기화하면 일시적으로 문제가 해결되더라도 원인을 파악하기 어렵습니다.
지연 시간 및 속도 테스트 FAQ
실제 연결 지연이 -1이면 노드를 바로 삭제해도 될까요?
아니요. 음수 값이나 시간 초과는 대개 이번 테스트가 성공하지 못했다는 뜻이지, 실제 지연 시간이 아닙니다. 먼저 해당 노드만 다시 측정하고 테스트 URL을 확인하세요. 이어서 로그에서 핸드셰이크 실패와 DNS 조회 실패, 대상 서버 시간 초과 여부를 확인한 뒤 실제 앱으로 접속해 보세요.
지연 시간이 가장 짧은 노드가 다운로드 속도는 왜 가장 느릴까요?
응답이 빠르다고 대역폭이 큰 것은 아닙니다. 후보 노드를 같은 출처의 다운로드로 하나씩 테스트하고 다른 트래픽은 중지한 뒤 안정 속도를 비교하세요. 지연 시간이 짧은 노드가 계속 2MB/s에 그치고 다른 노드가 8MB/s를 안정적으로 유지한다면 대용량 파일 작업에는 후자를 우선 고려할 수 있습니다.
PC와 안드로이드에서 같은 구독을 쓰는데 측정값이 크게 다른 이유는 무엇인가요?
먼저 같은 서버와 포트, 테스트 URL을 사용했는지 확인한 다음 두 기기를 같은 Wi-Fi에 연결하세요. 차이가 계속된다면 코어 버전과 DNS, IPv4·IPv6 경로, 클라이언트의 측정 방식도 확인해야 합니다. 어느 한 플랫폼이 무조건 더 느리다고 단정하지 마세요.
시간 초과를 5초에서 10초로 늘리면 노드가 더 빨라지나요?
아니요. 시간 초과를 늘리면 요청이 완료될 때까지 기다리는 시간만 길어질 뿐, 실제 소요 시간이 줄어들지는 않습니다. 느린 요청이 결국 성공하는지 확인할 때는 유용하지만, 정식 비교에서는 기준을 동일하게 유지하고 기존 시간 초과 기준을 넘긴 결과도 기록해야 합니다.