Clash 규칙 세트(Rule Provider)를 못 받을 때: 원격 URL, PATH, interval, YAML·로그 점검

이 글은 누구를 위한 내용인가요?

이미 mode: rule과 DOMAIN·GEOIP 정도는 써 본 분이지만, 구독 프로필에 포함된 rule-providers(일명 Rule Provider, 원격 규칙 세트)를 바꾸거나 직접 추가했는데 갱신 실패·다운로드 오류·로컬 PATH를 찾지 못한다는 메시지가 뜰 때, 어디를 먼저 봐야 할지 갈피를 못 잡는 경우가 많습니다. 본문은 Clash 계열(Mihomo·Clash Meta 등)에서 remote rule을 HTTP로 끌어오는 흐름을 기준으로, 설정 필드·YAML 문법·interval 의미, 그리고 로그에 나오는 단서를 한데 묶어 설명합니다.

도메인 유형이나 정책 그룹 설계 전반은 규칙 분할 가이드에 가깝고, 여기서는 “규칙이 왜 엔진에 올라오지 않는가”라는 공급망( provider ) 층에 초점을 둡니다.

rule-providers가 하는 일

rule-providers 블록은 외부에서 규칙 파일을 가져와 캐시에 저장한 뒤, rules: 안의 RULE-SET,이름,정책 한 줄과 연결하는 레이어입니다. 즉, 사용자가 rules:에 수백 줄을 직접 쓰지 않고, https://로 올라와 있는 rule-set을 주기적으로 동기화하는 패턴이 됩니다. 이 단계가 실패하면 그 세트에 의존하는 RULE-SET 규칙은 비어 있거나 이전 캐시에 멈춰, 체감상 “새 DOMAIN이 안 먹힌다”로 보일 수 있습니다.

꼭 맞아야 하는 YAML 뼈대

가장 흔한 실수는 들여쓰기와 콜론 뒤 공백입니다. rule-providers는 보통 proxy-groups·proxies와 같은 루트 레벨에 있어야 합니다(구독이 한 파일에 합쳐 넣는 방식이면 프로필 전체를 한 눈에 보세요). 항목 이름(예: reject, myrules)은 아래 예시처럼 키로 두고, 그 아래에 type·url 등을 둡니다.

YAMLrule-providers:
  my-remote-set:
    type: http
    behavior: classical
    url: "https://example.com/path/to/ruleset.yaml"
    path: "./rulesets/my-remote-set.yaml"
    interval: 86400

rules:
  - RULE-SET,my-remote-set,Proxy
  - MATCH,Proxy

behavior는 classical·domain·ipcidr 등 커널이 기대하는 형식과 받은 파일이 맞아야 합니다. 잘못 지정하면 파싱은 되지만 매칭이 이상하거나, 아예 읽기 단계에서 오류가 날 수 있으니 규칙 소스가 어떤 스키마인지(주석·문서)를 함께 확인하십시오.

원격 url: remote rule이 안 받아질 때

type: http인 경우 url이 사실상 전부입니다. 여기서 자주 터지는 원인은 다음과 같습니다.

  • URL 오타 또는 http ↔ https 혼동. 리다이렉트가 끊기면 일부 환경에서 실패로 남습니다.
  • 403·401: 저장소·CDN이 User-Agent나 Referer를 요구하거나, 비공개 Raw 링크가 만료된 경우입니다. 브라우저에서는 열리는데 커널에서만 막힌다면 이 축을 의심하십시오.
  • TLS 인증서 문제: 잘못된 중간 인증서, 기업 MITM, 시스템 신뢰 저장소가 다른 경우(특히 일부 임베디드)입니다.
  • 지역·IP 제한: 원문 서버가 특정 국가만 허용하는 경우, 프록시 노드를 바꾸기 전에 직접 다운로드가 되는지 먼저 구분하십시오.

우회용 클라이언트라도 rule provider 자체를 받을 때는 시스템 DNS·직접 경로로 먼저 붙는 경우가 있어, “노드는 잘 쓰는데 규칙 URL만 막힌다”는 패턴이 나올 수 있습니다. 이 때는 다른 네트워크에서 같은 url을 curl로 받아 보거나, 미러·로컬 mirror 파일로 바꾸는 현실적 대안을 고려할 수 있습니다.

로컬 path: 캐시가 쓰는 PATH 이해하기

path는 다운로드한 규칙 세트를 디스크에 쓰는 위치입니다. 상대 경로(예: ./rulesets/x.yaml)는 프로필(구독)이 열리는 기준 디렉터리에 따라 달라지므로, OS마다 Clash·GUI가 쓰는 작업 폴더를 한 번은 확인하는 것이 좋습니다. 잘못 잡으면 쓰기 권한 없음, 경로 중복(서로 다른 provider가 같은 파일명), 상대 depth 오산이 납니다.

절대 경로를 허용하는 빌드도 있으나, 이식성을 위해 사용자 홈 기준으로 통일하거나, GUI가 제안하는 기본 ruleset 폴더를 따르는 편이 안전합니다. 갱신 실패가 아니라 재시작 후에만 비는 경우, 백그라운드에 남은 잠금 파일·백신이 폴더를 지웠는지도 함께 보십시오.

