GeoIP·GeoSite 데이터베이스가 오래됐을 때: 업데이트 방법과 규칙 매칭 원리

GeoIP·GeoSite 데이터베이스란 정확히 무엇인가

일반적인 Clash 또는 mihomo 설정 파일을 열어보면 규칙 영역에서 GEOIP,CN,DIRECT나 GEOSITE,netflix,Proxy 같은 문법을 자주 볼 수 있습니다. 이 두 규칙이 참조하는 것이 바로 GeoIP 데이터베이스와 GeoSite 데이터베이스입니다. 이들은 설정 파일의 일부가 아니라 별도로 패키징돼 따로 내려받고 갱신해야 하는 바이너리 리소스 파일로, 보통 geoip.dat(또는 geoip.metadb)와 geosite.dat로 불립니다. mihomo 코어에서는 Country.mmdb 같은 MaxMind 형식으로도 자주 등장합니다.

GeoIP 데이터베이스는 「어떤 IP 대역이 어느 국가·지역에 속하는지」를 기록합니다. 예를 들어 특정 IPv4/IPv6 대역이 CN(중국 본토), US(미국), JP(일본) 등으로 표시됩니다. GeoSite 데이터베이스는 「도메인 또는 도메인 접미사가 어떤 분류에 속하는지」를 기록하는데, 예를 들어 geolocation-cn 분류에는 중국 본토에서 자주 쓰이는 사이트 도메인 규칙이 대량 포함돼 있고, netflix, google, telegram 같은 분류는 특정 서비스 제공사의 도메인 집합을 가리킵니다. 두 데이터베이스는 규칙 기반 프록시 설정에서 가장 기초적인 판단 근거를 이룹니다. 클라이언트는 연결 요청을 받으면 대상이 도메인인지 IP인지 먼저 확인하고, 해당 데이터베이스를 조회해 어떤 분류에 속하는지 판단한 뒤 설정된 규칙에 따라 직접 연결, 프록시 경유, 또는 차단 중 하나를 선택합니다.

규칙 매칭에서 두 데이터베이스가 실제로 쓰이는 방식

매칭 흐름을 이해하면 데이터베이스가 오래됐을 때 어느 단계에서 문제가 생기는지 파악하기 쉬워집니다. 흔히 쓰이는 규칙 집합을 예로 들면 다음과 같습니다.

rules:
  - GEOSITE,geolocation-cn,DIRECT
  - GEOSITE,netflix,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

클라이언트가 특정 도메인에 접속하려 하면 코어는 먼저 도메인 규칙 매칭을 시도합니다. GeoSite 데이터베이스의 geolocation-cn 분류에 해당 도메인(또는 상위 도메인, 와일드카드 접미사)이 포함돼 있는지 확인하고, 일치하면 직접 연결로 처리합니다. 일치하지 않으면 다음으로 netflix 분류를 확인하고, 일치하면 Proxy 프록시 그룹으로 보냅니다. 도메인 규칙이 전부 일치하지 않으면 코어는 먼저 DNS 조회로 IP 주소를 얻은 뒤, GeoIP 데이터베이스로 해당 IP가 어느 국가에 속하는지 확인합니다. CN과 일치하면 직접 연결하고, 그렇지 않으면 마지막 MATCH 기본 규칙에 따라 프록시로 넘어갑니다.

이 흐름이 보여주는 것은 GeoSite는 도메인 차원의 분류를, GeoIP는 IP 차원의 분류를 담당하며 서로 대체가 아닌 상호 보완 관계라는 점입니다. 「설정에는 프록시로 나가라고 써놨는데 특정 사이트가 직접 연결로 처리된다」거나 반대 상황을 겪는 사용자가 많은데, 원인은 대부분 규칙 작성 오류가 아니라 데이터베이스에 해당 도메인이나 IP 대역의 최신 정보가 빠져 있기 때문입니다. 즉 데이터베이스가 서비스 제공사의 실제 인프라 변화를 따라가지 못한 것입니다.

참고GeoIP/GeoSite 데이터베이스는 커뮤니티가 지속적으로 유지 관리하는 오픈소스 규칙 세트로, 갱신 주기는 선택한 규칙 세트 원본 저장소에 따라 매일에서 매주까지 다양합니다. 클라이언트 소프트웨어 자체의 버전 업데이트 주기와는 직접적인 관련이 없습니다.

데이터베이스가 오래되면 나타나는 대표적인 증상

인터넷 서비스 제공사는 사용하는 IP 대역과 도메인을 자주 변경하거나 확장합니다(특히 CDN 노드, 클라우드 서비스 출구 IP). 반면 GeoIP/GeoSite 데이터베이스는 수동 또는 자동화 스크립트로 주기적으로 수집·검증·패키징해 배포해야 하기 때문에 둘 사이에는 자연스러운 시차가 생깁니다. 데이터베이스가 오래되면 흔히 다음과 같은 증상이 나타납니다.

