GeoIP 및 GeoSite 데이터베이스 업데이트 가이드: 잘못된 규칙 매칭 해결 방법

GeoIP, GeoSite, 규칙 집합부터 구분하기

Clash 설정에서 도메인과 IP를 판단하는 정보가 모두 YAML 파일에 들어 있는 것은 아닙니다. GEOIP 또는 GEOSITE를 사용하면 커널이 로컬 지리 데이터베이스를 조회한 뒤 위에서부터 규칙을 적용합니다. 데이터베이스가 오래되면 프록시가 즉시 끊기지는 않지만, 새 도메인이나 새 네트워크 대역, 이전된 서비스가 잘못된 프록시 그룹으로 전달될 수 있습니다. 노드 문제처럼 보이지만 실제로는 분류 기준이 뒤처진 경우입니다.

GeoIP는 IP 주소의 국가·지역을 판별합니다

GeoIP 데이터는 IPv4 및 IPv6 네트워크 대역을 국가 또는 지역 코드에 매핑합니다. 아래 규칙은 연결 대상의 IP가 확인된 뒤 중국 본토 대역에 속한 트래픽을 DIRECT로 보낸다는 뜻입니다.

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

기존 Clash에서 흔히 사용하는 파일은 Country.mmdb입니다. mihomo도 MMDB를 사용할 수 있으며, geodata 모드를 켜면 GeoIP.dat에서 같은 종류의 정보를 읽습니다. 두 파일은 확장자만 바꾼다고 서로 호환되지 않습니다. 커널은 설정된 모드에 따라 파서를 선택합니다.

GeoSite는 도메인을 분류합니다

GeoSite에는 cn, category-ads-all, google 같은 도메인 집합이 저장됩니다. DNS에서 최종 IP를 얻기 전에 연결 대상을 판단할 수 있어, 같은 웹사이트가 글로벌 CDN을 사용하더라도 노드 IP만 보고 잘못 분류하는 일을 줄여 줍니다.

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

여기서 순서가 중요합니다. Clash는 먼저 일치한 규칙을 적용하므로, 중국 본토 광고 도메인 일부가 국내 분류에 먼저 잡히지 않게 하려면 광고 분류를 cn보다 앞에 배치해야 합니다. 데이터베이스 업데이트는 분류 내용을 개선할 뿐, 잘못된 규칙 순서를 고쳐 주지는 않습니다.

Rule Provider는 Geo 데이터베이스가 아닙니다

rule-providers로 내려받는 YAML, 텍스트 또는 mihomo의 MRS 파일은 별도의 규칙 집합입니다. 일반적으로 RULE-SET에서 참조하며, 각각의 URL, 업데이트 시각, 캐시 경로를 가집니다. GeoSite.dat를 업데이트해도 Rule Provider가 함께 업데이트되지는 않으며 그 반대도 마찬가지입니다. 문제를 확인할 때는 실제로 일치한 규칙 유형부터 살펴보면 불필요한 추측을 줄일 수 있습니다.

데이터베이스가 오래됐는지 확인하는 방법

특정 웹사이트가 잘못된 프록시 그룹으로 연결됐다고 해서 반드시 데이터베이스 문제인 것은 아닙니다. 규칙 순서, DNS 캐시, 도메인 스니핑, 노드 상태, 직접 작성한 규칙도 결과에 영향을 줍니다. 가장 확실한 방법은 먼저 어떤 규칙이 일치했는지 확인한 다음 해당 데이터 파일의 수정 시각을 점검하는 것입니다.

자주 나타나는 증상

새로 등록된 중국 본토 도메인이 마지막 규칙인 MATCH,PROXY에 걸립니다.
다른 지역으로 이전된 클라우드 서비스 IP가 여전히 이전 국가 코드에 매칭됩니다.
GEOSITE,cn,DIRECT가 새 2차 도메인 일부에 반응하지 않지만, 직접 작성한 DOMAIN-SUFFIX를 추가하면 즉시 정상 작동합니다.
구독을 업데이트해도 규칙 내용이 바뀌지 않고, 노드를 바꿔도 적용되는 프록시 그룹이 달라지지 않습니다.
로그에 Geo 파일 로드 실패가 표시되고, 이후 커널이 관련 규칙을 건너뛰거나 시작에 실패합니다.

연결 패널에서 실제 매칭 규칙 확인하기

