원격 구독은 그대로, 규칙만 덧붙이기: Clash Meta mixin으로 갱신에도 안 날아가게

왜 “구독 파일에 직접 붙여넣기”가 위험한가

클라이언트가 주기적으로 원격 구독을 받아오면, 디스크에 풀린 구성은 매번 서버가 준 스냅샷으로 바뀝니다. 그 안에 rules: 블록을 손으로 끼워 넣었다면 다음 갱신에서 사라지기 쉽습니다. “한 번만 고치면 되지 않나?”라는 생각은 자동 새로고침이 켜진 순간 깨집니다. 반대로 공항 YAML을 절대 수정하지 않는 원칙을 세우면, 문제는 “어디에 내 규칙을 두어야 코어가 항상 같은 방식으로 합치는가?”로 바뀌고 답이 mixin 프로필과 클라이언트가 제공하는 프로필 디렉터리입니다.

비슷한 맥락으로 Subconverter로 한 번 더 가공하는 방법도 있지만, 이미 Clash 형식 구독을 쓰는 경우에는 Meta 쪽 병합 기능이 반복 작업을 줄입니다. 변환 파이프가 필요하면 《Subconverter로 Clash YAML 만들기》를 함께 보세요.

멘탈 모델: 업스트림 스냅샷 vs 로컬 오버레이

원격 구독은 “노드·기본 규칙·기본 그룹”을 빠르게 채워 주는 업스트림입니다. mixin은 그 위에 얹는 얇은 패치 레이어로 생각하면 됩니다. 코어는 보통 구독에서 받은 베이스를 먼저 읽고, 그다음 로컬 패치를 합칩니다. 중요한 점은 맵 형태(예: dns: 아래 키-값)와 리스트 형태(rules:, proxy-groups:)의 합치기 규칙이 다르다는 것입니다. 리스트는 “앞에 붙일지, 뒤에 붙일지, 통째로 바꿀지”를 전략으로 고를 수 있어야 사고가 줄어듭니다.

profile: YAML 키와 GUI의 “프로필” 폴더

용어가 겹쳐 헷갈립니다. 루트의 profile: 블록은 런타임 동작 옵션(예: 선택한 노드 기억 여부)을 다루는 경우가 많고, Clash Verge Rev 같은 클라이언트의 프로필 디렉터리는 mixin.yaml·로컬 스니펫을 두는 파일 시스템 위치입니다. 이 글에서 말하는 profile은 문맥에 따라 둘 중 하나일 수 있으니, 설정 화면에서 “mixin 파일 경로”가 어디를 가리키는지 먼저 확인하세요.

리스트 병합과 list-strategy

최신 mihomo 계열에서는 배열 병합을 세밀하게 제어하려는 요구가 많아졌고, insert-front(앞에 삽입·규칙 우선권 확보), append(뒤에 추가), override(통째 교체) 같은 list-strategy 개념이 문서와 이슈 트래커에 등장합니다. 예를 들어 공항이 넣은 dns.nameserver 앞에 무조건 한 줄이 붙어 해석이 느려지는 상황이라면, 단순 “병합”이 아니라 교체 전략을 검토해야 합니다. 버전마다 키 이름이 조금씩 다를 수 있으므로, 사용 중인 코어 버전 릴리스 노트를 한 번 확인하는 것을 권합니다.

1단계: mixin 파일 위치 잡기

데스크톱 GUI에서는 설정 → 프로필 디렉터리 열기류의 메뉴로 mixin.yaml(또는 동일 역할 파일)이 어디에 있는지 확인합니다. 서버나 Docker에서는 볼륨으로 마운트한 디렉터리에 두는 편이 안전합니다. 목표는 하나입니다. 구독 캐시가 덮어써지는 경로와 mixin 경로를 분리하는 것.

2단계: 광고 차단·국내 DIRECT를 mixin에 넣기

가장 흔한 패턴은 rule-providers로 원격 규칙 세트를 받고, rules:에서 RULE-SET을 참조하는 것입니다. rule-provider가 URL에서 내려받히지 않으면 《rule-providers path·interval》 글의 순서대로 path와 갱신 주기를 먼저 고칩니다. mixin 쪽에는 “공항이 이미 쓰는 이름과 충돌하지 않는” 프로바이더 이름을 쓰세요.

