V2Ray 지연 시간 측정 가이드: TCPing, 프록시 연결 지연, 다운로드 속도 차이

세 가지 측정: 포트 연결, 요청 성공 여부, 실효 전송량

일상적인 노드 선별에는 실제 연결 지연, 접속 지점 확인에는 TCPing, 대용량 전송에는 다운로드 속도 측정이 적합합니다. 세 가지는 같은 지표의 정밀도 차이가 아니며, 밀리초와 초당 메가바이트를 하나의 점수처럼 비교할 수도 없습니다. 노드 입구가 가까워도 프록시 출구에서 웹사이트까지 가까운 것은 아닙니다. 응답이 빨라도 지속 전송 대역폭이 넓다는 뜻은 아닙니다.

일반 Ping은 대개 ICMP를 사용하고 TCPing은 TCP 연결을 사용하므로 두 결과를 같은 의미로 해석하면 안 됩니다. 서버가 ICMP를 거부하면 Ping은 시간 초과가 나도 프록시는 정상 작동할 수 있습니다. 반대로 Ping 응답이 있다고 해서 프록시 포트가 열려 있다는 뜻도 아닙니다. 노드가 UDP 기반 전송을 사용한다면 TCP 포트 탐색 결과는 해당 노드의 사용 가능 여부를 판단하는 필수 조건이 될 수 없습니다.

TCPing은 빠른데 연결되지 않음: 프록시 핸드셰이크 전 단계만 측정한 경우

TCPing 성공은 특정 TCP 포트가 연결을 받아들였다는 뜻일 뿐입니다. 예를 들어 서버 입구가 443 포트를 사용하더라도 연결 수립 후 TLS 검증, 전송 경로, 프록시 인증 단계에서 실패할 수 있습니다. 해당 포트가 리버스 프록시를 통해 연결될 수도 있으며, TCP 연결을 받은 장치가 최종 프록시 프로세스라고 단정할 수 없습니다.

v2rayN 기본 창에서 노드를 선택하고 마우스 오른쪽 버튼을 눌러 서버 편집 창을 여세요. 구독 정보와 설정값을 대조하고, 지연 시간을 낮추려고 SNI를 임의로 바꾸지 마세요. TLS를 사용하는 노드는 시스템 시간도 정확해야 합니다. Windows에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 자동 시간 설정과 동기화 상태를 확인할 수 있습니다.

• 모든 노드 입구에서 시간 초과: 먼저 PC의 인터넷 연결, 구독 유효 여부, 서버 주소의 DNS 조회 결과를 확인하세요.
• 입구 연결은 되지만 실제 연결에 실패: 로그에서 TLS, 인증 또는 전송 오류를 확인한 뒤 노드 설정을 대조하세요.
• 특정 대상 하나에만 실패: 신뢰할 수 있는 다른 테스트 대상으로 비교해 보세요. 노드 전체가 오프라인이라고 바로 단정하지 마세요.

실제 연결 지연: 테스트 주소와 실제 경로가 중요합니다

실제 연결 테스트는 측정할 노드를 거쳐 HTTP 또는 HTTPS 요청을 보내는 방식이 일반적입니다. 새 연결을 만들 때는 서버 주소 조회, 프록시 입구 연결, TLS 및 프록시 협상, 출구에서 대상에 연결하는 시간, 대상 응답 시간이 포함될 수 있습니다. TCPing보다 ‘프록시를 통해 웹사이트를 여는 상황’에 가깝지만, 모든 웹페이지와 앱에 공통으로 적용되는 지연 시간은 아닙니다.

HTTPS 테스트 주소를 사용하면 대상 사이트의 TLS 처리, 리디렉션, 응답 속도, 연결 재사용 여부도 측정값에 영향을 줄 수 있습니다. 클라이언트에 표시되는 값을 순수한 네트워크 왕복 지연 시간으로 해석해서는 안 됩니다. 두 테스트의 측정 시점과 범위가 다르므로 ‘실제 연결 지연 - TCPing’으로 출구 지연 시간을 단순 계산할 수도 없습니다.

1. v2rayN 서버 목록에서 노드를 몇 개 선택한 뒤 마우스 오른쪽 버튼을 누르고 ‘서버 실제 연결 지연 시간 테스트’와 비슷한 이름의 항목을 선택하세요. 일부 버전에서는 항목 이름에 ‘다중 선택’이 붙습니다.
2. 테스트 대상을 확인하려면 ‘설정’ → ‘매개변수 설정’으로 이동한 뒤 v2rayN 설정 관련 페이지에서 ‘실제 연결 테스트 주소’를 확인하세요. 버전에 따라 메뉴 이름이 조금 다를 수 있으니 현재 창에 표시된 이름을 기준으로 하세요.
3. 노드를 비교할 때는 같은 테스트 주소를 사용하세요. 모든 노드에서 테스트가 실패하면 먼저 해당 주소가 정상적으로 응답하는지 확인하세요.
4. 노드를 선택한 뒤 브라우저에서 실제로 방문하려는 웹사이트를 열어 보세요. 클라이언트 로그도 확인해 요청이 의도한 출구를 통해 전달되는지 점검하세요.

