GeoIP·GeoSite 데이터베이스 업데이트 방법: geodata 모드, 다운로드 URL, 규칙 설정

1. GeoIP·GeoSite와 구독 업데이트의 차이

GeoIP와 GeoSite는 트래픽 분리 규칙에서 참조하는 데이터이지, 프록시 노드가 아닙니다. 구독을 업데이트하면 보통 노드, 정책 그룹 또는 전체 설정을 가져오지만, 지리 데이터베이스를 업데이트하면 규칙이 매칭할 수 있는 IP 대역이나 도메인 목록이 바뀝니다. 두 데이터는 서로 다른 방식으로 관리되므로 ‘구독 업데이트’를 한 번 눌렀다고 데이터베이스까지 업데이트됐다고 볼 수는 없습니다.

GeoIP의 국가·지역 분류는 웹사이트 운영 주체의 소재지를 뜻하지 않으며, 사용자가 접속할 때 실제 서비스 위치를 반영한다고 보장할 수도 없습니다. CDN, 여러 지역에 분산된 서버, 데이터 출처별 수록 차이 때문에 ‘도메인은 직접 연결해야 하는데 조회된 IP는 다른 지역으로 분류되는’ 상황이 생길 수 있습니다. 따라서 일반적으로 도메인 규칙을 IP 규칙보다 앞에 둡니다.

2. geodata-mode의 역할과 파일 저장 위치

GeoIP 데이터 형식을 선택하는 설정

mihomo에서 geodata-mode: true로 설정하면 GeoIP에 DAT 데이터를 사용하고, false로 설정하면 MMDB 데이터를 사용합니다. 이 옵션은 ‘모든 지리 기반 트래픽 분리’를 켜는 스위치가 아니며 규칙을 만들지도 않습니다. GeoSite를 사용하려면 해당 데이터 파일과 GEOSITE 규칙도 필요합니다.

• geox-url.geoip: GeoIP DAT 다운로드 주소입니다.
• geox-url.mmdb: GeoIP MMDB 다운로드 주소입니다.
• geox-url.geosite: GeoSite DAT 다운로드 주소입니다.
• geodata-loader: DAT 데이터를 불러오는 방식입니다. 주로 standard와 memconservative를 사용하며, 규칙의 대상 정책을 결정하지는 않습니다.

파일은 보통 커널의 작업 디렉터리에 저장됩니다. 파일명은 주로 GeoIP.dat, GeoSite.dat, country.mmdb입니다. 클라이언트마다 실행 디렉터리가 다를 수 있으므로 설치 프로그램이 있는 폴더를 데이터 디렉터리로 간주하면 안 됩니다. Linux에서는 대소문자 구분이 파일 인식에 영향을 줄 수 있으니 커널 로그, 실제 파일, 클라이언트 안내를 확인하세요.

실행 옵션으로 작업 디렉터리 확인하기

1. 클라이언트에서 설정 디렉터리나 작업 디렉터리를 여는 기능을 찾아 데이터베이스 파일을 확인하세요. ‘설정 디렉터리’와 ‘앱 로그 디렉터리’는 서로 다를 수 있습니다.
2. 커널 실행 옵션을 확인하세요. -d는 작업 디렉터리를, -f는 설정 파일을 지정합니다. 설정 파일이 있는 디렉터리가 작업 디렉터리와 같다는 보장은 없습니다.
3. 커널을 직접 실행한다면 mihomo -d ./mihomo-data -f ./config.yaml처럼 지정해 작업 디렉터리를 명확히 할 수 있습니다.
4. 컨테이너를 사용한다면 디렉터리 마운트 설정을 확인하세요. 컨테이너 내부의 작업 디렉터리와 호스트에서 파일을 저장하는 위치가 다를 수 있습니다.

수정하기 전에 현재 설정과 기존 데이터베이스를 백업하세요. 클라이언트에서 오버라이드, 병합 또는 확장 설정을 지원한다면 해당 영구 설정 경로에 전역 필드를 추가하세요. 자동 생성된 실행 설정을 직접 수정하면 다음 구독 업데이트 때 변경 사항이 사라질 수 있습니다.

3. 다운로드 주소 설정 및 24시간마다 자동 업데이트

아래 예시는 mihomo 설정 최상위에 병합할 수 있습니다. 데이터는 MetaCubeX의 meta-rules-dat 릴리스에서 가져오며, geo-update-interval의 단위는 시간입니다. 값 24는 하루 간격으로 업데이트한다는 뜻입니다. 규칙 프로바이더에서 사용하는 초 단위 간격과는 다릅니다.

