Clash Meta rule-providers로 규칙집 붙이기:
interval·path·RULE-SET YAML 순서 정리

1. rule-providers로 무엇이 좋아지나요

공개 커뮤니티에서 흔히 주는 「올인원」 프로파일은 수백 줄의 DOMAIN과 IP-CIDR을 한 파일 안에 들고 다닙니다. 이 방식도 동작에는 문제 없지만 업스트림이 목록만 갱신할 때 사용자는 통째 블록을 또 붙여 넣거나 머지 스크립트를 돌려야 합니다. rule-providers는 이름 그대로 규칙 제공자(rule provider)에게 그 일을 넘길 수 있게 해 줍니다. 코어가 url에서 원본 규칙 파일을 받아 path에 저장해 두었다가 필요할 때 불러오고, interval이 지나면 다시 받으려 시도합니다. 사용자 입장에서는 rules: 쪽 줄 수가 줄고, 유지 보수 책임이 소스 레포 한곳으로 모입니다.

Mihomo 같은 메타 브랜치는 이 경로와 동작을 오래도록 다듬어 왔기 때문에 검색 결과에 「Clash Meta rule-providers」와 「Mihomo 설정」 표현이 같이 붙습니다. 기능 이름은 거의 동일하게 쓰이므로 같은 YAML 패턴이라고 이해하면 됩니다. 노드 제공자와 혼동하기 쉬운데, proxy-providers는 서버 줄을 채워 넣고, rule-providers는 트래픽 매칭용 목록 파일을 채웁니다. 구독이 비거나 provider 캐시가 깨진 경우를 볼 때처럼, 이번에도 「원격 줄이 존재하는가」보다 「로컬 캐시와 이름 매핑이 맞는가」가 먼저입니다.

2. 필드 타입과 behavior 선택

대부분의 예시에서는 type: http으로 원격 URL을 받아 옵니다. behavior는 내려받은 텍스트를 어떤 자료구조로 읽을지 알려 주는 라벨에 가깝습니다. 같은 GitHub 레포라도 패키지에 따라 도메인 suffix 트라이가 맞는지, 클래식 줄 단위 규칙이 맞는지가 갈립니다. 설명 페이지에 clasical처럼 철자가 틀린 배너만 붙어 있어도 실제 패키지는 classical일 때가 많으므로 제공자 저장소 안내를 따라가세요. 잘못 고르면 로더가 조용히 생략하거나 일부 줄만 무시되는 식이라 체감으로는 규칙이 없는 줄과 비슷해집니다.

3. 단계 1: YAML에 rule-providers 작성

루트에 rule-providers: 맵을 열고, 그 안에 제공자 이름을 키로 하나씩 둡니다. 아래 예시의 키 my-domains는 사용자가 고르기 나름이라도 RULE-SET,my-domains,...)의 첫 인자와 정확히 같아야 하므로 짧더라도 중복 없이 명명합니다. type과 behavior는 패키지 README를 따르고, 숫자 interval은 하루·12시간·6시간 등 운영에 맞춰 선택합니다. 실제 운영에서 하루 갱신이면 통상적으로 86400(초)를 씁니다. 트래픽이 많지 않더라도 같은 패키지를 여러 제공자 줄로 받기만 하면 경로 하나가 덮여 쓰이는 레이스가 생길 수 있으니 디렉터리를 폴더 단위로 나누는 습관이 좋습니다.

rule-providers:
  my-domains:
    type: http
    behavior: domain
    url: "https://example.com/rules/my-domains.txt"
    path: ./rules/cache/my-domains.yaml
    interval: 86400

여기서 따옴표는 YAML 파서에게 특수문자가 섞인 URL을 더 안전히 넘기기 위함입니다. path의 확장자가 .yaml이든 제공자 패키지에 맞는 다른 확장자이든 실제 필요는 「그 경로가 쓰여지고 읽힐 수 있는가」뿐입니다. 구독 파일 합본이나 패치 스크립트가 나중에 이 블록을 덮어쓸 수 있으니, 변경 후에는 로드 결과 프리뷰에서 이 섹션만 다시 확인하세요. Verge 같은 GUI는 내려받은 캐시를 바로 파일 관리자로 열 수 있게 하는 경우도 있어, 비어 있는 파일이라면 업스트림 URL부터 의심하는 편이 빠릅니다.

4. 단계 2: path와 디렉터리 권한

path는 문자열이라 보기 간단하지만 실제로 삽질 많은 지점입니다. 데스크톱 앱들은 종종 패키지 내부의 읽기 전용 영역과 사용자 「프로파일 디렉터리」가 갈립니다. 상대 경로를 썼는데 시작 위치가 기대와 다르면 파일이 다른 곳에 생기거나, 샌드박스 때문에 쓰기 자체가 막히기도 합니다. 경로 불확실할 때는 설정 디렉터리를 에디터로 연 직후 테스트 파일 하나를 같은 방식으로 써 보고 존재하는지 확인하면 재현 속도가 좋습니다.

