Clash 다중 구독 병합: 오버라이드와 프로필 분할로 YAML 한 벌 쓰기 (2026)

1. 다중 구독이 서로 덮어쓰기처럼 보이는 이유

구독 한 줄은 보통 완전한 프로필 조각입니다. proxies·proxy-groups·rules·dns까지 한꺼번에 실려 오는 경우가 많아, 클라이언트가 "그대로 합치기"만 하면 같은 키가 뒤쪽에서 앞을 덮거나, 프록시 이름이 동일해 구독 충돌이 납니다. 특히 🔰 Proxy 같은 표준 그룹 이름을 여러 소스가 동시에 정의하면, 마지막에 로드된 정의만 살아 남는 식의 혼란이 생깁니다. mihomo 코어 입장에서는 "한 번에 로드되는 단일 YAML 트리"가 진실이므로, 다중 구독 병합은 단순 문자열 붙이기가 아니라 이름 공간과 규칙 우선순위를 설계하는 일에 가깝습니다.

또 하나의 함정은 rules 상단과 하단의 차이입니다. MATCH에 가까운 광역 규칙이 위에 올라가 있으면, 아래에 아무리 세밀한 줄을 넣어도 도달하지 못합니다. 오버라이드로 규칙을 "맨 앞에 끼워 넣기"하지 않으면, 새 구독이 들어올 때마다 체감상 "내 분기가 사라졌다"로 느껴집니다. 그래서 이 글은 소스를 proxy-providers로 쪼갠 다음, 사용자 고정 블록은 프로필 머지에서 항상 같은 순서로 붙도록 가정합니다.

2. 한 프로필로 합칠지, 프로필을 나눌지

목표가 "출퇴근용·게임용·업무용을 완전히 분리"라면 프로필 자체를 나누는 편이 정신 건강에 이롭습니다. 클라이언트에서 프로필만 바꾸면 dns·tun·rules 전체가 함께 바뀌므로, 서로 다른 공항의 DNS 스타일이 섞여 생기는 문제를 원천 차단할 수 있습니다. 반대로 "노드 풀은 한 화면에서 고르고 싶다"면 한 프로필 안에서 다중 구독 병합이 맞습니다. 이때는 반드시 이름 충돌을 먼저 설계하고, 지연·페일오버·로드 밸런싱 글과 같이 "여러 노드를 한 그룹에 넣었을 때"의 동작을 이해해 두는 것이 좋습니다.

3. 1단계: proxy-providers로 소스 분리·이름 접두

proxy-providers는 URL에서 주기적으로 노드 목록을 받아 mihomo가 내부 proxies로 펼칩니다. 제공자마다 health-check·override(프로바이더 단위 패치)를 둘 수 있어, "이 공항은 이렇게만 손본다"를 소스별로 고정하기 좋습니다. 핵심은 프록시 이름이 겹치지 않게 하는 것인데, 클라이언트가 지원한다면 proxy-prefix 같은 필드로 접두를 붙이거나, 제공자 YAML에서 노드 이름 패턴을 조정합니다. 이름이 겹치면 나중에 로드된 쪽이 덮어쓰거나, 그룹 참조가 엉켜 구독 충돌 디버깅이 길어집니다.

# Example — provider names and URLs are placeholders
proxy-providers:
  airport-a:
    type: http
    url: "https://example.com/sub-a"
    path: ./providers/airport-a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
  airport-b:
    type: http
    url: "https://example.com/sub-b"
    path: ./providers/airport-b.yaml
    interval: 3600

위처럼 소스를 파일 경로로도 쪼개 두면, GUI가 구독을 덮어써도 "캐시된 제공자 파일 + 메인 YAML" 구조를 유지하기 쉽습니다. YAML 병합을 수동으로 할 때도 동일한 원칙이 적용됩니다. 즉 proxies: 배열을 문자 그대로 이어 붙이기보다, 제공자 블록을 늘리고 proxy-groups에서만 소비합니다.

4. 2단계: policy-groups에서 선택·지연 그룹 만들기

제공자가 노드를 펼친 뒤에는 proxy-groups에 type: select로 "공항 A만", url-test로 "지연 최저", fallback로 "살아 있는 첫 노드" 같은 정책을 겁니다. 다중 구독 병합의 목적이 "한 화면에서 고른다"면, 최상위 select 아래에 공항별 서브 그룹을 두는 트리가 읽기 쉽습니다. 반대로 모든 노드를 한 그룹에 평면 나열하면 UI는 간단해지지만, 수백 개 항목이 한 번에 뜨고 규칙에서 참조하기도 어려워집니다.

rules에서는 이 정책 그룹 이름만 박으면 되므로, 그룹 이름을 구독 원본과 동일하게 두지 말고 내 네임스페이스로 고정하는 습관이 중요합니다. 예를 들어 🌐 Outbound·✈️ Airports처럼 로컬에서만 쓰는 레이블을 쓰면, 새 공항 YAML이 들어와도 규칙 줄을 대량 수정할 일이 줄어듭니다.

