1 왜 원본 구독 파일을 직접 고치면 안 되나
클라이언트가 URL 가져오기로 받아 오는 내용은 대부분 서버가 생성한 스냅샷입니다. 사용자가 그 파일에 rules:를 몇 줄 붙이거나 proxy-groups의 기본 선택을 바꿔도, 다음 자동 갱신이나 수동 «새로고침» 한 번이면 원격 버전으로 덮어쓰기되는 구조인 경우가 많습니다. 그래서 «한 번 고쳤는데 며칠 뒤에 또 사라졌다»는 불만이 반복됩니다.
해결책은 간단히 말해 원본과 사용자 수정을 물리적으로 분리하는 것입니다. 한 층은 공급자가 주는 구독(노드 목록·기본 규칙), 다른 층은 내가 유지하는 오버라이드 YAML 또는 코어가 지원하는 mixin 병합입니다. 이렇게 나누면 구독 업데이트는 노드 정보만 최신으로 바꾸고, 사내 도메인을 DIRECT로 보낸다든지 스트리밍만 특정 그룹으로 보낸다든지 하는 규칙 추가는 그대로 남습니다.
원시 링크를 Clash 형식으로 바꾸는 단계가 아직이라면 구독 변환 가이드에서 먼저 흐름을 잡은 뒤, 이 글의 «덧씌우기»를 적용하는 순서를 권장합니다.
2 mixin·오버라이드가 하는 일
Mihomo(Clash Meta) 계열에서는 실행 시점에 여러 소스를 깊은 병합해 하나의 유효 설정으로 만듭니다. 문서·커뮤니티에서 말하는 mixin은 보통 «메인 프로필 위에 덧붙이는 보조 YAML」을 가리키며, GUI에서는 Override·Mixin·Merge 같은 이름으로 같은 자리에 붙습니다.
오버라이드에 자주 넣는 내용은 다음과 같습니다. rules: 앞쪽에 끼워 넣을 사용자 규칙, proxy-groups에서 기본 선택(use·proxies 순서), dns:의 일부 키, 필요 시 tun: 등입니다. 정확히 어떤 키가 병합되는지는 클라이언트 버전과 «구독 한 장짜리인지·로컬 파일 여러 개인지»에 따라 조금씩 다르므로, 바꾼 뒤에는 항상 로그와 연결 테스트로 확인하는 습관이 필요합니다.
3 Clash Verge Rev에서 쓰는 법
Clash Verge Rev는 구독으로 받은 프로필과 별도로, 사용자가 작성한 YAML 조각을 오버라이드 슬롯에 넣어 최종 설정을 만드는 방식을 지원합니다. 앱 버전에 따라 정확한 메뉴 경로는 «프로필 / 설정 / 구독» 근처의 Override·Mixin 항목으로 표시되며, 공통 문서인 사용 설명서(규칙·오버라이드 안내)에도 같은 예시가 실려 있습니다.
실무에서는 (1) 원격 구독 URL만으로 노드를 채우고, (2) 오버라이드 창에는 꼭 유지하고 싶은 규칙과 그룹 조정만 적는 패턴이 가장 관리가 쉽습니다. 처음부터 긴 rules:를 오버라이드에 모두 넣기보다, 스트리밍·사내망처럼 자주 바꾸는 부분만 두고 나머지는 Rule Provider로 나누는 편이 디버깅에 유리합니다. Rule Provider 패턴은 ACL4SSR·Rule Provider 글과 함께 보면 흐름이 이어집니다.
Windows·macOS 설치가 처음이라면 Windows 설치 또는 macOS 설치 튜토리얼에서 프로필 목록과 구독 추가부터 맞춘 뒤 이 단계로 넘어오면 혼선이 적습니다.
4 규칙·정책 그룹 YAML 예시
오버라이드에 넣는 내용은 완전한 프로필 전체가 아니어도 되는 경우가 많고, 아래처럼 필요한 키만 작성합니다. 예시는 설명용이며, 실제 Proxy·DIRECT 뒤에 올 그룹 이름은 자신의 프로필에 맞게 바꿔야 합니다.
# User override: prepend-style rules + tweak default group
rules:
- DOMAIN-SUFFIX,corp.example,DIRECT
- DOMAIN-SUFFIX,internal.corp,DIRECT
- DOMAIN-KEYWORD,steam,Proxy
proxy-groups:
- name: Proxy
type: select
proxies:
- AUTO
- node-hk
- node-jp
# use: ... # if your profile uses provider-based groups, align names with subscription output
- name: AUTO
type: url-test
proxies:
- node-hk
- node-jp
url: "https://www.gstatic.com/generate_204"
interval: 300
위에서 node-hk 같은 문자열은 구독에서 내려온 프록시 이름과 한 글자도 틀리지 않게 맞춰야 합니다. 이름이 바뀌면 그룹이 비거나 선택이 깨집니다. url-test·fallback 그룹을 오버라이드에서 정의할 때도 같은 원칙이 적용되며, 상세 패턴은 URL-Test·Fallback 가이드를 참고하면 됩니다.
proxy-groups가 기존 구독의 그룹과 완전히 같은 구조를 덮어쓰면 의도와 다르게 동작할 수 있습니다. 처음에는 rules만 추가하고, 그룹 수정은 로그를 보며 한 단계씩 올리는 편이 안전합니다.
5 노드 표시명과 proxy-providers
원격 구독이 길고 난해한 노드 표시명을 붙여 줄 때, 가장 깔끔한 방법은 «구독을 proxy-providers로 읽고, 코어가 제공하는 override 옵션으로 접두사·치환 규칙을 건다»는 패턴입니다. 이렇게 하면 원본 URL은 그대로 두고도 목록에 보이는 이름만 정리할 수 있습니다. 반대로 단순히 선택 그룹 안에서만 보기 좋은 이름을 쓰고 싶다면, select 그룹의 proxies 목록이 실제 노드 name과 일치하기만 하면 되므로, 원격 이름을 바꾸지 않고도 운영할 수 있습니다.
어떤 배포본은 오버라이드에 proxy-providers: 블록 전체를 넣는 대신 GUI의 «구독 편집»에서 이름·갱신 주기만 조정하도록 안내하기도 합니다. 중요한 것은 갱신 시 덮어쓰이는 파일이 무엇인지를 앱이 어떻게 나누는지 이해하는 것입니다. 사용자 전용 레이어(오버라이드·로컬 mixin 파일)에만 손대면, 다음 구독 업데이트에 날아가지 않습니다.
6 규칙 순서: 앞에 넣을지 뒤에 넣을지
Clash 규칙은 위에서 아래로 첫 매칭에서 끝납니다. 그래서 «사내망은 무조건 직접» 같은 예외는 목록 앞쪽에 두는 것이 맞고, 길게 이어지는 지역·스토어 규칙은 보통 원격 구독이 이미 포함하고 있을 수 있습니다. 오버라이드가 구독 규칙보다 우선이 되게 할지, 뒤에 붙일지는 클라이언트의 병합 규칙에 따르므로, 한 번 테스트 규칙(예: 특정 도메인만 REJECT)을 넣어 순서를 확인해 보는 것이 좋습니다.
DNS를 건드리는 경우에는 rules만이 아니라 DNS·Fake-IP 설정과의 관계도 함께 봐야 합니다. 규칙에서 도메인이 잡혀도 이름 해석 단계가 어긋나면 기대한 출구로 안 나갈 수 있습니다.
7 자주 나는 실수
- 들여쓰기 혼합: YAML은 스페이스와 탭을 섞으면 조용히 깨집니다. 오버라이드 편집기에서 탭을 쓰지 말고, 블록 단위로 복사합니다.
- 같은 키 두 번:
proxies:를 오버라이드와 구독 양쪽에 중복 정의하면 해석 순서에 따라 한쪽이 무시되거나 충돌합니다. 보통은 규칙·그룹만 오버라이드에 두고 노드는 구독에 맡깁니다. - 이름 변경 후 규칙 미수정: 원격에서 노드 이름이 바뀌면
DOMAIN-SUFFIX규칙은 그대로여도 그룹 안의 참조가 깨집니다. 구독 갱신 직후 한 번 선택 그룹을 열어 이름이 맞는지 확인하세요. - 과도한 규칙 복붙: 수만 줄 규칙을 오버라이드에 직접 붙이면 편집·디버깅이 어렵습니다. Rule Provider로 분리하는 편이 낫습니다.
8 정리
공항 구독을 주기적으로 받는 환경에서는, 원격 파일을 직접 수정하는 대신 mixin·오버라이드 층에 규칙 추가와 그룹 조정을 두는 것이 정신 건강에 이롭습니다. Clash Verge Rev처럼 GUI에서 그 슬롯을 명시해 주는 앱을 쓰면 YAML 실력이 조금 부족해도 «구독은 자동·내 규칙은 고정」이라는 운영 모델을 유지하기 쉽습니다. 노드 품질·지연은 url-test 같은 그룹으로 다루고, 사내망·스토어처럼 정책이 다른 영역은 규칙 순서로 분리하면 장애 때 원인도 빨리 좁혀집니다.
브라우저 확장만 쓰던 때와 비교하면, Clash 계열은 한 번 이 레이어를 잡아 두면 데스크톱 전체 트래픽에 같은 논리를 적용할 수 있다는 장점이 있습니다. 설치 파일은 저장소 직링크보다 사이트 다운로드 페이지에서 플랫폼별로 고르는 방식을 권장합니다.
