GeoIP 및 GeoSite 데이터베이스 업데이트 방법: mihomo 규칙 데이터 관리와 주요 오류

GeoIP 및 GeoSite는 각각 어떤 문제를 해결할까

mihomo가 프록시 규칙을 읽을 때는 도메인, IP 주소 또는 기타 연결 속성을 규칙과 하나씩 비교해야 합니다. GeoIP와 GeoSite는 모두 규칙 판단에 필요한 데이터지만 처리 대상은 서로 다릅니다. 데이터베이스가 업데이트되지 않았다고 해서 모든 프록시 연결이 끊기는 것은 아닙니다. 보통은 지역 판정이 오래되거나 새 도메인이 매칭되지 않거나, 시작 시 데이터 파일이 없다는 오류가 표시됩니다.

GeoIP는 대상 IP의 지역을 기준으로 분류

GeoIP 데이터는 IP 주소 대역과 국가·지역 등의 정보 간 대응 관계를 기록합니다. 설정의 GEOIP,CN,DIRECT는 연결 대상 IP를 확인한 뒤 해당 주소가 CN 분류에 속하면 DIRECT 정책을 사용한다는 의미입니다. 대표적인 파일로는 Country.mmdb와 geoip.dat가 있으며, 실제로 어떤 파일을 읽는지는 mihomo 설정, 클라이언트 버전 및 데이터 모드에 따라 달라집니다.

GeoIP 판정은 IP 계층에서 이루어집니다. 도메인이 잘못된 주소로 먼저 해석되거나 DNS 응답이 오염되었거나, 앞선 도메인 규칙이 이미 매칭되었다면 뒤의 GEOIP 규칙은 완료된 매칭 결과를 바꾸지 못합니다. 따라서 “중국 본토 웹사이트가 프록시로 연결된다”고 해서 데이터베이스 날짜만 확인해서는 안 되며, 규칙 순서와 DNS 결과도 함께 점검해야 합니다.

GeoSite는 도메인 집합을 기준으로 분류

GeoSite는 정리된 도메인 집합을 저장합니다. 예를 들어 GEOSITE,cn,DIRECT는 cn 분류에 포함된 도메인을 매칭하고, GEOSITE,category-ads-all,REJECT는 해당 분류를 처리하는 데 사용할 수 있습니다. 대표적인 데이터 파일명은 geosite.dat입니다. GeoSite는 서버 IP가 어느 국가에 속하는지 판단하지 않고, 요청에 포함된 도메인을 직접 처리합니다.

도메인 서비스에 새 진입점이 추가되거나 CDN 도메인이 변경되거나 API가 교체되면 이전 버전의 GeoSite에 해당 기록이 없을 수 있습니다. 이 경우 연결은 보통 뒤에 있는 규칙, 예를 들어 MATCH로 넘어가며 “데이터베이스가 오래되었습니다”라는 알림이 표시되지는 않습니다. 이 때문에 GeoSite 문제를 노드나 구독 오류로 잘못 판단하는 경우가 많습니다.

데이터 유형	주요 입력	대표 규칙	주요 파일
GeoIP	대상 IP 주소	`GEOIP,CN,DIRECT`	`Country.mmdb`、`geoip.dat`
GeoSite	요청 도메인	`GEOSITE,cn,DIRECT`	`geosite.dat`
Rule Provider	외부 규칙 항목	`RULE-SET,private,DIRECT`	YAML, 텍스트 또는 바이너리 규칙 집합

업데이트 전에 커널, 모드와 실제 데이터 디렉터리 확인

같은 데스크톱 클라이언트라도 시기에 따라 Clash Premium, Clash Meta 또는 mihomo 커널을 사용했을 수 있습니다. 이전 설정 디렉터리에 같은 이름의 파일이 여러 개 남아 있을 수도 있습니다. 수동으로 교체하기 전에 클라이언트의 “정보”, “커널” 또는 “실행 로그”에서 현재 커널을 확인하세요. 계속 유지 관리되는 mihomo 안정 버전을 사용하는 것이 좋으며, 업데이트 전 커널 버전과 데이터 파일의 수정 시간을 기록해 두세요.

실행 인자로 디렉터리 확인

