노드 지연 시간 측정 원리: URL 테스트와 실제 속도 차이

1. 패널의 밀리초 수치는 다운로드 속도가 아닙니다

Clash 클라이언트의 프록시 화면에 표시되는 120 ms는 보통 코어가 지정된 노드를 통해 URL 탐색 요청을 보낸 결과입니다. 이 값은 “이 프록시 경로로 작은 요청을 완료하는 데 걸리는 시간”을 나타낼 뿐, “초당 데이터를 얼마나 다운로드할 수 있는지”를 뜻하지 않습니다. 수동 속도 테스트, 구독 노드 상태 확인, url-test 자동 선택은 서로 다른 URL과 시간 제한을 사용할 수 있으므로, 결과를 비교하기 전에 측정 방식을 확인해야 합니다.

지연 시간은 밀리초(ms), 처리량은 보통 Mbps 또는 MB/s로 표시합니다. 노드 A의 측정 결과가 80 ms와 다운로드 속도 2 MB/s이고, 노드 B가 160 ms와 15 MB/s라고 가정해 보겠습니다. A는 작은 요청이 잦은 작업에, B는 대용량 파일 다운로드에 더 적합할 수 있습니다. 수치는 지표의 차이를 설명하기 위한 예시일 뿐, 실제 회선 측정 결과나 성능 보장이 아닙니다.

2. url-test 요청은 어떤 단계를 거칠까

프록시를 통해 https://www.gstatic.com/generate_204에 접속한다고 가정하면, 요청 경로는 클라이언트 코어 → 프록시 서버 또는 프록시 체인 → 측정 사이트 → 응답 반환 순서입니다. 이 URL은 보통 HTTP 204를 반환하며, 지속적인 처리량을 측정할 만한 큰 응답 본문은 없습니다. 따라서 가벼운 연결 확인에 적합합니다.

1. 측정 대상과 연결 정보를 준비합니다. 프록시 서버 주소를 확인하고 측정 대상의 도메인이나 주소를 준비합니다. DNS 조회가 로컬에서 이뤄지는지 원격에서 이뤄지는지는 프로토콜, DNS 설정, 연결 경로에 따라 달라집니다.
2. 프록시에 연결합니다. 노드 프로토콜에 따라 TCP 연결, TLS, WebSocket 또는 UDP 기반 전송 핸드셰이크가 필요할 수 있습니다. 프로토콜마다 연결에 드는 비용은 다릅니다.
3. 측정 대상까지의 경로를 만듭니다. 프록시 출구에서 측정 사이트에 연결합니다. HTTPS 대상이라면 대상 사이트와 TLS 핸드셰이크도 진행됩니다. 이는 프록시 프로토콜 자체에서 사용하는 TLS와는 별개의 계층입니다.
4. 요청을 보내고 응답을 기다립니다. 대상 사이트가 요청을 처리하고 응답을 프록시 경로로 반환하면, 코어가 해당 탐색 결과를 기록합니다.

이 네 단계를 모든 버전에서 똑같이 적용되는 고정 측정 공식으로 보면 안 됩니다. 오리지널 Clash, Clash Meta(현재 mihomo)와 버전에 따라 요청 방식, 연결 재사용, 반복 측정, 지연 시간 기록 방식이 다를 수 있습니다. DNS 캐시도 실제 소요 시간에 영향을 줍니다. 특정 수치를 정확히 해석해야 한다면 클라이언트와 코어 버전을 기록한 뒤 해당 구현을 확인하세요.

첫 측정과 재측정 결과가 다른 이유

첫 접속에서는 DNS 조회나 새 연결 설정이 발생할 수 있습니다. 이후 측정에는 캐시, 세션 재개, 서버 부하 변화가 영향을 줄 수 있습니다. 매번 새 연결을 만들더라도 모든 상태가 초기화되는 것은 아닙니다. 첫 결과가 240 ms이고 다음 결과가 130 ms라고 해서 노드가 갑자기 빨라졌다고 단정할 수는 없습니다.

3. 측정 URL에 따라 노드 순위가 달라집니다

URL 테스트는 “노드에서 특정 측정 대상까지”의 경로를 측정합니다. 측정 사이트의 CDN, 지역별 라우팅, 통신사 간 연결은 실제 이용하려는 사이트와 다를 수 있습니다. 특정 노드가 측정 URL에는 빠르게 연결되지만 코드 저장소, 동영상 CDN, 업무 서비스까지는 우회할 수 있습니다. 이 경우 패널에는 지연 시간이 낮게 표시되는데 웹페이지는 느린 상황이 동시에 생길 수 있습니다.

