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

GeoIP, GeoSite, 규칙 세트의 차이

mihomo의 트래픽 분기에서 규칙은 매칭 순서를 정하고, 데이터베이스는 매칭에 필요한 분류 데이터를 제공합니다. 데이터베이스를 업데이트해도 규칙 순서는 바뀌지 않으며 구독 노드도 교체되지 않습니다. 특정 사이트가 잘못된 프록시 그룹을 이용하는 경우 현재 설정, 데이터베이스 내용, 연결에 실제로 적용된 규칙을 각각 확인하세요.

주요 지리 데이터베이스와 용도
파일	데이터 내용	사용 조건
`geoip.dat`	국가 또는 카테고리별 IP 주소 범위	`geodata-mode: true`일 때 GEOIP에 사용
`Country.mmdb`	MMDB 형식의 IP 위치 데이터	`geodata-mode: false`일 때 GEOIP에 사용
`geosite.dat`	도메인 및 사이트 분류 모음	GEOSITE 규칙 및 관련 도메인 매칭 기능에 사용

geodata-mode는 GEOIP 데이터 백엔드를 선택하는 설정입니다. 이를 끈다고 GEOSITE를 사용할 수 없게 되는 것은 아닙니다. GeoSite는 연결에 포함된 도메인이나 코어가 확인한 도메인으로 매칭하고, GeoIP는 대상 IP를 기준으로 매칭합니다. 도메인 분류만으로 서버의 실제 위치를 알 수 없으며, IP 위치만으로 특정 서비스를 직접 연결해야 하는지도 판단할 수 없습니다.

rule-providers는 별도의 메커니즘입니다. 일반적으로 RULE-SET으로 참조하며 YAML, 텍스트, MRS 등의 규칙 세트 파일과 자체 업데이트 설정을 사용합니다. geosite.dat만 업데이트해도 모든 규칙 제공자가 함께 새로 고쳐지는 것은 아닙니다.

코어, 데이터 출처 및 작업 디렉터리 확인

이 문서의 설정은 mihomo를 기준으로 합니다. 구형 Clash 클라이언트는 서로 다른 코어를 탑재했을 수 있으므로 화면에 표시된 이름만 보고 호환성을 판단하지 마세요. 먼저 클라이언트의 코어 정보나 시작 로그에서 mihomo가 실행 중인지 확인하세요. 명령줄로 설치했다면 아래 명령을 실행해 실제 버전을 기록한 뒤 설정을 점검하세요.

mihomo -v
mihomo -h

규칙의 분류 이름과 일치하는 데이터 소스 선택

대표적인 데이터 소스로는 MetaCubeX의 meta-rules-dat 릴리스 파일과 Loyalsoldier의 관련 규칙 데이터 프로젝트가 있습니다. 프로젝트마다 사용하는 상위 데이터, 추출 방식, 분류 이름이 다를 수 있습니다. 파일명이 같아도 cn, github, 광고 분류가 동일하게 포함된다는 뜻은 아닙니다.

데이터 프로젝트의 릴리스 페이지에서 파일 형식을 확인한 다음 실제 다운로드 URL을 복사하세요. 웹페이지 주소를 데이터베이스 파일로 저장하면 안 됩니다.
GeoIP DAT 파일과 MMDB 파일은 확장자만 바꿔 서로 대체할 수 없습니다.
경량 버전은 저장 공간과 로딩 부담을 줄일 수 있지만, 기존 규칙에서 참조하는 분류가 빠질 수 있습니다.
정상 작동하는 설정과 데이터를 먼저 백업한 뒤 데이터 소스를 바꾸세요. 한 번에 여러 변수를 바꾸지 않는 것이 좋습니다.

코어가 실제로 읽는 경로 확인

코어를 직접 실행할 때 -d는 작업 디렉터리, -f는 설정 파일을 지정합니다. Clash 클라이언트에서 실행한다면 코어 시작 로그를 확인하거나 클라이언트가 제공하는 데이터 디렉터리 메뉴를 이용하세요. 클라이언트 설치 디렉터리, 구독 저장 디렉터리, 코어 실행 디렉터리는 서로 다를 수 있습니다.

mihomo -d /srv/mihomo -f /srv/mihomo/config.yaml

위 경로는 Linux 예시입니다. 이 배포 방식에서는 보통 /srv/mihomo에서 데이터베이스를 관리합니다. Windows와 macOS에서는 로그에 표시된 실제 경로를 사용하세요. Linux는 파일명의 대소문자를 구분하므로 MMDB 파일을 직접 교체할 때 특히 Country.mmdb의 철자를 확인해야 합니다.

geodata 자동 업데이트 설정

