왜 지금 폴백(fallback) 전략 그룹만 따로 조정해야 할까요?
Clash Verge Rev는 mihomo(Clash Meta 계열) 코어 위에서 프로필·구독·패치(Override)를 한 화면에 모읍니다. 구독이 풀리면 여러 줄기 노드 이름 아래로 proxy-groups 안에 자동 기능이 한꺼번에 들어오는데, 그중에서도 fallback 타입은 헬스체크가 “이 줄이 죽었는지 살았는지”를 판정해 순위대로 넘어가는 축이라서 테스트 URL 하나와 재검사 간격만 어긋나도 사용자 화면에는 이상하게 자주 출구만 바뀌는 것처럼 보입니다. 규칙 모드 설계까지 한 번에 읽기 어렵다는 점은 규칙 심화 가이드에서 다룬 개념을 전제로 하고, 이 글은 폴백 블록에 붙어 있는 헬스·간격 노브만 순서대로 정리했습니다.
비슷한 화면의 “자동” 그룹이라도 속이 url-test인 경우에는 지연을 재측정해 빠른 노드를 계속 재선택하기 때문에 줄기가 흔들리는 패턴이 다릅니다. 순위 게임 줄이기·interval·tolerance·lazy는 동일 제품 줄기의 url-test 안내 글에서 다룹니다. 지연 순위보다 줄기 다운·차단 회피 순서 유지가 목표면 이 글의 fallback 초점만 따로 따라가면 됩니다. Windows에서 메뉴와 로그 흐름을 같이 잡아야 한다면 Verge Rev Windows 사용법을 세트로 두세요.
fallback 전략 그룹이 하는 일
YAML에서 type: fallback(대소문자 규칙은 코어·프리셋에 따릅니다)으로 선언된 그룹은 proxies: 목록의 위에서 아래 순서를 후보 큐로 봅니다. 코어는 보통 첫 줄에 대해 지정한 헬스 URL로 짧은 검사를 보내 살아 있다고 판단되면 그 노드를 출구로 씁니다. 검사가 실패하거나 응답이 없어 “죽음”으로 보이면 다음 후보로 넘어가 같은 방식을 반복합니다. 사용자가 UI에서 버튼을 누르지 않아도 실패 패턴에 반응한 전환이 일어나므로 라이브·결제처럼 세션 고정이 중요한 트래픽에서는 이 자동 줄기가 오히려 방해가 될 수 있습니다.
반면 업무 회선처럼 “막히면 바로 두 번째·세 번째 백업으로만 넘어가면 된다”는 요구에는 fallback이 더 직관적입니다. 제공자 패키지는 동일 이름으로 url-test 줄기와 fallback 줄기를 섞어 놓기도 하므로, 수정 전에 활성 결과 YAML에서 블록 이름과 type 줄을 꼭 대조해야 합니다. 구독이 덮어쓰는 시점과 혼동되지 않게 갱신 정책은 구독 관리 안내와 시간축을 맞추어 두면 좋습니다.
헬스 URL: 살아 있음을 어떻게 판정할까
폴백의 전환은 실제 웹사이트 지연이 아니라 헬스 대상까지의 짧은 요청이 성공했는지에 크게 의존합니다. 구독 기본값이 특정 글로벌 사이트를 가리키면, 그 사이트만 지역·ISP 경로가 거칠 때 살아 있는 노드도 연속으로 실패한 것처럼 보일 수 있습니다. 반대로 너무 가벼운 엔드포인트는 통과하지만 실제 목적 호스트는 막혀 있어 착시가 남을 수 있으므로, 증상을 재현하는 앱의 호스트와 완전히 무관한 URL만 쓰고 있다면 한 단계씩 바꿔 비교하는 것이 좋습니다.
운영망에서는 방화벽이 특정 테스트 대역만 차단하는 경우도 흔합니다. 그러면 모든 후보가 동일하게 헬스에만 실패해 두 번째 후보로 점프하거나 교체가 이상하게 보일 수 있습니다. 사내 정책을 벗어난 임의 URL을 많이 두기보다, 허용된 범위 안에서 빠르게 응답하는 안정적인 HTTPS 한두 곳으로 좁히고 패치 하나에 모아두는 편이 유지보수에 유리합니다.
interval: 재검사 주기와 체감 타임아웃
interval은 헬스 프로브를 반복하는 대략적인 간격입니다. 값이 극단적으로 짧으면 테스트 요청이 겹치고 네트워크 순간 상태만으로 연속 실패가 기록되어 불필요한 순위 이동이 잦아질 수 있습니다. 반대로 너무 길면 첫 줄이 실제로는 망가졌는데도 헬스가 늦게 반영되어 사용자가 “한동안 안 붙는다”처럼 느낍니다.
코어 버전별로 허용되는 최소·최대와 기본 동작 차이가 있으니 패키지에 이미 박혀 있는 숫자를 기준점으로 삼습니다. 헬스 URL을 먼저 바꿨는데도 짧은 주기 때문에만 출구 깜박임이 보이면 interval을 소폭 늘리는 실험이 의미 있습니다. 사용자 인터페이스의 수동 테스트 버튼과 자동 헬스는 타이밍이 다르다는 전제도 잊지 마세요.
timeout에 가까운 증상: 무엇이 느리게 보이게 하나
설정 파일 어딘가에 “테스트 초를 직접 입력하는 한 줄 timeout”이 항상 보이는 형태는 아닙니다. 실무에서는 헬스 요청이 코어 안에서 허용한 시간 안에 완결되지 못했을 때 타임아웃으로 패배 처리된다고 이해하는 편이 맞습니다. 그래서 느린 헬스 URL, 긴 라우팅, TLS 핸드셰이크만 간헐적으로 밀리는 회선에서는 살아 있는 줄도 자주 패배로 기록되고 순위가 불필하게 내려갑니다.
이럴 때는 사용자가 모든 필드를 다 외우기보다 “테스트 줄기가 실제 줄기 실패보다 빨리 죽는가?”를 확인하는 순서가 낫습니다. URL 교체 후에도 패턴이 그대로면 패킷 레벨 증상(DNS 우회·UDP·IPv6 분기 등)을 다른 전용 글들과 묶어 봐야 할 수 있습니다. 일단 폴백만 손본다면 타임아웃 체감은 대부분 헬스 대상과 interval 조합부터 줄어드는 경우가 많습니다.
tolerance: 전환과 복귀의 히스테리시스
일부 빌드와 프리셋에서는 폴백 줄기에도 tolerance처럼 숫자가 조금 들쭉날쭉해도 바로 순위를 흔들지 않도록 하는 옵션을 같은 그룹 블록에 포함할 수 있는 경우도 있습니다. 의미가 url-test의 “더 빠른 노드만 골라 갈아타기”와 완전히 같지는 않더라도, 헬스 지연 샘플이 잡음일 때 의미 있는 폭 너머로만 상태가 바뀌게 하는 데 활용합니다. 값이 과하면 망가진 첫 줄에 오래 매달리는 새 비용이 생기므로 패키지 기본 근처에서 조금씩만 옮기세요.
문서에는 동일 이름이라도 버전 차이가 있어 “키가 존재하는데 무시된다”거나 “패치에서만 새 키를 받는다” 같은 상황이 생길 수 있습니다. 따라서 패치 작성 후 렌더링된 최종 문자열 속에 해당 키가 남아 있는지 확인하는 습관이 중요합니다. 파싱 실패 줄기는 YAML 오류 안내에서 패턴까지 같이 잡을 수 있습니다.
lazy: 쓰이지 않는 폴백 줄기의 테스트 부하 줄이기
lazy를 지원하면 실제 선택으로 쓰이지 않는 폴백 그룹이 주기 테스트를 과하게 돌며 코어 부하만 올리는 상황을 완화하는 데 도움이 됩니다. 자동 줄기 종류가 많은 패키지에서 백그라운드 테스트만 모이면 순간 순위 교체 줄기처럼 느껴질 때가 있어, 사용하지 않는 하위 줄기부터 lazy를 코어 버전이 허용하는 범위에서 켜고 끄는 전략이 있습니다. 반드시 현재 버전 릴리스 노트와 예제 YAML과 맞춰 보세요.
YAML에서 fallback 블록을 찾았을 때 보는 레이아웃
들여쓰기 깊이는 패키지마다 다르지만 관념적으로는 한 그룹 블록에 모아두는 형태입니다. 아래 예시 필드 이름은 교육용이며 실제 활성 결과와 대조해 맞춥니다.
# Example shape only — align with your live profile
proxy-groups:
- name: BACKUP-HK
type: fallback
proxies:
- NODE-A
- NODE-B
- NODE-C
url: https://example.com/generate_204 # health endpoint from provider/policy
interval: 120
tolerance: 80
lazy: false
tolerance 등 일부 줄은 코어·프로필 버전 조합에서 생략되거나 다른 키로 표현됩니다. 패치로만 살아나는 줄이라면 패치 순서가 구독 덮어쓰기 뒤쪽에 확실히 오는지 검증해야 합니다.
Clash Verge Rev에서 패치로 폴백만 덮어쓰기
원격 프로필이 주기적으로 갱신되어 로컬에서 직접 YAML 전체를 고정 저장하기 어렵다면, Verge Rev의 패치 기능에 해당 proxy-groups 항목만 넣거나 기존 그룹 이름을 따라 부분 교체 규칙을 씁니다. 패치 레이어가 앞쪽에서 들어오고 구독이 뒤에서 다시 깨먹으면 수정이 반영되지 않습니다. 활성 결과를 보여 주는 미리 보기 기능이 있다면 폴백 블록에 의도한 url와 interval가 남았는지 눈으로 대조하기 바랍니다.
GUI에서 줄기 이름만 보이고 속성 편집이 답답한 경우라도 패치 문자열 하나로 블록을 통째로 교체하면 재현 가능한 테스트가 빨라집니다. 전체 화면 흐름은 앞선 Windows 사용 안내 글과 맞물립니다.
언제 폴백 대신 수동 select로 줄일까?
결제 플로우나 DRM이 붙은 스트림처럼 공인 세션이 줄기 중간에 바뀌는 것 자체가 부하면 자동 줄기 종류 전부를 재검토하는 편이 낫습니다. 이때 증상이 사라지는지 보려면 문제 구간 한정으로 해당 정책을 select로 바꿔 한 노드를 고정해 보세요. 고정 상태에서 증상이 줄어든다면 폴백 줄기 파라미터만 손본다고 해결되지 않았을 가능성도 함께 기록해야 합니다.
반대로 외근·공용 와이파이처럼 상위 줄이 자주 불안정하지만 순위는 명확한 백업 두세 개만 있으면 된다는 패턴이라면 폴백을 유지한 채 헬스 목적지만 현실적인 대상으로 맞추는 편이 맞습니다. 어떤 그룹이 실제 해당 도메인에 연결되는지 연결 패널까지 따라가면 설계 선택이 깔끔해집니다.
실무에서 자주 이어 붙는 질문
헬스는 통과인데 브라우저만 깨져요. 폴백은 테스트 대상 줄기와 사용자 앱 줄기가 분리되어 있어 둘이 어긋날 수 있습니다. 테스트 URL을 실사용 라인과 비슷한 지역 계열로 조정해 보거나 select 고정 테스트로 원인 분기를 하세요.
같은 프로필에 url-test 줄기와 fallback 줄기가 헷갈려요. 이름 라벨이 비슷해도 type 줄이 다르면 동작 논리 전체가 갈립니다. 렌더링된 YAML 스냅샷 한 장을 메모처럼 두고 수정합니다.
패치 순서 문제를 빨리 증명하려면 어떻게 하나요? 일시적으로 테스트 전용 로컬 프로필 하나를 복제해 순수 로컬 병합으로만 수정해 보세요. 줄기 책임이 패치 순서 때문인지 구독 본문 때문인지 즉시 갈립니다.
정리
fallback 전략 그룹은 순위 경쟁이 아니라 줄기 다운·실패 순서 회복에 가깝게 움직입니다. Clash Verge Rev로 GUI와 패치를 같이 쓰는 환경에서는 헬스 URL·interval부터 맞추고, 들쭉날쭉한 전환은 tolerance·lazy를 해당 코어·버전이 지원하는 범위에서 조합한 뒤 렌더링 결과로 검증하는 순서가 안전합니다. 타임아웃처럼 느린 체감은 종종 테스트 줄기 한계에서 먼저 드러납니다. 자동 속도 테스트 쪽 줄기를 같이 묶어 보려면 url-test 전용 글과 각각 초점만 나누어 보시면 학습 순서가 겹치지 않습니다.
원클릭 형태 상용 클라이언트는 자동 줄기 줄을 화려하게 보여 주지만 패치 순서까지 설명하지 못하거나, 테스트 대상 줄기와 사용자 실제 줄기의 차이를 좁히는 안내 없이 순위 교체만 반복 노출되는 경우가 많습니다. 단일 회선 과금 클라우드 VPN은 한 관문에 트래픽을 몰아넣어 테스트 세부 줄기를 사용자가 조정하지 못하게 만들기도 합니다.
반면 오픈소스 Clash·mihomo 줄기에서는 폴백 줄기 속성을 YAML과 패치로 직접 조정하고, 규칙 전체 교과서는 규칙 가이드처럼 별 장으로 두고 따라가며 설계 깊이를 조절할 수 있습니다. Verge Rev를 쓸 때 헬스·간격·히스테리시스를 한 번 안정적으로 맞춰 두면, 구독이 갱신돼 이름만 바뀌어도 동작 줄기 패턴 자체가 덜 바뀌어 유지 시간이 길어집니다.