1 이럴 때 지리 DB를 먼저 의심하세요
Clash Meta(Mihomo) 규칙에서 GEOIP,US·GEOIP,CN,DIRECT 같은 줄은 목적지 IP를 국가 코드로 분류해 정책을 고릅니다. GEOSITE 계열은 도메인을 카테고리·지역 태그와 매칭합니다. 데이터가 오래되면 CDN·클라우드 앞단 IP의 소유 주체가 바뀐 뒤에도 옛 매핑이 남아, 국내 CDN을 해외로 보내거나 반대로 해외 전용 스트리밍이 직접 연결로 떨어지는 식의 분류 불일치가 납니다. 구독이나 노드 목록은 그대로인데 «갑자기» 증상만 바뀌었다면, 룰셋보다 로컬 geo 파일의 날짜를 보는 편이 빠릅니다.
다만 모든 이상이 지리 DB 탓은 아닙니다. HTTPS 초기에 코어가 IP만 보고 판단하면 DOMAIN-SUFFIX가 뒤늦게 적용되는 경우가 있어, 《Clash Meta Sniffer·HTTPS 분할》에서 다룬 것처럼 SNI와 규칙 순서를 함께 봐야 합니다. 본문은 «지리 데이터가 낡았다»는 가설을 확인·교체·검증하는 절차에 집중합니다.
2 geoip.dat·geosite.dat와 mmdb 차이
Mihomo는 설정의 geodata-mode(또는 동일 목적 플래그)에 따라 로드하는 파일 형식이 갈립니다. geodata 모드가 켜진 전형적인 구성에서는 geoip.dat와 geosite.dat 한 쌍을 씁니다. geodata-mode가 꺼진 구성에서는 GeoIP에 Country.mmdb(MaxMind 계열 바이너리)를 쓰고, Geosite는 여전히 geosite.dat를 두는 경우가 많습니다. 파일 이름을 바꿔 끼우기 전에 지금 프로필이 어떤 모드인지 GUI 설정이나 YAML 루트를 확인하세요. 형식이 어긋나면 코어가 조용히 예전 캐시를 붙잡거나 시작 시 오류를 내기도 합니다.
3 신뢰할 만한 다운로드 소스 고르기
커뮤니티에서 널리 쓰는 경로는 메타 규칙 데이터 릴리스(예: MetaCubeX 쪽 meta-rules-dat 저장소의 릴리스 아티팩트)와, Loyalsoldier 등이 배포하는 geoip.dat·geosite.dat 또는 Country.mmdb 묶음입니다. 어떤 미러를 쓰든 공식·반복 링크에서 직접 받고, 중간 프록시가 바이너리를 바꿨는지 의심될 때는 해시나 파일 크기를 한 번 더 확인하세요. 기업망에서는 보안 정책상 특정 도메인만 허용될 수 있으므로, 허용된 미러를 내부 문서로 고정해 두는 편이 안전합니다.
GUI 클라이언트(예: Clash Verge 계열)는 지리 데이터 업데이트 버튼으로 같은 파일을 내려받게 해 주는 경우가 많습니다. 수동으로 바꿀 때는 그 버튼이 가리키는 URL이 무엇인지 설정 화면에서 확인하면, 이후 자동 갱신과 수동 파일이 서로 덮어쓰지 않게 조율하기 쉽습니다.
4 YAML에서 자동 갱신·geox-url 맞추기
Mihomo는 루트에 geo-auto-update·geo-update-interval·geox-url 같은 키로 주기적 다운로드를 켤 수 있습니다. geox-url의 geoip·geosite 항목이 가리키는 URL이 깨졌거나 오래된 미러면, 자동 갱신이 돌아도 빈 파일·오류 응답이 쌓일 수 있습니다. 수동 교체 후에는 이 URL들을 검증된 릴리스 직링크로 바꿔 두면 다음번부터 같은 소스를 유지하기 좋습니다.
# Mihomo / Clash Meta profile root (illustrative)
geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
geoip: "https://example.com/release/geoip.dat"
geosite: "https://example.com/release/geosite.dat"
실제 키 이름·기본값은 코어 버전마다 조금씩 다릅니다. 업그레이드 직후에는 반드시 구성 검사(-t)나 클라이언트 내 검증을 돌리고, 변경 로그에서 geox·geoip 관련 항목이 없는지 확인하세요.
5 배치 경로와 안전한 교체 순서
파일 위치는 작업 디렉터리와 클라이언트가 지정한 홈 경로에 따릅니다. Linux에서 systemd로 Mihomo만 돌리는 경우《Linux Mihomo·systemd 가이드》에 적힌 -d 데이터 디렉터리 아래에 geoip.dat 등이 놓이는 경우가 많습니다. 데스크톱 앱은 각 OS의 앱 데이터 폴더에 동일 이름을 두기도 하니, 실행 중인 프로세스가 읽는 경로를 로그나 설정 화면으로 먼저 확인하세요.
- 코어를 리로드 가능한 상태로 두고, 기존
geoip.dat·geosite.dat·Country.mmdb를 이름에 날짜를 붙여 백업합니다. - 다운로드한 파일을 설정이 기대하는 정확한 파일명으로 복사합니다. 대소문자·확장자 하나만 달라도 못 읽는 경우가 있습니다.
- 권한이 필요한 경로라면 소유자·읽기 권한을 맞춥니다.
- 클라이언트에서 구성 다시 로드 또는 코어 재시작을 수행합니다.
6 리로드 후 검증: 로그·규칙 매칭
재시작 뒤 디버그 로그에서 geo 관련 로딩 오류가 없는지 확인합니다. 특정 사이트만 문제라면 연결 로그에 찍힌 목적지 IP와 매칭된 규칙 이름을 보면, GEOIP 줄이 의도대로 타는지 바로 알 수 있습니다. DNS가 FakeIP·DoH와 얽혀 있으면 IP가 예상과 다르게 보일 수 있으므로,《Meta DNS·FakeIP 유출 방지》와 함께 해석 결과도 짧게 점검하세요. 지리 DB를 새로 깔았는데도 증상이 그대로면, Rule Provider 캐시나 상위의 IP-CIDR 규칙이 먼저 잡는지 《ACL4SSR·rule-provider》 관점에서 순서를 다시 봅니다.
스트리밍·결제처럼 지역 잠금이 민감한 서비스는, 노드 국가와 exit IP의 GeoIP 결과가 일치하는지 외부 «내 IP」 페이지로 한 번 확인하면 교체 성공 여부를 빠르게 판별할 수 있습니다. 단, 이런 확인은 개인 정보·이용 약관 범위 안에서만 하세요.
7 지리 DB만 바꿔서는 안 풀릴 때
- 규칙 순서: 넓은
MATCH나 상위RULE-SET이 먼저 걸리면GEOIP에 닿지 않습니다. - 스니퍼·도메인 컨텍스트: TLS SNI가 비어 있으면 IP 기반 판단만 남습니다.
- DNS 누수·이중 해석: 앱이 시스템 DNS로 빠지면 규칙이 보는 IP 자체가 달라집니다.
- 서비스 측 정책 변경: IP 대역·봇 탐지가 바뀌면 같은 노드라도 차단될 수 있습니다.
따라서 운영 습관으로는 한 번에 한 가지 축만 바꾸고(지리 DB, DNS, 스니퍼, 룰셋), 증상을 짧게 기록해 두는 것이 이후 트러블슈팅에 유리합니다.
8 정리
Clash Meta·Mihomo에서 GEOIP·GEOSITE 기반 분류가 틀어지면, 구독보다 먼저 geoip.dat·geosite.dat·Country.mmdb의 선택·경로·모드 일치를 확인하세요. 검증된 릴리스에서 내려받아 백업 후 교체하고, 리로드·로그로 로딩 오류를 없앤 뒤 규칙 매칭을 다시 봅니다. 자동 갱신을 쓰면 geox-url을 안정적인 주소로 고정해 두면 재발을 줄일 수 있습니다.
데스크톱에서는 GUI로 지리 리소스를 갱신하고 로그를 보는 편이 수월합니다. 설치 패키지는 GitHub 릴리스보다 사이트의 다운로드 페이지를 우선하면 버전·경로 안내가 한곳에 모입니다. 오픈 소스 이슈·릴리스 노트는 필요할 때만 GitHub를 참고하고, 실제 설치 파일은 사이트 안내를 따르는 흐름이 일관됩니다.
유사 증상이라도 원인 레이어가 다를 수 있으니, 지리 DB를 새로 깐 뒤에도 이상하면 Sniffer·DNS·rule-provider를 순서대로 의심하면 됩니다.
