mihomo GeoIP·GeoSite 데이터베이스 자동 업데이트 및 규칙 설정

GeoIP와 GeoSite: IP 및 도메인 기준으로 트래픽 분기하기

mihomo는 프록시 연결을 설정하고 DNS를 조회하며 규칙을 실행하는 코어입니다. Clash Verge Rev 같은 데스크톱 클라이언트는 인터페이스를 제공하고 코어를 관리합니다. 이 문서의 설정은 mihomo용이므로 해당 필드를 지원하지 않는 구형 Clash 코어에 그대로 적용하면 안 됩니다.

GEOIP와 GEOSITE는 모두 규칙 유형이지만 조회 대상은 다릅니다. GeoIP는 IP 주소 대역을 국가, 지역 또는 기타 데이터 세트의 분류에 연결하고, GeoSite는 도메인을 사이트, 서비스 또는 주제별 분류에 연결합니다. 둘 다 외부에서 관리하는 데이터 파일을 사용하며, 코어가 실시간으로 조회하는 온라인 지리 정보 서비스가 아닙니다.

비교 항목	GeoIP	GeoSite
매칭 대상	연결 대상 IP 주소	코어가 알고 있는 대상 도메인
일반적인 규칙	`GEOIP,CN,DIRECT`	`GEOSITE,cn,DIRECT`
일반적인 파일	`geoip.dat` 또는 `country.mmdb`	`geosite.dat`
주요 한계	IP의 지역 정보가 웹사이트의 서비스 지역을 뜻하지는 않음	분류에 새 도메인이 빠질 수 있으며, IP로 직접 연결하는 경우는 자동으로 처리하지 않음

예를 들어 한 서비스의 콘텐츠가 여러 지역의 CDN에 배포될 수 있습니다. 서버 IP의 지역만으로는 서비스 종류를 정확히 판별하기 어렵습니다. 먼저 GeoSite로 도메인을 매칭하고 GeoIP로 나머지 연결을 보완하면 트래픽 분기 의도를 더 명확하게 표현할 수 있습니다. GeoIP 결과는 물리적 위치를 증명하지 않으며, 데이터 업데이트 주기와 주소 대역 소속 변경에 따라 결과가 달라질 수 있습니다.

데이터베이스 출처와 파일 형식: 먼저 로딩 모드 확인하기

데이터는 주로 커뮤니티 프로젝트에서 취합해 배포합니다. 대표적인 출처로 MetaCubeX의 meta-rules-dat와 도메인 및 IP 분류를 관리하는 다른 프로젝트가 있습니다. 파일명이 모두 geosite.dat로 같더라도 배포처에 따라 분류 이름, 업데이트 주기와 포함된 항목이 다를 수 있습니다. 규칙에 사용하는 cn, google 등의 이름이 현재 데이터 세트에 실제로 있는지 확인해야 합니다.

geodata-mode로 GeoIP 파일 형식 선택하기

geodata-mode: true: GeoIP에 DAT 형식을 사용하며 geox-url.geoip에 지정된 데이터 소스를 읽습니다.
geodata-mode: false: GeoIP에 MMDB 형식을 사용하며 geox-url.mmdb에 지정된 데이터 소스를 읽습니다.
GEOSITE는 geosite.dat를 사용하며, GeoIP를 MMDB로 전환해도 자동으로 비활성화되지 않습니다.

파일 확장자를 바꿔도 형식이 변환되지는 않습니다. MMDB 파일의 이름을 geoip.dat로 바꿔도 DAT 로더가 읽을 수 없습니다. 마찬가지로 규칙 세트에서 사용하는 YAML, 텍스트 또는 MRS 파일을 geox-url.geosite 데이터베이스 주소로 지정할 수 없습니다.

자동 업데이트 설정: geox-url 및 업데이트 주기

아래 예시는 DAT 모드를 사용하며, 데이터 출처는 MetaCubeX 배포 파일입니다. 예시 주소는 데이터베이스 다운로드 주소이며 클라이언트 설치 파일 주소가 아닙니다. 이 항목들은 설정 파일의 최상위에 dns, rules와 같은 수준으로 작성하고, 정책 그룹이나 DNS 설정 내부에 들여쓰기하지 마세요.

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-auto-update: true: 코어의 Geo 데이터 자동 업데이트 기능을 활성화합니다.
geo-update-interval: 24: 업데이트 주기는 24시간입니다. 24초가 아닙니다.
geox-url.geoip: DAT 모드에서 사용하는 GeoIP 데이터 출처입니다.
geox-url.geosite: GEOSITE 규칙에서 사용할 GeoSite 데이터 출처입니다.

