왜 노드만 자동으로 바뀌어서 끊김처럼 느껴질까요?
Clash Verge Rev로 mihomo(구 Clash Meta) 코어 위에 프로필을 올린 뒤 구독을 넣어두었는데, 화면의 ‘자동’·AUTO 같은 그룹이 수시로 갈려 방송 버퍼가 일어나거나 게임에서 짧게 딜레이 스파이크가 난 경험이 있다면 원인 후보 하나는 proxy-groups 안의 url-test(자동 속도 테스트) 타입입니다. 사용자가 버튼을 누르지 않았는데도 코어가 interval 주기와 tolerance 조건으로 “지금 숫자가 제일 빠른 링크”를 다시 고르기 때문입니다.
같은 개념이지만 기기에서 보이는 메뉴 이름은 제공자 패키지마다 다르고, 규칙 전체 깊숙한 설계까지 한 번에 읽기 어렵다는 점 때문에 이 글에서는 url-test 세트의 손맛 노브만 모아 순서대로 적습니다. Windows에서 화면 누르는 흐름과 로그 패턴까지 같이 필요하면 클라이언트 사용 안내 글을 묶어서 보세요.
url-test 그룹이 하는 일 요약
proxy-groups 항목에서 type: URL-TEST(대소문자는 코어 버전별로 허용 범위가 다를 수 있습니다)처럼 선언된 그룹은 proxies: 아래 목록 각각에 주기적으로 지연 테스트를 날립니다. 흔히 설정 파일에는 헬스체크 URL로 https://... 주소 하나를 두거나, 제공자 패키지의 기본 테스트 엔드포인트가 그대로 실려 옵니다. 이 주소까지의 레이턴시 순위가 근처에서 엎치락뒤치락이면 선택된 출구 이름도 따라 흔들립니다.
반면 select 타입 그룹은 사용자가 목록에서 직접 고른 하나를 안정적으로 쓰므로 라이브·경쟁 온라인처럼 한 줄 회선 고정이 중요하면 자동 테스트 그룹을 반드시 써야 할 이유부터 다시 적어 보는 것이 좋습니다. 구독 갱신·룰셋 갱신 흐름은 구독 관리 안내와 세트로 돌려 주기를 헷갈리지 않게 하는 편입니다.
interval: 얼마나 자주 순위표를 새로 받을까
interval은 자동 테스트가 다시 실행되는 간격입니다. 초 단위로 줄이면 새 데이터를 빨리 얻지만, 테스트 요청 트래픽 자체와 짧게 열린 TCP 세션 때문에 측정 분산이 커져 ‘조금이라도 김새 숫자’가 순위 재정렬로 이어질 수 있습니다. 반대로 너무 길게 잡아 두면 순위는 차분하지만 막힌 링크에 오래 매달린 뒤에야 교체되는 비용도 생깁니다.
첫 손에서는 기본값 근처에서 한 단계 크게 또는 작게 두고 옮겨 보는 것보다 먼저 아래쪽 tolerance와 테스트 URL부터 맞추는 순서가 낫습니다. interval만 공격적으로 낮추면 UI에서 깜박임이 줄기보다 불안정 노브가 되는 패턴을 자주 봅니다.
tolerance: ‘조금 이기긴 하는데 안 바뀜’ 허용치
tolerance는 새 후보가 현재 채택 링크보다 ‘의미 있는 만큼’ 더 좋아지지 않는 한 자리를 지키도록 하는 장치입니다. 값이 크면 과거 채택자와 새 측정치 사이에 일정 간격보다 많이 벌어져야만 스위치가 발생하므로, 체감상의 전략 그룹 깜박임 자체가 완만해지는 경우가 많습니다.
과도하게 키우면 레이턴시 순위 차이보다 허용치가 커져 망가진 노드 교체까지 늦어집니다. 그래서 패키지에 이미 깔린 수치 근처를 기준점으로 삼아 조금씩 키우며, 실패·타임아웃 같은 신호와 함께 두 축을 같이 확인하는 편이 안전합니다. 방송에서는 화면 흔들림 최소화가 우선이면 테스트 주기 줄이기와 함께 허용치를 과감히 키웠다가 라이브 끝난 뒤 다시 낮추는 패턴도 씁니다.
lazy: 쓰이지 않는 그룹의 테스트 과도 실행 줄이기
lazy를 쓰게 되면 활성 상태가 아니거나 실제 선택으로 지정되기 전까지는 주기 테스트를 미룰 수 있어, 다수 자동 그룹이 존재하는 프로필에서 백그라운드 소음을 줄입니다. 여러 줄기가 같은 인터페이스로 동시 테스트를 거는 상황이면 순위 교체 패턴 자체가 잡히는 장면을 자주 확인할 수 있습니다. 다만 lazy 옵션의 정확한 기본값·동작 디테일은 코어 버전 문서와 맞춰 보는 편이 안전합니다.
헬스체크·테스트 URL을 바꿔야 하는 경우
UI에서 하는 수동 필터 테스트와 같은 URL을 쓰지 않았다면 헬스체크는 ‘아무 깨끗한 HTTPS’처럼 보이는 다른 서버까지의 지연입니다. 제공자 패키지에 실린 기본 테스트 대상이 ICMP 제한구역이거나 지역 라우팅이 거칠면 순위 신호 자체가 잡음처럼 흔들립니다.
증상이 한국 접속 기준 라이브·게임이라면 테스트 대상까지의 경로가 실제 이용 도메인과 다를 수 있습니다. 간단히 응답하는 공개 엔드포인트부터 출발해 증상별 실제 접속 줄을 연결 패널로 확인한 다음, 테스트 URL 목록을 순차적으로 교체하면서 순위 교체 패턴과 체감이 같이 줄어드는지 비교하면 됩니다. 완전히 다른 체증이 계속된다면 url-test 레이턴시와 체감이 어긋난 상태이므로 같은 그룹을 select로 바꿔 출구 하나를 고정해 보세요. 고정 시 문제가 줄어들면 테스트 모델이 목적 접속 형태와 안 맞다고 정리하면 됩니다.
YAML에서 수정할 때 참고 레이아웃
실제 패키지의 들여쓰기 깊이는 다양합니다만, 개념적으로는 같은 그룹 블록 아래 필요한 줄을 함께 둔다고 이해하면 됩니다.
# Example shape only — match your subscription indent & field names
proxy-groups:
- name: AUTO-HK
type: url-test
proxies:
- NODE-A
- NODE-B
url: https://example.com/generate_204 # probe URL depends on provider / policy
interval: 90
tolerance: 150
lazy: false
위 예시처럼 tolerance 숫자는 코어 버전별로 허용 범위·단위가 다를 수 있으니 패키지에 이미 존재하는 값 근처를 기준점으로 시작하세요.
Clash Verge Rev에서 패치(Override)를 쓸 때 순서 의식하기
원격 프로필이 주기적으로 덮어쓰므로 수정은 보통 패치 기능에 둔다는 가정입니다. 패치 순서 상 뒷단에서 들어오는 줄이 우선이라면 새로 들어온 기본 테스트 값이 패치 결과를 깨먹습니다. 패치 작성 후 활성 결과 YAML을 확인할 수 있는 UI가 제공되면, 최종 문자열 속에 의도한 interval와 tolerance 그대로 남았는지 눈으로 대조하기 바랍니다.
패치만으로 레이블을 바꾸기 어렵다면 별도 프로필로 복사해 테스트하는 편이 안전합니다. 문법 깨짐은 YAML 파싱 오류 정리 글에서 패턴까지 같이 잡습니다.
언제 테스트 대신 수동 select로 두는 게 맞을까?
자동 테스트는 회선 상태가 자주 바뀌지만 실제 업무 패턴에서는 몇 시간 동안 같은 출구를 붙들고 두고 싶을 때 균형 게임이 필요합니다. 경쟁 타이틀에서는 짧게라도 순위 교체 순간 패킷이 튀어도 즉시 체감되므로 select 고정 노드 하나를 메인 채택으로 두고, 테스트 그룹은 백업 풀로만 두는 구성도 흔합니다.
라이브는 CDN 입구별로 패턴이 크게 달라 자동 테스트 URL과 순위 교체 패턴 모두 과대 반응일 수 있습니다. 이때 테스트 파라미터를 조정해 보았는데 교체 줄기만 줄었지 버퍼는 그대로라면 테스트 대상이 해당 스트림 핸들과 완전히 다르거나 DNS· QUIC 경로 차이 같은 다른 병목을 살피세요. QUIC·저수준 패턴까지 넓히고 싶다면 같은 생태 다른 글 모음을 순서대로 읽어 확장하면 됩니다.
실무 자주 받는 추가 질문
interval을 아주 크게 만들면 교체 문제를 끝낼 수 있나요? 순위 교체 속도 자체는 느려지지만, 망가진 줄을 오래 끌어안는 새 비용이 생깁니다. 대신 헬스실패 패턴까지 같이 봐야 합니다.
tolerance 하나만 과장되게 높히면 무슨 증상이 오나요? 테스트 상으로는 새 후보가 조금이라도 우위일 때 교체해야 할 때도 과거 줄에 붙어버립니다.
여러 줄기 테스트가 동시에 돌 때 전체 속도 저하처럼 느껴져요? lazy와 간격 간균형, 불필요한 자동 그룹 존재 자체 줄이기, 그룹 깊은 중복 참조 줄이기를 같이 봐야 해결되기 마련입니다.
UI에서 테스트 버튼은 낮아 보이고 자동 순위 교체만 난항인 이유도 비슷한 계열이라, 테스트 모드 차이부터 비교표로 적어 놓으면 디버깅 말풍선이 줄어듭니다.
정리
Clash류 생태에서 url-test는 간단히 보여도 레이턴시 샘플 주기와 허용치·테스트 목적지 선택이 사용자 체감을 크게 바꿉니다. 패치가 언급 순서 때문에 덮였는지 놓치지 않고 검증해야 하며, 여전히 체증이 테스트 숫자와 어긋나면 해당 그룹을 select로 조정하면 원인 분기가 깔끔해집니다. 라이브·실시간에 민감하면 자동 테스트의 정밀 디테일을 유지하면서 순위 교체 줄이기 위해 tolerance·테스트 목적 재선정이 핵심입니다.
상용 원클릭 클라이언트는 속도 테스트를 한 화면에만 모아 속은 세부 패치가 어렵거나, 테스트와 실제 패킷 형태 차이까지 설명하지 못해 줄기만 줄이도록 보이지만 실패 지점 확인은 결국 제공자 헬프데스크에 맡아야 하는 경우가 많습니다. 반면 클라우드 과금 단일 터널형 SaaS 도구들은 레이턴시 테스트라는 이름 아래 회선 순위 교체 디테일을 숨긴 채 트래픽을 같은 큐 안에 묶어버리기도 해 세밀 규칙을 포기해야 합니다.
오픈소스 Clash·mihomo 줄기는 테스트 주기와 허용치·패치 순서처럼 로컬에서 실제 줄기를 깎아 수정할 수 있습니다. 규칙 전체 교과서까지 한 장에 들고 가고 싶다면 깊숙 항목을 규칙 가이드와 나누어 읽는 편이 흐름이 덜 바뀝니다. Verge Rev로 연결 줄과 로그를 동시에 띄워 두며 파라미터를 조금씩 옮길 때, 자동 테스트는 꼭 ‘필요한 경우에만 과하게 줄이거나 늘리는 레버’처럼 취급하면 일상 업무와 놀이 줄기 속도 교체 줄기가 줄어든다고 느낄 가능성이 큽니다.