규칙 집합을 rule-providers로 두는 이유
인라인 rules만 쓰면 나중에 항목이 길어지고, 커뮤니티에서 배포하는 도메인 목록·국가 예외 묶음을 매번 손으로 붙여 넣기 어렵습니다. rule-providers는 이름 붙은 외부 규칙 소스를 등록하는 자리이고, 코어는 주기적으로 그 소스에서 파일을 받아 path 아래에 두었다가 RULE-SET 규칙이 참조합니다. 이렇게 하면 프록시 노드 목록은 proxies·구독 쪽, 분류 규칙 본문은 RULE-SET 쪽으로 책임이 갈라져 유지보수가 쉬워집니다.
사용자 입장에서 검색하기 쉬운 표현은 “Mihomo rule-providers 간격”, “규칙 집합 자동 업데이트”, “RULE-SET interval” 같은 조합입니다. 이 글도 그 의도에 맞춰 필드 이름을 그대로 쓰되, 실제 YAML 키는 쓰는 빌드 문서와 반드시 대조하세요.
1interval은 무엇을 제어하나
일반적인 해석은 “원격 규칙 파일을 다시 가져오기까지 기다리는 타이머”입니다. 값은 보통 초 단위이며, 86400은 하루입니다. 타이머가 돌 때 코어는 url(HTTP 타입일 때)을 다시 요청하고, 성공하면 path 위치를 갱신한 뒤 규칙 엔진이 새 목록을 읽습니다. 실패하면 이전 캐시를 유지하는 경우가 많아서, 표면상으로는 “규칙이 안 바뀐다”로 보일 수 있습니다.
구독 URL이 노드·프록시 정보를 갱신하는 것과는 별개입니다. 노드 목록은 여전히 앱의 구독 새로고침 주기를 따르고, RULE-SET은 rule-providers의 interval을 따릅니다. 둘 중 하나만 자주 맞춰도 체감이 어긋납니다. 예를 들어 노드는 최신인데 목록 태그가 옛날이면 특정 사이트 줄이 계속 빗나갈 수 있습니다.
팁: 여러 RULE-SET을 동시에 두면 각각의 interval이 돌아갑니다. 장치가 많거나 간격을 극단적으로 짧게 두면 원본 서버나 CDN에서 429·403이 나기 쉽습니다. 공개 목록 제공자의 안내 주기가 있으면 그 근처로 맞추는 편이 안전합니다.
2url과 path를 한 세트로 설계
type: http일 때 url은 내려받을 주소입니다. 릴리스 페이지의 원시 파일 링크, 정적 호스팅, 미러 등 어떤 형태든 되지만 코어가 TLS 검증·리다이렉트를 처리할 수 있는지는 환경마다 다릅니다. 기업망이나 투명 프록시에서는 예외가 필요할 수 있습니다.
path는 로컬에 저장할 상대 또는 절대 경로입니다. 데스크톱 클라이언트는 사용자 프로필 폴더 아래에 규칙 캐시를 두는 경우가 많고, Docker로 돌리면 컨테이너 안 경로와 호스트 볼륨이 일치하는지 반드시 확인해야 합니다. 권한이 없으면 파일은 받아졌다고 로그에 보여도 실제로는 비어 있거나 옛 파일만 남을 수 있습니다.
behavior와 파일 형식 맞추기
behavior는 domain, ipcidr, classical 등으로 나뉩니다. 받은 파일이 어떤 규칙 타입 묶음인지와 맞지 않으면 RULE-SET이 로드되어도 매칭이 거의 일어나지 않습니다. GEOSITE 태그가 들어 있는 classical 형태와, 순수 도메인 목록 형태를 혼동하는 경우가 흔합니다. 의심되면 제공자 문서의 예시 YAML을 그대로 따른 뒤 한 줄씩 바꿔 나가세요.
3복붙용 YAML 스케치
아래는 개념 정리용 예시입니다. 키 이름·세부 옵션은 현재 Mihomo 버전 문서를 우선합니다. 정책 그룹 이름은 자신의 프로필에 있는 이름으로 바꿔야 합니다.
# Sketch — verify keys against Mihomo docs for your version
rule-providers:
remote-geosite:
type: http
behavior: domain
url: "https://example.com/rules/geosite-tag.yaml"
path: ./ruleset/geosite-remote.yaml
interval: 86400
rules:
- RULE-SET,remote-geosite,PROXY
- GEOIP,CN,DIRECT,no-resolve
- MATCH,DIRECT
RULE-SET 줄은 rules 배열 안에서 다른 줄들과 같은 순서 규칙을 따릅니다. 넓은 RULE-SET을 너무 위에 두면 세부 예외 줄까지 도달하지 못합니다. 순서 설계는 별도 글의 패턴을 참고하세요.
4GEOSITE·GEOIP 데이터베이스와 RULE-SET
GEOSITE·GEOIP 인라인 규칙이 동작하려면 보통 geosite.dat, Country.mmdb 같은 geodata가 코어가 읽을 수 있는 위치에 있어야 합니다. 이 파일들의 버전은 클라이언트 업데이터나 수동 배포로 바뀌는 경우가 많고, rule-providers의 interval과는 별개입니다.
반면 RULE-SET으로 가져오는 원격 파일 안에도 GEOIP·GEOSITE 스타일 규칙이 들어 있을 수 있습니다. 즉 “태그 이름이 같은데 왜 매칭이 다르지?”는 질문은 종종 어떤 데이터 소스를 바라보는지가 달라서 생깁니다. 어떤 빌드의 geosite를 쓰는지 먼저 고정하는 것이 디버깅 비용을 줄입니다.
5GUI·mixin·프로필 합치기 시 주의점
Clash Verge Rev 구독 자동 새로고침 글처럼 GUI에는 구독 간격 설정이 따로 있지만, RULE-SET 주기는 최종적으로 생성된 설정 YAML의 rule-providers에 반영되어야 합니다. mixin·프로필 병합을 쓰면 같은 키가 여러 층에서 덮어씌워질 수 있으니, 편집기에서 최종 병합 결과만 보고 interval을 판단하면 실수가 줄어듭니다.
6재로드·수동 갱신·로그로 확인
설정을 저장한 뒤에는 코어 재시작 또는 설정 재로드가 필요할 수 있습니다. 일부 클라이언트는 RULE-SET만 다시 받는 버튼을 제공합니다. 로그에는 규칙 프로바이더 이름과 함께 HTTP 결과·파일 경로가 찍히는 경우가 많습니다.
외부 컨트롤러를 켠 환경이라면 Yacd 같은 패널에서 요청을 시험해 볼 수 있습니다. 다만 보안상 API를 외부에 노출하지 않도록 방화벽과 토큰 설정을 먼저 정리하세요.
자주 막히는 지점
- 간격은 짧은데 403·429: 제공자 정책과 충돌했을 가능성이 큽니다. interval을 늘리고 장치별 동시 요청을 줄입니다.
- behavior 불일치: 파일 형식과
behavior가 어긋나면 “아무 것도 안 맞는다”로 보입니다. - path 권한·읽기 전용 볼륨: 특히 NAS·컨테이너 마운트에서 발생합니다.
- HTTPS 호스트가 비어 GEOSITE가 안 맞음: 연결 단계에서 이름 정보가 없으면 도메인 태그 매칭이 빗나갈 수 있습니다. Sniffer와 DNS를 함께 봅니다.
- 정책 그룹 이름 오타: RULE-SET 줄 끝의 그룹 이름이 프로필에 없으면 재로드 오류나 의도치 않은 폴백이 생깁니다.
주의: 포럼 예시 YAML을 그대로 쓸 때 url이 만료형 서명 링크인 경우가 많습니다. 며칠 뒤 갑자기 실패하는 원인이 되므로, 장기적으로는 안정적인 정적 원본이나 자신이 통제하는 미러를 쓰는 편이 낫습니다.
짧은 FAQ
Q. interval을 0으로 두면 매 요청마다 받나요?
구현과 버전에 따라 의미가 다를 수 있어 문서를 확인해야 합니다. “항상 최신”을 노리다 레이트 리밋에 걸리는 경우가 많습니다.
Q. 노드 구독만 자주 갱신하면 충분하지 않나요?
노드가 바뀌어도 “어떤 트래픽을 어느 노드로 보낼지”는 규칙이 결정합니다. RULE-SET이 오래되면 목록 태그가 현실과 어긋납니다.
Q. 규칙 파일과 GeoIP DB를 같은 날짜로 맞춰야 하나요?
엄격히 동기화할 필요는 없지만, 둘 다 너무 오래되면 같은 증상이 겹쳐 보입니다. 문제가 길게 지속되면 각각의 출처와 마지막 수정 시각을 따로 확인하세요.
정리
Clash Meta·Mihomo에서 원격 규칙 집합을 쓰려면 rule-providers에 URL·path·interval을 명확히 적고 rules에서 RULE-SET으로 묶는 흐름이 중심입니다. interval은 자동 갱신의 심박이지만, 너무 빠르게 두면 운영 정책과 충돌하고, 너무 느리면 사용자 체감이 뒤처집니다. geodata와 RULE-SET 파일을 구분해 두면 GEOIP·GEOSITE 관련 이슈를 좁히기 쉽습니다.
같은 구독이라도 클라이언트 빌드와 코어 버전에 따라 메뉴 이름이 달라지므로, 릴리스 직링크보다 사이트의 다운로드 허브에서 플랫폼에 맞는 패키지를 고르고 YAML은 문서와 대조해 가며 조정하는 편이 안전합니다. 여러 장치에 배포할 때는 RULE-SET 간격까지 포함해 한 번에 문서화해 두면 재현성이 좋아집니다.
→ Clash 클라이언트를 무료로 내려받아 Mihomo 코어에서 rule-providers와 RULE-SET 자동 갱신을 바로 시험해 보세요