GeoIP·GeoSite 데이터베이스 업데이트 가이드: 분산 규칙 오류의 원인과 해결

Clash와 mihomo 코어의 분산 규칙은 직접 작성한 도메인이나 IP 대역에만 의존하지 않습니다. 자주 쓰는 규칙 중 상당수는 실제로 두 종류의 오프라인 데이터베이스를 참조합니다: GeoIP와 GeoSite. 이들은 방대한 IP 대역과 도메인을 분류해 묶어두므로, 규칙 파일에 GEOIP,CN 한 줄이나 규칙셋 참조 하나만 적어도 수천 개의 실제 주소를 포괄할 수 있습니다. 설정은 간결해지지만, 쉽게 간과되는 위험도 함께 생깁니다—데이터베이스 자체에는 유효기간이 있고, 오래된 데이터베이스는 원래 정확했던 규칙을 조용히 틀리게 만듭니다.

GeoIP와 GeoSite에는 실제로 무엇이 담겨 있나

이 두 데이터베이스는 같은 문제를 서로 다른 두 축에서 해결합니다. 하나는 IP 기준 분류, 다른 하나는 도메인 기준 분류입니다. 이 차이를 이해하는 것이 분산 이상을 점검하는 전제 조건입니다.

mihomo 코어는 실행 시 이 두 데이터베이스를 메모리에 로드하고, 이후 매 연결마다 규칙 매칭을 위해 조회를 수행합니다—어떤 IP가 어느 국가에 속하는지, 어떤 도메인이 어떤 분류에 속하는지 확인하는 방식입니다. 데이터베이스에 없는 항목은 당연히 해당 규칙에 매칭되지 않고 계속 아래로 넘어가며, 대개 규칙 목록 맨 끝의 MATCH 기본 정책에 걸리는데, 이는 기대한 출구 노드와 다른 경우가 많습니다.

데이터베이스가 오래되면 나타나는 구체적 증상

데이터베이스 노화는 오류를 표시하지도, 화면에 "업데이트하세요"라고 알려주지도 않습니다. 조용한 편차일 뿐이며, 분산 결과의 이상 현상으로만 역추적할 수 있습니다. 자주 나타나는 몇 가지 증상은 다음과 같습니다.

• 신규 서비스가 국내 IP로 오판됨: 일부 클라우드 사업자는 새로 할당받은 IP 대역을 특정 지역으로 분류하는데, GeoIP 데이터베이스가 이 변경을 즉시 반영하지 못하면 신규 서비스 연결이 GEOIP,CN 규칙에 의해 국내 IP로 잘못 판정되어 직접 연결로 처리되고, 결과적으로 연결 시간 초과나 접속 실패가 발생합니다.
• 규칙셋을 올바르게 작성했는데도 전혀 매칭되지 않음: 특정 분류의 GeoSite 규칙셋(예: 스트리밍이나 소셜 앱 분류)을 참조할 때, 해당 분류에 최근 도메인이 추가되었지만 데이터베이스가 갱신되지 않았다면 신규 도메인이 규칙셋을 우회해 기본 정책으로 떨어지고, "같은 앱인데 일부 기능은 프록시로, 일부는 직접 연결로 처리됨" 같은 현상이 나타납니다.
• 국내 사이트가 간헐적으로 프록시를 거침: 반대로 어떤 IP 대역이 클라우드 사업자에 반환되거나 해외 주체로 이전되었는데도 예전 데이터베이스가 여전히 국내로 표시하면, 원래 직접 연결되어야 할 사이트가 잘못 프록시 출구로 밀려 속도가 뚜렷하게 느려집니다.
• 지연 측정은 정상인데 실제 접속은 이상함: 노드 지연 측정은 고정된 테스트 주소를 사용하며 전체 도메인/IP 분산 판단을 거치지 않으므로, 데이터베이스 노화로 인한 문제는 노드 속도 측정 단계에서는 전혀 드러나지 않고 실제 업무 도메인에 접속할 때만 표면화됩니다.

데이터베이스 파일 수동 교체

수동 교체는 가장 직접적이고 통제 가능한 방식으로, 점검 단계에서 문제를 확인하거나 자동 업데이트 메커니즘이 불안한 경우에 적합합니다. 핵심 단계는 세 가지뿐입니다: 코어의 데이터 디렉터리 찾기, 최신 데이터베이스 파일 내려받기, 코어를 재시작해 다시 로드하게 하기.

1. 데이터 디렉터리 위치 확인: mihomo 코어는 기본적으로 작업 디렉터리 하위에서 Country.mmdb와 geosite.dat(또는 이에 대응하는 .metadb 형식)를 찾습니다. 데스크톱 환경에서는 보통 설정 디렉터리와 같은 레벨에 있으며, iOS 클라이언트에서는 대개 앱 내 규칙/데이터 관리 페이지에 이 두 항목이 따로 나열되어 있어 파일 시스템 경로를 직접 찾을 필요가 없습니다.
2. 최신 데이터베이스 확보: 데이터베이스는 mihomo 관련 오픈소스 프로젝트의 규칙셋 저장소를 통해 지속적으로 관리되고 배포되며, 배포 주기는 보통 몇 주에 한 번이고, IP 대역이 대규모로 조정되거나 인기 도메인이 이전되는 경우에는 별도의 패치 버전이 나옵니다.
3. 교체 후 재시작: 새 파일로 기존 파일을 덮어쓴 뒤에는 반드시 코어를 완전히 재시작해야 합니다(설정 리로드만으로는 데이터베이스 파일이 다시 로드되지 않는 경우가 대부분입니다). 그렇지 않으면 메모리에는 여전히 이전 버전의 매핑 테이블이 남아 있어 교체가 적용되지 않습니다.

