load-balance 가 풀 문제·url-test 와 무엇이 다른가

Clash 계열에서는 정책 그룹(proxy-groups) 이 “지금 플로를 어떤 출구 클래스에 맡길지”를 정합니다. select는 UI에서 마지막으로 고른 자식 하나로 고정되고, url-test는 프로브 주기와 지연으로 비교적 빠른 멤버에 붙이려 하며, fallback은 목록 순서대로 상태를 타고 활성 하나로 수렴합니다. 반대로 load-balance의 의미는 풀 안 멤버 사이에서 연결 부하를 분산하는 것입니다. 다중 스레드 다운로드·짧게 많이 여는 세션처럼 여러 회선에 플로를 펼치려 할 때 적합하지, “항상 밀리초 순위 1등만” 같은 목표와는 어긋납니다.

검색으로 “로드밸런스”만 치면 사실 속마음은 자동 최저 지연 선택인 경우가 많습니다. 그때는 남매 글의 url-test 절이 맞습니다. 두 개념을 섞으면 load-balance를 썼는데도 왜 계속 같은 노드처럼 느껴진다거나, 반대로 url-test만으로 초고병렬 다운로드를 기대했다가 제공자 쪽 속도 한도나 세션 거절만 만지는 패턴이 납니다.

Windows 11 데스크톱에서는 예컨대 “다운로드 전용” 그룹 아래 플로를 세 줄로 깔고 싶거나, 도구 여럿에서 짧은 TCP 세션이 하나의 POP에만 몰리지 않길 원할 때가 흔합니다. 그때 종종 같은 비용보다 Mihomo 클래스 proxy-groups 한 줄의 type: load-balance와 맞는 strategy 선택이 빠른 해입니다. 아래는 CfW 에서 Meta/Mihomo 경로로 프로필이 파싱된다는 전제입니다. 극히 오래된 빌드에서 필드 에러만 반복되면 코어 교체나 유지되는 GUI 쪽으로 이동하는 편이 낫습니다.

ℹ 사이트 내 역할 분담: 이 페이지는 Clash for Windows + YAML 에서만 load-balance를 다룹니다. Proxies 카드 패턴과 모드 체감은 Win11 CfW 지연·정책 그룹 GUI 글을, 자동 최저 지연과 주·예비 체인은 url-test·fallback 전문을 보세요. TUN·Strict Route·Party 스킨 캡처급 순서는 이 글에 넣지 않았습니다.

시작 전: Mihomo 코어·프로필·이름 충돌

편집기를 열기 전 확인 세 가지입니다. 첫째, Profiles에서 실제로 쓰는 번들을 골라 두었는지, 트레이·메인 창에서 코어가 떠 있는지입니다. 디스크의 텍스트만 고치면 메모리에 올린 구성과 엇갈립니다. 둘째, 동작 코어가 Mihomo(Meta) 계열인지입니다—load-balance 의 strategy 표현과 동작은 릴리스 문서가 기준입니다. 구형 빌드가 미지 필드를 조용히 무시하면 저장은 됐는데 행동이 평범한 그룹처럼 보일 수 있습니다. 셋째, 새 그룹 이름을 구독이 자동으로 만든 항목과 겹치지 않게 짓습니다. PROXY나 “♻ 자동 선택” 같은 원격 패턴 아래 같은 문자열을 또 쓰면 병합·우선순위만 꼬입니다.

전체 config.yaml이 구독 URL 한 번 받을 때마다 통째로 덮어써 진다면, 로컬에 손본 proxy-groups 줄은 “업데이트” 한 번에 사라질 수 있습니다. 장기적으로는 원격 패치, provider 오버레이, 로컬 include로 증분을 합치는 방식이 필요하지만 제공자별로 다르니 브랜드 튜토리얼까지는 두지 않습니다. 대신 트러블슈팅 할 때 스스로 “다음 새로 고침에 이 파일 또 덮일까?”를 먼저 물어보면 낭비 시간이 줄어듭니다.

마지막으로 노드 문자열 준비: proxies: 아래 각 name 이 proxy-groups[].proxies 에 나오는 문자열과 바이트 단위까지 같아야 합니다—대소문자, 공백, 이모지까지 포함합니다. 많은 사람이 카드 레이블을 복사했는데 YAML 정의 와 하나도 다른 보이지 않는 문자 때문에 막합니다. 헷갈리면 해당 노드 블록을 에디터에서 검색해 정의 줄을 통째로 복사해 넣습니다.

CfW에서 Profiles 로 들어가 편집기 여는 순서

오래된 Clash for Windows는 활성 번들을 Profiles 목록 위에 두는 패턴입니다. 해당 프로필을 고른 다음 편집 아이콘·메뉴·“폴더에서 열기 옆 단축 편집” 등 버전별 엔트리로 들어가 실제 적재본과 같은 본문 YAML을 여세요. VS Code처럼 외부 에디터로 직접 경로만 열도 되지만, CfW 가 저장하고 리로드할 때 같은 파일인지부터 맞춥니다—“디스크는 바뀌었는데 UI는 옛 버전”의 대표 레시피입니다.