이 예시에서는 실제로 사용하는 두 파일만 설정합니다. 기존 설정에서 MMDB를 사용 중이라면 geodata-mode: false를 유지하고 적절한 geox-url.mmdb를 설정하세요. 다운로드 주소만 바꾸고 로딩 모드를 전환하지 않는 일이 없도록 주의하세요. 업데이트 주기를 설정해도 24시간마다 데이터가 반드시 바뀌는 것은 아닙니다. 상위 배포처에 새 데이터가 없거나 다운로드에 실패하거나 코어가 계속 실행되지 않으면 업데이트 결과가 달라질 수 있습니다.

Clash Verge Rev에서 설정을 유지하는 방법

「설정」을 열고 현재 활성화된 구독 설정 파일을 확인합니다.
클라이언트에서 제공하는 병합 설정 또는 오버라이드 기능으로 위 최상위 항목을 추가합니다. 버전에 따라 편집 메뉴 이름이 다를 수 있으므로 최종 적용된 설정에서 결과를 확인하세요.
설정을 다시 불러옵니다. 업데이트 작업이나 데이터베이스 상태가 예상과 다르면 코어를 재시작한 뒤 시작 로그를 확인하세요.
적용된 설정에 geox-url이 명확하게 하나만 지정되어 있는지, geo-auto-update가 여전히 true인지 확인하세요.

구독에서 내려받은 파일을 직접 편집하면 다음 구독 업데이트 때 변경 사항이 덮어써질 수 있습니다. 오버라이드 시 목록 병합 방식에도 유의하세요. 일부 작업은 rules 목록 뒤에 항목을 추가하는 대신 목록 전체를 교체합니다. 수정하기 전에 현재 설정을 백업하고 클라이언트의 병합 순서를 확인하세요.

GEOIP·GEOSITE 규칙과 실행 순서

아래 예시는 일반적인 규칙 순서를 보여 줍니다. 명시적인 도메인 규칙을 먼저 적용하고, 도메인 분류와 IP 분류를 차례로 처리한 뒤 마지막에 기본 규칙을 둡니다. 예시의 「노드 선택」은 기존 설정에 정의된 정책 그룹 이름이어야 합니다. 실제 이름이 다르면 함께 수정하세요. 이 코드는 규칙 일부일 뿐, 노드·DNS·수신 포트를 포함한 전체 설정이 아닙니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOSITE,google,노드 선택
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,노드 선택

mihomo는 일반 규칙을 목록 위에서 아래로 확인하고, 일치하는 규칙의 정책을 적용합니다. 따라서 앞쪽에 둔 명시적 도메인 규칙이 뒤쪽의 분류 규칙보다 먼저 적용되며, MATCH는 기본 규칙으로 마지막에 두어야 합니다. MATCH를 첫 줄에 두면 뒤에 있는 Geo 규칙이 연결 경로를 결정할 기회가 없습니다.

GEOSITE 분류 이름은 모든 데이터베이스에서 통용되는 고정 목록이 아닙니다

GEOSITE,google,노드 선택은 현재 데이터베이스의 google 분류를 사용한다는 뜻입니다. 코어가 해당 단어를 포함하는 모든 도메인을 자동으로 수집한다는 뜻은 아닙니다. GeoSite 데이터 출처를 바꾼 뒤에는 사용 중인 분류가 그대로 있는지 확인하세요. 분류가 없다는 로딩 오류가 발생하면 규칙을 수정하거나 호환되는 데이터 소스로 바꾸세요. 노드만 반복해서 바꾸는 것은 해결책이 아닙니다.

GeoSite가 도메인을 매칭하려면 코어가 해당 도메인을 알아야 합니다. 앱이 IP에 직접 연결하거나 트래픽을 가로채는 과정에서 도메인 정보가 보존되거나 복원되지 않으면 대상 IP만으로 사이트 분류에 일치시킬 수 없습니다. TUN 모드는 가로채는 트래픽 범위를 넓힐 뿐, 모든 연결에 GeoSite가 판단할 수 있는 도메인이 포함된다는 뜻은 아닙니다.

