오버라이드는 구독 갱신 후 사용자 설정을 유지한다

현재 공식 문서는 Clash Party라는 이름을 쓰지만 이전 파일명, 버전, 검색어에는 Mihomo Party가 남아 있습니다. 이 글에서 두 이름은 같은 프로젝트의 이전과 현재 브랜드를 가리키며 두 클라이언트를 함께 설치하라는 뜻이 아닙니다. 현재 공식 저장소와 문서로 실제 버전을 확인하세요.

공식 오버라이드 문서는 구독 설정을 사용자 정의하면서 구독 갱신 후에도 그 변경을 유지하는 기능으로 설명합니다. 변경할 키만 작은 YAML에 작성하고, 로드할 때 구독 원본과 병합합니다. 매번 다운로드된 메인 YAML을 직접 편집하는 것보다 원인과 롤백이 명확합니다.

오버라이드는 구독 변환기가 아닙니다. 프록시 노드를 만들지 않고 만료된 URL을 복구하지도 않습니다. 원본 구독이 다운로드되고 파싱되는지 먼저 증명하세요.

전역 또는 구독별 범위를 선택한 뒤 YAML 연결

Clash Party는 오버라이드를 전역으로 활성화하거나 특정 구독에만 연결할 수 있습니다. 첫 테스트는 구독별 연결이 안전합니다. 테스트 프로필만 바뀌고 다른 검증된 구독은 비교 대상으로 남습니다. 제공자 전용 그룹 이름을 모든 프로필에 잘못 적용하는 위험도 줄어듭니다.

  1. 왼쪽 탐색에서 Overrides를 열고 직접 검토할 수 있는 로컬 YAML을 가져옵니다. URL은 내용을 신뢰할 수 있을 때만 사용합니다.
  2. 가져온 항목을 열고 이번 테스트에 필요한 키만 남긴 뒤 저장하고 이름을 기록합니다.
  3. Subscription Management에서 대상 구독의 세 점 메뉴를 열고 Edit Information을 선택합니다.
  4. Override 필드에서 방금 만든 YAML을 선택하고 저장한 뒤 대상 구독을 다시 로드합니다.
  5. 실제 적용 설정이나 연결 로그에서 변경된 키가 코어에 도달했는지 검증합니다. 편집기의 '저장됨'은 저장만 증명합니다.

URL로 불러온 오버라이드는 나중에 변경될 수 있습니다. DNS, 스크립트, 원격 규칙 제공자, 외부 컨트롤러를 바꾸는 파일은 로컬 사본을 보관하고 줄단위로 검토하세요. 토큰이 있는 구독 원본을 오버라이드라고 생각해 공개하지 마세요.

스칼라, 객체, 배열의 병합 규칙 이해

공식 YAML 문서에 따르면 오버라이드는 깊은 병합을 사용하며 이 계층의 우선순위는 앱의 공통 설정 오버라이드보다 낮습니다. 단순 값은 교체되고 중첩 객체는 재귀적으로 병합됩니다. 키에 !를 붙이면 재귀 병합 대신 전체 객체를 교체합니다. 배열은 기본적으로 교체되며, 키 앞의 +는 앞에 추가, 뒤의 +는 뒤에 추가입니다.

# 기존 규칙 앞에 추가
+rules:
  - DOMAIN,example.internal,DIRECT

# 기존 규칙 뒤에 추가
rules+:
  - DOMAIN-SUFFIX,example.net,Proxy

example.internal, example.net, Proxy는 예시입니다. 정책 이름은 선택한 구독에 실제로 존재하는 프록시 그룹으로 바꾸세요. YAML 문법이 올바라도 존재하지 않는 정책을 참조하면 Mihomo가 실제 설정을 거부할 수 있습니다.

규칙은 순서대로 평가됩니다. 범위가 넓은 규칙을 앞에 추가하면 제공자의 더 구체적인 규칙보다 먼저 일치할 수 있습니다. 종단 MATCH 뒤에 추가된 규칙은 영원히 도달하지 못할 수 있습니다.

구독 갱신 전에 관찰 가능한 변경 하나를 테스트

첫 오버라이드로 DNS, TUN, 프록시 그룹, 여러 십 개의 규칙을 함께 바꾸지 마세요. 직접 관리하는 테스트 도메인에 대한 앞쪽 규칙 하나처럼 관찰할 수 있고 되돌릴 수 있는 필드를 선택합니다. 프로필을 재로드한 뒤 Connections 또는 Logs에서 예상한 정책을 사용하는지 확인합니다.

  1. 변경 전 구독 이름, 오버라이드 연결, 테스트 요청이 실제로 사용한 정책을 기록합니다.
  2. 하나의 변경만 포함한 YAML을 활성화하고 프로필을 재로드한 후 같은 요청을 반복합니다.
  3. 예상한 경로 변경을 확인하면 다운로드된 메인 설정을 편집하지 않고 구독을 수동 갱신합니다.
  4. 갱신 후 같은 요청을 반복하여 오버라이드가 여전히 연결되고 병합에 참여하는지 검증합니다.
  5. 마지막으로 오버라이드를 비활성화하고 재로드해 원래 경로가 돌아오는지 확인합니다.

'편집기 저장', '구독 갱신', '코어의 실제 설정 로드'는 세 개의 다른 검증 지점입니다. 오버라이드의 목적은 갱신 후에도 변경을 유지하는 것이므로 실제 구독을 갱신한 뒤 같은 동작을 관찰할 때까지 테스트는 완료되지 않습니다.

파싱이나 라우팅이 깨지면 먼저 연결 해제

실제 설정이 로드되지 않으면 Subscription Management에서 해당 구독을 편집하고 오버라이드 연결을 제거한 뒤 원본 구독을 재로드하세요. 구독, 오버라이드, 앱 데이터를 한번에 삭제하지 마세요. 연결 해제만으로 병합 결과가 원인인지 알 수 있고 YAML도 검토용으로 남습니다.

YAML 오버라이드 빠른 진단
현상먼저 확인복구
저장 시 문법 오류들여쓰기, 콜론, 배열 표시, 인용부호키 하나의 최소 오버라이드로 복귀
코어가 정책 없음을 보고현재 구독 프록시 그룹과 이름이 완전히 같은지실제 존재하는 정책 사용
기존 규칙이 전체 사라짐rules:가 배열을 교체했는지의도에 따라 +rules: 또는 rules+:
변경이 적용되지 않음연결, 선택된 구독, 더 높은 우선순위의 공통 설정편집기가 아닌 실제 설정 확인

오버라이드를 작고 버전 관리 가능한 패치로 취급하세요. 파일명에 목적을 적고, 가정하는 프록시 그룹 이름을 주석으로 남기고, 한 번에 한 유형의 변경만 추가하세요. 구독 제공자가 그룹을 개명하거나 규칙 구조를 바꾸면 어떤 가정이 만료되었는지 빠르게 파악할 수 있습니다.

공식 자료와 버전 범위

버전 번호, 파일 이름, 화면 문구는 업데이트로 바뀔 수 있습니다. 작업 전에 연결된 공식 문서를 확인하세요.