1. GeoIP와 GeoSite는 각각 무엇을 담당하나
분류 규칙을 일종의 분류 문제라고 생각해 봅시다. 연결이 들어올 때마다 코어는 두 가지 질문에 답해야 합니다. 이 대상 IP는 어느 국가/지역에 속하는가? 이 대상 도메인은 어떤 종류의 사이트에 속하는가? 첫 번째 질문은 GeoIP 데이터베이스에서, 두 번째 질문은 GeoSite 데이터베이스에서 답을 찾습니다. 두 파일은 역할이 완전히 다르며 서로 대체할 수 없습니다. 둘 중 하나라도 없으면 해당 규칙은 답을 찾지 못합니다.
GeoIP: IP를 국가/지역으로 매핑하는 표
GeoIP 데이터베이스는 IP 주소 대역과 국가/지역 코드의 매핑 정보를 담고 있습니다. 규칙에 GEOIP,CN,DIRECT라고 쓰면, 코어는 연결의 대상 IP를 데이터베이스에서 조회해 CN 대역에 해당하면 직접 연결로 처리합니다. mihomo(Clash Meta) 코어는 기본적으로 country.mmdb를 읽으며, 처음 로드할 때 자체적으로 사용할 geoip.metadb 캐시를 생성합니다. geodata-mode를 true로 설정하면 GEOIP 규칙은 v2ray 형식인 geoip.dat를 읽도록 바뀝니다. 그 외에 선택적으로 ASN 데이터베이스인 GeoLite2-ASN.mmdb가 있어, IP-ASN 규칙에서 자율 시스템 번호 기준으로 분류할 때 사용됩니다. 이 용어들은 용어 설명 페이지에 정리되어 있으니 헷갈릴 때 참고하세요.
GeoSite: 도메인을 사이트 분류로 매핑하는 표
GeoSite 데이터베이스는 커뮤니티 프로젝트인 domain-list-community에서 제공합니다. 관리자들이 방대한 도메인을 서비스, 제공업체, 지역별로 정리해 분류 목록을 만들고, 이를 컴파일해 geosite.dat 파일로 만듭니다. 규칙에 GEOSITE,google이라고 쓰면 코어는 대상 도메인을 google 분류에 속한 항목들과 하나씩 비교합니다. 분류에는 속성 태그를 붙일 수도 있는데, 예를 들어 google@cn은 google 분류 중 중국 본토 속성으로 표시된 항목만 매칭시켜 전체 분류보다 더 세밀하게 걸러냅니다.
| 비교 항목 | GeoIP | GeoSite |
|---|---|---|
| 기본 파일 | country.mmdb / geoip.metadb | geosite.dat |
| 답하는 질문 | 이 IP는 어느 국가/지역에 속하는가 | 이 도메인은 어떤 종류의 사이트인가 |
| 관련 규칙 | GEOIP,CN,DIRECT | GEOSITE,cn,DIRECT |
| 데이터 내용 | IP 대역과 국가 코드의 매핑 | 도메인과 분류 태그의 매핑 |
| 일반적인 출처 | meta-rules-dat 저장소 | meta-rules-dat 저장소 |
2. 두 데이터베이스를 왜 주기적으로 업데이트해야 하나
두 데이터베이스 모두 살아있는 데이터입니다. 클라우드 업체는 매달 서버를 증설하면서 IP 대역이 지역 간에 재배정되고, 새 서비스가 출시되거나 오래된 도메인의 소유주가 바뀌면서 사이트 분류도 함께 변합니다. 데이터베이스가 반년 전 상태에 머물러 있으면 분류 판단도 반년 전 세계 기준으로 이루어지며, 흔히 발생하는 문제는 세 가지입니다.
- 직결해야 할 트래픽이 프록시를 타는 경우: 새로 CN에 편입된 IP 대역이 옛 데이터베이스에는 기록되어 있지 않아 기본 규칙에 의해 프록시로 전송되고, 국내 사이트 접속인데 오히려 우회하는 결과가 됩니다.
- 프록시를 타야 할 트래픽이 직결되는 경우: 새로 출시된 해외 서비스 도메인이 아직 geosite 분류에 포함되지 않아 GEOIP나 기본 규칙에 의해 직결로 처리되고, 접속이 안 되거나 불안정하게 동작합니다.
- 규칙 매칭률 저하: 분류 항목이 변경되면서 기존에 의존하던 분류명이 분리되거나 이름이 바뀌어, 예전 규칙이 사실상 무효화됩니다.
일반적인 사용 강도라면 1~4주 간격 업데이트로 충분합니다. 새로 출시된 서비스를 즉시 인식해야 하는 등 시간에 민감한 규칙이 필요하다면 자동 업데이트 간격을 24시간까지 줄여도 되며, 대가는 하루에 몇 MB짜리 파일을 한 번 더 받는 정도입니다.
3. 데이터베이스 업데이트 방법 세 가지
방법 1: 클라이언트 화면의 버튼 클릭(가장 간편)
그래픽 클라이언트는 업데이트를 버튼 하나로 처리할 수 있게 해줍니다. Clash Verge Rev를 예로 들면, 설정 화면에 GeoIP, GeoSite 등 외부 리소스 항목이 있고 업데이트를 누르면 최신 파일을 받아옵니다. FlClash 등 다른 클라이언트에도 비슷한 리소스 업데이트 메뉴가 있습니다. 업데이트가 끝나면 설정을 한 번 리로드하거나 코어를 재시작해야 새 데이터베이스가 실제로 적용됩니다. 이 방법은 누구에게나 적합하며, 먼저 방법을 익히고 나중에 원리를 살펴보면 됩니다. 버튼 뒤에서 실행되는 작업이 바로 방법 3에서 수동으로 하는 다운로드 및 교체 과정입니다.
방법 2: 설정 파일에서 자동 업데이트 활성화
mihomo 코어에는 자동 업데이트 스위치가 내장되어 있으며, config.yaml 최상위에 다음과 같이 작성하면 됩니다.
# Geo 데이터베이스 자동 업데이트
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"
asn: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/GeoLite2-ASN.mmdb"핵심은 세 가지입니다. geo-update-interval의 단위는 시간이며 초가 아닙니다. geox-url의 네 개 키는 각각 geoip.dat, geosite.dat, country.mmdb, ASN 데이터베이스에 대응하며, 사용하지 않는 키는 생략해도 됩니다. GitHub 직접 연결이 불안정한 네트워크 환경이라면 주소를 접속 가능한 미러로 교체하면 되고, 파일 내용은 동일합니다.
방법 3: 파일을 수동으로 다운로드해 교체(가장 확실)
화면상의 업데이트가 실패하거나 파일 버전을 정확히 제어하고 싶을 때는 수동 교체가 가장 확실합니다.
- 다운로드 페이지 열기브라우저로 meta-rules-dat 저장소의 Release 페이지에 접속해 geoip.dat, geosite.dat, country.mmdb, GeoLite2-ASN.mmdb 네 개 파일을 찾습니다.
- 로컬에 다운로드하나씩 클릭해 다운로드합니다. 명령줄 환경에서는 curl로 개별 파일을 한 번에 받을 수도 있습니다.
- 설정 디렉터리 찾기mihomo의 설정 디렉터리는 config.yaml과 같은 위치에 있습니다. Clash Verge Rev는 설정 화면에서 클릭 한 번으로 설정 디렉터리를 열 수 있습니다.
- 교체 후 재시작새 파일로 기존 파일을 덮어쓴 다음 코어를 재시작하거나 설정을 리로드해, 코어가 데이터베이스를 다시 읽도록 합니다.
curl -L -o geosite.dat https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat교체 전에는 코어를 먼저 종료
일부 시스템에서는 파일이 사용 중이면 덮어쓰기가 실패할 수 있으므로, 교체 전에 코어를 종료하거나 일시 정지해야 합니다. 교체 후에는 실행 로그를 확인해 geo 파일 로드 줄에 오류가 없는지 반드시 확인하세요.
4. 분류 규칙에서 geoip와 geosite 참조하기
데이터베이스가 준비되어야 규칙이 조회할 대상이 생깁니다. 전형적인 분류 규칙 마무리 부분은 다음과 같습니다.
rules:
- GEOSITE,category-ads-all,REJECT # 광고 도메인, 바로 차단
- GEOSITE,google,노드 선택 # Google 계열 서비스는 프록시로
- GEOSITE,cn,DIRECT # 중국 본토 사이트는 직결
- GEOIP,CN,DIRECT,no-resolve # 대상 IP가 중국 본토면 직결
- MATCH,노드 선택 # 나머지는 모두 프록시로처리 순서를 하나씩 따라가 보면 이렇습니다. 연결이 들어오면 먼저 도메인 분류를 비교하고, GEOSITE 세 줄에서 도메인으로 판단 가능한 것을 모두 처리합니다. GEOIP로 넘어갈 때 대상이 IP라면 바로 데이터베이스를 조회하고, 도메인이라면 no-resolve 여부에 따라 달라집니다. no-resolve가 없으면 코어가 먼저 DNS 조회를 한 뒤 데이터베이스를 확인해 더 폭넓게 판단하지만 조회가 한 번 더 발생합니다. no-resolve를 붙이면 IP 형태의 연결에만 적용되어 조회 비용을 줄이지만, 도메인 형태의 연결은 이 규칙을 건너뛰게 됩니다. 위 설정에서는 GEOSITE,cn을 앞에 배치해 중국 본토 도메인을 미리 처리했으므로, GEOIP에 no-resolve를 붙여도 이들을 놓치지 않습니다.
자주 쓰는 geosite 분류 빠른 참고표
| 분류명 | 포함 범위 |
|---|---|
| category-ads-all | 광고 및 추적 도메인 모음 |
| cn | 중국 본토 사이트 도메인 |
| geolocation-!cn | 중국 본토 이외 지역의 사이트 |
| google / youtube | Google 계열 서비스 및 YouTube |
| telegram | Telegram 전체 도메인 |
| github | GitHub 본사이트 및 리소스 도메인 |
| apple / microsoft | Apple 및 Microsoft 서비스 도메인 |
| gfw | 자주 차단되는 사이트 모음 |
작성 시 지켜야 할 두 가지 규칙이 있습니다. 분류명은 반드시 공식 목록의 소문자 표기 그대로 사용해야 하며, 잘못 쓰면 오류는 나지 않고 조용히 매칭되지 않을 뿐입니다. 더 세밀한 제어가 필요하면 @ 속성을 사용하는데, 예를 들어 GEOSITE,google@cn,DIRECT는 중국 본토에서 접속 가능한 Google 도메인만 별도로 직결시키고, GEOSITE,geolocation-!cn,노드 선택은 “중국 본토 외 사이트는 모두 프록시로”와 같은 의미입니다.
5. 업데이트 및 규칙 참조 관련 자주 묻는 질문
업데이트 버튼을 눌러도 계속 실패해요
대부분 다운로드 소스에 접속이 안 되는 경우입니다. GitHub Release는 일부 네트워크 환경에서 직접 접속이 어려우니 geox-url을 미러 주소로 바꾸거나, 클라이언트 자체를 먼저 프록시로 연결한 뒤 업데이트를 눌러 보세요. 방법 3의 수동 교체로 클라이언트의 다운로드 로직을 그냥 우회하는 것도 가능합니다.
규칙을 작성했는데 적용이 안 돼요
순서대로 세 곳을 확인하세요. 첫째, 규칙 순서를 확인해 GEOSITE/GEOIP보다 앞에 있는 광범위한 규칙(앞쪽의 MATCH나 큰 범위의 IP-CIDR 등)이 먼저 가로채고 있지 않은지 봅니다. 둘째, 리로드 여부를 확인합니다. 설정을 수정한 뒤에는 반드시 리로드하거나 코어를 재시작해야 데이터베이스를 다시 읽습니다. 셋째, 분류명 오타를 확인합니다. 잘못 쓴 분류명은 오류를 내지 않고 조용히 누락됩니다.
저사양 기기에서 로딩이 느려요
공유기 같은 저사양 기기라면 geodata-loader를 memconservative로 설정해 로딩 속도를 메모리 사용량과 맞바꿀 수 있습니다. 일반 PC라면 기본값인 standard를 그대로 두면 됩니다.
업데이트 주기는 geo-auto-update에 맡기고, 분류 판단은 순서가 잘 정리된 규칙에 맡기면 두 데이터베이스는 오랫동안 조용히 제 역할을 합니다. 규칙 기반 분류의 전체적인 틀이 아직 잡혀 있지 않다면 먼저 사용 가이드로 돌아가 기본을 다진 뒤, 다시 이 고급 설정으로 돌아오세요. 순서를 바꾸지 않는 것이 중요합니다.