Clash Meta(Mihomo) load-balance와 consistent-hashing: proxy-groups로 로드밸런싱·출구 고정을 단계별로 설정하기 (2026)

무엇을 위해 load-balance를 쓰나

url-test는 여러 후보 중 지연 혹은 헬스 상태를 보고 현재 최적인 한 줄을 고르는 데 강합니다. 반면 load-balance는 “한 줄만 쓴다”보다 동시에 여러 줄을 활용하거나, 연결 단위로 항상 같은 줄로 모으고 싶은 패턴에 더 가깝습니다. 예를 들어 대량 다운로드·여러 탭 브라우징처럼 새 연결이 계속 생길 때 순환으로 노드를 고르게 만들거나, 특정 서버 IP·포트 조합마다 같은 업스트림을 붙여 두어 캐시·속도 편차를 줄이려는 식입니다.

전제는 여전히 같습니다. proxies에 정의된 name과 그룹 안의 문자열이 정확히 일치해야 하고, 실제 트래픽은 rules가 가리키는 정책 이름을 타야 합니다. 광역 GEOIP나 큰 IP-CIDR이 먼저 매칭되면 아래쪽 정책은 실행되지 않으니, 충돌이면 규칙 순서·매칭부터 다시 그리는 경우가 많습니다. relay로 이중 홉을 엮는 그림은 relay 체인 글과 구분해서 읽으면 혼선이 줄어듭니다.

round-robin과 consistent-hashing, 한 줄 요약

round-robin은 코어가 새로 잡히는 연결(또는 구현 세부에 따라 스케줄 단위)을 후보 목록을 돌아가며 할당합니다. 한 사이트에 대해 브라우저가 여러 TCP·TLS 세션을 동시에 열면 서로 다른 노드로 갈라질 수 있어, 체감상 “한 탭마다 속도가 들쭉날쭉”해 보일 수도 있습니다. 대신 장기간 보면 여러 회선에 부하가 비교적 고르게 퍼지는 장점이 있습니다.

consistent-hashing은 흔히 목적지(도메인·IP·포트 등 코어가 쓰는 키)를 해시해 그 결과로 업스트림을 고릅니다. 같은 목적지로 향하는 새 연결은 같은 버킷으로 붙기 쉬워, 사용자 입장에서는 “사이트마다 한 줄에 고정”처럼 느껴지는 경우가 많습니다. 다만 이것은 웹 서버가 주는 세션 쿠키나 로그인 토큰을 보장하는 레이어가 아니라, 연결 라우팅 규칙에 가깝습니다. 앱이 중간에 다른 호스트로 재연결하거나, HTTP/3·QUIC처럼 연결 특성이 다른 프로토콜을 섞으면 기대와 어긋날 수 있습니다.

1proxies 이름과 그룹 구성 습관

그룹의 proxies 배열에는 문자열 이름만 올립니다. 구독에서 한꺼번에 들어온 이름을 정리하지 않은 채 일부만 그룹에 넣으면, 저장 시 참조 오류로 코어가 기동하지 않거나 해당 멤버만 빠집니다. GUI를 쓰더라도 텍스트로 합치는 날을 대비해 노드 이름 목록을 한 번 스냅샷해 두고, 그룹과 rules에서 같은 철자를 쓰는 습관이 안전합니다.

2round-robin 스케치

아래는 개념용 스케치입니다. 실제 프로필에 넣을 때 노드 이름은 환경에 맞게 바꿉니다. 사용 중인 코어·GUI 버전에 따라 일부 키 이름이 조금 다를 수 있으니, 필요하면 문서 허브와 릴리스 노트를 함께 확인하세요.

# Sketch — merge into your real profile; proxy names must exist under proxies:
proxy-groups:
  - name: "LB-ROUND-ROBIN"
    type: load-balance
    strategy: round-robin
    proxies:
      - "tokyo-A"
      - "tokyo-B"
      - "seoul-C"

  - name: "PROXY"
    type: select
    proxies:
      - LB-ROUND-ROBIN
      - "tokyo-A"
      - DIRECT

LB-ROUND-ROBIN을 PROXY 같은 상위 select 안에 넣어 두면, 클라이언트 UI에서는 사용자가 PROXY만 고르고 실제 분산은 하위 그룹이 담당하는 식으로 운영할 수 있습니다. 장애 대응을 같은 그룹 안에서 하고 싶다면 fallback 그룹과 조합하는 대신, 아예 별도 정책 이름으로 나누어 rules에서 용도별로 가리키는 편이 디버깅에 유리합니다.

3consistent-hashing 스케치

# Sketch — same destination tends to stick to the same upstream
proxy-groups:
  - name: "LB-CONSISTENT"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - "tokyo-A"
      - "tokyo-B"
      - "seoul-C"

  - name: "PROXY"
    type: select
    proxies:
      - LB-CONSISTENT
      - DIRECT