클라이언트에 그래픽 형태의 "GeoIP/GeoSite 업데이트" 버튼이 있다면 우선 그 기능을 사용하세요. 파일 검증과 재시작 과정을 자동으로 처리해 파일 시스템을 직접 조작하는 것보다 오류가 적습니다.

설정 내 자동 업데이트, 두 가지 방식

수동 교체는 결국 수동적인 대응입니다. 더 권장되는 방식은 설정에서 자동 업데이트를 켜서 코어가 주기적으로 스스로 점검하게 하는 것입니다. mihomo는 각각 별도로 설정할 수 있는 두 계층의 업데이트 메커니즘을 제공합니다.

1단계: 코어 레벨 GeoIP/GeoSite 자동 업데이트

이 계층은 코어에 내장된 지리 데이터베이스 자체를 제어하며, 설정 파일 최상위에서 설정합니다.

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: "https://example-mirror.invalid/country.mmdb"
  geosite: "https://example-mirror.invalid/geosite.dat"

geo-update-interval의 단위는 시간(hour)으로, 코어가 원격에 새 버전이 있는지 얼마나 자주 확인할지 결정합니다. geox-url은 자체 구축한 서버나 서드파티 미러 주소를 지정할 수 있어 다운로드를 가속하거나 접속 불안정 문제를 피할 수 있습니다. 켜두면 별도의 개입 없이 코어가 백그라운드에서 조용히 업데이트를 완료합니다.

2단계: 규칙셋(rule-providers)의 독립적인 업데이트

분산 규칙이 코어에 내장된 GeoSite 분류가 아니라 외부 규칙셋을 사용하는 경우, 업데이트 주기는 각 rule-provider에서 별도로 선언해야 합니다.

rule-providers:
  reject-list:
    type: http
    behavior: domain
    url: "https://example-mirror.invalid/reject.txt"
    path: ./rules/reject.yaml
    interval: 86400

interval의 단위는 초로, 86400은 하루에 한 번입니다. 규칙셋과 코어에 내장된 GeoIP/GeoSite는 서로 독립된 업데이트 경로이며, 한쪽만 켜둔다고 다른 쪽까지 자동으로 갱신되지는 않습니다. 이것이 "데이터베이스를 업데이트했는데도 규칙이 여전히 부정확한" 흔한 원인 중 하나입니다.

업데이트 후 적용 여부 검증하는 법

파일을 교체하거나 설정을 바꾼 뒤에는 감으로 "이제 됐겠지"라고 판단하지 말고, 재현 가능한 검증 절차를 따르세요.

1. 실행 로그 확인: 코어를 재시작하면 데이터베이스 로드 정보(파일 경로, 레코드 수 포함)가 출력됩니다. 로그에 다운로드 실패나 파일 검증 오류가 나타난다면 업데이트가 실제로 적용되지 않았고 규칙은 여전히 예전 데이터를 사용하고 있다는 뜻입니다.
2. 알려진 경계 주소로 테스트: 최근 소속이 바뀐 것이 확인된 도메인이나 IP를 골라 업데이트 전후로 각각 분산 결과를 테스트합니다. 출구 정책이 예상대로 바뀌었다면 새 데이터베이스가 실제로 로드되어 매칭에 참여했다는 뜻입니다.
3. 규칙셋 항목 수 대조: 일부 클라이언트의 규칙 관리 화면에는 각 규칙셋에 포함된 도메인/IP 개수가 표시됩니다. 업데이트 전후로 개수가 뚜렷하게 달라졌다면 데이터베이스가 실제로 갱신되었다는 직접적인 증거입니다.
4. 연결 캐시를 비우고 재테스트: 일부 코어는 이미 성립된 연결 결과를 짧게 캐시합니다. 검증 전에 연결을 끊고 다시 접속하거나 클라이언트를 재시작해, 예전 캐시 결과에 판단이 흐려지지 않도록 하세요.

검증 절차가 다소 번거로워 보일 수 있지만, "업데이트했으니 끝"이라고 여기는 것보다 같은 문제를 반복해서 점검하는 수고를 훨씨 줄여줍니다. 데이터베이스 관련 분산 이상은 대개 겉으로 드러나지 않고 지연되어 나타나므로, 미리 검증하는 습관을 들여두면 이후 로그를 뒤지는 시간을 크게 아낄 수 있습니다.

지속 가능한 업데이트 주기 계획하기

대부분의 사용 환경에서는 코어 레벨 자동 업데이트를 켜고 12~24시간 간격으로 확인하도록 설정하는 것으로 충분합니다. 분 단위 실시간 동기화까지 추구할 필요는 없으며, GeoIP·GeoSite 데이터베이스의 상류 배포 주기 자체가 그런 빈도를 지원하지도 않습니다. 만약 같은 유형의 서비스에서 분산 문제가 반복적으로 나타난다면, 업데이트 간격을 무한정 줄이기보다 해당 분류에 대응하는 규칙셋의 출처가 여전히 관리되고 있는지를 구체적으로 점검하는 쪽이 더 가치 있습니다. 데이터베이스 업데이트는 분산 정확도를 좌우하는 여러 요소 중 하나일 뿐이며, 실행 로그를 정기적으로 확인하고 규칙 매칭 결과에 주의를 기울이는 습관을 함께 갖춰야 우발적인 분산 오차를 최소한으로 유지할 수 있습니다.