GeoIP·GeoSite 데이터베이스 설정 및 업데이트 가이드

먼저 구분하기: IP 위치 데이터베이스, 도메인 분류 데이터베이스, 구독

노드 구독 업데이트에 성공해도 분류 데이터베이스까지 업데이트된 것은 아닙니다. 구독에는 보통 노드, 정책 그룹, 규칙이 포함되지만 GeoIP와 GeoSite는 코어가 읽는 로컬 데이터 파일입니다. 특정 도메인이 갑자기 기본 규칙으로 처리된다면 구독 업데이트를 반복하기보다 규칙 순서, 분류 존재 여부, 데이터베이스 로드 상태를 각각 확인하세요.

이 글은 mihomo 코어를 기준으로 설명합니다. 원본 Clash, 일부 구버전 Premium, 현재 mihomo는 지원하는 설정 항목이 서로 다르므로 아래 설정을 Clash라는 이름의 모든 프로그램에 그대로 적용할 수는 없습니다. 먼저 클라이언트의 코어 정보나 시작 로그에서 실제 코어를 확인하세요. 명령줄에서는 mihomo -v를 실행해 버전 정보를 확인할 수 있습니다.

파일	저장 데이터	주요 사용처
`Country.mmdb`	IP 주소와 국가·지역 매핑	`geodata-mode: false`일 때 GeoIP 조회
`geoip.dat`	태그별 IP 대역 모음	`geodata-mode: true`일 때 GeoIP 조회
`GeoSite.dat`	태그별 도메인 모음	`GEOSITE` 규칙 및 도메인 매칭

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

분류 태그에 맞는 데이터 출처 선택

mihomo에서 자주 사용하는 데이터 출처로는 MetaCubeX의 meta-rules-dat 프로젝트가 있습니다. 도메인 분류에는 domain-list-community와 이를 기반으로 한 빌드가 널리 쓰이며, IP 분류에도 여러 GeoIP 빌드 프로젝트가 있습니다. 중요한 것은 다운로드 속도가 아니라 파일 형식, 포함된 태그, 관리자의 릴리스 안내를 확인하는 것입니다.

규칙에 GEOSITE,cn,DIRECT를 썼다면 도메인 데이터베이스에 cn 분류가 있어야 합니다.
규칙에 서비스 이름을 썼다고 해서 모든 데이터 출처에 같은 이름의 분류가 있는 것은 아닙니다. 데이터베이스를 바꾼 뒤에는 설정을 다시 테스트하세요.
일반 텍스트 도메인 목록, 규칙 모음 YAML, 다운로드 실패 시 표시되는 HTML 페이지를 GeoSite.dat로 저장하지 마세요.
데이터 출처를 통일하면 분류 차이를 줄일 수 있지만, 업데이트 안내는 계속 확인해야 합니다. 데이터가 바뀌면 규칙의 매칭 결과도 달라질 수 있습니다.

설치 경로가 아닌 코어 데이터 디렉터리 찾기

그래픽 클라이언트의 프로그램 디렉터리, 설정 디렉터리, 코어 데이터 디렉터리는 서로 다를 수 있습니다. Windows에서는 코어가 서비스 프로세스로 실행되어 현재 사용자가 직접 프로그램을 실행할 때와 다른 디렉터리를 읽기도 합니다. 시작 로그에서 설정·데이터베이스 로드 경로나 다운로드 경로를 먼저 확인하세요. 클라이언트에 ‘설정 폴더 열기’ 기능이 있어도 그 안의 파일이 코어에서 실제로 사용하는 데이터인지 확인해야 합니다.

명령줄로 배포할 때는 -d 옵션으로 작업 디렉터리를 지정할 수 있습니다. 아래 명령은 데이터 디렉터리를 현재 사용자의 .config/mihomo로 지정하고 해당 디렉터리에서 설정을 읽습니다. 경로가 미리 존재해야 하며, 그 안에 사용할 수 있는 config.yaml이 있어야 합니다.

mihomo -d "$HOME/.config/mihomo" \
  -f "$HOME/.config/mihomo/config.yaml"

