Clash Meta load-balance 정책 그룹: consistent-hashing·round-robin과 rules 연결

먼저 개념: 분배 versus 단일 승자

select는 사람이 고르는 그룹이고, url-test는 헬스 체크로 가장 나은 한 후보를 고릅니다. fallback은 위에서부터 살아 있는 첫 줄을 씁니다. load-balance는 이들과 달리 “한 줄만”이 아니라 트래픽을 후보 풀에 분산합니다. 그래서 검색어로 부하 분산이나 일관 해시를 찾아온 사용자 — 다운로드·API·멀티 탭 브라우징처럼 동시에 많은 TCP 연결이 열리는 환경 — 과 잘 맞지만, 한 긴 동영상 세션을 절대 끊기지 않게 만드는 용도의 기본값으로 쓰기엔 설계가 다릅니다. 머리속에 “분배냐 단일 승자냐”를 먼저 나누면 url-test·fallback 글과 역할이 겹치지 않습니다.

consistent-hashing과 round-robin: 언제 무엇을 쓰나

consistent-hashing은 출발지·목적지 등 코어가 정한 키로 해시를 만들어 후보 중 하나에 매핑합니다. 같은 키를 가진 연결은 같은 노드를 탈 가능성이 높아, 사이트나 API가 세션·쿠키·IP 일관성에 민감할 때 유리한 편입니다. 노드를 넣거나 빼면 일부 매핑만 다시 계산되는 안정적 재분배라는 설명을 자주 듣게 되는데, 실무에서는 “같은 호스트로 여러 번 붙을 때 한 노드에 붙는 비율이 어느 정도 유지되는가”로 체감하면 됩니다.

round-robin은 후보를 순서대로 돌며 연결을 나눕니다. 구현 단순·예측이 쉽고, 후보 지연이 비슷한 풀에서 대칭적으로 터치 수를 맞추고 싶을 때 고려합니다. 반대로 특정 목적지가 항상 특정 노드에 붙어야 한다는 보장은 consistent-hashing 쪽이 더 가깝습니다. 둘 다 “가장 빠른 한 줄”이 아니므로, 지연 최소만이 목표면 url-test가 먼저입니다.

1단계: proxies 후보와 이름 정리

load-balance의 proxies: 목록에는 이미 정의된 프록시 이름이나 다른 정책 그룹 이름이 들어갑니다. 구독 전체에서 쓸 이름을 그대로 나열할 수도 있고, 지역별 select 안에 모아 둔 뒤 그 이름만 넣을 수도 있습니다. 오타 한 글자면 코어가 기동 실패하거나 해당 행을 건너뛰므로, 편집기에서 이름 검색으로 전부 존재하는지 확인하는 습관이 중요합니다. 원격 규칙 세트를 고치면서 그룹 이름이 바뀌는 경우는 rule-provider 갱신 직후 로그를 한 번 훑는 편이 안전합니다.

2단계: proxy-groups에 load-balance 블록 추가

proxy-groups 아래에 새 항목을 추가하고 type: load-balance를 지정합니다. strategy에는 consistent-hashing 또는 round-robin을 넣습니다. 클라이언트·코어 버전에 따라 옵션 이름이 조금 다를 수 있으니, 사용 중인 Mihomo 릴리스 문서와 샘플 프로필을 같이 보세요. 헬스 체크를 쓰는 구성이라면 url과 interval을 함께 적어 후보가 죽었을 때 분배 대상에서 빼는 데 도움을 줍니다. lazy: true처럼 자주 쓰지 않는 그룹의 부하를 줄이는 패턴은 url-test 글과 비슷한 직관으로 적용할 수 있습니다.

3단계: rules와 상위 그룹에서 이름 참조

준비한 name을 rules 오른쪽에 둡니다. 예를 들어 DOMAIN-SUFFIX,cdn.example.com,LB-GROUP처럼 쓰면 해당 접미사는 모두 그 그룹을 탑니다. 기본 출력이 select인 프로필이라면, select의 proxies: 목록에 LB-GROUP 문자열을 한 줄 추가해 사람이 수동으로 고를 수 있게 할 수도 있습니다. MATCH 행을 메인 출구로 두었다면 마지막에 LB-GROUP을 넣기보다, 해외 일반 웹만 분산하고 국내· 직접은 DIRECT로 두는 식으로 규칙 순서를 나누는 것이 일반적입니다. 규칙이 기대와 다르면 DNS·fake-ip와 행 순서를 함께 봐야 합니다.

