GeoIP 및 GeoSite 데이터베이스 업데이트 가이드: 다운로드 소스 설정, 수동 교체와 규칙 연동

먼저 GeoIP와 GeoSite의 매칭 대상을 구분하기

GeoIP와 GeoSite는 모두 많은 규칙을 짧은 조건 하나로 압축할 수 있지만, 처리 대상은 서로 다릅니다. GeoIP는 연결 대상의 IP 주소를 기준으로 국가나 지역을 판단하고, GeoSite는 도메인의 분류를 기준으로 매칭합니다. 같은 데이터베이스가 아니므로 서로 대체할 수도 없습니다.

항목	GeoIP	GeoSite
주요 파일	GeoIP.dat 또는 Country.mmdb	GeoSite.dat
입력 대상	IPv4 및 IPv6 주소	도메인 및 도메인 분류 태그
대표 규칙	GEOIP,CN,DIRECT	GEOSITE,cn,DIRECT
주요 용도	대상 IP의 지역을 기준으로 최종 분기	사이트, 서비스 또는 카테고리를 기준으로 우선 분기
주요 제약	CDN, Anycast 및 클라우드 서비스 주소는 여러 지역에 걸쳐 있을 수 있음	연결 단계에서 도메인 정보를 보존하거나 복원해야 함

GeoSite를 GeoIP보다 먼저 배치하기

대부분의 설정은 위에서 아래로 규칙을 매칭합니다. 도메인 규칙은 IP의 지리적 위치보다 서비스 의미를 더 직접적으로 반영하므로 우선 처리하는 것이 좋습니다. 예를 들어 여러 국가에 분산된 CDN을 사용하는 서비스는 GeoIP에서 현재 해석된 노드 주소만 확인하지만, GeoSite는 원래 도메인을 기준으로 일관되게 분류할 수 있습니다.

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,노드 선택

이 규칙 그룹은 먼저 광고 카테고리를 차단한 다음 중국 본토에서 자주 사용되는 도메인을 처리합니다. 이후 도메인 규칙에 매칭되지 않은 중국 본토 IP 주소를 GeoIP로 보완하고, 마지막으로 기본 정책 그룹에 넘깁니다. 실제 태그의 존재 여부는 선택한 GeoSite 데이터 소스에 따라 달라지므로, 소스를 변경하기 전에 태그 이름이 일치하는지 확인해야 합니다.

Mihomo가 실제로 사용하는 데이터 형식 확인하기

Clash Meta는 이후 Mihomo라는 이름으로 유지 관리됩니다. 클라이언트마다 내장된 코어 버전이 다를 수 있고, 이전 Clash 방식의 설정 메뉴가 남아 있을 수도 있습니다. 업데이트하기 전에 클라이언트의 「설정」→「코어」 또는 「설정」→「버전 정보」에서 코어 이름과 버전을 확인하세요. 명령줄 환경에서는 mihomo -v를 실행하면 됩니다.

Mihomo의 geodata-mode는 GeoIP 데이터의 읽기 방식을 결정합니다. 활성화하면 일반적으로 GeoIP.dat를 읽고, 비활성화하면 보통 MMDB 형식의 Country.mmdb를 사용합니다. GeoSite 분류는 여전히 GeoSite.dat에서 제공합니다. 같은 이름의 파일 하나만 교체하고 코어가 반드시 그 파일을 읽을 것이라고 가정하지 마세요. 설정 모드와 작업 디렉터리도 함께 확인해야 합니다.

geodata-mode: true
geodata-loader: memconservative

rules:
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,노드 선택

geodata-loader: memconservative는 메모리 사용량을 줄이는 것이 중요한 환경에 적합합니다. 사용할 수 있는 값과 동작은 코어 버전에 따라 달라질 수 있으므로, 변경 후에는 클라이언트의 설정 검사나 명령줄 테스트로 확인해야 합니다. 메모리가 충분한 데스크톱에서는 클라이언트가 생성한 기본값을 유지하는 편이 보통 더 안정적입니다.

