Rule Providers가 해결하는 문제
초기에는 rules: 아래에 도메인·IP·GeoIP 규칙을 한 줄씩 직접 적는 방식으로도 충분한 경우가 많습니다. 그러나 시간이 지나면 구독 노드만큼이 아니라 분류용 목록이 수천~수만 줄로 불어나고, 매주 갱신되는 광고 차단·지역별 스트리밍·악성 IP 피드까지 합치면 단일 YAML 파일을 읽고 diff 하기가 거의 불가능에 가까워집니다. 이때 rule-providers는 원격 또는 로컬의 규칙 묶음을 이름 붙은 모듈로 불러와 캐시하고, 본문 rules에서는 짧은 한 줄로 그 모듈 전체를 참조하게 해 줍니다.
한마디로, 거대한 목록은 구독 가능한 규칙 세트로 분리하고 메인 프로필에는 「어떤 세트를 어느 정책 그룹에 붙일지」만 남기는 패턴입니다. GUI 클라이언트가 프로필을 생성할 때도 내부적으로 비슷한 구조를 쓰는 경우가 많으므로, 원리를 알아 두면 커스텀 규칙을 덧붙이거나 제공자 템플릿을 손볼 때 훨씬 수월합니다.
왜 규칙까지 「구독」하는가
첫째, 유지보수 주체를 분리할 수 있습니다. 노드 구독 URL은 업체가 관리하고, 광고·트래킹 차단 목록은 오픈소스 커뮤니티나 별도 저장소가 관리하는 식으로 역할을 나누면, 한쪽만 갱신돼도 전체 프로필을 수동 병합할 필요가 줄어듭니다. 둘째, 갱신 주기를 규칙 종류별로 다르게 둘 수 있습니다. 예를 들어 GeoIP 성격의 큰 데이터는 하루 한 번이면 충분한 반면, 일시적으로 급증하는 악성 도메인 피드는 더 짧은 interval을 주고 싶을 수 있습니다. 셋째, 디스크 캐시에 내려받아 두면 재시작 후에도 동일한 스냅샷에서 시작할 수 있어, 오프라인 환경에서도 마지막으로 성공한 규칙 세트를 유지하기 쉽습니다.
반대로 말하면, 신뢰할 수 없는 URL을 그대로 rule-provider로 넣으면 원격에서 규칙 내용이 바뀔 때마다 트래픽 경로가 바뀌는 위험이 있습니다. 출처의 신뢰도·HTTPS 사용 여부·체크섬 또는 고정 태그 릴리스를 쓸 수 있는지 등을 사전에 검토하는 것이 좋습니다.
rule-providers 기본 골격
이름은 자유롭게 정하되, 이후 rules에서 그 이름을 그대로 씁니다. 흔한 필드는 type(보통 원격이면 http), url, 로컬 캐시 경로 path, 목록 해석 방식 behavior, 선택적 interval(초 단위 갱신 주기)입니다. 아래는 설명용 최소 예시입니다.
# Example only — replace URL/path with your trusted sources
rule-providers:
my-domains:
type: http
behavior: domain
url: "https://example.com/rules/domains.txt"
path: ./rules/my-domains.yaml
interval: 86400
rules:
- RULE-SET,my-domains,DIRECT
- MATCH,PROXYpath는 클라이언트가 다운로드한 결과를 저장하는 위치로, 기기마다 기본 작업 디렉터리가 다르므로 GUI에서 생성된 프로필의 상대 경로를 우선 따르는 편이 안전합니다. interval을 생략하면 구현·버전에 따라 기본값이 달라질 수 있으니, 운영 정책이 있다면 명시하는 것을 권장합니다.
behavior와 파일 형식 맞추기
가장 흔한 실수는 behavior와 실제 파일 내용의 불일치입니다. 대략적으로, classical은 전통적인 Clash 규칙 한 줄 한 줄 형태의 묶음에 가깝고, domain·ipcidr 등은 해당 타입에 맞춘 단순 목록 형태를 기대하는 경우가 많습니다. 코어가 Meta/Mihomo 계열이라면 바이너리 규칙 세트(rule-set)나 별도 스키마를 쓰는 모드가 추가로 있을 수 있어, 복사한 예제가 어떤 코어·어떤 버전 기준인지 항상 확인해야 합니다.
파싱 오류가 나면 로그에 프로바이더 이름과 줄 번호·키워드가 함께 찍히는 경우가 많습니다. 이때는 (1) URL이 실제로 기대한 포맷을 반환하는지 브라우저나 curl로 확인하고, (2) behavior를 문서에 맞게 수정하고, (3) 중간에 프록시 캐시가 오래된 응답을 주고 있지 않은지 순서로 좁혀 가면 됩니다.
interval, 캐시, 디스크 사용량
짧은 interval은 항상 「최신」에 가깝게 유지해 주지만, 모바일 데이터나 약한 Wi-Fi에서는 백그라운드 다운로드가 잦아져 배터리·지연에 영향을 줄 수 있습니다. 반대로 너무 길면 목록이 실제보다 늦게 따라와 특정 사이트만 간헐적으로 막히거나 열리는 현상이 생길 수 있습니다. 실무에서는 목록 성격별로 tier를 나누는 방식이 무난합니다. 예를 들어 핵심 Geo/지역 분류는 일 단위, 실험적 피드는 수 시간 단위, 거의 변하지 않는 로컬 커스텀 목록은 수동 갱신만 허용하는 식입니다.
캐시 파일이 쌓이면 디스크 용량이 눈에 띄게 늘 수 있습니다. 클라이언트 설정 화면에서 캐시 위치를 확인하고, 필요 시 앱 데이터를 정리하거나 문제 재현을 위해 특정 path 파일만 삭제 후 재다운로드해 보세요. 업데이트 후 「이전에는 되던 규칙이 갑자기 이상하다」는 경우, 남은 오래된 캐시가 원인인 경우가 흔합니다.
rules에서 프로바이더 연결하기
rules 항목의 순서는 그대로 위에서 아래로 매칭됩니다. 따라서 좁고 구체적인 예외(특정 도메인 DIRECT 등)를 위에 두고, RULE-SET으로 가져온 대형 목록은 그 아래에 배치하는 식으로 설계하는 경우가 많습니다. 여러 RULE-SET을 나열할 때는 서로 겹치는 패턴이 없는지, 앞선 규칙이 의도치 않게 뒤쪽 세트를 가리지 않는지 한 번씩 훑어 보세요.
정책 그룹 이름은 실제 proxy-groups에 정의된 이름과 정확히 일치해야 합니다. 오타 하나로 해당 줄 전체가 무시되거나 기본 경로로 떨어져 「프록시로 보내야 할 트래픽이 DIRECT로 나간다」 같은 증상으로 이어질 수 있습니다. 복잡한 구성이라면 문서 허브의 정책 그룹 설명과 함께, 로그의 매칭 결과를 병행해 검증하는 것이 좋습니다.
Mihomo(Clash Meta)와 rule-set 개념
최신 Meta/Mihomo 계열에서는 대용량 데이터를 효율적으로 다루기 위해 rule-set이라는 이름이 설정 곳곳에 등장합니다. 이름이 비슷해 헷갈리기 쉬운데, 큰 그림에서는 「규칙 데이터를 외부 파일·원격 소스에서 가져와 엔진이 빠르게 조회한다」는 점에서 rule-providers와 맥락을 같이합니다. 다만 키 이름·지원 타입·GUI가 생성하는 YAML 조각은 코어 버전에 따라 다르므로, 인터넷에 떠도는 예제를 붙여 넣기 전에 현재 쓰는 클라이언트가 끌어오는 코어 버전의 공식 문서를 한 번 대조하세요.
코어를 올린 직후 규칙만 이상해졌다면, 구버전용 classical 목록을 rule-set 전용 필드에 넣은 경우일 수 있습니다. 이때는 제공자 템플릿을 최신으로 바꾸거나, behavior·포맷을 문서에 맞게 수정하는 편이 빠릅니다.
자주 쓰는 구성 패턴
로컬 오버라이드와 원격 베이스 결합은 실무에서 매우 흔합니다. 팀 공용 베이스 RULE-SET은 URL로 받고, 사내 포털·은행·헬스체크 도메인만 rules 상단에 소수의 고정 줄로 적어 두면, 베이스가 업데이트돼도 예외가 덮어쓰이지 않습니다. 중복 provider는 같은 대형 목록을 이름만 다르게 두 번 받아 디스크와 CPU를 낭비하기 쉬우니, 한 provider를 여러 규칙 줄에서 참조할 수 있는지 먼저 확인하세요.
또 하나는 스테이징입니다. 새 규칙 세트 URL을 바로 메인 프로필에 넣기보다, 테스트용 프로필에서만 interval을 짧게 두고 며칠간 로그를 본 뒤 본 프로필에 합류시키면 장애 반경을 줄일 수 있습니다.
rule-providers 블록을 수동으로 편집했다면, 다음 동기화 때 덮어쓰일 수 있습니다. 장기 커스텀이 필요하면 「사용자 규칙」 전용 파일이나 병합 순서를 지원하는 클라이언트 기능을 활용하세요.문제 해결 체크리스트
프로필은 뜨는데 특정 RULE-SET만 비어 있다
URL 차단·인증서 오류·리다이렉트 루프를 의심하세요. 동일 네트워크에서 URL을 직접 열어 보고, 필요하면 다른 DNS나 시간대에서 재시도해 봅니다.
첫 연결만 유난히 느리다
대형 세트를 cold load하는 동안 지연이 생길 수 있습니다. interval을 늘리거나, 불필요한 대형 세트를 줄이고, 캐시가 SSD에 가까운 경로에 있는지 확인하세요.
규칙이 예상과 다르게 매칭된다
rules 순서와 정책 그룹 이름을 다시 확인하고, 로그에서 실제 매칭된 규칙 이름을 추적하세요. DNS 모드(fake-ip 등)와 함께 쓸 때는 도메인 기반 규칙이 기대와 다르게 동작하지 않는지도 같이 봐야 합니다.
클라이언트·문서·설치 패키지
코어와 GUI는 오픈소스 저장소에서 이슈와 릴리스 노트를 확인할 수 있어 투명성이 높습니다. 다만 실행 파일을 받는 주 경로는 신뢰할 수 있는 배포 채널을 쓰는 것이 안전합니다. 플랫폼별 클라이언트 모음과 재설치 절차는 다운로드 페이지를 우선 참고하고, 라이선스와 소스 코드는 별도로 공개 저장소를 통해 확인하시면 혼선이 적습니다.
정리
Rule Providers를 잘 쓰면 거대한 규칙 목록을 모듈화하고 갱신 주기까지 분리해 운영 부담을 크게 줄일 수 있습니다. 핵심은 behavior와 실제 파일 형식의 일치, rules 배치 순서, 캐시·interval 균형, 그리고 신뢰할 수 있는 규칙 출처를 고르는 일입니다. Meta/Mihomo로 갈수록 rule-set 계열 기능이 중요해지므로, 코어 버전과 문서를 세트로 읽는 습관을 들이면 장기적으로 시간을 아낄 수 있습니다.
비슷한 도구들 가운데에서도 Clash 계열은 규칙 기반 분기와 프로바이더 패턴이 성숙해 있어, 구독 노드와 규칙 세트를 함께 다루는 일상 운영에 잘 맞는 편입니다. 설정이 길어질수록 「한 파일에 모두 넣기」보다 역할별로 쪼개고 검증 가능한 단위로 유지하는 쪽이 안정적입니다.