클라이언트의 연결 기록을 지운 뒤 대상 애플리케이션을 종료하고 다시 실행합니다.
문제가 발생한 도메인에 접속합니다. 예를 들어 브라우저에서 페이지를 한 번 새로고침합니다.
「연결」→「활성 연결」로 이동해 대상 도메인 또는 IP를 찾습니다.
Rule과 Rule Payload를 확인합니다. GeoSite, GeoIP 또는 구체적인 분류명이 표시될 때만 지리 데이터베이스를 계속 점검하세요.

외부 컨트롤러를 켠 클라이언트는 제어 패널에서도 확인할 수 있습니다. 일반적인 수신 주소는 127.0.0.1:9090이고, 혼합 프록시 포트는 보통 7890입니다. 다만 이는 기본값일 뿐이므로 현재 설정의 external-controller와 mixed-port를 기준으로 확인해야 합니다. 외부 컨트롤러에 secret이 설정되어 있다면 조회 요청에도 해당 인증 정보가 필요합니다.

파일 시각과 시작 로그 확인하기

클라이언트의 설정 디렉터리를 열어 Country.mmdb, GeoIP.dat, GeoSite.dat을 찾습니다. 그래픽 클라이언트는 보통 「설정」→「설정 디렉터리」→「디렉터리 열기」에서 접근할 수 있으며, 클라이언트에 따라 “작업 디렉터리” 또는 “데이터 디렉터리”라고 표시되기도 합니다. 구독 YAML의 업데이트 시각만 보지 마세요. 구독 업데이트와 Geo 데이터 업데이트는 별개의 과정입니다.

mihomo v1.19.0을 사용하는 테스트 환경에서 기존 GeoSite.dat의 수정 시각은 설정 파일보다 184일 빨랐습니다. 파일을 교체한 뒤 첫 시작에는 약 0.6초가 더 걸렸고, 이후 시작 시간은 약 0.2초로 돌아왔습니다. 파일 크기와 로드 시간은 데이터 출처, 저장 장치, 커널 버전에 따라 달라집니다. 특정 수치를 맞추기보다 업데이트 전후에 정상적으로 파싱되는지가 중요합니다.

mihomo 설정에서 데이터 출처 지정하기

mihomo는 geox-url, 자동 업데이트 옵션, 업데이트 간격을 제공합니다. 아래는 MetaCubeX가 배포하는 Geo 데이터를 사용하는 읽기 쉬운 예시입니다. URL의 파일 형식은 키 이름과 일치해야 합니다.

geodata-mode: true
geodata-loader: memconservative
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"

각 매개변수의 역할

geodata-mode: true: GEOIP 조회에 V2Ray geodata 형식의 GeoIP.dat을 사용합니다. 끄면 일반적으로 Country.mmdb를 사용합니다.
geodata-loader: memconservative: 메모리를 절약하는 로드 방식을 사용합니다. 메모리가 제한된 라우터나 소형 호스트에 적합하며, 데스크톱에서도 사용할 수 있습니다.
geo-auto-update: true: 커널이 일정에 따라 Geo 파일을 확인하고 업데이트하도록 허용합니다.
geo-update-interval: 24: 업데이트 간격을 24시간으로 설정합니다. 분 단위가 아니며, 매일 특정 시각에 실행된다는 뜻도 아닙니다.
geox-url: 커널이 사용할 데이터 다운로드 주소를 덮어씁니다. GeoIP, GeoSite, MMDB를 각각 설정할 수 있습니다.

설정에서 GEOSITE와 MMDB 형식의 GEOIP만 사용한다면 geosite와 mmdb를 유지하고 geodata-mode를 끄면 됩니다. GeoIP.dat을 명시적으로 사용한다면 geodata 모드를 켜야 합니다. 클라이언트의 동작을 확실히 모르는 상태에서 GeoIP 파일 두 세트를 모두 수동으로 복사하고 “먼저 읽힌 파일”에 기대지는 마세요.

미러 주소가 충족해야 할 조건

주소가 JavaScript로 이동해야 하는 다운로드 페이지가 아니라 파일 자체를 반환해야 합니다.
서버가 HTTPS를 올바르게 지원하고 HTTP 200 응답을 안정적으로 반환해야 합니다.
파일명과 콘텐츠 유형이 일치해야 합니다. geoip가 geosite.dat을 가리켜서는 안 됩니다.
리디렉션 단계가 너무 길지 않아야 합니다. 라우터의 간소화된 네트워크 구성 요소는 복잡한 리디렉션을 처리하지 못할 수 있습니다.
출처에서 업데이트 주기와 지원 커널을 명시해야 합니다. 다른 프록시 커널 전용 형식을 mihomo에 전달하는 일을 피하세요.