이 예시는 Unix 계열 셸 기준이며 모든 클라이언트의 기본 경로는 아닙니다. Linux는 파일 이름의 대소문자를 구분합니다. 배포 파일 이름이 geosite.dat여도 저장할 때는 코어가 기대하는 GeoSite.dat 이름을 사용하세요. Country.mmdb도 마찬가지입니다. 디렉터리를 잘못 찾으면 파일을 백 번 바꿔도 코어가 읽지 않는 파일만 업데이트하게 됩니다.

수동 교체: 백업 후 테스트하고 재시작

오프라인 장비, 자동 다운로드 실패, 데이터 버전 고정, 데이터 출처 변경 직후에는 수동 업데이트가 유용합니다. 클라이언트가 데이터베이스를 다운로드하는 동안 파일을 덮어쓰지 마세요. 먼저 클라이언트를 종료하거나 해당 서비스를 중지하고 코어 프로세스가 끝났는지 확인해야 합니다.

현재 모드 기록. 최종 적용 설정에서 geodata-mode 값을 확인하세요. false이면 GeoIP에 MMDB를 사용하고, true이면 DAT를 사용합니다. GeoSite는 별도의 도메인 데이터베이스를 계속 사용합니다.
복구용 파일 보관. 교체할 기존 파일을 백업하고 출처와 다운로드 날짜를 기록하세요. 사용할 수 있는 유일한 파일을 바로 삭제하지 마세요.
임시 파일로 다운로드. HTTP 요청이 성공했는지 확인한 뒤 코어 작업 디렉터리로 옮기세요. 다운로드가 덜 된 파일을 정식 파일 이름으로 두지 마세요.
전체 설정 테스트. 실제 운영과 동일한 코어, 설정 파일, 데이터 디렉터리로 테스트해야 합니다.
코어 재시작. 화면 새로고침이나 연결 페이지를 다시 여는 것만으로는 데이터베이스가 다시 로드되지 않을 수 있습니다. 이후 시작 로그와 실제 규칙 매칭 결과를 확인하세요.

아래는 Bash에서 GeoSite.dat를 업데이트하는 예시입니다. 데이터 디렉터리를 확인했고 코어가 중지된 상태라고 가정합니다. 다른 데이터베이스는 실제 모드에 맞춰 각각 처리하세요. 확장자만 바꾸면 안 됩니다.

cd "$HOME/.config/mihomo" || exit 1

if [ -f GeoSite.dat ]; then
  cp -p GeoSite.dat GeoSite.dat.bak || exit 1
fi

curl --fail --location --retry 2 \
  --output GeoSite.dat.new \
  "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat" \
  && mv GeoSite.dat.new GeoSite.dat

mihomo -t -d "$PWD" -f "$PWD/config.yaml"

curl --fail은 일반적인 HTTP 오류가 발생하면 실패를 반환하지만, 파일 내용이 올바르다는 것까지 보장하지는 않습니다. 형식과 분류가 유효한지는 코어에서 확인해야 합니다. 테스트에 실패하면 오류 내용을 보관하고 백업을 복원하세요. 기존 파일이 있다면 cp -p GeoSite.dat.bak GeoSite.dat를 실행한 뒤 다시 테스트하면 됩니다. 테스트를 통과한 다음에만 서비스를 시작하세요.

자동 업데이트: geox-url과 업데이트 간격

해당 항목을 지원하는 mihomo에서는 geox-url로 다운로드 출처를 지정하고, geo-auto-update로 주기 업데이트를 제어하며, geo-update-interval의 단위는 시간입니다. 다운로드 주소만 설정한다고 정기 업데이트가 활성화되는 것은 아닙니다. 아래는 최상위 설정 항목 예시이므로 기존 설정에 병합해야 합니다. 노드와 정책 그룹을 포함한 전체 설정 파일은 아닙니다.

# 최상위 항목이며 dns, rules와 같은 수준
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"

geoip는 geoip.dat에 해당합니다. 이 예시는 DAT 모드를 활성화해 GeoIP 규칙에서 해당 파일을 사용합니다.
geosite는 GeoSite.dat에 해당하며, GEOSITE 도메인 분류에 필요합니다.
mmdb는 Country.mmdb에 해당하며 MMDB 모드로 전환할 때 사용합니다. 출처를 설정했다고 해서 매번 모든 파일을 다운로드해야 하는 것은 아닙니다.
24는 24시간을 뜻합니다. 매일 자정이나 24분을 의미하지 않습니다. 기기가 절전 상태이거나 코어가 종료되어 있으면 상시 실행 서비스처럼 업데이트될 것으로 기대할 수 없습니다.

