rule-providers로 커지는 Clash 규칙 파일 나누기

Clash 설정에 앱별 도메인, 광고 차단 목록, 회사 내부 주소, 직접 연결 예외를 계속 추가하다 보면 rules:가 길어지고 수정 한 번의 영향 범위도 커집니다. 여기에 여러 기기에서 같은 규칙을 반복해 관리하면 노트북에서는 반영됐지만 데스크톱 프로필에는 빠지는 식의 차이가 생기기 쉽습니다. rule-providers는 규칙 목록을 별도의 파일로 분리해 원격 주소에서 가져오고, 메인 설정에서는 제공자 이름만 참조하도록 해 이런 부담을 줄이는 기능입니다.

Mihomo 기반 클라이언트에서는 보통 제공자 선언부인 rule-providers:와 실제 적용 순서를 정하는 rules:를 각각 관리합니다. 예를 들어 직접 만든 업무용 도메인 묶음은 GitHub 저장소에 두고, 메인 프로필에는 해당 묶음을 어느 정책으로 보낼지만 적을 수 있습니다. 이렇게 나누면 규칙 데이터 수정과 프록시 그룹 설계를 따로 검토할 수 있고, 같은 규칙 파일을 여러 프로필에서 재사용하기도 편합니다.

다만 provider를 설정했다고 규칙이 자동으로 원하는 위치에서 적용되는 것은 아닙니다. 원격 YAML의 형식, 코어가 내려받을 수 있는 URL, 로컬 캐시 경로, 갱신 간격, 규칙의 위에서 아래로 처리되는 순서를 함께 맞춰야 합니다. 클라이언트가 Clash Verge Rev, Mihomo Party 등 무엇이든 실제 동작을 결정하는 것은 활성 프로필과 그 프로필을 읽는 코어이므로, 화면의 저장 완료만으로 성공을 판단하지 마세요.

ℹ 먼저 확인: 사용하는 코어가 Mihomo인지 확인하고, 활성 프로필의 YAML을 백업하세요. rule-provider 필드나 지원 형식은 코어 버전에 따라 차이가 날 수 있으므로, 오래된 Clash 계열 코어에서 예시 설정을 그대로 복사해 쓰기보다 해당 빌드의 문서와 로그를 기준으로 검증하는 편이 안전합니다.

GitHub에 규칙 YAML 만들고 URL 고정하기

먼저 규칙만 담는 파일을 저장소에 만듭니다. 예를 들어 rules/my-services.yaml을 만들고, YAML 형식의 domain provider라면 최상위에 payload 목록을 둡니다. 이 파일에는 도메인 패턴만 넣고, 어떤 프록시 그룹이나 최종 정책으로 보낼지는 메인 설정의 RULE-SET 줄에서 결정하는 방식이 관리하기 쉽습니다. 파일을 저장한 뒤에는 GitHub 웹 화면에서 원문이 정상적으로 보이는지, 들여쓰기와 따옴표가 깨지지 않았는지 확인하세요. 

payload:
  - '+.service.example'
  - 'api.example.net'

GitHub에서 일반적으로 보는 파일 페이지 주소와 Clash가 내려받을 원문 주소는 다릅니다. provider의 url에는 저장소의 원문(raw) URL을 사용해야 하며, 소유자·저장소·브랜치 또는 태그·파일 경로가 모두 실제 위치와 일치해야 합니다. 저장소를 공개로 운영하면 URL을 가진 사람이 규칙 내용을 볼 수 있으므로, 도메인 목록에 내부 시스템 이름이나 민감한 정보를 넣지 마세요. 비공개 저장소는 인증이 필요할 수 있으며, 접근 토큰을 프로필에 평문으로 넣거나 공개 저장소에 커밋하는 방식은 피해야 합니다.

브랜치의 최신 파일을 가리키면 GitHub에서 수정한 내용이 다음 갱신 때 반영되는 장점이 있지만, 다른 사람이 파일을 바꾸면 본인도 의도하지 않은 규칙을 받게 될 수 있습니다. 개인 테스트에는 기본 브랜치 주소가 편리할 수 있고, 여러 기기나 팀에서 재현 가능한 상태가 중요하다면 릴리스 태그나 특정 커밋에 고정하는 방법을 검토하세요. 자동 업데이트의 편리함과 변경 통제 중 무엇이 더 중요한지 먼저 정하면 URL 선택이 분명해집니다.

