v2rayN 지연 시간 테스트 방법: Tcping·실제 연결 지연·다운로드 속도 측정 차이

이 글의 핵심

Tcping은 서버 포트에 TCP 연결을 설정할 수 있는지 확인하고, 실제 연결 지연은 프록시를 거쳐 테스트 대상에 요청을 완료할 수 있는지 확인하며, 다운로드 속도 측정은 일정 시간 동안의 전송 처리량을 살펴봅니다. 지연 시간은 표시되는데 웹페이지가 열리지 않거나 지연 시간은 낮은데 다운로드가 느린 경우를 위한 안내입니다. 각 테스트 범위와 설정을 확인하고 결과를 조합하는 순서대로 문제를 점검해, 밀리초 수치 하나만 보고 노드를 고르는 일을 피할 수 있습니다.

Tcping·실제 연결 지연·다운로드 속도 측정은 무엇을 확인할까

v2rayN은 설정을 관리하고 프록시 코어를 실행하는 데스크톱 클라이언트입니다. 노드 목록의 테스트 결과는 서로 다른 측정 절차에서 나온 것으로, 같은 회선을 다른 단위로 표시한 값이 아닙니다. 측정 범위를 알아야 테스트 성공으로 어떤 문제가 배제됐는지, 또 무엇은 확인되지 않았는지 판단할 수 있습니다.

세 가지 테스트의 측정 범위
테스트 항목	주요 측정 대상	이 결과만으로 확인할 수 없는 것
Tcping	이 기기에서 노드 주소와 포트까지 TCP 연결을 설정하는 데 걸리는 시간	프록시 인증 정보가 올바른지, 대상 웹사이트에 접속할 수 있는지
실제 연결 지연	테스트 중인 프록시를 통해 지정된 테스트 URL에 요청하는 데 걸리는 시간	모든 웹사이트에 접속할 수 있는지, 지속적인 다운로드 속도가 빠른지
다운로드 속도 측정	테스트 중인 프록시를 통해 속도 측정 리소스를 읽을 때의 전송 속도	응답이 빠른지, 모든 다운로드 서버에서 같은 속도가 나오는지

측정 결과는 클라이언트 버전과 코어, 테스트 URL, 시간 초과 및 동시 실행 설정에도 영향을 받습니다. 실제 연결 지연에는 대개 프록시 연결, 필요한 핸드셰이크, 대상 서버의 응답 대기 시간이 포함되지만, 구체적인 측정 시작·종료 지점과 연결 재사용 방식은 구현에 따라 다릅니다. 이를 단일 네트워크 왕복 시간의 정밀한 측정값으로 볼 수 없으며, Tcping 결과를 빼서 서버 처리 시간을 계산해서도 안 됩니다.

Tcping은 정상인데 인터넷이 안 되는 이유

Tcping은 명령 프롬프트의 ICMP ping과 다릅니다. 서버가 ICMP에 응답하지 않아도 프록시 포트는 사용할 수 있습니다. 반대로 TCP 연결에 성공해도 해당 주소와 포트에서 연결을 받아들였다는 뜻일 뿐입니다. 포트 뒤의 서비스가 VMess 또는 VLESS를 처리하는지, 사용자 식별 정보가 유효한지, 전송 설정이 일치하는지는 아직 확인되지 않았습니다.

노드 주소 확인 TCP 연결 설정 프록시 핸드셰이크 테스트 사이트 연결 응답 수신

일반적인 TCP 기반 연결에서 Tcping은 주로 흐름의 앞부분을 확인합니다. 이후 TLS 핸드셰이크 실패, WebSocket 경로 오류, REALITY 공개 키 또는 서버 이름 불일치가 있으면 “Tcping 수치는 나오지만 실제 연결은 시간 초과”로 나타날 수 있습니다. 리버스 프록시나 중계 서버 뒤에 같은 주소가 연결된 경우 TCP 연결에 성공해도 입구에만 도달했을 뿐, 뒤쪽 프록시 서비스까지 확인하지 못했을 수 있습니다.

인증 정보: 구독을 업데이트했는지, 사용자 식별 정보나 비밀번호를 직접 변경하지 않았는지 확인하세요. 다른 노드의 값을 가져와 현재 설정에 섞어 쓰지 마세요.
전송 설정: WebSocket 경로, Host, TLS 서버 이름과 REALITY 관련 필드를 확인하고 서버에서 요구하는 조합을 그대로 유지하세요.
시스템 시간: 시스템 시간 동기화를 켜세요. 시간이 크게 어긋나면 인증서 유효 기간 판단에 영향을 주거나 시간 검증이 포함된 프로토콜 인증에 문제가 생길 수 있습니다.
서버 측 외부 연결: 연결을 받아들이는 입구가 정상이어도 서버의 DNS나 대상 웹사이트에 접속하는 네트워크에 문제가 있으면 실제 연결에 실패할 수 있습니다.