`no-resolve`는 모든 경우에 필요한 옵션이 아닙니다

GEOIP 규칙에 전달된 대상이 아직 도메인인 경우, 지역 매칭을 위해 코어가 먼저 IP를 해석해야 할 수 있습니다. 규칙 끝에 no-resolve를 추가하면 해당 규칙 때문에 별도의 해석을 수행하지 않습니다. 불필요한 DNS 요청을 줄일 수 있지만, 대상 IP를 아직 얻지 못한 상태에서는 이 GEOIP 규칙이 직접 해석하여 매칭하지 않습니다.

연결에 대상 IP가 이미 포함된 경우: GEOIP가 바로 판단할 수 있으므로 no-resolve가 일반적으로 매칭을 방해하지 않습니다.
대상이 아직 도메인인 경우: DOMAIN, DOMAIN-SUFFIX 또는 GEOSITE 규칙을 우선 사용하세요.
도메인 해석 결과를 GEOIP 판단에 의존하는 설정이라면 no-resolve를 테스트 없이 추가하지 마세요.

자동 업데이트 다운로드 소스 설정하기

Mihomo에서는 geox-url로 지리 데이터베이스 주소를 지정하고, geo-auto-update로 자동 업데이트를 제어할 수 있습니다. 아래 예시는 동일한 릴리스 저장소의 GeoIP와 GeoSite 파일을 사용해 두 데이터 세트의 업데이트 시점과 분류 기준이 크게 어긋나는 것을 방지합니다.

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24

geox-url:
  geoip: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat"
  geosite: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat"

geo-update-interval: 24의 단위는 시간이며, 24시간마다 한 번씩 확인한다는 뜻입니다. 데스크톱 클라이언트는 하루 한 번 업데이트하면 충분하므로 1시간 이하로 설정할 필요가 없습니다. 데이터베이스의 배포 주기는 보통 프록시 노드 상태 변화보다 느리기 때문에, 지나치게 자주 확인하면 시작 시 네트워크 요청만 늘어납니다.

다운로드 소스가 충족해야 할 네 가지 조건

파일 형식이 일치해야 합니다. GeoIP 주소는 현재 코어 모드가 지원하는 데이터 파일을 반환해야 하며, 웹 다운로드 페이지를 바이너리 파일 주소로 사용해서는 안 됩니다.
파일 이름과 내용이 일치해야 합니다. geoip 항목은 IP 데이터를, geosite 항목은 도메인 분류 데이터를 가리켜야 합니다.
태그 기준을 확인할 수 있어야 합니다. 설정에서 사용하는 cn, private, category-ads-all 등의 태그가 해당 데이터 소스에 존재해야 합니다.
코어가 시작할 때 접근할 수 있어야 합니다. 규칙이 적용되기 전에 최초 다운로드가 진행된다면, 다운로드 경로가 아직 로드되지 않은 동일한 규칙 세트에 의존해 순환 구조를 만들지 않아야 합니다.

변경 후에는 먼저 설정을 검사한 다음 코어를 다시 로드하세요

명령줄 환경에서는 코어 자체의 YAML 검사 기능을 사용할 수 있습니다. -d는 실행 디렉터리를 지정하며 데이터베이스도 이 디렉터리에서 읽습니다. -f는 기본 설정 파일을 지정합니다. 경로에 공백이 있으면 따옴표로 감싸야 합니다.

mihomo -d "/opt/mihomo" -f "/opt/mihomo/config.yaml" -t

클라이언트 사용자는 「설정」 페이지에서 현재 설정을 선택한 뒤 「검사」 또는 「다시 로드」를 실행할 수 있습니다. 메뉴 이름은 클라이언트 버전에 따라 조금 다를 수 있지만, 저장 가능한 백업 복사본 만들기, YAML 검사, 코어 다시 로드, 로그 확인의 순서는 유지해야 합니다. 로그에 다운로드 실패, 파일 형식 오류 또는 태그 없음이 표시되면 먼저 이전 파일을 복원하고 여러 설정을 연속해서 변경하지 마세요.

