GeoIP와 GeoSite는 정확히 무엇인가

Clash 계열 설정 파일에는 흔히 다음과 같은 규칙이 있습니다.

rules:
  - GEOIP,CN,DIRECT
  - GEOSITE,google,Proxy
  - GEOSITE,cn,DIRECT
  - MATCH,Proxy

여기서 GEOIP,CN과 GEOSITE,google은 코어가 스스로 판단하는 것이 아니라, 사전에 컴파일된 두 종류의 지리 데이터베이스를 조회한 결과입니다.

• GeoIP 데이터베이스(흔히 Country.mmdb 또는 geoip.dat 파일명): 전 세계 IP 대역을 국가/지역 코드로 분류해 두고, 코어가 목적지 IP를 받으면 이 표를 조회해 CN, US, HK 같은 소속 지역을 얻은 뒤 규칙에 맞춰 직접 연결 또는 프록시 여부를 결정합니다.
• GeoSite 데이터베이스(흔히 geosite.dat 또는 geosite.db 파일명): 자주 쓰이는 도메인이나 도메인 접미사를 cn, google, github, netflix 같은 사전 정의 그룹으로 분류하고, 그룹에 매칭되면 해당 정책을 트리거합니다.

이 두 데이터베이스는 커뮤니티가 관리하는 정적 파일로, 상위 프로젝트(Loyalsoldier의 규칙 세트, v2fly의 domain-list-community 등)를 따라 주기적으로 다시 컴파일되어 배포됩니다. 코어 업그레이드에 맞춰 자동으로 갱신되지 않으며, 구독을 바꾼다고 새로 고쳐지지도 않습니다. 일종의 "사전"과 같아서, 사전이 인쇄된 시점이 조회 가능 여부를 결정합니다.

데이터베이스가 오래되면 왜 분기가 "부정확"해지는가

인터넷의 IP 대역 할당과 도메인 소속은 고정되어 있지 않습니다. 클라우드 서비스 제공업체의 IP 풀은 확장되거나 이전되고, CDN 노드는 지역 간에 재배치되며, 새로 등장한 도메인은 당분간 어떤 그룹에도 속하지 않습니다. 로컬 데이터베이스가 몇 달, 심지어 1~2년 전 버전에 머물러 있으면 다음 두 가지 전형적인 증상이 나타납니다.

• 직접 연결해야 할 것이 프록시로 처리됨: 국내 사이트가 새 IP 대역이나 새 CDN을 사용하기 시작하면, 오래된 GeoIP 데이터베이스에서는 CN 소속으로 조회되지 않아 규칙 판정에 실패하고 기본 정책(보통 프록시)으로 떨어집니다. 접속이 눈에 띄게 느려지거나 간헐적으로 연결 실패가 발생합니다.
• 프록시로 처리해야 할 것이 직접 연결됨: 해외 서비스가 도메인을 바꾸거나 새 서브도메인을 추가했는데 오래된 GeoSite 그룹에 등록되지 않으면, 규칙이 해당 그룹에 매칭되지 못하고 결국 MATCH,DIRECT 같은 기본 규칙이 처리해, 프록시 없는 네트워크 환경에 그대로 노출됩니다.

먼저 현재 데이터베이스 버전과 업데이트 시각을 확인

업데이트를 시작하기 전에 문제가 실제로 데이터베이스에 있는지 확인해야 합니다. 클라이언트마다 확인 방법은 약간 다르지만 방향은 동일합니다. 데이터베이스 파일의 최종 수정 시각을 찾아 상위 배포 기록과 비교하는 것입니다.

1. 클라이언트의 "코어/규칙" 설정 페이지에서 보통 GeoIP, GeoSite 파일의 로컬 경로와 최종 업데이트 타임스탬프를 확인할 수 있으며, 일부 클라이언트는 버전 번호나 커밋 해시 앞부분을 직접 표시합니다.
2. 클라이언트 화면에 이 정보가 없다면 설정 디렉터리에서 Country.mmdb, geosite.dat 파일의 수정 날짜를 직접 확인할 수 있습니다. 안드로이드에서는 보통 앱 전용 디렉터리 아래 data 또는 geo 하위 폴더에 있습니다.
3. 상위 저장소의 배포 날짜(GeoIP·GeoSite 데이터베이스는 보통 주 단위 또는 2주 단위로 업데이트됨)와 비교했을 때 로컬 파일이 한 달 이상 뒤처졌다면 수동 갱신이 필요하다고 거의 확정할 수 있습니다.

