mixin·Merge·profile가 각각 가리키는 층

Clash Meta / Mihomo를 쓸 때, 「mixin」은 문서·GUI마다 포인터가 다릅니다. (1) 그래픽 클라이언트의 「Merge / Mixin / 스크립트」는 보통 원격 구독이 생성한 config 뒤에, 사용자가 쓴 짧은 YAML을 deep merge하는 추가 레이어를 뜻합니다. (2) 코어 문서의 profile은 store-selected·store-fake-ip 같이, 재시작 후에도 유지될 상태를 말하는 경우가 많습니다. 둘을 한 덩어리로 떠올리면「프로필이 안 바뀐다」·「Merge가 안 먹는다」가 동시에 섞여 디버깅이 길어집니다. 클라이언트가 실제로 코어에 싣는 최종 YAML을 API·로그로 확인하려면 external-controller·Secret·Web UI 흐름이 도움이 되고, 키·필드 정렬·구버전 이행은 Clash Meta 업그레이드·Mihomo와 같이 읽는 편이 안전합니다.

Clash 클라이언트 고르기를 할 때, 「Merge를 몇 겹 쌓을 수 있는가」「끄면 구독만 쓰는가」를 미리 보면, 집/회사용 스니펫을 재사용하기 쉽습니다. 데이터가 길지 않다면, 큰 rules: 전체를 붙이기보다 최소 예외 + prepend/append + 공통 rule-providers가 유지보수에 유리한 경우가 많습니다.

병합 순서: 구독 → 러너·클라이언트 → 로컬

실제 운용에서 최종 러닝 config는 대략 (A) 구독/템플릿이 뿌리고, (B) GUI Merge·패치가 쌓이고, (C) (선택) 호스트/사용자명 기반 조건부 override가 마지막에 끼는 식이 흔합니다. 정확한 키 이름은 쓰는 코어·클라이언트 버전을 따르며, 여기서 기억할 점은 뒤에 온 값이 단순 스칼라면 덮고, 맵·리스트는 병합 규칙(리스트는 앞/뒤/교체)이 별도라는 것입니다. 구독 URL이 갱신될 때마다 (A)가 바뀌므로, (B)에서 바꾼 줄이 같은 키로 다시 충돌하는지, 중복 dns: 두 블록이 생기지 않는지 눈으로 diff하는 습관이 필요합니다. 갱신 자체는 구독·노드 유지 절차와 겹칩니다.

TUN·DNS를 만지다 보면, Merge 한 장에 tun·dns·rules를 전부 넣고 싶어집니다. 팀이 크지 않다면 기능 단위로 쪼개 두었다가, 사무실엔 office-dns.yaml만, 집에선 home-rules.yaml만 켜는 식이 롤백이 쉽습니다(파일 존재·경로는 클라이언트 문서·로그에 맞출 것).

prepend-rules·append-rules와 MATCH 위치

집/회사로 나눌 때 가장 쓰기 쉬운 건, 구독이 만든 rules: 앞에, 지사 사내만 DIRECT·특정 IP 대역·사내 SNI를 박는 작은 prepend-rules 조각입니다. 이미 본문 끝이 MATCH,...로 막혀 있으면, 그 아래에만 줄을 추가하는 Merge는 절대 실행되지 않게 됩니다(자주 겪는 함정). 그래서 Merge에서는 prepend로 위에 넣는 편이 안전하다는 말이 나옵니다. 출구 선택/폴백과 이름이 겹쳐 헷갈리면 정책 그룹 url-test·fallback 글의 프록시 층과 구분하세요(여기는 라우트 규칙 줄 순서 이야기).

Illustration — prepend before MATCH 
# Merge snippet: office exceptions first (illustration only; replace CIDRs)
prepend-rules:
  - IP-CIDR,10.0.0.0/8,DIRECT
  - DOMAIN-SUFFIX,corp-intranet.example,DIRECT
# then subscription rules continue, ending with MATCH

dns·tun 블록: 덮어쓰기 vs 중복 키

YAML에서 최상위 dns:가 두 번이면, 파서/클라이언트에 따라 나중 키만 살고 앞이 조용히 사라질 수 있어, 「Merge에 썼는데 사라졌다」로 보입니다. 한 블록으로 합쳤는지, Merge가 부분 키만 바꾸는지(예: nameserver만) 먼저 맞춰야 Meta DNS 튜닝이 의도대로 갑니다. fake-ip·LAN 케이스는 Fake-IP·LAN과 같이 봅니다. tun·dns-hijack이 겹칠 때는 TUN의 hijack·스택을 Merge 한 장에 몰지 말고, TUN on/off가 다른 환경(회사 VPN 동시)이면 충돌부터 줄여야 합니다. 종료 후 인터넷이 안 되는 잔상은 프록시/TUN 잔여 절차와 겹칩니다.

ℹ 팁: Merge는 「전체 dns 복붙」보다, 이미 쓰는 dns 구조에 추가 키만 넣는 편이 중복·덮기 실수를 줄입니다. (코어/클라이언트가 허용하는 키만.)

코어 profile과 GUI Merge의 관계