아래 예시는 MetaCubeX에서 배포하는 데이터베이스를 사용하고 GEOIP 백엔드로 DAT를 선택합니다. 다음 항목을 설정 최상위에 병합하세요. dns, tun 또는 프록시 그룹 내부에 넣지 마세요. 이미 geox-url이 있다면 중복 키를 만들지 말고 기존 항목을 수정하세요.

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"
  mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb"

geo-auto-update: true: 코어의 지리 데이터베이스 자동 업데이트를 활성화합니다.
geo-update-interval: 24: 업데이트 간격은 24시간입니다. 24초가 아닙니다.
geox-url.geoip: DAT 형식 GEOIP 데이터 소스입니다.
geox-url.geosite: GeoSite 데이터 소스입니다.
geox-url.mmdb: MMDB 데이터 소스입니다. MMDB 백엔드로 전환할 때 사용합니다.

설정에 다운로드 URL을 지정한다고 해서 실행할 때마다 모든 파일을 강제로 다시 받는 것은 아닙니다. 실제 로딩과 업데이트 여부는 현재 코어의 로그를 기준으로 확인하세요. 저장 후 설정을 검증하고 클라이언트에서 다시 불러오세요. 클라이언트가 지리 데이터베이스를 별도로 관리한다면 해당 기능이 이 설정을 덮어쓰는지도 확인해야 합니다.

첫 실행 시 데이터베이스가 없으면 규칙을 불러오기 전에 코어가 데이터를 다운로드해야 할 수 있습니다. 이때 다운로드에 필요한 네트워크 연결이 아직 시작되지 않은 프록시에 의존하면 시작 과정에서 의존성 문제가 생깁니다. 사용 가능한 네트워크로 로컬 파일을 먼저 준비하고, 실행을 마친 뒤 자동 업데이트가 작동하는지 확인하세요.

GeoIP 및 GeoSite 파일 수동 교체

다운로드가 제한되거나 기기 저장 공간이 부족한 경우, 또는 이전 데이터베이스로 되돌려야 할 때는 수동 업데이트가 편리합니다. 사용 중인 대상 파일에 직접 계속 쓰지 말고, 파일명만으로 다운로드 성공 여부를 판단하지도 마세요.

실행 정보를 기록합니다. 코어 버전, 작업 디렉터리, 설정 경로, 현재 geodata-mode 값을 확인하세요.
기존 파일을 백업합니다. 현재 정상 작동하는 geoip.dat, geosite.dat 또는 Country.mmdb를 백업 디렉터리에 복사하세요.
임시 경로에 다운로드합니다. HTTP 다운로드가 성공했는지, 파일 크기가 적절한지 확인하세요. 로그인 페이지나 오류 페이지가 내려받아졌다면 올바른 파일을 다시 받으세요.
코어를 중지한 뒤 교체합니다. 클라이언트 코어를 종료하거나 해당 서비스를 중지한 다음 새 파일을 실제 작업 디렉터리에 넣으세요. 기존 파일명을 유지하고 올바른 읽기 권한을 설정하세요.
테스트한 뒤 다시 시작합니다. 동일한 작업 디렉터리에서 설정을 검증하고, 실행 후 데이터베이스 로딩 로그와 새 연결의 매칭 결과를 확인하세요.

mihomo -t -d /srv/mihomo -f /srv/mihomo/config.yaml

-t는 설정을 테스트하는 옵션이지 실제 웹사이트 접속을 완료하는 옵션은 아닙니다. 테스트에 필요한 데이터가 없으면 다운로드가 시작되거나 오류가 발생할 수 있습니다. Linux 서비스 배포에서는 테스트 실행 계정과 서비스 계정의 디렉터리 접근 권한이 같은지도 확인하세요.

파일을 교체해도 실행 중인 코어가 즉시 다시 읽는 것은 아닙니다. 코어를 중지한 뒤 파일을 교체하고 다시 시작하는 편이 확실합니다. 새 데이터에서 분류가 누락되거나 로딩에 실패하면 백업 파일과 기존 설정을 복구한 뒤 다시 실행해 확인하세요. 코어, 구독, 데이터베이스를 한꺼번에 바꾸면 원인을 찾기 어렵습니다.

GEOIP 및 GEOSITE 규칙 작성법

아래 예시는 설정에 PROXY라는 정책 그룹이 이미 있다고 가정합니다. DIRECT는 내장 직결 정책입니다. 실제 프록시 그룹 이름이 “节点选择”이라면 예시의 PROXY를 해당 이름으로 바꾸세요. 정책 이름은 설정에 지정된 이름과 일치해야 합니다.

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - GEOSITE,github,PROXY
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

위에서 아래로 확인해 처음 일치한 규칙 적용