5. 오버라이드와 머지 순서(클라이언트·수동 YAML)

Clash Verge Rev 등 데스크톱 클라이언트는 종종 "베이스 구독 + 사용자 패치" 모델을 씁니다. 의미는 같습니다. 먼저 원격 구독이 펼쳐지고, 그다음 로컬 오버라이드 YAML이 같은 키를 덮거나 배열에 항목을 끼워 넣습니다. 여기서 순서가 뒤집히면 사용자 규칙이 구독의 광역 MATCH보다 아래에 깔려 무용지물이 됩니다. 그래서 클라이언트 설정에서 "패치가 항상 마지막"인지, "특정 섹션만 앞에 삽입"인지 문서를 확인하고, 팀 내에서는 한 가지 패턴만 쓰기를 권합니다.

완전 수동 편집이라면, config.yaml을 Git으로 관리하고 구독은 proxy-providers로만 받아들이는 방식이 충돌이 가장 적습니다. 메인 파일에는 rules 상단에 회사망·스토어·스트리밍 등 고정 줄을 두고, 아래쪽은 rule-providers로 외부 규칙 세트를 붙인 뒤 MATCH로 마감하는 패턴이 흔합니다. rule-providers·GEOIP 글과 짝을 이루면, "구독 노드는 자주 바뀌지만 규칙 세트는 별도 갱신" 구조를 만들기 쉽습니다.

6. port·DNS·rules 충돌을 줄이는 규칙

여러 소스를 합치면 mixed-port·external-controller·secret 같은 키도 중복될 수 있습니다. 최종 트리에는 값이 하나만 남아야 하므로, 베이스 프로필 한 곳에만 두고 나머지 구독 템플릿에서는 해당 키를 제거하거나, 오버라이드에서 명시적으로 덮어씁니다. dns 블록은 특히 민감합니다. 한 공항은 fake-ip, 다른 공항은 redir-host를 기본으로 쓰면, 합친 뒤 DNS 해석 경로가 기대와 달라 구독 충돌이 아니라 "증상만 이상한" 상태가 됩니다. Windows 구독·TLS·DNS 글에서 로그로 출구를 맞추는 습관을 같이 들이면 진단이 빨라집니다.

rules 배열은 앞줄이 이깁니다. GEOIP,CN,DIRECT를 너무 위에 두면 해외 CDN이 의도치 않게 직행하거나, 반대로 모든 트래픽이 한 노드로 몰릴 수 있습니다. YAML 병합 후에는 반드시 전체 규칙을 스크롤해 "내가 넣은 줄보다 위에 광역 규칙이 없는지" 확인하세요. 자동 생성 클라이언트라면, 생성 로그나 미리보기에서 동일 검증을 합니다.

7. 구독 갱신 후에도 깨지지 않는 습관

공항 패널이 노드 이름을 바꾸면, 로컬 proxy-groups의 참조가 끊길 수 있습니다. proxy-providers를 쓰면 제공자가 갱신될 때마다 노드 집합이 바뀌므로, 그룹 정의는 "특정 이름 나열"보다 use 필드로 제공자 전체를 끌어오는 방식이 유지보수에 유리한 경우가 많습니다(클라이언트·버전에 따라 키 이름은 다를 수 있으니 매뉴얼을 확인하세요). 또한 프로필 백업을 날짜별로 남겨 두면, 갱신 직후 규칙이 날아갔을 때 diff로 원인을 바로 볼 수 있습니다.

GUI에서 "구독만 다시 받기"를 눌렀을 때 로컬 패치가 사라진다면, 그 클라이언트는 패치를 별도 파일로 저장하지 않는 구조일 수 있습니다. 이때는 오버라이드 파일을 수동으로 지정하거나, 아예 외부 에디터에서 메인 YAML을 편집하는 워크플로로 옮기는 편이 안전합니다. 다른 클라이언트로 이전할 때도 같은 논리로, "구독 URL"과 "내 커스텀 블록"을 분리해 옮기면 재발이 줄어듭니다.

8. 점검 체크리스트

첫째, 합친 뒤 대시보드나 API로 /proxies 목록을 열어 중복 이름이 없는지 확인합니다. 둘째, /rules 또는 로그에서 테스트 도메인이 기대한 정책 그룹으로 떨어지는지 봅니다. 셋째, DNS 모드가 한 벌로 고정됐는지, OS·브라우저 DoH가 코어를 우회하지 않는지 점검합니다. 넷째, 구독 갱신 직후에도 오버라이드가 같은 순서로 적용되는지 클라이언트 문서에 따라 검증합니다. 다섯째, 문제가 생기면 최소 구성(한 제공자만 남기기)으로 되돌려 재현 범위를 줄입니다. 이 루틴은 다중 구독 병합뿐 아니라 팀에서 프로필을 공유할 때도 동일합니다.