TCPing은 서버 포트와의 TCP 핸드셰이크를 확인하고, 실제 연결 지연은 노드를 거쳐 보낸 요청을 측정하며, 다운로드 테스트는 일정 시간 동안의 전송 성능을 확인합니다. 웹서핑용 노드는 실제 연결이 성공하고 안정적인지 먼저 살펴보고, 대용량 파일을 전송할 때 다운로드 속도를 비교하세요. v2rayN·v2rayNG에서 테스트하는 순서와 지연 시간은 낮지만 웹페이지가 열리지 않을 때의 점검 방법을 소개합니다.
세 가지 측정값은 각각 어디까지 측정할까?
지연 시간은 작업을 시작해 결과를 받을 때까지 걸리는 시간이지, 회선에 고정된 속성이 아닙니다. 테스트 방식과 대상 주소, 연결 재사용 여부에 따라 결과가 달라집니다. 서로 다른 클라이언트 화면에 표시된 밀리초를 그대로 비교하면 실제로는 서로 다른 작업을 비교하는 셈일 수 있습니다.
TCPing
노드 서버의 주소와 포트에 TCP 연결을 설정해 해당 구간의 핸드셰이크 시간을 주로 측정합니다. 핸드셰이크에 성공해도 프록시 프로토콜 인증이나 대상 웹사이트 접속까지 성공한 것은 아닙니다.
적합한 용도: 포트에 연결할 수 없거나 핸드셰이크가 눈에 띄게 느린 노드를 일괄 제외할 때
실제 연결 지연
추천클라이언트가 노드를 거쳐 테스트 주소로 요청을 보냅니다. 프록시 연결과 대상 서버 요청 등 더 많은 구간을 측정하지만, 테스트 주소와 시간 제한 설정의 영향도 받습니다.
적합한 용도: 웹서핑용 노드를 고르고 요청이 완료되는지 먼저 확인할 때
다운로드 속도
테스트 파일을 일정 시간 동안 내려받아 수신 데이터량을 확인합니다. 결과는 파일 서버와 기기 성능, 동시에 진행 중인 전송의 영향도 받습니다.
적합한 용도: 대용량 파일 다운로드와 장시간 전송 성능을 비교할 때
TCPing은 모든 전송 방식에 공통으로 적용할 수 있는 지연 시간 측정법이 아닙니다. 노드가 TCP가 아닌 방식으로 연결된다면, 특정 TCP 포트의 핸드셰이크 시간을 노드의 실제 연결 시간으로 대신할 수 없습니다. 실제 연결 테스트도 현재 테스트 주소에 보낸 한 번의 요청만 보여줍니다. 대상 사이트의 DNS, 라우팅, 응답 속도가 바뀌면 측정값도 달라질 수 있습니다.
결론: 무엇을 측정했는지 확인한 뒤 수치를 비교하세요
같은 클라이언트와 테스트 주소를 사용해 비슷한 시간대에 측정한 실제 연결 지연끼리 비교하세요. TCPing은 연결 가능 여부를 미리 확인하는 용도로 사용하고, 웹페이지가 반드시 열린다는 근거로 삼지 마세요.
TCPing은 낮은데 웹페이지가 열리지 않는 이유
예를 들어 TCPing이 40 ms라면, 측정 당시 서버 포트와의 TCP 핸드셰이크가 빨랐다는 뜻입니다. 노드의 VMess 또는 VLESS 설정이 서버와 맞지 않을 수 있고, 프록시 연결이 완료된 뒤에도 대상 도메인 조회, 라우팅 분기, 대상 서버 응답 단계에서 문제가 생길 수 있습니다. 웹페이지가 열리지 않으면 먼저 테스트 주소 요청도 실패하는지, 특정 사이트만 실패하는지 구분하세요.
위 수치는 단위 차이를 설명하기 위한 예시일 뿐, 특정 노드의 성능을 보장하지 않습니다. 40 ms와 240 ms는 서로 모순되지 않습니다. 앞의 수치는 서버 포트와의 핸드셰이크까지만 측정하고, 뒤의 수치에는 클라이언트와 프록시 경로, 테스트 대상까지 포함됩니다. 5.8 MB/s는 전송 속도이므로 웹페이지의 첫 바이트를 기다리는 시간으로 환산할 수 없습니다. 10808은 로컬 수신 포트 번호로, 속도 측정값이 아닙니다.
- 먼저 실제 연결 테스트가 성공하는지 확인하세요. 실패하면 클라이언트 로그를 열어 연결 시간 초과, 인증 오류, 대상 요청 오류를 구분합니다.
- 현재 활성 노드가 방금 테스트한 노드인지 확인하고, 시스템 프록시나 앱 내 프록시가 현재 클라이언트를 사용하도록 설정되어 있는지 점검하세요.
- 라우팅 규칙에 따라 대상 도메인의 트래픽이 프록시를 거치는지 확인하세요. 같은 도메인이라도 직접 연결과 프록시 경로에서는 문제가 발생하는 지점이 다를 수 있습니다.
- 특정 사이트만 접속되지 않는다면 해당 도메인의 조회 결과와 대상 사이트 상태를 확인하세요. TCPing 한 번의 결과만으로 전체 구독 목록을 바꾸지 마세요.
v2rayN·v2rayNG에서 노드 비교하기
먼저 구독을 갱신하고 테스트 조건을 통일하세요. 테스트하는 동안에는 같은 네트워크를 유지하고 대역폭을 많이 쓰는 대용량 전송은 일시 중지하세요. 비교할 노드에는 같은 테스트 주소와 시간 제한을 적용합니다. 버전에 따라 메뉴 이름이 조금 다를 수 있으므로 현재 클라이언트에 표시된 안내를 따르세요.
추천 순서: 사용 가능한 노드를 추린 뒤 지속 전송 속도 측정
데스크톱: v2rayN
- 서버 목록에서 같은 노드들을 선택하고 TCPing을 실행해 포트에 연결할 수 없는 노드를 제외합니다.
- 그다음 서버 목록의 ‘서버 실제 연결 지연 테스트’ 기능을 사용해 성공 여부와 밀리초를 기록합니다.
- 후보 노드를 하나씩 활성 노드로 설정한 뒤 실제 웹페이지 요청으로 다시 확인합니다.
안드로이드: v2rayNG
- 구성 목록에서 후보 노드의 연결 테스트 또는 실제 연결 테스트를 실행하고 실패 메시지를 확인합니다.
- 선택한 구성을 활성화한 다음 시스템의 VPN 연결이 실제로 활성 상태인지 확인합니다.
- 같은 네트워크에서 자주 사용하는 페이지를 열어 보고, 전송 성능이 중요한 노드는 다운로드 테스트도 진행합니다.
각 기기에서 결과를 따로 기록하세요. 데스크톱의 유선 네트워크 결과와 안드로이드의 모바일 네트워크 결과를 그대로 비교해 순위를 매기면 안 됩니다.
v2rayN에서는 서버 목록 작업 메뉴에 실제 연결 테스트 항목이 표시되는 경우가 많습니다. v2rayNG의 테스트 위치와 일괄 테스트 명칭은 버전에 따라 달라질 수 있습니다. 같은 이름의 메뉴가 없으면 구성 목록 메뉴에서 연결 테스트 항목을 찾아보세요. 두 클라이언트 모두 테스트 주소를 확인해야 합니다. 테스트 대상의 응답이 느리면 모든 노드의 결과가 함께 느려질 수 있습니다.
후보 노드마다 간격을 두고 세 번씩 테스트해 성공 여부와 대략적인 지연 범위를 기록하세요. 예를 들어 A 노드는 180, 195, 188 ms가 연속으로 나오고 B 노드는 90 ms, 시간 초과, 310 ms가 나올 수 있습니다. B의 최저값만 보면 한 번의 실패와 큰 편차를 놓치게 됩니다. 웹서핑용으로는 요청이 안정적으로 완료되는 노드를 우선 선택하세요.
결론: 한 번의 최저 지연 시간보다 안정적인 요청 완료가 우선입니다
실제 연결이 반복해서 시간 초과되는 노드를 먼저 제외한 다음 안정적인 후보끼리 지연 시간을 비교하세요. 지속 다운로드가 주된 용도일 때만 다운로드 속도를 기준으로 최종 순위를 정하세요.
다운로드 속도 확인법과 재측정 시점
다운로드 속도와 지연 시간은 서로 다른 질문에 답합니다. 실제 연결 지연이 비슷해도 장시간 전송에서는 한 회선이 더 빠를 수 있고, 다운로드 속도가 비슷해도 작은 웹페이지는 다른 회선에서 더 빨리 열릴 수 있습니다. 다운로드 테스트에서는 파일 크기가 충분한지, 일정 시간 동안 전송이 지속됐는지 확인하세요. 시작 직후의 순간 최고 속도로 회선 전체를 판단하면 안 됩니다.
| 측정 결과 | 먼저 확인할 항목 | 다음 단계 |
|---|---|---|
| TCPing은 낮지만 실제 연결 시간 초과 | 프로토콜 설정, 노드 로그, 테스트 주소 | 요청 실패부터 해결한 뒤 순위를 비교하세요 |
| 실제 연결은 안정적이지만 다운로드가 느림 | 테스트 파일 출처, 동시 다운로드, 회선 혼잡 | 같은 테스트 파일로 다른 시간대에 다시 측정 |
| 다운로드는 빠른데 웹페이지는 여전히 느림 | 대상 사이트 응답, 도메인 조회, 라우팅 규칙 | 자주 쓰는 사이트를 각각 테스트하고 전송량으로 응답 시간을 대신하지 마세요 |
테스트 주소 자체도 결과에 영향을 줍니다. 다운로드 파일이 있는 서버에서 속도를 제한하면 측정값은 노드의 최대 속도가 아니라 ‘노드와 해당 파일 서버 조합’의 속도입니다. 라우팅 규칙에서 테스트 주소를 직접 연결로 지정했다면 다운로드 수치도 프록시를 통한 전송 성능을 나타내지 못합니다. 테스트 전에 트래픽이 현재 활성 노드를 실제로 통과하는지 확인하세요.
- 다시 측정할 때는 네트워크 종류와 테스트 대상, 파일 크기를 동일하게 맞추고 테스트 시간대도 기록하세요.
- MB/s와 Mbps를 구분해 기록하세요. 십진 단위로 대략 환산하면 1 MB/s는 약 8 Mbps입니다.
- 한 노드의 속도 측정이 끝나기 전에 다음 노드로 전환하지 마세요. 이전 연결이 계속 대역폭을 사용할 수 있습니다.
자주 나오는 결과와 대응 방법
노드 목록에 지연 시간이 낮은 항목이 여럿 보이면 먼저 실제 요청이 완료된 노드를 확인한 뒤 자주 사용하는 웹사이트로 재검증하세요. 한 번의 결과는 특정 시점의 상태만 보여줍니다. 네트워크 전환, 서버 부하, 대상 사이트의 변화에 따라 다음 테스트에서는 순서가 달라질 수 있습니다.
TCPing은 30 ms인데 실제 연결은 시간 초과되나요?
먼저 현재 노드의 주소와 포트, 프로토콜 설정을 확인한 다음 클라이언트 로그를 살펴보세요. TCP 포트에 연결할 수 있다는 사실은 일부 네트워크 문제를 제외할 뿐, VMess 또는 VLESS 프록시 요청이 성공했음을 의미하지 않습니다.
실제 연결 테스트는 성공했는데 브라우저에서 웹페이지가 열리지 않는 이유는?
브라우저가 시스템 프록시를 사용하거나 올바른 수동 프록시 포트를 지정했는지 확인하세요. 이어서 대상 도메인의 라우팅 규칙을 점검합니다. 테스트 주소에 접속할 수 있다고 해서 모든 도메인이 같은 경로를 사용하는 것은 아닙니다.
v2rayN과 v2rayNG의 지연 시간이 크게 다른가요?
먼저 두 클라이언트에서 같은 노드와 테스트 주소, 네트워크를 사용하는지 확인하세요. 그런 다음 양쪽의 코어 설정과 라우팅 설정을 점검합니다. 조건이 다르면 밀리초만으로 기기별 결과를 직접 비교하기 어렵습니다.
다운로드 테스트가 첫 1초에는 빠르다가 느려지나요?
전체 전송 과정의 평균 속도를 기록하고 같은 파일로 다른 시간대에 다시 측정하세요. 시작할 때의 최고 속도는 캐시나 순간적인 가용 대역폭의 영향을 받을 수 있으므로, 그것만으로 노드를 선택하지 마세요.
지연 시간이 가장 낮은 노드만 선택해야 하나요?
웹서핑용 노드는 요청이 실패하거나 지연 편차가 큰 항목을 먼저 제외한 뒤, 안정적인 후보의 실제 연결 지연을 비교하세요. 대용량 파일 전송이 목적이라면 다운로드 테스트를 추가하고 실제로 사용하는 시간대의 결과를 기준으로 삼으세요.
최종 선택은 사용 목적에 맞춰야 합니다. 웹페이지를 열 때는 요청이 안정적으로 완료되는지, 지속 전송에서는 일정 시간 동안의 속도가 어떤지 확인하고, 연결 구간 문제를 점검할 때는 TCPing을 우선 살펴보세요. 최저 지연 시간 하나만 저장하는 것보다 테스트 시간과 네트워크 종류, 실패 메시지를 함께 기록하는 편이 다음 문제를 찾는 데 도움이 됩니다.