Windows 가이드 · · 약 15분 소요

Clash Meta rule-providers와 GEOIP 갱신이 실패할 때: mihomo 로그로 URL·경로·권한을 점검하기 (2026)

Clash Meta 계열 코어(mihomo)는 프로필 안의 rule-providers로 외부 규칙 세트를 받아 오고, GEOIP·geodata 파일로 지리 기반 분기를 합니다. 이 둘을 자동으로 갱신하도록 켜 두면 편하지만, 다운로드 실패·경로 없음·권한 거부 같은 메시지가 반복되거나, 파일은 받았는데도 규칙이 안 먹는 것처럼 보일 수 있습니다. 이 글은 로그에서 원인을 URL·TLS·DNS인지, 캐시 경로·홈 디렉터리인지, 파일 권한인지, 아니면 설정 키 누락인지로 나눈 뒤 고치는 순서를 정리합니다. 구독 URL 쪽 TLS·DNS·로그 루틴은 Windows 구독 갱신·TLS·DNS 글과 겹치니 같이 두면 빠르고, 규칙 순서·GEOIP와의 관계는 고급 라우팅 가이드를 참고하세요.

1. 증상: 갱신 실패·규칙 미적용·GEOIP 만료

흔한 표현은 다음과 같이 갈립니다. GUI에 「규칙 제공자 갱신 실패」「provider update failed」류 알림이 뜨거나, 로그에 HTTP 상태 코드·TLS 오류·타임아웃이 찍힙니다. 반대로 갱신은 성공한 것처럼 보이는데 RULE-SET이 비어 있거나 예전 스냅샷만 남아 도메인 분기가 기대와 다릅니다. GEOIP는 버전이 오래돼 국내·해외 판정이 어긋나거나, 아예 mmdb·dat 파일을 찾지 못해 규칙 엔진이 해당 줄을 건너뛰는 경우도 있습니다.

중요한 점은 「규칙 파일이 틀렸다」만 보지 말고, 먼저 리소스가 최신·유효한 경로에 있는지를 확인하는 것입니다. HTTPS 스니퍼·SNI 이슈로 도메인이 안 보이는 경우와 섞이면 더 헷갈리는데, 그때는 Sniffer·SNI 로그 글의 순서와 병행하는 편이 안전합니다.

2. rule-providers·GEOIP가 mihomo에서 어떻게 갱신되나

rule-providers는 보통 원격 URL에서 텍스트·규칙 세트를 받아 로컬 캐시에 저장한 뒤, 메모리에 로드합니다. 주기는 interval 등으로 정하며, 코어 시작 시와 주기적 백그라운드 작업이 겹칩니다. GEOIP·국가 데이터는 geodata 모드 설정에 따라 MaxMind 형식 .mmdb나 레거시 .dat 계열을 쓰며, 별도 geoip·geosite 다운로드 URL이나 내장 경로가 프로필에 박혀 있습니다.

즉 실패 지점은 (가) 네트워크로 원본을 못 가져오거나, (나) 가져왔는데 디스크에 쓰지 못하거나, (다) 쓴 위치와 런타임이 읽는 위치가 다르거나, (라) 파일은 있는데 규칙 배열 순서·GEOIP 행보다 위쪽 다른 규칙이 먼저 매칭되는 경우로 나뉩니다. 이 글은 (가)~(나)~(다)에 초점을 맞추고, (라)는 라우팅 문서로 넘깁니다.

3. 로그에서 먼저 찾을 키워드

먼저 로그 레벨을 debug 또는 info로 올린 뒤, provider·rule·fetch·download·geoip·geodata 같은 단어로 필터링해 보세요. permission denied·no such file·cannot create이면 경로·권한 쪽으로 무게를 둡니다. TLS handshake·x509·certificate면 구독 글과 같은 TLS·회사망 검사 이슈를 의심합니다. 403·429·503이면 원본 서버·CDN 정책·레이트 리밋이 원인일 수 있습니다.

로그에 찍힌 절대 경로 한 줄을 그대로 복사해 파일 탐색기나 터미널에서 존재 여부를 확인하세요. GUI가 표시하는 「홈」과 실제 코어 프로세스의 작업 디렉터리가 다르면, 사용자는 맞는 경로를 보고 있어도 코어는 다른 곳에 쓰고 있는 상황이 나옵니다.