직접 연결돼야 할 사이트가 프록시로 나감:중국 본토의 특정 자주 쓰이는 사이트가 서버 IP를 새로 교체했는데, 오래된 데이터베이스에는 해당 IP 대역이 여전히 해외 또는 미분류로 표시돼 있어 원래 DIRECT로 처리돼야 할 트래픽이 기본 규칙에 의해 프록시 그룹으로 넘어가면서 불필요한 지연이 발생합니다.
프록시로 나가야 할 서비스가 직접 연결됨:반대로 일부 스트리밍이나 소셔 플랫폼이 도메인 구조를 바꾸거나 새 서브도메인을 추가했는데, 오래된 GeoSite 분류에는 이런 신규 도메인이 등록돼 있지 않아 요청이 어떤 규칙에도 일치하지 않고 기본값인 직접 연결로 처리돼, 접속 실패나 지역 제한 안내가 뜨는 경우가 있습니다.
분流 규칙 전체가 “둔감해짐”:시간이 지날수록 정확한 규칙에 매칭되지 않는 연결이 점점 늘어나 결국 대부분이 마지막 MATCH 기본 규칙으로 처리됩니다. 규칙 세트가 유명무실해지고 프록시 그룹의 부하와 지연 상태도 함께 나빠집니다.
사내망·내부 서비스 이상:사설 IP 대역 규칙을 직접 설정해뒀는데 오래된 GeoIP 데이터를 기준으로 비교하고 있다면 일부 내부 서비스 판단에도 오차가 생길 수 있습니다. 특히 TUN 모드로 전체 트래픽을 가로채는 환경에서 이런 문제가 더 쉽게 드러납니다.

이런 증상들은 개별적으로 나타나면 「구독 노드 품질이 나쁘다」거나 「클라이언트 버그」로 오해하기 쉽지만, 「전에는 정상이었는데 최근 들어 느려지거나 부정확해졌다」는 시간 흐름과 함께 나타난다면 데이터베이스 버전을 우선 의심해볼 만합니다.

세 가지 업데이트 방식 비교

현재 주요 Clash / Clash Meta(mihomo) 클라이언트가 지원하는 업데이트 방식은 크게 세 가지로 나뉘며, 각각 적합한 상황이 다릅니다.

방식 1: 클라이언트 내장 업데이트 버튼

대부분의 GUI 클라이언트(Clash Verge Rev, FlClash 등)는 설정 화면에 「GeoIP/GeoSite 데이터베이스 업데이트」 또는 「코어 리소스 업데이트」 버튼을 제공합니다. 클릭하면 내장된 기본 소스에서 최신 패키지 파일을 받아와 로컬 캐시를 덮어씁니다. 파일 구조를 이해할 필요가 없어 가장 간편한 방식이며, 대다수 일반 사용자에게 적합합니다. 단점은 업데이트 소스가 보통 개발자가 지정한 저장소 미러로 고정돼 있어, 해당 미러가 특정 네트워크 환경에서 접속이 불안정하면 업데이트가 실패하거나 느려질 수 있고 이 경우 수동 조치가 필요합니다.

방식 2: 파일 수동 다운로드 및 교체

명령줄 환경이나 GUI 버튼을 제공하지 않는 배포 방식이라면, 규칙 세트 배포 저장소에서 geoip.dat, geosite.dat(또는 mihomo용 .metadb/.mmdb 파일)를 직접 내려받아 클라이언트 설정 디렉터리 안의 같은 이름의 기존 파일을 교체하고, 코어를 재시작하거나 설정 리로드를 실행하면 적용됩니다. 이 방식은 제어력이 높아 특정 규칙 세트 버전을 정확히 선택할 수 있다는 장점이 있지만, 파일명과 배치 경로가 클라이언트가 요구하는 것과 정확히 일치해야 하며, 잘못된 디렉터리에 두면 업데이트 후에도 여전히 이전 캐시를 읽게 됩니다.

방식 3: 설정 파일 필드로 업데이트 소스 지정

mihomo 코어는 설정 파일에서 전용 필드로 지역 데이터베이스의 다운로드 주소와 자동 업데이트 정책을 선언하는 기능을 지원합니다. 자주 쓰이는 필드는 다음과 같습니다.

geodata-mode: true
geodata-loader: standard
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: "https://예시-신뢰하는-미러-주소/geoip.dat"
  geosite: "https://예시-신뢰하는-미러-주소/geosite.dat"