더 직접적인 검증 방법도 있습니다. 설정에 분기 오류가 의심되는 대상을 지정하는 명확한 도메인 또는 IP 규칙을 임시로 추가하고, 예상 그룹이 아니라 기본 정책이 적용되는지 관찰합니다. 정밀 규칙은 적용되는데 Geo 규칙만 적용되지 않는다면 문제는 데이터베이스 자체로 거의 확정됩니다.

데이터베이스 수동 업데이트 절차

수동 업데이트의 핵심은 신뢰할 수 있는 규칙 세트 저장소에서 최신 컴파일된 데이터베이스 파일을 내려받아 클라이언트 설정 디렉터리의 오래된 파일을 교체하고, 코어를 재시작하거나 설정을 다시 불러오는 것입니다.

1. 클라이언트가 사용하는 코어 버전 확인: Clash 원판, Clash Meta, mihomo는 데이터베이스 파일 형식 요구가 완전히 같지 않습니다. mihomo는 일부 버전에서 더 세분화된 규칙 세트 형식을 지원하므로, 교체 전에 현재 코어가 읽을 수 있는 파일 형식(.mmdb / .dat / .db)을 먼저 확인하세요.
2. 최신 데이터베이스 파일 확보: 해당 상위 규칙 세트 프로젝트의 배포 페이지에서 최신 버전을 내려받습니다. 파일명은 클라이언트 설정의 geodata-url, geoip-url 또는 로컬 경로와 일치해야 하며, 파일명이 맞지 않아 클라이언트가 여전히 이전 파일을 읽는 상황을 피해야 합니다.
3. 로컬 파일 교체: 내려받은 파일을 클라이언트 설정 디렉터리의 원래 파일 위치에 넣습니다. 새 파일 자체가 손상되었을 때 되돌릴 수 있도록 이전 파일을 먼저 백업한 뒤 덮어쓰는 것을 권장합니다.
4. 코어 재시작 또는 설정 다시 불러오기: 대부분의 클라이언트는 파일 교체 후 프록시 서비스를 재시작해야 데이터베이스를 다시 불러옵니다. 구독만 새로고침하거나 노드만 전환하는 것으로는 보통 데이터베이스 재조회가 트리거되지 않습니다.
5. 적용 확인: 재시작 후 이전에 잘못 판정되던 사이트에 접속하거나, 클라이언트 연결 로그에서 해당 요청이 매칭된 규칙 이름을 확인해 예상 그룹에 속하는지 검증합니다.

# mihomo 코어 커맨드라인 예시, 수동 교체 후 설정을 다시 불러오는 일반적인 절차
# 1. 실행 중인 서비스 중지
systemctl stop mihomo
# 2. 새 파일로 기존 GeoIP / GeoSite 데이터베이스 덮어쓰기
cp Country.mmdb /etc/mihomo/Country.mmdb
cp geosite.dat /etc/mihomo/geosite.dat
# 3. 서비스 재시작
systemctl start mihomo

자동 업데이트 설정으로 반복되는 만료 방지

수동 업데이트로는 그 순간의 문제만 해결할 뿐, 시간이 지나면 데이터베이스는 다시 오래된 것이 됩니다. 더 안정적인 방법은 설정 파일에 데이터베이스의 원격 주소와 업데이트 주기를 명시해, 클라이언트가 시작 시 또는 정기 작업에서 자동으로 최신 버전을 가져오도록 하는 것입니다.

이 필드를 지원하는 코어를 예로 들면, 설정 파일에는 보통 다음과 같은 구조가 있습니다.

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

• geo-auto-update: 코어가 백그라운드에서 새 버전 데이터베이스를 자동으로 확인하고 내려받도록 허용할지 여부.
• geo-update-interval: 자동 확인 간격(시간 단위). 너무 짧게 설정하면 불필요한 네트워크 요청이 늘어나며, 보통 24시간에 한 번이면 상위 배포 주기를 충분히 따라갈 수 있습니다.
• geox-url: 데이터베이스 다운로드 소스 주소를 지정합니다. 기본 소스가 네트워크 환경에서 느리다면 미러 주소로 바꿀 수 있지만, 미러의 동기화 신선도를 반드시 확인해야 합니다. 그렇지 않으면 장소만 바꿔 계속 오래된 데이터를 쓰는 셈이 됩니다.

