⚙️ 설정 ⏱ 약 19분 분량

Windows 11에서 Clash Verge Rev rule-providers(규칙 제공기) 자동 갱신 간격(interval)과 캐시 경로(path) 맞추기: 실패 재시도·GEO와의 리듬까지 (2026)

이미 YAML 안에 rule-providers로 규칙 파일을 끌어오기 시작한 사람이 보통 다음을 검색합니다. 얼마나 자주 새로 받는지, 실패하면 언제 다시 시도하는지, 캐시는 어디에 저장되는지·옮길 수 있는지, 그리고 구독 전체 갱신이나 GEOIP·GeoSite 갱신이랑 주기를 어떻게 맞출지요. 이 글은 데스크톱용 Clash Verge Rev가 깐 Mihomo(Clash Meta) 코어 관점에서 그 축만 분리해 설명합니다. 원격 구독 URL 타이머 자체는 Clash Verge Rev 구독 자동 업데이트 간격 글과 역할을 나눕니다.

검색 의도를 한 줄로 정리하면

rule-providers는 「긴 rules 목록을 URL이나 파일로 모듈화해 두고, 코어가 주기적으로 받아서 RULE-SET 한 줄로 묶는 장치」에 가깝습니다. 사용자 입장에서 궁금한 것은 기능 이름이 아니라 실제 운영 값입니다. 몇 초·몇 시간마다 네트워크를 두드리는지, 끊겼을 때 마지막 성공본을 쓰는지, 디스크에 어떤 이름으로 남는지, 그리고 공항 구독이 한꺼번에 갱신될 때 규칙셋만 따로 느리게 돌려도 되는지입니다.

Windows 11에서는 탐색기·작업 관리자·로그 패널을 같이 쓰면 추측이 줄어듭니다. 특히 회사망이나 밤 시간대에만 터널이 열리는 환경이라면 「짧은 interval로 실패 로그만 양산」하는 패턴보다, 「조금 긴 주기 + 필요할 때만 수동 새로 받기」가 체력 소모가 적은 경우가 많습니다.

구독 갱신과 rule-providers 갱신은 별도 타이머다

Clash Verge Rev 화면에서 구독 카드에 있는 자동 업데이트 숫자를 바꿨다고 해서, 깊은 곳의 rule-providers.interval까지 자동으로 따라오지는 않는 경우가 대부분입니다. 둘 다 「원격에서 파일을 당긴다」는 점은 같지만, 대상 파일과 파서가 다릅니다. 구독이 새 노드 목록과 긴 설정 꼬리를 통째로 가져올 때, rule-provider는 붙어 있는 단일 규칙셋만 부분 갱신하는 그림으로 이해하면 헷갈림이 재료됩니다.

실무 팁은 표를 만드는 것입니다. 프로필마다 (1) 구독 간격 분·시간, (2) 각 rule-provider 이름과 interval 초, (3) 수동으로만 당기고 싶은 예외 URL을 한 줄 메모해 두면, 나중에 「어느 쪽이 429를 냈는지」를 역추적하기 쉬워집니다. 구독 쪽 운영 패턴은 앞서 링크한 구독 자동 갱신 글의 실패·레이트 제한 절과 그대로 합쳐서 읽으면 좋습니다.

interval은 보통 「초」 단위 정수로 읽는다

Mihomo 계열에서 rule-providers의 interval은 흔히 초 단위 양의 정수로 해석됩니다. 예를 들어 하루 한 번이면 86400, 한 시간이면 3600처럼 환산해 두면 문서·커뮤니티 답변을 읽을 때도 속도가 납니다. 흔한 실수는 분 단위로 착각하는 것인데, 그 경우 숫자가 한 자릿수만 달라도 실제 네트워크 빈도가 열 배로 흔들립니다.

너무 짧게 두면 제공자 CDN이나 자체 미러에 부담이 가고, 동일 목록을 여러 PC가 공유할 때 HTTP 429나 짧은 재시도 루프가 보일 수 있습니다. 반대로 며칠 이상으로 늘리면 사이트 리스트가 하루 만에 바뀌는 서비스를 쓸 때 체감이 굳습니다. 「정답 숫자」는 없고, 로그에 남는 마지막 성공 시각과 업무에 필요한 최신도 사이에서 타협합니다.

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

위는 개념 예시입니다. behavior나 파일 확장자, 원격 서버가 주는 실제 형식은 사용 중인 코어 버전과 규칙 제공자 문서에 맞춰야 하며, 잘못 고르면 조용히 비어 있는 RULE-SET처럼 보이기도 합니다. 문법 전체의 뼈대는 Clash 입문 튜토리얼에서 프로필 구조를 먼저 잡은 뒤 이 절을 적용하는 편이 안전합니다.

