Clash Meta 오버라이드: 구독 YAML 안 고치고 노드·규칙만 로컬 수정

왜 원격 구독 YAML을 직접 고치면 안 되나요?

대부분의 사용자는 대시보드에서 발급한 구독 링크로 노드 목록을 불러옵니다. 클라이언트가 받아 오는 파일은 공항 측 템플릿이며, 사용자가 로컬에서 몇 줄을 손봐도 다음 자동 갱신 때 덮어쓰기되는 것이 정상입니다. 그래서 특정 도메인만 직결로 보내고 싶다든지, 공항에 없는 커스텀 노드를 하나 끼워 넣고 싶다든지 하는 요구는, 원본을 수정하는 방식으로는 오래 유지되지 않습니다.

해결책은 단순합니다. 원격이 관리하는 부분과 본인 PC에서만 유지할 부분을 나누는 것입니다. 후자가 바로 이 글에서 말하는 오버라이드 또는 로컬 병합에 해당합니다. Clash Meta(Mihomo) 코어는 설정을 한 덩어리로 합성할 때 상당히 유연한 편이라, GUI마다 메뉴 이름은 다르지만 개념은 같습니다. 구독 가져오기 절차 자체는 구독 링크 사용 튜토리얼과 맞물려 있으니, 처음 설정 중이라면 그 글을 먼저 보고 오셔도 좋습니다.

오버라이드가 하는 일: 합쳐진 하나의 실행 설정

실제로 코어가 읽는 것은 최종적으로 병합된 하나의 프로필입니다. 구독에서 내려온 proxies·proxy-groups·rules가 있고, 그 위에 사용자가 만든 작은 YAML이나 클라이언트의 「Merge」「Patch」「Override」에 해당하는 조각이 얹힙니다. 합성 규칙은 버전과 클라이언트에 따라 미묘하게 다를 수 있으므로, 적용 후에는 반드시 미리보기·유효성 검사로 최종 텍스트를 확인하는 습관이 필요합니다.

중요한 직관은 다음과 같습니다. 오버라이드는 「구독 파일을 영구적으로 바꾼다」가 아니라, 실행 시점에만 덧붙이거나 덮어쓴다에 가깝습니다. 그래서 공항이 노드 이름을 바꿔도 로컬에서 참조하는 정책 그룹 이름만 일치하면 나머지 커스텀 블록은 그대로 살아 있습니다. 반대로, 구독 쪽에서 그룹 이름을 갑자기 바꾸면 로컬 규칙이 가리키는 대상이 어긋날 수 있으니, 큰 템플릿 변경이 있을 때마다 한 번씩 점검하는 것이 좋습니다.

💡

한 줄 요약 오버라이드는 구독을 대체하는 것이 아니라, 구독 위에 얹는 로컬 레이어입니다. 갱신이 와도 이 레이어는 클라이언트가 보관합니다.

로컬에만 두는 proxies와 proxy-groups

회사 VPN이나 개인 VPS처럼 구독에 없는 엔드포인트를 쓰려면, 해당 proxies 항목을 로컬 전용 YAML에 정의합니다. 그다음 기존 proxy-groups의 proxies 목록에 새 이름을 한 줄 추가하면, UI의 선택 그룹에도 같은 이름이 나타나는 패턴이 일반적입니다. 이름은 구독 쪽 노드와 절대 겹치지 않게 짓는 것이 디버깅에 유리합니다. 예를 들어 MY-VPS-SEOUL처럼 접두어를 붙이면 로그에서도 식별하기 쉽습니다.

일부 클라이언트는 proxy-providers로 원격 노드 묶음을 따로 불러온 뒤, 그 provider가 내놓는 프록시 이름을 그룹에 넣는 구조를 지원합니다. 이 경우에도 원칙은 같습니다. 이름 공간이 충돌하지 않게 정리하고, 최종 병합 결과에서 한 노드가 두 번 정의되지 않았는지 확인합니다. 병합 오류가 있으면 코어가 기동을 거부하거나, 조용히 한쪽 정의만 택하는 등 클라이언트마다 대응이 달라 문제 추적이 어려워집니다.

# Local-only snippet example — proxy names must stay unique after merge
proxies:
  - name: MY-VPS-SEOUL
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-256-gcm
    password: "REPLACE_ME"

proxy-groups:
  - name: "🚀-Select"
    type: select
    proxies:
      - MY-VPS-SEOUL
      - AUTO

위 예시에서 🚀-Select나 AUTO 같은 이름은 실제 구독에 맞춰 바꿔야 합니다. 핵심은 로컬 조각이 최종 그룹 정의와 같은 이름을 가질 때 병합 규칙에 따라 덮어쓰기·병합이 일어난다는 점을 염두에 두는 것입니다. 잘 모르겠으면 새 그룹을 하나 파서 그쪽으로만 트래픽을 보내는 편이 안전합니다.

규칙을 앞·뒤에 붙이기: 우선순위를 내가 쥔다

분류 규칙은 위에서 아래로 읽히며 첫 매칭에서 끝납니다. 구독 템플릿이 이미 긴 GEOIP나 RULE-SET을 포함하고 있어도, 그 앞에 로컬 규칙을 삽입할 수 있다면 회사 내망·테스트 도메인·특정 SaaS만 내가 원하는 정책 그룹으로 보내는 식의 조정이 가능합니다. 반대로 맨 뒤에 붙이면 MATCH 직전에 예외를 추가하는 효과를 낼 수 있습니다.

