1 왜 url-test만으로는 부족한가
url-test는 같은 이름의 프록시 그룹 안에서 주기적으로 지연을 재고, 그중 상대적으로 가장 나은 한 노드를 선택합니다. 지연이 튀는 환경에서 «지금 쓸 만한 한 줄기」를 고르는 데 유리하지만, 동시에 여러 노드에 부하를 나누는 동작은 아닙니다. 반대로 이중 구독이나 한 공항의 여러 지역 노드를 모두 살리고 싶다면, 한 번에 한 노드만 쓰는 구조는 대역·동시 연결 측면에서 아쉬울 수 있습니다. 이때 검색 의도에 맞는 것이 type: load-balance입니다. 자동 측정·장애 조치 위주 설명은《Clash URL-Test와 Fallback: 지연 선택과 장애 조치》에서 다루었으니, 본문은 부하 분산과 해시 기반 고정에 초점을 둡니다. 구독 링크를 아직 proxies 목록으로 바꾸지 않았다면《구독 변환: SS·V2Ray·Trojan을 Clash YAML로》를 먼저 맞추는 편이 좋습니다.
2 load-balance 프록시 그룹이 하는 일
Clash Meta 계열(Mihomo 등)에서 load-balance는 proxies에 나열한 여러 멤버 사이에 새 연결(또는 코어 구현에 따른 단위)을 분배합니다. 단일 노드에 모든 TCP·UDP가 몰리지 않게 하려는 목적이며, 최저 지연을 보장하는 모드가 아닙니다. 그 점이 url-test와 직관적으로 다릅니다. 후자는 «누가 더 빠른가」를 보고 한 명을 고르고, 전자는 «여러 줄기로 나눠 실을 잡는다»에 가깝습니다. 또한 fallback은 순서대로 살아 있는지를 보며 한 줄기씩 넘어가는 장애 조치라, 역시 load-balance와 목적이 다릅니다. 세 가지를 같은 문단에서 섞어 말하면 설정이 꼬이기 쉬우니, 한 그룹에는 한 가지 타입을 명확히 두고 rules에서 필요하면 그룹을 중첩하는 편이 안전합니다.
url-test는 가장 나은 한 노드, fallback은 순서대로 살아 있는 노드, load-balance는 여러 노드로 나눈다. 부하 분산은 마지막만 해당합니다.
3 strategy: round-robin과 consistent-hashing
load-balance에는 보통 strategy로 round-robin과 consistent-hashing을 고릅니다. round-robin은 연결을 순환 배정해 가장 고르게 흩뿌리는 데 가깝고, 목적지마다 출구가 달라질 수 있어 일부 사이트에서 로그인 세션이나 위험도 판단(IP 기반)이 불안정해 보일 수 있습니다. consistent-hashing은 해시 함수에 따라 동일한 키(코어 구현상 보통 목적지 주소·포트 등 연결 특성)가 같은 노드로 매핑되도록 하여, 같은 목적지로 가는 연결이 같은 출구로 모이기 쉽습니다. 이것을 흔히 «세션 유지에 가깝다»고 말하지만, 애플리케이션 계층의 HTTP 세션·쿠키를 코어가 직접 다루는 것은 아니고, 연결 단위의 출구 일관성을 높이는 장치로 이해하는 것이 정확합니다.
지연(latency)과의 관계를 헷갈리지 말 것이 중요합니다. consistent-hashing은 «가장 빠른 노드를 고른다»가 아니라 «같은 키는 같은 슬롯으로»입니다. 따라서 특정 목적지가 우연히 느린 노드에 매핑되면, url-test를 쓸 때보다 체감 지연이 나쁠 수 있습니다. 반대로 한 노드에만 몰리는 병목을 줄이고 싶다면 load-balance 자체가 의미가 있고, 그중에서도 사이트별 출구 고정이 필요하면 consistent-hashing이 후보가 됩니다. 은행·결제처럼 IP가 바뀌면 안 되는 트래픽은 원칙적으로 단일 안정 노드나 select로 고정하는 편이 낫고, load-balance는 대역 분산·다중 회선 활용이 우선일 때 검토합니다.
4 proxy-groups YAML 예시 (Mihomo·Clash Meta)
아래는 예시일 뿐이며, 실제 필드 이름·지원 범위는 사용 중인 Mihomo(Clash Meta) 버전 문서를 확인하세요. proxies의 name과 아래 목록이 정확히 일치해야 하고, 구독 갱신 후 이름이 바뀌면 그룹도 함께 고쳐야 합니다. url·interval은 그룹에 따라 헬스 체크 등에 쓰이는 경우가 있어 코어 문서를 따릅니다.
proxy-groups:
- name: MULTI-LB
type: load-balance
strategy: consistent-hashing
proxies:
- NODE-A
- NODE-B
- NODE-C
url: http://www.gstatic.com/generate_204
interval: 300
round-robin으로 바꾸려면 strategy: round-robin만 교체하면 됩니다. lazy: true를 지원하는 환경이라면 자주 쓰이지 않는 그룹의 불필요한 검사를 줄이는 데 도움이 될 수 있습니다. 설정을 넣은 뒤에는 GUI의 구성 검사나 CLI의 -t로 문법을 확인하고, 서버 측에서 동일 계정 다중 동시 접속을 제한하는지도 함께 봐야 합니다. load-balance로 노드를 바꿔 타면 한 계정 한 IP 정책에 걸릴 수 있습니다.
규칙에서 그룹 이름 참조
rules에서는 다른 프록시 그룹과 마찬가지로 MULTI-LB 같은 name을 정책으로 지정합니다. RULE-SET·rule-providers를 쓰면 외부 규칙이 기대하는 정책 이름과 맞추어야 하며, 이름만 바꾸고 규칙을 안 고치면 전혀 다른 그룹으로 트래픽이 갑니다. 대규모 규칙 세트를 쓰는 경우《ACL4SSR·rule-provider》와 정책 이름 관습을 맞추면 유지보수가 쉬워집니다.
5 세션·지연·운영 함정
- 구독 갱신 후 노드 목록 변화: 멤버가 추가·삭제·순서 변경되면 해시 링이 달라져, 이전과 다른 노드로 매핑될 수 있습니다. «어제까지 됐는데 오늘 로그인이 풀린다» 식의 증상이 나올 수 있어, 이름 고정·select가 필요한 서비스는 load-balance만 믿지 마세요.
- 지연 최적화 기대: 부하 분산은 평균 부하·대역 관점이지 RTT 최소화가 아닙니다. 지연이 최우선이면 url-test나 수동 select를 검토합니다.
- UDP·긴 세션: 게임·음성 등은 노드가 바뀌면 끊길 수 있습니다. consistent-hashing이 도움이 될 수는 있으나, 100% 보장은 아닙니다. 게임 전용은 별도 그룹으로 빼는 편이 안전합니다.
- 측정 URL·헬스:
url이 본인 회선에서 불안정하면 그룹 전체가 이상하게 동작할 수 있습니다. 《url-test 글》에서 말한 것처럼 가볍고 안정적인 측정 대상을 쓰세요. - 코어 차이: 상용 Clash 프리미티브만 쓰는 빌드에서는 load-balance 미지원일 수 있습니다. Meta/Mihomo 사용 여부를 먼저 확인하세요.
6 다른 프록시 그룹과 조합하기
실무에서는 지역별 url-test 그룹을 만든 뒤, 그 위에 fallback으로 예비 지역을 얹거나, 반대로 load-balance 안에 개별 노드를 직접 나열하는 식으로 씁니다. 중첩이 가능한지·이름 순환 참조가 없는지는 YAML 검증으로 확인하세요. Linux 서버에 Mihomo만 올린 경우《Linux Mihomo·systemd 가이드》의 절차로 구성을 검사할 수 있습니다. 한 가지 원칙은, 규칙(rules)에서 최종적으로 가리키는 정책 이름이 사용자가 GUI에서 바꾸는 최상위 그룹과 일치하도록 설계하는 것입니다.
7 정리
load-balance는 다중 노드에 트래픽을 나누는 프록시 그룹 유형이고, consistent-hashing은 그중에서도 연결 특성이 같은 출구로 모이도록 해시를 쓰는 전략입니다. url-test가 주는 «가장 빠른 한 노드»와 목적이 다르며, 지연을 최소화하는 스위치가 아님을 기억해야 합니다. YAML은 type·strategy·proxies 목록을 맞추고, 구독 갱신·노드 이름 변경에 취약한 점을 운영 습관으로 상쇄하세요. GUI에서 그룹 동작을 눈으로 확인하려면 다운로드 페이지에서 본인 OS에 맞는 Clash Verge Rev 등 Meta/Mihomo 클라이언트를 쓰는 것이 디버깅에 유리합니다. 오픈 소스·이슈 트래킹은 GitHub를 참고하되, 설치 패키지는 사이트 안내 경로를 우선하는 편이 일관됩니다.
같은 주제를 측속·장애 조치 관점에서 정리한《URL-Test·Fallback》과 짝을 이루어 읽으면, 전략 그룹 전체 그림이 잡힙니다. 설정을 바꿀 때마다 백업 YAML을 남기고, 문제가 나면 select와 단순 규칙으로 되돌려 원인을 쪼개면 복구가 빠릅니다.