# Example YAML shape (names only; adapt to your profile)
rule-providers:
  community:
    type: http
    behavior: classical
    url: "https://example.com/rules.yaml"
    path: ./ruleset/community.yaml
    interval: 86400

위에서 path는 상대 경로일 때 코어의 기준 디렉터리에 붙습니다. 기대와 다른 폴더에 쓰이면 「갱신은 됐는데 파일이 안 보인다」가 됩니다.

4. URL·TLS·DNS·프록시 출구 분기

규칙 세트·GEOIP 다운로드도 결국 HTTPS 요청입니다. DNS가 잘못 해석되면 엉뚱한 IP로 붙고, 회사망 SSL 검사가 끼면 코어만 인증서 검증에 실패할 수 있습니다. 브라우저는 되는데 코어만 실패하면 구독 갱신 글의 DNS·TLS 분기를 그대로 이어 붙이면 됩니다. 다만 규칙 URL이 GitHub Raw·jsDelivr 같은 미러를 쓰는 경우, 특정 지역에서만 막히거나 속도 제한이 걸리기도 하니, 로그의 최종 URL과 상태 코드를 확인한 뒤 미러를 바꾸는 것이 안전합니다.

규칙 모드에서 provider 요청이 의도와 다른 아웃바운드로 나가면, 노드 측에서 TLS가 깨지거나 느려질 수 있습니다. 로그에 찍힌 다이얼 경로가 DIRECT인지 PROXY인지 먼저 맞추고, 테스트용으로 해당 도메인만 DIRECT로 고정해 보는 방법도 있습니다. 다운로드 전용 트래픽만 분리하는 전략은 보안 정책과 충돌하지 않는 범위에서 선택하세요.

5. 경로: 홈 디렉터리·캐시·상대 경로

rule-providerspath는 상대 경로일 때 코어가 사용하는 작업 디렉터리 또는 프로필 디렉터리를 기준으로 해석됩니다. Clash Verge Rev 등은 사용자별 데이터 폴더가 분리되어 있어, 예전에 수동으로 편집한 경로와 실제 실행 경로가 어긋나기 쉽습니다. 로그에 open file 오류가 나오면 그 줄의 경로를 기준으로 맞추고, 가능하면 ./ 대신 GUI가 보여 주는 절대 경로로 통일해 두면 재발을 줄일 수 있습니다.

GEOIP·geosite 파일은 용량이 커서, 첫 실행 시 다운로드에 시간이 걸리거나 디스크 부족으로 중간에 끊길 수 있습니다. SSD 절약을 위해 다른 드라이브로 옮겼다면, 프로필의 geodata 경로 설정이 그 위치를 가리키는지 다시 확인해야 합니다. 여러 프로필을 오가며 테스트할 때는 각 프로필이 별도 캐시를 쓰는지, 아니면 공용 폴더를 공유하는지에 따라 「한쪽만 갱신됐다」는 착시가 납니다.

한 줄 정리

로그에 찍힌 절대 경로가 곧 진실에 가깝습니다. GUI에 보이는 경로와 다르면 코어 기준 디렉터리부터 다시 맞추세요.

6. 권한·백신·백업 도구와의 충돌

Windows에서는 Program Files 아래에 설정을 두면 일반 사용자 권한으로는 쓰기 실패가 나기 쉽습니다. 코어를 관리자 권한으로만 올리면 해결되는 것처럼 보여도, 실제로는 데이터 폴더를 사용자 쓰기 가능한 위치로 옮기는 편이 정석입니다. 백신·랜섬웨어 방어가 특정 폴더의 빈번한 덮어쓰기를 막으면, 갱신 직후 파일이 잠깐 사라지거나 잠겨 provider 파싱이 실패하는 경우도 있습니다.

클라우드 동기화 도구(OneDrive 등)가 사용자 디렉터리 전체를 감싸고 있으면, 동기화 중인 파일에 코어가 잠금을 걸다 충돌을 일으키기도 합니다. 규칙 캐시·mmdb 폴더를 동기화 제외하거나, 데이터 루트를 동기화 밖으로 옮기는 것을 권장합니다. 읽기 전용 플래그가 붙은 파일이나 상위 폴더에도 실패 원인이 남습니다.