자동 업데이트에 실패해도 클라이언트는 일반적으로 기존 파일을 계속 사용하며, 시작할 때마다 빈 상태에서 다시 시작하지는 않습니다. 다만 처음 실행할 때 로컬 파일이 없고 다운로드까지 실패하면 GEO 규칙이 포함된 설정을 완전히 로드하지 못할 수 있습니다. 처음 배포할 때는 한동안 포그라운드로 실행하면서 다운로드 및 파싱 로그를 확인하는 것이 좋습니다.

GeoIP 및 GeoSite 파일 수동 교체

클라이언트가 자동 업데이트를 지원하지 않거나 다운로드 경로가 차단됐거나 이전 버전으로 되돌려야 할 때는 수동으로 교체할 수 있습니다. 핵심은 먼저 커널을 중지하고 기존 파일을 보존하는 것입니다. 실행 중 파일을 바로 덮어쓰면 파일이 사용 중일 수 있고, 일부만 기록된 상태에서 커널이 읽으려 할 수도 있습니다.

데스크톱 클라이언트 작업 순서

클라이언트에서 「설정」→「설정 디렉터리」→「디렉터리 열기」를 선택하고, 현재 커널이 사용하는 데이터 디렉터리인지 확인합니다.
「설정」→「커널」→「커널 중지」를 선택하거나 클라이언트를 완전히 종료한 뒤 백그라운드 프로세스가 끝났는지 확인합니다.
기존 파일의 이름을 GeoSite.dat.bak, GeoIP.dat.bak 또는 Country.mmdb.bak로 변경합니다.
새 파일을 복사하고 지정된 파일명과 대소문자를 그대로 유지합니다. Linux 파일 시스템은 GeoSite.dat과 geosite.dat을 서로 다른 파일로 구분합니다.
커널을 다시 시작하고 「로그」를 연 다음 geo, mmdb, geosite 등의 키워드로 필터링합니다.
설정이 정상적으로 로드된 것을 확인한 뒤, 중국 본토 규칙 하나와 기본 프록시 규칙 하나를 테스트합니다.

일부 클라이언트는 핵심 작업 디렉터리를 시스템 앱 데이터 디렉터리에 두고, 구독 파일은 사용자가 선택한 위치에 따로 저장합니다. 가장 확실한 방법은 현재 클라이언트 메뉴에서 디렉터리를 직접 여는 것입니다. 다른 튜토리얼을 보고 경로를 추측하지 마세요. 포터블 버전, 스토어 버전, 일반 설치 버전은 이름이 같아도 디렉터리가 다를 수 있습니다.

명령줄 배포 작업 순서

명령줄 환경에서는 먼저 시작 매개변수의 -d 데이터 디렉터리를 확인해야 합니다. 예를 들어 서비스가 실제로 /etc/mihomo를 사용하면서 파일을 현재 사용자의 ~/.config/mihomo에 복사하면, 재시작해도 당연히 적용되지 않습니다.

mihomo -v
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml -t

sudo systemctl stop mihomo
sudo mv /etc/mihomo/GeoSite.dat /etc/mihomo/GeoSite.dat.bak
sudo cp GeoSite.dat /etc/mihomo/GeoSite.dat
sudo systemctl start mihomo
sudo systemctl status mihomo

-t는 설정을 로드할 수 있는지 테스트하는 옵션입니다. 먼저 테스트한 뒤 서비스를 재시작하면 문법 오류와 Geo 파일 오류를 구분할 수 있습니다. 서비스 계정에는 새 파일을 읽을 권한도 필요합니다. 복사 후 소유자가 현재 로그인 사용자로 바뀌었다면 기존 파일의 소유자와 권한에 맞게 조정하세요.

교체에 실패했을 때 되돌리는 방법