처음 시작할 때 파일이 없으면 다운로드가 시작될 수 있습니다. 하지만 다운로드에 필요한 연결이 아직 로드되지 않은 분류 규칙이나 사용할 수 없는 프록시에 의존하면 시작 과정에서 의존성 문제가 생깁니다. 이럴 때는 재시작을 반복하며 실패 로그만 쌓기보다 작동하는 데이터베이스를 수동으로 넣은 뒤 업데이트 경로를 확인하는 편이 빠릅니다.

규칙 작성: GEOSITE를 먼저, GEOIP를 다음에

도메인 규칙은 도메인 분류를, IP 규칙은 대상 주소 분류를 기준으로 하므로 서로 다른 질문에 답합니다. ‘특정 서비스의 도메인’이라고 해서 ‘서버가 특정 국가나 지역에 있다’는 뜻은 아닙니다. 웹사이트가 해외 CDN을 이용하거나 같은 도메인에 여러 지역의 주소를 반환할 수 있습니다. 따라서 명확한 도메인 규칙을 먼저 두고, 범위가 넓은 IP 규칙을 뒤에 배치한 다음 MATCH를 마지막에 둡니다.

아래 예시는 기존 설정에 PROXY라는 이름의 정책 그룹이 정의되어 있다고 가정합니다. 이름은 대소문자를 구분하므로 실제 정책 그룹 이름과 정확히 일치시켜야 합니다. 규칙만 복사하고 참조하는 아웃바운드를 빠뜨리지 마세요.

mode: rule

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

규칙별 매칭 동작 이해하기

DOMAIN-SUFFIX는 특정 도메인에 적용하는 명시적 예외입니다. 범위가 넓은 분류 규칙에 먼저 매칭되지 않도록 앞에 배치합니다. 여기서 example.com은 문법 예시일 뿐입니다.
GEOSITE,cn,DIRECT는 도메인 데이터베이스의 cn 분류와 매칭됩니다. 도메인 분류를 판단할 때 실제 IP로 먼저 해석할 필요는 없습니다.
GEOIP,private,DIRECT,no-resolve는 사설 주소 분류를 사용합니다. 해당 태그는 선택한 데이터 출처에서 지원해야 합니다. MMDB 모드와 DAT 모드가 완전히 같은 태그를 제공한다고 가정하지 마세요.
GEOIP,CN,DIRECT는 대상 IP를 기준으로 국가를 판단합니다. 연결에 도메인만 있으면 IP를 조회하기 위해 DNS 해석이 발생할 수 있습니다.
MATCH,PROXY는 앞선 규칙에 매칭되지 않은 연결을 처리합니다. ‘자동 판별’ 기능이 아니라 마지막 기본 규칙입니다.

no-resolve는 DNS 유출 방지 옵션이 아닙니다

no-resolve는 해당 IP 규칙과 매칭하기 위해 도메인을 능동적으로 해석하지 않는다는 뜻입니다. 연결에 사용할 수 있는 대상 IP가 이미 있으면 규칙에 매칭될 수 있습니다. 도메인만 있고 적용 가능한 IP가 없다면 뒤의 규칙을 계속 확인합니다. 모든 GEOIP 규칙에 이 옵션을 넣으면 DNS 해석 결과에 의존하는 직접 연결 규칙이 적용되지 않아 더 많은 연결이 MATCH로 넘어갈 수 있습니다.

fake-ip 모드에서도 GeoSite는 계속 작동합니다. 코어는 fake-ip 매핑을 통해 도메인과 연결할 수 있지만, 그렇다고 GEOIP에서 198.18.0.0/16 대역의 합성 주소를 서버의 실제 위치로 취급해야 한다는 뜻은 아닙니다. 문제를 확인할 때는 도메인, 실제 DNS 응답, 매칭된 규칙을 함께 살펴보세요. 연결 목록의 주소 하나만 보고 판단하면 안 됩니다.