속도 순서 추천: 전체 파일을 시간 붙여 백업 후 proxy-groups: 근처만 수정합니다. 들여쓰기는 스페이스, 리스트 줄은 하이픈 한 칸 후 값—탭 중간 삽입은 파서가 극적으로 깨지기 좋습니다. 저장 후 CfW 로 돌아와 빨간 오류 줄이 있는지 보고, 코어 거부 시 백업으로 롤백한 뒤 구간별로 줄여 가며 깨진 곳만 찾습니다.

Proxies 탭만 누르는 경로보다 두뇌 부하는 크지만 한 그룹의 타입 문자열만 바꿀 자유가 생깁니다. Win11에서 CfW 에 익숙한 사람에게 고급 정책을 디스크에 남기는 가장 짧은 통로입니다. YAML 자체가 싫다면 Verge Rev 등 오버레이 UI를 검토하면 되지만 이 글 표준은 CfW 라벨링을 유지합니다.

복사용 proxy-groups: type·strategy·proxies

아래 블록은 문법 검토용 예시입니다—MY-LB-POOL 을 새 그룹 이름으로, node-a 등은 proxies: 에 실제 존재하는 name 으로 바꿉니다. Mihomo 계열에서는 strategy 로 흔히 consistent-hashing 과 round-robin 이 비교됩니다—전자는 목적지 기준 비교적 한 멤버에 매달리려 하고 후자는 멤버를 순환합니다. 허용 키는 릴리스 노트와 맞추고 저장 시 미지 필드 에러 나면 표기부터 다시 확인합니다.

proxy-groups snippet 
proxy-groups:
  - name: "MY-LB-POOL"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - node-a
      - node-b
      - node-c

목적지 차원 고정 없이 가능한 균등 분포를 보고 싶으면 같은 풀로 round-robin 대조 실험을 합니다. 어떤 strategy 든 느린 멤버도 슬롯을 받습니다—건강도 기반 순위 건너뜀처럼 느껴지는 fallback 행태와 같지 않습니다. 실무에서는 같은 지연·손실 밴드를 가진 노드 세~다섯 개만 남긴 다음 로드밸런스를 쓰는 편이, 구독 전체 상백 줄을 무작정 넣는 것보다 안정적입니다.

같은 패턴 중첩도 가능합니다: load-balance 의 proxies 에 다른 그룹 이름을 두어 지역·수동 선택을 먼저 묶은 뒤 하위에서만 세션 분산합니다. 디버깅은 Connections 에 더 의존하므로 처음에는 평면 풀만으로 부하가 진짜 깔렸는지 확인한 다음 단계적으로 넓히세요.

규칙에 새 그룹 이름 연결하기

그룹만 만들면 라우팅은 바뀌지 않습니다. rules: 의 세 번째 열 또는 상위 최종 줄이 새 이름을 참조해야 합니다—전형적으로 DOMAIN-SUFFIX,…​,MY-LB-POOL 과 같습니다. 규칙은 위에서 아래 순서 매칭이라 앞선 넓은 규칙이 잡히면 나중 줄은 영원히 지나가지 않을 수 있습니다. 순서 패턴은 라우팅 모범을 같이 놓습니다.

rules example 
rules:
  - DOMAIN-SUFFIX,large-cdn.example,MY-LB-POOL
  - MATCH,MY-LB-POOL

두 번째 예시 줄(MATCH)은 데모용입니다. 실무에서는 종종 최종 줄을 계속 손 선택 그룹에 두고, 대용량·특정 도메인 줄만 로드밸런스 풀에 향하게 합니다. 로그인 상태·금융·일부 API처럼 같은 출구를 기대하는 사이트는 큰 허브 풀과 한 규칙에 섞지 말거나, 최소한 해시가 출구 변경을 줄이는지만 이해한 뒤에만 넣습니다.

저장·리로드·Connections 검증

YAML 저장 후 CfW 에서 설정 리로드를 한 번 거칩니다(버전 따라 General 또는 Profiles 근처). 새 그룹 라벨이 Proxies 목록에 뜨고 자동 분산처럼 동작하는지부터 봅니다. 여전히 손 선택처럼만 보이면 비활성 프로필을 고치고 있거나 파싱 실패로 기본 레이아웃에 떨어진 경우가 많습니다.

검증 때 지연 위젯만 보지 마세요—Connections 를 켠 채 브라우저·다운로드로 여러 TCP 를 동시에 열었을 때 이름이 순환하는지 봅니다. 전부 한 멤버에 고정되면 규칙 실제 적중·하위 재매핑·시스템 프록시/TUN 우회 같은 부분부터 의심합니다. 일부 앱만 이상하면 mixed-port 와 프록시 우회 패턴 글을 교차 검사합니다.