커널을 중지하고 방금 넣은 새 파일을 삭제한 뒤 .bak 파일의 이름을 원래대로 되돌리면 됩니다. 되돌린 후에도 오류가 발생한다면 문제는 데이터베이스 자체가 아니라 YAML 문법, 규칙 분류명 또는 디렉터리 선택에 있을 수 있습니다. 특히 GEOSITE 분류가 실제로 존재하는지 확인하세요. 철자 오류는 데이터베이스를 업데이트해도 자동으로 수정되지 않습니다.

자동 업데이트가 적용되지 않을 때의 점검 순서

자동 업데이트는 타이머, 다운로드 주소, 파일 쓰기, 다시 로드하는 네 단계로 진행됩니다. “다운로드 시작”만 보였다고 업데이트가 완료된 것은 아니므로, 아래 순서대로 단계별로 확인하는 것이 좋습니다.

1단계: 현재 커널에 설정이 실제로 전달되는지 확인

클라이언트의 실행 설정 미리보기에서 geo-auto-update를 검색합니다.
구독 덮어쓰기나 스크립트가 geox-url을 삭제하지 않았는지 확인합니다.
디스크에 있는 예비 YAML만 편집하지 말고 현재 활성 설정을 확인합니다.
수정 후 「설정」→「다시 로드」를 실행하고, 필요하면 커널을 재시작합니다.

일부 클라이언트는 구독 업데이트 후 실행 설정을 다시 생성합니다. Geo 매개변수를 생성된 임시 파일에만 작성하면 다음 구독 새로고침 때 사라집니다. 클라이언트가 제공하는 전역 덮어쓰기, 병합 설정 또는 안정적인 기본 설정 파일에 작성하는 편이 안전합니다.

2단계: 네트워크와 HTTP 응답 확인

Geo 데이터 다운로드는 프록시가 완전히 시작되기 전에 진행될 수 있습니다. 다운로드 주소에 프록시가 있어야만 접근할 수 있다면 작은 순환 문제가 생길 수 있습니다. 데이터베이스를 내려받지 못해 설정을 로드할 수 없고, 설정을 로드하지 못해 프록시도 사용할 수 없는 상황입니다. 이때는 파일을 임시로 수동 다운로드하거나 현재 네트워크에서 직접 접근할 수 있는 데이터 출처를 선택하세요.

로그의 HTTP 403은 요청 방식이 출처 제한에 걸렸을 때 흔히 발생하고, 404는 대개 파일명이나 배포 경로가 바뀐 경우입니다. 시간 초과가 발생하면 DNS, 게이트웨이, 방화벽을 확인하세요. 응답이 HTML 페이지라면 커널은 대개 이어서 파싱 실패를 보고합니다. 다운로드가 완료됐다고 파일 내용까지 올바른 것은 아닙니다.

3단계: 디렉터리 쓰기 권한 확인

시스템 서비스는 전용 계정으로 실행되는 경우가 많습니다. 데이터 디렉터리를 읽을 수는 있지만 쓸 수 없다면 기존 데이터베이스는 로드되더라도 자동 업데이트 파일을 저장할 수 없습니다. Linux에서는 서비스 상태와 로그를 확인하고, macOS에서는 클라이언트가 읽기 전용 앱 번들에서 실행되는지 살펴보세요. Windows에서는 추가 권한이 필요한 프로그램 설치 디렉터리에 동적 데이터를 저장하지 않는 것이 좋습니다.

4단계: 타이머를 반복해서 초기화하지 않기

geo-update-interval: 24는 커널 로직에 따른 간격으로 확인한다는 뜻입니다. 10분마다 클라이언트를 재시작하면 버전에 따라 시작 시 다음 업데이트 시각을 다시 계산할 수 있습니다. 테스트할 때는 클라이언트의 “Geo 데이터 즉시 업데이트” 기능을 사용해 성공 여부를 확인한 뒤 24시간 또는 72시간으로 되돌리세요. 장기간 1시간으로 설정하는 것은 권장하지 않습니다.

업데이트 후 규칙 매칭이 정확해졌는지 확인

데이터베이스 교체가 성공한 것은 첫 단계일 뿐입니다. DNS 캐시와 이미 연결된 세션에는 이전 결과가 남아 있을 수 있으므로, 확인하기 전에 대상 연결을 끊고 클라이언트가 지원한다면 DNS 캐시도 삭제하세요. 브라우저 자체가 연결을 재사용할 수도 있으므로, 연속 새로고침보다 브라우저를 완전히 종료했다가 다시 여는 편이 확실합니다.

세 가지 테스트 대상 준비