DOMAIN-SUFFIX는 명시적인 도메인 예외를 처리합니다. GEOSITE,github,PROXY는 데이터베이스의 GitHub 분류와 매칭합니다. GEOSITE,cn,DIRECT는 해당 데이터 소스에서 정의한 cn 도메인 모음과 매칭합니다. GEOIP,CN,DIRECT,no-resolve는 대상 IP를 확인하며, 마지막으로 MATCH가 나머지 연결을 처리합니다.

MATCH를 맨 앞에 두면 뒤의 규칙은 매칭될 기회가 없습니다. 범위가 넓은 분류를 정확한 예외보다 앞에 배치해도 예외가 적용되지 않을 수 있습니다. 일반적으로 도메인 규칙을 IP 기준 규칙보다 먼저 두지만, 구체적인 순서는 실제 사용 목적에 따라 정해야 합니다.

no-resolve는 DNS 조회 방식을 제어하며 IP 매칭을 건너뛰는 옵션이 아닙니다

no-resolve는 이 IP 규칙을 확인하기 위해 대상 도메인을 별도로 조회하지 말라는 뜻입니다. 연결에 사용할 수 있는 대상 IP가 이미 있다면 GEOIP 매칭은 계속 수행할 수 있습니다. 전역 DNS를 끄는 옵션도 아니며 DNS 유출을 막는 단독 스위치도 아닙니다.

예를 들어 아직 IP가 확인되지 않은 도메인이 앞선 GEOSITE 규칙에 매칭되지 않은 상태에서 no-resolve가 붙은 GEOIP 규칙을 만나면, 뒤의 규칙으로 넘어갈 수 있습니다. 해당 도메인을 항상 직결하려면 no-resolve만 제거하기보다 정확한 도메인 규칙을 추가하는 편이 관리하기 쉽습니다.

업데이트 후에도 적용되지 않을 때 점검 순서

증상, 확인 항목 및 조치 방향
증상	우선 확인할 항목	조치 방향
다운로드 시간 초과	DNS, TLS, 다운로드 도메인 접속 가능 여부	먼저 정상적인 다운로드 경로를 복구하고, 필요하면 파일을 수동으로 준비합니다.
파일을 읽을 수 없음	파일 형식, 다운로드한 내용, 파일 전송 완료 여부	해당 DAT 또는 MMDB 파일을 다시 받습니다.
규칙에서 참조한 분류가 없음	데이터 소스 및 경량 버전에 포함된 분류 범위	해당 분류가 포함된 데이터를 선택하거나 분류 규칙을 수정합니다.
파일은 업데이트됐지만 트래픽 분기가 그대로임	작업 디렉터리, 백엔드 선택, 규칙 순서	코어가 실제로 불러온 파일과 매칭된 규칙을 확인합니다.
구독을 새로 고친 뒤 설정이 초기화됨	최종 적용 설정	로컬 항목을 지속적으로 유지되는 덮어쓰기 설정으로 옮깁니다.

페이지를 새로 고치는 데 그치지 말고 새 연결로 검증하세요.

먼저 규칙 모드인지 확인한 다음 클라이언트의 연결 기록을 열어 대상 도메인, 대상 IP, 매칭 규칙, 정책 체인을 확인하세요. 전역 모드에서는 최종 프록시 출구만 보고 GEOIP나 GEOSITE가 예상대로 트래픽 분기에 사용됐는지 판단할 수 없습니다.

브라우저는 기존 HTTP/2 또는 QUIC 연결을 재사용할 수 있습니다. 규칙이나 데이터를 바꾼 뒤에는 기존 연결을 닫고 새 요청을 보내세요. 같은 탭에서 새로 고침만 해서는 연결이 다시 생성되지 않을 수 있습니다. 검증할 때는 직결되어야 하는 도메인, 프록시를 거쳐야 하는 도메인, IP를 알고 있는 대상의 결과를 각각 하나 이상 기록하세요.

DNS 문제와 데이터베이스 문제 구분

CDN, DNS 캐시, 서로 다른 리졸버로 인해 같은 도메인도 다른 IP를 반환할 수 있습니다. 따라서 GEOIP 결과가 바뀌었다고 데이터베이스 업데이트에 실패한 것은 아닙니다. TUN이나 fake-ip를 사용한다면 코어가 확인한 도메인과 실제 대상 정보도 살펴보세요. 앱에 표시되는 가상 주소를 공인 IP의 실제 위치로 간주하면 안 됩니다.

안정적으로 관리하려면 현재 사용하는 파일과 코어를 먼저 확인하고, 규칙 분류를 검증한 다음 실제 연결을 살펴보세요. 데이터베이스 업데이트는 분류 기준을 새로 고치는 작업입니다. DNS, 규칙 순서, 프록시 그룹 선택은 각각 별도로 설정해야 합니다. 기본 개념은 개념 빠른 참조에서, 설치 단계는 전 플랫폼 가이드에서 확인하세요.