Clash 지연 테스트 원리

지연 시간은 한 번의 요청에 걸리는 시간입니다

Clash 클라이언트에서 흔히 볼 수 있는 ‘속도 테스트’ 버튼은 보통 프록시를 통해 지정된 URL에 접속하는 데 걸리는 시간을 측정합니다. 큰 파일을 내려받아 대역폭을 계산하는 기능은 아닙니다. 화면에 표시되는 80ms, 160ms는 해당 테스트 경로의 응답 시간입니다. 이를 초당 다운로드 가능한 MB로 환산할 수 없으며, 모든 웹사이트의 응답 시간을 나타내지도 않습니다.

클라이언트에 따라 TCP 연결 테스트, HTTP 지연 테스트, 별도의 다운로드 속도 측정 기능을 제공할 수 있습니다. 이 글에서는 설정의 url-test와 HTTP 요청 기반 노드 지연 테스트를 다룹니다. 클라이언트와 코어 버전에 따라 측정 구간과 연결 재사용 방식이 다를 수 있으므로, 비교하기 전에 같은 유형의 테스트인지 확인하세요.

url-test 요청은 어떤 과정을 거칠까요?

흔히 쓰이는 HTTPS 테스트 URL인 https://www.gstatic.com/generate_204를 예로 들면, 코어는 테스트 대상 프록시를 통해 HTTP 요청을 보냅니다. 이 주소는 보통 본문을 내려받지 않는 HTTP 204 응답을 반환하므로, 가벼운 연결 확인과 응답 시간 측정에 적합합니다. 대역폭 측정용 파일은 아니며, 모든 네트워크 환경에서 접속이 보장되는 것도 아닙니다.

1. 연결 대상 확인. 클라이언트는 프록시 서버 주소를 알아야 합니다. 서버 주소가 도메인이라면 연결 전에 DNS 조회가 필요할 수 있습니다. 테스트 대상 도메인을 로컬에서 조회할지 원격에서 조회할지는 프록시 프로토콜과 코어의 DNS 설정에 따라 달라집니다.
2. 프록시 서버에 연결. 로컬 네트워크와 프록시 서버 사이에 전송 연결을 설정해야 합니다. TCP 기반 프로토콜은 TCP 핸드셰이크를 거칠 수 있고, 일부 프로토콜은 TLS 핸드셰이크나 인증도 필요합니다. 다른 전송 방식을 사용하는 프로토콜은 같은 절차로 단순하게 계산할 수 없습니다.
3. 대상 서버로 연결 경로 설정. 프록시 출구 서버가 테스트 사이트에 연결합니다. 입구 서버가 가까워도 출구 서버와 대상 사이트 사이의 거리가 가깝다는 뜻은 아닙니다. 다른 지역을 거쳐 가거나 출구 서버가 혼잡하면 대기 시간이 늘어날 수 있습니다.
4. 요청을 보내고 응답 대기. 코어에서 정한 측정 구간이 끝나면 소요 시간이 클라이언트에 표시됩니다. 인증서 검증 실패, 연결 재설정, 시간 초과는 유효한 밀리초 값이 아니라 테스트 실패로 나타날 수 있습니다.

따라서 HTTP 지연 시간은 단순히 ‘내 컴퓨터에서 서버까지의 ping’을 뜻하지 않으며, 모든 핸드셰이크 시간을 더한 값으로 해석해서도 안 됩니다. DNS 캐시, TLS 세션 재개, 하위 연결 재사용, 코어 구현 방식이 모두 결과에 영향을 줍니다. 첫 측정에서 230ms가 나왔다가 다음에 120ms로 줄었다고 해서 회선 대역폭이 갑자기 늘었다고 볼 수는 없습니다.

ping 수치가 더 낮게 나오는 이유

명령줄의 ping은 보통 ICMP 에코 요청을 보내 지정한 호스트까지의 왕복 시간을 측정합니다. 위에서 설명한 HTTP 요청을 수행하지 않으며, 일반적으로 시스템 HTTP 프록시를 거치지도 않습니다. 서버가 ICMP 요청은 제한하면서 프록시 서비스는 정상적으로 허용할 수도 있습니다. 따라서 ping에 실패했다고 노드를 사용할 수 없는 것은 아니며, ping 수치가 낮다고 HTTPS 페이지가 빠르게 열린다는 보장도 없습니다.

테스트 URL에 따라 비교 대상이 달라집니다

노드 테스트는 테스트 URL에 접속하지만, 브라우저에서는 동영상 사이트, 코드 저장소, 화상 회의 서버 등에 접속할 수 있습니다. 각 서비스의 CDN 분포, 원본 서버 위치, 통신사 간 연결 상태가 다릅니다. 한 회선은 테스트 사이트까지 60ms면 도달하지만 업무에 필요한 사이트까지 우회할 수 있고, 다른 회선은 테스트 결과가 110ms여도 실제 서비스에 더 적합한 경로를 제공할 수 있습니다.