7. 설정 키 점검: interval·geoip·geodata

rule-providers마다 interval이 너무 짧으면 원본과 429·차단을 유발할 수 있고, 너무 길면 「갱신이 안 된다」는 느낌이 듭니다. 운영 목적에 맞게 하루 한 번 이상 정도로 조정하는 경우가 많습니다. GEOIPgeodata-mode·geoip·geox-url 등 프로필 키 이름이 버전·문서에 따라 조금씩 다를 수 있으니, 사용 중인 mihomo 버전의 공식 문서와 샘플을 기준으로 맞추는 것이 안전합니다.

규칙 세트는 behavior(classical·domain 등)에 따라 파서가 다릅니다. 잘못된 타입으로 받으면 다운로드는 성공했는데 파싱 단계에서 버려지는 일이 생깁니다. 로그에 parse·format 오류가 나오면 원본 형식과 behavior 조합을 의심하세요. GEOIP 규칙이 동작하려면 최소한 해당 mmdb·dat가 로드되어 있어야 하며, 버전이 오래되면 실제 IP 대역과 불일치해 「규칙이 이상하다」로 보일 수 있습니다.

규칙 순서·GEOIP·MATCH 관계는 라우팅 가이드의 설명대로, 넓은 조건이 위에 있으면 세부 규칙 세트를 아래에 깔아도 도달하지 못합니다. 이 글에서 리소스 갱신·경로를 고친 뒤에도 분기가 이상하면, 그 다음 단계는 규칙 순서 점검입니다.

8. 한 번에 적는 수정 체크리스트

(1) 로그 레벨을 올리고 갱신을 한 번 재현한다. (2) provider·geoip 관련 줄에서 URL·경로·HTTP 코드를 확인한다. (3) DNS·TLS·아웃바운드가 구독 갱신과 같은지 비교한다. (4) 로그의 절대 경로에 파일이 실제로 존재하는지, 크기가 0이 아닌지 본다. (5) 쓰기 권한·백신·동기화 충돌을 제거한다. (6) interval·미러·geodata 키를 문서와 맞춘다. (7) 그다음에야 규칙 순서·스니퍼·SNI를 의심한다.

이 순서를 지키면 「rule-providers 갱신 실패」와 「GEOIP가 안 맞는다」는 증상을 한 번에 감으로만 때리지 않고, mihomo 로그에 기반해 재현 가능한 범위로 좁힐 수 있습니다. Clash Meta 계열은 규칙·지리 데이터가 분리·캐시되는 구조라, 경로와 권한만 맞아도 반복되는 미스터리가 크게 줄어듭니다.

네트워크 쪽 의심

TLS·DNS·403/429·다른 아웃바운드로 나가는 경우. 구독 글의 분기와 동일하게 보면 됩니다.

디스크·권한 의심

permission denied·경로 없음·동기화·백신 잠금. 로그의 절대 경로를 기준으로 맞춥니다.

보안: 규칙·GEOIP URL은 신뢰할 수 있는 소스만 사용하세요. 인증서 검증을 끄는 우회는 최후의 수단으로만 제한적으로 고려해야 합니다.

정리하면, Clash Meta·mihomo에서 rule-providersGEOIP 자동 갱신은 구독과 마찬가지로 로그에 단계가 남습니다. URL·TLS·DNS 문제인지, 캐시 경로·상대 경로 해석 문제인지, 파일 권한·백신·동기화 문제인지를 가른 뒤 설정을 맞추면, 규칙 세트가 비어 있거나 지리 DB만 오래된 상태로 남는 일을 크게 줄일 수 있습니다. 상용 VPN 앱처럼 블랙박스가 아니라 규칙과 데이터가 명시적으로 보이는 구조라, 한 번 흐름을 잡아 두면 이후 튜닝이 훨씬 수월합니다.

Clash를 무료로 내려받아 최신 클라이언트로 설치한 뒤, 이 글의 순서대로 로그를 열고 규칙·GEOIP 갱신을 다시 시도해 보세요.

주제 관련도가 높은 읽을거리 — 같은 카테고리의 Clash 실전 가이드.