이때 쓰이는 것이 흔히 「prepend」「append」「prepend-rules」「append-rules」 같은 클라이언트·코어 옵션 이름입니다. 정확한 키 이름은 사용 중인 앱 버전과 코어 릴리스 노트를 확인해야 하며, 본 글에서는 구조만 기억해 두면 됩니다. 앞에 붙인 줄이 먼저 평가되고, 구독이 가져온 거대한 규칙 블록은 중간, 로컬 후행 규칙은 마지막에 가깝게 붙는 식입니다. 분류 규칙 전반의 설계는 분류 규칙 최적 전략에서 다룬 순서 원칙과 그대로 맞닿아 있습니다.

# Example: high-priority local rules (adjust policy group names)
rules:
  - DOMAIN-SUFFIX,company.internal,DIRECT
  - DOMAIN-SUFFIX,example-dev.net,🔰-Proxy
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

no-resolve 여부, RULE-SET과의 상호작용 등은 DNS 모드와 세트를 함께 봐야 합니다. 규칙만 덧붙였는데도 이상하면, 로그에서 어떤 줄에 걸렸는지 역추적하는 절차는 연결 로그 트러블슈팅 글의 흐름을 참고하세요.

GUI에서의 실무: 프로필·머지·패치 메뉴를 어떻게 읽을까

Windows에서는 Clash Verge Rev처럼 프로필 단위로 구독과 로컬 조각을 나누어 보여 주는 앱이 많습니다. 일반적인 작업 순서는 다음과 같습니다. 첫째, 구독을 정상적으로 가져와 기본 동작을 확인합니다. 둘째, 「Merge」「Script」「Patch」 등 앱이 제공하는 로컬 오버라이드 입력란에 위에서 설명한 proxies·rules 일부만 넣습니다. 셋째, 생성된 최종 설정 미리보기에서 YAML 오류가 없는지 확인한 뒤 적용합니다.

macOS·Android·명령줄 설치도 개념은 동일하고, 차이는 파일 경로와 재시작 동작뿐입니다. 어디에 merge 파일이 저장되는지, 백업 시 그 파일까지 포함되는지는 한 번만이라도 확인해 두면 기기 이전이나 재설치 때 시간을 아낄 수 있습니다.

흔한 실수: 이름 충돌·순서 착각·구버전 문법

첫째, 동일한 프록시 이름이 두 번 정의되면 어떤 것이 살아남는지는 병합 구현에 좌우됩니다. 의도와 다르게 오래된 정의가 남으면 지연·인증 오류가 「간헐적」으로 보입니다. 둘째, 규칙을 앞에 많이 붙이다 보면 원래 구독의 세밀한 예외를 모두 가리는 경우가 있습니다. 셋째, Meta 전용 필드를 구형 예제에서 그대로 가져오면 경고가 뜨거나 무시될 수 있으니, 코어 버전과 문서 페이지의 용어를 맞추는 것이 좋습니다.

네 번째로, 오버라이드로 dns나 tun까지 건드리면 영향 범위가 커집니다. 가능하면 규칙과 프록시부터 시작하고, DNS·TUN은 별도 변경으로 나누어 검증하세요. TUN과의 관계는 TUN 모드 가이드와 함께 읽으면 전체 그림이 잡힙니다.

자주 묻는 질문

구독을 수동으로 갱신해도 오버라이드는 유지되나요?

일반적으로 로컬에 저장된 merge·override 조각은 구독 갱신과 별도 레이어로 유지됩니다. 다만 클라이언트가 「구독 내용을 단일 파일로 덮어쓴다」는 식으로 구현된 경우, 그 파일을 직접 편집한 내용만 사라지고 merge 층은 남는 식으로 동작하는 경우가 많습니다. 혼동을 줄이려면 원격에서 받은 스냅샷은 건드리지 말고, 항상 오버라이드 전용 입력란만 사용하세요.

노드는 그대로 두고 규칙만 바꾸고 싶습니다

가능합니다. rules만 로컬에 추가하고 proxies는 건드리지 않으면 됩니다. 이때 규칙에서 참조하는 정책 그룹 이름이 구독 쪽과 일치하는지만 반복해서 확인하세요.

설정을 Git으로 관리하고 싶습니다

민감 정보가 들어 있는 파일은 저장소에 올리지 마세요. 대신 proxies의 비밀번호 부분을 환경 변수나 별도 로컬 파일로 분리하는 패턴을 검토할 수 있습니다. 구조 자체는 오버라이드가 구독과 분리되어 있으면 Git 친화적으로 가져가기 쉽습니다.

정리하며

Clash Meta 계열에서 오버라이드는 고급 사용자만의 기능이 아니라, 구독을 건강하게 유지하면서도 내 환경에 맞게 손볼 수 있는 기본 패턴에 가깝습니다. 원격 YAML을 직접 수정하지 않는다는 규칙만 지키면, 갱신과 커스터마이징이 서로 충돌하지 않습니다. 규칙 설계·DNS·로그 해석까지 한 번에 다잡고 싶다면 위에서 안내한 관련 글들을 순서대로 읽어 보시길 권합니다.

같은 Mihomo 코어를 쓰더라도 GUI마다 메뉴 이름과 저장 위치가 달라 처음에는 헷갈릴 수 있습니다. 다만 한 번 「구독은 저쪽, 나는 이쪽」으로 레이어를 나누는 경험을 하면 이후 설정 변경이 훨씬 빨라집니다. 다른 도구에 비해 Clash 계열은 규칙과 프로필을 텍스트로 남기기 쉬워, 문제가 생겼을 때 원인을 추적하기에도 유리합니다.

클라이언트 설치와 코어 선택이 아직이라면, 변조 위험을 줄이려면 검증된 배포 경로를 쓰는 것이 좋습니다. 본 사이트 다운로드 페이지에서 플랫폼별 빌드를 한곳에서 받을 수 있습니다. 환경을 맞춰 두었다면 → Clash를 무료로 내려받아 오버라이드까지 포함한 워크플로를 바로 시험해 보세요.