Clash Meta(Mihomo) GeoSite·GeoIP 오프라인 경로 설정과 수동 갱신·검증 (2026)

Clash Meta 계열 커널인 Mihomo는 GEOIP·GEOSITE 규칙을 쓰려면 로컬에 지리·도메인 분류용 바이너리 라이브러리가 있어야 합니다. 구독 프리셋은 대부분 원격 RULE-SET과 별개로, 이 ‘Geo’ 계층이 오래되거나 잘못된 경로를 보면 분류가 틀어져 일부 사이트가 프록시로 새거나 직결로 떨어지는 식의 체감 불일치가 납니다. 이 글은 GeoSite·GeoIP 파일을 사용자가 지정한 작업 디렉터리에 두고, 끊긴 망이나 사내 정책처럼 오프라인으로 직접 교체한 뒤 규칙 엔진이 새 DB를 읽었는지 스스로 확인하는 절차에만 초점을 맞춥니다.

GEOIP,CN,DIRECT처럼 ‘어느 국가 코드로 판별되느냐’와 줄의 순서 디버깅은 GEOIP CN·MATCH 순서 문제 해결 글에 따로 정리되어 있으므로 여기서는 중복하지 않습니다. 커널 자체 교체 배경은 Mihomo 마이그레이션 가이드, 규칙 설계 개요는 규칙 분할 가이드를 참고하면 맥락이 부드럽게 이어집니다.

컴플라이언스: 지리 분류 파일은 출처·라이선스(MIT·CC·상표 조항 등)를 확인해야 합니다. 업무 또는 교육기관에서는 프록시·우회 규칙 변경이 허용되지 않았을 수 있으니 해당 정책을 우선 준수하세요.

왜 ‘경로 지정·수동 교체’까지 손대나요?

mihomo 사용자 중 상당수는 geo-auto-update로 주기 받기만 해도 충분합니다. 하지만 다음과 같은 요구에서는 오프라인 mmdb·dat 경로와 파일명을 직접 통제하는 편이 낫습니다. 첫째, 공용 PC나 폐망 테스트 환경처럼 외부 HTTP로 큰 파일을 받을 수 없는 경우입니다. 둘째, 동일 레포 배포판을 모든 단말에 미리 검증하고 내부 미러 디렉터리만 바라보게 하고 싶을 때입니다. 셋째, 자동 업데이트 채널이 일시 장애이거나 회사 차단 때문에 예상치 못한 구버전이 남는 것을 막고 싶을 때입니다.

이때 핵심은 “YAML에 URL만 있으면 끝”이 아니라 실제로 커널 프로세스가 어느 폴더의 어떤 파일명을 열었는지를 일치시키는 일입니다. GUI 클라이언트(Verge·Stash·CFW 포크 등)는 홈 경로를 자체적으로 감싸므로, 터미널에서 직접 mihomo -d /path로 돌릴 때와 기본 검색 위치가 다를 수 있습니다. 한 번 경로를 찾아 두면 이후 수동 갱신은 ‘덮어쓰기·리로드’ 두 동작으로 줄어듭니다.

GeoSite·GeoIP가 가리키는 파일 형식 이해하기

Mihomo 문맥에서 흔히 마주치는 조합은 (1) 도메인 태그 묶음을 담은 geosite.dat 계열, (2) IP 국가·ASN 판별을 위한 country.mmdb 또는 geoip.dat 류입니다. 사용 중인 빌드와 geodata-mode 설정에 따라 엔진이 선호하는 포맷과 파일명 표기가 달라질 수 있으므로, 구버전 튜토리얼의 스크린샷 YAML을 그대로 복사하기보다는 현재 바이너리가 안내하는 스키마를 한 번 대조하는 습관이 필요합니다.

geodata-loader를 standard와 memconservative 중에서 고를 수 있는 환경이라면, 저사양 라우터나 오래된 노트북에서는 메모리 사용을 줄이는 쪽이 안정적일 때가 있습니다. 반면 데스크톱에서는 기본 로더로도 부담이 적은 경우가 많습니다. 로더 모드는 ‘파일 경로’와는 별개지만, 같은 파일을 읽어도 적재 방식이 달라지므로 OOM이나 느린 첫 연결 같은 증상을 볼 때 함께 조정할 가치가 있습니다.

YAML에서 건드리는 대표 옵션

대부분의 최신 프로필은 상위 수준에 아래와 비슷한 블록을 둡니다. 주석은 영어로만 적는 것이 관례이므로 예시에도 그렇게 맞춥니다.

YAML# Example only — align keys with your Mihomo version docs
geodata-mode: true
geodata-loader: standard
geo-auto-update: false
geo-update-interval: 24