모바일이나 패키지화된 버전에서는 외부 저장소 접근 허용 같은 OS 권한이 걸린 경우도 있습니다. WSL 안에서 Windows 쪽 디스크 경로만 바꿨더니 심벌릭 경로 때문에 중복 제공자 줄이 깨졌던 사례는 꽤 흔합니다. 한 OS·한 디스크 레이아웃에 맞춰 템플릿을 각각 만들어 두는 편이 정신 건강에 좋습니다. 패키지를 직접 배포했다면 Dockerfile에서도 기록 경로를 마운트로 분리해야 컨테이너 재시작 때마다 캐시를 잃지 않습니다.

5. 단계 3: interval과 수동 새로고침

interval은 자동 새로고침 주기이지 실시간 푸시가 아닙니다. 앱 시작 직후 곧바로 새 파일이 반영된다고 단정하면 안 되고, 많은 실행 환경에서 한 번 시작할 때 초기 패치 한 번 이후 시간 기반으로 돌립니다. 정책이 급변하는 리스트면 GUI의 수동 갱신·External Controller 명령(지원한다면)·앱 재시작까지 단계별로 테스트하는 것이 낫습니다. 반대로 10분 간격처럼 지나치게 짧게 잡아 두면 제공자 레이트 리밋이나 회사 게이트웨이 차단 때문에 다른 기능까지 연쇄 지연을 부르기도 하니, 업스트림 권장치가 있으면 그보다 무리하지 마세요.

간격을 줄이더라도 RULE-SET 적용 순서를 바꾸지 않는 한 새 목록만큼 즉석에서 스플릿 정책이 달라지지는 않을 수 있습니다. 예를 들어 상단 규칙이 이미 MATCH로 떨어지면 아래에 추가된 줄은 관찰 비용 없이 존재감만 있을 때가 있습니다. 테스트할 때는 충돌하는 상위 규칙을 일시 접거나 로그 레벨을 올려 어떤 집합이 적중했는지를 보는 방법이 신뢰도가 높습니다. 헬스체크 간격 글처럼 건강 점검과 허용 오차를 노드에게만 걸지 말고, 규칙 공급에도 과한 폴링을 두지 않는지 돌아보면 전체 레이턴시가 줄어 드는 경우가 있습니다.

6. 단계 4: rules에서 RULE-SET 연결

제공자 키를 RULE-SET에 연결하는 한 줄만 붙어도 엔진은 해당 캐시를 규칙 트라이에 장착합니다. 구문은 선택한 에디터 플러그인이 무엇인지보다 코어 버전 헬프를 따르는 것이 안전합니다. 아래는 개념을 보여 주는 패턴 예시입니다. 실제 타깃 이름·정책 그룹·마지막의 MATCH는 본인의 구성 그대로로 바꿉니다.

rules:
  - RULE-SET,my-domains,🔰 Proxy
  - GEOIP,KR,DIRECT,no-resolve
  - RULE-SET,another-set,🔰 Proxy
  - MATCH,🔥 Final

여기에서 🔰 Proxy 자리에는 실제 존재하는 정책 그룹명을 넣어야 하고 오타 하나면 해당 규칙 줄 전체가 사실상 죽습니다. 제공자 줄에 별도 헤더(룰 파일 안의 코멘트나 메타)가 있더라도 RULE-SET이 보는 이름은 블록 키뿐입니다. 구독을 붙였다 떼는 실험을 반복했다면 제공자 이름이 남았는데 블록이 없는 상태가 되기도 하므로, 정리 차원에서 더 이상 쓰지 않는 줄은 YAML과 GUI 양쪽에서 같이 치워 주는 버릇을 들이세요. DNS 레이어나 GEOIP와 DIRECT 조합, ,no-resolve 같은 힌트가 있는 규칙과 섞여 있을 때는 해석 순서가 곧 결과이므로, GeoIP 목록 업데이트를 rule-providers로 옮긴다면 예전 레거시 줄과 이중 카운팅되지 않는지도 함께 봐야 합니다.

7. GeoIP·geosite와 함께 쓸 때 순서 감각

RULE-SET은 도메인·IP 패키지에 치중하고 GEOIP는 국가 코드 기반 블록에 치중합니다. 둘을 같이 두면 순서 하나로 「어느 쪽 규칙이 먼저 말을 거나」가 바뀌어 트래픽이 다른 노드를 탑니다. 메타 브랜치는 종종 geosite·geoip 데이터베이스를 패키지에 묶거나 다운로드 경로 옵션을 따로 줄 수 있습니다. 업데이트 주기만 rule-providers에 맞췄다고 해서 레거시 MATCH 줄이 과거 그대로라면 결과는 변하지 않을 수 있습니다. 중국 본토 DIRECT 튜토리얼처럼 지연 문제를 GeoIP로 접근한다면 제공자 줄과 순서까지 동시에 열어두고 diff하는 습관이 필요합니다.