이런 결과 조합이 나타나면 코어 로그에서 핸드셰이크, 인증, DNS 확인 오류를 먼저 살펴본 다음 설정을 점검하세요. Tcping을 반복해도 새로운 구간을 확인할 수 없고 프로토콜 설정 오류도 해결되지 않습니다. 인증서나 인증 실패가 원인이라면 인증서 검증을 건너뛰어 문제를 가리는 것은 권장하지 않습니다.

실제 연결 지연: 테스트 대상과 실제 웹 탐색은 따로 확인

실제 연결 지연은 프록시 코어를 실행하거나 호출하고 테스트 중인 노드를 통해 지정된 주소에 요청하므로 Tcping보다 일상적인 요청에 가깝습니다. “이 설정으로 프록시 요청 하나를 완료할 수 있는지” 판단하는 데 유용하지만, 특정 요청 하나만 확인할 뿐 브라우저 접속 전체 과정을 검사하지는 않습니다.

실제 연결 테스트 조건

설정 경로: 「설정」→「매개변수 설정」의 속도 측정 관련 옵션
대상 주소: 화면에 실제로 설정된 지연 시간 테스트 URL 기록
변수 통제: 테스트 중 URL, 네트워크, 시간 초과 설정을 바꾸지 않기

버전에 따라 항목 이름과 위치가 다를 수 있으므로 현재 화면의 테스트 주소와 시간 초과 설정을 기준으로 확인하세요.

브라우저 접속 조건

앱 연결: 브라우저가 시스템 프록시를 사용하거나 로컬 프록시를 직접 설정했는지 확인
노드 선택: 현재 활성 노드가 방금 테스트한 노드인지 확인
라우팅 확인: 로그에서 웹사이트 요청이 프록시를 거치는지 직접 연결되는지 확인

내장 테스트는 테스트 대상 프록시를 직접 호출할 수 있으므로 시스템 프록시가 켜져 있어야 하는 것은 아닙니다.

따라서 실제 연결은 성공했는데 브라우저에서 접속이 안 되는 상황은 모순이 아닙니다. 브라우저가 프록시를 사용하지 않거나 확장 프로그램에서 별도의 프록시 설정을 사용할 수 있습니다. 웹사이트 도메인은 직접 연결 규칙에 걸리고 테스트 URL은 프록시를 사용할 수도 있습니다. 브라우저에서 요청을 보내는 동안 로그를 확인해 요청이 코어에 전달됐는지, 어떤 아웃바운드가 적용됐는지 살펴보세요.

반대로 브라우저에서 자주 쓰는 웹사이트가 열려도 실제 연결 테스트가 실패할 수 있습니다. 테스트 사이트에 접속할 수 없거나, 응답 내용이 테스트 구현의 예상과 다르거나, 시간 초과가 너무 짧을 수 있습니다. 먼저 같은 노드로 테스트 대상에 접속해 본 다음, 사용 가능한 것으로 확인된 다른 경량 테스트 대상으로 다시 측정하세요. 대상을 바꾸는 목적은 테스트 조건을 확인하는 것이며, 더 낮은 수치가 쉽게 나오는 대상을 고르는 것이 아닙니다.

노드 목록에서 테스트할 항목을 몇 개 선택한 뒤 마우스 오른쪽 버튼 메뉴에서 이름에 “실제 연결 지연”이 포함된 테스트 항목을 찾으세요.
이번 테스트가 끝날 때까지 기다린 뒤 성공 또는 실패 여부와 현재 테스트 대상을 기록하세요. 메뉴 이름은 사용 중인 버전에 따라 다를 수 있습니다.
성공한 노드 중 하나를 활성 노드로 설정한 다음 브라우저에서 실제로 사용할 웹사이트에 접속하세요.
결과가 다르면 시스템 프록시, 로컬 수신 포트, 브라우저 프록시 설정, 라우팅 로그를 확인하세요.

다운로드 속도 측정: 처리량·단위·리소스 사용량

