2026-10-03 · 심화 원리 · 약 10분

V2Ray 노드 핑 테스트 방법: TCPing·실제 연결 지연·다운로드 속도 차이

클라이언트의 세 가지 속도 측정 방식, 즉 TCP 연결 시간, 프록시 연결 전체의 응답 시간, 실제 다운로드 속도를 비교합니다. 측정 결과를 제대로 읽고 숫자 하나만 보고 노드를 고르는 실수를 줄여 보세요.

핵심 내용

TCPing은 노드의 접속 지점에 TCP 연결을 맺을 수 있는지 확인합니다. 실제 연결 지연은 프록시 경로로 지정한 테스트 대상에 접속되는지 검증하고, 다운로드 속도 테스트는 지속적인 전송 성능을 측정합니다. v2rayN, v2rayNG, v2flyNG 사용자를 위해 테스트 범위와 메뉴 조작부터 결과 기록과 문제 진단까지 살펴보고, 연결 여부를 먼저 확인한 뒤 응답 속도를 비교하고 마지막으로 전송 속도를 측정하는 노드 선택 절차를 안내합니다.

세 가지 속도 측정 방식은 연결 경로의 어디까지 확인할까?

클라이언트 목록에 표시되는 밀리초 값은 같은 방식으로 측정한 경우에만 비교할 수 있습니다. TCP 연결에 성공해도 VMess 또는 VLESS 인증까지 통과했다는 뜻은 아닙니다. 테스트 페이지가 빠르게 열려도 대용량 파일을 계속 빠르게 전송할 수 있다는 보장은 없습니다. 먼저 메뉴에서 어떤 테스트를 실행했는지 확인한 다음 결과를 살펴보세요.

TCPing: 노드 접속 확인

노드 주소와 포트에 TCP 연결을 시도하고, 보통 연결이 성립하기까지 걸린 시간을 측정합니다. 시스템의 ICMP ping과는 다르며 프록시 프로토콜, 계정 설정, 노드 출구까지 검증하지는 않습니다.

사용 목적: 접속 포트에 연결할 수 없는 설정을 한꺼번에 걸러내어 이후 테스트 대상을 줄일 때 적합합니다.

실제 연결 지연: 프록시 요청 확인

권장

테스트할 설정과 코어를 통해 지정한 대상에 요청을 보냅니다. 측정 시간에는 노드 연결, 프록시 핸드셰이크, 대상 주소 확인, 대상 응답이 포함될 수 있습니다. 구체적인 측정 구간은 클라이언트 구현에 따라 다르므로 단순한 네트워크 왕복 시간으로 볼 수 없습니다.

사용 목적: 웹 접속에 쓸 노드를 일상적으로 선별하고 프로토콜 설정과 요청 경로가 정상인지 확인할 때 적합합니다.

다운로드 속도 테스트: 지속 전송 성능 확인

테스트할 설정을 통해 테스트 데이터를 다운로드하고 전송한 바이트 수와 걸린 시간을 바탕으로 속도를 계산합니다. 결과는 다운로드 서버, 회선 혼잡, 서버 속도 제한, 테스트 시간, 기기 처리 성능에 모두 영향을 받습니다.

사용 목적: 사용 가능한 노드 몇 개의 대용량 파일 전송 성능을 비교할 때 적합합니다.

예를 들어 노드 접속 포트가 TCP 443이라면 TCPing 성공은 해당 주소의 443 포트에 그 시점에 연결할 수 있었다는 뜻일 뿐입니다. UUID가 틀리거나 WebSocket 경로가 맞지 않아도 접속 지점에서 응답하면 낮은 밀리초 값이 나올 수 있습니다. TCP 이외의 전송 방식을 쓰는 설정은 TCPing 실패만으로 전체 설정을 사용할 수 없다고 판단해서도 안 됩니다.

v2rayN 및 Android 클라이언트에서 속도 측정하기

