여러 VMess 및 VLESS 노드 중 어떤 측정 결과를 봐야 할지 모르는 사용자에게 적합합니다. ping은 기본 네트워크 경로, 실제 연결 지연은 프록시 요청 완료 속도, 다운로드 테스트는 지속 전송 성능을 판단하는 지표입니다. 노드를 고를 때는 실제 용도에 맞춰 세 가지 데이터를 함께 비교해야 하며, 숫자가 가장 작은 하나의 항목만 선택 기준으로 삼아서는 안 됩니다.
세 가지 속도 테스트는 서로 다른 구간을 측정합니다
측정값 해석
ping, 실제 연결 지연, 다운로드 테스트는 노드 목록에 함께 표시되지만 서로 다른 계층을 측정합니다. ping은 보통 ICMP Echo 요청을 보내 현재 기기와 서버 주소 사이의 네트워크 왕복 시간을 확인합니다. V2Ray 또는 Xray 프록시 세션을 시작하지 않으며 VMess와 VLESS의 인증 정보, TLS 핸드셰이크, 전송 경로, 프록시 출구도 검증하지 않습니다.
측정값 해석
실제 연결 지연 테스트는 클라이언트가 지정한 노드를 통해 실제 프록시 요청을 보냅니다. v2rayN 7.x의 일반적인 동작을 예로 들면 클라이언트가 코어를 시작하고 노드 설정을 읽은 뒤 TCP 또는 다른 전송 연결을 수립하고 프로토콜 인증을 수행한 다음 테스트 주소에 접속합니다. 테스트 성공 후 표시되는 밀리초 수치는 웹페이지를 열기 전 첫 요청이 기다리는 시간에 더 가깝습니다.
측정값 해석
다운로드 테스트는 연결이 수립된 후 일정량의 데이터를 계속 수신합니다. 왕복 지연뿐 아니라 서버 출구 대역폭, 회선 혼잡, TCP 혼잡 제어, 패킷 손실에 따른 재전송, 로컬 네트워크, 테스트 파일 크기의 영향도 받습니다. 한 노드는 실제 연결 지연이 180ms여도 150Mbps가 나올 수 있고, 다른 노드는 실제 연결 지연이 80ms여도 출구 속도 제한 때문에 12Mbps에 그칠 수 있습니다.
| 테스트 방식 | 주요 측정 대상 | 프록시 프로토콜 경유 여부 | 답할 수 있는 질문 |
|---|---|---|---|
| ICMP ping | 현재 기기와 서버 주소 사이의 네트워크 왕복 | 아니요 | 기본 경로에 도달할 수 있는가, 지터가 큰가 |
| 실제 연결 지연 | 연결 수립, 핸드셰이크, 인증 및 프록시 요청 | 예 | 웹페이지 첫 요청까지 얼마나 기다려야 하는가 |
| 다운로드 속도 테스트 | 연결 수립 후의 지속 처리량 | 예 | 대용량 파일과 동영상 전송 속도는 어떤가 |
ping이 매우 낮아도 노드가 느릴 수 있는 이유
측정값 해석
가장 흔한 오판은 ping이 낮은 순서로 정렬한 뒤 첫 번째 노드를 바로 선택하는 것입니다. 어떤 서버의 ICMP 왕복 시간이 24ms라면 이는 서버 주소가 현재 네트워크와 가깝다는 뜻일 뿐입니다. 프록시 요청은 TLS, WebSocket, 중계 진입점 또는 다른 출구 회선을 거칠 수 있으므로 실제 대상 서비스에 접속할 때의 경로가 ICMP 경로와 완전히 같다고 볼 수 없습니다.
측정값 해석
일부 네트워크는 ICMP 요청을 제한하거나 우선순위를 낮추며, 서버가 ICMP에 아예 응답하지 않는 경우도 있습니다. 이때 ping 시간 초과가 발생해도 VMess 또는 VLESS 포트에 연결할 수 없다는 뜻은 아닙니다. 반대로 ICMP 응답이 안정적이어도 구독의 포트, UUID, 전송 경로, Server Name 또는 Reality 설정이 올바르다는 보장은 없습니다. 이러한 설정 항목까지 확인하려면 실제 연결 테스트가 필요합니다.
측정값 해석
낮은 ping만으로는 패킷 손실 이후의 속도 저하도 알 수 없습니다. 지속 다운로드는 많은 데이터 패킷이 연속해서 도착해야 하므로 1~3%의 패킷 손실만으로도 재전송과 혼잡 윈도 축소가 발생할 수 있습니다. 짧은 ICMP 샘플에서는 30ms로 보여도 지속 전송 중에는 속도가 80Mbps에서 주기적으로 15Mbps까지 떨어질 수 있습니다. 웹페이지는 첫 화면이 빠르게 열리지만 이미지와 동영상은 느리게 로드되는 식입니다.
결론: 노드 정렬은 실제 연결 결과를 우선하세요
웹페이지 탐색, 메신저 사용, 빈번한 단기 연결이 목적이라면 먼저 실제 연결 시간 초과 노드를 제외한 뒤, 지연이 비슷한 노드끼리 지터와 다운로드 속도를 비교하세요. ICMP 수치 하나가 가장 낮다는 이유만으로 최종 노드를 선택해서는 안 됩니다.
실제 연결 지연에는 어떤 시간이 포함되나요
측정값 해석
실제 연결 지연은 단일 네트워크 왕복 시간이 아니라 여러 단계의 누적 결과입니다. 도메인 노드는 먼저 DNS 확인을 완료해야 하며, 이후 서버 포트에 연결하고 TLS 또는 Reality를 사용할 경우 해당 핸드셰이크를 수행합니다. 코어는 다시 VMess 또는 VLESS 인증을 처리한 뒤 프록시 출구를 통해 테스트 리소스를 요청합니다. 어느 한 단계에서든 재시도가 발생하면 최종 수치는 크게 늘어납니다.
측정값 해석
전송 조합에 따른 고정 오버헤드도 서로 다릅니다. VLESS와 VMess는 프록시 프로토콜이고 TCP와 WebSocket 등은 전송 설정에 해당하며, TLS와 Reality는 각각의 핸드셰이크와 연결 특성을 담당합니다. 프로토콜 이름만으로 빠르기를 판단할 수 없으며, 실제 결과는 서버 부하, 경로 품질, 설정 일치 여부, 테스트 시간대에 따라 달라집니다.
VLESS + TCP + Reality
- 주요 오버헤드
- TCP 및 Reality 핸드셰이크
- 인증 단계
- VLESS 사용자 식별자 검증
- 테스트 핵심
- 연속 3회 실제 연결 결과
- 이상 신호
- 시간 초과 또는 100ms를 넘는 수치 급변
구독을 가져온 뒤에는 서버 이름, 포트, Flow, Server Name, 공개 키와 짧은 식별자 사이의 대응 관계를 유지해야 합니다.
VMess + WebSocket + TLS
- 주요 오버헤드
- TCP, TLS 및 WebSocket 연결 수립
- 인증 단계
- VMess 사용자 정보 검증
- 테스트 핵심
- 첫 번째 결과와 이후 결과의 차이
- 이상 신호
- 경로 오류 또는 TLS 핸드셰이크 실패
도메인, 포트, Host, 경로와 TLS 매개변수는 함께 일치해야 하며, 어느 하나라도 잘못되면 실제 연결 시간 초과로 나타날 수 있습니다.
측정값 해석
첫 번째 테스트가 이후 테스트보다 느린 경우가 있습니다. 처음 실행할 때 DNS 조회, 코어 시작, 연결 예열이 포함될 수 있기 때문입니다. 더 신뢰할 수 있는 방법은 후보 노드를 연속 3회 테스트하고 첫 실행의 뚜렷한 오버헤드는 제외한 뒤 중앙값을 비교하는 것입니다. 예를 들어 결과가 210, 126, 132ms라면 210ms가 아니라 약 132ms를 대표값으로 보는 편이 적절합니다.
v2rayN과 Android 클라이언트에서 테스트하는 방법
측정값 해석
데스크톱에서는 노드를 일괄 비교하기 좋습니다. 구독을 가져오고 그룹을 업데이트한 뒤 로컬 네트워크가 안정적인지 확인하고 실제 연결 테스트를 실행하세요. 테스트 중에는 대용량 파일 다운로드나 시스템 업데이트를 함께 진행하지 마세요. 로컬 대역폭 경쟁으로 결과가 왜곡될 수 있습니다. 테스트 대상 자체의 응답이 불안정하면 여러 번 측정한 결과도 함께 흔들립니다.
- v2rayN 7.x 메인 창에서 같은 구독 그룹에 있는 후보 서버를 선택하세요. 한 번에 5~10개 노드만 고르면 동시 테스트로 인한 간섭을 줄일 수 있습니다.
- 「서버」 메뉴를 열고 「서버 실제 연결 지연 테스트」를 사용하세요. 세부 버전에 따라 서버 목록의 오른쪽 클릭 메뉴에서도 같은 이름의 테스트 항목을 찾을 수 있습니다.
- 지연 시간 열이 갱신될 때까지 기다린 뒤 시간 초과 또는 연결 실패로 표시된 노드를 삭제하거나 잠시 제외하세요. 그다음 수치가 낮은 세 항목을 두 번 더 반복 측정합니다.
- 「설정」→「매개변수 설정」으로 이동해 실제 연결 테스트 주소와 시간 초과 시간을 확인하세요. 테스트 주소는 매우 작은 응답 본문과 안정적인 HTTP 상태를 반환해야 하며, 파일 다운로드 시간이 지연 측정에 섞이지 않도록 해야 합니다.
- 후보 노드를 선택해 활성 서버로 지정하고 시스템 프록시를 켠 다음, 실제 브라우저 접속과 다운로드 작업으로 최종 확인하세요.
측정값 해석
v2rayN의 일반적인 로컬 SOCKS 수신 포트는 10808이며, 일부 설정에서는 HTTP 진입점이 10809를 사용합니다. 정확한 값은 「설정」→「매개변수 설정」의 로컬 수신 설정을 기준으로 확인하세요. 포트는 로컬 애플리케이션이 프록시에 연결할 때만 사용되며 노드 서버 포트가 아닙니다. 로컬 포트를 변경해도 원격 노드의 지연 시간은 줄어들지 않습니다.
측정값 해석
Android에서는 v2rayNG가 Xray 코어를 사용하고 v2flyNG가 v2fly 코어를 사용합니다. 두 클라이언트 모두 노드 목록에서 지연 시간 테스트를 실행할 수 있지만 메뉴 이름과 테스트 방식은 버전에 따라 달라질 수 있습니다. Wi-Fi와 모바일 네트워크 사이를 전환하면 기존 연결이 끊길 수 있으므로 네트워크를 바꾼 뒤에는 현재 설정을 다시 시작하고 재측정하세요. 전환 전 수치를 그대로 사용하지 마세요.
- 테스트 전에 대역폭을 계속 사용하는 다른 작업을 종료하고 화면을 켜 둔 상태로 유지하세요. 시스템이 백그라운드 네트워크 활동을 일시 중지하지 않도록 하는 것이 좋습니다.
- 같은 노드를 최소 3회 측정하고 중앙값을 기록하세요. 20ms, 180ms, 24ms라는 결과는 한 번의 뚜렷한 지터가 있었음을 의미합니다.
- 클라이언트를 비교할 때는 같은 네트워크, 같은 노드, 같은 시간대를 사용하세요. 가정용 광대역 결과와 모바일 네트워크 결과를 직접 함께 비교해서는 안 됩니다.
- 데스크톱에서는 성공하지만 Android에서 시간 초과가 발생한다면 먼저 구독이 같은 버전으로 업데이트되었는지 확인한 다음 코어 로그의 핸드셰이크와 DNS 정보를 점검하세요.
다운로드 속도 테스트를 실제 체감 속도로 환산하는 방법
측정값 해석
다운로드 테스트는 단위 시간에 얼마나 많은 데이터를 전송했는지 측정합니다. 테스트 도구는 보통 초당 메가비트인 Mbps를 사용하고, 브라우저 다운로드 표시줄은 초당 메가바이트인 MB/s를 사용하는 경우가 많습니다. 환산할 때는 8로 나눕니다. 80Mbps는 이론상 약 10MB/s, 100Mbps는 약 12.5MB/s입니다. 프로토콜 오버헤드, 재전송, 디스크 기록 때문에 실제 수치는 조금 낮아집니다.
측정값 해석
짧은 테스트는 연결 예열과 순간적인 급증을 장기 성능으로 오인하기 쉽습니다. 노드를 비교할 때는 최소 20~30초 동안 측정하고 평균 속도와 최저 속도를 함께 확인하세요. 예를 들어 어떤 노드가 처음 3초 동안 160Mbps를 기록한 뒤 45Mbps로 안정된다면, 이 노드는 160Mbps가 아니라 45Mbps 노드에 가깝습니다. 순간 최고치는 장시간 다운로드 성능을 대표하지 않습니다.
| 사용 상황 | 우선 지표 | 판단 기준 |
|---|---|---|
| 웹페이지 및 즉시 요청 | 실제 연결 지연, 지터 | 연속 3회 중앙값이 낮고 시간 초과가 없음 |
| 고화질 동영상 | 지속 다운로드 속도, 최저 속도 | 30초 그래프를 확인하고 최고치만 보지 않기 |
| 대용량 파일 전송 | 평균 처리량, 패킷 손실 및 안정성 | 장시간 속도가 주기적으로 0에 가까워지지 않음 |
| 원격 상호작용 | 실제 연결 지연, 지터, 패킷 손실 | 안정적인 120ms가 50~300ms 사이를 반복하는 연결보다 대체로 낫습니다. |
측정값 해석
노드 대역폭과 로컬 접속 대역폭도 구분해야 합니다. 로컬 광대역의 상한이 100Mbps라면 여러 노드가 모두 92~95Mbps로 측정될 때 병목은 이미 로컬 회선에 있을 가능성이 높습니다. 이를 근거로 노드 출구의 최대 대역폭을 판단할 수는 없습니다. 로컬 네트워크가 유휴 상태일 때 직접 측정한 속도가 500Mbps인데 프록시 사용 시 장기간 40Mbps에 그친다면 서버 출구, 회선 혼잡 또는 노드 속도 제한을 추가로 점검할 필요가 있습니다.
결론: 처리량은 안정 구간을 보고 순간 최고치는 보지 마세요
테스트를 30초까지 진행하고 마지막 20초의 평균값을 기록하세요. 평균 82Mbps, 최저 74Mbps인 노드가 최고 180Mbps를 기록했지만 후반에 8Mbps까지 반복해서 떨어지는 노드보다 지속 다운로드와 동영상 재생에 더 적합합니다.
반복 가능한 노드 선별 순서
측정값 해석
속도 테스트의 목적은 특정 수치가 가장 낮은 노드를 찾는 것이 아니라 반복 가능한 선별 절차를 만드는 것입니다. 먼저 설정이 작동하는지 확인하고 용도에 따라 범위를 좁힌 뒤 실제 작업으로 최종 검증하세요. 이렇게 하면 서버의 일시적인 부하, 테스트 주소의 변동, 로컬 네트워크 경쟁으로 인한 오판을 줄일 수 있습니다.
- 1단계: 연결 가능성 확인: 실제 연결 테스트를 실행해 인증 실패, 핸드셰이크 실패, 지속적인 시간 초과가 발생하는 노드를 제외합니다. ping이 시간 초과되어도 실제 연결에 성공한 노드는 유지할 수 있습니다.
- 2단계: 응답성 확인: 남은 노드를 연속 3회 테스트하고 중앙값과 최대 편차를 비교합니다. 중앙값 차이가 20ms 미만이라면 더 낮은 숫자만을 위해 자주 전환할 필요가 없습니다.
- 3단계: 처리량 확인: 상위 3개 후보 노드에서 30초 다운로드 테스트를 진행하고 평균 Mbps, 최저 Mbps, 중간에 멈춤이 발생하는지를 기록합니다.
- 4단계: 실제 작업 확인: 자주 사용하는 웹페이지를 열고 평소 시청하는 화질의 동영상을 재생하거나 실제 다운로드를 실행한 뒤 최소 5분간 관찰합니다.
- 5단계: 시간대별 재측정: 평일 혼잡 시간대와 한산한 시간대에 각각 한 번씩 측정합니다. 특정 노드가 저녁에만 뚜렷하게 느려진다면 낮 시간 결과를 그대로 사용하지 말고 실제 사용 시간에 맞춰 결정하세요.
측정값 해석
실용적인 기록은 다음처럼 작성할 수 있습니다. 노드 A는 실제 연결 중앙값 96ms, 30초 평균 62Mbps, 최저 55Mbps이고, 노드 B는 실제 연결 중앙값 148ms, 평균 118Mbps, 최저 103Mbps입니다. 웹 탐색에는 A를, 대용량 파일 다운로드에는 B를 우선할 수 있습니다. '가장 빠른 노드'는 작업 유형에 따라 달라지며 모든 상황에 통하는 단일 정답은 없습니다.
자주 발생하는 속도 테스트 문제와 해결 방법
ping은 시간 초과인데 노드는 정상적으로 연결되나요?
측정값 해석
서버 또는 중간 네트워크가 ICMP에 응답하지 않는 것일 수 있습니다. 실제 연결 테스트와 실제 프록시 요청을 기준으로 판단하고, 세 번의 테스트가 안정적인지도 확인하세요. ping 시간 초과만으로 노드를 삭제하지 마세요.
실제 연결 지연이 처음에는 500ms인데 이후에는 120ms뿐인가요?
측정값 해석
첫 번째 결과에는 DNS 조회, 코어 시작, 연결 예열이 포함될 수 있습니다. 연속 3회 테스트해 중앙값을 사용하세요. 매번 첫 번째 측정만 비정상적으로 느리다면 DNS 설정과 코어 로그를 확인합니다.
지연 시간은 70ms뿐인데 다운로드 속도가 왜 2MB/s에도 못 미치나요?
측정값 해석
70ms는 요청 응답이 빠르다는 뜻일 뿐입니다. 서버 출구, 로컬 대역폭, 저녁 시간대 혼잡, 패킷 손실을 추가로 확인하고 최소 30초 동안 지속 다운로드를 테스트하세요. 2MB/s는 약 16Mbps입니다.
같은 노드인데 v2rayN과 v2rayNG의 결과가 다른 이유는 무엇인가요?
측정값 해석
먼저 두 클라이언트가 같은 구독 항목, 같은 네트워크, 같은 시간대를 사용하는지 확인하세요. 그런 다음 테스트 주소, DNS, 코어 버전, 전송 매개변수를 점검합니다. 테스트 대상이 다르면 수치를 직접 비교할 수 없습니다.
일괄 속도 테스트 후 모든 노드가 함께 느려졌나요?
측정값 해석
동시 테스트로 로컬 연결이 가득 차거나 서버에 일시적인 부하가 발생했을 수 있습니다. 후보 노드를 5~10개로 줄이고 다른 다운로드 작업을 중지한 뒤 30초 간격으로 나누어 다시 측정하세요.
측정값 해석
마지막으로 간단한 원칙을 기억하세요. ping은 기본 경로를 확인하고, 실제 연결 지연은 전체 프록시 경로의 응답을 확인하며, 다운로드 테스트는 지속 전송 성능을 측정합니다. 세 결과는 서로 보완적이며 어느 하나만으로 노드 품질 전체를 설명할 수 없습니다. 같은 네트워크, 같은 테스트 대상, 같은 시간대와 같은 측정 시간을 사용해야 결과를 비교할 수 있습니다.