1. 이럴 때 이 글을 보면 됩니다
대시보드 지연은 낮은데 웹은 느리다, 혹은 조금만 불안정해도 노드가 바뀌어 로그인이 끊긴다면 url-test의 샘플 측정과 실제 트래픽 경로가 어긋난 전형입니다. 먼저 TLS·SNI로 노드 자체를 분리하고, 그다음 이 글의 interval / tolerance / lazy를 조정하세요.
2. url-test가 고르는 것은 “그 URL까지의 HTTP 지연”이다
proxy-groups에서 type: url-test이면 코어는 주기적으로 각 후보로 url 요청을 보내 RTT를 기록합니다. 장시간 대역폭·UDP 품질·비디오 CDN 경로는 반영하지 않습니다. 규칙이 트래픽을 어디로 보내는지는 규칙·모드 설명과 함께 봐야 하고, 노드 목록이 비정상이면 구독·Provider 글부터 고치는 편이 낫습니다.
같은 이유로, 게임 음성·실시간 화상처럼 UDP가 중요한 트래픽은 url-test 숫자만으로 품질을 대표하기 어렵습니다. 이런 경우에는 자동 그룹보다 select나 fallback으로 출구를 고정하고, 문제가 될 때만 수동으로 바꾸는 운영이 더 솔직한 해답인 경우가 많습니다. 반면 웹 브라우징처럼 TCP 위주로 끊김이 “느린 노드로의 자동 전환”처럼 보일 때는 이 글의 파라미터 조합이 체감에 직접 닿습니다.
3. interval: 측정 주기
interval(초)이 너무 짧으면 순위가 잦아 뒤집히고, 너무 길면 장애 반영이 느립니다. 스트리밍처럼 세션을 유지하고 싶다면 YouTube·Netflix 글에서 말한 것처럼 전용 그룹을 나누고 interval을 길게 잡는 경우가 많습니다. 반대로 API처럼 빠른 전환이 필요하면 짧게—대신 측정 부하가 늘어납니다.
4. tolerance: 히스테리시스(덜 갈아타기 vs 느리게 유지)
tolerance(ms)는 “최저 지연 후보” 대비 현재 선택을 유지할 여유를 줍니다. 키우면 스위칭은 줄지만 느린 출구에 머를 수 있고, 줄이면 민감해져 세션이 끊길 수 있습니다. 아래 표는 직관용입니다.
| 조정 | 기대 | 주의 |
|---|---|---|
| tolerance ↑ | 출구 고정, 전환 감소 | 느린 노드 장기 체류 |
| tolerance ↓ | 최저 지연에 가깝게 이동 | 전환 증가·세션 불안 |
| interval ↑ | 측정 부하·순위 요동 감소 | 장애 반영 지연 |
5. lazy: 선제 측정 줄이기
lazy: true는 그룹이 실제로 쓰이기 전까지 측정을 늦추는 성격에 가깝습니다. “첫 연결만 유난히 느리다”면 lazy와 GUI의 선제 테스트 설정을 함께 보세요. 모바일에서는 Wi-Fi vs LTE 글처럼 회선이 바뀔 때마다 체감이 달라질 수 있습니다.
6. 헬스 URL이 체감을 속일 때
예제로 많이 쓰는 가벼운 generate_204 류는 전 세계 엣지에서 빠르게 응답해 “기본 RTT” 보기엔 좋지만, 사용자가 매일 쓰는 API·동영상 CDN과는 경로가 다를 수 있습니다. TLS 측정만 실패한다면 TLS Handshake Timeout 순서로 노드를 먼저 검증하세요.
# Example url-test (tune for your network)
proxy-groups:
- name: "AUTO"
type: url-test
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 50
lazy: true
proxies:
- "Node-A"
- "Node-B"7. Mihomo·Linux에서 로그와 함께 보기
Mihomo(Clash Meta)를 서버에 올렸다면 Ubuntu·systemd 가이드의 journalctl 흐름으로 측정·전환 로그를 붙잡기 쉽습니다. Windows TUN 이슈는 TUN·방화벽 글과 겹칩니다.
8. DNS·fake-ip과 함께 생각하기
헬스는 통과하는데 특정 사이트만 느리면 url-test 문제가 아니라 DNS·스니핑·fake-ip일 수 있습니다. fake-ip 필터·DNS 글의 순서로 점검한 뒤에도 동일하면 이 글의 파라미터로 돌아오면 됩니다.
9. 로그로 “왜 이 노드인가”
GUI·코어 로그에서 전환 직전의 지연 표와 타임아웃을 함께 봅니다. 안드로이드는 Clash Meta Android 구독 글의 환경에서 로그를 떼기 쉽습니다.
10. 단계별 튜닝 순서
- 규칙이 의도한
proxy-group으로 들어가는지 문서 흐름과 대조 - 헬스 URL만 바꿔 A/B 비교
interval고정 후tolerance만 단계 스윕lazyon/off 비교- 문제 노드를 그룹에서 제외해 측정 편향 제거
스트리밍 전용·업무 전용처럼 그룹을 나누면 Netflix·YouTube 글과 같은 패턴으로 유지보수가 쉬워집니다.
11. 체크리스트
- 느린데 안 바뀜 →
tolerance과대·interval과대·헬스 URL 부적합 - 자꾸 바뀜 →
interval과소·tolerance과소·간헐 타임아웃 - 첫 접속만 느림 →
lazy·선제 테스트 - 측정만 빠름 → DNS·규칙·TLS
12. 요약
url-test는 지정 URL에 대한 HTTP 지연으로 출구를 고릅니다. interval·tolerance·lazy는 측정 빈도·전환 민감도·선제 테스트를 조절합니다. 한 번에 모두 바꾸지 말고, 위 관련 문서 링크와 로그를 번갈아 대조하면 같은 구독이라도 체감이 달라집니다.