YAML 예시

아래는 필드 이해를 위한 예시입니다. 노드 이름은 구독에 맞게 바꿉니다.

# Illustrative snippet — replace proxy names with your subscription
proxy-groups:
  - name: LB-EXIT
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - TOKYO-01
      - TOKYO-02
      - OSAKA-01
    url: http://www.gstatic.com/generate_204
    interval: 300

  - name: LB-ROUND
    type: load-balance
    strategy: round-robin
    proxies:
      - SINGAPORE-01
      - SINGAPORE-02

rules:
  - DOMAIN-SUFFIX,example.com,LB-EXIT
  - MATCH,LB-ROUND

실제 프로필에는 그 위에 수십 줄의 DOMAIN·GEOIP 행이 있으므로 MATCH는 마지막 안전망인지 반드시 확인하세요.

운영 팁: 로그, 혼합 구성, mixin

분배가 의도대로인지는 클라이언트의 연결 보기나 코어 로그로 체인에 찍힌 노드 이름을 비교하는 것이 가장 빠릅니다. 여러 탭을 열어 같은 사이트에 동시에 접속했을 때 노드가 어떻게 갈리는지 보면 consistent-hashing과 round-robin 차이가 눈에 들어옵니다. 원격 구독이 덮어쓰기 때문에 로컬에만 그룹을 두고 싶다면 mixin으로 주입하는 방식을 검토하세요.

문제 해결: 갑자기 IP가 바뀐다, 한 노드만 든다

한 노드만 계속 든다면 후보 중 일부가 헬스에서 탈락했거나, 이름이 잘못되어 실질적으로 한 줄만 살아 있는지 확인합니다. 짧은 간격에 출구가 바뀐다면 후보 지연이 들쭉날쭉하거나 round-robin 특성상 순환하면서 체감이 흔들리는 경우가 있습니다. 특정 사이트만 로그인 풀림은 해당 도메인을 분산 그룹에서 빼고 단일 그룹으로 고정하는 편이 빠를 때가 많습니다.

증상	살펴볼 곳
출구 IP가 자주 바뀜	strategy, 후보 수, 해당 앱이 IP 고정을 요구하는지
분배가 안 되는 것 같음	규칙이 다른 그룹을 가리키는지, 헬스로 후보가 줄었는지
리로드 후 오류	proxies 이름 오타, 들여쓰기, 코어 버전과 필드 호환

FAQ

url-test 대신 load-balance를 쓰면 더 빨라지나요?

반드시 그렇지는 않습니다. url-test는 가장 낮은 지연 한 줄에 모을 때 유리하고, load-balance는 여러 줄에 나눌 때 유리합니다. 대역 집중을 줄이거나 규제·쿼터를 피하려는 목적이라면 분배가 맞고, 지연 최소만 본다면 자동 단일 선택을 먼저 고르세요.

목록에 DIRECT를 넣어도 되나요?

구성에 따라 가능한 경우도 있지만, 분배 의미와 “직접은 규칙 상단에서 처리” 원칙이 충돌하지 않게 설계해야 합니다. 대부분의 사용자는 국내 트래픽을 규칙으로 먼저 DIRECT에 보내고, 해외만 프록시 그룹으로 넘깁니다.

실무 체크리스트

마치며

load-balance는 UI 스위치 한 방이 아니라, 후보 풀·전략·규칙 행이 동시에 맞아야 하는 설정입니다. 숫자와 이름을 바꿀 때마다 로그로 한 번씩 검증하면 같은 구독이라도 체감이 달라집니다.

범용 프록시 앱은 화면만 간단해 보여도, 분배·측정·DNS가 얽히면 프로필을 여러 번 갈아야 하는 번거로움이 생깁니다. 검증 단계가 길어질수록 YAML·규칙·로그를 한 클라이언트 안에서 다루는 경험이 중요해집니다.

Clash는 오픈 생태계와 꾸준한 Meta·Mihomo 호환을 전제로, 구독·로컬 규칙·고급 그룹을 한 파일에서 정리하고 UI로 재적용하기 쉽게 설계되어 있습니다. 웹과 API를 나눠 쓰면서 노드 부담을 줄이고 싶다면 load-balance를 시험해 보시고, 아래 링크에서 클라이언트를 받아 프로필을 바로 맞춰 보실 수 있습니다.

Clash를 무료로 내려받고 부하 분산 그룹을 바로 시험해 보세요