오프라인 환경에서 데이터베이스 수동 교체하기

서버가 다운로드 소스에 직접 접근할 수 없거나 기업 네트워크가 외부 연결을 제한하는 경우, 또는 특정 데이터베이스 버전을 고정해야 하는 경우에는 오프라인으로 교체할 수 있습니다. 핵심은 파일을 프로그램 설치 디렉터리에 복사하는 것이 아니라 Mihomo의 작업 디렉터리를 찾는 것입니다. 명령줄 배포에서는 -d 매개변수로 작업 디렉터리를 정하며, 그래픽 클라이언트는 보통 「설정」→「설정 디렉터리」 또는 「설정」→「앱 디렉터리」에서 열기 기능을 제공합니다.

표준 교체 절차

인터넷에 연결된 장치에서 현재 설정에 맞는 GeoIP.dat, GeoSite.dat 또는 Country.mmdb를 다운로드합니다.
나중에 업데이트 필요 여부를 판단할 수 있도록 릴리스 버전과 다운로드 날짜(예: 2026-05-28)를 기록합니다.
대상 장치에서 Mihomo 코어를 중지하고, 트레이 메뉴나 서비스 관리자가 코어 종료 상태를 표시하는지 확인합니다.
작업 디렉터리를 열고 기존 파일 이름을 GeoIP.dat.bak 및 GeoSite.dat.bak으로 변경합니다.
새 파일을 복사하고 코어가 예상하는 대소문자와 파일 이름을 그대로 유지합니다.
설정 검사를 실행한 다음 코어를 시작하고 처음 30초 동안의 로그를 확인합니다.
세 가지 테스트를 완료합니다: 사설 주소, 자주 사용하는 중국 본토 도메인, 기본 프록시 도메인.

Linux 서비스 배포에서는 먼저 임시 이름으로 복사한 뒤 동일한 파일 시스템 안에서 이름을 변경해 교체하면 프로세스가 불완전한 파일을 읽을 위험을 줄일 수 있습니다. 아래 경로는 -d /etc/mihomo로 정한 작업 디렉터리의 예시입니다.

sudo systemctl stop mihomo
sudo cp /mnt/offline/GeoIP.dat /etc/mihomo/GeoIP.dat.new
sudo cp /mnt/offline/GeoSite.dat /etc/mihomo/GeoSite.dat.new
sudo mv /etc/mihomo/GeoIP.dat /etc/mihomo/GeoIP.dat.bak
sudo mv /etc/mihomo/GeoSite.dat /etc/mihomo/GeoSite.dat.bak
sudo mv /etc/mihomo/GeoIP.dat.new /etc/mihomo/GeoIP.dat
sudo mv /etc/mihomo/GeoSite.dat.new /etc/mihomo/GeoSite.dat
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml -t
sudo systemctl start mihomo

Windows 그래픽 클라이언트에서는 코어가 실행 중일 때 파일을 직접 덮어쓰지 마세요. 먼저 트레이 메뉴에서 코어 또는 클라이언트를 종료한 뒤 설정 디렉터리에서 작업합니다. 파일이 사용 중인 상태에서 강제로 덮어쓰면 임시 파일이 남고, 다음 실행 때 클라이언트가 이전 데이터베이스를 계속 읽을 수 있습니다.

데이터베이스가 오래되면 어떤 분기 오류가 발생할까

오래된 지리 데이터베이스는 보통 클라이언트를 즉시 중단시키기보다 부분적이고 간헐적인 분기 이상을 일으킵니다. 같은 웹사이트에서도 일부 CDN 주소나 새 도메인만 잘못된 정책에 매칭될 수 있어 노드 불안정으로 오해하기 쉽습니다.

오래된 GeoIP에서 나타나는 대표적인 증상