geox-url:
  geoip: "https://example.com/path/to/geoip.dat"
  geosite: "https://example.com/path/to/geosite.dat"
  mmdb: "https://example.com/path/to/country.mmdb"
  # asn: optional mirror URL when your build expects ASN DB

geo-auto-update를 false로 두면 커널이 주기적으로 외부에서 끌어오지 않으므로, 수동으로 복사한 파일이 계속 우선합니다. 반대로 true인데 회사 미러만 쓰고 싶다면 geox-url 각 키를 내부 HTTPS 엔드포인트나 검증 가능한 거울 저장소 주소로만 채워 두면 됩니다. 신뢰할 수 없는 단축 URL이나 무출처 업로드를 그대로 넣지 마세요.

팁: 많은 사용자가 널리 검증되는 메타 규칙 데이터 릴리스(meta-rules-dat) 같은 공개 배포를 가져오지만, 이 글에서는 특정 호스트 이름을 고정 안내하지 않습니다. 레포 로그와 릴리스 노트에 적힌 무결성 해시값이 있다면 교체 후 비교까지 하는 것을 권장합니다.

플랫폼별 작업 디렉터리를 찾는 법

파일 교체 실패 원인 첫 순위는 ‘다른 복사본을 고쳐서 커널이 보지 않는 경로만 최신이라고 생각함’입니다. Windows에서는 사용자 프로필 아래 숨김 디렉터리, macOS·Linux에서는 ~/.config 패밀리, 일부 패키지는 /var/lib 식 분리 디렉터리를 쓰기도 합니다. 현재 인스턴스가 실제 열어본 디렉터리는 각 GUI의 ‘데이터 디렉터리 열기’ 메뉴나, 최초 실행 시 출력되는 로그의 cwd·home 한 줄 근처에 드러나는 경우가 많습니다.

터미널 기동이라면 -d 또는 환경 변수로 홈 디렉터리를 줄 때 파일도 그 아래 이름으로 놓입니다. 디렉터리를 확인한 다음에는 같은 자리에서 예전 라이브러리를 확장자까지 유지해 백업(예: geosite.dat.bak)해 두세요. 디스크 절약 때문에 이름만 다른 파일을 놓거나 링크를 꼬아 두면 업데이트 스크립트가 덮어쓸 때 꼬이기 쉽습니다.

오프라인 수동 교체 절차(핵심)

  1. 먼저 설정 검증 단계에서 파싱은 통과했다는 것만으로 DB가 존재한다고 단정 금지입니다. mihomo -t 계열 테스트가 있다면 교체 후 한 번 실행해 보세요. 옵션과 출력 형식은 설치 패키지에 따라 다릅니다.
  2. 동작 중인 커널을 잠깐 종료할 수 있는 환경이면 교체 순간까지 중지 후 파일을 덮어쓰면 잠금 이슈를 줄일 수 있습니다. 핫 리로드를 지원하는 클라이언트라면 API로 리로드를 호출했을 때 새 파일 크기 타임스탬프가 갱신됐는지 확인합니다.
  3. 받아 온 패키지에 체크섬 파일이나 서명 검증 방법이 포함되어 있다면 반드시 수행합니다. 부분 받기로 깨진 mmdb 하나가 전체 GEOIP 라인 신뢰를 무너뜁니다.
  4. 교체 후 예상 이름—geosite.dat, geoip.dat, country.mmdb 등—이 실제로 있는지 디렉터리 목록에서 다시 확인하고, 활성 프로필이 해당 홈 디렉터리를 참조하는지 교차 확인합니다.
  5. GUI가 별도 ‘지도 데이터 디렉터리’를 노출하면 그 경로 우선 규칙을 따르고, 앱 업데이트로 경로 문자열이 바뀔 수 있어 릴즈 노트를 습관화합니다.

교체했다고 해서 규칙이 바로 바뀌는 건 아닙니다

GEO 데이터가 새로워도 규칙 배열 어딘가의 DOMAIN 줄이 더 위에서 먼저 매칭되면 결과는 예전과 같습니다. 디버깅 시에는 테스트용 대상 접속 하나를 고르고, 대시보드나 로그에 찍히는 ‘matched rule’ 이름과 정책 그룹이 어떻게 표시되는지 메모합니다. 이어서 해당 목적지 IP가 실제 새 mmdb 클래스에 어떻게 분류되어야 하는지 대략이라도 교차 검증해야 ‘DB 미적용 문제’와 ‘YAML 순서 문제’를 갈라냅니다.

GEOSITE 기반 줄을 건드렸을 때 변화가 제한적으로 보일 수 있습니다. 제공자별 태그 집합이 다르거나, 사용자 정의 라우팅이 DNS 스테이지에서 이미 다른 인터페이스로 나갔을 수 있기 때문입니다. DNS 레이어는 실제 패킷이 어떤 IP로 만들어져 규칙 엔진에 들어오느냐를 바꿀 수 있어, 순수 Geo 파일 교체보다 먼저 DNS를 의심하는 경우도 있습니다.