측정 URL을 바꿀 때는 응답 상태와 현재 코어의 상태 확인 조건을 살펴보세요. 로그인이 필요하거나 계속 리디렉션되는 페이지, 접속 확인 절차가 있는 페이지는 안정적인 탐침으로 적합하지 않습니다. expected-status를 설정한 경우 예상 상태 코드와 다르면 실패로 판정될 수 있으므로, 모든 실패를 회선 단절로 단정하면 안 됩니다.

4. 동시 요청·혼잡·패킷 손실이 차이를 키우는 이유

작은 요청으로는 지속 대역폭을 측정할 수 없습니다

응답 본문이 거의 없는 요청은 금세 끝납니다. 따라서 장시간 다운로드 중의 혼잡 윈도우 증가, 대역폭 제한, 지속적인 패킷 손실, 공유 출구 부하를 확인하기 어렵습니다. 저녁 시간대에도 회선이 약 100 ms 만에 작은 요청을 처리할 수는 있지만, 고화질 동영상을 안정적으로 전송하지 못할 수도 있습니다.

모든 노드를 한꺼번에 테스트하면 서로 영향을 줍니다

일괄 테스트는 짧은 시간에 여러 연결을 만듭니다. 노드들이 같은 진입점이나 중계 회선을 공유하거나, 심지어 같은 출구를 사용할 수도 있습니다. 이때 로컬 Wi-Fi, 라우터의 연결 처리 능력, 통신사 업로드 회선도 측정에 영향을 줄 수 있습니다. 백그라운드에서 대용량 파일을 업로드하고 있다면 대기열 때문에 지연 시간이 크게 늘어날 수도 있습니다.

• 대용량 파일 업로드, 클라우드 동기화, 다른 속도 테스트를 먼저 중지합니다.
• 일괄 측정 결과에서 후보 노드 2~3개를 고른 뒤 하나씩 다시 테스트합니다.
• 후보 노드마다 최소 5회 측정하고 중앙값, 최고값, 실패 횟수를 기록합니다.
• 주로 사용하는 시간대에 다시 측정합니다. 낮에 나온 결과가 저녁의 높은 부하 상황을 대신할 수는 없습니다.

예를 들어 측정값이 90, 92, 95, 98, 800 ms라면 중앙값은 95 ms이지만, 한 번 발생한 큰 지연도 주의해서 살펴봐야 합니다. 다섯 번 중 두 번 실패했다면 나머지 세 번 중 가장 낮은 값만으로 비교해서는 안 됩니다. 웹페이지 상호작용과 실시간 통신은 평균 지연 시간보다 지터와 패킷 손실에 더 민감한 경우가 많습니다.

5. url-test 자동 선택은 다운로드가 가장 빠른 노드를 고르는 기능이 아닙니다

url-test는 탐색 결과를 기준으로 출구를 자동 선택하는 프록시 그룹 유형입니다. 대용량 파일을 내려받아 대역폭을 비교하지 않으며, 현재 작업이 동영상 시청인지 회의인지 소프트웨어 업데이트인지도 판단하지 않습니다. select는 수동 선택에, fallback은 순서대로 사용 가능한 출구를 찾는 데 중점을 둡니다. 이러한 전략 그룹을 모두 “속도 최적화” 기능으로 여겨서는 안 됩니다.

기존 url-test 그룹을 확인할 때는 아래 필드부터 살펴보세요. 예시는 각 필드의 의미만 보여 주며 완전한 구독 설정이 아니므로 설정 파일 전체를 대체하는 데 사용할 수 없습니다. 사용 가능한 필드는 실제 코어 버전에 따라 달라집니다.

type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: true

• interval: 300: 300초마다 정기적으로 확인한다는 뜻입니다. 모든 페이지 요청 때마다 다시 측정한다는 뜻은 아닙니다.
• tolerance: 50: 전환 허용 범위를 밀리초 단위로 설정해 작은 차이로 반복 전환되는 일을 줄입니다. 시간 초과 한도가 아니며 대역폭을 높여 주지도 않습니다.
• lazy: true: 그룹을 사용하지 않을 때 정기 확인을 건너뛸 수 있습니다. 그룹의 활성 상태를 판단하는 기준은 현재 코어 구현에 따라 다릅니다. 따라서 패널에 표시된 결과가 방금 측정한 값이 아닐 수도 있습니다.

구독의 proxy-providers에는 자체 health-check가 설정되어 있을 수도 있습니다. 프록시 목록 상태 확인과 프록시 그룹 테스트는 일대일로 대응하지 않으며, 클라이언트에서 수동으로 측정할 때는 또 다른 설정을 사용할 수 있습니다. 문제를 확인할 때는 탐색 URL, 결과 시간, 설정 출처를 함께 살펴 오래된 결과를 현재 상태로 오해하지 않도록 하세요. 구독을 업데이트하면 로컬 수정 사항이 덮어써질 수 있으므로, 계속 적용할 변경은 클라이언트에서 지원하는 오버라이드 기능을 사용하세요.