interval(갱신 주기)이 의미하는 것

interval은 초 단위로, 백그라운드에서 규칙을 다시 받을 최소 간격을 둡니다. 86400이면 대략 하루 한 번입니다. 0이거나 아주 짧으면(구현에 따라) 매 재시작·매 요청에 가깝게 당겨 서버 부하나 rate limit에 걸릴 수 있어, 공개 링크를 쓰는 경우 특히 위험합니다. 반대로 너무 길면 막 업데이트된 목록이 반영되지 않아 “Rule Provider 업데이트 실패가 아닌데도 옛 DOMAIN이 남는” 착시가 생깁니다.

GUI의 “지금 provider 갱신” 버튼이 있다면, interval을 기다리지 않고 수동으로 한 번 밀어 넣을 수 있으니, 최초 설치 직후는 수동 갱신으로 캐시를 채웠는지 확인하는 것이 좋습니다.

rules: 쪽에서 막히는 경우

provider는 정상인데도 트래픽이 이상하다면 rules:에서 RULE-SET,이름,정책의 철자와 순서를 보십시오. 이름이 rule-providers 키와 완전히 동일해야 합니다. 그리고 GEOIP·MATCH가 위에 있어 요청이 먼저 소진되면, 아래에 둔 RULE-SET은 실행되지 않습니다. 이 전체 흐름은 규칙 분할 글의 “첫 일치” 절과 같이 읽으면 연결됩니다.

로그로 좁히기: 찾을 키워드

대부분의 Clash·Mihomo 계열은 로그에 rule provider·fetch·cache·parse·HTTP 상태코드·TLS 관련 힌트를 남깁니다. 아래 흐름으로 보십시오.

  1. 다운로드 단계: 타임아웃, DNS 실패, 403, TLS handshake 실패 — url·네트워크·DNS 쪽.
  2. 저장 단계: permission denied, no space — path·디스크·권한.
  3. 파싱 단계: invalid yaml, unexpected key — 다운로드한 파일이 JSON이어야 하거나, 인코딩·주석·상단 프리앰블이 끼어 있지 않은지 확인.

로그 수준이 info 이상일 때 provider 관련 한 줄이 보이는 경우가 많으니, 트러블슈팅 직전에만 debug로 올리고, 원인이 좁혀지면 다시 낮추는 것이 로그 민감도에 좋습니다.

보안: 알 수 없는 remote rule

Rule Provider URL은 실행 코드가 아닌 텍스트 규칙이지만, 악의적인 목록이면 REJECT 남용·잘못된 Proxy로의 유도가 가능합니다. 출처를 알고 있는지, 커뮤니티에서 널리 쓰이는지, 가능하면 파일 내용을 샘플로 읽어 보는 습관을 권장합니다. 오픈소스 GitHub 저장소의 Issue·Release 노트는 신뢰도를 가늠하는 데 도움이 됩니다(단, 클라이언트 설치 패키지는 반드시 이 사이트의 다운로드 페이지를 우선하십시오).

구독·프로필과의 관계

일부 구독 URL은 정적 YAML 전체를 내려주며, 그 안에 이미 rule-providers가 들어 있습니다. 이때 로컬에 덮어쓴 파일과 원격이 다시 당겨온 내용이 충돌하지 않는지(동기화 시 덮어쓰기)를 GUI의 “구독 갱신” 동작과 함께 이해하는 것이 좋습니다. 구독 흐름은 구독 가져오기 가이드와 겹치므로, 로컬 편집과 자동 갱신을 어떤 순서로 쓰는지 먼저 정리해 두십시오.

요약 체크리스트

  • rule-providers 키와 RULE-SET의 이름이 일치하는가.
  • url이 브라우저뿐 아니라 커널이 직접 받을 수 있는가(403, 리다이렉트, UA).
  • path가 쓰기 가능하며, 다른 provider와 충돌하지 않는가.
  • interval이 너무 짧거나 길지 않은가; 수동 갱신으로 캐시를 채웠는가.
  • rules: 상단에 넓은 GEOIP·MATCH가 RULE-SET을 가리지 않는가.

마무리

Rule Provider는 한 줄짜리 RULE-SET보다 앞 단계에 있는 인프라입니다. URL·PATH·interval·YAML이 맞지 않으면 어떤 정교한 remote rule도 엔진에 올라오지 못하고, 갱신 실패는 대개 이 네 가지와 로그 키워드로 설명됩니다. 다른 도구와 달리 Clash·Mihomo는 규칙을 직접 읽는 구조라, 공급망이 안정돼야 비로소 TUN·분할 정책이 의도대로 보입니다.

클라이언트는 아직 설치하지 않았다면 Clash를 무료로 내려받아 설치한 뒤, 구독이 넣어 준 rule-providers를 그대로 두고 URL 한 줄과 path만 위 체크리스트로 점검해 보는 것만으로도 “갱신만 안 된다” 류의 문제는 상당 부분 정리됩니다. 안정성과 규칙 제어 측면에서 한 번 쓰기 시작하면 꽤 오래 쓰게 되는 편입니다.