Clash GeoIP·GeoSite 데이터베이스 업데이트 가이드: 다운로드 소스 선택, 수동 교체와 자동 업데이트 설정

GeoIP와 GeoSite가 분流 규칙에서 실제로 하는 일

Clash의 분流 규칙에서는 GEOIP,CN,DIRECT나 GEOSITE,google,PROXY 같은 표기를 자주 보게 됩니다. 이 두 규칙은 두 종류의 데이터 파일에 의존합니다. GeoIP 데이터베이스는 IP 주소 대역을 국가·지역 코드에 매핑하고, GeoSite 데이터베이스는 도메인을 미리 정의된 그룹(예: google, github, netflix)으로 분류합니다. 규칙 엔진이 트래픽을 매칭할 때 도메인이나 IP 대역을 일일이 하드코딩할 필요 없이, 데이터베이스 안의 그룹 이름만 참조하면 수천, 수만 개의 항목을 한 번에 커버할 수 있습니다.

이런 설계는 "규칙 로직"과 "규칙 데이터"를 분리합니다. 규칙 로직은 rules 필드에 작성되며 기본적으로 수정할 필요가 없고, 규칙 데이터는 별도의 바이너리 파일에 저장되어 독립적으로 다운로드하고 업데이트할 수 있습니다. 데이터베이스 자체에는 판단 로직이 없으며 단순히 인덱스 표에 가깝습니다. 도메인과 IP를 서로 다른 폴더에 정리해 두는 것과 비슷합니다. 특정 사이트가 IP 대역을 바꾸거나 새 도메인이 대량으로 추가되었을 때, 데이터베이스가 시의적절하게 업데이트되면 규칙의 판단 결과도 자동으로 반영되며, 사용자가 설정 파일의 규칙 항목을 직접 수정할 필요가 없습니다.

반대로 데이터베이스가 오랫동안 업데이트되지 않으면 규칙의 정확도가 점점 떨어집니다. 새로 등록된 도메인이 원래 속해야 할 그룹에 들어가지 못하거나, 특정 CDN이 바꾼 새 IP 대역이 해외 그룹으로 잘못 판별될 수도 있습니다. 그래서 설정 파일을 한 번 작성하고 끝내는 것이 아니라, 데이터베이스 버전과 업데이트 주기도 따로 신경 써야 합니다.

주요 데이터베이스 배포판 비교

세간에 도는 데이터베이스 파일명과 형식은 통일되어 있지 않아 혼동하기 쉽습니다. 먼저 클라이언트 코어 계열별로 나눠 정리합니다.

Clash 오리지널과 Clash Meta(mihomo)의 차이

초기 Clash 오리지널 코어는 Country.mmdb를 사용했습니다. 이는 MaxMind 형식의 GeoIP 데이터베이스로, IP를 국가 코드로 매핑하는 기능만 있고 GeoSite 도메인 분류 기능은 없으며, 오리지널 코어의 GEOSITE 규칙 지원도 제한적입니다. Clash Meta와 그 후속 유지보수 분기인 mihomo는 자체 데이터 형식을 채택했습니다. GeoIP 쪽은 geoip.dat 또는 더 새로운 geoip.metadb이고, GeoSite 쪽은 geosite.dat입니다. .metadb는 mihomo 팀이 이후 전환한 자체 형식으로, 용량이 더 작고 조회 속도가 더 빠르며 기존 .dat 형식과는 혼용할 수 없습니다.

데이터 출처: V2Ray/Xray 계열과 MaxMind 계열

geoip.dat와 geosite.dat의 명명 규칙과 구조는 원래 V2Ray/Xray 생태계에서 나온 것으로, 이후 Clash Meta가 그대로 가져와 사용했기 때문에 양쪽 데이터 파일 형식이 상당히 호환되고 그룹 이름(예: cn, category-ads-all)도 거의 일치합니다. 이런 종류의 데이터베이스는 보통 커뮤니티 프로젝트가 정기적으로 컴파일해 배포하며, 자주 쓰이는 배포 저장소는 IP 대역과 도메인 목록의 변화를 지속적으로 반영합니다. MaxMind의 GeoLite2-Country.mmdb는 또 다른 계열로, 데이터 구조가 전통적인 IP 지리 위치 라이브러리에 더 가깝고, 주로 .mmdb 형식만 인식하는 구형 코어에서 사용됩니다.