rule-providers 선언과 RULE-SET 연결

메인 프로필의 rule-providers: 아래에 고유한 이름을 지정하고, provider의 다운로드 방식과 콘텐츠 종류를 코어에 알려 줍니다. HTTP로 원격 파일을 가져오는 구성에서는 보통 URL, 로컬 캐시 파일 경로, 규칙 동작 유형, 갱신 간격을 함께 둡니다. YAML provider라면 format을 지원 코어가 이해하는 YAML 형식으로 지정하고, 파일 안의 목록 구조와 behavior를 서로 맞춰야 합니다. domain은 도메인 중심 목록, classical은 일반 규칙 줄을 담는 목록 등에 사용되므로 두 형식을 섞어 쓰지 않는 것이 좋습니다. 

rule-providers:
  MY-SERVICES:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/OWNER/REPO/main/rules/my-services.yaml"
    path: ./ruleset/my-services.yaml
    interval: 86400

rules:
  - RULE-SET,MY-SERVICES,PROXY
  - MATCH,DIRECT

위 설정에서 OWNER와 REPO는 실제 GitHub 정보로 바꾸고, 경로와 파일명도 저장소 구조에 맞춰야 합니다. provider 이름은 RULE-SET에서 참조하는 문자열과 대소문자까지 일치시킵니다. path는 원격 주소가 아니라 내려받은 파일을 코어가 저장할 로컬 경로입니다. 상대 경로가 어디를 기준으로 해석되는지는 실행 환경과 구성 방식에 영향을 받을 수 있으므로, 사용 중인 코어 로그에 표시되는 저장 위치를 확인하고 쓰기 가능한 디렉터리를 선택하세요.

interval은 보통 초 단위의 갱신 주기를 의미합니다. 하루 간격인 86400초는 예시일 뿐이며, 규칙을 바꾸는 빈도와 원격 저장소의 요청 제한을 고려해 정합니다. 잦은 새로 고침은 규칙 변경을 빠르게 반영하는 대신 불필요한 요청이나 접근 제한을 부를 수 있습니다. 반대로 주기를 지나치게 길게 두면 GitHub 파일을 수정했는데도 클라이언트가 한동안 이전 캐시를 계속 쓸 수 있습니다.

provider를 선언하는 것만으로는 트래픽이 분류되지 않습니다. rules:에 RULE-SET,MY-SERVICES,PROXY처럼 참조 줄을 넣어야 하며, 마지막의 PROXY는 실제 설정에 존재하는 정책 그룹 이름으로 바꿉니다. 한 provider를 여러 규칙 줄에서 반복 참조하거나, 그룹이 아닌 DIRECT, REJECT 같은 정책을 지정할 수도 있습니다. 다만 도메인 목록을 차단하려는 목적이라면 실수로 프록시 그룹에 보내지 않았는지, 반대로 업무 주소를 차단하지 않았는지 먼저 소수의 테스트 항목으로 확인하세요.

규칙 순서와 provider 설계 원칙

Clash 규칙은 일반적으로 위에서 아래로 평가되어 먼저 일치한 항목이 적용됩니다. 따라서 같은 도메인이 더 넓은 규칙에 먼저 걸리면 아래쪽 provider 줄에 도달하지 않습니다. 예를 들어 특정 서비스를 프록시로 보내려는 RULE-SET을 광범위한 직접 연결 규칙이나 국가·지역 기반 규칙 아래에 두면, 예상과 다르게 앞선 규칙이 먼저 선택될 수 있습니다. provider 파일 자체의 줄 순서뿐 아니라 메인 프로필의 rules:에서 어느 위치에 참조하는지도 확인해야 합니다.

안정적인 순서를 잡으려면 먼저 예외처럼 범위가 좁고 우선순위가 높은 규칙을 두고, 그 뒤에 서비스별 provider, 지역 또는 공통 분류 규칙을 배치한 다음, 마지막에 최종 처리 규칙을 둡니다. 정확한 순서는 사용자의 기존 정책과 코어 기능에 따라 달라지므로 모든 프로필에 통용되는 고정 템플릿으로 보아서는 안 됩니다. 특히 GEOIP, GEOSITE, DOMAIN-SUFFIX, RULE-SET이 한 파일에 섞여 있다면 각 줄이 먼저 매치될 때 어떤 결과가 생기는지 한 항목씩 추적하세요.