mihomo의 데이터 디렉터리는 보통 시작 인자 -d로 지정됩니다. 예를 들어 시작 명령에 mihomo -d /home/user/.config/mihomo가 있다면 데이터베이스는 실행 파일이 있는 디렉터리가 아니라 해당 경로에 저장해야 합니다. 데스크톱 클라이언트는 자체 데이터 디렉터리를 전달하므로 운영체제만 보고 경로를 추측해서는 안 됩니다.

먼저 클라이언트의 “설정” → “설정 디렉터리” 또는 “데이터 디렉터리 열기” 메뉴를 이용하세요.
해당 메뉴가 없다면 실행 로그 첫 부분에서 configuration directory, home directory 또는 -d 뒤에 나오는 경로를 찾으세요.
Windows에서는 작업 관리자의 프로세스 세부 정보에서 실행 파일을 확인한 다음, 클라이언트 로그에서 시작 인자를 확인할 수 있습니다.
macOS 클라이언트의 데이터는 보통 사용자 라이브러리 안에 있지만 애플리케이션마다 컨테이너 디렉터리가 다르므로 로그와 클라이언트 메뉴를 기준으로 확인해야 합니다.
Linux 서비스를 systemd로 시작했다면 systemctl cat mihomo로 ExecStart 안의 -d 인자를 확인할 수 있습니다.

현재 MMDB를 사용하는지 DAT를 사용하는지 확인

mihomo는 여러 지리 데이터 형식을 지원합니다. geodata-mode: true가 활성화된 설정은 보통 geoip.dat 및 geosite.dat와 함께 사용합니다. 이 모드가 활성화되지 않은 설정은 Country.mmdb로 GEOIP를 판정할 수 있습니다. 버전에 따라 기본 동작이 달라질 수 있으므로 파일 존재 여부만으로 판단하지 말고 설정과 시작 로그를 함께 확인하세요.

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

geo-update-interval의 단위는 시간입니다. 24로 설정하면 커널이 하루 간격으로 데이터 업데이트를 확인합니다. 클라이언트가 실행 설정을 생성하는 경우 생성된 파일을 직접 수정하면 다음 시작이나 구독 전환 때 덮어써질 수 있습니다. 이러한 키는 클라이언트의 오버라이드, Mixin 또는 전역 확장 설정에 추가해야 합니다.

클라이언트 내장 업데이트 우선 사용

mihomo를 지원하는 클라이언트에는 보통 GeoData 또는 지리 데이터 업데이트 메뉴가 있습니다. 메뉴 이름은 버전에 따라 달라질 수 있으며, “설정” → “Clash 설정” → “GeoData” 또는 “설정” → “커널” → “지리 데이터 업데이트”에서 찾는 경우가 많습니다. 작업 중에는 버튼을 연속해서 누르지 마세요. 한 번의 다운로드에 수십 MB의 데이터가 포함될 수 있으므로 네트워크가 느리면 로그에 완료 상태가 표시될 때까지 기다려야 합니다.

먼저 현재 설정을 업데이트하고 활성화한 뒤 커널이 정상적으로 시작되는지 확인하세요.
“설정”에서 GeoData, 지리 데이터 또는 커널 데이터 페이지를 여세요.
GeoIP, GeoSite 또는 전체 업데이트를 각각 실행하세요.
화면에 완료가 표시될 때까지 기다린 다음 로그에서 download, unmarshal, permission denied 등의 메시지를 확인하세요.
설정을 다시 불러오세요. 클라이언트에 다시 불러오기 버튼이 없다면 애플리케이션을 완전히 종료한 뒤 다시 시작하세요.
연결 기록에서 알고 있는 도메인이 실제로 어떤 규칙에 매칭되었는지 확인하세요.

내장 업데이트의 장점은 클라이언트가 자신의 데이터 디렉터리를 알고 있으며 다운로드 후 올바른 파일명으로 저장할 수 있다는 점입니다. 서비스 모드나 관리자 보조 프로세스를 사용하는 데스크톱 클라이언트에서는 일반 사용자 프로세스에 디렉터리 쓰기 권한이 없을 때 발생하는 문제도 줄일 수 있습니다.

mihomo 자동 업데이트 활성화

라우터, 서버 또는 장시간 실행되는 데스크톱 기기는 mihomo가 정기적으로 데이터를 업데이트하도록 설정할 수 있습니다. geo-auto-update를 활성화하는 것 외에도 geox-url로 파일 유형별 주소를 지정할 수 있습니다. 주소는 해당 바이너리 파일을 직접 반환해야 하며, 릴리스 페이지나 브라우저 확인이 필요한 HTML 페이지를 반환해서는 안 됩니다.

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"