다운로드 속도 측정은 일정 시간 동안 데이터를 수신하는 능력을 확인합니다. 회선 대역폭, 서버 부하, 패킷 손실, 혼잡 제어, 속도 측정 파일이 있는 사이트, 측정 시간 모두 결과에 영향을 줍니다. 지연 시간이 낮으면 대화형 응답에 유리하지만 지속적인 전송 처리량이 높다는 보장은 없습니다. 대역폭이 큰 장거리 회선이라도 실제 연결 지연이 가장 낮게 나오지 않을 수 있습니다.

단위부터 확인: MB/s와 Mbps는 같은 단위가 아닙니다. 십진법 기준으로 1 MB/s는 8 Mbps입니다. 화면에 MiB/s가 표시된다면 이진법 기준으로 따로 환산해야 합니다.
대역폭을 나눠 쓰지 않도록 주의: 대용량 파일 다운로드, 클라우드 동기화, 다른 노드의 속도 측정을 일시 중지하세요. 그렇지 않으면 공유 회선에서 발생한 경쟁이 측정 결과에 반영됩니다.
소수의 노드부터 재측정: 실제 연결에 성공한 노드 중 후보를 몇 개 골라 테스트하세요. 처음부터 구독 목록 전체를 대상으로 다운로드 속도를 측정하지 마세요.
사용량 확인: 속도 측정은 실제 다운로드 트래픽을 발생시키며 시스템이나 서버의 트래픽 한도에 포함될 수 있습니다. 반복 측정에 비용이 들지 않는 것은 아닙니다.

짧은 다운로드는 연결 설정과 전송 속도가 오르는 과정의 영향을 받기 쉽고, 오래 다운로드하면 부하 변화가 생길 가능성이 커집니다. 순간 최고 속도가 높다가 이후 크게 떨어진다면 최고값만 기록하지 말고 안정적으로 전송되는 구간을 확인하세요. 속도 측정 리소스마다 서로 다른 네트워크에 있을 수 있습니다. 테스트 서버 자체에 속도 제한이 있다면 그 결과만으로 노드의 외부 회선 대역폭이 부족하다고 단정할 수 없습니다.

포트와 테스트 순서: 사용 가능 여부를 확인한 뒤 속도 비교

문제를 점검할 때 노드 포트, 로컬 수신 포트, 대상 웹사이트 포트를 혼동하기 쉽습니다. 이 세 포트는 서로 다른 연결 구간에 있습니다. 아래 숫자는 포트별 역할을 설명하기 위한 예시일 뿐 모든 노드에 적용되는 설정 권장값도, 현재 v2rayN의 고정 기본값도 아닙니다.

443

HTTPS에서 흔히 쓰는 대상 포트입니다. 노드에서도 사용할 수 있으므로 설정을 확인하세요.

HTTP에서 흔히 쓰는 대상 포트이며, 프록시 서비스가 반드시 이 포트에서 수신한다는 뜻은 아닙니다.

10808

로컬 프록시 포트 예시입니다. 앱에 입력하기 전에 실제 수신 포트를 확인하세요.

예를 들어 어떤 앱이 127.0.0.1:10808에 연결한다면 연결 대상은 로컬 수신 주소이지 원격 노드의 443 포트가 아닙니다. 현재 설정이 10808에서 해당 앱에 필요한 프록시 프로토콜을 제공할 때만 이 입력이 유효합니다. 포트 번호가 같다고 프로토콜까지 같은 것은 아니며, HTTP 프록시와 SOCKS 프록시를 임의로 바꿔 입력해서는 안 됩니다.

설정 확인: 구독을 업데이트한 뒤 노드 주소, 포트, 전송 정보를 확인하세요. 코어 시작 오류가 있다면 먼저 해결해야 합니다.
Tcping으로 1차 선별: TCP 연결 설정에 뚜렷한 문제가 있는지 확인하되 최저 수치만 보고 바로 활성 노드를 정하지 마세요.
실제 연결로 재선별: 후보 노드에 같은 테스트 URL을 사용하세요. 실패한 항목은 로그를 살펴보고, 성공한 항목은 다음 단계로 진행합니다.
다운로드 속도 측정으로 보완: 지속적인 전송이 필요한 후보만 측정하고, 같은 리소스를 사용해 속도가 안정적인지 살펴보세요.
실제 앱으로 확인: 필요한 연결 방식을 켜고 자주 사용하는 웹사이트에 접속해 라우팅과 로그가 예상대로 작동하는지 확인하세요.

같은 조건에서 3회 반복 측정하고 최고값 하나만 남기지 말고 중간 수준과 실패 횟수를 기록하는 것을 권장합니다. 이는 비교 방법일 뿐 성능을 보장하지 않습니다. 업무 시간과 저녁 시간의 부하가 다르다면 각각 기록해 두세요. 이른 아침 결과만으로 사용량이 많은 시간대의 성능을 판단하지 않도록 할 수 있습니다.