로그 레벨로 로딩 상태를 확인하기

일반 운영에는 info가 무난하지만 일회성 교체 검증이라면 단기적으로 debug 또는 상위 레벨로 올려 geodata 초기 로딩 줄이 있는지 훑어보면 큰 폭으로 불안을 줄입니다. 여기에는 실패 원인 파일 경로 등이 문자열 형태로 남는 경우도 있습니다. 과도한 디버그 출력은 디스크·개인 정보 이슈를 키울 수 있으니 확인이 끝나면 레벨을 되돌리세요.

외부 컨트롤러 패널이 있다면 /configs나 유사 메타 엔드포인트에서 활성 이름과 홈 디렉터리 문자열을 읽어보고, 교체 디렉터리와 문자 단위까지 일치하는지 확인하는 방법도 있습니다. 대시보드 사용 전체 방법은 해당 글테마와 겹치므로 세부 버튼 경로까지는 적지 않습니다.

아주 간단히: geosite-matcher 차이 한 줄 요약

일부 사용자는 레거시 mph 매처 호환 때문에 geosite-matcher를 바꿉니다. 패턴 속도나 메모리 트레이드오프는 환경마다 크게 달라서, 디폴트를 유지했다가 교체 테스트에서 CPU 사용이 튀면 문서별 옵션을 비교하면 됩니다. 이 설정은 라이브러리 ‘파일 이름’과 무관하게 읽었을 해석 결과에 영향을 줄 수 있음을 숙지해야 합니다.

주의: 체크섬이 없는 무작위 링크의 Geo 패키지는 악의적으로 넓게 잡인 DOMAIN 패턴으로 프록시 흐름을 유도하지 못하더라도 잘못된 국가 판별을 일으킬 수 있습니다. 릴리스 페이지·공식 미러처럼 제공 경로와 해시 검증 가능한 채널만 쓰세요.

자주 묻는 질문

Q. 교체 크기만 보고 버전 확인이 되나요? 크기 차이만으로 검증 불가입니다. 같은 릴라우스 패치가 압축률 때문에 비슷한 용량을 낼 때도 있습니다. 제공자 해시 또는 내부 해시 레지스트리를 맞추는 편이 낫습니다.

Q. 라우터 OpenWrt·게이트웨이 패키지는? 가정용 장비는 공간이 줄어 패키지가 기본 디렉터리를 하드코딩해 두거나 tmpfs 아래 받기도 합니다. 장비별 문서의 ‘데이터 디렉터리’ 섹션을 따라가 세트 전체 파일을 동시 교체해야 꼬이지 않습니다.

Q. 구독이 외부 rule-provider만 갱신하면 Geo는 자동이라고 해도 되나요? 규칙 세트 업데이트와 Geo 레이어는 별 채널입니다. 규칙 YAML이 최신이어도 mmdb 분류표가 과거 상태이면 새 IP 대역 매핑은 엇나갑니다.

정리

지금까지 Mihomo(Clash Meta)에서 GeoSite·GeoIP 바이너리 라이브러리를 사용자 환경에 맞는 작업 디렉터리 아래 이름대로 놓거나, 필요하면 외부 업데이트 채널 URL을 통제해서 오프라인 복구를 돕고, 교체 후 파일 존재·로그 줄·실제 규칙 매칭까지 세 레이어를 확인하는 과정을 풀어 설명했습니다. Geo 자체 교체와 별개로 표면 증상이 비슷한 ‘규칙 순서 문제’는 GEOIP 순서별 문서를 함께 열어두면 결론까지 도달 시간이 줄어듭니다.

시중의 일반 프록시 앱 많은 종이 Geo 데이터 내부를 숨기고 자동 업데이트 채널만 노출해서, 회사 허브나 공항 와이파이 같은 제한 네트워크에서는 원하는 검증 패키지를 미리 놓아 둘 수 없거나 로그 접근조차 까다로운 편입니다. 같은 상황에서 Clash 계열 생태계는 사용자가 YAML과 파일 경로까지 직조정할 수 있는 여지가 남아 있어, 교체 순간의 재현 가능성과 감사 trail을 스스로 잡기에는 유리한 조건을 갖습니다.

정리했던 순서 그대로 테스트할 테스트용 클라이언트나 커널 번들을 아직 두지 않았다면, 패키지를 한 세트 받아 놓은 뒤 대시보드에서 경로부터 맞춰 보세요. 필요하면 바로 여기에서 ClashSource 클라이언트 페이지로 이동해 무료로 받기를 눌러 보시길 바랍니다.