실제로 선택할 때는 원칙 하나만 기억하면 됩니다. 먼저 자신이 쓰는 코어가 어떤 계열인지(Clash 오리지널, Clash Meta, 아니면 mihomo) 확인하고, 그다음 어떤 데이터 파일 형식을 인식하는지 확인해야 합니다. 둘이 맞지 않으면 교체해도 적용되지 않을 뿐만 아니라, 규칙 엔진 오류로 시작 자체가 실패할 수도 있습니다.

파일 수동 교체 전체 절차

수동 업데이트는 설정 파일을 건드리지 않고 한 번만 임시로 데이터를 갱신하려는 상황에 적합합니다. 핵심 흐름은 새 데이터베이스 파일을 다운로드해 클라이언트가 읽을 수 있는 디렉터리에 넣어 기존 파일을 덮어쓰고 코어를 재시작하는 것입니다.

1. 클라이언트의 데이터 디렉터리 확인

   클라이언트마다 GeoIP/GeoSite 파일을 저장하는 디렉터리가 다릅니다. 흔한 경우는 설정 파일과 같은 디렉터리이거나, 클라이언트 설치 디렉터리 아래의 data, resources 하위 디렉터리입니다. 먼저 클라이언트의 설정 관리 화면에서 현재 적용 중인 설정 파일 경로를 확인해 보면, 데이터베이스 파일은 보통 같은 디렉터리나 그 상위 디렉터리에 있습니다.

2. 코어가 인식하는 파일 형식 확인

   클라이언트의 코어 버전 정보를 열어 Clash 오리지널, Clash Meta, mihomo 중 어느 것인지 확인합니다. mihomo의 비교적 새로운 버전은 기본적으로 geoip.metadb를 인식하고, 비교적 오래된 버전과 Clash Meta는 geoip.dat와 geosite.dat를 인식합니다. 다운로드 전에 파일명 확장자를 먼저 확인해 형식을 잘못 받는 일을 피하세요.

3. 해당하는 배포 소스에서 최신 파일 다운로드

   유지보수가 활발한 커뮤니티 배포 소스 하나를 골라, 자신의 코어에 맞는 파일 버전을 다운로드합니다. 다운로드 후 바로 덮어쓰지 말고, 원본 파일이 있는 디렉터리에 먼저 백업을 하나 만들어 두면 교체 후 문제가 생겼을 때 빠르게 되돌릴 수 있습니다.

4. 코어를 정지한 뒤 파일 교체

   데이터베이스 파일은 보통 코어 시작 시 메모리에 로드되기 때문에, 실행 중에 파일을 바로 덮어써도 즉시 적용되지 않을 수 있고, 일부 시스템에서는 파일이 사용 중이라 교체 자체가 실패할 수도 있습니다. 클라이언트에서 프록시 서비스를 먼저 중지하거나 클라이언트를 종료한 뒤 파일을 교체하는 것을 권장합니다.

5. 코어 재시작 후 로그 확인

   교체가 끝나면 클라이언트나 프록시 서비스를 다시 시작해, 코어 로그에 데이터베이스 로드 실패나 형식 불일치 같은 오류가 있는지 확인합니다. 로그가 정상이고 오류가 없다면 새 데이터베이스가 적용된 것으로 볼 수 있으며, 소속이 명확한 도메인이나 IP 하나로 분流 결과를 테스트해 다시 한 번 확인하면 좋습니다.

설정 파일에서 정기 자동 업데이트 켜기

수동 교체는 사람의 개입이 필요해서 장기적으로는 업데이트를 잊기 쉽습니다. Clash Meta와 mihomo는 설정 파일에 데이터베이스 소스와 업데이트 주기를 선언해 두면 코어가 스스로 정기적으로 새 버전을 가져올 수 있게 지원하며, 사람이 따로 개입할 필요가 없습니다. 핵심 필드는 설정 파일 최상단의 geox-url과 업데이트 주기 관련 설정에 몰려 있으며, 전형적인 작성 예는 다음과 같습니다.

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

