TCPing은 서버 포트를 빠르게 확인하고, 실제 연결 지연은 노드가 프록시 요청을 처리할 수 있는지 점검하며, 다운로드 속도 측정은 지속적인 전송 성능을 살펴봅니다. 지연 시간은 낮은데 웹페이지가 열리지 않거나, 지연 시간은 높은데 다운로드는 빠른 v2rayN 사용자에게 적합한 안내입니다. 먼저 테스트 조건을 통일하고 단계별로 점검한 뒤, 실제 용도에 맞는 노드를 선택하세요.
세 가지 속도 측정은 연결의 어느 구간을 확인할까
웹페이지에 접속할 때는 서버에 연결하는 것만으로 끝나지 않습니다. 먼저 기기에서 노드의 진입 지점에 접속하고, 프록시 코어가 프로토콜 인증과 전송 협상을 처리합니다. 그다음 노드가 대상 웹사이트에 연결하고 응답 데이터를 돌려보냅니다. TCPing, 실제 연결 지연, 다운로드 속도 측정은 각각 다른 구간을 확인하므로 측정값을 한데 놓고 순위를 매길 수 없습니다.
| 측정 방식 | 주요 측정 대상 | 알 수 있는 내용 | 직접 알 수 없는 내용 |
|---|---|---|---|
| TCPing | 기기에서 노드 주소와 포트로 연결하는 TCP 연결 | 진입 포트에 접속할 수 있는지, 연결에 대략 얼마나 걸리는지 | UUID가 올바른지, 프록시로 웹사이트에 접속할 수 있는지 |
| 실제 연결 지연 | 테스트 대상 노드를 통해 테스트 URL에 요청 전송 | 프록시 경로와 테스트 대상이 정상적으로 작동하는지 | 모든 웹사이트의 응답 속도, 대용량 파일 전송 속도 |
| 다운로드 속도 측정 | 노드를 거쳐 속도 측정 서버에서 데이터를 지속적으로 수신 | 해당 시간대와 대상 서버에서의 전송 속도 | 장기간 유지되는 최소 대역폭, 게임 지연 시간, 모든 앱의 사용 경험 |
실제 연결 테스트에는 상태 코드 204를 반환하는 URL처럼 응답 크기가 매우 작은 HTTP 요청이 자주 사용됩니다. 실제 프록시 요청을 한 번 실행하는 방식이지, 웹페이지 전체를 불러오는 테스트는 아닙니다. 측정 종료 시점, 연결 재사용, 시간 초과 처리는 클라이언트와 코어의 구현에 따라 달라집니다. 따라서 이 값을 브라우저에서 페이지가 완전히 열리는 데 걸리는 시간으로 단순 해석해서는 안 됩니다.
TCPing은 낮은데 노드를 사용할 수 없는 이유
TCPing은 보통 노드 설정에 지정된 서버 주소와 포트로 연결을 시도합니다. 노드 주소가 도메인 이름이라면 먼저 IP 주소를 확인해야 하며, 도메인 조회 시간이 측정값에 포함되는지는 구현에 따라 다릅니다. TCPing은 ICMP Ping이 아니며 서버가 ICMP 응답을 보내야 하는 것도 아닙니다. 서버에서 일반 Ping을 차단하더라도 TCP 포트 연결은 정상적으로 이루어질 수 있습니다.
예를 들어 진입 포트가 TCP 443인 VLESS 노드에서 TCPing 결과가 45ms라면, 진입 지점에서 TCP 연결을 허용했다는 뜻일 뿐입니다. 이후의 TLS 또는 REALITY 협상, VLESS 인증, 노드에서 대상 웹사이트로 나가는 연결까지 이 수치로 확인된 것은 아닙니다.
- 인증 오류: VMess 또는 VLESS의 UUID가 일치하지 않으면 TCP 연결은 될 수 있어도 프록시 요청은 실패할 수 있습니다.
- 전송 매개변수 오류: WebSocket 경로, Host 또는 TLS의
serverName이 일치하지 않으면 TCP 연결 이후에 문제가 드러날 수 있습니다. - 보안 계층 매개변수 오류: REALITY의 공개 키,
shortId또는 관련 설정이 일치하지 않는다면 TCPing을 계속 새로 고치기보다 코어 로그를 확인해야 합니다. - 측정 대상은 진입 지점: CDN을 사용하는 노드는 가까운 엣지 서버에 먼저 연결될 수 있습니다. 진입 지연 시간이 낮다고 해서 원본 서버로의 연결이나 이후 외부 연결도 빠르다는 뜻은 아닙니다.
실제 연결 지연: 밀리초보다 요청 성공 여부를 먼저 확인하세요
실제 연결 테스트에서는 테스트 요청이 선택한 노드를 통과합니다. 보통 기기에서 노드까지의 연결, 프록시 프로토콜 처리, 노드에서 테스트 대상까지의 연결, 응답 반환이 모두 포함됩니다. HTTPS 테스트 주소를 사용하면 대상 서버와의 TLS 핸드셰이크도 포함됩니다. DNS 캐시, 연결 재사용, 테스트 방식에 따라 측정 시간은 달라질 수 있습니다.
따라서 TCPing이 45ms이고 실제 연결이 260ms여도 모순은 아닙니다. 두 수치의 차이를 정확히 분리해 낼 수 있는 서버 처리 지연으로 볼 수 없으며, 단순히 빼서 노드 부하 때문이라고 단정해서도 안 됩니다. 테스트 대상의 위치, 노드의 외부 연결 경로, 핸드셰이크 횟수 등이 결과에 영향을 줄 수 있습니다.
TCPing으로 1차 확인
먼저 진입 연결을 확인해 여러 노드에 네트워크 또는 포트 문제가 있는지 빠르게 파악하세요. 밀리초가 가장 낮다는 이유만으로 주로 사용할 노드를 정하지 마세요.
적합한 경우: 노드가 많아 진입 지점 문제를 빠르게 점검해야 할 때
실제 연결 지연으로 선별
권장동일한 테스트 URL로 여러 번 측정하세요. 요청이 안정적으로 성공하고 지연 편차가 작은 노드를 우선 선택한 다음, 실제 웹사이트에 접속해 확인하세요.
적합한 경우: 웹 탐색, API 요청, 일상적인 노드 선택
다운로드 속도로 최종 확인
후보 노드 몇 개만 골라 지속적인 데이터 수신 성능을 테스트하세요. 데이터 사용량과 실제 용도를 고려해 구독의 모든 노드를 반복해서 최고 속도로 측정할 필요는 없습니다.
적합한 경우: 대용량 파일 전송, 동영상 버퍼링 성능 확인
실제 연결 시간 초과가 노드 전체의 작동 불량을 뜻하지는 않습니다. 테스트 주소에 접속할 수 없거나, 대상 서버가 특정 외부 연결을 제한하거나, DNS 조회가 실패했을 수 있습니다. 먼저 기존 주소의 측정 기록을 남기고, 안정적인 소용량 응답 주소로 바꿔 다시 테스트하세요. 매번 비교할 때마다 대상을 임의로 바꾸면 일관된 기준으로 순위를 비교할 수 없습니다.
다운로드 속도 측정: MB/s, Mbps, 순간 최고 속도 이해하기
다운로드 속도 측정은 일정 시간 동안 수신한 데이터의 양을 확인합니다. 병목은 가정용 인터넷, Wi-Fi, 노드의 공유 대역폭, 외부 연결 경로, 속도 측정 파일 서버 등 어디에서든 발생할 수 있습니다. 측정값은 전체 경로의 결과이지, 노드 서버만 따로 성능을 측정한 값이 아닙니다.
먼저 단위를 확인하세요. 10진법 기준으로 1 MB/s는 8 Mbps입니다. 인터넷 요금제는 보통 Mbps를 사용하고, 앱의 다운로드 화면은 MB/s 또는 MiB/s로 표시할 수 있습니다. 아래는 세 지표가 동시에 나타날 수 있음을 설명하기 위한 교육용 예시이며, 본 사이트의 실측 결과나 특정 노드의 성능 보장이 아닙니다.
- 지연은 낮지만 전송 속도도 낮음: 짧은 요청에는 빠르게 응답해도 장시간 연결에서는 속도 제한이나 공유 대역폭의 영향을 받을 수 있습니다.
- 지연은 높지만 전송 속도도 높음: 거리가 먼 경로에서는 왕복 시간이 길어도 연결이 이루어진 뒤에는 높은 전송 속도를 유지할 수 있습니다.
- 처음에는 빠르다가 느려짐: 순간 대역폭, 혼잡, 서버 정책이 원인일 수 있습니다. 순간 최고 속도만 기록하지 말고 안정적으로 유지되는 구간을 살펴보세요.
평균 속도가 8 MB/s이고 15초 동안 테스트한다면, 프로토콜 오버헤드를 제외하고 약 120 MB의 데이터를 받게 됩니다. 여러 노드를 테스트하면 사용량이 누적됩니다. 특히 사용량에 따라 요금이 부과되는 구독이라면 실제 연결 테스트로 후보를 좁힌 뒤 두세 개 노드만 속도를 측정하는 편이 좋습니다.
v2rayN에서 재현 가능한 테스트 절차 만들기
아래 내용은 노드 목록에서의 작업 흐름을 기준으로 설명합니다. 버전에 따라 마우스 오른쪽 버튼 메뉴에 ‘서버 지연 시간 테스트 Tcping’, ‘서버 실제 연결 지연 테스트’와 비슷한 이름이 표시될 수 있으며 설정 항목의 분류도 달라질 수 있습니다. 현재 화면에 표시된 내용을 기준으로 진행하세요. 테스트 전에 클라이언트와 코어 버전을 기록하고, 업그레이드 전후의 결과를 같은 데이터로 섞어 비교하지 마세요.
- 네트워크 조건 고정: 다른 다운로드, 클라우드 동기화, 시스템 업데이트를 일시 중지하세요. 유선 또는 동일한 Wi-Fi 네트워크를 선택하고 테스트 중에는 네트워크를 바꾸지 마세요.
- 테스트 설정 확인: ‘설정’ → ‘매개변수 설정’을 열어 현재 버전의 지연 테스트 주소, 속도 측정 주소, 시간 초과 및 동시 실행 관련 설정을 확인하세요. 실제 설정값을 기록하고, 별도의 속도 측정 메뉴에 설정이 있다면 해당 메뉴도 확인하세요.
- 소규모로 1차 선별: 노드 목록에서 테스트할 노드를 선택하고 마우스 오른쪽 버튼을 눌러 TCPing을 실행하세요. 그다음 같은 노드에 실제 연결 테스트를 실행하고 결과를 각각 기록하세요. 두 지연 시간 항목을 서로 대체해 사용하지 마세요.
- 세 차례 반복: 같은 테스트 대상으로 요청 성공 횟수와 지연 시간을 기록하세요. 예를 들어 결과가 180, 185, 620ms라면 중앙값은 185ms지만, 620ms로 나타난 편차도 기록에 남겨야 합니다.
- 전송 속도는 따로 측정: 후보 노드만 하나씩 다운로드 속도 테스트를 실행하세요. 측정 시간대, 지속 시간, 평균 속도를 기록하고 여러 다운로드 작업이 기기 대역폭을 나눠 쓰지 않도록 하세요.
- 실제 용도로 확인: 노드를 현재 노드로 설정한 뒤 실제 사용하는 웹사이트나 서비스를 열어 보세요. 내장 테스트가 성공해도 시스템 프록시, 앱 프록시, 라우팅 설정이 올바르다는 뜻은 아닙니다.
두 단계로 확인: 노드 품질과 사용 환경 구분하기
조건을 통제한 테스트 환경
- 테스트 URL, 네트워크, 측정 시간을 고정합니다.
- 먼저 소수 노드의 지연 시간을 확인한 뒤 하나씩 다운로드 속도를 측정합니다.
- 최저값만 고르지 말고 세 차례의 결과를 기록합니다.
일상적인 앱 사용 환경
- 평소 사용하는 시스템 프록시와 라우팅 설정으로 되돌립니다.
- 대상 앱이 실제로 선택한 노드를 통과하는지 확인합니다.
- 자주 사용하는 시간대에 웹페이지, 동영상 또는 다운로드를 다시 테스트합니다.
조건을 통제한 테스트는 노드 비교에, 일상 환경에서의 확인은 설정과 실제 사용 경험 점검에 쓰입니다. 두 방식은 서로 대체할 수 없습니다.
내장 테스트는 성공했는데 브라우저가 느릴 때: 프록시 경로 확인
v2rayN의 노드 테스트와 브라우저 접속이 완전히 같은 설정 경로를 따르지 않을 수 있습니다. 노드 테스트는 보통 테스트 대상 노드에 맞춰 연결을 설정하지만, 일상적인 앱 사용은 시스템 프록시, 앱 자체의 프록시 설정, routing 규칙, DNS 동작에도 영향을 받습니다. 특정 웹사이트가 규칙에 따라 직접 연결되도록 설정되어 있다면 노드를 바꿔도 접속 속도가 달라지지 않을 수 있습니다.
별도로 확인하려면 로컬 SOCKS 진입점을 명시할 수 있습니다. 아래 명령을 사용하기 전에 127.0.0.1:10808이 현재 사용 가능한 SOCKS 또는 호환 혼합 인바운드인지 확인하고, 화면에서 대상 노드를 선택해야 합니다. 10808은 예시 포트이며 모든 설치에서 사용할 수 있는 것은 아닙니다. 로컬 수신 포트가 다르면 명령의 주소를 먼저 바꾸세요.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://www.example.com/- 이 명령은
curl을 사용할 수 있는 Linux 및 macOS 터미널에서 실행할 수 있습니다. Windows PowerShell에서는curl.exe를 사용하고, 출력 대상/dev/null을NUL로 바꾸세요. socks5h는 대상 도메인 이름의 조회를 SOCKS 프록시 측에 맡긴다는 뜻이며, 로컬 DNS 조회 차이의 영향을 줄일 수 있습니다. 실제 조회 위치는 코어와 라우팅 설정에 따라 달라집니다.time_total은 이 명령을 시작한 시점부터 전송이 끝날 때까지 걸린 전체 시간입니다. v2rayN의 실제 연결 지연 항목과 같지 않으며 서버 처리 시간만을 나타내는 값도 아닙니다.- 예시 대상은 요청 확인용입니다. 결과를 비교하려면 같은 안정적인 대상을 계속 사용하세요. 응답이 작은 웹페이지의 결과로 대용량 파일 다운로드 대역폭을 추정하지 마세요.
프록시 진입점을 명시하면 시스템 프록시 적용 여부에 대한 의문은 해결할 수 있지만, 코어의 routing까지 자동으로 우회하지는 않습니다. 요청 경로가 의심된다면 접속 시 로그에 표시된 대상, 일치한 규칙, 외부 연결 태그를 함께 확인하세요. 로그를 공유하기 전에 구독 주소, 인증 정보 등 민감한 내용을 가리세요.
속도 측정 자주 묻는 질문: 증상별 점검 범위
TCPing은 수십 ms인데 실제 연결은 시간 초과됩니다. 노드를 바꿔야 하나요?
먼저 노드 목록에서 실제 연결 테스트를 다시 실행한 뒤 해당 시점의 코어 로그를 확인하세요. 인증 또는 핸드셰이크 오류가 있다면 UUID, TLS, REALITY, 전송 매개변수를 확인하세요. 테스트 주소에서만 실패한다면 안정적인 다른 주소로 다시 측정한 뒤 판단하세요.
모든 노드가 같은 시간대에 테스트에 실패하면 구독이 만료된 건가요?
먼저 테스트 대상을 정상 작동이 확인된 노드 하나로 줄이고 동시 실행 수를 낮추세요. 기기의 네트워크, 테스트 URL, 코어가 정상적으로 실행 중인지 확인하세요. 원인을 파악하기 전에는 구독 전체를 반복해서 삭제하고 다시 가져오지 마세요.
다운로드 속도는 빠른데 웹페이지는 왜 느린가요?
대용량 파일 전송과 짧은 연결을 여러 번 반복하는 작업은 부하 특성이 다릅니다. 먼저 실제 연결 지연을 여러 차례 측정해 편차를 살펴본 뒤 브라우저의 DNS, 라우팅, 웹사이트의 서드파티 리소스를 확인하세요. 같은 페이지를 이용해 다시 테스트하고 서로 다른 웹사이트의 로딩 시간을 비교해 노드를 판단하지 마세요.
측정 결과가 -1 또는 시간 초과로 표시되면 지연 시간이 매우 크다는 뜻인가요?
일반적으로 이런 결과는 지연 시간이 음수라는 뜻이 아니라 테스트가 성공하지 못했다는 뜻입니다. 시간 초과 설정과 로그를 확인한 뒤 따로 다시 측정하세요. 실패 표시 방식은 버전에 따라 다를 수 있으므로 상태 문구도 함께 확인해야 합니다. 정상적인 밀리초 값과 섞어 평균을 계산하지 마세요.
항상 지연 시간이 가장 낮은 노드를 선택해야 하나요?
먼저 성공률과 편차를 비교한 뒤 용도를 따져 보세요. 웹 탐색에는 실제 연결이 안정적인 노드를 우선 선택하고, 대용량 파일 전송에는 지속 전송 속도를 비교하세요. 자주 사용하는 시간대에 한 번 이상 다시 측정하고, 작동을 확인한 예비 노드도 남겨 두세요.
노드 선택 순서는 요청 성공 여부, 결과의 안정성, 실제 서비스 이용 가능 여부를 먼저 확인하고, 개별 측정값이 더 낮거나 높은지는 마지막에 비교하는 것입니다. 테스트 대상, 네트워크, 시간대, 단위를 기록해 두어야 속도가 느려진 원인이 노드인지 대상 서버인지 기기 환경인지 판단할 수 있습니다.