기기가 프록시를 통해서만 다운로드 주소에 접근할 수 있다면 먼저 커널이 시작된 후 외부 연결을 수립할 수 있는지 확인해야 합니다. 최초 시작 시 데이터베이스가 없는데 규칙은 GeoSite에 의존하면 “데이터베이스가 없어 시작할 수 없고, 커널이 시작되지 않아 다운로드할 수도 없는” 순환이 생깁니다. 이때는 먼저 읽을 수 있는 데이터 파일을 수동으로 넣은 뒤 자동 업데이트를 활성화하는 편이 안전합니다.

GeoIP 및 GeoSite 파일 수동 교체

클라이언트 내장 업데이트가 실패하거나 오프라인 기기를 유지 관리해야 하거나 현재 네트워크에서 데이터 소스에 접근할 수 없을 때는 수동으로 교체할 수 있습니다. 실행 중인 파일을 바로 덮어쓰지 말고, 먼저 임시 이름으로 다운로드한 뒤 커널을 중지하고 교체를 완료한 후 다시 시작하는 것이 올바른 절차입니다. 이렇게 하면 다운로드 중단으로 불완전한 파일이 남을 가능성을 줄일 수 있습니다.

일반적인 교체 절차

클라이언트에서 시스템 프록시와 TUN을 중지한 뒤 애플리케이션을 종료하세요. 서비스 모드라면 해당 백그라운드 서비스도 중지해야 합니다.
앞에서 확인한 데이터 디렉터리를 열고 기존 파일의 크기와 수정 시간을 기록하세요.
기존 파일의 이름을 geoip.dat.bak, geosite.dat.bak 또는 Country.mmdb.bak로 변경하세요.
새 파일을 같은 디렉터리에 복사하고 커널이 요구하는 정확한 파일명을 유지하세요.
현재 사용자 또는 서비스 계정에 읽기 권한이 있는지 확인하세요.
클라이언트를 시작하고 가장 처음 기록된 로그를 확인하세요. 설정 로딩이 완료된 뒤 시스템 프록시나 TUN을 다시 활성화하세요.
검증이 끝날 때까지 백업을 보관하고, 자주 사용하는 도메인 규칙이 정상적으로 작동하는 것을 확인한 후 삭제하세요.

Linux 또는 macOS에서는 먼저 임시 파일에 기록한 다음 같은 파일 시스템 안에서 파일명을 변경해 교체할 수 있습니다. 아래 명령은 mihomo의 실제 데이터 디렉터리에서 실행해야 합니다.

curl -L "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat" -o geoip.dat.new
curl -L "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat" -o geosite.dat.new

mv geoip.dat geoip.dat.bak
mv geosite.dat geosite.dat.bak
mv geoip.dat.new geoip.dat
mv geosite.dat.new geosite.dat

Windows에서 수동 교체 중 파일이 사용 중이라는 메시지가 표시되면 클라이언트 창을 닫았어도 커널 프로세스나 서비스가 계속 실행 중이라는 뜻입니다. 클라이언트에서 먼저 서비스를 중지하거나 “작업 관리자” → “세부 정보”에서 mihomo 프로세스가 종료되었는지 확인하세요. 사용 중이라는 경고를 무시하려고 반복해서 덮어쓰지 마세요.

컨테이너 및 라우터 추가 점검

Docker로 배포했다면 데이터베이스 디렉터리가 컨테이너에서 사용하는 -d 경로에 실제로 volume 마운트되어 있는지 확인하세요. 호스트의 마운트되지 않은 디렉터리만 교체하면 컨테이너 내부에는 변화가 없습니다. 업데이트 후 컨테이너를 다시 시작하고 로그에서 읽기 경로를 확인할 수 있습니다. OpenWrt와 같이 저장 공간이 제한된 기기는 사용 가능한 용량도 점검해야 합니다. 임시 다운로드 파일과 백업을 함께 보관하면 순간적으로 데이터 파일 두세 개에 해당하는 공간이 필요할 수 있습니다.

다운로드 실패 및 시작 오류 해결 방법

`context deadline exceeded` 또는 TLS 시간 초과

