TCPing은 서버 포트에 연결할 수 있는지 확인하고, 실제 연결 지연은 프록시 경로로 테스트 요청을 완료할 수 있는지 확인합니다. 다운로드 속도 테스트는 데이터를 계속 전송하는 성능을 측정합니다. 구독을 가져와 노드를 고르는 중이라면 먼저 연결할 수 없는 설정을 제외하고, 응답 시간을 비교한 다음 후보 노드의 다운로드 속도를 측정하세요.
세 가지 속도 테스트의 측정 범위: 포트·요청·지속 전송
클라이언트 서버 목록에 표시되는 ‘지연 시간’은 하나의 통일된 지표가 아닙니다. 같은 밀리초 단위라도 서버와 TCP 연결만 맺었을 수도 있고, 프록시를 통해 테스트 웹사이트에 접속했을 수도 있습니다. 수치를 비교하기 전에 어떤 테스트를 실행했는지, 테스트 대상이 같은지 확인하세요.
| 테스트 방식 | 주요 측정 범위 | 이 결과만으로 알 수 없는 것 |
|---|---|---|
| TCPing | 이 기기에서 설정된 서버 주소와 TCP 포트까지 연결하는 데 걸리는 시간. 일반적으로 연결 수립 시간을 측정합니다. | 프록시 인증이 올바른지, 대상 웹사이트에 접속할 수 있는지, 다운로드 대역폭이 충분한지 |
| 실제 연결 지연 | 지정한 노드를 통해 테스트 주소에 접속합니다. 일반적으로 프록시 연결과 HTTP 또는 HTTPS 요청 1회가 포함됩니다. | 모든 웹사이트에 접속할 수 있는지, 장시간 연결이 안정적인지, 지속 다운로드 속도가 빠른지 |
| 다운로드 속도 테스트 | 프록시를 통해 테스트 파일을 받아 전송한 바이트 수와 시간을 기준으로 처리량을 계산합니다. | 대화형 응답이 항상 빠른지, 시간대와 관계없이 속도가 일정한지, 모든 대상에서 속도가 같은지 |
실제 연결 지연의 측정 범위는 클라이언트 버전과 테스트 방식에 따라 달라집니다. DNS 조회, TLS 핸드셰이크, 연결 초기화가 포함될 수도 있고 기존 연결을 재사용할 수도 있습니다. ‘지정된 조건에서 요청 1회를 완료하는 데 걸린 시간’으로 이해하는 편이 정확합니다. 이 수치를 플랫폼을 초월해 통용되는 네트워크 왕복 시간으로 보아서는 안 됩니다.
TCPing 수치는 낮은데 웹페이지가 열리지 않는다면, 어느 단계에서 막힌 걸까?
예를 들어 설정에 TCP 포트 443이 지정되어 있다고 가정해 보겠습니다. TCPing이 성공했다는 것은 해당 주소의 포트가 TCP 연결을 받아들였다는 뜻일 뿐입니다. 이 포트가 리버스 프록시나 CDN 엣지에서 열려 있을 수도 있습니다. 이후 요청은 전송 계층 설정, 프록시 인증, 원격 서버의 아웃바운드 연결, 대상 웹사이트를 거쳐야 하므로 어느 단계에서든 실패하면 페이지가 열리지 않을 수 있습니다.
- 먼저 서버 항목을 확인하세요. 구독에 포함된 서버 주소, 포트, 사용자 ID가 서로 맞아야 합니다. 공유 링크에 표시된 이름을 서버 주소로 착각하지 말고, 포트를 임의로
443으로 바꾸지 마세요. - 다음으로 전송 매개변수를 확인하세요. WebSocket을 사용한다면 경로와 Host를 확인하고, TLS를 사용한다면 서버 이름과 기기의 시간을 확인하세요. VLESS 설정에서 REALITY를 사용하는 경우 서버에서 요구하는 공개 키와 서버 이름 등의 매개변수도 일치해야 합니다.
- 코어가 설정을 지원하는지 확인하세요. V2Ray와 Xray가 지원하는 기능은 완전히 같지 않습니다. 설정을 가져오는 데 성공했더라도 현재 코어가 모든 전송 방식과 보안 옵션을 지원한다는 뜻은 아닙니다. 시작 로그와 연결 오류를 확인하세요.
- 마지막으로 출구와 대상 웹사이트를 확인하세요. 노드 인증에 성공해도 원격 DNS, 출구 네트워크 또는 대상 웹사이트에서 문제가 생길 수 있습니다. 서로 다른 웹사이트 두 곳으로 확인하고, 한 곳의 결과만으로 결론 내리지 마세요.
로그의 connection refused는 보통 연결 대상이 연결을 거부했다는 뜻입니다. timeout은 지정된 시간 안에 작업을 완료하지 못했다는 의미일 뿐입니다. 로그에 나온 대상이 로컬 수신 주소인지, 프록시 서버인지, 최종 목적지인지 먼저 확인한 뒤 원인을 찾아보세요. 오류 문구 하나만 보고 진입 구간 문제를 노드 문제로 오해하기 쉽습니다.
판단 기준: 포트에 연결할 수 있다면 프로토콜과 요청 경로부터 확인
TCPing은 성공하지만 실제 연결이 계속 실패한다면 설정, 코어 로그, 테스트 주소부터 확인하세요. TCPing 결과로 노드를 계속 정렬할 필요는 없습니다. 요청 단계의 테스트를 통과한 뒤에야 포트 연결 시간이 낮은 노드끼리 비교하는 의미가 있습니다.
v2rayN과 Android에서 테스트하는 방법
v2rayN에서는 서버 목록에서 항목을 선택한 뒤 마우스 오른쪽 버튼 메뉴에서 ‘서버 TCPing 지연 시간 테스트’, ‘서버 실제 연결 지연 시간 테스트’, ‘서버 속도 테스트’ 등의 항목을 찾을 수 있습니다. 버전에 따라 띄어쓰기나 단축키가 달라지거나 테스트 하위 메뉴에 포함될 수 있으므로 기능 이름을 기준으로 찾으세요. 목록에 남아 있는 이전 결과를 이번 테스트 결과로 착각하지 마세요.
테스트 순서: 연결 가능 여부부터 확인하고 속도 측정
데스크톱: v2rayN
- 구독을 업데이트한 뒤 테스트할 항목을 선택하고 마우스 오른쪽 버튼 메뉴에서 실제 연결 지연 테스트를 실행하세요.
- 이번 테스트가 모두 끝날 때까지 기다린 다음 실패 항목과 테스트 시간을 기록하세요.
- 통과한 후보 항목의 속도를 하나씩 측정하세요. 여러 항목을 동시에 다운로드하면 대역폭을 서로 나눠 쓰게 됩니다.
- 활성 서버를 바꾼 뒤 브라우저로 자주 사용하는 웹사이트에 접속해 확인하세요.
Android: v2rayNG / v2flyNG
- 먼저 설정을 선택하고 연결을 시작한 뒤, 시스템 안내에 따라 VPN 연결 권한을 허용하세요.
- 메뉴에서 ‘실제 연결 테스트’ 또는 이에 해당하는 연결 테스트 항목을 찾으세요. 여러 항목을 한꺼번에 테스트하는 기능은 버전마다 다를 수 있습니다.
- v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 이전하기 전에 설정 지원 범위를 확인하세요.
- 테스트하는 동안 같은 Wi-Fi 또는 모바일 네트워크를 유지하고 네트워크를 전환하지 마세요.
두 클라이언트는 테스트 주소, 시간 초과 기준, 시간 측정 방식이 다를 수 있습니다. 각 클라이언트 안에서 결과를 비교하고, 데스크톱과 Android의 밀리초 수치를 합쳐 순위를 매기지 마세요.
클라이언트 내장 테스트는 선택한 항목에 테스트 연결을 직접 만들 수 있어 시스템 프록시를 거치지 않을 수 있습니다. 반면 브라우저는 시스템 프록시, 브라우저 자체 설정 또는 TUN 연결 여부에 따라 달라집니다. 따라서 내장 테스트가 성공해도 실제 앱 트래픽이 의도한 진입 경로를 이용하는지 확인해야 합니다. 브라우저 진입 문제를 해결하려고 구독 설정을 반복해서 수정하지 마세요.
다운로드 속도 확인법: 단위·측정 시간·동시 연결 조건
다운로드 속도 테스트는 일정 시간 동안 데이터를 받아들이는 성능을 측정하며, 단위로는 보통 MB/s, MiB/s 또는 Mbps를 사용합니다. 인터넷 요금제는 Mbps를 쓰지만 클라이언트는 초당 바이트 수를 표시할 수 있습니다. 수치가 약 8배 차이 난다면 회선 속도 제한을 의심하기 전에 대소문자와 단위를 확인하세요.
위 내용은 단위 환산 예시이며 실제 노드 측정 결과가 아니고 프로토콜 오버헤드도 포함하지 않습니다. 연결 준비 시간까지 측정하면 작은 파일의 평균 속도는 크게 낮아질 수 있습니다. 여러 연결로 동시에 다운로드하면 단일 연결보다 결과가 높게 나올 수도 있습니다. 순간 최고 속도 하나만 저장하는 것보다 테스트 방식을 기록하는 편이 유용합니다.
- 같은 파일과 측정 시간을 사용하세요. 한 번의 비교에서는 같은 테스트 주소와 파일 크기 또는 측정 시간을 적용하세요. 한쪽 파일만 CDN 캐시에서 제공되고 다른 쪽은 원본 서버에서 받아오는 상황을 피할 수 있습니다.
- 대역폭을 사용하는 다른 작업을 중지하세요. 시스템 업데이트, 클라우드 동기화, 다른 다운로드를 일시 중지하세요. 같은 네트워크의 다른 기기가 대역폭을 모두 사용해도 측정 결과가 낮아질 수 있습니다.
- 초기 최고 속도와 지속 속도를 구분하세요. 짧은 순간의 급격한 속도 상승이 장시간 다운로드 성능을 의미하지는 않습니다. 후반부에도 안정적으로 유지되는지, 자주 멈추는지 확인하세요.
- 데이터 사용량을 확인하세요. 속도 테스트는 실제 데이터를 전송합니다. 평균 10 MB/s로 10초 동안 측정하면 약 100 MB를 받게 됩니다. 테스트를 반복하기 전에 요금제 잔여량을 확인하세요.
노드 정렬 기준: 용도에 따라 두 단계로 선별
일반 웹 탐색과 API 요청은 안정적으로 응답을 완료하는지가 중요하고, 대용량 파일 전송은 지속 처리량이 더 중요합니다. 먼저 실제 연결 테스트로 사용할 수 있는 설정을 추린 다음, 용도에 맞춰 지연 시간이나 다운로드 속도를 비교하세요. TCPing은 진입 구간 문제를 찾는 데 유용하지만 최종 사용 경험을 평가하는 순위 기준으로는 적합하지 않습니다.
실제 연결 지연 우선
추천연속으로 실패하는 항목을 먼저 제외하고 동일한 테스트 조건에서 여러 차례 결과를 비교하세요. 간혹 빠르게 응답하더라도 나머지 테스트에서 시간 초과가 발생한다면 계속 사용할 수 있는 항목보다 낮은 순위로 두세요.
적합한 용도: 일반 웹 탐색, 짧은 요청, 기본 노드 선별
다운로드 속도로 2차 선별
연결 테스트를 통과한 후보 항목만 측정하세요. 지속 속도와 전송 중 멈춤 여부를 비교하고, 순간 최고 속도 한 번만 보고 노드를 자주 바꾸지 마세요.
적합한 용도: 대용량 파일 전송, 장시간 데이터 수신
TCPing으로 보조 진단
서버의 TCP 진입 포트에 연결할 수 있는지 확인합니다. 포트 연결은 빠르지만 요청이 실패한다면 프록시 설정과 이후 연결 경로를 확인하세요.
적합한 용도: 포트 연결 실패와 요청 단계 실패 구분
후보 항목마다 먼저 3회씩 테스트하고 성공 횟수와 대표 응답 시간을 기록하세요. 예를 들어 같은 테스트 주소에서 세 번 측정한 결과가 180, 195, 210밀리초라면 중앙값은 195밀리초입니다. 다른 항목이 한 번 80밀리초를 기록했지만 나머지 두 번 시간 초과가 발생했다면 최솟값만으로 더 낫다고 판단할 수 없습니다. 수치는 기록 방법을 보여 주기 위한 예시일 뿐 실제 노드 성능을 나타내지 않습니다.
실행 순서: 성공률 → 대표 지연 시간 → 지속 속도
먼저 여러 차례 요청을 모두 완료한 항목을 선택하세요. 응답 시간이 비슷하다면 실제 다운로드 용도에 따라 처리량을 비교하세요. 시간 초과는 실패로 따로 기록하고 평균을 계산할 때 0밀리초로 취급하지 마세요.
속도 테스트와 웹 사용 경험이 다른 이유: 자주 발생하는 네 가지 문제
실제 연결 테스트는 성공했는데 브라우저에서 페이지가 열리지 않나요?
먼저 v2rayN 트레이 메뉴의 ‘시스템 프록시’에서 ‘시스템 프록시 자동 설정’을 선택했는지 확인한 다음, 브라우저에 다른 고정 프록시가 설정되어 있지 않은지 살펴보세요. 클라이언트가 실제로 수신 대기 중인 포트도 확인하세요. 화면에 10808로 표시된다면 외부 앱에서도 해당 포트를 사용해야 하며, 다른 가이드에 나온 포트를 그대로 따라서는 안 됩니다. 그런 다음 라우팅에서 대상 트래픽이 예상한 아웃바운드로 전달되는지 확인하세요.
실제 연결 테스트만 시간 초과인데 자주 쓰는 웹사이트는 열리나요?
현재 버전의 설정에서 테스트 주소와 시간 초과 기준을 확인하고 테스트 대상에 실제로 접속할 수 있는지 점검하세요. 노드를 고정한 뒤 접속이 확인된 다른 웹사이트도 열어 보세요. 테스트 주소가 차단되었거나 응답 형식이 바뀌었거나 시간 초과 기준이 너무 짧으면 실패로 표시될 수 있습니다. 측정 수치를 정상으로 보이게 하려고 TLS 인증서 검증을 끄지 마세요.
다운로드는 빠른데 웹페이지 첫 화면이 느린 이유는 무엇인가요?
웹페이지는 여러 도메인, DNS 조회, 스크립트, 이미지로 이루어져 있어 한 번의 연속 다운로드와 다릅니다. 현재 노드를 유지한 채 다른 웹사이트도 확인하세요. 그런 다음 로그에서 느린 요청의 대상과 아웃바운드를 살펴보세요. 실제 연결 테스트는 설정된 테스트 주소만 확인하므로 웹페이지의 모든 리소스를 대표하지 않으며 UDP 앱의 사용 경험도 검증하지 않습니다.
낮에는 괜찮은데 밤에 속도가 떨어지면 프로토콜을 바꿔야 하나요?
먼저 노드, 네트워크, 테스트 주소, 테스트 방식을 고정하고 두 시간대의 결과를 각각 기록하세요. 여러 항목의 속도가 동시에 떨어진다면 로컬 대역폭을 사용하는 작업과 네트워크 혼잡부터 확인하세요. 한 항목만 계속 문제가 생긴다면 서버나 특정 경로를 살펴보세요. VMess와 VLESS는 프록시 프로토콜 이름이지 대역폭 등급이 아닙니다. 프로토콜 이름만으로 속도를 예측할 수는 없습니다.
간단한 기록만 남겨도 충분합니다. 날짜와 시간대, 네트워크 유형, 클라이언트 및 코어 버전, 테스트 주소, 성공 횟수, 대표 지연 시간, 다운로드 단위를 기록하세요. 로그를 공유해 도움을 요청하기 전에 구독 주소, 사용자 ID, 공유 링크의 인증 정보를 가리세요. 진입 구간과 라우팅을 더 확인하려면 고급 사용법을 참고하세요. 먼저 앱 트래픽을 올바른 진입 경로로 보낸 다음 어느 경로가 더 빠른지 비교하세요.