도메인 조회가 이뤄지는 곳도 여러 군데입니다. 노드 서버 주소와 대상 도메인의 DNS 조회를 같은 구성 요소가 담당한다고 볼 수 없습니다. 로컬에서 조회할지 원격에서 조회할지는 코어와 설정에 따라 달라집니다. 지연 시간이 높다는 이유만으로 모든 DNS 설정을 바꾸지 마세요. 먼저 로그에서 노드 연결 실패인지 대상 연결 실패인지 구분하세요.

다운로드 속도 측정: MB/s, Mbps와 테스트 데이터 사용량

다운로드 속도가 높다는 것은 해당 테스트 경로의 실효 전송량이 많다는 뜻이지, 웹페이지 첫 화면이 반드시 빨리 뜬다는 뜻은 아닙니다. 속도 측정 서버의 위치, 단일·다중 연결 방식, 테스트 시간, 노드 공유 부하에 따라 결과가 달라집니다. 속도 테스트는 실제 데이터를 전송하므로 구독 데이터 한도를 사용할 수 있습니다. 특히 모바일 데이터 사용 시 남은 용량을 먼저 확인하세요.

아래는 단위 환산 예시입니다. 십진 단위를 기준으로 수신 속도가 10 MB/s로 안정적으로 유지되고 20초간 전송한다고 가정하면 전송량은 약 200 MB입니다. 실제 클라이언트는 다른 단위를 표시할 수 있고 준비 단계 등의 추가 전송이 포함될 수 있으므로, 이 예시를 매번 동일하게 발생하는 사용량으로 간주하지 마세요.

• 단위를 통일하세요: 열 이름이 MB/s, MiB/s, Mbps 중 무엇인지 확인한 뒤 값을 비교하세요.
• 한 번에 하나씩 실행하세요: 여러 다운로드 테스트를 동시에 하면 로컬 대역폭을 나눠 쓰므로, 낮은 결과가 노드 속도 제한 때문이라고 단정할 수 없습니다.
• 백그라운드 작업을 멈추세요: 다운로드, 클라우드 동기화, 시스템 업데이트는 대역폭을 차지합니다. 업로드 대역폭이 꽉 차면 요청 지연도 늘어날 수 있습니다.
• 지속 속도를 기록하세요: 시작 시점의 최고 속도는 캐시와 일시적인 전송 증가에 영향을 받을 수 있으므로, 일정 시간 동안의 안정적인 속도를 대신할 수 없습니다.

PC와 Android: 같은 조건으로 비교하기

v2rayN, v2rayNG, v2flyNG는 인터페이스와 코어 조합이 달라 테스트 방식도 다를 수 있습니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 같은 구독을 가져왔더라도 양쪽에서 같은 서버, 포트, 전송 설정을 선택했는지 확인하세요. 노드 메모만 보고 설정이 같다고 판단하면 안 됩니다.

현재 v2flyNG 버전에 표시되는 테스트 항목이 다르면 실제 항목 이름을 기록하세요. 일반 연결 테스트를 다운로드 속도 측정이라고 바꿔 부르면 안 됩니다. 코어를 바꾼다고 속도가 반드시 빨라지는 것도 아닙니다. 프로토콜과 전송 방식이 지원되어야 하며, 병목은 무선 신호, 통신사 경로, 원격 대역폭에 있을 수도 있습니다.

1. 환경을 고정하세요: 다른 프록시 연결을 끄고 백그라운드 다운로드를 중지한 뒤 같은 네트워크를 사용하세요.
2. 세 차례 반복하세요: 매회 약 10초 간격을 두고 실제 연결 결과와 실패 횟수를 기록하세요. 유효한 값이 세 개라면 중앙값을 사용하고, 실패는 별도로 기록하세요.
3. 시간대를 달리해 다시 측정하세요: 낮과 저녁에 각각 한 그룹씩 테스트하고 같은 대상으로 부하 변화를 확인하세요. 가장 좋은 결과 하나만 남기지 마세요.
4. 실제 작업을 확인하세요: 필요한 용도에 따라 브라우저, 동영상, 파일 다운로드를 각각 테스트하세요. 실제 작업을 종합 점수 하나로 대신하지 마세요.

자주 묻는 질문: 시간 초과, 음수 값, 측정값 변동 대처법

우선순위는 사용 가능 여부, 안정성, 필요에 따른 전송 속도 순입니다. 일반 웹 탐색에는 실제 연결이 연속해서 성공하고 응답 편차가 작은 노드를 선택하세요. 대용량 파일을 받을 때는 다운로드 테스트를 추가로 진행하면 됩니다. 문제가 생기면 TCPing, 실제 연결, 실제 작업 결과를 각각 기록해야 입구, 프록시 설정, 출구 또는 라우팅 중 어디를 확인할지 파악할 수 있습니다.