일부 패키지는 DIRECT 전용 제공자 줄과 프록시 전용 제공자 줄을 섞어도 상단 규칙이 이미 DNS 기반 GEOIP 블록에 걸리면 노드 선택이 무의미하게 됩니다. 이 경우 「DNS에서는 지역 레코드를 받았는데 TCP는 다른 경로를 탄다» 같은 교차 디버깅이 필요해서, 레이어별로 로그 접두어만 맞춰도 분석 속도가 확 좋아집니다. 전체 레퍼런스는 시간이 지나면 조금씩 달라지므로 현재 사용 중인 메이저 버전에 맞춘 공식 채널의 스키마 페이지를 책갈피해 두세요.

8. 헷갈리는 증상과 점검

규칙을 바꿨는데 즉시 반영이 안 된다: 캐시 파일을 직접 열어보면 이전 줄이 그대로인지 새 줄인지 즉결됩니다. path가 사용자가 생각하는 위치가 아니라면 수정은 했지만 읽히는 디스크 다른 곳에 남았을 가능성부터 지웁니다. RULE-SET 인자 이름 오타는 로그 레벨이 낮을 때 무음에 가까우니 문자 단위 검사를 권장합니다. 「원격 줄은 존재하는데 MATCH만 친다」면 제공자 줄의 behavior 불일치로 실제 활성 줄 수가 줄었을 수 있습니다.

자주 묻는 질문

interval 단위가 분인가 초인가? 메타 계열에서 자주 등장하는 YAML 샘플은 초 기준입니다. 의심스러우면 3600처럼 짧지만 과하지 않게 두고 시작 직후·한 시간 후의 파일 타임스탬프 차이만 보더라도 확정됩니다. path는 어디가 좋은가? OS별로 사용자 쓰기 가능한 「프로파일 루트」 아래에 rules/cache/… 같이 디렉터리를 새로 깔아 두면 백업·삭제 규칙이 단순해집니다. GUI에서 수정한 줄이 재시작 후 사라진다? 상위 디렉터리에 있는 마스터 YAML을 다시 읽거나 클라우드 동기 폴더가 덮어쓸 수 있으므로 진입 방식별로 우선 순위 테이블을 한 번 확인하세요.

9. 마무리

rule-providers는 네 줄짜리 선언 하나로 긴 규칙 파일을 버전별로 교체 가능하게 만들어 주지만, 진짜 효과는 behavior 매칭, 중복 없는 path, 합리적인 interval, 그리고 rules:의 RULE-SET 선언 순서가 함께 맞았을 때 납니다. 이 네 요소 하나라도 놓치면 제공자 줄을 아무리 늘려도 결과는 과거 레거시 MATCH 한 줄처럼 보일 때가 많습니다.

시중 일부 초간단 브라우저 확장이나 패널 형 도구들은 즉석 스위치까지는 간단하지만, 대규모 제3자 규칙 생태계·자동 새로고침·패키지화된 제공자 줄을 깔끔히 받아 쓰기는 불리한 경우가 있습니다. 업데이트 주기 세밀하게 다루기도 어렵고, 여러 디바이스에 같은 분류 결과를 재현하기엔 버전 차이부터 큽니다. 반면 공개 생태계에 맞춰 설계된 클래스 기반 규칙 엔진 안에서 제공자 줄을 쓰면 공개 목록 업데이터가 바뀔 때 따라가기 유리합니다. 패키지는 문서 허브의 모드별 설명처럼 정리되어 있으며, 깃허브는 이슈·릴리스 추적에는 좋고 일상 패키지는 사이트의 클라이언트 패키지 허브를 쓰는 편이 낫습니다.

원격 줄과 로컬 캐시, 그리고 실제 라우팅 세 줄까지 한 번 정리했다면 같은 패턴으로 다른 카테고리 패키지만 덧붙여도 실험 속도가 빨라집니다. 레이블과 경로 이름만 일관적으로 유지해 두면 새 기기 세팅도 지루한 복사·붙여넣기가 아니라 점진적 확장이 됩니다. 유사 카테고리와 경쟁하는 일부 패널 형 솔루션은 업데이터가 장기 미갱신이거나 특정 OS에서만 동작하는 경우가 있어, 분류 정책을 직접 파일로 들고 다니는 흐름이 유지 보수에 유리한 경우가 많습니다. 이 맥락에서 Clash 계열은 규칙 생태계가 넓고 YAML로 공유하기 쉬우며, 멀티 플랫폼 클라이언트에서도 같은 제공자 블록을 재사용하기 좋습니다. 반복 작업을 줄이고 싶다면 Clash 클라이언트를 무료로 내려받고 이 글의 순서대로 rule-providers와 RULE-SET만 맞춰 보세요.

→ 문서 허브에서 모드·DNS·규칙 스키마를 함께 열어 두면 이번에 정리한 제공자 줄이 다른 옵션과 충돌하지 않는지 더 빨리 검증할 수 있습니다.