‘지연 시간은 낮은데 웹페이지가 열리지 않음’, ‘Ping은 시간 초과인데 프록시는 정상’, ‘속도 측정은 빠른데 자주 끊김’ 같은 문제를 겪는 v2rayN 사용자에게 적합한 글입니다. 호스트 응답, 포트 연결, 프록시 요청, 지속 전송 속도라는 네 가지 지표를 구분하고, 동일한 테스트 대상과 순차 재측정, 실제 앱 검증을 통해 노드를 고르세요. 밀리초 수치 하나만으로 전체 사용 가능 여부를 판단하지 마세요.
네 가지 테스트: 먼저 어떤 구간을 측정하는지 확인
v2rayN은 데스크톱 GUI 클라이언트이며, 노드 설정은 선택한 코어가 처리합니다. 서버 목록의 지연 시간은 노드에 고정된 속성이 아니라 현재 네트워크와 테스트 대상, 측정 방식에 따라 달라지는 결과입니다. Wi-Fi를 바꾸거나 테스트 URL을 변경하고, 같은 시간대에 더 많은 노드를 동시에 테스트해도 순위가 달라질 수 있습니다.
버전에 따라 메뉴 이름과 테스트 옵션, 측정 범위가 달라집니다. 실행하기 전에 명령 이름을 확인하세요. TCPing 결과를 ‘프록시 접속 지연 시간’이라고 부르거나, 다운로드 속도 열을 웹페이지 첫 화면이 표시되는 시간으로 해석하면 안 됩니다.
| 지표 | 주요 측정 대상 | 확인할 수 있는 내용 | 이 결과만으로 확인할 수 없는 내용 |
|---|---|---|---|
| ICMP Ping | 내 컴퓨터에서 대상 주소까지의 ICMP 왕복 시간 | 대상의 응답 여부, 왕복 시간, 패킷 손실 | 프록시 포트와 인증, 대상 웹사이트의 사용 가능 여부 |
| TCPing | 내 컴퓨터에서 지정한 TCP 포트까지의 연결 설정 | 해당 주소와 포트가 TCP 연결을 수락하는지 여부 | VMess, VLESS 등의 프로토콜 설정이 올바른지 여부 |
| 실제 연결 지연 시간 | 테스트 대상 프록시 설정으로 테스트 URL에 접속 | 지정한 테스트 조건에서 해당 설정으로 요청을 완료할 수 있는지 여부 | 모든 웹사이트와 UDP 트래픽, 장시간 다운로드의 정상 작동 여부 |
| 다운로드 속도 측정 | 프록시를 통해 테스트 리소스 다운로드 | 해당 리소스와 테스트 시간대의 전송 속도 | 일상적인 지연 시간과 장기 안정성, 모든 작업의 속도 |
Ping과 TCPing: 지연 시간이 낮아도 프록시가 작동한다는 뜻은 아닙니다
ICMP Ping은 프록시 프로토콜 인증 정보를 보내지 않으며 TLS, WebSocket 경로, 서버의 외부 연결 기능도 확인하지 않습니다. 일부 서버나 중간 네트워크는 ICMP를 제한하므로 Ping 시간 초과는 예상한 응답을 받지 못했다는 뜻일 뿐, 프록시가 작동하지 않는다고 단정할 수는 없습니다. 반대로 ICMP 응답이 정상이어도 프록시 포트에서 서비스가 대기 중이라는 의미는 아닙니다.
TCPing은 포트 연결 여부를 확인하는 데 더 적합합니다. 예를 들어 노드 설정에 TCP 443 포트가 지정되어 있다면 임의의 다른 호스트가 아니라 설정에 입력된 서버 주소와 443 포트를 테스트해야 합니다. 포트 연결에 성공해도 이후 인증, TLS 협상, 전송 경로 일치 단계에서 실패할 수 있습니다. CDN을 사용하는 노드는 TCP 연결이 먼저 엣지 서버에 도달할 수도 있으므로, 실제 프록시 서비스에 연결됐다고 볼 수는 없습니다.
- Ping 응답은 있지만 TCP 연결에 실패: 노드 포트 설정 오류, 네트워크의 포트 차단 여부, 서버의 리스닝 상태를 먼저 확인하세요.
- TCP 연결은 성공했지만 실제 연결이 시간 초과: 프로토콜 매개변수, TLS 서버 이름, 전송 설정, 서버의 트래픽 전달 기능을 확인하세요.
- Ping은 시간 초과지만 실제 연결은 정상: ICMP 응답이 없다는 이유만으로 해당 노드를 삭제하지 마세요.
- 노드가 TCP가 아닌 전송 방식을 사용: TCPing으로 해당 전송 방식의 사용 가능 여부를 확인할 수 없습니다. 코어가 실제로 프록시 연결을 설정하도록 테스트하세요.
실제 연결 지연: 테스트 URL과 코어가 모두 결과에 영향을 줍니다
실제 연결 테스트는 대개 테스트 대상 설정으로 프록시 아웃바운드를 시작하거나 사용한 뒤 지정된 URL에 접속합니다. TCP 포트만 검사하는 것보다 더 많은 구간을 확인하지만, ‘실제 연결’의 측정 기준은 모든 버전에서 동일하지 않습니다. DNS 조회, 프록시 핸드셰이크, TLS 연결, 응답 수신 중 어느 단계까지 측정에 포함되는지는 현재 버전의 구현에 따라 다릅니다.
v2rayN에서 「설정」→「매개변수 설정」으로 이동해 지연 시간 테스트 주소 및 속도 측정 주소와 관련된 옵션을 찾아보세요. 서버 목록에서 마우스 오른쪽 버튼을 누르면 보통 ‘실제 연결 지연 시간’이 포함된 테스트 명령을 사용할 수 있습니다. 메뉴 분류와 문구는 설치된 버전에 따라 다를 수 있습니다. 주소를 변경하기 전에 현재 값을 기록해 두세요. 테스트 대상이 바뀌면 새 결과와 이전 결과를 그대로 비교할 수 없습니다.
응답이 작은 고정 테스트 대상
권장안정적으로 접속할 수 있고 응답 크기가 작은 동일한 URL을 사용하세요. 프로토콜과 리디렉션 동작도 동일하게 유지해야 합니다. 노드를 비교할 때는 테스트 대상을 바꾸지 말고 노드만 변경하세요.
적합한 용도: 일상적인 노드 선별 및 반복 테스트 결과 비교.
실제로 사용하는 웹사이트
로그인, 페이지 리소스, 특정 아웃바운드 제한을 추가로 확인할 때 사용하세요. 완전한 웹페이지는 여러 도메인과 요청으로 구성되므로 페이지 전체 로딩 시간을 작은 응답의 지연 시간과 동일하게 볼 수 없습니다.
적합한 용도: 일반 테스트는 통과했지만 특정 서비스는 여전히 작동하지 않을 때.
대용량 파일 다운로드 대상
전송량과 지속 전송 속도를 확인하는 데 적합하지만, 트래픽이 적은 빈번한 테스트에는 적합하지 않습니다. 리소스 속도 제한, 캐시 적중 여부, 테스트 시간이 표시 결과에 영향을 줍니다.
적합한 용도: 연결 테스트를 통과한 후보 노드의 다운로드 성능을 비교할 때.
모든 노드가 갑자기 같은 URL에서 시간 초과된다면 구독을 모두 다시 가져오기 전에 테스트 대상에 문제가 있는지 확인하세요. 시스템 시간, 로그의 인증서 오류, 테스트 대상이 서버의 아웃바운드 연결을 거부하는지도 살펴보세요. 실제 연결 테스트에 한 번 성공했다고 해서 해당 요청이 성공했다는 사실만 확인할 수 있습니다.
다운로드 속도 측정: 대역폭과 단위, 순간 최고 속도 구분하기
지연 시간은 요청과 응답 사이의 대기 시간을 나타내고, 처리량은 단위 시간당 전송되는 데이터의 양을 나타냅니다. 서로 관련은 있을 수 있지만 같은 지표는 아닙니다. 먼 지역의 노드가 왕복 시간은 길어도 지속 다운로드 속도가 더 높을 수 있고, 가까운 노드라도 연결이 빠른 대신 공유 대역폭이나 혼잡 시간대의 정체에 영향을 받을 수 있습니다.
아래 세 항목은 단위 환산 예시이며, 이 사이트에서 측정한 결과나 특정 노드의 성능을 보장하는 값이 아닙니다. 소문자 b는 bit, 대문자 B는 byte를 뜻하며, 십진 단위 기준으로 1 byte는 8 bit입니다. 프로그램에 MiB/s로 표시된다면 이진 단위와의 차이도 고려해야 합니다.
판단 기준: 연결 테스트를 먼저 통과한 뒤 트래픽을 사용해 속도 측정
실제 연결 테스트를 안정적으로 통과한 후보 노드 2~3개만 짧게, 순차적으로 다운로드 테스트하세요. 최고 속도 한 번이 아니라 지속 속도를 기록하고 구독 요금제의 데이터 사용량 과금 방식도 확인하세요.
- 로컬 환경의 한계: 인터넷 회선 속도, 무선 신호, 라우터 부하, 다른 다운로드 작업이 모두 측정 결과를 낮출 수 있습니다.
- 원격 환경의 한계: 노드의 아웃바운드 연결, 속도 측정 리소스가 위치한 네트워크, 단일 연결 속도 제한, 서버 부하가 모두 처리량을 제한할 수 있습니다.
- 테스트 시간: 너무 짧으면 안정적인 전송이 시작되기 전에 끝날 수 있고, 너무 길면 더 많은 데이터가 사용됩니다. 비교할 때는 테스트 시간을 통일하세요.
- 프로토콜 오버헤드: 암호화와 캡슐화, 재전송에 리소스가 사용되므로 실제 앱 속도는 회선의 표시 속도를 이론적으로 환산한 값에 미치지 못하는 경우가 많습니다.
재현 가능한 노드 선별 순서: 조건을 고정하고 단계별로 기록
모든 노드를 선택한 뒤 여러 테스트를 동시에 실행하지 마세요. 동시 작업은 로컬 대역폭과 연결 리소스, CPU 시간을 놓고 경쟁해 테스트 자체가 대기열을 만들 수 있습니다. 먼저 범위를 넓게 좁힌 뒤 후보를 추리고 실제 앱에서 확인하는 편이 더 신뢰할 수 있습니다.
- 환경 고정: 시스템 업데이트와 대용량 다운로드를 일시 중지하고 같은 네트워크를 사용하세요. 현재 코어, 테스트 URL, 테스트 시간도 기록하세요.
- 포트 1차 점검: 해당하는 TCP 노드의 연결 여부를 확인하세요. 이 단계는 후보 범위를 좁히기 위한 것이며, Ping 결과만으로 노드를 탈락시키지 마세요.
- 실제 연결 재측정: 후보 노드를 하나씩 5회 테스트하고 성공 횟수와 각 소요 시간을 기록하세요. 5회 모두 성공하지 않았다면 성공한 샘플의 평균만 기록하지 마세요.
- 중앙값 비교: 예를 들어 5회 결과가 180, 185, 190, 210, 900ms라면 정렬 후 중앙값은 190ms입니다. 900ms의 급등 기록도 함께 남겨 변동 폭이 중앙값에 가려지지 않도록 하세요.
- 짧게 처리량 측정: 안정적인 후보 2~3개를 같은 리소스와 시간으로 순차 테스트하세요. 위 데이터는 계산 예시일 뿐 실제 노드 순위가 아닙니다.
- 실제 앱에서 확인: 활성 노드를 전환하고 시스템 프록시나 TUN이 예상대로 켜졌는지 확인한 뒤, 자주 쓰는 웹사이트와 동영상, 파일 전송을 테스트하세요.
사용 목적에 따라 재테스트 기준을 달리하세요
웹 브라우징과 대화형 요청
- 실제 연결 성공률과 반복 테스트의 변동 폭을 우선 확인하세요.
- 실제 웹사이트에서 도메인 조회와 로그인, 리소스 로딩을 확인하세요.
- 한가한 시간대의 최저값만 보지 말고 혼잡 시간대 결과도 기록하세요.
대용량 파일과 지속 전송
- 연결 안정성을 먼저 확인한 뒤 지속 다운로드 속도를 비교하세요.
- 다운로드 대상과 테스트 시간, 로컬 네트워크를 동일하게 유지하세요.
- 전송 중 멈춤과 재연결 여부를 살펴보고 순간 최고 속도로 순위를 매기지 마세요.
결론: 주력 노드는 실제 사용 목적에 따라 고르고, 백업 노드는 사용 가능성을 확인해 보관하세요. 지연 시간과 처리량은 따로 기록하세요.
테스트는 통과했는데 접속이 안 될 때: 실제 트래픽 경로 확인
노드 테스트와 브라우저 트래픽은 완전히 같은 진입점과 경로를 거치지 않을 수 있습니다. 클라이언트는 지정한 노드로 테스트를 보낼 수 있지만, 브라우저가 시스템 프록시를 사용하지 않거나 라우팅 규칙에 따라 직접 연결될 수도 있습니다. 따라서 ‘서버 목록의 테스트 성공’과 ‘현재 앱이 해당 노드를 사용 중’이라는 판단은 서로 다릅니다.
- 시스템 프록시: 앱이 시스템 프록시 설정을 사용하는지 확인하세요. 명령줄 도구와 일부 앱은 시스템 프록시를 자동으로 따르지 않을 수 있습니다.
- TUN: 가상 네트워크 인터페이스가 정상적으로 시작됐는지, 필요한 권한이 있는지, 관련 라우팅이 적용됐는지 확인하세요. 토글이 켜져 있는지만 보아서는 안 됩니다.
- 로컬 리스닝: 매개변수 설정에서 실제 포트를 확인하세요. 포트를
127.0.0.1:10808로 직접 설정했다면 앱도 해당 포트와 올바른 프록시 유형을 사용해야 합니다. 이는 설정 예시이며 현재 버전의 기본값과 같다고 보장하지 않습니다. - 라우팅과 DNS: 대상 도메인에 적용되는 규칙과 아웃바운드 경로를 확인하세요. 테스트 도메인에 접속할 수 있다고 해서 서비스 도메인도 같은 경로를 사용한다는 뜻은 아닙니다.
- 코어 로그: 연결 시간 초과와 인증 실패, 인증서 오류, 로컬 포트 사용 중 여부를 구분한 뒤 어느 설정을 수정할지 판단하세요.
VMess와 VLESS는 프록시 프로토콜 이름이지 속도 등급이 아닙니다. 프로토콜을 바꿔도 설정 확인을 대신할 수는 없습니다. TLS 노드는 서버 요구사항에 맞춰 서버 이름 등의 설정을 확인하고, 테스트를 통과시키려고 인증서 검증을 임의로 끄지 마세요. 설정이 서버와 일치하지 않으면 TCP 지연 시간이 낮아도 해결에 도움이 되지 않습니다.
자주 묻는 질문: 지연 시간 표시, 속도 측정값, 노드 선택
지연 시간에 -1이 표시됩니다. 노드가 완전히 작동하지 않는 건가요?
일부 버전은 테스트에 실패하면 음수나 빈 값으로 표시합니다. ‘음수 지연 시간’을 뜻하는 것은 아닙니다. 먼저 TCPing과 실제 연결 테스트 중 무엇을 사용했는지 확인하고, 같은 대상으로 해당 노드를 개별 재테스트하세요. 로그와 시간 초과 설정도 점검해야 합니다. 여러 번 실패하고 실제 앱에서도 사용할 수 없을 때 노드 장애로 처리하세요.
왜 80ms 노드가 200ms 노드보다 느릴 수 있나요?
먼저 두 수치가 같은 테스트에서 나온 것인지 확인하세요. 동일한 URL로 측정한 실제 연결 지연 시간이라면 지속 처리량과 요청 성공률을 비교하세요. 80ms 노드는 연결 설정은 빠르지만 아웃바운드가 혼잡할 수 있고, 200ms 노드는 왕복 거리가 더 멀어도 전송 대역폭이 더 충분할 수 있습니다.
속도를 측정할 때 시스템 프록시를 켜야 하나요?
클라이언트 내장 노드 테스트는 보통 테스트 대상의 프록시 설정을 자체적으로 사용하므로 시스템 프록시 스위치가 반드시 필요한 것은 아닙니다. 구체적인 동작은 현재 버전에 따라 다릅니다. 브라우저나 외부 다운로드 도구로 확인할 때는 시스템 프록시와 TUN, 도구의 프록시 매개변수가 적용되는지 별도로 확인하세요.
순위가 매번 바뀌는데 자동 전환을 계속 사용해야 하나요?
먼저 테스트 조건을 고정하고 한가한 시간대와 혼잡 시간대에 각각 5회씩 기록하세요. 차이가 몇 ms에 불과하고 성공률이 비슷하다면 현재 안정적인 노드를 유지하는 편이 좋습니다. 지속적인 시간 초과나 눈에 띄는 끊김, 서비스 이용 불가가 있을 때만 전환해 정상적인 변동을 장애로 오해하지 않도록 하세요.
다운로드 속도가 정상이면 동영상과 실시간 통신도 정상이라고 볼 수 있나요?
아닙니다. 다운로드 속도 테스트는 특정 리소스의 처리량을 주로 확인합니다. 실시간 서비스는 지터와 패킷 손실, UDP 지원 여부, 앱 자체의 경로 선택에도 영향을 받습니다. 실제 앱에서 짧게 확인하고 끊김 현상을 기록하세요. 다운로드 결과 하나만으로 모든 네트워크 서비스가 정상이라고 판단하지 마세요.
최종 선택: 성공률을 우선하고, 지연 시간과 속도는 용도에 맞게 비교
주로 사용할 노드 하나와 검증된 백업 노드 하나를 보관하세요. 문제가 생기면 같은 대상으로 먼저 재테스트한 다음 앱의 트래픽 경로를 확인하세요. 구독 정보나 프로토콜 설정은 노드 매개변수 또는 서버에 문제가 있다는 근거가 있을 때만 변경하세요.