목록에 노드를 추가·삭제·순서 변경하면 해시 링이 바뀌어 기존 목적지도 다른 줄로 재할당될 수 있습니다. 운영 중 인플레이스로 멤버를 자주 바꾸면 체감상 “갑자기 줄이 바뀌었다”는 리포트가 나오기 쉬우니, 변경 후에는 짧게 연결 로그나 패널에서 선택 멤버가 어떻게 보이는지 확인하는 것이 좋습니다.

4rules에서 그룹 이름 연결하기

그룹을 아무리 잘 만들어도 rules가 다른 정책을 가리키면 효과가 없습니다. HTTPS에서 호스트가 숨겨져 있으면 도메인 규칙이 기대대로 동작하지 않을 수 있어, 그때는 Sniffer 전제를 맞추거나 IP 기반 규칙과의 우선순위를 조정해야 합니다. 마지막에 MATCH,PROXY처럼 넓게 잡고 세부만 위에서 덧씌우는 패턴이 흔합니다.

rules:
  - DOMAIN-SUFFIX,corp.internal,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위에서 PROXY는 앞서 정의한 select 그룹 이름입니다. 운영자는 UI에서 최종적으로 LB-CONSISTENT나 LB-ROUND-ROBIN이 선택된 상태의 PROXY를 쓰게 하면, 규칙 파일은 단순하게 유지한 채 실험만 교체할 수 있습니다.

흔한 오해와 실무 함정

첫째, consistent-hashing을 로그인 세션 고정 장치로만 이해하면 안 됩니다. 코어가 보는 키와 앱이 만드는 연결 패턴이 다르면 같은 서비스라도 줄이 바뀝니다. 둘째, UDP·음성·게임처럼 비연결 특성이 강한 트래픽은 TCP 중심으로 생각한 기대와 어긋날 수 있습니다. 실사용 검증은 항상 해당 앱으로 하세요. 관련해서는 VoIP 시나리오를 다룬 Discord·UDP·TUN 글과 관점을 나란히 두면 좋습니다.

셋째, DNS가 코어 밖에서 따로 해석되면 출구만 바뀌고 문제가 유지되는 패턴이 남습니다. FakeIP·DoH·스플릿 환경은 Meta 코어 DNS 유출 방지 순서와 맞춥니다. 넷째, GUI에서 사용자가 수동으로 특정 노드를 고르면 하위 load-balance 그룹이 가리키는 선택을 덮어쓸 수 있어, 테스트 중에는 UI 상태를 다시 확인해야 합니다.

5검증: 패널·로그·실사이트

최소 루틴은 (1) 저장 후 코어 에러 없이 기동했는지 (2) external-controller·Yacd 등에서 해당 그룹과 활성 연결의 출구 이름이 기대와 같은지 (3) 문제 사이트를 새로 열거나 새 탭으로 재현해 보고 연결 로그의 정책 이름을 확인하는 순서입니다. 한 번에 변수를 여러 개 바꾸지 말고, 전략·멤버 목록·규칙 순서를 하나씩만 움직이면 원인이 좁혀집니다.

라운드로빈을 쓸 때 여러 줄에 갈라진 연결이 한 앱 안에서 보이면, 그것이 전략상 정상일 수 있습니다. 반대로 일관 해시를 썼는데도 줄이 바뀌면 목적지 재정의(SNI·리다이렉트)나 목록 변경을 의심합니다.

오픈소스 정보와 설치 패키지

Mihomo의 소스·이슈·라이선스는 GitHub에서 확인할 수 있습니다. 다만 클라이언트 설치 파일의 주된 안내는 이 사이트 다운로드 페이지를 권장합니다. 저장소 링크는 투명성용으로 두고, 설치 경로는 허브로 통일하면 사용자 혼선이 줄어듭니다.

맺음말

load-balance는 round-robin으로 부하를 퍼뜨리거나 consistent-hashing으로 목적지 단위 출구를 안정적으로 묶는 proxy-groups 패턴입니다. 자동 헬스체크 기반으로 한 줄 고르기는 url-test·fallback 글에 맡기고, 이 글에서는 YAML 연결과 오해 가능 지점만 분리했습니다. 규칙·DNS·스니퍼 전제가 같을 때 설정은 재현 가능하고, 로그만으로도 “어떤 정책을 탔는지”가 드러나는 편이라 한 번 틀을 잡아 두면 이후 튜닝이 빨라집니다.

같은 Clash 계열이라도 GUI마다 편집 경로가 다르니, 스케치를 복사한 뒤 저장 → 로그 → 실사이트 루프를 짧게 여러 번 도는 방식이 가장 안전합니다. 다른 도구에 비해 정책 이름과 트레이스가 읽기 쉬운 편이라, 운영 문서에 그룹 이름 규칙만 정해 두어도 팀 협업이 수월해집니다.

→ Clash를 무료로 다운로드하고, load-balance 전략을 프로필에 반영해 여러 노드 구성을 검증해 보세요