geox-url:
  geoip: "https://example.com/geoip.metadb"
  geosite: "https://example.com/geosite.dat"
  mmdb: "https://example.com/Country.mmdb"

각 필드의 역할은 다음과 같습니다. geodata-mode를 켜야 GEOSITE 규칙이 실제로 도메인 그룹 기준으로 매칭되며, 그렇지 않으면 코어가 이를 무시합니다. geo-auto-update는 자동 업데이트 활성화 여부를 결정합니다. geo-update-interval은 시간 단위로 업데이트 간격을 설정하며, 예시의 24는 하루에 한 번 확인함을 뜻합니다. geox-url 아래 세 개의 키는 각각 GeoIP, GeoSite, MaxMind 형식 데이터베이스의 다운로드 주소를 지정하며, 코어는 이 주소를 주기적으로 조회해 가져옵니다. 코어 버전마다 필드명 지원 여부가 조금씩 다르므로, 클라이언트를 업그레이드한 뒤에는 현재 버전의 업데이트 로그를 참고해 필드명이 바뀌지 않았는지 확인하는 것을 권장합니다. 그렇지 않으면 예전 필드명을 그대로 써서 자동 업데이트가 조용히 무효화될 수 있습니다.

구독 자체가 서비스 제공사에서 오는 경우, 구독 변환 서비스에 이미 미리 설정된 geox-url이 포함되어 있을 수 있으며, 이럴 때는 직접 작성한 필드가 구독 내용에 의해 덮어써질 수 있습니다. 자동 업데이트가 동작하지 않는다면 먼저 최종적으로 적용된 설정 파일에서 이 필드들이 구독 내용에 의해 다시 쓰여진 것은 아닌지 확인해 보세요.

업데이트 후 흔한 문제 점검

데이터베이스 업데이트 후 규칙 동작이 이상해지는 경우는 대부분 다음 몇 가지 원인에 집중됩니다.

• 형식 불일치: .dat 형식을 다운로드했는데 .metadb만 인식하는 신버전 코어에 로드시키면, 코어는 보통 로그에 파싱 실패를 남기고 규칙 엔진은 "매칭 실패" 상태로 돌아가 많은 트래픽이 기본 정책 그룹으로 떨어집니다.
• 그룹 이름 불일치: 같은 종류의 사이트에 대해 배포 소스마다 그룹 명명이 다를 수 있습니다. 예를 들어 어떤 곳은 netflix라고 부르고, 어떤 곳은 더 세분화된 하위 그룹으로 나눕니다. 규칙에 쓴 그룹 이름은 데이터베이스에 실제로 수록된 그룹 이름과 완전히 일치해야 하며, 대소문자와 철자까지 확인해야 합니다.
• 자동 업데이트 주소 접근 불가: geox-url이 가리키는 주소가 접속이 불안정하거나 프록시를 거쳐야만 접근 가능한데, 업데이트 동작이 프록시 링크가 구성되기 전에 일어난다면 업데이트가 계속 실패하는 상황이 생길 수 있습니다. 이런 주소는 접속 경로가 단순하고 안정적인 배포 소스를 선택하는 것을 권장합니다.
• 캐시가 갱신되지 않음: 일부 클라이언트는 그래픽 인터페이스에서 규칙을 추가로 캐시해 두는데, 데이터베이스 파일은 이미 업데이트됐지만 화면에 표시되는 매칭 결과가 변하지 않는 경우가 있습니다. 클라이언트를 한 번 재시작하면 대체로 해결됩니다.

점검할 때는 "파일이 올바른 디렉터리에 있는가 → 형식이 코어와 맞는가 → 설정 필드가 덮어써지지 않았는가 → 업데이트 주소에 네트워크로 접근 가능한가" 순서로 하나씩 확인하는 것을 권장합니다. 데이터베이스 관련 분流 이상 문제는 대부분 이 몇 단계에서 원인을 찾을 수 있습니다.