이러한 메시지는 보통 다운로드 주소의 연결 또는 전송이 제한 시간 안에 완료되지 않았다는 뜻입니다. 먼저 브라우저나 curl -I -L로 같은 주소가 리디렉션을 따라 정상적으로 열리는지 테스트한 뒤 DNS, 시스템 시간과 외부 연결 정책을 확인하세요. 시스템 시간이 몇 분만 어긋나도 TLS 인증에 실패할 수 있습니다. 연결에 프록시가 필요하다면 업데이트 요청이 실제로 사용 가능한 정책을 거치는지, GEOIP 또는 MATCH 규칙에 의해 작동하지 않는 노드로 전달되지 않는지 확인하세요.

403, 404가 반환되거나 HTML이 다운로드되는 경우

404는 보통 파일명, 릴리스 경로 또는 데이터 소스 구조가 변경되었다는 의미입니다. 403은 접근 빈도 제한, 네트워크 출구 제한 또는 추가 인증이 필요한 주소에서 자주 발생합니다. URL이 릴리스 안내 페이지를 가리켜 실제 다운로드 결과가 HTML인 경우도 있습니다. 그러면 mihomo는 이후 파싱 실패, 잘못된 형식 또는 데이터베이스 로딩 실패를 보고합니다. 직접 파일을 반환하는 주소로 변경하고 리디렉션 후 응답 유형과 파일 크기가 적절한지 확인하세요.

`permission denied` 또는 파일을 쓸 수 없는 경우

먼저 오류에 표시된 경로가 현재 데이터 디렉터리와 일치하는지 확인하세요. Windows 서비스 모드에서는 화면 프로세스와 백그라운드 서비스가 서로 다른 계정을 사용할 수 있으며, Linux systemd 서비스도 User=로 제한된 계정을 지정할 수 있습니다. 해당 서비스 계정이 디렉터리에 임시 파일을 만들고 파일명을 변경하며 업데이트 결과를 읽을 수 있어야 합니다. 기존 파일 하나에만 쓰기 권한을 추가해도 디렉터리에 쓸 수 없으면 계속 실패합니다.

`no such file`, MMDB를 열 수 없거나 GeoSite 로딩에 실패하는 경우

이러한 오류가 발생하면 먼저 파일명의 대소문자, 설정 모드와 디렉터리를 확인하세요. Linux에서는 GeoSite.dat와 geosite.dat를 서로 다른 파일로 인식합니다. 설정에서 geodata 모드를 활성화했는데 Country.mmdb만 넣었다면 GeoSite 규칙은 여전히 작동하지 않습니다. 반대로 MMDB에 의존하는 설정에는 geoip.dat만으로 충분하지 않습니다. 백업을 복원했을 때 시작된다면 새 파일이 불완전하거나 형식이 맞지 않거나 현재 커널과 호환되지 않는 출처일 가능성이 큽니다.

데이터베이스를 업데이트했는데 규칙이 여전히 적용되지 않는 이유

규칙 엔진은 설정에 적힌 순서대로 위에서 아래로 매칭하며, 한 번 매칭되면 보통 “더 적합한” 규칙을 계속 찾지 않습니다. 데이터베이스 업데이트는 GEOIP 또는 GEOSITE에서 조회할 수 있는 데이터만 바꿀 뿐 규칙 순서를 자동으로 조정하지 않습니다. 따라서 문제를 확인할 때는 연결 기록에서 대상 요청을 찾아 도메인, 대상 IP, 매칭된 규칙과 최종 정책을 확인해야 합니다.

앞선 규칙이 이미 요청을 가로챈 경우

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

이 설정에서는 example.com이 GeoSite의 cn 분류에 포함되어 있더라도 첫 번째 DOMAIN-SUFFIX 규칙이 먼저 Proxy에 매칭됩니다. GeoSite를 업데이트해도 앞선 규칙이 무시되지는 않습니다. 특정 규칙을 일시적으로 적절한 위치로 옮기고 다시 불러온 뒤 재시험해야 순서 문제인지 확인할 수 있습니다.

`no-resolve`가 GEOIP 적용 조건을 바꾸는 경우

