Rule Provider 실전: 수백 줄의 규칙을 직접 작성하지 않아도 됩니다

"자주 쓰는 사이트는 직접 연결, 흔한 광고 도메인은 차단, 스트리밍은 특정 노드로" — 이런 규칙은 거의 모두에게 필요하지만, 직접 작성하려면 수백 개의 DOMAIN-SUFFIX가 필요하고 업데이트도 스스로 관리해야 합니다. Rule Provider는 바로 이 문제를 해결하기 위해 존재합니다.

🗓️ 2026년 6월 26일 ⏱️ 약 7분 소요 🔗 관련 문서: 고급 설정 · Rule Provider: 규칙 세트 구독

Rule Provider가 해결하는 문제

규칙은 본질적으로 "도메인/IP를 특정 동작에 매핑"하는 표이며, 커뮤니티에서는 이미 흔한 카테고리(광고 도메인, 자주 쓰는 사이트, 각종 스트리밍 서비스 등)를 공개적으로 관리되고 계속 업데이트되는 규칙 파일로 정리해두고 있습니다.

rule-providers를 사용하면 Clash가 원격 URL에서 이 규칙 파일을 직접 다운로드하고, 설정한 주기에 따라 자동으로 업데이트합니다. 설정 파일에서는 한 번만 참조하면 되며, 수백~수천 개의 규칙을 직접 관리할 필요가 없습니다.

✅

손으로 작성한 규칙과 비교했을 때 Rule Provider의 가장 큰 장점은 "수고를 던다"는 것이 아니라 "지속적인 관리"입니다 — 도메인은 계속 바뀌고 광고 도메인 목록도 끊임없이 업데이트가 필요한데, 이는 규칙 세트 관리자가 대신 해주고 있으며 당신은 주기에 맞춰 동기화만 하면 됩니다.

세 가지 규칙 세트 유형

유형 (behavior)	내용 형식	대표적인 용도
`domain`	한 줄에 도메인 하나, 와일드카드 지원	도메인 기준으로 분류(광고 도메인, 특정 사이트 등)
`ipcidr`	한 줄에 IP 범위(CIDR) 하나	IP 범위 기준으로 분류(특정 지역, 특정 데이터센터의 IP 범위 등)
`classical`	표준 Clash 규칙 문법을 한 줄씩	혼합 유형. 하나의 파일에 `DOMAIN`, `IP-CIDR` 등 여러 규칙을 함께 작성 가능

또한 파일 형식을 결정하는 format 필드도 있으며, 흔히 쓰이는 것은 yaml과 용량이 더 작고 파싱이 더 빠른 mrs(mihomo 규칙 세트 바이너리 형식)입니다.

실제 설정 예시

config.yamlyaml

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400
  direct:
    type: http
    behavior: classical
    url: "https://example.com/rules/direct.txt"
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - MATCH,PROXY

핵심 필드 몇 가지:

interval: 규칙 세트 자동 업데이트 주기(초)입니다. 내용은 시간이 지나면서 바뀌므로 대략 하루(86400) 정도로 설정하면 충분하며, 너무 자주 갱신할 필요는 없습니다.
path: 로컬 캐시 경로입니다. 다운로드된 규칙 세트는 먼저 로컬에 저장되며, 클라이언트를 재시작해도 다시 다운로드할 필요가 없습니다.
RULE-SET,이름,동작: rules에서 이름으로 특정 규칙 세트를 참조합니다. 동작은 DIRECT, REJECT이거나 특정 프록시 그룹 이름일 수 있습니다.

⚠️

rules는 위에서 아래로 평가되며 처음 매칭되는 순간 멈추기 때문에, 규칙 세트를 참조하는 순서도 중요합니다 — 보통 우선순위가 높은 정확 매칭 규칙(직접 추가한 예외 등)을 맨 앞에, 규칙 세트를 중간에, 마지막에 처리하는 MATCH를 맨 뒤에 둡니다.

규칙 세트는 어디서 구하나요

규칙 세트를 직접 작성할 필요는 없습니다. 커뮤니티에는 이미 자주 쓰는 사이트 직접 연결, 광고 차단, 인기 스트리밍 플랫폼, 흔히 쓰는 AI 서비스 등의 카테고리를 다루는, 오랫동안 관리되고 정리된 공개 프로젝트가 다수 존재하며, 설정 파일을 구성할 때 거의 "표준 의존성"처럼 쓰입니다. 규칙 세트 출처를 고를 때는 다음 두 가지를 중점적으로 확인하세요:

업데이트가 활발한가: 도메인과 IP 범위는 계속 바뀌므로, 몇 달째 업데이트되지 않은 규칙 세트는 점점 정확도가 떨어집니다. 저장소의 최근 커밋 기록을 보고 판단할 수 있습니다.
분류가 충분히 세밀한가: 일부 규칙 세트는 "자주 쓰는 사이트 직접 연결"과 "광고 차단"을 따로 관리해, 필요한 것만 참조할 수 있게 해줍니다. 크고 모든 것이 담긴 하나의 파일을 통째로 다운로드하지 않아도 됩니다.

💡

규칙 세트마다 분류 기준이 완전히 같지는 않습니다. 여러 소스를 섞어 쓰기 전에, 먼저 며칠간 소규모로 테스트해서 명확한 오탐이나 누락이 있는지 확인한 뒤 장기적으로 사용할지 결정하는 것이 좋습니다.

자동 업데이트와 수동 강제 새로고침

interval은 Clash 코어가 백그라운드에서 실행 중일 때 주기적으로 업데이트를 확인하는 간격을 제어하지만, 설정을 방금 바꾸고 클라이언트를 재시작한 순간에 강제로 새로고침하지는 않습니다 — 이미 로컬에 규칙 세트 파일(path가 가리키는 파일)이 캐시되어 있다면, 코어는 기본적으로 먼저 로컬 캐시를 사용하고 interval 주기가 되었을 때 다시 다운로드합니다.

다음 두 상황에서는 특히 주의가 필요합니다:

규칙 세트 주소를 A에서 B로 방금 바꿨는데 path는 함께 바꾸지 않은 경우, 코어가 여전히 이전 파일에 해당하는 캐시 경로를 사용하고 있어 "설정을 바꿨는데 적용이 안 된" 것처럼 보일 수 있습니다.
규칙 세트 관리자가 명백한 오차단 문제를 방금 수정했고 최신 버전을 즉시 쓰고 싶다면, path가 가리키는 로컬 캐시 파일을 직접 삭제하고 클라이언트를 재시작해 강제 재다운로드를 유도할 수 있습니다.

Dashboard 패널이 있는 대부분의 클라이언트는 "규칙 업데이트" 버튼도 제공하는데, 이는 캐시를 수동으로 삭제하고 재시작하는 것과 같은 효과이며 일상적으로 사용하기 더 편리합니다.

규칙 세트 vs 손으로 작성한 규칙: 성능은 어떨까

"수만 개의 규칙을 다운로드하면 매칭 속도가 느려지지 않을까" 걱정하는 사람도 있지만, 실제로는 코어가 규칙 세트를 불러올 때 전처리를 수행합니다(예: 도메인 규칙을 트라이 구조로 정리하는 등). 그래서 개별 규칙의 매칭 비용이 규칙 수에 따라 선형으로 늘어나지 않으며, 수천 개에서 수만 개의 규칙이라도 현대 기기에서는 체감할 수 있는 지연 차이가 거의 없습니다.

실제로 체감 속도에 영향을 주는 것은 오히려 규칙의 배치 순서입니다 — 매칭률이 높은 규칙일수록 앞쪽에 둘수록 평균 매칭 횟수가 줄어듭니다. 그래서 자주 쓰는 직접 연결 규칙 세트를 앞쪽에 두는 것을 권장하는 것이지, 아무 생각 없이 규칙 목록 맨 끝에 두면 안 됩니다.

실전 팁

서로 다른 출처의 규칙 세트를 너무 많이 겹쳐 쓰지 마세요. 같은 도메인이 여러 규칙 세트에서 서로 다르게 판정되어 동작이 일관되지 않을 수 있습니다. 하나의 필요에는 활발히 관리되는 규칙 세트 하나만 선택하면 충분합니다.
규칙 세트에 문제가 생겼을 때(예: 정상적인 사이트가 잘못 차단된 경우), 먼저 자신의 설정을 의심하기 전에 규칙 세트 자체의 문제인지 확인하세요 — 특정 RULE-SET 줄을 임시로 주석 처리해 원인을 찾아볼 수 있습니다.
스트리밍 우회 관련 규칙 세트는 업데이트가 가장 빈번합니다(플랫폼이 IP 범위와 도메인을 계속 바꾸기 때문). interval을 조금 더 짧게, 예를 들어 43200(12시간)으로 설정하는 것도 합리적입니다.
참조하고 있는 규칙 세트 목록을 주기적으로 검토하고 더 이상 필요 없는 카테고리는 삭제하세요. 설정 파일이 간결할수록 문제가 생겼을 때 원인을 찾기 쉬워집니다.

더 완전한 규칙 문법과 우선순위 설명은 고급 설정 가이드의 규칙 엔진 섹션을 참고하세요.