1. Windows에서 원격 규칙셋을 rule-providers로 자동 유지해야 할 때

패널 구독 한 줄이 proxies와 proxy-groups까지는 잘 채워 주어도, 지역·서비스별 분기 규칙은 외부 프로젝트가 만든 텍스트 파일로 갱신하는 경우가 많습니다. 예전에는 수동규칙 붙여넣기로 일했지만, 엔진이 Mihomo(Clash Meta) 계열이면 rule-providers로 원격 소스를 등록하고 interval만큼 시간이 지날 때마다 다시 받아 오는 흐름이 표준에 가깝습니다. Clash Verge Rev는 그 코어를 감싼 클라이언트이므로, 설정의 진실은 결국 활성 프로필 YAML 한 장 안에 모입니다.

윈도 사용자가 혼동하기 쉬운 지점은「구독 새로고침 버튼」과「규칙셋 rule-providers 갱신」이 같은 타이밍이 아니라는 것입니다. 구독 URL은 노드 목록·템플릿 전체를 갈아끼우고, rule-providers는 이름 붙인 소스 하나씩의 로컬 캐시를 따로 관리합니다. 둘 중 하나만 돌아가면「노드는 새 것인데 구 사이트가 계속 직행한다」같은 증상이 나옵니다. 이 글에서는 두 경로가 겹치지 않게 검증 순서까지 적어 두었습니다.

2. 용어 정리: rule-providers, interval, RULE-SET

rule-providers는 YAML 최상위 블록으로, 각 항목이 type·원본 위치·로컬 path·갱신 주기 interval 등을 가집니다. 원격 파일은 보통 http 또는 https로 받으며, 내장 포맷은 규칙 텍스트(classical·yaml 등 코어가 해석 가능한 형식)여야 합니다. interval은「다음 자동 재다운로드까지 기다릴 최소 간격」에 가깝게 이해하면 됩니다. 수치는 환경마다 다르지만, 초 단위 정수로 두는 예가 대부분이며, 너무 짧게 잡으면 공개 미러 입장에서도 부담이 되고 로그만 잦아질 수 있습니다.

rules 안에서는 RULE-SET 타입 한 줄이 위에서 정의한 공급자 이름을 가리킵니다. 사용자가 패널에서 보는 규칙셋이란 말과 영문 RULE-SET은 같은 축입니다. 이름 대소문자를 바꾸면「정의는 있는데 매칭 줄이 안 탄다」로 이어지므로, 복사·붙여넣기 할 때 한 번 더 눈으로 교차 확인하는 습관이 필요합니다.

💡

영문 검색·이슈를 볼 때는 설정 파일에 적힌 그대로 rule-providers, RULE-SET, interval를 검색어에 넣으면 Mihomo 문서와 맞물립니다.

3. YAML에 rule-providers 블록 넣기 (예시)

아래는 설명용 축약 예시입니다. 실제 프로필에는 이미 proxies와 긴 rules가 있을 것이므로, 블록을 기존 키와 충돌 없는 위치에 끼워 넣습니다. URL과 파일 이름은 본인이 신뢰하는 소스로 바꿉니다.

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

  streaming:
    type: http
    behavior: classical
    url: "https://example.com/rules/stream.yaml"
    path: ./ruleset/stream.yaml
    interval: 43200

path는 로컬 캐시 파일입니다. 여러 공급자가 같은 경로를 쓰면 마지막에 쓴 쪽이 이전 내용을 덮어 분류가 꼬이므로, 항목마다 서로 다른 파일 이름을 주는 것이 안전합니다. behavior는 파일 포맷·파서 종류와 맞아야 하며, 제공자 문서가 권장하는 값을 따릅니다. 처음에는 공급자 예제를 그대로 복사하고, 안정화 뒤에만 interval을 조정하는 편이 실수가 적습니다.

rules: 목록은 위에서 아래로 평가됩니다. 고정적으로 먼저 타야 할 MATCH나 짧은 커스텀 줄이 있다면 그 위에 두고, 원격 셋은 그 다음에 두는 식으로 우선순위를 설계합니다. 대표적인 한 줄은 다음과 같습니다.

rules:
  - RULE-SET,streaming,Proxy
  - RULE-SET,reject-domains,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

여기서 streaming·reject-domains는 앞 절 rule-providers 키 이름과 동일해야 합니다. 세 번째 인자는 정책 그룹 이름이며, 정책 그룹·지연 측정 글에서 정리한 proxy-groups 레이블과 맞물립니다. 이름이 어긋나면 코어 기동 실패 또는 조용히 잘못된 그룹으로 붙는 두 가지로 갈라지므로, 저장 전에 스펠링을 다시 읽는 시간을 두면 운영 비용이 줄어듭니다.

⚠️

구독 전체를 덮어쓰는 업데이트가 있다면 사용자 편집이 통째로 날아갈 수 있습니다. 상시 유지할 커스텀 줄은 패치 파일·로컬 병합 또는 제공자가 지원하는 사용자 오버레이 슬롯을 쓰는 편이 안전합니다.

5. interval 현실적으로 잡는 기준

매일 바뀌는 광고·악성 도메인 리스트라면 하루 한 번(86400 초 근처)도 충분한 경우가 많고, 서비스 지역 판별처럼 덜 자주 바뀌는 셋은 그보다 길게 두어도 됩니다. 회사 네트워크나 카페 Wi‑Fi처럼 다운로드가 잦은 환경이 싫다면 interval을 늘리고, 대신 문제가 생겼을 때만 Verge Rev에서 수동으로 해당 프로필을 다시 불러오는 보조 습관을 들이면 됩니다. 반대로 짧게 쓰면 체감 반영은 빨라지지만 배터리·로그·원격 서버 응답 오류에 더 자주 노출됩니다.

