노드는 ‘프록시 연결이 되는지, 이용하려는 서비스에 접속할 수 있는지, 주로 쓰는 시간대에도 안정적인지, 트래픽 비용이 적절한지’ 순서로 확인하세요. 구독을 가져왔지만 서버 목록에서 어떤 항목을 골라야 할지 모르는 사용자를 위한 안내입니다. 같은 조건으로 테스트해 주 노드와 예비 노드를 추리면 목록에서 지연 시간이 가장 짧은 항목만 고르는 실수를 줄일 수 있습니다.
TCPing, 실제 연결 지연 시간, 다운로드 속도 구분하기
요약하면 TCPing은 노드 입구를 빠르게 확인하고, 실제 연결 테스트는 프록시 경로를 점검하며, 다운로드 테스트는 처리량을 확인합니다. 각 테스트가 확인하는 내용은 다릅니다. 노드 주소의 TCP 연결이 성립해도 계정이 유효하거나 프로토콜 설정이 맞는다는 뜻은 아니며, 해당 노드를 통해 원하는 웹사이트에 접속할 수 있다는 보장도 없습니다.
| 테스트 항목 | 실제로 확인하는 내용 | 이 결과만으로 알 수 없는 내용 |
|---|---|---|
| TCPing | 현재 기기에서 노드 입구 포트까지 TCP 연결을 맺는 데 걸리는 시간 | 프록시 인증 성공 여부, 출구 연결 상태, 웹페이지 로딩 속도 |
| 실제 연결 지연 시간 | 노드를 통해 지정한 테스트 URL에 요청을 보내는 데 걸리는 시간 | 모든 웹사이트에 접속할 수 있는지, 지속적인 다운로드 대역폭이 충분한지 |
| 다운로드 속도 테스트 | 프록시를 통해 테스트 데이터를 받을 때의 처리량 | 저녁에도 같은 속도가 유지되는지, 다른 목적지에도 같은 경로를 쓸 수 있는지 |
| 실제 사용 테스트 | 원하는 웹페이지 열기, 동영상 재생 또는 서비스 연결 결과 | 다른 지역 서비스의 이용 가능 여부와 모든 시간대의 안정성 |
실제 연결 지연 시간은 테스트 주소, DNS, TLS 핸드셰이크, 연결 재사용 및 클라이언트 구현 방식에 따라 달라집니다. 결과를 비교할 때는 같은 테스트 주소와 네트워크를 사용하세요. 모바일 데이터에서 측정한 결과와 컴퓨터 유선 네트워크에서 측정한 결과를 그대로 비교할 수는 없습니다. TCPing은 ICMP Ping과도 다릅니다. 시스템에서 ICMP 응답을 차단해도 TCPing은 실패하지 않을 수 있습니다.
v2rayN에서 같은 조건으로 노드 추리기
후보를 몇 개만 남긴 다음 반복 테스트하세요. 구독에 있는 모든 노드를 대상으로 다운로드 속도 테스트를 연속 실행하지 마세요. 여러 테스트를 동시에 돌리면 로컬 대역폭을 나눠 쓰게 되고 구독 트래픽도 크게 소모될 수 있습니다. 아래 메뉴 이름은 v2rayN에서 흔히 사용하는 중국어 표기를 기준으로 합니다. 버전에 따라 메뉴 이름이나 위치가 다를 수 있으니 실제 우클릭 메뉴를 확인하세요.
-
테스트 조건 확인
‘설정’ → ‘매개변수 설정’을 열고 현재 화면에서 제공하는 테스트 주소와 시간 초과 옵션 등을 확인하세요. ‘속도 테스트’ 섹션이 있다면 해당 설정도 기록해 둡니다. 진행 중인 다운로드를 중지하고, 이후 테스트에서는 주소와 시간 초과 값을 변경하지 마세요.
-
입구 연결 먼저 확인
메인 화면의 서버 목록에서 후보를 선택한 뒤 마우스 오른쪽 버튼을 눌러 ‘서버 지연 시간 테스트 Tcping’을 선택하세요. 계속 시간 초과되는 항목은 제외하되, 입구에 연결되지만 실제 연결 결과가 아직 확인되지 않은 노드는 일단 남겨 둡니다.
-
프록시 경로 테스트
같은 후보 목록을 우클릭해 ‘서버 실제 연결 지연 시간 테스트’를 선택하고 성공 또는 실패를 기록하세요. 각 후보를 따로 3회 반복해 연속으로 성공하는지 확인합니다. 우연히 나온 최저값 한 번으로 최종 순위를 정하지 마세요.
-
실제 출구 확인
노드를 선택하고 Enter 키를 눌러 활성 서버로 지정한 다음, 시스템 트레이에서 ‘시스템 프록시’ → ‘시스템 프록시 자동 구성’을 선택해 시스템 프록시를 따르는 앱이 연결되도록 합니다. 현재 라우팅 모드를 확인하고 대상 요청이 선택한 프록시를 통해 나가는지 점검하세요.
-
자주 쓰는 서비스로 확인
평소 이용하는 서비스를 열어 확인한 뒤, 후보 몇 개만 우클릭하여 ‘서버 다운로드 속도 테스트’를 실행하세요. 주로 사용하는 저녁 시간대에도 한 번 더 확인하고, 마지막에는 주 노드 하나와 다른 경로를 사용하는 예비 노드 하나를 남겨 두세요.
시스템 프록시는 모든 프로그램의 트래픽을 전환하는 기능이 아닙니다. 앱이 시스템 프록시를 무시하거나 클라이언트 라우팅 규칙에 따라 대상에 직접 연결될 수 있습니다. 활성 노드를 바꿨는데도 출구가 그대로라면 먼저 앱의 프록시 설정과 라우팅 로그를 확인하세요. 트래픽 경로를 확인하지 않은 채 웹페이지 로딩 속도만으로 노드를 평가하지 마세요.
Android에서는 v2rayNG와 v2flyNG 각각의 서버 목록에 제공되는 연결 테스트 기능을 사용해야 합니다. 데스크톱 메뉴 경로는 Android 화면에 적용되지 않습니다. 기기 간 결과를 비교할 때는 두 기기가 같은 네트워크를 사용하고, 테스트 경로를 바꾸는 다른 VPN 연결이 없는지도 확인하세요.
트래픽 배율 계산법: 과금 기준부터 사용량까지
트래픽 배율은 보통 구독 서비스 서버의 과금 규칙이며, VLESS·VMess·Trojan 프로토콜의 필드가 아닙니다. 클라이언트 목록의 ‘배율’ 표시는 노드 메모에서 가져온 값일 수도 있고 오래된 정보일 수도 있습니다. 실제 차감량은 서비스 제공자의 최신 안내와 계정 페이지를 기준으로 확인하세요.
아래는 계산 방법을 보여 주는 예시이며 특정 구독 요금제의 실제 데이터가 아닙니다. 서비스 제공자가 업로드와 다운로드 합계를 먼저 구한 뒤 노드 배율을 곱한다고 가정하면, 업로드 0.2GiB와 다운로드 0.8GiB를 사용했을 때 2배 노드에서 2GiB가 차감됩니다. 요금제가 십진수 GB를 사용하거나 업로드와 다운로드에 서로 다른 규칙을 적용한다면 해당 단위와 기준에 맞춰 다시 계산하세요.
- 먼저 집계 기준을 확인하세요: 업로드와 다운로드가 모두 과금되는지, 별도 회선 규칙이 있는지 확인합니다.
- 다음으로 배율 적용 범위를 확인하세요: 시간대에 따라 배율이 바뀌는지, 노드 메모가 계정 안내와 일치하는지 살펴봅니다.
- 마지막으로 테스트 비용을 고려하세요: 다운로드 속도 테스트도 데이터를 전송합니다. 여러 차례 테스트하면 웹페이지 몇 개를 여는 것보다 트래픽을 더 많이 쓸 수 있습니다.
배율이 낮다고 대역폭이 낮은 것은 아니며, 배율이 높다고 안정성이 보장되는 것도 아닙니다. 배율은 과금 관계만 나타냅니다. 웹 탐색이나 대화형 작업에는 연결 성공률과 응답 시간을 우선 확인하고, 대용량 파일을 전송할 때는 처리량과 계정 잔여량도 함께 살펴보세요. 브라우저에 표시된 파일 크기가 서버 집계량과 반드시 일치하는 것은 아닙니다. 재시도, 백그라운드 요청, 프로토콜 오버헤드로 차이가 날 수 있습니다.
노드 지역 선택법: 입구, 출구, 대상 서비스 구분하기
지역 표시는 우선 후보를 구분하는 꼬리표일 뿐, 전체 네트워크 경로를 보여 주지는 않습니다. 특정 지역으로 표시된 노드도 입구 서버는 다른 곳에 있고 중계 서버를 거쳐 출구에 도달할 수 있습니다. 지리적으로 가까우면 지연 시간이 낮을 가능성은 있지만, 통신사 간 연결, 국경을 넘는 회선, 혼잡 및 우회 경로에 따라 결과가 달라집니다.
| 사용 목적 | 우선 확인할 항목 | 선택 방법 |
|---|---|---|
| 웹 탐색 및 실시간 작업 | 반복 측정한 실제 연결 결과와 실제 페이지 첫 화면 로딩 | 필요한 서비스에 접속할 수 있는 후보 중 결과 변동이 적은 경로를 우선 선택 |
| 특정 지역 서비스 이용 | 출구 IP 지역, 서비스 계정 및 접속 규칙 | 먼저 대상 서비스를 실제로 이용할 수 있는지 확인한 다음 지연 시간을 비교 |
| 동영상 및 대용량 파일 | 지속 처리량, 버퍼링 상태, 배율 | 주로 사용하는 시간대에 테스트하고 순간 최고 속도만 보지 않기 |
| 예비 연결 | 입구와 상위 경로가 서로 독립적인지 | 주 노드와 예비 노드가 같은 경로에 메모만 다르게 붙은 경우는 피하기 |
노드 메모에 적힌 지역이 대상 웹사이트에서 인식하는 지역과 같다는 보장은 없습니다. 웹사이트는 출구 IP 데이터베이스, 계정 지역, 결제 정보 및 이전 세션을 종합해 판단할 수 있습니다. IP 조회 페이지에 올바른 지역이 표시되더라도 대상 서비스 자체의 확인을 대신할 수는 없습니다.
VLESS·VMess·Trojan: 서버 설정과 코어 지원에 맞춰 선택
프로토콜 이름만으로 속도를 판단할 수는 없습니다. 실제 경로에는 전송 방식, TLS 또는 REALITY, 입구 회선, 출구 대역폭 및 서버 부하가 모두 영향을 줍니다. 이미 구독을 가져왔다면 먼저 클라이언트가 노드 매개변수를 완전히 지원하는지 확인하세요. 프로토콜 이름 하나를 수동으로 바꿔도 기존 서버가 다른 프로토콜로 변환되지는 않습니다.
VLESS + REALITY 예시
- 프로토콜
- VLESS
- 전송 방식
- TCP
- 보안 계층
- REALITY
- Flow
xtls-rprx-vision, 서버에서 요구하는 경우에만- 주요 매개변수
- UUID, 서비스 이름, 공개 키, Short ID
매개변수 조합 예시입니다. REALITY를 사용하려면 이를 지원하는 Xray 코어와 일치하는 설정이 필요하며, 일반 TLS 노드 설정을 그대로 적용할 수 없습니다.
VMess + WS + TLS 예시
- 프로토콜
- VMess
- 전송 방식
- WebSocket
- 보안 계층
- TLS
- 경로
/ws, 예시 경로일 뿐입니다- 주요 매개변수
- UUID, Host, 경로, TLS 서버 이름
경로와 Host는 서버 설정과 일치해야 합니다. WebSocket을 사용한다고 해서 반드시 CDN을 거치는 것도 아니며 안정성이 자동으로 높아지는 것도 아닙니다.
- VLESS: VLESS 설정이 서버와 일치하는 환경에 적합합니다. VLESS 자체는 페이로드를 암호화하지 않으므로 보통 TLS, REALITY 등의 보안 계층과 함께 사용합니다. ‘경량’이라는 특성을 더 낮은 회선 지연 시간으로 곧바로 환산할 수는 없습니다.
- VMess: 서버에서 VMess를 제공하고 클라이언트가 관련 필드를 모두 가져올 수 있는 환경에 적합합니다. 인증에 시스템 시간이 사용되므로 인증에 실패하면 시스템의 자동 시간 동기화를 먼저 켠 뒤 UUID와 전송 매개변수를 확인하세요.
- Trojan: 흔히 비밀번호 인증과 TLS를 함께 사용하는 설정입니다. 비밀번호, TLS 서버 이름, 인증서 검증 결과를 중점적으로 확인하세요. TCP 443은 흔히 쓰이는 서버 포트지만 반드시 사용해야 하는 고정 포트는 아닙니다.
v2rayN의 실제 지원 여부는 선택한 코어와 버전에 따라 달라집니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 두 코어 계열의 기능이 완전히 같다고 볼 수는 없습니다. 특히 REALITY 노드를 일반 VLESS 노드처럼 가져온 뒤 호환된다고 단정하지 마세요. 알 수 없는 필드, 시작 실패 또는 미지원 전송 방식 안내가 나타나면 반복해서 속도 테스트하지 말고 코어가 해당 기능을 지원하는지 확인하세요.
노드 연결이 정상적으로 성립한 뒤 같은 서비스를 이용해 실제 성능을 비교하세요. 두 노드가 각각 VLESS와 Trojan을 사용하더라도 입구, 출구, 상위 경로가 모두 다르다면 결과는 두 전체 경로의 차이만 보여 줍니다. 특정 프로토콜이 일반적으로 더 빠르다고 판단할 수는 없습니다.
자주 묻는 문제: 낮은 지연 시간, 시간 초과, 노드 변경 후에도 그대로인 출구
지연 시간은 낮은데 동영상이 계속 버퍼링되는 이유는 무엇인가요?
먼저 동영상 요청이 실제로 프록시를 통하는지 확인한 다음 같은 시간대에 해당 노드의 다운로드 테스트를 한 번 실행하세요. 짧은 요청에 빠르게 응답한다고 해서 지속 대역폭까지 충분한 것은 아닙니다. 낮에는 괜찮고 저녁에 버퍼링된다면 두 시간대의 결과를 각각 기록하고 다른 상위 경로의 노드와 교차 확인하세요.
TCPing은 성공하지만 실제 연결이 계속 시간 초과됩니다. 지역을 바꿔야 하나요?
우선 지역을 바꾸지 마세요. 시스템 시간과 계정 상태를 확인한 다음 v2rayN 로그에서 인증, TLS, DNS 또는 시간 초과 관련 정보를 살펴보세요. 구독 정보와 포트, 서버 이름, 전송 경로가 일치하는지도 확인합니다. 모든 노드가 같은 테스트 주소에서만 실패한다면 사용 가능한 다른 테스트 주소로 다시 확인하세요.
노드를 바꿨는데 웹사이트에 표시되는 출구가 그대로인 이유는 무엇인가요?
새 노드가 활성 서버로 지정됐는지 확인한 뒤 앱이 시스템 프록시를 사용하는지, 라우팅 규칙이 대상을 직접 연결로 지정하는지 살펴보세요. 앱에서 연결을 새로 맺은 다음 출구를 다시 확인하세요. 기존 장시간 연결은 잠시 이전 경로를 계속 쓸 수 있으므로 구독 전체를 곧바로 다시 가져올 필요는 없습니다.
지연 시간순으로 정렬한 뒤 항상 1위 노드만 써도 되나요?
정렬은 후보를 좁히는 데만 활용하세요. 상위 몇 개를 골라 실제 연결 테스트를 각각 3회 반복하고, 실제 대상 서비스에 접속한 뒤 배율도 확인합니다. 1위 노드가 가끔 시간 초과되는데 다른 노드는 연속으로 연결되고 필요한 작업도 가능하다면, 후자를 주 노드로 남겨 두는 편이 낫습니다.
마지막으로 기록하기: 다시 확인할 수 있는 선택 근거 남기기
노드를 고를 때마다 전체 평가를 다시 할 필요는 없지만 최소한의 기록은 남겨 두세요. 네트워크, 시간, 테스트 방법, 실제 서비스 이용 결과를 적어 두면 나중에 로컬 네트워크 변화인지, 상위 경로 혼잡인지, 대상 서비스의 접속 정책 변경인지 구분할 수 있습니다.
- 테스트 환경: 날짜와 시간대, 유선 인터넷 또는 모바일 네트워크, 클라이언트와 선택한 코어.
- 연결 결과: 같은 테스트 URL에서 3회 측정한 실제 연결 결과를 기록하세요. 성공한 값만 남기지 말고 시간 초과도 기록합니다.
- 사용 비용: 현재 배율, 과금 단위, 업로드와 다운로드 합산 여부.
- 서비스 확인: 자주 쓰는 웹사이트에 접속할 수 있는지, 출구 지역이 필요한 조건에 맞는지, 지속 전송이 안정적인지.
- 주 노드와 예비 노드: 주 노드는 일상적인 사용을 담당하고, 예비 노드는 다른 입구나 상위 경로를 우선 선택합니다. 예비 노드도 주기적으로 연결 여부를 확인하세요.
최종 확인 순서는 그대로 유지하세요. 먼저 설정 호환성과 프록시 연결 성공 여부를 확인하고, 다음으로 대상 서비스를 이용할 수 있는지 확인한 뒤 안정성, 지연 시간, 처리량 및 배율을 비교합니다. 이 순서로 고르면 선택 근거가 분명해지고 문제가 생겼을 때 다시 확인할 계층도 쉽게 찾을 수 있습니다.