자주 나오는 결과 조합: 실패한 구간부터 처리

Tcping 결과는 나오는데 실제 연결이 계속 시간 초과되면 무엇부터 바꿔야 하나요?

먼저 로그를 열고 노드 하나만 따로 테스트하세요. 인증에 실패하면 구독을 업데이트하고 사용자 식별 정보를 확인합니다. TLS 또는 REALITY 핸드셰이크 오류가 나면 서버 이름, 공개 키 등 관련 설정을 확인하고, DNS 확인에 실패하면 해당 도메인의 DNS를 점검하세요. 전송, 라우팅, DNS를 한꺼번에 바꾸면 어떤 변경이 효과가 있었는지 알 수 없습니다.

실제 연결은 정상인데 브라우저에서 페이지가 열리지 않나요?

먼저 해당 노드를 활성 노드로 설정하고 기본 화면의 시스템 프록시 옵션에서 현재 사용 방식에 맞는 설정을 선택하세요. 이어서 브라우저에 별도 프록시가 설정되어 있는지, 로컬 포트가 앱에 입력한 값과 일치하는지 확인합니다. 요청이 코어에 전달된 것이 확인되면 테스트 주소를 바꾸는 대신 대상 도메인에 적용된 라우팅 규칙을 살펴보세요.

지연 시간은 매우 낮은데 다운로드가 느린 이유는 무엇인가요?

먼저 다른 다운로드를 일시 중지한 다음 같은 속도 측정 리소스로 후보 노드를 하나씩 테스트하세요. 특정 다운로드 사이트에서만 느리다면 대상 사이트의 속도 제한이나 노드에서 해당 사이트까지의 경로를 확인하세요. 여러 리소스에서 모두 느리다면 로컬 대역폭, 노드 혼잡, 시간대별 성능을 비교하세요. 밀리초 수치만으로 다운로드 대역폭을 환산할 수는 없습니다.

결과가 -1 또는 시간 초과로 표시되면 노드를 더는 사용할 수 없는 건가요?

음수나 시간 초과는 보통 이번 측정에서 유효한 결과를 얻지 못했다는 뜻입니다. 구체적인 표시는 버전에 따라 다르며 “음수 지연 시간”을 의미하지 않습니다. 테스트 대상에 접속할 수 있는지, 코어가 정상적으로 시작됐는지 확인한 다음 같은 노드를 다시 측정하세요. 여러 노드에서 동시에 실패한다면 공통 테스트 주소, 로컬 네트워크, 수신 포트를 먼저 점검하세요.

노드 선택: 사용 가능 여부를 우선하고 안정성을 비교

일상적인 웹 탐색을 위해서는 실제 연결에 반복해서 실패하는 노드를 먼저 제외한 다음 여러 번 측정했을 때의 응답과 변동 폭을 비교하세요. 대용량 파일을 전송해야 한다면 다운로드 속도의 지속성도 확인하세요. 한 가지 항목만 뛰어난 노드가 모든 용도에 적합한 것은 아닙니다. 모든 네트워크와 웹사이트에 통용되는 합격 기준 지연 시간도 없습니다.

웹 탐색과 대화형 사용: 실제 웹사이트에 접속할 수 있고 연결 성공률이 안정적이며, 여러 차례 측정한 실제 연결 지연이 크게 변하지 않는 노드를 우선하세요.
지속적인 다운로드: 사용 가능한 노드 중 같은 리소스에서 안정적으로 전송되는 속도를 비교하고 트래픽 사용량도 확인하세요.
문제 재현 기록: 테스트 시간, 네트워크, 대상 URL, 오류 유형, 라우팅 결과를 기록하세요. 구독 주소나 인증 정보는 공개하지 마세요.

세 가지 테스트는 확인 범위를 단계적으로 넓히는 방식으로 이해할 수 있습니다. Tcping은 연결 입구를, 실제 연결은 프록시 요청 하나를, 다운로드 속도 측정은 지속적인 전송을 확인합니다. 마지막으로 실제 앱에서도 테스트해야 “목록에 수치가 표시된다”는 상태를 넘어 “현재 사용 방식에서 실제로 작동한다”고 판단할 수 있습니다. 연결 방식과 분할 라우팅 설정을 더 확인하려면 라우팅 설정 안내를 참고하세요. 구독을 업데이트할 수 없다면 구독 문제 해결을 확인하세요.