geodata-mode: true
geodata-loader: memconservative
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"

• 이 필드들은 rules, dns와 같은 단계에 둡니다. proxy-groups나 profile 아래에 넣지 마세요.
• 이미 geox-url이 있다면 기존 매핑에 병합하고, 같은 이름의 최상위 키를 중복으로 추가하지 마세요.
• geodata-mode: false로 바꾼 경우 MMDB 다운로드 주소가 정상적으로 작동하는지 확인하세요. DAT만 업데이트해도 현재 사용 중인 MMDB를 대체할 수는 없습니다.
• 자동 업데이트를 설정해도 설정을 저장하는 즉시 다운로드가 시작되는 것은 아닙니다. 설정을 적용하거나 커널을 재시작한 뒤 업데이트 로그에서 예약 작업이 활성화됐는지 확인하세요.

데이터 출처 프로젝트는 MetaCubeX/meta-rules-dat에서 확인할 수 있습니다. 필드 설명은 mihomo 일반 설정 문서를 참고하세요. 릴리스 파일은 프로젝트 관리에 따라 바뀔 수 있습니다. 링크가 작동하지 않으면 릴리스 페이지를 먼저 확인하고, 파일명만 보고 낯선 다운로드 주소로 바꾸지 마세요.

4. GEOIP·GEOSITE 규칙과 적용 순서

Clash 계열 규칙은 위에서부터 차례로 매칭하며, 먼저 일치한 규칙의 정책을 적용합니다. 아래 예시는 IP 규칙보다 도메인 목록을 앞에 두고, 마지막에 MATCH로 나머지를 처리합니다. ‘아웃바운드 선택’ 정책 그룹은 구조를 설명하기 위해 만들었으며, 그룹 안에는 DIRECT만 있습니다. 실제로 사용하려면 기존 프록시 노드나 정책 그룹을 연결해야 하며, 이 예시만으로 프록시 연결이 구성되는 것은 아닙니다.

proxy-groups:
  - name: 아웃바운드 선택
    type: select
    proxies:
      - DIRECT

rules:
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,아웃바운드 선택

no-resolve는 DNS를 끄는 옵션이 아닙니다

GEOIP,CN,DIRECT,no-resolve는 해당 규칙이 매칭을 위해 도메인 조회를 새로 요청하지 않는다는 뜻입니다. 연결 정보에 대상 IP가 이미 있으면 IP 매칭을 계속할 수 있고, 사용할 IP가 없으면 다음 규칙으로 넘어갈 수 있습니다. 이 옵션은 클라이언트 전체의 DNS를 끄지 않으며, 다른 단계에서 앱이 도메인을 조회하는 것도 막지 않습니다.

매칭 결과는 연결 정보에 따라 달라집니다

GeoSite 규칙에는 도메인 정보가 필요합니다. 앱이 IP에 직접 연결하거나 도메인 매핑이 사라지거나 트래픽 가로채기 방식이 바뀌면 모든 연결이 도메인 분류와 매칭된다고 보장할 수 없습니다. TUN은 트래픽을 가로채는 방식이지 GeoSite 업데이트의 필수 조건이 아닙니다. TUN을 켠다고 모든 연결의 도메인 정보가 자동으로 복구되는 것도 아닙니다. fake-ip를 사용하는 경우 DNS 매핑 상태에 따라 커널이 해당 도메인을 복원할 수 있는지도 달라집니다.

특정 사이트의 연결 경로를 고정하려면 분류 규칙보다 앞에 DOMAIN-SUFFIX,example.com,DIRECT처럼 구체적인 규칙을 추가하세요. 이는 규칙 순서를 조정하는 방법이므로 도메인 하나 때문에 데이터베이스를 다시 만들 필요는 없습니다. 실제로 처리할 도메인을 규칙에 넣고 연결 세부 정보에서 매칭 결과를 확인하세요.

5. 자동 다운로드 실패 시 수동으로 교체하기

다운로드 시간 초과, 리디렉션 대상에 연결할 수 없음, 프록시 아웃바운드가 아직 불러오지 못한 설정에 의존하는 경우 등이 대표적인 실패 원인입니다. 브라우저에서 GitHub 메인 페이지가 열린다고 커널도 릴리스 첨부 파일을 내려받을 수 있는 것은 아닙니다. 브라우저와 커널은 프록시 설정이나 네트워크 경로가 다를 수 있습니다.