path는 「캐시 파일 이름 + 상대 위치」를 고정하는 스위치다

path 필드는 원격에서 받은 규칙셋을 어떤 로컬 파일 이름으로 저장·재사용할지 정합니다. 상대 경로를 쓰면 기준점은 보통 앱이 프로필을 풀어 두는 작업 디렉터리 쪽이라, Clash Verge Rev에서는 설정 화면에서 프로필 폴더를 연 뒤 실제 트리를 따라가 보면 빠릅니다. 여러 프로필을 오간다면 동일 path 문자열이 어느 프로필 폴더에 중복으로 생기는지도 함께 확인합니다.

Windows 11에서 백업을 떠 났다가 복원할 때는 「프로필 YAML만」 옮기고 path 아래 실 파일을 빼먹으면 첫 부팅에 다시 원격을 긁는 패턴이 됩니다. 반대로 캐시를 통째로 복사해 오면 네트워크 없이도 이전 상태로 빨리 올라오니, 노트북을 포맷할 때 어떤 하위 폴더를 tarball에 넣을지 미리 팀 규칙으로 정해 두면 재난 복구가 단순해집니다.

💡 핵심 path를 바꾸면 사실상 새 파일 슬롯을 만드는 것과 같습니다. 이름만 살짝 바꿨는데 디스크에 예전 파일이 남아 용량을 먹는다면, 정말 필요한 캐시인지 한 번 정리해 보세요.

실패·오프라인일 때 기대할 수 있는 동작

대부분의 상황에서 네트워크 다운로드가 한 번이라도 성공해 디스크에 남아 있다면, 이후 요청이 실패해도 그 캐시를 읽어 계속 매칭을 수행하는 편이 자연스럽습니다. 사용자가 느끼기에 「규칙이 갑자기 통째로 사라졌다」기보다 「어제 받아 둔 목록이 하루 더 남아 있다」에 가깝습니다. 문제는 제공자가 형식을 바꿨거나 파일이 반만 쓰인 상태로 끊긴 경우인데, 이때는 로그의 파싱 오류와 파일 크기·타임스탬프를 같이 봐야 합니다.

자동 재시도는 친절하게 버튼 이름으로 드러나지 않을 때가 많고, 사실상 「다음 interval 주기가 돌아올 때 다시 시도」 + 「UI에서 해당 항목을 수동으로 새로 받기」 조합으로 운영합니다. 급한 날에는 간격을 잠깐 줄였다가 안정되면 다시 늘리는 식의 일시적 조정도 흔합니다. 연결 시간 초과 패턴 자체를 로그에서 익히고 싶다면 Windows 11 로그·타임아웃 진단 순서를 같이 밟아 두면 좋습니다.

GEOIP·GeoSite 갱신과 주기를 맞출 때

GEOIP류 규칙은 「국가 코드로 잡는」 데이터베이스 파일 자체가 따로 있고, 그 파일의 버전이 오래되면 rule-providers가 아무리 최신이어도 최종 판정이 어긋납니다. 운영 습관으로는 (1) 규칙셋 URL 갱신, (2) GEO 데이터베이스 갱신, (3) 공항 구독 전체 갱신을 서로 다른 줄에 적어 두고, 모두 같은 분에 몰리지 않게 미세하게 어긋나게 두는 편이 디버깅에 유리합니다.

한꺼번에 세 축이 동시에 돌면 회사 프록시나 제공자 쪽에서 짧은 시간 안에 많은 TLS 세션이 열려 일시적인 실패가 겹치기 쉽습니다. 반대로 한 축만 느리면 「노드는 새 건데 국가 판정만 옛날」 같은 부조화가 나오므로, 증상이 나온 날의 로그 타임스탬프를 기준으로 어느 리소스가 갱신됐는지부터 역추적합니다.

GUI 없이 YAML만 손대는 경우

Mixin이나 프로필 편집기에서 rule-providers 조각만 얹는 패턴이면, 원격 구독이 통째로 덮어쓸 때 interval 숫자가 원복되는지 여부가 쟁점입니다. 이때는 베이스 YAML과 로컬 오버라이드의 병합 순서를 빌드 문서에 맞춰 다시 읽어야 합니다. 큰 그림은 Windows 11 Mixin·프로필 오버라이드 글과 같이 보시면「어느 층의 숫자가 최종적으로 살아 남는지」가 선명해집니다.

팀 저장소에 규칙셋을 올려 GitHub raw URL로 당기는 경우, 커밋이 잦으면 interval을 길게 잡고 릴리스 태그만 수동으로 갱신하는 편이 레이트 제한에 무난합니다. 반대로 LAN 내부 미러를 쓰면 짧은 주기도 부담이 적습니다. 같은 문장이라도 네트워크 위치에 따라 최적값이 달라진다는 점만 기억하면 됩니다.

