왜 “베이스는 건드리지 않는가”
원격 구독은 주기적으로 덮어써집니다. 그 안의 rules·proxy-groups·proxy-providers에 직접 펜을 대면, 다음 갱신에서 충돌·누락이 나기 쉽습니다. 그래서 “읽기 전용인 상류 템플릿”과 “나만의 덧댄 규칙”을 레이어로 나누는 것이 유지보수에 유리합니다. Subconverter로 형식을 맞추는 일(Subconverter 가이드)도 같은 맥락에서, “한 번에 한 파일”이 아니라 파이프라인으로 보는 쪽이 장기적으로 덜 흔들립니다.
문서·설정 허브의 다중 설정 병합 챕터는 GUI 관점의 Merge·Override를 짚고, 이 글은 코어가 최종에 어떤 그림을 쓰는지와 profile 키를 함께 읽는 데 맞춰져 있습니다.
profile과 mixin·병합의 차이
둘 다 설정 파일에 자주 나오는 단어라 한 덩어리로 느껴질 수 있지만, 역할이 다릅니다. profile(및 store-selected·store-fake-ip 등 상태 기억 옵션)은 대개 선택한 노드·UI에서 고른 항목을 디스크에 남기는 런타임/세션 쪽에 가깝습니다. 반면 mixin·클라이언트 Merge는 정적 YAML 조각을 베이스 구성과 합쳐 최종 로딩될 config를 만듭니다. 한 줄로 말해, profile은 무엇을 기억할지, mixin/Merge는 규칙·프로바이더·노드 정의를 어떻게 겹쳐 쌓을지에 가깝습니다.
Mihomo 단독 실행에서의 전형적 패턴
서버·systemd·Docker처럼 한 개의 config.yaml을 엔트리로 쓰는 구성이면, 흐름은 보통 (1) 기본/구독에서 받은 본문이 있고, (2) 그 위에 로컬 스니펫을 얹는 방식으로 정리됩니다. 코어/빌드·클라이언트에 따라 mixin 파일 경로·!include·프로필 폴더 표기는 조금씩 달라지므로, 사용 중인 Mihomo 릴리스의 공식 문서에서 mixin·include 키를 먼저 확인하는 것이 안전합니다.
추가하고 싶은 것이 proxy-providers라면, 이름이 겹치지 않게 새 provider 블록을 정의한 뒤, proxy-groups에서 그 필터·사용을 끼워 넣는 식이 일반적입니다. rules를 맨 끝에만 덧붙이면 MATCH 이전에 가로막힌 줄 때문에 “새 룰이 안 먹는” 상황이 생길 수 있으니, 규칙 우선순위를 반드시 같이 봅니다. RULE-SET·rule-providers는 유지보수에 유리해, 인라인 rules를 무한히 늘리기보다 Provider로 묶는 편이 뒤탈이 적습니다. ACL4SSR 비교도 룰셋 선택에 참고가 됩니다.
# Example sketch — real keys follow your Mihomo build docs
# Base: from subscription / template (do not edit in place)
# Mixin: your overlay file
proxy-providers:
my-extra-nodes:
type: http
url: "https://example.com/extra.yaml"
path: ./providers/extra.yaml
interval: 3600
health-check:
enable: true
url: "https://www.gstatic.com/generate_204"
interval: 300
# rules: append with care — order matters; place before MATCH
rules:
- DOMAIN,internal.corp.example,DIRECT
- MATCH,PROXY여러 구독·룰을 “한 런타임”에 넣는 발상
다중 proxy-providers는 각 url·path 쌍을 서로 다른 이름으로 정의한 뒤, 하나의 proxy-group에 use·필터로 묶는 방식이 흔합니다. 베이스에 이미 provider1이 있다면, mixin에는 provider2만 정의해도 “같은 프로필 안에 두 축”이 생깁니다. 이때 그룹 이름·노드 이름이 구독에서 대량·중복될 수 있으므로, 프리픽스·필터·GUI의 이름 가공이 필요한지 로그/패널로 확인하세요. external-controller·Yacd는 이런 병합 결과를 눈으로 검산하기 좋습니다.
규칙 쪽은 병합 후 최종 rules 배열의 앞뒤가 핵심입니다. Clash는 위에서 아래로 첫 일치이므로, mixin에 높은 우선을 주고 싶은 DOMAIN·PROCESS-NAME 류는 베이스의 넓은 룰보다 앞에 있어야 합니다. “merge가 뒤에 붙는다”는 전제는 런타임/클라이언트마다 다를 수 있으니, 실제로 로드된 config(내보내기·대시보드)에서 최종 순서를 한 번은 확인하라고 말해도 될 만큼 중요합니다.
Clash Verge Rev·Merge(병합)과의 대응
데스크톱 Clash Verge Rev는 “원본 구독 + Merge/Override” 흐름이 직관적으로 드러납니다. Merge 유형 스니펫은 심층 병합에 가깝고, Override 스크립트는 객체를 프로그램으로 고치는 층입니다. 한국어 문서의 다중 병합 챕터에 예시 YAML이 있으니, GUI에 넣는 텍스트가 결국 어떤 키를 덧쓰는지를 그림으로 맞춰 두면, 나중에 순수 Mihomo로 옮겨도 개념이 갈리지 않습니다. 요지는 구독 파일을 직접 편집하지 말고, 내 레이어에만 rules·dns·proxy-providers를 쌓는다는 점입니다.
흔한 함정: 충돌·DNS·proxies 이름
같은 키를 베이스와 mixin 둘 다에서 서로 다르게 쓰면, 나중/우선 규칙이 이기거나, 로드 실패로 떨어질 수 있습니다. dns: 전체를 mixin에서 덮어쓰는 것은 가정한 것보다 훨씬 강한 변경이니, Meta DNS와 함께 한 겹씩 적용하세요. proxy-groups에 proxies 목록을 늘릴 때, 문자열이 가리키는 노드 태그가 실제 merge 결과에 존재하는지(오타·중복)도 체크합니다. HEALTH/URL-TEST·fallback이 엮인 경우는 url-test 글과 맞춰 읽는 편이 안전합니다.
주의: 원격 URL로 받는 베이스에 민감 정보가 섞이지 않는지, 로컬 mixin이 백업·리포에 올라가지 않는지(회사·팀)도 같이 관리하세요. 오픈소스·GitHub는 이슈·라이선스 확인용이고, 클라이언트 설치는 다운로드 페이지를 우선합니다.
검산 순서
- 베이스(구독)와 mixin을 분리했는지, 갱신 스크립트가 어느 파일을 덮는지 먼저 고릅니다.
- 로드된 최종
rules순서에서 의도한 줄이MATCH앞에 오는지 확인합니다. proxy-providers이름·path·health-check가 중복·충돌 없는지, 그룹이 필터된 노드를 실제로 참조하는지 봅니다.- 패널(Yacd 등)이나 로그로 한 도메인이 어떤 정책을 탔는지 점검해 로그·규칙 튜토리얼과 연결합니다.
- 변경은 한 층씩: DNS → 규칙 → 노드 중 어디를 건드렸는지 기록해 두면 롤백이 빨라집니다.
맺음말
Mihomo·Clash Meta 환경에서 구독은 “갱신될 수 있는 상류”, mixin·Merge는 “손댈 가치가 있는 하류”로 읽는 편이 구조가 선명해집니다. profile이 노드 선택 같은 상태를 맡는 동안, rule·provider의 형태는 로컬 스니펫에 모아 두면, 규칙 문법 글(Sniffer·GEOIP·relay)과 맞물려도 설정 관리 한 축이 완성됩니다. 다른 툴에만 익숙해도, “최종 한 장의 config로 합쳐진 뒤 코어가 읽는다”는 사실만 공유해도 팀 합이 좋아집니다. 설치·프로필 흐름을 한곳에 맞추고 싶다면 사이트 다운로드 허브·문서 허브와 병행해 보시길 권합니다.
→ Clash 클라이언트를 무료로 내려받아, 구독은 상류에 두고 mixin·Merge로 룰과 프로바이더만 가볍게 겹쳐 보세요