TCPing은 서버 포트에 연결할 수 있는지 빠르게 확인하고, 실제 연결 지연은 프록시 경로로 요청을 완료할 수 있는지 검증하며, 다운로드 속도 측정은 지속 전송 성능을 확인합니다. 구독을 가져온 뒤 어떤 항목을 기준으로 정렬해야 할지 모르는 경우에 유용합니다. 이 글의 순서대로 테스트하면 ‘포트 연결 가능’, ‘프록시 사용 가능’, ‘다운로드 속도 충분’을 따로 판단할 수 있어, 지연 시간은 가장 낮지만 정상적으로 사용할 수 없는 노드를 고르는 일을 피할 수 있습니다.
세 가지 노드 속도 측정은 서로 다른 구간을 확인합니다
노드 목록에 표시되는 밀리초 값이 모두 같은 기준으로 측정되는 것은 아닙니다. TCPing은 대개 노드 주소와 포트에 TCP 연결만 설정합니다. 실제 연결 테스트는 프록시 코어를 사용해 지정된 노드로 테스트 주소에 접속합니다. 다운로드 속도 측정은 응답 데이터를 계속 받아 일정 시간 동안의 처리량을 계산합니다. 도달 지점과 요청량, 측정 시간이 서로 다르므로 수치를 직접 비교할 수 없습니다.
이 흐름은 프록시를 통해 대상 서비스에 접속하는 논리적 과정을 나타냅니다. 노드에 별도의 전송 계층이나 중계 서버가 사용되면 진입 지점과 프록시 서비스 사이에 다른 단계가 추가될 수도 있습니다. TCPing은 대체로 흐름의 앞부분만 확인합니다. 실제 연결 및 다운로드 테스트는 이후 경로까지 이어서 점검합니다.
| 측정 방식 | 주요 확인 항목 | 이 결과만으로 확인할 수 없는 항목 |
|---|---|---|
| TCPing | 노드 진입 지점의 TCP 포트에 연결할 수 있는지 | 프록시 인증, 대상 웹사이트 접속, 지속 속도 |
| 실제 연결 지연 | 지정된 프록시 경로로 테스트 요청을 완료할 수 있는지 | 모든 웹사이트 접속 가능 여부, 장시간 다운로드 안정성 |
| 다운로드 속도 측정 | 속도 측정 리소스까지의 실효 전송 속도 | 웹페이지 첫 화면이 빠른지, 다른 시간대에도 같은 속도가 나오는지 |
TCPing 수치는 낮은데 노드는 왜 작동하지 않을까요?
서버 포트 443을 예로 들어 TCPing에 38 ms가 표시된다면, 일반적으로 이 주소의 TCP 수신 포트와 빠르게 연결할 수 있다는 뜻입니다. VMess 또는 VLESS에 필요한 인증 정보를 보내지 않으며 TLS 매개변수나 WebSocket 경로, 노드 출구에서 대상 사이트에 접속할 수 있는지도 확인하지 않습니다.
- 인증 정보가 일치하지 않음: 서버가 TCP 연결은 받아들이더라도 이후 프록시 요청을 거부할 수 있습니다. TCPing을 반복해도 인증 필드 오류를 찾아낼 수는 없습니다.
- 전송 매개변수가 일치하지 않음: 포트에 연결할 수 있어도 TLS 서버 이름이나 전송 경로 등의 매개변수가 잘못되면 애플리케이션 계층 연결은 실패합니다.
- 진입 지점이 최종 서버는 아님: 주소 앞에 중계 서버나 CDN이 있으면 낮은 수치는 진입 지점까지의 거리를 주로 반영할 수 있습니다.
- 모든 프로토콜이 TCP에만 의존하는 것은 아님: TCPing은 실제 UDP 트래픽 테스트를 대신할 수 없습니다. 이 결과만으로 모든 프로토콜을 사용할 수 있다고 판단하지 마세요.
반대로 TCPing 시간 초과도 테스트 구현 방식과 네트워크 환경을 함께 고려해야 합니다. 클라이언트가 현재 노드 주소와 올바른 포트를 측정하는지 먼저 확인한 다음 실제 연결 결과를 살펴보세요. 둘 다 실패한다면 그때 로컬 네트워크, 진입 포트, 노드 상태와 구독 매개변수를 점검하세요. 한 가지 결과만으로 서버가 다운됐다고 단정해서는 안 됩니다.
실제 연결 지연은 사용 가능성을 더 잘 보여주지만, 테스트 대상을 확인해야 합니다
실제 연결 테스트는 보통 코어를 통해 측정 대상 노드로 프록시 경로를 만든 다음 설정된 테스트 URL을 요청합니다. 측정 시간에는 도메인 조회, 프록시 핸드셰이크, 대상 사이트의 TLS 핸드셰이크, 응답 대기가 포함될 수 있습니다. 정확한 시작점과 종료점은 클라이언트 및 코어 구현에 따라 달라집니다. 이를 ‘TCPing에 왕복 횟수를 몇 번 더한 값’으로 고정해 계산할 수는 없습니다.
일부 테스트 주소는 아주 작은 응답을 반환하거나 성공 신호로 204 상태 코드를 사용합니다. 이런 요청은 응답 속도를 확인하는 데 적합하지만 충분한 데이터를 계속 전송하지 않으므로 다운로드 대역폭을 추정할 수는 없습니다. DNS 캐시, 연결 재사용, 테스트 리소스의 위치도 반복 측정 결과에 영향을 줍니다.
실제 연결 테스트 기록
- 대상 주소
- 동일한 HTTPS 테스트 URL 사용
- 테스트 횟수
- 노드당 5회
- 간격
- 매회 최소 3초 간격
- 기록 항목
- 중앙값, 최댓값, 실패 횟수
대상과 측정 방식을 동일하게 유지한 다음 노드끼리 비교하세요.
다운로드 속도 측정 기록
- 다운로드 리소스
- 동일한 속도 측정 파일 사용
- 측정 시간
- 예: 매회 10초
- 동시 작업
- 한 번에 노드 1개만 측정
- 기록 항목
- 평균 속도, 변동 폭, 실제 사용량
지속 속도를 확인할 수 있도록 리소스 크기가 충분해야 합니다.
테스트 대상에 접속할 수 없으면 정상적인 노드 여러 개에서도 동시에 시간 초과가 발생할 수 있습니다. 이때는 기존 설정을 보존하고, 접속 가능 여부가 확인된 작은 HTTPS 테스트 대상으로 바꿔 비교한 뒤 원래 주소로 다시 테스트하세요. 특정 대상에서만 실패한다면 해당 대상의 접근 제한과 노드 출구 경로를 확인하세요. 구독 전체를 바로 삭제할 필요는 없습니다.
다운로드 속도는 처리량을 확인하세요. MB/s와 Mbps를 먼저 구분해야 합니다
다운로드 속도는 로컬 인터넷 회선, 무선 신호, 노드 진입 지점, 서버 출구 대역폭, 대상 리소스의 속도 제한, 테스트 동시 작업 수 등 전체 경로에서 가장 느린 구간에 따라 달라집니다. 노드 진입 지점이 가까우면 일부 왕복 시간이 줄어들 수는 있지만 출구 대역폭까지 충분하다는 뜻은 아닙니다. 지연 시간이 긴 노드도 연결이 설정된 뒤에는 높은 처리량을 유지할 수 있습니다.
단위를 확인하세요. 여기서는 십진 단위로 환산하며 1 MB/s = 8 Mbps입니다. 표시 대역폭이 100 Mbps인 회선은 이론상 약 12.5 MB/s에 해당합니다. 실제 속도는 프로토콜 오버헤드와 공유 네트워크의 영향도 받습니다. 인터페이스에 MiB/s로 표시된다면 이진 바이트 단위로 따로 환산해야 합니다. M이 포함된 수치를 모두 같은 기준으로 정렬하지 마세요.
| 표시 수치 | 십진 단위 환산 | 해석 |
|---|---|---|
| 5 MB/s | 40 Mbps | 초당 약 5 MB 전송 |
| 10 MB/s | 80 Mbps | 10 Mbps에 불과하다고 잘못 해석하지 마세요 |
| 100 Mbps | 12.5 MB/s | 이론상 환산값이며 측정 속도를 보장하지 않습니다 |
v2rayN에서 정해진 순서로 노드 비교하기
아래 설명은 Windows용 v2rayN의 일반적인 데스크톱 인터페이스를 기준으로 합니다. 버전이나 인터페이스에 따라 메뉴 이름이 조금 다를 수 있으므로 “Tcping”, “실제 연결 지연”, “속도”를 기준으로 측정 항목을 찾으세요. 측정 매개변수는 보통 「설정」→「매개변수 설정」의 속도 측정 관련 항목에서 확인할 수 있습니다. 먼저 현재 테스트 URL, 시간 초과 값, 다운로드 시간을 기록한 뒤 비교를 시작하세요.
- 목록 갱신 및 확인: 해당 구독 그룹을 업데이트하고 측정할 노드가 같은 목록에 속하는지 확인합니다. 구독 업데이트 성공은 설정을 가져왔다는 뜻일 뿐, 모든 노드의 연결 테스트가 통과했다는 의미는 아닙니다.
- 로컬 환경 고정: 다른 다운로드와 클라우드 동기화를 일시 중지하고 동일한 네트워크 연결 방식을 유지합니다. 한 노드는 유선 네트워크에서, 다른 노드는 혼잡한 무선 네트워크에서 측정하지 마세요.
- 진입 지점부터 측정: 서버 목록에서 후보 행을 선택하고 마우스 오른쪽 버튼을 눌러 Tcping에 해당하는 측정 항목을 선택합니다. 진입 지점 연결 여부를 판단할 수 있도록 결과를 기록하되, 최저 수치만 보고 최종 노드를 정하지 마세요.
- 다음은 실제 연결 측정: 마우스 오른쪽 버튼을 눌러 실제 연결 지연에 해당하는 측정 항목을 선택합니다. 앞서 설명한 5회 기록 방식을 권장합니다. 현재 버전에서 테스트 동시 실행 수를 설정할 수 있다면 1로 지정해 작업 간 영향을 줄이세요.
- 다운로드 측정은 일부 노드만: 실제 연결이 안정적인 노드 두세 개만 속도 측정을 실행합니다. 평균 속도를 기록하고, 시작 순간의 최고 속도를 지속 대역폭으로 간주하지 마세요.
- 실제 사용 환경에서 검증: 후보 노드를 활성 서버로 설정하고 「시스템 프록시」 메뉴의 현재 상태를 확인한 다음 브라우저가 시스템 프록시를 사용하는지 점검합니다. 실제로 사용할 페이지를 열고 다운로드도 한 번 진행해 보세요.
내장 테스트는 전용으로 생성된 테스트 설정을 사용할 수 있으므로 브라우저의 전체 접속 경로와 같지 않을 수 있습니다. 내장 실제 연결 테스트는 성공하지만 브라우저에서 실패한다면 시스템 프록시, 앱 자체 프록시, 라우팅 규칙, DNS를 추가로 확인하세요. 앱에 127.0.0.1:10808처럼 로컬 프록시를 직접 지정했다면 「설정」→「매개변수 설정」에 표시된 실제 수신 포트와 일치해야 합니다. 이 포트는 예시이며 모든 설치 환경에서 같은 값으로 고정되어 있지 않습니다.
‘지연 시간은 낮은데 다운로드는 느린’ 상황을 예시로 이해하기
아래는 판단 방법을 설명하기 위한 가상 데이터이며, 이 사이트에서 직접 측정한 결과도 특정 서비스의 성능 보장도 아닙니다. 같은 네트워크와 시간대, 테스트 대상을 기준으로 노드 A의 TCPing은 32 ms, 실제 연결 중앙값은 460 ms, 다운로드 평균은 2 MB/s라고 가정해 보겠습니다. 노드 B의 결과는 다음과 같습니다.
A는 진입 지점까지 더 빠르지만 프록시를 통해 테스트 대상에 접속하면 오히려 느립니다. 진입 지점 이후의 경로나 처리 과정을 더 살펴볼 필요가 있다는 뜻입니다. 이 세 가지 수치만으로 서버 CPU 부족이나 회선 혼잡을 단정할 수는 없습니다. 로그와 여러 대상, 다른 시간대의 재측정 결과를 함께 확인하세요. 이 예시에서는 B를 실제 사용 환경에서 검증해 볼 만합니다.
판단 기준: 불안정한 노드를 먼저 제외하고 용도에 따라 정렬
웹 브라우징용 노드는 실제 연결 성공률과 응답 변동 폭을 먼저 비교하고, 대용량 파일 전송에는 지속 다운로드 속도를 비교하세요. 간혹 가장 낮은 지연 시간이 나오더라도 반복 측정에서 자주 실패하는 노드는 안정적인 후보보다 우선하기 어렵습니다.
평균값이 이상치를 가리지 않도록 주의하세요. 180, 190, 185, 900, 시간 초과라는 5회 결과는 매번 220 ms 안팎인 경우와 사용 경험이 다릅니다. 새로 고침 후 마지막으로 남은 숫자만 보는 것보다 시간 초과 횟수와 느린 요청을 기록하는 편이 유용합니다. 저녁 시간대에 다시 측정하면 낮에는 드러나지 않았던 문제를 발견할 수 있습니다.
속도 측정 관련 자주 묻는 질문과 다음 단계
TCPing 수치는 나오는데 실제 연결은 모두 시간 초과입니다. 무엇부터 바꿔야 하나요?
먼저 테스트 URL과 시간 초과 설정을 확인한 다음 코어 실행 로그를 살펴보세요. TLS나 인증 관련 오류가 나타나면 구독을 최신 상태로 업데이트했는지, 시스템 시간이 정확한지, 전송 매개변수를 직접 변경했는지 점검합니다. 포트에 연결할 수 있는 상황에서 로컬 수신 포트를 반복해서 바꾸는 것으로 원격 핸드셰이크 오류를 해결할 수는 없습니다.
실제 연결은 성공하는데 브라우저에서 열리지 않습니다. 노드 문제인가요?
먼저 활성 서버를 확인한 다음 「시스템 프록시」 상태와 브라우저 프록시 설정을 점검하세요. 프록시를 직접 설정한 앱은 로컬 주소와 포트도 확인해야 합니다. 일부 도메인만 실패한다면 라우팅 규칙이 해당 도메인을 직접 연결로 보내는지, DNS가 비정상적인 주소를 반환하는지 확인하세요. 한 대상에서만 실패한다고 노드 전체가 작동하지 않는다고 판단하지 마세요.
다운로드 속도는 잘 나오는데 웹페이지는 왜 오래 걸리나요?
지속 전송 속도가 빠르다고 연결 설정도 빠른 것은 아닙니다. 웹페이지는 여러 도메인에 접속하며 DNS 조회, 핸드셰이크, 응답 대기를 여러 차례 거칩니다. 먼저 실제 연결 지연의 변동을 확인한 뒤 브라우저 네트워크 패널에서 DNS, 연결, TLS, 응답 대기 시간을 구분해 보세요. 필요한 경우 다른 대상을 비교해 웹사이트 자체의 처리 지연인지 확인합니다.
데스크톱과 Android에서 측정 결과가 다릅니다. 어떤 결과가 정확한가요?
먼저 두 기기를 같은 네트워크에 연결하고, 같은 노드와 테스트 대상, 비슷한 시간대를 사용해 측정한 뒤 비교하세요. v2rayN은 데스크톱 클라이언트이고, v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 구체적인 테스트 방식과 설정은 다를 수 있습니다. 각 결과는 우선 측정 당시 해당 기기의 접속 환경을 보여주는 것이므로 기기 간 수치를 바로 순위로 매기지 않는 편이 좋습니다.
테스트 시간, 네트워크 연결 방식, 노드 이름, 실제 연결 성공 횟수, 지연 시간 중앙값, 다운로드 평균만 간단히 기록해 두면 충분합니다. 구독 주소와 인증 정보가 포함된 내용은 공개 스크린샷에 넣지 마세요. 추가로 문제를 확인하려면 문제 진단에서 ‘연결 실패’ 또는 ‘일부 웹사이트에 접속할 수 없음’을 선택해 점검을 이어가세요.