1. 오류 기록: 로그에 표시된 리소스 주소, 오류 유형, 대상 파일 위치를 저장하고 연결 시간 초과, HTTP 오류, 데이터 파싱 실패를 구분합니다.
2. 해당 파일 다운로드: 설정에 지정된 릴리스 출처에서 실제 바이너리 파일을 받았는지 확인합니다. 웹페이지, 로그인 페이지 또는 오류 응답을 파일로 저장하지 않도록 주의하세요.
3. 커널 종료: 클라이언트의 종료 기능을 사용하세요. 창을 닫은 뒤에도 트레이에서 계속 실행 중이라면 파일이 점유되지 않도록 백그라운드 커널을 직접 종료합니다.
4. 백업 후 교체: 기존 파일을 백업 디렉터리로 옮긴 다음, 확인한 작업 디렉터리에 새 파일을 넣습니다. 커널에서 요구하는 파일명은 그대로 사용하세요.
5. 재시작: 데이터 로드 로그와 설정 파싱 결과를 확인하세요. 분류가 없다는 오류나 파싱 오류가 발생하면 먼저 백업을 복원한 뒤 출처와 형식을 점검합니다.

MMDB 파일의 이름을 DAT로 바꿔 형식을 변환하려고 하지 말고, GeoSite 데이터를 GeoIP 파일 위치에 넣지도 마세요. 확장자를 바꿔도 형식이 변환되지는 않습니다. 커널은 파일 내부 구조를 읽습니다. Linux에서 실행하거나 서비스로 구동한다면 커널 실행 계정에 디렉터리 읽기 권한이 있는지 확인하세요. 자동 업데이트를 사용하려면 쓰기 권한도 필요합니다.

6. 업데이트 후 로그와 연결 정보로 교차 확인하기

‘파일 시간이 바뀌었다’는 것은 파일에 쓰기 작업이 있었다는 뜻일 뿐입니다. ‘설정이 정상적으로 시작됐다’고 테스트 트래픽이 의도한 규칙과 매칭됐다는 의미도 아닙니다. 웹페이지가 열리는지만 보지 말고 업데이트 과정과 실제 트래픽 분리를 나눠 각각 확인하고 기록하세요.

테스트하기 전에 기존 장기 연결을 종료하고 새 요청을 보내세요. 이미 연결된 세션은 데이터베이스를 새로 고쳐도 보통 전체 경로를 다시 선택하지 않습니다. 브라우저의 연결 재사용 때문에 결과가 바뀌지 않은 것처럼 보일 수도 있습니다. 문제 해결을 위해 로그 상세 수준을 잠시 높였다면 점검이 끝난 뒤 원래대로 돌리고, 노드 인증 정보, 구독 주소, 개인 접속 기록이 포함된 전체 로그를 외부에 공유하지 마세요.

7. 자주 발생하는 오류와 점검 범위

‘분류를 찾을 수 없음’ 또는 GeoSite 로드 실패

먼저 규칙의 분류명이 현재 데이터 출처에서 제공되는지 확인하고, 다운로드한 파일이 실제 GeoSite DAT인지 점검하세요. 경량 데이터 출처로 바꾸면 일부 분류가 빠질 수 있습니다. 호환되는 데이터 출처로 되돌리거나 지원되지 않는 규칙을 삭제하는 편이 반복해서 재시작하는 것보다 효과적입니다.

데이터베이스를 업데이트했는데 특정 사이트의 정책이 잘못 적용됨

앞에 있는 DOMAIN, DOMAIN-SUFFIX 또는 RULE-SET 규칙이 먼저 매칭되는지 확인하세요. 이어서 DNS 응답 주소와 연결 세부 정보에 표시된 대상 IP를 비교합니다. 데이터베이스 업데이트는 규칙 순서를 바꾸거나 DNS 캐시를 모두 지우지 않습니다. 실제 매칭 경로를 확인한 뒤 규칙을 수정할지, 캐시를 비울지, 데이터 출처에 분류 추가를 요청할지 결정하세요.

rule-providers를 사용 중인데 GeoSite도 업데이트해야 하나요?

설정에서 지리 데이터를 계속 참조하는지에 따라 다릅니다. RULE-SET 규칙 프로바이더는 각자의 url, path, interval 설정에 따라 업데이트됩니다. 지리 데이터베이스 자동 업데이트가 이 방식을 대신하지는 않습니다. 설정에서 GEOSITE나 GEOIP를 사용하거나 DNS 설정이 관련 분류를 참조한다면 해당 데이터도 계속 관리해야 합니다.