# mixin.yaml (illustrative) — adjust names to match your subscription
rule-providers:
  reject-ads:
    type: http
    behavior: classical
    url: "https://example.com/rules/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject-ads,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위는 예시입니다. 실제 REJECT·PROXY·DIRECT 타깃은 공항이 이미 정의한 정책 그룹 이름과 맞아야 합니다. 이름이 다르면 코어가 기동 단계에서 오류를 내거나 조용히 매칭에 실패합니다.

3단계: 맞춤 proxy-groups를 “추가 전용”으로 설계

구독이 이미 proxy-groups:를 가져왔다면, mixin에서 같은 그룹 이름을 다시 선언해 버리면 병합 결과가 직관과 다를 수 있습니다. 안전한 패턴은 새 그룹 이름을 만들고, 그 안에서 proxies: 목록에 공항이 준 그룹이나 노드 이름을 참조만 하는 것입니다. 자동 선택·장애 대출구는 《url-test·fallback·lazy》에서 파라미터를 맞추세요.

병합 순서를 몸으로 익히기

문서화된 정확한 단계는 릴리스마다 조금씩 바뀔 수 있으므로, 이 글은 “항상 이렇다” 대신 검증 루틴을 권합니다. 원칙만 정리하면 다음과 같습니다.

• 베이스: 원격 구독에서 온 proxies·기본 rules·기본 그룹.
• 오버레이: mixin에 적은 추가 rule-providers·추가 rules 행·추가 그룹.
• 우선순위: 규칙은 위에서 아래로 매칭되므로, “먼저 적용되게 하고 싶은 행”이 리스트 상에서 더 위에 와야 합니다.

클라이언트가 렌더된 설정이나 REST로 최종 구성을 보여 주면, 머릿속 모델과 실제가 어긋나는지 바로 잡을 수 있습니다.

검증: 구독 새로고침 전후로 같은지 보려면

한 번에 변수를 여러 개 바꾸지 말고, mixin만 켠 상태에서 구독 갱신을 반복해 보는 것이 디버깅 비용을 줄입니다.

자주 밟는 함정

이름 충돌

proxy-groups·rule-providers·script 단위 이름이 구독과 겹치면 병합 결과가 기대와 다릅니다. 접두사를 붙여 내 쪽만의 네임스페이스를 만드세요.

규칙 순서 착각

공항이 넣은 넓은 GEOIP나 MATCH가 먼저 승리하면, mixin에 넣은 세밀한 행은 영원히 실행되지 않습니다. “내 행이 위에 있는가?”를 렌더된 리스트로 확인하세요.

에디터로 구독 캐시를 직접 연 경우

일부 클라이언트는 구독을 캐시 파일로 풀어 두고 에디터로 열 수 있게 합니다. 그 파일을 습관처럼 고치면 다음 갱신에 날아갑니다. 습관을 mixin 파일만 고치도록 바꾸세요.

FAQ

YAML 주석이나 앵커가 mixin에서 깨질 수 있나요?

클라이언트가 병합 과정에서 다시 직렬화하면 주석이 사라질 수 있습니다. “설명은 버전 관리되는 mixin 쪽에만” 두는 편이 정신 건강에 이롭습니다.

모바일에도 같은 방식이 되나요?

클라이언트가 mixin에 해당하는 로컬 패치 슬롯을 제공하는지가 관건입니다. 제공하지 않으면 원격 구독 URL을 Subconverter 등으로 한 단계 가공하는 쪽이 현실적인 대안입니다.

체크리스트

정리

Clash Meta 생태계에서 원격 구독은 빠른 시작을, mixin은 지속 가능한 커스터마이징을 맡깁니다. 두 레이어의 역할을 분리하면 구독 갱신이 더 이상 두려운 이벤트가 아니라 노드 목록만 최신으로 바꾸는 정기 작업으로 돌아옵니다.

Clash를 무료로 내려받아 mixin 기반 워크플로를 바로 시험해 보세요