노드 목록의 밀리초 수치와 다운로드 속도는 서로 다른 정보를 보여줍니다. Tcping은 서버 포트에 연결할 수 있는지, 실제 연결 지연은 프록시 요청이 완료되는지, 다운로드 속도 테스트는 지속적인 전송 성능을 확인합니다. 지연 시간은 낮은데 웹페이지가 열리지 않거나, 실제 연결은 시간 초과되지만 포트는 정상인 경우에 참고하세요. 각 테스트의 범위와 결과 해석, 점검 순서를 살펴보며 단일 수치만으로 정렬하지 않고 사용 가능한 노드를 고르는 방법을 안내합니다.
세 가지 테스트가 확인하는 구간
먼저 연결 경로를 나눠 보겠습니다. 내 PC가 노드 서버에 연결하고, 프록시 코어가 프로토콜과 전송 계층을 협상한 뒤, 노드가 대상 웹사이트에 접속합니다. 노드 서버가 응답한다고 인증까지 성공한 것은 아니며, 인증에 성공해도 대상 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 테스트마다 확인하는 구간이 다르므로 결과를 서로 대체할 수 없습니다.
Tcping: 서버 포트 연결 가능 여부
노드 주소와 포트에 TCP 연결을 시도해 연결 수립에 걸리는 시간을 주로 확인합니다. VMess 또는 VLESS 인증 정보는 검증하지 않으며 대상 웹페이지에 요청을 보내지도 않습니다.
적합한 용도: 포트에 연결할 수 없거나 서버 주소가 잘못된 등 기본 연결 문제를 빠르게 걸러낼 때
실제 연결 지연: 프록시 요청 사용 가능 여부
권장테스트할 노드를 통해 지정된 테스트 주소로 요청을 보내며, 프록시 프로토콜 협상과 노드의 외부 접속까지 확인합니다. 일반적인 웹 요청과 더 가까운 테스트지만, 결과는 해당 테스트 대상에만 해당합니다.
적합한 용도: 평소 사용할 노드를 고를 때 프록시 요청을 완료할 수 있는 후보를 먼저 추릴 때
다운로드 속도 테스트: 지속 전송 성능
테스트할 노드를 통해 데이터를 다운로드하고 일정 시간 동안의 전송 속도를 확인합니다. 테스트 서버, 네트워크 혼잡, 측정 시간, 동시 연결 수가 모두 결과에 영향을 줍니다.
적합한 용도: 연결이 정상임을 확인한 뒤 대용량 파일 다운로드처럼 지속적인 트래픽이 필요한 상황을 비교할 때
v2rayN 메인 창에서 서버를 선택하고 마우스 오른쪽 버튼을 눌러 ‘서버 지연 시간 테스트 Tcping’, ‘서버 실제 연결 지연 테스트’, ‘서버 속도 테스트’와 같은 메뉴를 찾아보세요. 화면 구성과 버전에 따라 메뉴 이름이나 위치가 달라질 수 있으므로 현재 메뉴를 기준으로 사용해야 합니다. 특정 버전의 단축키가 모든 버전에서 통한다고 가정하지 마세요.
Tcping 수치는 낮은데 웹페이지가 열리지 않는 이유
Tcping은 운영체제의 ping과 다릅니다. 일반적인 ping은 ICMP를 사용하지만, 여기서는 TCP 포트를 확인합니다. 서버가 ICMP 응답을 비활성화해도 TCP 연결은 허용할 수 있습니다. 반대로 ping에 응답하는 호스트라도 노드에서 사용하는 포트가 열려 있다고 볼 수는 없습니다.
노드 주소에 도메인을 입력했다면 연결 전에 주소를 확인해야 합니다. 도메인 조회 시간이 결과에 포함되는지는 테스트 구현에 따라 다르므로, Tcping 수치만 보고 DNS가 정상이라고 단정할 수 없습니다. 실제 전송에 TCP를 사용하지 않는 설정이라면 TCP 탐색으로 실제 프로토콜 테스트를 대신할 수도 없습니다.
- 포트는 열렸지만 인증 정보가 잘못된 경우: UUID, 비밀번호 또는 프로토콜 매개변수가 틀려도 TCP 연결은 성공할 수 있지만 프록시 요청은 실패합니다.
- 진입점은 연결되지만 전송 설정이 일치하지 않는 경우: WebSocket 경로, Host 또는 TLS 서버 이름 설정이 맞지 않으면 이후 협상 단계에서 거부될 수 있습니다.
- 앞단 서비스가 응답하는 경우: 역방향 프록시나 CDN을 사용하는 노드라면 Tcping은 백엔드 프록시 서비스 전체가 아니라 앞단 진입점을 측정할 수 있습니다.
- 외부 접속이 제한된 경우: 노드가 연결을 받아도 외부 네트워크 장애나 대상 사이트의 제한 등으로 테스트 사이트의 주소를 확인하거나 접속하지 못할 수 있습니다.
판단 기준: 포트 연결을 확인한 뒤 프록시 요청 테스트
Tcping 결과는 있는데 웹페이지가 열리지 않는다면 다음으로 실제 연결 지연을 테스트하고 코어 로그를 확인하세요. 밀리초 수치가 낮다는 이유만으로 로컬 시스템 프록시 설정을 반복해서 바꾸지 마세요.
실제 연결 지연에 포함되는 항목과 시간 초과 점검 방법
실제 연결 지연은 단순히 ‘내 PC와 서버 사이의 거리’를 나타내는 값이 아닙니다. 보통 노드 연결, 프록시 프로토콜 협상, 노드의 테스트 주소 접속, 응답 대기 단계가 포함됩니다. HTTPS 테스트 주소를 사용하면 해당 TLS 과정도 포함됩니다. 구체적인 측정 범위와 연결 재사용 방식, 성공 판정은 버전에 따라 다를 수 있으므로 서로 다른 도구의 결과를 그대로 비교해 순위를 매기는 것은 적절하지 않습니다.
먼저 ‘설정’ → ‘매개변수 설정’에서 실제 연결 테스트 주소, 속도 테스트 주소, 시간 초과 관련 옵션을 찾아보세요. 화면에 탭이 여러 개라면 ‘테스트’ 또는 ‘속도’ 관련 설정을 확인합니다. 실제 URL을 기록한 뒤 노드별로 비교하세요. 빈 응답이나 작은 데이터를 반환하는 테스트 주소는 요청 지연을 확인하는 데 적합하고, 대용량 파일 주소는 전송량을 측정하는 데 적합합니다. 두 주소의 용도는 다릅니다.
- 노드 하나씩 테스트하세요. 일괄 작업을 일시 중지하고 같은 노드를 다시 테스트해, 동시 연결이 로컬 대역폭을 차지하거나 서버 측 제한을 유발하지 않도록 하세요.
- 노드 설정을 확인하세요. 서버 목록에서 해당 항목을 편집하고 출처와 대조해 주소, 포트, 인증 정보, 전송 방식, TLS 설정을 확인하세요. 추측으로 필드를 채우지 마세요.
- 시스템 시간을 확인하세요. 운영체제에서 자동 시간 동기화를 켜세요. 시간이 크게 어긋나면 인증서 검증에 문제가 생길 수 있고, 시간 조건이 있는 프로토콜 인증에도 영향을 줄 수 있습니다.
- 로그에서 실패 단계를 확인하세요. 연결 시간 초과는 우선 연결 가능 여부를, 인증서 오류는 시간과 서버 이름을, 인증 또는 전송 오류는 노드 설정을 확인하세요. timeout 하나만으로 어느 쪽에서 문제가 발생했는지 단정할 수는 없습니다.
- 접속할 수 있는 다른 테스트 대상으로 다시 확인하세요. 원래 대상에만 실패한다면 노드 외부에서 해당 대상까지의 연결을 계속 점검하세요. 노드 전체에 문제가 있다고 바로 단정하지 마세요.
다운로드 속도 테스트 읽는 법: 단위·시간·트래픽
다운로드 속도 테스트는 응답 지연이 아니라 전송량을 측정합니다. 지연 시간이 긴 회선도 다운로드를 계속하는 동안에는 높은 속도를 낼 수 있고, 지연 시간이 짧은 회선도 외부 대역폭이나 서버 속도 제한 때문에 느려질 수 있습니다. 첫 요청의 반응 속도와 장시간 다운로드의 안정성은 따로 판단해야 합니다.
위 대역폭 수치는 단위 환산 예시이며 이 사이트에서 측정한 결과가 아닙니다. 대문자 B와 소문자 b를 구분하세요. MB/s는 초당 메가바이트, Mbps는 초당 메가비트입니다. 화면에 MiB/s가 표시된다면 환산 기준도 MB/s와 다릅니다. 비교 전에 단위를 통일하고, 통신사에서 안내하는 회선 속도와 테스트 화면의 수치를 단순히 빼서 비교하지 마세요.
- 테스트 서버를 동일하게 유지하세요: 같은 노드라도 다운로드 주소를 바꾸면 결과가 달라질 수 있습니다. 테스트 서버 자체의 속도 제한과 부하, 위치가 모두 결과에 영향을 줍니다.
- 테스트 조건을 동일하게 유지하세요: 같은 네트워크와 비슷한 시간대, 동일한 속도 테스트 설정을 사용하세요. 대용량 다운로드, 클라우드 동기화 등 대역폭을 사용하는 작업은 일시 중지합니다.
- 순간 최고 속도만 보지 마세요: 짧게 테스트하면 연결 수립과 전송 가속 단계의 영향을 받을 수 있습니다. 클라이언트가 평균값이나 다른 통계값 중 무엇을 표시하는지 확인한 뒤 결과를 해석하세요.
- 데이터 사용량을 확인하세요: 10 MB/s로 10초 동안 계속 다운로드하면 프로토콜 오버헤드를 제외하고 약 100 MB를 사용합니다. 여러 노드를 일괄 테스트하면 사용량은 계속 누적됩니다.
테스트 결과를 노드 선택 순서에 활용하기
모든 노드의 다운로드 속도를 먼저 측정하지 마세요. 연결 가능 여부를 확인하고, 실제 요청을 테스트한 다음, 후보 몇 개만 골라 전송량을 비교하면 문제 범위를 좁히고 불필요한 데이터 사용을 줄일 수 있습니다. 아래 표는 결과 조합을 해석하는 기준이며 특정 노드 묶음의 성능 기록이 아닙니다.
| 결과 조합 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| Tcping 성공, 실제 연결 시간 초과 | 진입점에는 연결됐지만 이후 프록시 요청이 완료되지 않음 | 프로토콜 설정, 코어 로그, 테스트 대상 확인 |
| 실제 연결 성공, 다운로드 속도 낮음 | 기본 요청은 가능하지만 전송량이 제한됨 | 테스트 서버를 동일하게 유지하고 로컬 대역폭 사용 작업을 중지한 뒤 재측정 |
| 실제 연결은 느리지만 지속 다운로드는 빠름 | 응답 지연과 지속 전송 성능이 다르게 나타남 | 웹 이용 또는 파일 다운로드 등 실제 용도에 맞춰 선택 |
| 테스트 성공, 브라우저 접속 실패 | 앱의 프록시 연결이나 대상 라우팅이 다를 수 있음 | 시스템 프록시, 브라우저 설정, 적용된 규칙 확인 |
실행 방법: 요청이 안정적으로 완료되는 노드를 추린 뒤 전송량 비교
후보 노드마다 실제 연결 테스트를 세 차례 진행하고 실패 횟수와 소요 시간 변화를 기록하세요. 반복해서 시간 초과되는 항목을 먼저 제외한 뒤 남은 후보의 다운로드 속도를 테스트합니다. 마지막으로 실제로 접속해야 하는 웹사이트에서 한 번 더 확인하세요.
세 차례 결과를 작은 값부터 정렬해 가운데 값을 이번 비교의 참고값으로 삼고, 실패 기록도 함께 남기세요. 시간 초과를 0ms로 기록해 평균을 내면 실패한 노드가 ‘더 빠른’ 것으로 계산됩니다. 시간대별 결과도 나눠 기록하세요. 저녁 시간대의 혼잡을 낮에 한 번 측정한 결과로 설명할 수는 없습니다.
지연 시간 테스트 FAQ
-1 또는 시간 초과로 표시되면 노드를 완전히 사용할 수 없다는 뜻인가요?
꼭 그렇지는 않습니다. 음수 값이나 시간 초과는 일반적으로 테스트 실패 상태이지 실제 지연 시간이 아닙니다. 먼저 노드 하나만 다시 테스트하고 테스트 주소와 로그를 확인하세요. 여러 노드가 같은 대상에서만 실패한다면 테스트 대상을 바꿔 확인하세요. 한 노드만 계속 실패한다면 해당 노드 설정과 서비스 상태를 점검하세요.
방금 테스트했을 때는 빨랐는데 잠시 후 느려지는 이유는 무엇인가요?
목록에 표시된 수치는 한 번의 테스트 결과일 뿐 지속적인 모니터링 값이 아닙니다. 같은 테스트 대상을 사용해 세 차례 소요 시간과 실패 여부를 기록하고 백그라운드 다운로드는 일시 중지하세요. 특정 시간대에만 변동이 크다면 그 시간대의 실제 접속 상태를 비교하세요. 한 번 최고 속도가 나왔다고 전체 설정을 바로 바꿀 필요는 없습니다.
노드 테스트 전에 시스템 프록시나 TUN을 먼저 켜야 하나요?
내장 테스트는 보통 테스트할 노드를 거치는 경로를 구성하므로 시스템 프록시나 TUN을 켜는 것이 필수 조건은 아닙니다. 먼저 코어가 정상적으로 시작되는지 확인하세요. 테스트에 성공한 뒤 브라우저 등 앱에서 사용할 연결 방식을 선택하면 됩니다. 여러 연결 방식을 동시에 사용한다면 트래픽이 되돌아오거나 경로가 혼동되지 않는지도 확인하세요.
실제 연결이 가장 빠른 노드가 다운로드에도 가장 적합한가요?
꼭 그렇지는 않습니다. 먼저 실제 연결 테스트로 사용 가능한 노드를 추린 뒤 그중 일부만 다운로드 속도를 측정하세요. 다운로드 작업에서는 지속 속도와 안정성을, 웹페이지 이용에서는 요청 응답과 실패율을 중점적으로 봅니다. 테스트 대상과 실제 이용 대상이 다를 수 있으므로 마지막에는 실제 사용 환경에서 확인해야 합니다.