no-resolve: 규칙 매칭을 위한 불필요한 도메인 조회 방지

GEOIP,CN,DIRECT,no-resolve에서 no-resolve는 규칙 매개변수입니다. 이 매개변수는 해당 IP 규칙을 실행할 때 IP 소속을 판단하기 위해서만 대상 도메인을 IP로 능동 조회하지 않도록 코어에 지시합니다. DNS를 전역적으로 끄거나 앱, 프록시 연결 또는 앞선 규칙에서 이미 이루어진 조회를 막는 기능은 아닙니다.

연결 상태	no-resolve 사용	no-resolve 미사용
대상에 사용 가능한 실제 IP가 있음	이미 확보한 IP로 소속을 판단할 수 있음	소속을 판단할 수 있음
도메인만 있고 사용 가능한 실제 IP는 없음	이 규칙에서 직접 조회하지 않고 다음 규칙을 확인	IP를 조회한 뒤 소속을 판단할 수 있음
앞의 도메인 규칙에 이미 일치함	이 규칙까지 실행되지 않음	이 규칙까지 실행되지 않음

불필요한 로컬 DNS 조회를 줄이려면 먼저 GeoSite로 주요 도메인을 처리하고, GeoIP 보완 규칙에 no-resolve를 추가할 수 있습니다. 다만 도메인 규칙에 포함되지 않았고 실제 대상 IP도 없는 연결은 뒤에 있는 MATCH로 바로 넘어갈 수 있습니다. 이는 규칙 설계에 따른 결과이지 GeoIP 데이터가 손상되었다는 뜻은 아닙니다.

나머지 도메인을 먼저 조회한 다음 IP 지역을 기준으로 직접 연결 여부를 판단하려면 GEOIP,CN,DIRECT를 사용할 수 있습니다. 이 경우 DNS 조회 경로, 상위 DNS 서버 연결 가능 여부와 개인정보 보호 요구 사항도 함께 검토하세요. 특히 fake-ip 모드에서는 가상 주소와 실제 대상 주소를 구분해야 합니다. 화면에 표시되는 fake-ip 주소를 GeoIP가 조회해야 할 공인 IP로 간주하면 안 됩니다.

업데이트와 트래픽 분기 확인: 설정·파일·연결을 따로 점검

검증은 세 단계로 나눠야 합니다. 설정 로딩 성공은 필드와 필요한 리소스가 해당 검사를 통과했다는 뜻이고, 데이터베이스 다운로드 성공은 리소스를 가져올 수 있다는 뜻입니다. 실제 연결이 예상한 규칙에 일치해야 비로소 트래픽 분기가 의도대로 작동한다고 볼 수 있습니다. 클라이언트의 스위치 상태나 웹페이지가 열리는지만 확인해서는 안 됩니다.

1단계: 코어 버전과 설정 구문 확인

mihomo를 독립 실행할 때는 아래 명령을 사용할 수 있습니다. 데이터 디렉터리와 설정 파일 경로가 실제 사용 위치를 가리키는지 확인하세요. 경로가 다르면 다른 파일을 대상으로 테스트할 수 있습니다. 데스크톱 클라이언트는 대개 자체 작업 디렉터리를 사용합니다. 코어가 실행 중일 때 다른 프로세스로 해당 디렉터리를 동시에 수정하지 마세요.

mihomo -v
mihomo -t -d ./mihomo-data -f ./config.yaml

-v는 실제 실행 중인 코어 버전을 확인할 때, -t는 설정을 테스트할 때 사용합니다. 알 수 없는 필드나 리소스 로딩 오류가 표시되면 먼저 해당 설정을 지원하는 mihomo 코어인지 확인한 다음 YAML 들여쓰기와 데이터 소스를 점검하세요. 클라이언트 이름만으로 코어 기능을 판단하면 안 됩니다.

2단계: 다운로드 로그와 실제 작업 디렉터리 확인

클라이언트의 「로그」 페이지에서 Geo 데이터 로딩·다운로드·업데이트 관련 기록을 찾고, 시간 초과, HTTP 상태 코드와 파싱 실패를 확인합니다.
코어의 실제 작업 디렉터리에서 geoip.dat, geosite.dat 또는 MMDB 모드에 해당하는 파일을 확인하세요. 구독 파일이 있는 디렉터리만 살펴보면 안 됩니다.
업데이트 전후의 파일 수정 시간, 파일 크기와 오류 로그를 기록하세요. 수정 시간 변경은 참고 자료일 뿐 분류 내용이 바뀌었다는 증거가 되지는 않습니다.

