Rule Provider가 해결하는 문제
Clash 계열 클라이언트(Mihomo·Clash Meta 포함)의 강점은 도메인·IP·지역·프로세스 등을 조합해 트래픽을 나누는 규칙 엔진에 있습니다. 그런데 인기 서비스 목록·광고 도메인·CDN 변화는 매일 조금씩 바뀌므로, 모든 항목을 한 파일에 정적으로 쌓아 두면 금세 수천 줄이 되고 갱신도 힘들어집니다.
Rule Provider(설정상 rule-providers)는 원격이나 로컬의 규칙 묶음을 이름 붙여 로드한 뒤, 본문 rules에서는 RULE-SET 한 줄로 참조하게 해 줍니다. 즉 「규칙 내용의 출처」와 「정책이 어느 프록시 그룹으로 가는지」를 분리해, 서드파티가 잘 관리하는 목록은 그쪽에 맡기고 나는 상위 정책만 다루는 구조가 됩니다.
네트워크 정책과 법규는 국가·기관마다 다릅니다. 본문은 기술적 동작 설명에 한정하며, 허용된 용도와 본인 책임 범위 안에서만 적용하시기 바랍니다. 기본 흐름은 Clash 사용 문서와 함께 보시면 이해가 빠릅니다.
핵심 개념: provider vs RULE-SET
rule-providers 블록은 「이름 → 리소스 위치·형식·갱신 주기」를 정의합니다. 실제 매칭은 rules: 아래에서 RULE-SET,<이름>,<정책> 형태로 이루어집니다. 정책 자리에는 DIRECT, REJECT, 또는 사용자가 만든 proxy-groups 이름이 올 수 있습니다.
behavior(또는 코어 버전에 따라 규칙 세트 타입)은 원격 파일이 어떤 문법으로 파싱될지를 결정합니다. classical은 일반 Clash 규칙 한 줄씩, domain은 도메인 위주의 간소 목록에 적합한 경우가 많습니다. 잘못 고르면 로드는 되어도 의도와 다르게 매칭되거나 무시되는 줄이 생기므로, 가져오는 리포지토리 문서를 꼭 확인해야 합니다.
interval은 백그라운드 갱신 주기입니다. 너무 짧으면 배터리·데이터·서버 부담만 늘고, 너무 길면 목록이 오래됩니다. 일반 가정용이라면 수 시간~하루부터 시작해 체감에 맞추는 편이 안전합니다. 갱신과 지연의 관계는 속도 최적화 가이드에서도 다룹니다.
YAML 예시: 정의와 rules 연결
아래는 이해를 돕기 위한 축약 예시입니다. 키 이름·들여쓰기는 실제 프로필과 동일한 패턴을 따르되, URL·경로·그룹 이름은 본인 환경에 맞게 바꿔야 합니다.
# rule-providers: register external rule sets (comments in English per project convention)
rule-providers:
my-domains:
type: http
behavior: domain
url: "https://example.com/rules/domains.txt"
path: ./ruleset/my-domains.yaml
interval: 86400
my-classical:
type: http
behavior: classical
url: "https://example.com/rules/classical.yaml"
path: ./ruleset/my-classical.yaml
interval: 43200
rules:
- RULE-SET,my-domains,DIRECT
- RULE-SET,my-classical,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY위에서 path는 로컬 캐시 위치로 쓰이는 경우가 많습니다. 최초 실행 시 원격에서 받아 저장하고, 이후에는 interval마다 다시 받습니다. 오프라인 테스트용으로는 type: file로 로컬 파일만 가리키는 구성도 가능합니다.
규칙 순서가 곧 정책이다
Clash는 rules를 위에서 아래로 훑다가 처음 맞는 한 줄에서 결정합니다. 따라서 RULE-SET을 어디에 두느냐가 결과를 바꿉니다. 흔한 패턴은 (1) 광고·추적 차단용 세트를 상단에 두어 빨리 끊거나 직접 연결로 보내고, (2) 국내 전용 도메인 세트를 DIRECT로 보내고, (3) 나머지 해외·글로벌 서비스는 프록시 그룹으로 넘기는 순서입니다.
서로 다른 RULE-SET 두 개가 같은 도메인을 다루면 위쪽이 승리합니다. 그래서 「작은 예외 목록」은 「큰 글로벌 목록」보다 위에 두는 식으로 조정합니다. 디버깅할 때는 로그에서 어떤 규칙이 매칭됐는지 확인하며 순서를 옮기면 됩니다.
서드파티 규칙을 고를 때의 신뢰와 보안
Rule Provider는 본질적으로 외부에서 코드에 가까운 정책을 가져오는 기능입니다. 악의적이거나 실수로 위험한 목록이면, 민감한 트래픽을 예상치 못한 경로로 보내거나 서비스가 막힐 수 있습니다. 따라서 다음을 권장합니다.
- 출처 확인: 공개 Git 저장소·체크섬·릴리스 노트가 있는지 본다.
- 고정 버전 URL: 가능하면 자주 바뀌는
raw/main대신 태그나 특정 커밋을 가리킨다. - 중간 변경 감지: 갱신 후 이상 증상이 있으면 직전 캐시와 비교하거나 갱신을 잠시 끈다.
- 개인 정보: 규칙 URL에 토큰을 넣는 형태는 유출 위험이 있으므로 피한다.
오픈 소스 코어와 빌드 출처는 투명성 측면에서 Mihomo GitHub 저장소에서 확인할 수 있습니다. 다만 클라이언트 설치 패키지는 배포 신뢰도를 위해 공식 다운로드 페이지를 우선하는 편이 좋습니다.
GEOIP·프로세스 규칙과의 조합
RULE-SET은 도메인·IP 규칙 묶음에 특히 잘 어울립니다. 그 다음 단계로 GEOIP를 두면 「목록에 없는 잔여 트래픽」을 국가 단위로 나눌 수 있습니다. 다만 GEOIP 데이터베이스 자체도 버전에 따라 경계가 달라질 수 있어, 금융·의료처럼 엄격한 직접 연결이 필요한 앱은 별도 예외 규칙으로 확실히 직접 연결을 박아 두는 편이 안전합니다.
일부 GUI는 프로세스 이름·패키지 기반 규칙을 지원합니다. 이런 항목은 RULE-SET 파일에 없고 프로필 본문에만 있을 수 있으므로, 「전부 provider로 빼야 한다」는 강박은 필요 없습니다. 자주 바뀌는 대량 목록만 provider로 두고, 소수의 개인 예외는 로컬에 두는 혼합이 가장 운영하기 좋습니다.
운영 팁: 실패·용량·버전 차이
원격 URL이 일시적으로 막히거나 인증서 오류가 나면 해당 RULE-SET은 갱신에 실패하고, 캐시가 있으면 이전 버전을 쓰거나 빈 세트로 동작할 수 있습니다. 증상이 「어제까지 되던 사이트가 갑자기 전부 프록시를 탄다」처럼 보일 때는 provider 한 곳씩 끄고 재현해 보세요.
규칙이 수만 줄을 넘으면 메모리와 매칭 비용이 늘어납니다. 꼭 필요한 세트만 쓰고, 겹치는 카테고리(예: 광고 차단을 여러 소스로 중복 적용)는 줄이는 것이 체감 성능에도 이롭습니다. 코어 버전별로 RULE-SET 옵션이나 키 이름이 조금씩 다를 수 있으므로, 업그레이드 후에는 릴리스 노트에서 provider 관련 변경을 확인하세요.
정리
Rule Provider는 「정밀 분류」를 가능하게 하는 도구이지만, 그 정밀함은 좋은 목록·올바른 behavior·합리적인 rules 순서가 함께일 때 완성됩니다. 처음에는 하나의 신뢰할 수 있는 세트만 붙이고, 직접 연결과 프록시 경계가 기대대로인지 검증한 뒤 단계적으로 늘리면 밤샘 디버깅을 줄일 수 있습니다.
규칙형 클라이언트는 한번 구조를 잡아 두면 앱·사이트·지역별 정책을 한눈에 유지하기 쉽습니다. GUI와 코어를 최신에 가깝게 맞춰 두면 파서와 provider 동작도 안정적인 편입니다.