새로 할당된 IP 대역이 MATCH로 넘어가고 예상한 GEOIP,CN에 매칭되지 않습니다.
클라우드 서비스나 CDN의 주소 지역이 변경된 뒤 연결이 예상과 다른 정책 그룹으로 분기됩니다.
IPv4는 정상적으로 매칭되지만 새로 추가된 IPv6 대역은 기본 정책으로 이동합니다.
같은 도메인이 해석될 때마다 다른 주소를 반환해 정책이 DIRECT와 기본 프록시 사이에서 바뀝니다.

오래된 GeoSite에서 나타나는 대표적인 증상

서비스가 새 도메인을 사용하기 시작했지만 새 도메인이 기존 분류에 포함되지 않습니다.
광고 분류가 최근 추가된 추적 도메인을 포함하지 못합니다.
설정에서 새 태그를 참조할 때 코어 로그에 해당 GeoSite 카테고리가 없다는 메시지가 표시됩니다.
데이터 소스에서 태그 구조를 변경한 뒤에도 이전 규칙은 로드되지만 적용 범위가 달라집니다.

단일 도메인이 잘못된 정책으로 분기되었다고 해서 데이터베이스가 오래되었다고 단정할 수는 없습니다. 규칙 순서, DNS 캐시, Fake-IP 매핑, 스니핑 설정 또는 사용자 지정 덮어쓰기가 원인일 수도 있습니다. 판단할 때는 먼저 연결 페이지에서 실제로 매칭된 규칙을 확인한 뒤 대상 도메인, 대상 IP 및 정책 그룹과 대조해야 합니다.

로그와 연결 기록으로 규칙 연동 확인하기

업데이트가 끝난 뒤 파일 날짜만 확인하지 마세요. 실제 연결이 어떤 규칙에 매칭되었는지 관찰하는 것이 더 효과적입니다. 클라이언트의 「연결」 페이지를 열고 이전 기록을 지운 다음 사설 주소, 중국 본토 사이트, 기본 정책을 사용해야 하는 사이트를 각각 방문하세요. 기록에는 대상 도메인, 대상 IP, 규칙 유형 및 최종 정책이 표시되어야 합니다.

권장하는 네 가지 테스트

사설 네트워크: 라우터 또는 LAN 서비스를 방문해 GEOSITE,private, GEOIP,private 또는 명시적인 대역 규칙이 우선 매칭되는지 확인합니다.
도메인 분류: 분류가 명확한 도메인에 접속해 GEOIP나 MATCH가 아니라 GEOSITE에 매칭되는지 확인합니다.
IP 보완 규칙: 대상 IP만 있는 연결에서 GEOIP가 예상대로 트래픽을 분기하는지 확인합니다.
기본 규칙: 앞서 언급한 분류에 속하지 않는 도메인을 선택해 마지막에 MATCH가 지정한 정책 그룹으로 들어가는지 확인합니다.

TUN 모드에서는 애플리케이션 트래픽이 먼저 IP 형태로 코어에 들어올 수 있습니다. Mihomo는 DNS 매핑과 도메인 스니핑을 함께 사용해 일부 도메인 정보를 복원할 수 있지만, 결과는 프로토콜, 암호화 방식 및 클라이언트 설정의 영향을 받습니다. GEOSITE가 계속 매칭되지 않는다면 데이터베이스를 반복해서 바꾸기보다 「설정」→「네트워크」에서 TUN, DNS 및 스니핑 옵션도 함께 확인하세요.

log-level: info

rules:
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,노드 선택

info 수준이면 일반적으로 연결 및 규칙 결과를 확인하기에 충분합니다. 데이터베이스 로드 실패, DNS 매핑 또는 스니핑 문제를 분석할 때만 일시적으로 debug로 전환하세요. 점검이 끝나면 원래 수준으로 되돌려 로그가 장기간 쌓이지 않도록 합니다.

자주 발생하는 업데이트 실패와 처리 순서

다운로드는 성공했지만 재시작 후에도 이전 결과를 사용하는 경우