먼저 구독을 업데이트한 다음 소수의 설정을 골라 테스트하세요. 버전과 화면에 따라 메뉴 이름은 조금씩 다를 수 있습니다. 아래는 일반적인 중국어 인터페이스를 기준으로 설명하며, 실제 메뉴에 표시되는 ‘Tcping’, ‘실제 연결 지연’, ‘속도’ 등의 작업명을 확인하세요. 모든 클라이언트가 같은 속도 측정 기능을 제공한다고 가정하지 마세요.

  1. v2rayN: 설정 선택. 서버 목록에서 Ctrl 키를 누른 채 노드 3~5개를 선택합니다. 마우스 오른쪽 버튼을 눌러 메뉴를 열고 ‘서버 지연 시간 테스트 Tcping’을 실행해 결과를 확인합니다. 이어서 같은 노드에 ‘서버 실제 연결 지연 테스트’를 실행하고 전체 테스트가 끝날 때까지 기다립니다.
  2. v2rayN: 속도 비교. 실제 연결 테스트에 성공한 후보 2~3개를 남기고 마우스 오른쪽 버튼을 눌러 ‘서버 속도 테스트’를 실행합니다. 이때 다른 대용량 작업은 실행하지 말고, 수백 개 노드를 한꺼번에 다운로드 테스트하지 마세요.
  3. v2rayN: 테스트 조건 통일. ‘설정’ → ‘매개변수 설정’을 열고 현재 버전에서 제공하는 지연 시간 테스트 주소, 다운로드 테스트 주소, 시간 초과 설정을 확인합니다. 해당 항목이 없다면 그 버전의 기본 동작을 기록하세요. 설정을 찾으려고 노드 프로토콜을 바꿀 필요는 없습니다.
  4. v2rayNG: 실제 연결 일괄 테스트. 설정 목록 오른쪽 위에서 메뉴를 열고 ‘모든 설정 실제 연결 테스트’를 선택합니다. 현재 노드를 확인하려면 해당 설정을 선택하고 서비스를 시작한 뒤 Android VPN 권한을 승인합니다. 그런 다음 하단의 연결 상태 영역을 눌러 현재 연결을 테스트합니다.
  5. v2flyNG: 실제 메뉴에 따라 테스트. 설정 목록 메뉴에서 현재 버전이 제공하는 연결 테스트 기능을 찾아 테스트 종류를 기록합니다. 테스트 전에 설정이 해당 V2Fly 코어에서 지원되는지 확인하세요. Xray 기능에 의존하는 VLESS + REALITY 설정은 이를 지원하는 클라이언트와 코어로 테스트해야 합니다.

같은 조건에서 지연 시간과 편차 비교하기

아래는 계산 방법을 설명하기 위한 가상 기록이며 실제 노드 성능 순위가 아닙니다. 같은 기기와 Wi-Fi, 테스트 대상을 사용해 노드 A를 다섯 번 측정했다고 가정해 보겠습니다. TCPing 결과는 31, 34, 35, 37, 52ms이고 실제 연결 결과는 168, 175, 182, 194, 620ms입니다.

35 ms
예시 TCPing 중앙값
182 ms
예시 실제 연결 중앙값
620 ms
예시 실제 연결 최댓값

다섯 개 결과를 작은 순서대로 정렬하면 세 번째 값이 중앙값입니다. 한 번 측정한 최솟값보다 이 테스트 묶음의 일반적인 값을 잘 나타내지만, 다섯 번의 측정만으로 장기적인 안정성을 판단하기는 어렵습니다. 620ms는 이번 측정에서 편차가 컸다는 신호이므로 추가로 테스트해야 합니다. 이 값만으로 노드가 장기적으로 불안정하다고 단정하지 마세요.

기록 항목노드 A노드 B판단 기준
TCPing 중앙값35 ms68 ms접속 지점의 연결 성립 시간만 비교
실제 연결 중앙값182 ms146 ms이 테스트 대상에는 B가 더 빠르게 응답
실제 연결 성공 횟수5 / 55 / 5이번 테스트에서 모두 요청 완료
평균 다운로드 속도8 MB/s5 MB/s이 다운로드 서버에서는 A의 처리량이 더 높음

결론: 실제 용도에 따라 후보 두 개를 남기세요

이 가상 결과에서는 웹 페이지를 이용할 때 노드 B를 먼저 시험하고, 대용량 파일을 전송할 때는 노드 A를 먼저 시험해 볼 수 있습니다. 실제 대상 웹사이트를 열어 확인하고 자주 사용하는 시간대에 다시 측정하세요. 접속 지연이 가장 짧은 노드를 모든 용도의 기본 노드로 자동 지정하지 마세요.

시간 초과는 ‘5회 중 4회 성공, 1회 시간 초과’처럼 따로 기록해야 합니다. 시간 초과를 0ms로 처리하거나 성공한 결과만 평균 내 실패 횟수를 감추지 마세요. 애플리케이션 계층의 시간 초과는 주소 확인, 핸드셰이크, 대상 응답 때문에 발생할 수 있으며 하위 네트워크의 패킷 손실률로 바로 환산할 수 없습니다.

다운로드 속도 단위와 테스트 시간, 데이터 사용량

인터넷 요금제 속도는 보통 Mbps로 표시되고 클라이언트에는 MB/s 또는 MiB/s가 표시되는 경우가 많습니다. 십진 단위로 환산하면 8MB/s는 약 64Mbps입니다. 8MiB/s라면 약 67.1Mbps입니다. 도구끼리 비교하기 전에 단위를 확인하세요. 숫자가 같다고 속도도 같은 것은 아닙니다.

지연 시간은 짧은데 웹 페이지가 열리지 않을 때: 실패 지점별 점검

먼저 실패 당시의 로그를 보관한 뒤 설정 하나만 바꿔 다시 시도하세요. DNS, 라우팅 모드, 전송 프로토콜, 테스트 대상을 한꺼번에 바꾸면 성공하거나 실패한 원인을 파악하기 어렵습니다. 로그에 서버 주소, 계정 식별 정보, 구독 정보가 포함되어 있다면 공유 전에 해당 항목을 가리세요.

TCPing은 30ms인데 실제 연결은 왜 계속 시간 초과되나요?