모든 클라이언트 그래픽 인터페이스가 이 필드들의 설정 입구를 노출하지는 않습니다. 화면에 해당 스위치가 없다면 "설정 파일 편집" 또는 "고급 설정"에서 텍스트로 위 필드를 직접 추가한 뒤 저장하고 서비스를 재시작하면 적용됩니다.

업데이트 후에도 규칙이 적용되지 않을 때의 점검법

최신 데이터베이스를 내려받아 교체했는데도 문제가 여전하다면, 다음 순서로 하나씩 점검하면 대체로 구체적인 원인을 찾을 수 있습니다.

1. 파일이 실제로 교체되었는지 확인: 파일의 수정 시각과 용량이 바뀌었는지 확인합니다. 일부 클라이언트는 데이터베이스를 여러 위치(설치 디렉터리와 사용자 설정 디렉터리 등)에 캐시하므로, 잘못된 위치를 교체하면 교체하지 않은 것과 같습니다.
2. 코어가 실제로 파일을 다시 불러왔는지 확인: 일부 클라이언트의 "재시작" 버튼은 화면 프로세스만 재시작하고 하위 코어 서비스는 재시작하지 않습니다. 시스템 레벨에서 해당 프로세스나 서비스를 완전히 중지한 뒤 다시 시작해야 합니다.
3. 더 앞선 규칙에 가로막히지 않았는지 확인: Clash 규칙은 위에서 아래로 순서대로 매칭됩니다. GEOSITE,cn,DIRECT 앞에 범위가 너무 넓은 규칙(예: 지나치게 광범위한 DOMAIN-SUFFIX나 IP-CIDR)이 있으면 대상 요청이 그 규칙에 먼저 매칭되어 Geo 규칙까지 도달하지 못합니다.
4. 구독이 로컬 규칙 세트 설정을 덮어썼는지 확인: "구독 변환" 서비스로 생성한 설정을 사용 중이라면, 일부 변환 규칙이 생성 단계에서 이미 자체 Geo 데이터 소스 주소를 기록해 두어 로컬에서 수동으로 교체한 파일이 전혀 참조되지 않을 수 있습니다.
5. 연결 로그로 실제 매칭된 규칙 이름 확인: 대부분의 클라이언트는 실시간 로그나 연결 패널을 제공해, 각 요청이 정확히 어떤 규칙에 매칭됐는지 볼 수 있습니다. 문제가 데이터베이스인지 규칙 순서인지 판단하는 가장 직접적인 방법입니다.

장기적인 유지 관리 습관 만들기

Geo 데이터베이스의 만료는 지속적인 문제이며, 한 번 고쳤다고 영구히 해결되지 않습니다. 다음과 같은 습관을 들이면 이후 같은 문제를 다시 겪을 가능성을 줄일 수 있습니다.

• 자동 업데이트 필드를 활성화한 뒤에도 일정 주기로 데이터베이스의 실제 업데이트 시각을 직접 확인해, 자동 업데이트 작업이 네트워크 문제로 조용히 실패했는데 모르는 상황을 방지합니다.
• 구독이나 규칙 세트 소스를 교체할 때, 그 안에 자체 Geo 데이터 소스 주소가 내장되어 있는지 확인해 로컬에서 수동으로 관리하는 설정과 충돌하지 않도록 합니다.
• 규칙 파일 변경이 큰 경우, 먼저 테스트 환경이나 별도의 설정 그룹에서 검증한 뒤 일상적으로 사용하는 주 설정에 합쳐, 실사용 중 분기가 광범위하게 오작동하는 상황을 피합니다.
• 상위 규칙 세트 프로젝트의 업데이트 로그를 주시하세요. 특히 자주 쓰는 국내 서비스가 대규모로 IP 대역을 이전하거나 도메인 구조를 바꾸는 시기에는, 자동 업데이트 주기를 기다리기보다 수동으로 한 번 갱신하는 것이 더 안전합니다.