• 노드 간 비교에는 같은 URL을 사용하세요. 노드 A는 한 사이트를, 노드 B는 다른 사이트를 테스트하면 결과를 공정하게 비교할 수 없습니다.
• 테스트 URL 문제는 따로 확인하세요. 테스트 도메인의 DNS 조회 실패, 인증서 날짜 검증 실패, 서버의 요청 제한 때문에 여러 노드가 동시에 시간 초과될 수 있습니다. 이때는 응답이 작고 안정적인 다른 HTTPS URL로 다시 테스트하세요.
• 상태 코드는 설정과 함께 확인하세요. 일부 코어나 클라이언트에서는 기대하는 응답 상태를 설정할 수 있습니다. 리디렉션, 인증 페이지, 예상하지 못한 상태 코드가 반환되면 응답을 받았더라도 테스트는 실패로 처리될 수 있습니다.
• 실제 서비스 확인도 필요합니다. 후보 노드를 고른 뒤에는 클라이언트 목록만 확인하지 말고 실제로 사용할 사이트를 열어 로그인, 이미지, 동영상 재생, 장시간 연결이 잘 되는지 살펴보세요.

지연 시간은 낮은데 다운로드가 느린 이유

가벼운 요청은 연결 설정과 응답 대기 비용을 주로 보여 주지만, 지속 다운로드 속도는 사용 가능한 대역폭, 혼잡 제어, 회선의 패킷 손실, 서버의 전송 능력에 더 큰 영향을 받습니다. 작은 응답은 빠르게 도착해도 같은 회선으로 500MB를 연속 전송하면 출구 서버의 속도 제한에 금방 걸릴 수 있습니다.

예시로 지연 시간과 처리량 비교하기

노드 A의 HTTP 지연 시간은 65ms, 지속 다운로드 속도는 2MB/s이고, 노드 B는 HTTP 지연 시간 140ms, 지속 다운로드 속도 15MB/s라고 가정해 보겠습니다. 지표 차이를 설명하기 위한 예시이며 실제 회선 측정 순위는 아닙니다. 짧은 웹 요청에서는 A가 더 빨리 응답을 시작할 수 있지만, 대용량 파일이나 고화질 동영상에는 B의 처리량이 더 충분할 수 있습니다. 사이트에서 속도 제한을 걸고 있다면 두 노드 모두 원본 서버의 제한을 받을 수 있습니다.

‘지연이 낮으니 무조건 빠르다’는 전송량을 고려하지 않은 판단입니다. ‘다운로드가 빠르니 화상 회의에도 적합하다’는 안정성, 업로드 성능, 실시간 서비스 경로를 간과한 판단입니다. 모든 성능을 하나의 순위로 합치기보다 용도를 먼저 정하고 필요한 지표를 확인하세요.

지터와 패킷 손실이 사용 경험에 미치는 영향

최저 지연 시간 하나만 보면 변동이 가려질 수 있습니다. 예를 들어 연속 측정값이 78, 82, 80, 460, 85ms라면 중간의 460ms를 눈여겨봐야 합니다. 무선 네트워크 경쟁, 대기열, 재전송, 테스트 사이트의 일시적인 지연이 원인일 수 있습니다. HTTP 요청 다섯 번의 결과만으로 하위 네트워크의 패킷 손실률을 단정할 수는 없습니다.

안정적인 전송이 필요한 연결에서는 데이터 손실로 재전송이 발생하고 혼잡 윈도우에 영향을 주어 장시간 다운로드 속도가 크게 느려질 수 있습니다. 실시간 음성·영상에서는 소리가 끊기거나 화면이 멈추고 버퍼링이 늘어날 수 있습니다. 앱마다 복구와 버퍼링 방식이 다르므로 같은 노드가 버퍼링이 있는 동영상 시청에는 적합해도 실시간 회의에는 맞지 않을 수 있습니다.

• 연속으로 5~10회 테스트해 중앙값, 최댓값, 실패 횟수를 확인하고 최저값만 기억하지 마세요.
• HTTP 테스트 10회 중 2회가 실패했다면 ‘이번 테스트에서 요청 2/10회 실패’라고 기록하세요. ‘회선 패킷 손실률 20%’라고 쓰면 안 됩니다.
• 네트워크가 한가한 시간대와 주로 사용하는 저녁 시간대에 각각 테스트하세요. 저녁에만 느려진다면 로컬 인터넷 회선과 프록시 출구 서버의 부하를 따로 비교해 보세요.
• 테스트 중에는 클라우드 드라이브 동기화, 대용량 다운로드, 다른 속도 테스트를 일시 중지해 자체 트래픽으로 대기열이 생기지 않도록 하세요.

url-test 자동 선택은 대역폭 우선 선택이 아닙니다

Clash 및 Clash Meta(현재는 주로 mihomo라고 부름) 설정에서 url-test 프록시 그룹은 지정된 URL의 지연 테스트 결과를 바탕으로 구성원을 선택합니다. 이름에 ‘속도 테스트’가 들어 있다고 해서 대용량 파일을 자동으로 내려받아 대역폭을 비교하지는 않습니다. 특정 회선을 직접 고정하려면 수동 선택 그룹을 사용하세요. 자동 테스트 그룹은 주로 지연 시간을 기준으로 선택한다는 점을 고려해야 합니다.