Windows Defender나 다른 보안 제품이 새로 받은 캐시 파일 잠금을 잠시 잡는 경우도 있으니, 갱신 직후 규칙이 튀었다면「파일 쓰기 충돌」 가능성도 같이 의심합니다. 이런 때는 코어를 한 번 재시작하거나, 잠깐 긴 간격으로 돌려서 재시도 타이밍을 피하는 식으로 완화할 수 있습니다.

6. Clash Verge Rev에서 저장·재적용하는 화면 순서

빌드마다 메뉴 이름은 조금 달라도 흐름은 비슷합니다. 프로필 선택 → 편집기에서 YAML 저장 → 프로필 다시 적용 또는 코어 재시작입니다. 텍스트만 저장하고 창을 닫으면 UI에는 반영되지 않는 경우가 있으니, 반드시 적용 버튼이나 트레이의 재시작 항목까지 눌러야 합니다. 첫 rule-providers 추가 직후에는 원격 URL이 TLS 오류로 막혀 코어가 기동 실패할 수 있으니, 그때는 로그 카드에 뜬 영문 메시지를 그대로 메모해 두는 것이 이후 검색에 도움이 됩니다.

같은 PC에서 예전 Clash for Windows와 경로 습관이 섞여 있으면 로컬 path 상대 위치를 헷갈리기 쉽습니다. 가능하면 프로필이 있는 디렉터리 기준으로 일관된 하위 폴더만 쓰고, 다른 장비로 복사할 계획이 있다면 절대 드라이브 문자에만 의존하지 않는 구조가 이전이 수월합니다.

7. 체크리스트: 갱신이 실제로 먹었는지 확인

아래를 순서 없이 훑어도 되지만, 번호 순으로 보면 빠르게 원인을 줄일 수 있습니다.

  • 키 이름 일치: rule-providers의 항목 이름과 RULE-SET 두 번째 인자가 정확히 같은지 확인합니다.
  • 원본 URL 응답: 브라우저나 curl로 같은 URL이 200대 본문을 주는지 확인합니다. 리다이렉트 체인이 너무 길면 타임아웃이 잦아질 수 있습니다.
  • 경로 충돌: 서로 다른 공급자가 같은 path 파일을 쓰지 않는지 봅니다.
  • rules 순서: 의도한 RULE-SET 줄이 너무 아래에 있어 앞선 MATCH에서 끝나 버리지 않는지 확인합니다.
  • 정책 그룹 존재: RULE-SET 세 번째 인자로 적은 그룹 이름이 proxy-groups에 실제로 있는지 봅니다.
  • 코어 재적용: 저장 후 재시작·재적용을 건너뛰지 않았는지 확인합니다.

증상이 규칙 매칭이 아니라「조회·증명서」쪽으로 기울면, 같은 시리즈의 DNS 글과 교차 점검하는 편이 빠릅니다. TUN 전체 경로를 다시 정리하고 싶다면 TUN 가이드를 보조로 쓰면 됩니다.

자주 묻는 질문

interval 단위가 헷갈립니다.

문서·커뮤니티 예시를 보면 초로 적는 경우가 대부분입니다. 환경에 따라 허용 범위가 다를 수 있으니, 너무 극단적인 값은 피하고 로그에 경고가 없는지 확인합니다.

RULE-SET 줄이 있는데 효과가 없습니다.

첫 페치가 실패해 캐시가 비었거나, 파일 포맷과 behavior가 맞지 않을 수 있습니다. URL 본문이 기대한 규칙 텍스트인지, 다운로드가 끝난 뒤 로컬 파일 크기가 0은 아닌지부터 봅니다.

구독만 갱신하면 될 줄 알았는데 규칙은 옛날입니다.

노드 목록과 규칙셋은 갱신 경로가 다릅니다. 구독 새로고침 후에도 분기가 이상하면 rule-providers 쪽 interval·수동 재적용을 의심합니다. 공통 패턴은 문제 해결 가이드에도 정리되어 있습니다.

정리하면

Windows Clash Verge Rev에서 규칙셋 자동 갱신을 한 줄로 요약하면 이렇습니다. rule-providers에 원격 소스와 interval을 적고, 서로 다른 path로 캐시를 나누며, rules의 RULE-SET 줄에서 같은 이름과 정책을 맞춘 뒤 저장하고 코어를 다시 적용합니다. 구독 갱신만으로는 부족할 때가 많다는 점, rules 순서가 실제 트래픽 경로를 결정한다는 점만 기억해도 운영 난이도가 많이 내려갑니다.

원클릭 VPN이나 단순 브라우저 확장은 규칙 파일·YAML 편집 없이 쓰기 쉽지만, 한 PC에서 업무·개인·지역 정책을 섞어 쓰기엔 출구가 거의 하나로 고정되는 경우가 많습니다. 반대로 수동으로 규칙 텍스트만 계속 붙여 넣는 방식은 버전이 바뀔 때마다 어느 줄이 최신인지 추적하기 어렵습니다. rule-providers와 interval로 원격 셋을 주기적으로 받게 두면, 엔진이 캐시와 갱신 타이밍을 대신 관리해 주고 패널에서는 정책 이름만 맞추면 됩니다. 이런 구조가 잡힌 Clash 계열 클라이언트는 장기적으로 튜닝 비용이 낮아집니다. 상용 터널 앱에 묶여 출구가 자주 꼬였다면, 규칙 기반 스택을 한 번에 받아 보세요. → 무료로 Clash 계열 클라이언트를 받아 Windows 실사용 규칙셋 주기까지 맞춰 보세요.