먼저 새 파일이 코어 작업 디렉터리에 들어갔는지, 설치 패키지 디렉터리나 다운로드 디렉터리에 들어간 것은 아닌지 확인합니다. 이어서 geodata-mode를 확인하세요. 설정이 MMDB를 요구한다면 GeoIP.dat만 교체해도 GeoIP 판단 방식은 바뀌지 않습니다. 그래픽 클라이언트가 여러 코어 디렉터리를 관리할 수도 있으므로 현재 활성 코어의 로그에 기록된 경로를 기준으로 확인해야 합니다.

로그에 GeoSite 태그가 없다고 표시되는 경우

이는 대개 규칙 태그와 데이터 소스의 분류 기준이 일치하지 않아서 발생합니다. 먼저 GEOSITE,category-ads-all,REJECT 같은 오류 규칙을 찾은 뒤 현재 데이터 소스가 해당 분류를 제공하는지 확인하세요. 이름이 비슷하다고 완전히 같은 태그로 보아서는 안 됩니다. 유지 관리 프로젝트에 따라 분류를 통합하거나 나누거나 이름을 변경할 수 있습니다.

시작 단계에서 자동 업데이트 시간이 초과되는 경우

먼저 업데이트 간격을 24시간으로 되돌리고 다운로드 주소가 데이터 파일을 직접 반환하는지 확인합니다. 최초 설치는 인터넷에 연결된 환경에서 데이터베이스를 수동으로 넣은 뒤 코어를 시작해도 됩니다. 이렇게 하면 원격 업데이트가 일시적으로 실패해도 기존 규칙을 로드할 수 있습니다. 서버 배포라면 systemd 서비스 사용자가 작업 디렉터리에 쓸 권한이 있는지도 확인해야 합니다.

업데이트 후 많은 트래픽이 다른 정책으로 분기되는 경우

즉시 세트 단위 백업을 복원한 다음 새 데이터 소스와 이전 데이터 소스, 태그 적용 범위 및 규칙 순서를 비교하세요. 데이터베이스 업데이트는 분류 결과를 바꿀 수 있지만, 기록 없이 규칙표와 DNS 및 TUN 설정을 동시에 수정해서는 안 됩니다. 한 번에 변수 하나만 변경해야 문제가 데이터에 있는지 설정에 있는지 판단할 수 있습니다.

반복 가능한 유지 관리 주기 만들기

개인용 데스크톱은 매일 자동 확인하고 매월 수동 검토하는 방식이 적합합니다. 장기간 실행되는 서버는 코어 버전, 데이터베이스 출처, 릴리스 날짜, 활성화 모드 및 최근 검증 결과를 기록해야 합니다. 분기 이상이 발생했을 때 이 다섯 가지 정보가 단순히 “업데이트 완료”라고 기록하는 것보다 훨씬 유용합니다.

매일: geo-auto-update가 24시간 간격으로 확인합니다.
매월: GeoIP와 GeoSite의 출처가 계속 유지 관리되는지 확인하고 네 가지 규칙을 표본 테스트합니다.
코어 업그레이드 후: geodata-mode, 파일 이름 및 작업 디렉터리를 다시 확인합니다.
데이터 소스를 변경할 때: 먼저 태그 목록을 확인한 다음 규칙을 조정하고, 운영 파일을 바로 덮어쓰지 않습니다.
이상이 발생할 때: 연결 기록, 매칭된 규칙, 대상 IP 및 로그 시점을 저장합니다.

GeoIP와 GeoSite 유지 관리의 핵심은 가장 높은 업데이트 빈도를 추구하는 것이 아니라 데이터 형식, 태그 기준, 규칙 순서 및 코어 작업 디렉터리를 일관되게 유지하는 데 있습니다. 자동 업데이트는 파일 확보를 담당하고, 수동 백업은 롤백을 가능하게 하며, 연결 기록은 최종 분기 결과를 검증합니다. 이 세 가지가 모두 갖춰져야 데이터베이스 업데이트가 진정으로 완료됩니다.