웹페이지 접속 여부를 확인하려면 프록시를 통한 실제 연결 요청을, 대용량 파일 다운로드 성능을 보려면 지속 처리량을 확인하세요. ICMP ping과 TCP 핸드셰이크는 연결 경로의 일부만 측정합니다. v2rayN이나 v2rayNG의 테스트 결과를 비교하는 사용자를 위해 측정 범위와 시간 초과의 의미, 동일한 대상·네트워크에서 반복 측정하는 방법을 설명합니다.
네 가지 테스트의 측정 범위
지연 시간은 특정 작업을 완료하는 데 걸리는 시간이고, 속도는 단위 시간당 전송되는 데이터량입니다. 클라이언트 목록에 표시되는 밀리초 값은 노드에 고정된 속성이 아닙니다. 테스트 대상, DNS 조회 결과, 연결 재사용 여부에 따라 결과가 달라질 수 있습니다. 비교하기 전에 열 이름의 ‘지연 시간’만 볼 것이 아니라 테스트 버튼이 실제로 무엇을 실행하는지 확인하세요.
| 테스트 | 주요 측정 대상 | 직접 확인할 수 없는 항목 |
|---|---|---|
| ICMP ping | 대상 호스트까지 ICMP 에코 패킷이 왕복하는 시간 | 프록시 포트 사용 가능 여부, 프로토콜 인증 성공 여부 |
| TCP 핸드셰이크 | 지정한 IP와 포트에 TCP 연결을 맺는 데 걸리는 시간 | TLS, VMess 또는 VLESS 설정의 정확성 |
| 실제 연결 지연 | 프록시를 통해 테스트 URL에 요청을 보내는 데 걸리는 시간. 측정 범위는 구현에 따라 다릅니다. | 모든 웹사이트에 접속할 수 있는지, 다운로드 속도가 계속 빠른지 |
| 다운로드 속도 테스트 | 지정한 경로로 데이터를 수신할 때의 유효 처리량 | 첫 요청의 응답 속도와 안정적인 상호작용 |
예를 들어 어떤 노드의 TCP 핸드셰이크가 45ms이고 실제 연결 요청은 260ms여도 모순이 아닙니다. 실제 연결 요청에는 프록시 프로토콜 핸드셰이크, 서버에서 대상 사이트로 연결하는 과정, 대상 사이트의 TLS 핸드셰이크와 응답 대기가 추가될 수 있습니다. 두 테스트는 측정 종료 지점이 다르므로 차이를 계산해 ‘암호화 오버헤드’로 볼 수 없습니다.
ICMP ping과 TCP 핸드셰이크: 연결 경로의 앞부분만 확인
시스템의 ping은 일반적으로 ICMP 에코 요청을 보냅니다. HTTP 또는 SOCKS 프록시를 설정해도 자동으로 해당 프록시를 통해 전송되지는 않습니다. 노드 도메인에 ping을 보내면 주로 로컬 네트워크에서 해당 도메인이 확인된 주소까지 연결되는지를 살펴봅니다. 도메인이 중계 진입점을 가리킨다면 측정 결과는 그 진입점까지의 경로를 나타낼 뿐, 최종 출구에서 대상 웹사이트까지의 전체 경로를 보여주지는 않습니다.
- ping은 시간 초과되지만 프록시는 작동함: 호스트나 경로상의 장비가 ICMP에 응답하지 않을 수 있습니다. 먼저 실제 서비스 포트를 테스트한 다음 프록시를 통한 요청을 보내세요.
- ping은 빠른데 웹페이지는 느림: 진입점이 가깝다고 해서 중계 경로, 출구 대역폭, 대상 사이트 응답까지 빠른 것은 아닙니다.
- TCP 핸드셰이크는 성공했지만 실제 연결은 실패함: 포트에서 서비스가 응답해도 UUID, TLS 서버 이름, 전송 경로 또는 프로토콜 매개변수가 잘못됐을 수 있습니다.
TCP 테스트는 노드 설정에 지정된 실제 포트를 대상으로 해야 합니다. 노드가 443 포트를 사용한다면 해당 주소의 443 포트를 테스트하세요. 같은 호스트의 80 포트로 대신할 수 없습니다. 설정된 전송 방식이 TCP가 아니라면 TCP 탐지 결과의 참고 가치가 더 낮아집니다. 원격 포트가 올바르고 핸드셰이크가 완료됐더라도 TCP 계층의 연결만 확인된 것이며, 애플리케이션 계층에서 프록시 설정을 받아들였다는 뜻은 아닙니다.
실제 연결 지연: 프록시를 통해 특정 URL에 요청
실제 연결 테스트는 일반적으로 커널이 테스트 대상 노드를 통해 HTTP 또는 HTTPS 테스트 주소에 접속하도록 합니다. 단순 포트 테스트보다 웹 이용에 가까운 결과를 얻을 수 있지만, ‘측정을 시작하는 시점과 끝나는 시점’은 클라이언트와 커널 구현에 따라 달라집니다. 응답 헤더를 받을 때까지 측정하는 구현도 있고, 연결 재사용의 영향을 받는 테스트도 있습니다. 따라서 클라이언트마다 실제 연결 결과의 측정 기준이 완전히 같다고 볼 수는 없습니다.
HTTPS 대상에 접속할 때는 서로 다른 용도의 TLS 연결이 두 번 사용될 수 있습니다. 하나는 노드 자체의 전송 보안을 위한 것이고, 다른 하나는 클라이언트와 대상 웹사이트 사이의 HTTPS 연결입니다. VMess와 VLESS는 프록시 프로토콜이며, TLS 사용 여부와 전송 방식은 노드 설정을 확인해야 합니다. 프로토콜 이름만으로 테스트 시간을 추정할 수는 없습니다.
테스트 URL은 응답 크기가 작고 안정적이며 예상 상태 코드가 명확한 HTTPS 주소를 선택하세요. 시간 초과가 노드를 완전히 사용할 수 없다는 뜻은 아닙니다. 대상 사이트가 특정 출구를 거부하거나 DNS 조회에 실패했거나, 테스트 구현에서 허용하지 않는 상태 코드를 반환했을 수 있습니다. 먼저 별도의 테스트 대상을 사용해 교차 확인한 다음 로그에서 연결, TLS, 응답 오류를 살펴보세요.
실제 연결 비교 조건
- 대상 프로토콜
- HTTPS, 전체 URL 기록
- 대상 포트
- 대개 443이며 URL 기준
- 반복 횟수
- 같은 노드에서 연속 5회 테스트
- 결과 기록
- 중앙값, 실패 횟수, 테스트 시간대
비교 실험을 위한 권장 사항이며 클라이언트의 기본 설정값은 아닙니다.
다운로드 비교 조건
- 대상 리소스
- 고정 URL의 대용량 파일 또는 지속적인 데이터 응답
- 연결 수
- 먼저 단일 연결을 테스트한 뒤 다중 연결은 따로 테스트
- 측정 시간
- 회당 약 20초, 안정적으로 유지되는 구간 기록
- 네트워크 조건
- 같은 네트워크를 사용하고 다른 다운로드는 일시 중지
속도 테스트는 데이터를 사용합니다. 모바일 네트워크에서는 먼저 데이터 잔여량을 확인하세요.
다운로드 속도: 처리량과 밀리초 지연은 서로 다른 지표
다운로드 속도는 로컬 접속 회선의 대역폭, 노드 속도 제한, 출구 혼잡, 대상 서버의 속도 제한, TCP 혼잡 제어의 영향을 함께 받습니다. 지연 시간이 낮으면 연결 설정과 상호작용에 유리하지만, 대역폭이 충분하다는 보장은 없습니다. 지연 시간이 높은 회선도 연결이 안정된 뒤에는 처리량이 높을 수 있습니다. 다운로드를 시작한 직후에는 연결 설정과 혼잡 윈도우 증가가 진행될 수 있으므로 순간 최고 속도만 잘라서 판단하지 마세요.
Mbps의 소문자 b는 비트, MB/s의 대문자 B는 바이트를 뜻합니다. 100Mbps를 8로 나누면 12.5MB/s입니다. 이는 프로토콜 및 회선 오버헤드를 제외한 환산값이며, 애플리케이션이 항상 이 속도를 내야 한다는 뜻은 아닙니다. 인터페이스에 MiB/s가 표시된다면 단위가 다르므로 데이터를 기록할 때 원래 단위를 유지하세요.
- 단일 연결 테스트: 일반적인 다운로드 한 건의 성능을 확인하기에 적합하며, 단일 연결 속도 제한과 왕복 지연 시간의 영향을 받기 쉽습니다.
- 다중 연결 테스트: 대역폭을 더 쉽게 채울 수 있지만 단일 연결의 속도 저하를 가릴 수 있으므로 단일 연결 결과와 직접 순위를 비교하면 안 됩니다.
- 테스트 중 웹페이지가 눈에 띄게 느려짐: 대역폭을 모두 사용하거나 대기열이 쌓였을 수 있습니다. 속도 테스트를 멈춘 뒤 지연 시간을 다시 측정해 유휴 상태와 부하 상태의 지연을 비교하세요.
v2rayN과 v2rayNG: 조건을 고정해 비교하기
클라이언트 메뉴는 버전과 인터페이스에 따라 바뀔 수 있습니다. 데스크톱 v2rayN에서는 서버 목록에서 노드를 선택하고 마우스 오른쪽 버튼 메뉴에서 ‘서버 실제 연결 지연 테스트’를 찾아보세요. 여러 노드를 일괄 테스트하기 전에 하나만 선택해 대상 주소와 로그를 확인하세요. Android용 v2rayNG에서는 메인 화면 오른쪽 위 메뉴에서 ‘모든 구성의 실제 연결 테스트’를 찾을 수 있습니다. 현재 버전에서 메뉴 이름이 다르다면 ‘실제 연결’ 기능인지 확인해 TCP 테스트를 전체 요청 테스트로 착각하지 않도록 하세요.
- 환경 기록: 클라이언트 버전, 커널 버전, 접속 네트워크와 시간을 기록하세요. 한 번은 Wi-Fi, 다른 한 번은 모바일 네트워크를 사용했다면 동일 조건 비교가 아닙니다.
- 테스트 대상 고정: 현재 버전의 테스트 주소 설정에서 URL을 확인하세요. 설정을 찾을 수 없다면 두 번 모두 같은 클라이언트와 같은 테스트 기능을 사용했는지 확인하세요.
- 동시 작업의 영향 제거: 동기화, 시스템 업데이트, 다른 다운로드를 일시 중지하세요. 로컬 대역폭이나 서버 리소스를 두고 경쟁하지 않도록 노드를 하나씩 테스트하세요.
- 반복하고 실패도 기록: 노드마다 5회 테스트하세요. 시간 초과를 0ms로 기록하거나 결과에서 삭제해서는 안 됩니다.
- 실제 사용 환경에서 확인: 노드를 선택한 뒤 평소 사용하는 웹사이트에 접속하고 테스트 파일을 따로 다운로드하세요. 클라이언트 내장 테스트는 별도의 임시 인바운드를 사용할 수 있어 시스템 프록시나 앱별 프록시 경로와 다를 수 있습니다.
수동으로 확인할 때 로컬에 HTTP를 지원하는 혼합 인바운드가 설정되어 있고 포트가 10808이라면, 명령줄 요청이 해당 인바운드를 명시적으로 통과하도록 할 수 있습니다. 이 포트는 예시이므로 현재 클라이언트의 수신 설정을 확인하세요. SOCKS 인바운드만 설정되어 있다면 HTTP 프록시 매개변수를 그대로 사용할 수 없습니다. 아래 명령은 경로 확인을 위해 본 사이트의 HTTPS 페이지에 접속하며, 해당 페이지를 일괄 속도 테스트 기준으로 사용하지 않습니다.
curl --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "HTTP=%{http_code} TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" https://v2ray-best.com/이 명령은 Linux 또는 macOS 터미널에서 사용할 수 있습니다. Windows에서는 curl.exe를 사용하고 /dev/null을 NUL로 바꾸세요. TTFB는 요청 시작부터 첫 바이트를 받을 때까지의 누적 시간이고, TOTAL은 요청이 끝날 때까지 걸린 시간입니다. 클라이언트의 실제 연결 측정 범위와 다를 수 있습니다. 로컬 프록시 포트에 연결하는 시간을 원격 노드까지의 TCP 지연 시간으로 간주해서도 안 됩니다.
지연 시간 결과를 읽는 방법
먼저 성공률을 확인하고, 다음으로 중앙값, 마지막으로 변동 폭을 살펴보세요. 아래는 결과를 설명하기 위한 예시이며 실제 노드 측정값이 아닙니다. 같은 대상을 다섯 번 테스트해 180, 190, 185, 920ms가 나왔고 한 번은 시간 초과됐다고 가정해 보겠습니다. 성공한 표본의 중앙값은 187.5ms지만, 5회 중 4회 성공하고 1회 실패했다는 점도 결론에 포함해야 합니다. ‘약 188ms’만 기록하면 사용 가능성 문제가 가려집니다.
| 관찰 결과 조합 | 우선 확인할 사항 | 다음 단계 |
|---|---|---|
| TCP는 빠르지만 실제 연결 시간 초과 | 프로토콜 매개변수, 대상 사이트, DNS 또는 출구 연결 문제 | 테스트 대상을 바꾸고 커널 로그 확인 |
| 실제 연결은 안정적이지만 다운로드가 느림 | 대역폭, 단일 연결 속도 제한, 대상 리소스 제한 | 리소스를 고정하고 단일 연결과 다중 연결 비교 |
| 유휴 상태에서는 빠르지만 다운로드 중 지연 시간 증가 | 대역폭 포화, 회선 대기열 적체 | 다운로드를 멈추고 다시 테스트한 다음 다운로드 속도 제한 시도 |
| 테스트는 성공했지만 특정 앱이 열리지 않음 | 앱이 프록시를 사용하지 않거나 라우팅이 다르거나 사이트별 제한이 있음 | 해당 앱의 프록시 진입점과 실제 아웃바운드 로그 확인 |
시간대가 달라도 동일한 조건을 유지하세요. 저녁의 혼잡 시간대와 오전의 한산한 시간대 차이가 노드 간 차이보다 클 수 있습니다. 동영상이나 대용량 파일 다운로드가 목적이라면 성공률이 안정적이고 지속 처리량이 충분한 회선을 우선하세요. 웹 탐색이나 원격 상호작용이 목적이라면 요청 지연 시간과 변동 폭을 더 중요하게 보세요. 하나의 숫자로 모든 사용 환경을 평가할 수는 없습니다.
자주 묻는 질문: 낮은 지연 시간, 시간 초과, 라우팅
ping이 되지 않아도 테스트를 계속해야 하나요?
네. 먼저 노드 설정을 기준으로 실제 서비스 포트를 확인한 뒤 실제 연결 테스트를 실행하세요. 실제 연결이 성공한다면 ICMP 응답이 없어도 해당 프록시 요청에는 문제가 없다는 뜻입니다. 이후 실제 웹페이지와 다운로드를 확인하면 됩니다. ping 응답을 받기 위해 프로토콜 매개변수를 바꿀 필요는 없습니다.
실제 연결은 100ms인데 웹페이지가 몇 초씩 걸리는 이유는 무엇인가요?
테스트는 작은 대상 하나에만 요청을 보내지만 웹페이지는 여러 도메인과 많은 리소스를 불러올 수 있습니다. 먼저 다운로드를 멈추고 브라우저 개발자 도구의 ‘네트워크’ 패널에서 느린 요청을 찾은 다음, 해당 도메인의 라우팅 아웃바운드와 DNS 조회 상태를 확인하세요. 테스트 URL의 속도가 모든 리소스 도메인의 속도를 나타내지는 않습니다.
v2rayNG 테스트는 성공했는데 특정 앱이 프록시를 사용하지 않는 이유는 무엇인가요?
시스템에서 VPN 연결 권한을 허용했는지 확인한 다음 v2rayNG의 ‘설정’에서 앱별 프록시 옵션을 열어 선택한 앱을 프록시로 보낼지, 선택한 앱을 우회할지 확인하세요. 저장한 뒤 인터페이스 안내에 따라 서비스를 재시작하고 대상 앱을 다시 열어 연결 로그를 살펴보세요. 내장 테스트 성공만으로 앱의 연결 경로까지 검증되지는 않습니다.
구독을 업데이트한 뒤 지연 시간이 달라졌습니다. 라우팅 설정도 초기화됐나요?
먼저 구독 업데이트로 노드 주소, 포트, 전송 매개변수가 바뀌었는지 확인한 다음 현재 선택된 노드를 살펴보세요. 구독은 주로 서버 설정을 업데이트하며, 일반적으로 로컬 라우팅 규칙을 직접 변경하지는 않습니다. 노드 이름이 같더라도 주소 조회 결과, 출구 부하, 테스트 시간대가 달라지면 결과에 영향을 줄 수 있습니다.
최종 선택 순서는 다음과 같이 정할 수 있습니다. 먼저 프록시 요청이 성공하는지 확인하고, 반복 측정한 지연 시간과 실패 횟수를 비교하세요. 다음으로 지속 처리량을 테스트하고 마지막으로 실제 앱에서 확인합니다. ICMP와 TCP 결과는 문제 범위를 좁히는 데, 실제 연결 테스트는 요청 경로를 확인하는 데, 다운로드 테스트는 대역폭을 살펴보는 데 적합합니다. 각 측정 범위를 구분해야 결과가 다른 이유를 올바르게 해석할 수 있습니다.