V2Ray 노드 품질을 비교하려는 사용자를 위해 ICMP ping, 실제 연결 지연 시간, 다운로드 속도 측정의 경로를 나누어 살펴보고 게임, 웹, 동영상, 대용량 파일 상황별 선택 기준을 정리합니다. 낮은 지연 시간 수치가 실제로 더 빠른 연결을 의미하는지 판단하고, 문제가 있는 노드를 정해진 순서로 재검사할 수 있습니다.
세 수치는 같은 구간을 측정하지 않습니다
노드 목록에 35ms, 118ms, 76Mbps가 동시에 표시되어도 이상한 일이 아닙니다. 밀리초는 한 번의 왕복이나 요청에 걸리는 시간을, Mbps는 단위 시간당 전송 데이터량을 나타냅니다. 앞의 두 수치는 대기 시간을, 마지막 수치는 지속 처리량을 보여 주므로 단위와 용도가 서로 다릅니다.
ICMP ping은 보통 시스템이 서버 주소로 직접 에코 요청을 보내 측정합니다. 패킷이 서버 네트워크 인터페이스에 도착해 응답을 받으면 측정이 끝납니다. 로컬 네트워크에서 서버 주소까지의 기본 왕복 시간과 패킷 손실은 확인할 수 있지만, 일반적으로 VMess, VLESS, 전송 계층 캡슐화, TLS 핸드셰이크, 프록시 출구를 통한 접속은 거치지 않습니다.
ICMP ping
내 PC에서 서버 주소까지의 기본 네트워크 왕복 시간을 측정합니다. 빠르게 실행할 수 있어 지리적 거리, 우회 라우팅, 명확한 패킷 손실을 1차로 확인하는 데 적합합니다.
적합한 용도: 지연 시간이 높거나 응답하지 않는 주소를 일괄적으로 제외할 때
실제 연결 지연 시간
추천클라이언트 코어와 노드 프로토콜, 프록시 출구를 거쳐 대상에 요청을 보내므로 평소 웹 페이지를 열 때의 대기 과정에 더 가깝습니다.
적합한 용도: 일상적인 상호작용과 웹 브라우징에 사용할 노드를 고를 때
다운로드 속도 측정
일정 시간 동안 데이터를 계속 전송하고, 전체 바이트 수와 소요 시간으로 처리량을 계산합니다. 결과는 보통 Mbps 또는 MB/s로 표시됩니다.
적합한 용도: 동영상 재생, 대용량 파일 다운로드, 지속적인 데이터 전송
실제 연결 지연 시간은 ping보다 더 긴 경로를 포함합니다. v2rayN과 Xray 코어를 사용하는 경우 요청은 로컬 프록시 진입점, 노드 프로토콜 핸드셰이크, TCP 또는 다른 전송 연결, 선택적 TLS 협상을 거친 뒤 서버 출구에서 테스트 주소에 접속합니다. 테스트 대상의 응답 속도, DNS 확인, 출구 회선 상태도 결과에 반영됩니다.
다운로드 속도 측정은 지속적인 전송 능력까지 이어서 측정합니다. 왕복 시간뿐 아니라 서버 제한 속도, 출구 대역폭, 로컬 인터넷 회선, 망 간 혼잡, TCP 혼잡 제어, 테스트 파일 출처에도 영향을 받습니다. 한 노드는 지연 시간이 160ms여도 100Mbps 처리량을 유지할 수 있고, 지연 시간이 45ms에 불과해도 지속 다운로드에서는 8Mbps만 나올 수 있습니다.
결론: 일상적인 노드 선택은 먼저 실제 연결 지연 시간을 확인하세요
웹 페이지를 빠르게 열거나 짧은 요청을 자주 보낼 때는 실제 연결 지연 시간이 안정적이고 실패율이 낮은 노드를 우선 선택하세요. 동영상이나 대용량 파일을 사용할 때만 지속 다운로드 속도의 우선순위를 높이면 됩니다.
ping은 낮은데 실제 연결 지연 시간은 높은 이유
가장 흔한 이유는 두 테스트의 종점이 다르기 때문입니다. ping은 서버 주소가 ICMP에 응답하면 끝나지만, 실제 연결 테스트는 서버에서 외부 대상까지 접속해야 합니다. 서버로 들어오는 회선이 양호하다고 해서 서버 출구에서 테스트 대상까지의 경로도 원활하다는 뜻은 아닙니다.
프로토콜 핸드셰이크도 고정적인 오버헤드를 추가합니다. TCP 연결 설정에는 보통 한 번의 왕복이 필요하고, TLS를 처음 협상할 때는 데이터를 더 주고받습니다. 노드가 WebSocket과 TLS를 사용한다면 실제 연결 테스트에서 수행할 단계가 단순한 ICMP 에코보다 많습니다. VLESS와 VMess 자체의 처리 시간은 대개 주요 병목이 아니며, 지역 간 왕복, TLS, 출구 혼잡이 차이를 더 크게 만들기 쉽습니다.
위 데이터는 동일한 네트워크 환경에서 기록한 설명용 사례입니다: Windows 11 24H2, v2rayN 7.12.5, Xray-core 25.6.8, 로컬 혼합 프록시 포트 10808. 78Mbps는 약 9.75MB/s이지만 브라우저나 다운로드 도구에 표시되는 실제 수치는 측정 주기와 프로토콜 오버헤드 차이도 포함합니다. 이 수치는 단위 간 관계를 설명하기 위한 것이며 노드 성능 기준이 아닙니다.
| 현상 | 일반적인 원인 | 재확인 방법 |
|---|---|---|
| ping은 낮지만 실제 연결은 높음 | 출구 경로 우회, 느린 TLS 핸드셰이크, 느린 테스트 대상 응답 | 테스트 대상을 바꾸고 실제 연결 테스트를 연속 3회 실행 |
| ping은 높지만 다운로드는 빠름 | 거리는 멀지만 회선이 안정적이고 사용 가능한 대역폭이 충분함 | 30초 이상 지속 다운로드 속도와 변동 폭을 관찰 |
| ping은 응답하지 않지만 프록시는 사용 가능 | 서버 또는 상위 네트워크가 ICMP에 응답하지 않음 | 실제 연결 테스트로 확인하고 시간 초과만으로 노드를 바로 삭제하지 않기 |
| 실제 연결은 낮지만 웹 페이지는 여전히 느림 | 로컬 라우팅 분기, DNS 또는 대상 사이트의 개별 혼잡 | 시스템 프록시, 라우팅 규칙, 코어 로그 확인 |
비교 가능한 노드 테스트 한 차례 진행하기
한 번 측정한 숫자보다 비교 가능한 조건을 만드는 일이 중요합니다. 한 노드는 이른 아침에 측정하고 다른 노드는 저녁 피크 시간에 측정해 비교하지 마세요. 테스트할 때는 기기, 접속 네트워크, 클라이언트 버전, 코어, 테스트 대상, 시간대를 고정하고 대역폭을 사용하는 동기화나 다운로드 작업은 일시 중지해야 합니다.
v2rayN 7.x에서는 먼저 비교할 노드를 선택한 다음 「서버」→「서버 실제 연결 지연 시간 테스트」를 사용하면 됩니다. 기본 네트워크 상태를 확인하려면 「서버」→「서버 지연 시간 테스트」를 사용할 수 있습니다. 세부 버전에 따라 메뉴 문구가 조금 다를 수 있지만, “지연 시간”과 “실제 연결 지연 시간”을 구분하고 두 열의 결과를 같은 지표로 취급하지 마세요.
- 먼저 「설정」→「매개변수 설정」에서 로컬 수신 포트가 충돌하지 않는지 확인하고 현재 사용하는 코어 유형을 기록하세요.
- 후보 노드 3~5개를 선택하고 실제 연결 지연 시간 테스트를 연속 3회 실행하세요. 각 측정 사이에는 약 10초 간격을 둡니다.
- 첫 번째 측정은 DNS 캐시가 비어 있거나 TLS 최초 협상 때문에 비정상적으로 튈 수 있으므로 제외하고, 두 번째와 세 번째 결과의 중앙값을 기록하세요.
- 연결 지연 시간 중앙값이 낮은 두 노드에 연결한 뒤, 동일한 테스트 파일을 각각 30~60초 동안 지속 다운로드하세요.
- 저녁 피크 시간에 한 번 더 반복하세요. 지연 시간과 속도가 모두 뚜렷하게 나빠진다면 시간대별 혼잡을 판단 기준에 포함해야 합니다.
추천 방법: 상호작용 지연 시간과 지속 처리량을 나누어 측정
웹 브라우징과 즉시 요청
- 실제 연결 지연 시간 중앙값을 우선 확인
- 시간 초과 횟수와 결과 변동 폭 기록
- 동일한 프로토콜과 동일한 전송 방식으로 비교
동영상과 대용량 파일
- 최소 30초 이상 지속 속도 측정
- 최저 속도와 평균 속도를 함께 확인
- 실제 사용하는 시간대에 재측정
먼저 실제 연결 지연 시간으로 후보를 좁힌 다음 지속 다운로드로 최종 노드를 결정하면, 짧은 측정에서 나온 우연한 수치 때문에 잘못 판단하는 일을 줄일 수 있습니다.
테스트 중에는 라우팅 모드도 고정해야 합니다. 브라우저의 다운로드 주소가 규칙에 따라 직접 연결로 분류되면 측정값은 노드 처리량이 아니라 로컬 인터넷 회선 속도가 됩니다. v2rayN 코어 로그에서 요청이 프록시 아웃바운드로 처리되었는지 확인하거나, 잠시 전역 프록시 모드로 비교한 뒤 테스트가 끝나면 기존 분할 라우팅 설정으로 되돌릴 수 있습니다.
평균값, 지터, 패킷 손실을 함께 보는 방법
최저값만 보면 우연히 빠른 노드를 고르기 쉽습니다. 한 번 48ms가 나왔다고 이후 요청도 계속 48ms를 유지하는 것은 아닙니다. 결과가 48, 51, 236, 55, 420ms라면 평균값은 급격한 튐 때문에 높아지지만 중앙값은 여전히 55ms에 가깝습니다. 이때 중앙값은 평소 상태를, 최댓값과 산포는 끊김 위험을 보여 줍니다.
상호작용이 많은 애플리케이션은 지터에 민감합니다. 웹 페이지 로딩은 여러 연결과 요청으로 이루어지므로 지연 시간이 가끔 수백 밀리초까지 튀면 일부 리소스가 한참 나타나지 않을 수 있습니다. 동영상 버퍼링은 지터의 일부를 흡수할 수 있어 지속 처리량에 더 의존하며, 실시간 음성 통화와 원격 조작은 안정적인 지연 시간과 패킷 손실을 더 중요하게 봅니다.
- 중앙값: 여러 결과를 정렬한 뒤 가운데 값을 취한 것으로, 현재 시간대 노드의 대표적인 지연 시간을 나타내는 데 적합합니다.
- 지터: 연속된 결과의 변화를 확인합니다. 대부분의 결과 차이가 15ms 이내라면 40~300ms 사이를 반복해서 오가는 경우보다 일반적으로 안정적입니다.
- 패킷 손실: ping 10회 중 1회가 손실되면 패킷 손실률은 10%입니다. 평균 지연 시간이 낮더라도 패킷 손실이 뚜렷하면 재전송이 발생해 실제 속도가 떨어집니다.
- 시간 초과율: 실제 연결 테스트에서 시간 초과가 연속으로 발생한다면 전체 프록시 경로에 실패가 있다는 뜻이며, 한 번 성공한 최저값보다 참고 가치가 높습니다.
결론: 중앙값과 실패 횟수를 기록하세요
각 후보 노드는 최소 3회 측정하세요. 두 노드의 중앙값 차이가 10ms에 불과하더라도 한 노드에서 2회 시간 초과가 발생했다면, 시간 초과가 없고 변동이 작은 노드를 우선 선택하는 편이 좋습니다.
ICMP 패킷 손실을 프록시 데이터 손실과 바로 같은 것으로 볼 수는 없습니다. 일부 네트워크는 ICMP 응답의 우선순위를 낮추지만 TCP 트래픽은 정상적으로 전송할 수 있습니다. ping에서 패킷 손실이 발생해도 실제 연결이 안정적이라면 다운로드와 실제 접속을 계속 관찰하고 ICMP 하나만으로 결론 내리지 마세요.
사용 시나리오별로 어떤 수치를 우선 볼까
웹 브라우징, 검색, API 요청은 짧은 연결이나 짧은 트랜잭션이 많이 발생하므로 대기 시간의 비중이 큽니다. 실제 연결 지연 시간이 300ms에서 100ms로 줄어드는 변화가 다운로드 속도가 80Mbps에서 100Mbps로 늘어나는 변화보다 체감하기 쉬운 경우가 많습니다. 이런 상황에서는 먼저 시간 초과 노드를 제외한 뒤 실제 연결 지연 시간 중앙값을 비교하세요.
고화질 동영상과 대용량 파일 전송은 안정적인 처리량에 더 의존합니다. 지연 시간이 시간 초과를 자주 일으킬 정도로 높지만 않다면 180ms·80Mbps 노드가 60ms·12Mbps 노드보다 지속 다운로드에 적합할 수 있습니다. 환산할 때 8Mbps는 이론상 약 1MB/s, 80Mbps는 약 10MB/s이며 실제 속도는 프로토콜 오버헤드로 조금 낮아질 수 있다는 점에 유의하세요.
- 일반 웹 페이지: 실제 연결 지연 시간을 우선하고, 다음으로 변동 폭과 시간 초과율을 확인합니다.
- 원격 터미널: 안정적인 지연 시간을 우선하며, 지속 대역폭 요구량은 보통 낮습니다.
- 동영상 재생: 지속 다운로드 속도를 우선하고, 저녁 피크 시간의 최저 속도도 확인합니다.
- 대용량 파일 전송: 평균 처리량을 우선하며, 테스트 시간은 60초 이상으로 늘리세요.
- 구독 목록 일괄 1차 선별: 먼저 ping으로 빠르게 확인한 뒤 후보 노드에 실제 연결 테스트를 실행합니다.
노드 프로토콜도 비교 가능한 조건으로 맞춰야 합니다. VLESS 노드와 VMess 노드는 지역, 전송 방식, 출구가 서로 다를 수 있으므로 수치 차이를 단순히 프로토콜 이름 탓으로 볼 수 없습니다. 프로토콜은 연결 형식과 기능을 결정하지만, 실제 지연 시간은 주로 물리적 거리, 통신사 라우팅, 혼잡, 서버 부하의 영향을 받습니다.
v2rayNG의 테스트 결과도 Android 기기의 현재 네트워크 상태에 영향을 받습니다. 무선 신호 변화, 모바일 네트워크 전환, 백그라운드 다운로드가 결과를 바꿀 수 있습니다. 데스크톱 v2rayN과 Android v2rayNG는 같은 구독을 사용하더라도 각각 테스트해야 하며, 한 기기에서 나온 밀리초 수치를 다른 기기에 그대로 적용하지 마세요.
지연 시간 테스트에서 자주 묻는 질문
ping이 시간 초과로 표시되면 노드가 이미 만료된 것인가요?
반드시 그렇지는 않습니다. 먼저 v2rayN에서 「서버」→「서버 실제 연결 지연 시간 테스트」를 실행하세요. 실제 연결 결과가 나오고 실제 웹 페이지도 열리는 경우라면, 보통 서버나 중간 네트워크가 ICMP에 응답하지 않는 것입니다.
첫 번째 실제 연결 테스트가 항상 더 느린 이유는 무엇인가요?
첫 번째 측정에는 DNS 조회, 코어 시작, TCP 최초 연결 설정, TLS 최초 협상이 포함될 수 있습니다. 3회 연속 측정한 뒤 중앙값을 확인하세요. 최저값만 남기거나 첫 번째 결과만으로 순위를 정하지 마세요.
지연 시간은 40ms인데 다운로드 속도가 왜 2MB/s밖에 안 나오나요?
40ms는 요청 왕복이 빠르다는 뜻일 뿐이며, 2MB/s는 약 16Mbps입니다. 병목은 서버 제한 속도, 출구 대역폭, 망 간 혼잡, 테스트 소스에 있을 수 있습니다. 동일한 파일을 다른 노드로 다운로드해 병목이 노드에 따라 이동하는지 확인해야 합니다.
속도 측정 중 시스템 프록시를 켜야 하나요?
v2rayN 내장 실제 연결 테스트를 사용하면 클라이언트가 해당 노드를 통해 테스트를 실행합니다. 브라우저나 다운로드 도구로 측정할 때는 시스템 프록시가 활성화되어 있는지 확인하고, 코어 로그에서 테스트 요청이 실제로 프록시 아웃바운드로 들어갔는지 검증해야 합니다.
구독을 업데이트한 뒤 어떤 수치로 정렬해야 하나요?
먼저 실제 연결 지연 시간을 일괄 측정하고, 계속 시간 초과가 발생하는 설정은 삭제하거나 비활성화하세요. 그런 다음 지연 시간이 낮은 후보를 대상으로 지속 다운로드를 측정합니다. 일상적인 웹 사용에는 안정적인 실제 연결 지연 시간을, 대용량 파일에는 실제 처리량을 기준으로 선택하세요.
최종 판단은 실제 사용 경로로 돌아가야 합니다. ping은 빠른 진단 도구이고, 실제 연결 지연 시간은 전체 프록시 요청의 대기 시간을, 다운로드 속도 측정은 지속적인 전송 능력을 보여 줍니다. 세 수치는 각각 “기본 네트워크가 얼마나 먼가”, “프록시 요청에 얼마나 걸리는가”, “장시간 얼마나 많은 데이터를 전송할 수 있는가”에 답하며, 어느 하나도 다른 둘을 대신할 수 없습니다.