provider를 너무 잘게 쪼개면 이름과 갱신 상태를 관리하기 어려워지고, 모든 규칙을 하나의 거대한 목록에 몰아넣으면 변경 원인을 찾기 힘들어집니다. 업무, 개발 도구, 광고 차단처럼 목적과 정책이 분명한 단위로 나누는 것이 실용적입니다. 목록을 수정할 때는 변경 이유와 적용일을 Git 커밋 메시지에 남기고, 위험이 큰 차단 규칙은 먼저 작은 테스트 묶음에서 검증하세요. 이렇게 하면 업데이트 뒤 특정 사이트가 열리지 않을 때 전체 provider를 되돌리지 않고 문제를 만든 변경만 찾기 쉽습니다.

자동 갱신이 편하더라도 파일 변경을 검토 없이 운영 환경에 반영하면 안 됩니다. 공개 규칙 저장소의 관리자가 바뀌거나 기본 브랜치가 수정되면 예상하지 못한 동작이 생길 수 있습니다. 여러 기기에서 같은 결과가 필요하다면 검증된 커밋을 기준으로 배포하고, 최신 추적이 우선이라면 갱신 후 연결 로그와 실제 매칭 결과를 확인하는 절차를 함께 두세요. 규칙 provider는 자동화 도구이지, 규칙의 타당성을 대신 판단하는 기능은 아닙니다.

자동 갱신 실패와 적용 여부 점검

먼저 클라이언트가 표시하는 provider 상태와 Mihomo 로그를 확인합니다. HTTP 오류, DNS 실패, TLS 인증서 문제, 시간 초과는 원인이 서로 다릅니다. URL을 브라우저에서 열었을 때 보이는 GitHub HTML 페이지를 provider URL로 잘못 넣었는지, 원문 파일이 404인지, 저장소가 비공개로 바뀌었는지부터 점검하세요. 브라우저가 파일을 열 수 있더라도 Clash 코어가 실행되는 환경의 DNS나 네트워크 경로가 다를 수 있으므로, 코어 로그의 요청 결과를 우선 기준으로 삼는 편이 정확합니다.

규칙을 바꾼 직후에는 클라이언트의 프로필 새로 고침과 provider 새로 고침이 같은 동작인지 확인하세요. 일부 인터페이스에서는 원격 프로필 업데이트와 개별 규칙 제공자 업데이트가 별도 메뉴에 있을 수 있습니다. 업데이트 버튼을 눌렀는데 결과가 없다면 코어를 재시작하기 전에 먼저 오류 로그를 저장하고, 활성 프로필이 편집한 파일과 같은지 확인합니다. 여러 프로필을 사용하는 경우 다른 프로필이 켜져 있어 변경 사항이 보이지 않는 일이 흔합니다.

캐시된 파일을 지우는 것은 마지막 수단으로 남겨 두세요. 우선 provider의 URL과 형식을 검증하고, YAML 문법 검사 후 새로 고침을 시도한 다음, 필요할 때만 로컬 캐시 경로를 확인합니다. 캐시를 삭제하면 네트워크 장애가 해결되지 않는 한 새 파일을 받지 못해 규칙 자체가 비어 보일 수 있습니다. 안정적인 복구를 위해 작업 전 기존 YAML과 캐시 경로를 기록해 두고, 수정은 한 번에 한 항목씩 적용해 어느 변경이 결과를 바꾸었는지 추적할 수 있게 하세요.

직접 메인 YAML에 모든 규칙을 넣는 방식은 외부 의존성이 적지만 파일이 커질수록 여러 기기에서 변경 내용을 맞추기 어렵고, 일반적인 구독 프로필은 업데이트 때 로컬 수정이 덮일 수 있습니다. 반면 Clash V.CORE에서 Mihomo 코어와 프로필을 함께 관리하면 provider를 쓰는 구성의 적용 상태를 확인하고 규칙 변경을 점검하기 수월합니다. GitHub YAML을 재사용하면서 갱신 오류와 규칙 순서를 한곳에서 확인하고 싶다면 다운로드하기를 통해 Clash V.CORE를 살펴보세요.