업데이트 후에도 매칭되지 않을 때: 로그로 원인 구분하기

증상	우선 확인할 항목	조치
시작 시 분류가 없다는 오류 발생	규칙 태그와 데이터베이스 출처가 일치하지 않음	해당 출처의 분류 목록을 확인하고 규칙을 수정하거나 기존 데이터베이스로 되돌리기
데이터베이스 파싱 실패	파일 형식 오류, 다운로드 미완료 또는 실제 내용이 웹페이지임	백업을 복원하고 임시 파일로 다시 다운로드한 뒤 설정 테스트 실행
로그에 파일이 없어 다운로드한다는 메시지가 계속 표시됨	디렉터리, 대소문자 또는 실제 실행 계정이 잘못됨	코어 시작 인수와 서비스 작업 디렉터리 확인
정기 업데이트 다운로드 시간 초과	다운로드 도메인의 DNS 해석, 네트워크 경로, 프록시 사용 가능 여부	먼저 수동 업데이트로 시작 문제를 해결한 뒤 다운로드 경로를 별도로 테스트
데이터베이스 로드는 성공했지만 기본 규칙으로 처리됨	규칙 순서, 분류 내용 또는 연결에 도메인이 없는 경우	출구 IP만 보지 말고 해당 연결의 규칙 매칭 정보를 확인

한 번에 변수 하나만 변경하세요. 먼저 규칙은 그대로 두고 파일을 업데이트해 정상 시작되는지 확인한 다음 규칙 순서를 조정하고, 마지막으로 geodata-mode나 데이터 출처를 바꾸세요. 세 가지를 한꺼번에 바꾸면 로그만 복잡해지고 원인을 더 빨리 찾을 수는 없습니다.

검증할 때는 먼저 클라이언트가 규칙 모드인지 확인하고 대상 앱의 기존 연결을 끊은 뒤 새 요청을 보내세요. 기존 TCP 연결은 규칙이나 데이터베이스가 바뀌어도 자동으로 다른 출구로 이동하지 않습니다. 브라우저의 연결 재사용도 확인을 방해할 수 있습니다. 문제를 확인 중인 도메인으로 테스트하고 연결 기록에서 매칭된 규칙 유형과 내용, 최종 정책 경로를 확인하세요.

일시적으로 로그 수준을 높였다면 문제 해결 후 원래 설정으로 되돌리세요. 로그를 공유하기 전에 구독 URL, 액세스 토큰, 노드 인증 정보, 컨트롤 인터페이스 키를 가려야 합니다. 데이터베이스 문제를 확인하는 데 필요한 것은 로드 경로와 오류가 기록된 행이지, 계정 정보 전체가 아닙니다.

유지 관리 기록: 되돌릴 수 있는 구성 조합 보관

코어 정보 기록: mihomo -v 출력 결과를 기록해 두세요. 클라이언트를 업그레이드한 뒤에도 구버전 코어 기준으로 항목 지원 여부를 판단하는 일을 막을 수 있습니다.
데이터 출처 기록: 저장소, 다운로드 날짜, 사용한 태그, geodata-mode를 기록해 매칭 결과가 바뀐 이유를 확인할 수 있게 하세요.
작동하는 설정 보관: 데이터베이스를 백업할 때 관련 설정도 함께 저장해야 되돌린 뒤 새 규칙이 기존 분류를 참조하는 문제를 피할 수 있습니다.
두 업데이트 경로를 따로 확인: 구독은 노드와 설정을 관리하고, 지리 데이터 업데이트는 분류 파일을 관리합니다. 한쪽의 성공 메시지가 다른 쪽의 성공을 대신하지 않습니다.

최종 점검에서는 세 가지만 확인하면 됩니다. 코어가 올바른 디렉터리의 파일을 로드하는지, 규칙에서 참조한 분류가 실제로 존재하는지, 새 연결이 예상한 정책에 매칭되는지 확인하세요. 모두 충족한 뒤 업데이트 주기와 다운로드 출처를 조정하면 됩니다. 데이터베이스가 최신이라고 해서 개인의 분류 요구에 반드시 맞는 것은 아닙니다. 명시적인 규칙은 항상 범위가 넓은 분류보다 앞에 두세요.