GEOSITE,cn에 확실히 매칭되어야 하는 도메인 하나.
프록시를 통해 접속해야 하며, 최종적으로 특정 분류 또는 MATCH에 매칭되어야 하는 도메인 하나.
IP로만 연결하는 테스트 대상 하나. GEOIP 결과를 확인하는 데 사용합니다.

테스트할 때 연결 패널의 Host, Destination IP, Rule, Rule Payload, 최종 프록시 그룹을 기록하세요. 웹페이지가 열리는지만 확인해서는 안 됩니다. 직접 연결과 프록시 연결 모두 성공할 수 있기 때문입니다. 실제로 확인해야 할 것은 예상한 규칙에 매칭됐는지입니다.

Geo 데이터 오류와 DNS 오류 구분하기

도메인 규칙은 올바르지만 해석된 주소가 이상하다면 DNS 설정을 점검해야 합니다. nameserver, proxy-server-nameserver, Fake-IP 필터 항목, 시스템 DNS 하이재킹이 활성화되어 있는지 확인하세요. GeoSite는 도메인을 분류할 뿐 DNS가 어떤 주소를 반환할지 보장하지 않습니다. GeoIP는 대상 IP의 소속을 판단하지만 DNS 오염을 직접 수정하지도 않습니다.

규칙이 GEOIP,CN,DIRECT,no-resolve로 작성된 경우 no-resolve는 이 규칙만을 위해 커널이 도메인을 추가로 해석하지 못하게 합니다. 대상 연결에 이미 IP가 있으면 계속 매칭될 수 있지만, 도메인만 있고 앞선 도메인 규칙이 매칭되지 않았다면 국가를 판단하기 위해 해석을 시도하지 않습니다. “GEOIP가 반응하지 않는다”는 문제를 확인할 때 이 매개변수를 놓치기 쉽습니다.

비교를 위해 임시로 정확한 규칙 하나 유지하기

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

정확한 DOMAIN-SUFFIX는 매칭되지만 GEOSITE,cn은 매칭되지 않는다면, 분류 데이터나 분류명 또는 GeoSite 파일 로드 문제일 가능성이 큽니다. 둘 다 매칭되지 않는다면 규칙이 실행 설정에 들어갔는지, 대상 애플리케이션의 트래픽이 Clash를 거치는지, TUN 또는 시스템 프록시가 실제로 연결을 인계했는지 확인해야 합니다.

안정적으로 유지 관리하는 설정 권장 사항

Geo 데이터 관리는 복잡한 절차가 필요하지 않습니다. 안정적인 출처 하나를 정하고 적절한 업데이트 주기를 유지하며 이전 버전 파일을 보관하고, 업데이트 후 규칙 매칭을 표본 점검하면 됩니다. 장기간 실행되는 게이트웨이라면 설정 변경과 데이터베이스 업데이트를 분리하세요. 먼저 데이터베이스를 업데이트하고 하루 동안 관찰한 다음 규칙을 조정하면 문제가 생겼을 때 원인을 쉽게 좁힐 수 있습니다.

데스크톱 클라이언트: 24~72시간마다 확인하는 것을 권장합니다.
홈 게이트웨이: 72~168시간마다 확인하고 이전 버전 파일을 보관하는 것을 권장합니다.
구독 업데이트와 Geo 업데이트를 따로 기록하세요. 두 작업을 같은 버튼으로 생각하지 마세요.
규칙 순서는 “정확한 도메인 → 분류 도메인 → IP 지리 정보 → MATCH”를 유지하세요.
MMDB와 DAT 모드를 전환하기 전에 현재 커널과 설정 필드가 모두 지원하는지 확인하세요.
업데이트가 끝나면 웹페이지가 열리는지만 보지 말고 연결 패널의 매칭 규칙을 확인하세요.

트래픽 분류가 잘못될 때 가장 짧은 점검 순서는 다음과 같습니다. 트래픽이 실제로 인계됐는지 확인하고, 적용된 규칙을 살펴보고, Geo 파일과 모드를 대조한 뒤, 커널을 업데이트하고 재시작하고, 마지막으로 기존 연결을 정리한 다음 다시 테스트하세요. 이 순서대로 진행하면 노드, DNS, 규칙 순서, 데이터베이스 문제를 분리할 수 있어 설정 파일을 무작정 반복 수정하지 않아도 됩니다.