대조법으로 잠시 해당 그룹을 select 단일 노드로 바꿔 애플리케이션 레이어 장애를 걷어낸 뒤 다시 load-balance 로 되돌리면 TLS 같은 문제와 전략 타입 문제를 헷갈리지 않게 됩니다—GUI 안내글에서 로그부터 보라던 습관과 동일하지만 확인 목표가 “어떤 노드” 대신 “풀 깔았는지”로 바뀝니다.

주의: 구독 덮어쓰기·불량 노드·UDP·금융·SSO

이미 언급한 원격 덮어쓰기. 다음은 불량 멤버 혼입입니다—분산 로직은 “느린 건 피해서만 보냄”하지 않으며 지연 차가 크면 번갈 속도만 요동합니다. 게임·통화처럼 UDP 차이 큰 회선들을 한 풀에 넣으면 체감만 나빠질 때가 많아 별 그룹·별 규칙 유지가 낫습니다.

금행·회사 VPN·SSO처럼 IP 변동과 악성 로그인 탐지에 민감한 플로는 긴 세션 동안 같은 출구를 가정하는 경우가 있습니다. 해시가 덜 깜박여도 SLA급 고정 종단치는 아닙니다—이런 도메인 에러로 로드밸런스를 걸었다가 간헐적 재인증까지 보면 Clash 버그보다 리스크 모델 불일치에 가깝습니다.

⚠ 준수: 사내 정책·공급 약관·현지 규제가 허용하는 계정과 네트워크에서만 적용합니다. 우회 목적 안내가 아니라 장비 구조 설명입니다.

자주 묻는 질문

load-balance 가 자동으로 지연이 가장 낮은 노드를 고르는가요?

아니오. 로드밸런스 정책 그룹은 strategy 에 따라 활성 멤버 사이에 연결 부하를 나눕니다. 「항상 측정상 1등 노드」가 목표라면 url-test 나 수동 select 가 맞으며, 세부 필드는 남매 글(url-test·fallback)을 함께 보세요.

consistent-hashing 와 round-robin 은 어떻게 선택하나요?

consistent-hashing 은 종종 목적지 지문 기준으로 동일 업무 플로를 비교적 같은 멤버에 두어 세션 일관성에 유리합니다. round-robin 은 새 연결마다 순환 분배에 가까워 순수 처리량·평등 분산에 맞추기 쉽습니다. 같은 사이트에 오래 같은 출구가 필요하면 전자, 무작위 다중 연결이 우선이면 후자 후보입니다.

구독을 갱신한 뒤 내 load-balance 그룹이 사라졌어요.

원격 구독이 전체 설정을 매번 덮어쓰면 로컬에서 손본 proxy-groups 줄이 증발합니다. 제공자 패치나 로컬 include·provider override 등 병합 전략을 정하고, 갱신 후에는 proxy-groups 블록을 diff 로 확인해야 합니다.

설치·구독 베이스라인: Windows 11 Clash for Windows 설치 · 그래픽 지연·모드 감각: 지연 테스트·프록시 그룹 GUI · 자동 최저 지연과 주·예비 체인: url-test·fallback YAML · 로그: timeout·TLS 초보 글. 다섯 편으로 “설치·클릭·편집·로그” Win11 CfW 학습 줄을 만들 수 있습니다.

맺음말

Windows 11에서 Clash for Windows 의 한 정책 그룹만 load-balance 로 두려는 사람은 명시적으로 「지연 순위표 1등」보다 연결 단위 분산을 원한다는 뜻입니다. Profiles → YAML 로 proxy-groups 를 쓰고 strategy 를 고른 뒤 규칙 세 번째 열에 이름을 두고 Connections 로 다중 연결 검증까지 하면 순서가 닫힙니다—url-test/fallback 디테일은 남매 글로 돌아가면 되고 모든 타입을 한 글에 뭉개지 마세요.

유지 종료된 데스크톱 셸에서는 YAML 기능이 들쭉날쭉하고 Mihomo 최신 필드와 어긋나며 “타입”을 카드 깊숙이 숨기는 일이 많습니다. 반대로 Clash V.CORE 쪽 메시지는 지속 업데이트되는 코어와 같은 문법으로 적을 클라이언트를 같은 문맥으로 묶습니다—CfW 에서 배운 load-balance YAML 은 현재 유지되는 셸·규칙 체인으로 이동해도 표현 자체가 낡아서 막히는 일이 줄어듭니다.

→ 현대 Mihomo 생태계에 맞는 클라이언트는 사이트 공통 다운로드 허브에서 이어 규칙·부하 분산 설정을 같은 재현 가능한 베이스 위에 쌓을 수 있습니다.