GEOIP,CN,DIRECT,no-resolve의 기능 중 하나는 규칙 매칭을 위해 추가 DNS 조회를 능동적으로 실행하지 않도록 하는 것입니다. 현재 연결이 도메인만 가지고 있고 판단에 사용할 대상 IP가 아직 없다면 이 규칙은 예상대로 작동하지 않을 수 있습니다. 설정에 GEOSITE 도메인 규칙이 있다면 보통 먼저 도메인으로 분류한 뒤 GEOIP로 남은 IP 연결을 처리하는 편이 논리적으로 명확합니다.

DNS 모드와 스니핑 결과가 표시되는 도메인에 미치는 영향

TUN 모드에서는 애플리케이션이 IP에 직접 연결할 수도 있고 QUIC, 암호화 DNS 또는 내장 리졸버를 통해 요청을 보낼 수도 있습니다. mihomo가 도메인을 얻지 못하면 GeoSite에는 매칭할 입력이 없습니다. 도메인 스니핑을 활성화하면 일부 상황을 처리할 수 있지만 모든 연결에서 도메인이 복원된다고 보장할 수는 없습니다. 문제를 확인할 때 시스템 프록시 모드와 TUN 모드의 연결 세부 정보를 비교하여 기록에 전체 도메인이 표시되는지 확인하세요.

구독 원본이 아닌 실행 설정을 수정한 경우

데스크톱 클라이언트는 구독, 오버라이드 내용과 전역 설정을 임시 실행 설정으로 병합하는 경우가 많습니다. 캐시된 구독 YAML을 직접 수정하면 다음 구독 업데이트 때 원래대로 돌아가고, 실행 설정을 직접 수정하면 다음 설정 전환 때 사라집니다. 클라이언트의 “설정” → “오버라이드” 또는 “설정” → “전역 확장”에서 사용자 지정 항목을 저장한 뒤 로그나 설정 검사 기능으로 최종 결과를 확인해야 합니다.

Rule Provider가 GeoData와 함께 업데이트되지 않은 경우

RULE-SET이 참조하는 외부 규칙 집합은 rule-providers가 관리하며 자체 URL, 캐시 경로와 업데이트 간격을 사용합니다. geoip.dat와 geosite.dat를 업데이트해도 이 Provider는 새로 고쳐지지 않습니다. 실제로 매칭된 규칙이 RULE-SET이라면 클라이언트의 규칙 집합 페이지에서 업데이트를 실행하거나 해당 Provider의 interval과 다운로드 로그를 확인하세요.

반복 실행할 수 있는 유지 관리 체크리스트

일반적인 데스크톱 기기에서는 매일 데이터베이스를 수동으로 교체할 필요가 없습니다. 클라이언트나 mihomo가 24시간마다 한 번씩 확인하도록 설정하고, 분류 이상이 발생했을 때 정해진 절차로 원인을 찾는 편이 효율적입니다. 서버와 라우터는 데이터 디렉터리, 백업과 서비스 계정 권한을 함께 유지 관리 대상에 포함해야 합니다.

현재 mihomo 커널을 사용 중인지 확인하고 버전을 기록하세요.
시작 인자 또는 로그에서 실제 데이터 디렉터리를 확인하세요.
설정이 DAT 모드인지 MMDB 모드인지 확인하세요.
먼저 클라이언트 내장 메뉴를 통해 한 번 업데이트하세요.
로그에서 다운로드, 저장과 다시 불러오기가 모두 완료되었는지 확인하세요.
수동으로 교체할 때는 먼저 커널을 중지하고 복구 가능한 기존 파일을 보관하세요.
연결 기록으로 도메인, 대상 IP, 매칭 규칙과 최종 정책을 검증하세요.
GeoData, 구독 규칙과 Rule Provider를 각각 확인하고 세 항목을 동일한 업데이트로 취급하지 마세요.
결과가 여전히 이상하면 규칙 순서, DNS, TUN, 스니핑과 실행 설정을 차례로 점검하세요.

유지 관리가 성공했는지는 버튼에 “업데이트 완료”가 표시되는지만으로 판단할 수 없습니다. 최소한 GeoSite 도메인 규칙 하나, GEOIP 주소 규칙 하나와 Rule Provider 규칙 하나를 각각 테스트하세요. 연결 기록에서 예상한 규칙 이름과 정책이 확인되고 클라이언트를 다시 시작한 뒤에도 결과가 유지되어야 파일 경로, 설정 모드와 업데이트 방식이 올바르게 연결되었다고 볼 수 있습니다.