3단계: 새 연결로 규칙 매칭 확인

클라이언트를 「규칙」 모드로 전환합니다. 전역 모드나 직접 연결 모드에서는 이 트래픽 분기 목록을 검증하기 어렵습니다.
대상 앱의 기존 연결을 끊거나 「연결」 페이지에서 해당 연결을 종료한 다음 테스트 도메인에 다시 접속합니다.
새 연결의 대상 도메인, 대상 IP, 일치한 규칙과 정책 체인을 확인해 GEOSITE, GEOIP, MATCH 중 어떤 규칙이 적용되었는지 살펴봅니다.
설정은 한 번에 하나씩만 변경하고, 다시 불러온 뒤 테스트를 반복해 결과를 기록하세요.

데이터베이스를 업데이트해도 기존 연결은 자동으로 새 경로를 선택하지 않습니다. 브라우저가 HTTP/2 또는 HTTP/3 연결을 재사용할 수도 있으므로 페이지를 새로고침해도 완전히 새로운 연결이 생긴다고 볼 수 없습니다. 시스템 프록시와 TUN을 함께 사용한다면 규칙을 점검하기 전에 테스트 앱의 트래픽이 현재 코어로 들어가는지 확인하세요.

자주 발생하는 문제: 다운로드 실패, 분류 누락, 규칙 미일치

브라우저에서는 데이터베이스 주소가 열리지만 코어에서는 다운로드 실패

브라우저는 프록시를 사용했을 수 있으며, 코어의 리소스 다운로드 경로와 DNS 상태 또는 시작 단계에서 사용할 수 있는 정책은 브라우저와 다를 수 있습니다. 두 경로를 동일하게 보면 안 됩니다. 먼저 로그에서 실제 다운로드 주소와 실패 단계를 확인하세요. 연결 시간 초과라면 네트워크 경로를, HTTP 404라면 배포 주소를 우선 점검합니다. 파싱에 실패하면 HTML 오류 페이지나 잘못된 형식의 파일을 내려받지 않았는지 확인하세요.

처음 실행할 때 데이터베이스가 없으면 의존성 순환이 발생할 수도 있습니다. 규칙을 불러오려면 데이터베이스가 필요한데, 데이터베이스 다운로드에는 아직 사용할 수 없는 프록시 경로가 필요한 상황입니다. 연결 가능한 네트워크에서 필요한 파일을 먼저 받아 실제 작업 디렉터리에 넣은 뒤 코어를 시작할 수 있습니다. 파일을 수동으로 배치한 뒤에도 이후 업데이트를 위해 올바른 데이터 출처 설정을 유지하세요.

업데이트는 성공했지만 GeoSite 분류가 없다는 오류가 표시됨

대개 규칙 이름과 데이터 소스가 일치하지 않는 경우입니다. 먼저 데이터 배포 프로젝트에서 제공하는 분류 목록을 확인한 뒤 규칙의 철자와 분류 속성을 점검하세요. 특정 구독에서 사용하는 전용 분류 이름을 모든 데이터베이스에 공통으로 있는 표준 이름처럼 취급하지 마세요. 확장자를 바꿔 해결하려고 해서도 안 됩니다.

중국 내 웹사이트 접속이 여전히 MATCH에 일치함

다음 순서로 확인하세요. 해당 도메인이 현재 GeoSite 분류에 포함되어 있는지, 앞선 다른 규칙이 먼저 일치하지 않았는지, 연결에 도메인만 있고 GeoIP 규칙에는 no-resolve가 지정되어 있는지, 최종 적용된 설정이 구독 업데이트로 덮어쓰이지 않았는지 확인합니다. 데이터베이스에서 해당 항목이 실제로 누락된 것을 확인한 뒤 범위가 명확한 DOMAIN 또는 DOMAIN-SUFFIX 규칙 추가를 고려하세요.

기본 개념을 더 알아보려면 용어집을, DNS·규칙·코어의 연동 방식을 알아보려면 프로토콜 안내서를 참고하세요. 문제를 진단할 때는 기존 설정과 로그를 보존해야 합니다. 데이터베이스, 노드, DNS를 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다.