rules 순서와 RULE-SET 연결을 잊지 말 것

rule-providers만 선언해 두고 rules 본문에 RULE-SET 줄을 빠뜨리면 아무 일도 일어나지 않습니다. 또 RULE-SET 줄이 있어도 위치가 너무 아래면 이미 GEOIP나 MATCH에 걸려 버립니다. 디버깅할 때는 연결 로그에서 실제 매칭된 규칙 이름을 확인하고, 필요하면 한 칸씩 위로 올려 재현해 보세요.

이 흐름을 넓게 잡고 싶다면 사용자 정의 규칙 튜토리얼의 순서 설명과 함께 읽으면 첫 매칭 승리 감각이 빨리 잡힙니다. 프록시 그룹 문자열만 어긋나도 같은 증상이 나오니 프록시 그룹 가이드도 짧게 훑는 것을 권합니다.

실측 체크리스트(Windows 11)

  1. 활성 프로필에서 rule-providers 이름·url·interval·path를 메모한다.
  2. 탐색기로 path가 가리키는 파일이 실제로 생겼는지, 수정 시각이 기대와 맞는지 본다.
  3. UI나 메뉴에서 해당 규칙셋을 수동으로 새로 받기 한 뒤 로그에 오류가 없는지 본다.
  4. 의도적으로 비행기 모드를 켜 동일 파일이 계속 읽히는지, 재시작 후에도 매칭이 유지되는지 확인한다.
  5. GEOIP 관련 DB 갱신 주기를 별도로 확인하고, 필요하면 구독·규칙셋 타이머와 어긋나게 조정한다.

한 번에 다섯 단계를 바꾸면 어디가 원인인지 다시 감이 안 옵니다. 새 숫자를 넣을 때는 하루에 한 축만 조정하는 습관이 시간을 아깁니다.

보안·유지보수 관점의 짧은 메모

외부 규칙 URL은 누가 편집하느냐에 따라 하룻밤 사이에 범위가 넓어질 수 있습니다. 신뢰할 수 있는 출처인지, 원문을 diffs로 볼 수 있는지, 팀 내 코드 리뷰가 가능한지부터 고르는 편이 안전합니다. 로컬 path에 민감한 내부 도메인이 들어 있다면 백업 ZIP을 공유할 때 포함 여부도 확인하세요.

이 글은 특정 공항·노드 판매자를 전제로 하지 않으며, 각 제공자의 허용 사용 범위·토큰 유효기간은 공지를 우선합니다.

자주 묻는 질문

interval을 0으로 두면 매 패킷마다 받나요?

코어 버전에 따라 해석이 다르거나 무시될 수 있어 문서 확인이 필요합니다. 실측 없이 극단값을 넣기보다, 로그로 실제 요청 간격을 본 뒤 조정하는 편이 안전합니다.

규칙 파일을 수동으로 교체했는데 날아갔어요.

다음 자동 갱신에 원격 내용이 덮어쓴 경우가 많습니다. 영구적인 로컬 수정이라면 별도 파일 이름과 provider 항목을 새로 파거나, 원격 URL 대신 file 스키마를 검토하세요.

노트북만 짧은 interval을 쓰고 싶어요.

프로필을 분리하거나 Mixin에서 조건부로 숫자를 바꾸려 해도 결국 YAML이 두 벌 필요해질 수 있습니다. 운영 비용이 낮은 쪽을 고르세요.

정리

Windows 11에서 Clash Verge Rev로 rule-providers를 쓸 때 기억할 핵심은 세 덩어리입니다. 첫째, interval은 보통 초로 읽고 구독 갱신과 별도입니다. 둘째, path는 캐시 파일 위치를 고정하므로 백업·복원 시 같이 다뤄야 합니다. 셋째, 실패 시에는 이전 캐시가 버티는 경우가 많고, GEOIP 데이터베이스 갱신은 또 다른 축입니다.

반면 일부 전통적인 단일 토글형 프록시 앱은 내부에서 규칙셋·데이터베이스 버전을 거의 숨겨, 처음에는 편하지만 「내가 언제 어떤 파일을 받았는지」를 사용자가 통제하기 어렵습니다. Clash·Mihomo 계열은 YAML에 근거를 남기고 로그로 검증하기 쉬워, 회사망·스크립트 자동화·팀 표준처럼 갱신 주기를 설명해야 할 때 유리합니다. 배포 경로를 정리해 클라이언트를 고르고 싶다면 Clash 다운로드 페이지에서 호환 빌드를 확인한 뒤 설치해 보세요.

보안 공지와 패키지 무결성 안내를 함께 보고 싶다면 Clash 받기 안내로 이동해 주세요.