6. 패널만 보지 말고 실제 요청으로 노드를 확인하세요

먼저 출구 모드를 규칙 모드로 설정하고, 프록시 화면에서 후보 노드를 고정합니다. 그런 다음 연결 기록을 확인해 대상 요청이 어떤 규칙과 프록시 그룹에 매칭됐고 최종적으로 어떤 출구를 사용했는지 살펴봅니다. 시스템 프록시는 이를 따르는 앱에만 영향을 주며, 터미널 도구는 시스템 프록시 설정을 읽지 않을 수 있습니다. TUN 모드는 가로채는 트래픽 범위를 넓히지만 회선 대역폭을 자동으로 높여 주지는 않습니다.

혼합 포트로 재현 가능한 테스트하기

아래 명령은 macOS 터미널용이며, 클라이언트의 실제 혼합 포트가 7890이라고 가정합니다. 먼저 클라이언트 설정에서 포트를 확인하세요. 다른 포트를 사용한다면 실제 값으로 바꿔야 합니다. -x는 로컬 HTTP 프록시를 명시하므로 터미널이 시스템 프록시 설정을 따르는지에 의존하지 않습니다. --noproxy ""는 기존 프록시 우회 목록 때문에 대상에 직접 연결되는 상황을 방지합니다.

curl --noproxy "" -x http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -sS -o /dev/null \
  -w 'status=%{http_code}\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

여기서 time_connect는 주로 로컬 프록시까지 TCP 연결을 맺는 시간을 나타냅니다. time_appconnect는 관련 보안 핸드셰이크를 마칠 때까지의 누적 시간이고, time_starttransfer는 첫 바이트를 받을 때까지의 누적 시간입니다. 각 값은 서로 겹치지 않는 별도 구간이 아니며 패널의 코어 탐색 결과와 직접 대응하지도 않습니다. 이 테스트는 조건을 고정해 요청을 다시 확인하기 위한 것으로, 두 구현에서 같은 수치가 표시되어야 한다는 증거가 아닙니다.

실제 서비스와 지속 처리량을 다시 측정하기

1. 실제로 사용하는 사이트를 열고 여러 페이지에 연속으로 접속해 첫 화면, 로그인, 리소스 로딩이 정상인지 확인합니다.
2. 접근 권한이 있고 테스트가 허용된 동일한 출처에서 같은 파일을 다운로드합니다. 동시 연결 수를 동일하게 유지하고 30~60초 동안 안정적인 속도를 확인합니다.
3. 측정 시간, 네트워크 환경, 노드, 실패 횟수, 안정적인 전송 속도를 기록합니다. 노드를 바꿔 반복 측정하되 여러 다운로드 테스트를 동시에 실행하지 않습니다.

단위 환산에 유의하세요. 8 Mbps는 약 1 MB/s이며, 실제 애플리케이션 처리량은 프로토콜 오버헤드의 영향도 받습니다. 속도 측정 사이트의 Mbps와 브라우저 다운로드 창의 MB/s는 숫자의 크기만으로 직접 비교할 수 없습니다.

7. 지연 시간은 낮은데 사이트가 열리지 않을 때 확인할 순서

1. 측정 결과가 최신인지 확인합니다. 노드 하나를 수동으로 다시 측정하고 URL과 시간을 기록하세요. 캐시된 결과이거나 정기 확인이 실행되지 않은 것은 아닌지 먼저 살펴봅니다.
2. 요청이 해당 노드를 통과하는지 확인합니다. 연결 화면에서 매칭된 규칙과 최종 출구를 확인하세요. 일부 도메인은 DIRECT에 매칭되거나 다른 프록시 그룹을 사용할 수 있습니다.
3. 트래픽 진입 경로를 확인합니다. 시스템 프록시가 켜져 있는지, 앱이 별도의 프록시를 사용하는지 확인하세요. TUN 모드라면 권한, 라우팅, 다른 VPN의 영향도 살펴봅니다.
4. 대상과 DNS를 확인합니다. 탐침에 연결할 수 있다고 해서 서비스 도메인에도 접속할 수 있는 것은 아닙니다. 로그에서 DNS 조회 실패, 연결 시간 초과, TLS 오류를 확인하고, 문제가 생겼다고 DNS 설정을 한꺼번에 바꾸지는 마세요.
5. TCP와 UDP를 구분합니다. HTTPS 요청이 성공해도 UDP 전달이 가능하다는 뜻은 아닙니다. 게임, 음성 통화, QUIC은 프로토콜 지원 여부와 실제 경로를 별도로 확인해야 합니다.