geo-auto-update를 켜면 코어가 geo-update-interval(단위: 시간)로 설정한 주기에 따라 자동으로 새 버전을 확인하고 내려받습니다. geox-url은 기본 소스를 원하는 미러 주소로 바꿀 수 있어, 자체 미러를 구축했거나 접속 속도에 특별한 요구가 있는 경우에 적합합니다. 이 방식은 가장 유연하지만 설정 필드의 의미를 정확히 이해해야 하며, 필드명이나 형식을 잘못 입력하면 코어 실행 시 오류가 발생할 수 있으므로 변경 전에 원본 설정을 백업하는 것이 좋습니다.

업데이트 방식	난이도	적합한 사용자	제어 수준
클라이언트 내장 버튼	낮음	일반 사용자	낮음
파일 수동 교체	중간	파일 디렉터리 구조에 익숙한 사용자	중간
설정 필드로 소스 지정	높음	직접 설정을 관리하는 / 장기 운영자	높음

업데이트 후 적용 여부 확인하는 법

업데이트 동작이 끝났다고 해서 규칙이 반드시 적용됐다는 보장은 없습니다. 다음 순서로 간단히 확인해보는 것을 권장합니다.

클라이언트의 로그 패널이나 실행 로그를 확인해 「geoip database loaded」, 「geosite updated」 같은 안내가 있는지 확인합니다. 조용히 실패한 경우도 있으니 로그를 꼭 확인해야 합니다.
최근 IP나 도메인이 변경된 것으로 알려진 사이트를 테스트 대상으로 골라 브라우저 DNS 캐시를 지운 뒤 다시 접속해보고, 연결이 실제로 어느 프록시 그룹을 타는지 확인합니다(대부분의 클라이언트 연결 패널은 각 연결이 매칭된 규칙명을 실시간으로 표시합니다).
클라이언트가 규칙 테스트나 「규칙 조회」 기능을 지원한다면 도메인/IP를 직접 입력해 매칭 결과를 확인하는 것이 웹사이트 접속을 반복 시도하는 것보다 훨씬 직관적입니다.
시스템이나 앱 계층의 DNS 캐시, 연결 캐시도 함께 지웠는지 확인해, 이전 해석 결과가 데이터베이스 업데이트 효과를 가려버리지 않도록 합니다.

확인 후에도 여전히 규칙이 부정확하다면 대부분 설정 파일 안의 규칙 세트 버전 번호나 URL이 예전 주소를 가리키고 있는 경우이며, 데이터베이스 자체가 업데이트되지 않은 것이 아닐 가능성이 높습니다. 이럴 때는 geox-url이나 클라이언트 설정의 미러 주소가 올바른지 다시 확인하는 것이 업데이트 버튼을 반복해서 누르는 것보다 훨씬 효과적입니다.

자주 발생하는 문제와 점검 방법

업데이트 후 규칙이 오히려 “다 뒤죠였다”면규칙 세트 배포자마다 분류 명명 방식과 수록 범위가 다를 수 있어, 설정에서 출처가 다른 두 규칙 세트 파일을 함께 쓰면 같은 분류명이 서로 다른 의미로 쓰이는 경우가 생길 수 있습니다. 이런 경우 먼저 rule-providers나 geox-url에서 참조하는 저장소 출처가 통일돼 있는지 확인해, 신구 버전을 섞어 쓰지 않도록 해야 합니다.

또 하나 자주 간과되는 부분은, 일부 클라이언트가 데이터베이스 파일에 대해 로컬 캐시 검증을 수행한다는 점입니다. 파일을 교체했는데도 캐시 디렉터리의 예전 인덱스를 지우지 않으면 재시작 후에도 예전 데이터를 계속 읽을 수 있습니다. 「파일은 분명 바꿨는데 동작이 그대로」인 경우, 설정만 리로드하지 말고 클라이언트 프로세스를 완전히 종료한 뒤 다시 실행해 코어가 데이터베이스 인덱스를 새로 초기화하도록 해보는 것이 좋습니다.

장기적으로는 「지역 데이터베이스 업데이트」를 「구독 링크 업데이트」와 동등하게 중요한 정기 유지 관리 작업으로 다루는 것을 권장합니다. 구독은 어떤 노드를 쓸 수 있는지를 결정하고, 데이터베이스는 트래픽이 그 노드를 타야 하는지를 결정합니다. 둘 중 하나라도 뒤처지면 전체 분流 정확도가 떨어집니다. 대다수 사용자는 클라이언트 설정에서 자동 업데이트를 켜두고 가끔 업데이트 로그를 확인하는 정도로 충분히 대응할 수 있으며, 직접 설정을 구성하거나 업데이트 소스에 특별한 요구가 있을 때만 설정 필드 단계까지 들어가 수동으로 관리하면 됩니다.