먼저 TCPing으로 노드의 진입 지점을 확인하고, 실제 연결 지연 시간으로 프록시 경로를 검증한 뒤, 다운로드 속도로 지속 전송 성능을 살펴보세요. 지연 시간은 낮은데 웹페이지가 열리지 않거나, 속도 측정은 빠른데 평소에 버벅이는 경우에 유용합니다. 같은 네트워크와 같은 측정 대상을 기준으로 여러 차례 테스트해 결과를 비교하는 방법을 소개합니다. 목록에서 가장 낮은 숫자만 보고 노드를 고르지 마세요.
1. 측정 대상부터 확인하기: 세 가지 값은 서로 바꿔 쓸 수 없습니다
먼저 메뉴에 표시된 테스트 이름을 확인한 다음 값을 비교하세요. TCPing은 보통 노드 서버의 TCP 포트에 연결해 연결이 설정될 때까지 걸린 시간을 측정합니다. 일반적인 ICMP Ping과는 다릅니다. 시간 단위인 밀리초는 ms로 표기하며, 대체로 낮을수록 좋습니다. 다운로드 속도는 보통 MB/s로 표시하고 초당 전송되는 데이터 양을 나타내므로 대체로 높을수록 좋습니다.
실제 연결 지연 시간은 노드를 통해 실제 요청을 보내 프록시가 지정된 테스트 주소에 접속할 수 있는지 확인합니다. 클라이언트 버전과 코어, 테스트 주소에 따라 측정 시작점과 종료점이 다를 수 있습니다. 프록시 핸드셰이크, 대상 서버 연결, TLS 핸드셰이크, 응답 대기 시간 일부가 포함될 수 있으므로 서버의 네트워크 왕복 시간으로 단순히 해석하면 안 됩니다.
TCPing: 진입 포트 확인
주로 “내 기기에서 이 주소와 포트에 연결할 수 있는가?”를 확인합니다. VMess나 VLESS 같은 프록시 프로토콜의 인증 여부를 확인하지 않으며, 노드가 대상 웹사이트에 접속할 수 있다는 의미도 아닙니다.
사용 목적: 진입 지점 연결에 실패하는 설정을 빠르게 걸러내고 주소, 포트, 로컬 네트워크를 점검할 때
실제 연결 지연 시간: 일상적인 사용 가능 여부 우선 확인
권장설정을 사용해 프록시 경로를 구성한 다음 테스트 주소에 접속합니다. 단순한 포트 연결보다 웹페이지를 여는 과정에 가깝지만, 테스트에 성공해도 해당 테스트 대상에 접속할 수 있다는 의미일 뿐입니다.
사용 목적: 평소에 사용할 노드를 선택하고 프로토콜 설정과 프록시 출구의 작동 여부를 확인할 때
다운로드 속도 측정: 지속 전송 성능 확인
노드를 통해 데이터를 일정 시간 동안 계속 받습니다. 결과는 로컬 회선 속도, 노드 부하, 출구 경로, 다운로드 서버의 성능에 모두 영향을 받으므로 웹페이지가 열리는 속도로 바로 환산할 수 없습니다.
사용 목적: 동영상 재생과 대용량 파일 다운로드, 같은 시간대의 지속 전송 속도 비교
2. TCPing은 빠른데 웹페이지가 열리지 않을 때: 경로를 단계별로 점검하기
프로토콜부터 반복해서 바꾸지 마세요. TCPing 성공은 진입 포트에서 TCP 연결이 성립했다는 뜻입니다. 노드 진입 지점이 리버스 프록시나 중계 서버라면 테스트가 진입 지점에서 끝날 수도 있습니다. 이후의 프록시 인증, 서버 전달, 대상 웹사이트는 아직 확인되지 않은 상태입니다.
| 확인된 현상 | 우선 점검할 항목 | 다음 조치 |
|---|---|---|
| TCPing 성공, 실제 연결 실패 | 프로토콜 설정, 인증, 전송 방식, 보안 설정 | 구독 정보의 주소와 포트, 사용자 ID, TLS, SNI, 전송 경로를 확인하세요. 진입 지점에 연결된다고 설정이 올바른 것은 아닙니다. |
| 실제 연결 성공, 일부 도메인만 접속 실패 | DNS, 라우팅, 대상 사이트의 접속 제한 | 테스트 도메인과 접속에 실패한 도메인의 라우팅 경로를 비교하고, 실패한 요청이 직접 연결로 처리됐는지 확인하세요. |
| 클라이언트 테스트는 성공하지만 브라우저에서 접속할 수 없음 | 시스템 프록시 또는 앱별 트래픽 처리 범위 | 브라우저가 클라이언트의 로컬 수신 포트를 사용하도록 설정됐는지 확인하세요. Android에서는 VPN이 연결되어 있고 대상 앱이 프록시 적용 범위에 포함됐는지 확인합니다. |
| 다른 네트워크로 바꾸면 정상 작동 | 현재 네트워크 연결과 진입 경로 | Wi-Fi와 모바일 네트워크의 결과를 따로 기록하세요. 두 네트워크의 측정값을 섞어 순위를 매기지 마세요. |
TLS는 연결을 암호화하는 프로토콜입니다. SNI는 TLS 핸드셰이크에서 접속하려는 호스트 이름을 전달하는 정보입니다. 진입 포트에 연결되더라도 SNI, 인증서 검증, WebSocket 경로 또는 REALITY 설정이 맞지 않으면 이후 핸드셰이크에서 실패할 수 있습니다. 먼저 구독 설정을 다시 확인하고, 문제를 가리기 위해 인증서 검증을 끄지 마세요.
3. 실제 연결 지연 시간 측정하기: 대상을 고정하고 반복 확인
테스트 주소를 하나로 고정한 뒤 후보 설정을 반복해서 테스트하세요. 테스트 주소는 클라이언트가 연결 상태를 확인하기 위해 사용하는 URL이며 노드 서버 주소가 아닙니다. 사이트마다 서버 위치와 응답 방식, 접속 정책이 다릅니다. 오늘은 한 대상을, 내일은 다른 대상을 측정하면 결과를 직접 비교하기 어렵습니다.
- 테스트 설정을 확인하세요. v2rayN의 ‘설정’ → ‘매개변수 설정’에서 지연 시간 테스트 주소와 다운로드 속도 테스트 주소 관련 항목을 찾으세요. 버전에 따라 항목 이름이 다를 수 있으니 먼저 현재 값을 기록하고, 숫자를 낮추려고 자주 바꾸지 마세요.
- 테스트를 따로 실행하세요. v2rayN 설정 목록에서 항목을 선택하고 마우스 오른쪽 버튼 메뉴에서 ‘Tcping’과 ‘실제 연결 지연 시간’이 포함된 테스트를 각각 실행하세요. 일괄 테스트와 대용량 파일 다운로드를 동시에 진행하지 마세요.
- Android에서는 사용할 수 있는 테스트 항목을 선택하세요. v2rayNG 메인 목록에서 오른쪽 위 메뉴를 열고 ‘모든 설정 실제 연결 테스트’ 등의 항목을 찾으세요. 일부 버전에서는 먼저 서비스를 시작해야 합니다. 메뉴에 다른 이름으로 표시되면 현재 버전을 기준으로 확인하세요. 테스트 성공을 모든 앱의 트래픽이 프록시를 통과한다는 뜻으로 받아들이지 마세요.
- 최소 3회 테스트하세요. 각 테스트가 끝난 뒤 약 10초 기다렸다가 다음 테스트를 진행하세요. 매회 성공 또는 실패 여부를 기록하고, 성공한 결과는 최솟값이 아니라 중앙값으로 비교하세요.
- 실제 사이트에도 접속해 보세요. 설정을 선택하고 연결을 시작한 뒤 평소 사용하는 웹사이트를 여세요. 테스트 주소에는 접속되지만 실제 사이트에서 실패한다면 해당 사이트의 DNS, 라우팅, 접속 제한을 점검하세요.
위 숫자는 테스트 방법에 관한 권장 사항이지 노드의 실제 측정 결과가 아닙니다. 세 번 테스트하면 빠르게 걸러낼 수 있지만 장기적인 안정성까지 보장하지는 않습니다. 회의나 장시간 전송에 사용할 노드는 실제 사용 시간에도 계속 확인하세요. 일괄 테스트를 동시에 많이 실행하면 로컬 네트워크와 기기 자원을 과도하게 사용할 수 있습니다. 문제가 생기면 항목별로 다시 테스트하세요.
결론: 반복해서 실패하는 항목을 먼저 제외하고 성공한 결과를 비교하세요
한 번 매우 빠르게 연결됐다고 해서 다른 회차의 실패를 무시하지 마세요. 반복 테스트에 모두 성공하고 실제 대상에도 접속할 수 있는 설정을 먼저 남긴 다음, 일반적인 응답 시간과 변동 폭을 비교하세요.
4. 다운로드 속도 측정 결과 읽기: 대역폭, 단위, 테스트 비용 구분
실제 연결 테스트를 통과한 소수의 설정만 다운로드 속도를 측정하세요. 처리량은 일정 시간 동안 전송되는 데이터 양으로, 지연 시간과는 별개의 지표입니다. 연결이 빨리 설정된다고 지속 전송 속도가 빠른 것은 아니며, 다운로드 속도가 높다고 작은 요청에도 항상 빠르게 응답하는 것은 아닙니다.
- 먼저 단위를 맞추세요. 1 Byte는 8 bit입니다. 프로토콜 오버헤드를 제외하면 100 Mbps 대역폭은 약 12.5 MB/s에 해당합니다. 이는 단위 환산일 뿐 노드 속도를 보장하는 수치가 아닙니다. 화면에 MiB/s가 표시된다면 십진 단위인 MB/s와 정확히 같지 않다는 점도 유의하세요.
- 연결 수를 확인하세요. 단일 연결 테스트와 다중 연결 테스트 결과를 그대로 비교하면 안 됩니다. 여러 연결을 사용하면 대역폭을 더 잘 활용할 수 있지만, 개별 다운로드나 단일 서비스 연결에서도 같은 속도가 나온다는 뜻은 아닙니다.
- 테스트 조건을 동일하게 유지하세요. 같은 다운로드 주소와 시간, 같은 네트워크를 사용하고 백그라운드 동기화, 시스템 업데이트, 다른 기기의 대용량 전송을 일시 중지하세요.
- 지속적인 성능을 확인하세요. 시작 직후의 순간 최고 속도는 버퍼링과 측정 방식의 영향을 받기 쉽습니다. 이후에도 안정적으로 유지되는지 살펴보고 실제 동영상이나 파일 다운로드로 확인하세요.
- 데이터 사용량을 관리하세요. 10 MB/s로 20초 동안 다운로드한다고 가정하면 데이터 사용량은 약 200 MB이며, 여기에 프로토콜 오버헤드가 더해집니다. 일괄 테스트를 실행하면 로컬 네트워크와 구독 데이터 사용량도 누적됩니다.
속도 측정 서버 자체가 병목일 수도 있습니다. 같은 시간대에 모든 설정의 속도가 비슷하게 낮다면 노드가 모두 혼잡하다고 단정하지 말고 로컬 네트워크와 테스트 서버부터 확인하세요. 브라우저 속도 측정은 브라우저의 프록시 설정에도 영향을 받습니다. 직접 연결 경로를 측정할 수도 있으므로 요청이 선택한 설정을 실제로 통과하는지 먼저 확인해야 합니다.
5. 데스크톱과 Android에서 확인하기: 같은 방법으로 앱별 트래픽 처리 범위 검증
‘노드 자체가 작동하는지’와 ‘앱 트래픽이 프록시를 통과하는지’를 나눠 확인하세요. v2rayN은 데스크톱 클라이언트이고 v2rayNG는 Xray 코어를 사용하는 Android 클라이언트입니다. 같은 구독을 가져와도 네트워크 연결, DNS, 프록시 적용 범위가 다르면 두 기기의 결과가 달라질 수 있습니다. 지연 시간 측정값이 완전히 같을 필요는 없습니다.
권장 순서: 먼저 설정을 테스트한 다음 실제 앱에서 확인
데스크톱: v2rayN
- 먼저 실제 연결 테스트를 실행해 선택한 설정으로 테스트 대상에 접속할 수 있는지 확인하세요.
- 시스템 프록시를 사용할 경우 대상 프로그램이 시스템 프록시 설정을 따르는지 확인하세요. 명령줄 도구는 자동으로 프록시를 사용하지 않을 수 있습니다.
- 로컬 수신 주소와 포트를 확인하세요. 예를 들어 실제 포트가 10808이라면 앱에서도 해당 포트와 프로토콜을 사용해야 합니다. 기억에 의존해 입력하지 마세요.
- TUN 가상 네트워크 어댑터로 트래픽을 처리한다면 적용 상태와 라우팅을 확인하세요. 시스템 프록시와 TUN의 효과를 같은 것으로 보지 마세요.
Android: v2rayNG
- 설정을 선택하고 서비스를 시작한 뒤 시스템에서 VPN 권한을 허용했는지 확인하세요.
- 앱별 프록시를 사용한다면 브라우저와 실제 서비스 앱이 원하는 적용 범위에 포함되어 있는지 확인하세요.
- Wi-Fi와 모바일 네트워크를 전환한 뒤 다시 테스트하세요. 이전 네트워크에서 정한 순위를 그대로 적용하지 마세요.
- 앱을 백그라운드로 보낸 뒤에만 연결이 끊긴다면 시스템의 배터리 제한을 확인하세요. 모든 문제를 노드 속도 탓으로 돌리지는 마세요.
두 기기에서 테스트 대상을 동일하게 설정하되 네트워크, 시간, 앱의 트래픽 처리 상태를 각각 기록하세요. 접속 가능 여부를 확인한 뒤 지연 시간과 처리량을 비교하면 됩니다.
결과를 기록할 때는 테스트 시간, 클라이언트 버전, 네트워크 유형, 대상 주소, 성공 횟수, 속도 단위를 적어 두면 됩니다. 스크린샷을 공유하기 전에는 구독 링크와 사용자 ID, 서버 관련 민감 정보를 가리세요. 전체 설정을 다른 사람에게 보낼 필요는 없습니다. 보통 실패한 단계와 관련 오류 메시지만으로도 원인을 좁힐 수 있습니다.
6. 자주 묻는 질문: 시간 초과, 음수, 속도 측정 순위
실제 연결 지연 시간이 -1로 표시되면 측정할 수 없을 만큼 빠르다는 뜻인가요?
아닙니다. 일부 버전은 실패, 시간 초과, 유효한 결과 없음 등을 음수나 별도의 문구로 표시합니다. 먼저 현재 클라이언트의 상태 설명을 확인하고 해당 설정만 따로 다시 테스트한 다음 실행 로그를 살펴보세요. 음수를 성공한 결과에 포함해 순위를 매기거나 ‘음수 지연 시간’으로 해석하면 안 됩니다.
브라우저에서는 웹페이지가 열리는데 클라이언트 테스트는 왜 시간 초과되나요?
먼저 테스트 대상에만 별도의 접속 제한이 있는지 확인한 다음 브라우저가 실제로 같은 설정을 사용하는지 살펴보세요. 브라우저가 캐시를 사용하거나 다른 프록시 확장 프로그램을 쓰거나 라우팅에 따라 직접 연결할 수 있습니다. 테스트 대상을 하나로 고정해 반복 비교하세요. 테스트 주소에서만 실패한다면 설정에서 접속이 확인됐고 응답이 안정적인 주소로 바꾼 다음 기준 결과를 다시 측정할 수 있습니다.
지연 시간이 가장 낮은 노드인데 동영상이 계속 버퍼링되는 이유는 무엇인가요?
먼저 다른 다운로드를 중지한 뒤 현재 설정의 지속 전송 속도를 측정하세요. 동영상 버퍼링은 미디어 서버로 가는 경로, 노드 출구 부하, 로컬 무선 네트워크 문제로도 발생할 수 있습니다. 같은 동영상과 화질, 같은 시간대를 기준으로 비교하세요. 테스트 페이지의 지연 시간만으로 동영상 전송 성능을 판단하지 마세요.
속도 순위가 매번 바뀌는데 계속 1위 노드로 전환해야 하나요?
한 번의 최저값을 쫓아다닐 필요는 없습니다. 계속 사용할 주 설정 하나와 예비 설정 하나를 남기고 세 차례 반복해 성공률을 확인하세요. 지속적인 실패나 큰 변동이 있거나 실제 작업이 느려질 때 전환하면 됩니다. 차이가 몇 ms 정도라면 실제 사용 경험을 먼저 지켜보고 현재 연결을 자주 끊지 마세요.
7. 이 순서대로 노드 선택하기
- 먼저 진입 지점을 확인하세요. TCP 전송이라면 TCPing으로 먼저 점검할 수 있지만, 포트에 연결된다는 사실을 프록시가 정상 작동한다는 뜻으로 보면 안 됩니다.
- 다음으로 프록시 경로를 확인하세요. 실제 연결 테스트 주소를 고정해 반복 측정하고, 계속 실패하지 않는 설정을 우선 선택하세요.
- 그다음 사용 목적에 맞춰 확인하세요. 일상적인 웹 탐색은 실제 연결의 안정성을 확인하고, 동영상과 대용량 파일은 다운로드 속도를 추가로 측정하세요. 실시간 서비스는 실제 앱에서 검증해야 합니다.
- 마지막으로 트래픽 적용 범위를 확인하세요. 시스템 프록시, TUN, Android VPN이 적용되는 범위를 점검해 클라이언트 테스트는 통과했지만 실제 앱의 트래픽은 프록시를 거치지 않는 상황을 방지하세요.
각 지표를 실제로 측정하는 단계에 맞춰 살펴보면 문제를 더 쉽게 찾을 수 있습니다. TCPing은 진입 지점에 연결할 수 있는지, 실제 연결은 프록시 경로로 요청을 완료할 수 있는지, 다운로드 속도 측정은 데이터를 지속적으로 전송할 수 있는지를 확인합니다. 먼저 사용 가능 여부를 확인하고 안정성을 비교한 다음 최고 속도를 살펴보는 편이 순위 하나만 보는 것보다 일상적인 사용에 더 잘 맞습니다.