아래는 프록시 그룹 설정 예시입니다. 현재 설정에 ‘홍콩 A’와 ‘일본 B’라는 이름의 프록시가 이미 있다고 가정합니다. 실제로 사용할 때는 구성원 이름을 기존 설정에 있는 정확한 이름으로 바꾸고, 기존 proxy-groups 목록에 합쳐야 합니다. 설정 파일 전체를 이 내용으로 바꾸면 안 됩니다.

proxy-groups:
  - name: 지연 시간 우선
    type: url-test
    proxies:
      - 홍콩 A
      - 일본 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• interval: 300은 테스트 간격을 300초로 설정한다는 뜻입니다. 실제 실행 시점은 코어의 지연 테스트 실행 방식 등에도 영향을 받을 수 있으므로 언제나 정확히 이 간격으로 실행되는 타이머라고 보면 안 됩니다.
• tolerance: 50은 밀리초 단위로 자동 선택의 전환 허용 범위를 설정해, 몇 밀리초 차이만으로 자주 전환되는 일을 줄입니다. 구체적인 동작은 사용하는 코어 버전에 따라 달라집니다.
• 그룹을 설정하는 것만으로는 충분하지 않습니다. 실제 연결에 선택 결과를 적용하려면 트래픽 규칙에서 해당 그룹을 참조하거나 상위 수동 선택 그룹에서 해당 그룹을 선택해야 합니다.

자동 그룹이 구성원을 다시 선택해도 이미 설정된 모든 연결이 즉시 옮겨가는 것은 아닙니다. 기존 연결은 이전 출구를 계속 사용할 수 있고, 새 연결부터 변경된 선택을 따를 수 있습니다. 문제를 확인할 때는 현재 노드 이름만 보지 말고 클라이언트의 ‘연결’ 화면에서 대상 도메인, 적용된 규칙, 프록시 체인을 확인하세요.

같은 조건에서 실제 속도 확인하기

대부분의 클라이언트에서는 ‘프록시’ 화면에서 노드를 선택해 지연 테스트를 실행한 다음, ‘연결’ 또는 ‘로그’ 화면에서 요청 경로를 확인할 수 있습니다. 이는 흔히 쓰이는 메뉴 이름이며 모든 클라이언트에 똑같이 적용되지는 않습니다. 시스템 프록시 모드와 TUN 모드는 트래픽을 처리하는 범위가 다르므로 테스트할 때 모드를 동일하게 유지하세요.

1. 네트워크 환경부터 고정하세요. 같은 기기, 같은 인터넷 회선, 같은 Wi-Fi 주파수 대역을 사용하세요. 가능하면 유선 연결로도 다시 테스트하세요. 휴대전화 셀룰러 네트워크 결과와 컴퓨터 Wi-Fi 결과를 바로 비교하지 마세요.
2. 실제 트래픽이 프록시를 통하는지 확인하세요. ‘연결’ 화면에서 테스트 사이트를 찾아 출구가 DIRECT가 아닌지, 올바른 노드를 사용하는지 확인하세요. 코어에서 실행하는 지연 테스트는 테스트 대상 프록시를 지정하는 경우가 많으므로, 테스트 성공만으로 브라우저 트래픽도 제대로 프록시를 통한다고 볼 수는 없습니다.
3. 가벼운 요청부터 기록하세요. 같은 URL로 5~10회 연속 테스트해 일반적인 응답 시간, 큰 지연 값, 실패 횟수를 기록하세요. 여러 노드를 한꺼번에 짧은 간격으로 테스트하지 마세요.
4. 그다음 지속 처리량을 측정하세요. 충분한 대역폭을 제공하는 고정된 서버에서 약 30초 동안 파일 하나를 다운로드하고 속도가 안정된 구간을 확인하세요. 비교할 때는 파일, 서버, 동시 연결 수를 같게 유지하고 요금제의 데이터 사용량도 확인하세요.
5. 마지막으로 실제 작업을 테스트하세요. 동영상은 버퍼링과 재생 안정성을, 화상 회의는 업로드와 음성 끊김 여부를, 코드 저장소는 페이지 로딩과 파일 다운로드를 각각 확인하세요. 한 번에 하나의 조건만 바꾸세요.

노드를 고를 때는 먼저 지연 테스트로 현재 접속할 수 없거나 이상이 뚜렷한 후보를 제외하고, 지연 변동, 지속 처리량, 실제 앱에서의 성능을 확인하세요. 웹 브라우징에는 응답 시간이 중요하고, 대용량 파일에는 대역폭이 더 중요하며, 실시간 통신에는 안정성과 업로드 성능도 중요합니다. 지표를 나눠 기록해야 클라이언트의 수치는 좋아 보이는데 실제 체감은 나아지지 않는 이유를 파악할 수 있습니다.