profile: { store-selected: true, store-fake-ip: true } 류는 전략 그룹에서 고른 값·Fake-IP 캐시를 다음 기동까지 남기고 싶을 때 쓰는 저장 옵션입니다. 반면 Merge는 코어에 싣는 텍스트를 바꿉니다. 둘을 같이 켜 둬도 역할이 다르므로, 「Merge를 고쳤는데 선택이 이전과 같다」는 정상일 수도 있고, 반대로 UI가 profile 쓰기를 막아 Merge만 반영되는 보호 필드가 있을 수도 있습니다(클라이언트별). 혼란을 줄이려면 한 번에 변하는 변수(예: 사무실 DNS)만 담은 Merge 파일을 쓰고, 나머지는 규칙·구독 쪽에서 관리하세요.

다중 Merge 파일·심볼릭·프로필 전환

집/회사를 한 PC에서 바꾸는 현실적인 방법은 (1) 클라이언트 프로필을 두 벌 두고 화면만 토글, (2) 심볼릭 링크로 home-merge.yaml ↔ work-merge.yaml을 바꿔 config 디렉터리가 같은 파일명을 가리키게, (3) 런치 스크립트에서 환경 변수로 Merge 경로를 넘기는 방식(지원될 때) 중 하나입니다. 어느 쪽이든 재로드(핫 리로드)를 했는지, 아니면 재시작이 필요한지는 클라이언트/코어 버전에 따라 갈립니다. “저장”만 누르고 코어가 읽지 않은 상태를 배제하려면, 런닝 config 덤프 또는 로그 반영 여부로 확인하세요.

체인이 여러 Merge를 순서대로 쌓는 UI라면, 앞 Merge가 만든 rules가 뒤 Merge에 영향을 주고, 반대로 뒤에서 앞 키를 의도와 다르게 덮지 않는지도 확인해야 합니다. 문서에 권장 순서(예: “기본 → 로컬 → 기업 override”)가 있으면 그대로 따르는 것이 가장 싸움이 적습니다.

(고급) override 조건: OS·호스트·리스트 전략

Mihomo 쪽 커뮤니티·최신 문서에서는, 단일 파일 안에 override: 항목을 두고, os / arch / hostname / username 조건에 맞을 때만 콘텐츠를 병합하는 형태(조건별 list-strategy: 앞/뒤/교체)를 다루는 사례가 늘고 있습니다. 필드 정확명·필수 키는 사용 중인 코어 Minor 버전 문서를 봐야 하며, 본문은 “한 YAML로 노트북/데스크톱 겸용”을 노릴 수 있다는 수준만 밝힙니다. 도입 시에는 최소 조건 1개·최소 diff로 시작해, 하나씩 켜 보며 기대와 다른 병합이 없는지 보는 것이 안전합니다.

Conceptual (verify against your mihomo version docs) 
# override:
#   - os: windows
#     list-strategy: append
#     content:
#       tun: { enable: true }

(위는 개념 예이며, 실제 키/들여쓰기/지원 OS 값은 공식 문서를 반드시 따르세요. 주석은 영어로.)

「썼는데 안 먹는」 세 가지 전형

  1. MATCH 위가 아닌가: 위에서 말한 대로, 규칙은 위에서 먼저 당첨됩니다. Merge에 추가한 줄이 끝에 갔다면, 이미 MATCH로 끝난 트래픽과 무관한 경우가 많습니다. 규칙과 함께 순서를 다시 읽으세요.
  2. 구독·캐시가 다시 씹음: 구독 갱신 직후 전체 rules가 밀리면서, Merge 파일 경로가 틀어졌거나, 클라이언트가 캐시한 “이전 합쳐진 결과”를 쓰는 경우. 캐시 날짜와 최신 덤프로 확인. 구독 갱신 404/403도 함께 봅니다.
  3. 리로드 없음·보호 필드·다른 러너: Merge 저장 후 코어 리로드가 실제로 돌지 않았거나, GUI가 external-controller·포트 등을 잠궜거나, 백그라운드에 옛 프로세스가 남아 다른 config을 읽는 경우. Web UI/Secret로 현재 설정을 읽고, FAQ의 연결 항목과 엇갈리지 않는지 봅니다.

“안 먹는다”는 말이 DNS·TLS와 겹쳐 보이면, 연결 로그에 찍힌 단계를 먼저 나누고(해석/핸드셰이크/첫 바이트), 연결 로그와 교차하세요. 원인이 Merge가 아닐 수 있습니다.

준수 알림

⚠ 법·정책: 회사/학교/공용 Wi-Fi·국가·서비스 약관이 금지하는 무단 우회·감시 회피를 돕는 내용이 아닙니다. 허용된 망·고용·보안 절차 안에서, 필수 split DNS·DMZ·VPN 공존이 있다면, IT 안내·보안팀 승인을 받고 적용하세요.

맺음말

Clash Meta·Mihomo에서 한 대로 기본은 유지하고, 집/회사·다른 Windows 사용자·최소 Direct 예외만 Merge(mixin) 체인으로 얹는 흐름을 이해하면, “구독이 바뀔 때마다 손이 많이 간다”는 압이 줄어듭니다. 최종으로 코어에 들어가는 한 장이 무엇인지—누가 마지막에 dns·rules를 덮는지—를 기준으로 diff 하면, “안 먹는” 일이 급감합니다. TUN·DNS·규칙은 TUN·DNS·규칙 길잡이를 붙이고, Merge는 얇고 반복 가능한 조각으로 유지하세요.

→ Clash를 무료로 다운로드한 뒤, 구독 + Merge로 만든 런닝 설정을 한곳에서 확인해 보시길 권합니다.