노드 편집 화면을 열어 제공된 설정과 주소, 포트, UUID, 전송 유형, 보안 옵션을 대조하세요. WebSocket 설정에서는 경로와 Host도 확인하고 TLS 설정에서는 서버 이름을 확인합니다. 접속 지점에 연결된다고 설정이 올바른 것은 아닙니다. 인증서 검증을 끄는 방식으로 설정 오류를 덮으려 하지 마세요.

실제 연결에는 성공했는데 브라우저에서 페이지가 열리지 않는 이유는 무엇인가요?

현재 활성화된 노드가 테스트한 노드와 같은지 먼저 확인하세요. 데스크톱에서는 시스템 프록시 또는 TUN이 의도대로 활성화되어 있는지, 브라우저에 별도 프록시가 설정되어 있는지 확인합니다. Android에서는 VPN 서비스가 실행 중인지, 대상 앱이 앱별 라우팅 규칙에서 제외되지 않았는지 확인하세요. 그런 다음 실제 대상에 접속하고 로그에서 아웃바운드와 오류 정보를 살펴보세요.

모든 노드가 동시에 시간 초과되면 구독이 만료된 건가요?

먼저 로컬 네트워크가 정상인지 확인한 다음 코어가 제대로 시작됐는지와 로그 오류를 살펴보세요. 모든 노드가 같은 테스트 대상에서만 실패한다면 ‘설정’ → ‘매개변수 설정’의 속도 테스트 항목에서 다른 테스트 대상을 지정해 다시 확인할 수 있습니다. 테스트 대상 문제와 계정 만료 여부는 각각 따로 검증하세요.

속도 테스트는 빠른데 저녁에는 다운로드가 느립니다. 프로토콜을 바꿔야 하나요?

먼저 저녁 시간에 같은 다운로드 서버와 테스트 시간을 사용해 다시 측정하고 다른 다운로드는 일시 중지하세요. 여러 노드가 동시에 느려진다면 로컬 네트워크와 공유 대역폭을 확인하고, 특정 노드만 느려졌다면 다른 노드와 비교하세요. VMess 또는 VLESS로 바꾼다고 출구 회선의 혼잡이나 서버 속도 제한이 자동으로 해결되지는 않습니다.

일부 도메인에서만 접속이 안 된다면 DNS와 라우팅도 확인하세요. 테스트 도구는 후보 설정마다 별도의 테스트 아웃바운드를 만들 수 있지만, 브라우저 트래픽은 현재 라우팅 규칙을 따릅니다. 두 요청이 완전히 같은 경로를 거치지 않을 수도 있습니다. 라우팅 분할 안내와 DNS 설정 안내를 함께 확인해 대상 요청이 실제로 어떤 경로를 사용하는지 살펴보세요.

반복 가능한 노드 선별 절차 만들기

첫 선별과 일상적인 재측정을 나눠서 진행하세요. 첫 선별에서는 사용할 수 있는 설정을 몇 개 찾고, 일상적인 재측정에서는 실제 사용 시간에도 해당 설정이 적합한지 확인합니다. 밀리초 값 몇 개를 더 낮추려고 구독 전체를 반복해서 대용량 테스트할 필요는 없습니다.

테스트 계획: 첫 선별과 일상 재측정

처음 가져온 뒤
  • 구독을 업데이트하고 설정 항목이 빠짐없이 들어왔는지 확인합니다.
  • TCPing으로 사용할 수 있는 TCP 접속 지점을 선별합니다.
  • 후보 3~5개를 골라 각각 실제 연결 테스트를 5회씩 진행합니다.
  • 후보 중 2개를 골라 하나씩 짧게 다운로드 테스트합니다.
일상적으로 사용하기 전
  • 기기와 네트워크, 테스트 대상을 고정합니다.
  • 성공 횟수와 중앙값, 눈에 띄는 편차를 기록합니다.
  • 주로 사용하는 저녁 시간대에 같은 노드 묶음을 다시 테스트합니다.
  • 실제 웹사이트나 파일을 열어 용도에 맞게 작동하는지 확인합니다.

먼저 요청이 성공하는지 확인하고 응답 시간을 비교하세요. 지속적인 전송이 필요한 경우에만 다운로드 속도 테스트를 추가합니다.

기록에는 테스트 시간, 접속 네트워크, 클라이언트 이름, 코어, 테스트 종류, 대상을 포함하세요. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. v2rayN도 어떤 코어를 선택했는지 함께 기록해야 합니다. 프로토콜이나 코어를 비교할 때 노드 출구와 대상, 테스트 시간이 모두 달라졌다면 차이 전체를 코어 탓으로 돌릴 수 없습니다.

  1. 먼저 성공률을 확인하세요. 자주 실패하는 노드는 간혹 지연 시간이 낮게 나오더라도 기본 노드로 바로 사용하기에 적합하지 않습니다.
  2. 다음으로 응답 시간과 편차를 확인하세요. 여러 번 측정한 실제 연결 결과를 바탕으로 실제 접속 대상에 맞는 후보를 선택합니다.
  3. 마지막으로 전송 속도를 확인하세요. 실제 다운로드 용도에 따라 지속 속도를 비교하고, 검증된 예비 설정도 하나 남겨 두세요.
클라이언트 다운로드플랫폼과 설치 파일 선택