먼저 GeoIP, GeoSite, 규칙의 차이부터 이해하기
GeoIP와 GeoSite는 모두 규칙 엔진이 조회하는 데이터셋이지만 처리 대상은 다릅니다. GeoIP는 대상 IP 주소를 바탕으로 국가, 지역 또는 사설 네트워크 범위를 판단하고, GeoSite는 도메인이 속한 사이트 그룹을 판단합니다. 설정의 GEOIP와 GEOSITE는 조회 명령일 뿐이며, 실제 분류 내용은 로컬 데이터베이스 파일에서 제공됩니다.
한 번의 접속을 예로 들면, 요청 대상이 도메인일 때 mihomo는 먼저 도메인 규칙이나 GeoSite 분류로 매칭할 수 있습니다. 앞선 규칙이 일치하지 않으면 이후의 GEOIP 규칙이 DNS 조회를 실행한 다음, 조회 결과로 IP 데이터베이스를 검색할 수 있습니다. 최종 전략 그룹은 규칙 목록에서 처음 일치한 규칙이 결정합니다. 데이터베이스는 해당 도메인이나 IP가 어느 그룹에 속하는지만 알려 줄 뿐, 직접 연결·프록시·차단 여부를 결정하지는 않습니다.
| 데이터 유형 | 매칭 대상 | 주요 파일 | 대표 용도 |
|---|---|---|---|
| GeoSite | 도메인 | geosite.dat |
사이트 유형, 서비스 제공업체 또는 지역별 도메인 그룹에 따른 트래픽 분기 |
| GeoIP Dat | IPv4 및 IPv6 주소 | geoip.dat |
geodata 모드에서 국가·지역별 IP 매칭 수행 |
| MMDB | IPv4 및 IPv6 주소 | country.mmdb |
MMDB 모드에서 GEOIP 규칙에 위치 정보 제공 |
| ASN MMDB | IP가 속한 자율 시스템 | GeoLite2-ASN.mmdb |
ASN 규칙 또는 관련 조회 기능에 사용 |
GeoSite는 최상위 도메인 목록이 아닙니다. 예를 들어 GEOSITE,cn은 데이터 제공자가 정리한 도메인 그룹을 조회하는 것이며, .cn으로 끝나는 주소만 매칭한다는 뜻이 아닙니다. 중국 본토 서비스라도 .com을 사용할 수 있고 이 그룹에 포함될 수 있습니다. 분류 결과는 현재 데이터베이스 버전에 따라 달라집니다.
geodata 모드와 MMDB 모드의 차이
geodata-mode를 활성화하면 어떻게 되나
geodata-mode: true로 설정하면 mihomo는 geoip.dat로 GEOIP 분류를 처리하고 geosite.dat로 GEOSITE 분류를 처리합니다. Dat 파일에는 여러 태그 그룹을 담을 수 있으며, 규칙에서 자주 사용하는 CN, LAN 또는 특정 GeoSite 태그는 파일 내부 항목에 매핑됩니다.
geodata-mode: true
geodata-loader: memconservativegeodata-loader는 geodata 데이터의 로딩 방식을 제어합니다. standard는 미리 로드하는 방식에 가까워 연속 매칭 시 성능 부담이 비교적 일정하지만 메모리를 더 사용합니다. memconservative는 필요할 때 로드하는 방식에 가까워 메모리가 적은 라우터나 컨테이너에 적합합니다. 사용 가능한 메모리가 약 100MB인 기기라면 먼저 memconservative를 선택하고, 규칙 로딩 및 최초 매칭 시간을 확인한 뒤 조정하는 것이 좋습니다.
geodata-mode를 비활성화하면 어떻게 되나
geodata-mode: false로 설정하면 GEOIP 조회는 일반적으로 country.mmdb를 사용합니다. MMDB는 IP 조회를 위한 데이터베이스 형식이므로 GeoSite의 도메인 분류를 대신할 수 없습니다. 따라서 설정에 GEOSITE 규칙이 있다면 geosite.dat도 계속 사용할 수 있어야 합니다.
geodata-mode: false두 모드 중 어느 것이 모든 기기에서 더 빠르다고 단정할 수는 없습니다. 데이터베이스 크기, 규칙 수, 디스크 성능, 로더 설정이 모두 결과에 영향을 줍니다. 데스크톱에서는 데이터 소스의 범위와 업데이트 주기를 우선 확인하고, 메모리가 적은 기기에서는 mihomo 실행 후 상주 메모리도 함께 확인해야 합니다. 모드를 전환한 뒤에는 화면에서 설정만 다시 불러오지 말고 코어를 완전히 재시작해야 합니다.
- 규칙에서
GEOSITE와 Dat 태그를 많이 사용한다면 geodata 모드를 우선 고려할 수 있습니다. - 기존 규칙이 주로
GEOIP,CN이고 데이터 소스가 MMDB만 제공한다면 MMDB 모드를 계속 사용해도 됩니다. geoip.dat의 이름을country.mmdb로 바꾸지 마세요. 확장자가 다르다는 것은 내부 형식도 다르다는 뜻입니다.- 모드를 전환하기 전에 기존 데이터베이스 파일을 보관해 두면 분류 오류나 시작 오류가 발생했을 때 쉽게 복구할 수 있습니다.
데이터베이스 자동 업데이트 설정
mihomo는 지정된 주소에서 GeoIP, GeoSite, MMDB 및 ASN 데이터를 가져올 수 있습니다. 핵심 필드는 geo-auto-update, geo-update-interval, geox-url입니다. 업데이트 간격의 단위는 시간이며, 24로 설정하면 24시간마다 한 번 확인합니다. 지리 분류 데이터는 보통 분 단위로 갱신할 필요가 없으므로, 데스크톱과 가정용 게이트웨이 대부분에서는 하루 한 번이면 충분합니다.
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"
asn: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/GeoLite2-ASN.mmdb"현재 geodata 모드를 사용 중이어도 나중에 전환할 수 있도록 MMDB 주소를 남겨 둘 수 있습니다. 다만 현재 규칙 경로에서 실제로 사용하는 파일은 모드와 규칙 유형이 결정합니다. 클라이언트의 오버라이드 기능으로 설정을 병합한다면 이 필드는 최상위에 배치해야 하며, dns, rules, proxy-groups 아래로 들여쓰면 안 됩니다.
업데이트 요청은 직접 연결할까, 프록시를 사용할까
데이터베이스 다운로드 성공 여부는 코어 실행 중 데이터 주소에 접근할 수 있는지에 달려 있습니다. 일부 클라이언트는 코어가 시작되는 초기에 파일을 다운로드하므로 이때는 프록시 정책이 아직 완전히 작동하지 않을 수 있습니다. 다른 클라이언트는 업데이트 요청을 현재 규칙을 통해 보냅니다. 로그에 시간 초과가 계속 나타나면 먼저 브라우저에서 주소에 접근할 수 있는지 확인한 뒤 DNS, 시스템 시간, 아웃바운드 규칙, 클라이언트가 코어 프로세스를 우회하도록 설정했는지 점검하세요.
문제를 확인할 때는 「로그」→「로그 수준」→「정보」 또는 「디버그」를 선택한 다음 코어를 재시작하세요. 정상적인 과정이라면 지리 데이터 다운로드, 기록 또는 로드 로그가 나타납니다. 30초가 지나도 연결 시간 초과만 표시된다면 업데이트 버튼을 계속 누르지 마세요. 먼저 데이터 도메인이 어느 전략 그룹과 매칭되는지 확인하고, 해당 전략 그룹의 현재 노드가 작동하는지 점검하세요.
GeoIP 및 GeoSite 파일 수동 교체
자동 업데이트가 실패하거나 기기에서 데이터 소스에 직접 접근할 수 없거나 특정 데이터 버전을 고정해야 할 때는 파일을 수동으로 교체할 수 있습니다. 핵심은 mihomo의 실제 작업 디렉터리를 찾는 것입니다. 명령줄의 기본 디렉터리는 Linux와 macOS에서 보통 ~/.config/mihomo/, Windows에서 보통 %USERPROFILE%\.config\mihomo\입니다. 시작 명령에 -d가 사용되었다면 -d 뒤에 지정된 디렉터리를 기준으로 합니다.
그래픽 클라이언트는 자체 애플리케이션 데이터 디렉터리를 사용하는 경우가 많아 위의 기본 경로를 읽지 않을 수 있습니다. 클라이언트의 「설정」→「설정 디렉터리」 또는 「설정」→「애플리케이션 디렉터리」에서 실제 위치를 열고, 로그에 표시된 데이터베이스 경로로 다시 확인하세요. 파일 관리자에서 같은 이름의 파일만 검색해서는 안 됩니다. 구버전 디렉터리와 현재 실행 디렉터리가 동시에 존재할 수 있기 때문입니다.
- 현재 코어 버전,
geodata-mode설정, 작업 디렉터리를 기록합니다. - 교체 중 파일 핸들이 계속 사용되지 않도록 mihomo 코어를 중지합니다.
- 기존 파일의 이름을 바꿔 보관합니다. 예를 들어
geosite.dat을geosite.dat.bak으로 변경합니다. - 새 파일을 복사하고 코어가 예상하는 이름을 유지합니다:
geoip.dat,geosite.dat,country.mmdb또는GeoLite2-ASN.mmdb. - 코어를 다시 시작하고 로그에 지원되지 않는 형식, 누락된 태그 또는 파일 읽기 실패가 표시되는지 확인합니다.
- 클라이언트에 “실행 중”이라고 표시되는지만 보지 말고, 명확한 테스트 규칙 하나로 매칭 결과를 검증하세요.
교체 후 load GeoSite failed, invalid database 또는 지정한 태그가 없다는 오류가 발생하면 먼저 백업 파일을 복원한 뒤 데이터 형식과 설정 모드를 확인하세요. 파일을 다운로드할 수 있다고 해서 현재 코어에 적합하다는 뜻은 아닙니다. 일부 데이터 소스는 태그 이름을 다르게 사용하므로 GEOSITE,cn은 작동하지만 더 세분화된 분류 태그는 작동하지 않을 수 있습니다.
GEOIP 및 GEOSITE 규칙 작성 방법
읽기 쉬운 기본 순서
mihomo는 위에서 아래로 규칙을 매칭하며 일치하면 검사를 중단합니다. 따라서 더 구체적인 규칙을 더 넓은 지리 규칙보다 앞에 배치하고, 마지막에는 MATCH로 기본 처리해야 합니다. 아래의 노드 선택과 국내 직접 연결은 설정에 실제로 존재하는 전략 그룹 이름과 일치해야 합니다.
rules:
- DOMAIN,api.example.org,노드 선택
- DOMAIN-SUFFIX,example.org,노드 선택
- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,국내 직접 연결
- GEOIP,LAN,DIRECT,no-resolve
- GEOIP,CN,국내 직접 연결
- MATCH,노드 선택첫 번째 정확한 도메인 규칙의 우선순위가 가장 높습니다. 두 번째 규칙은 해당 도메인과 하위 도메인을 포괄합니다. 그 다음에야 GeoSite 분류와 GeoIP 판단이 진행됩니다. 특수 처리가 필요한 중국 본토 사이트 규칙보다 GEOSITE,cn,국내 직접 연결을 앞에 배치하면 특수 규칙은 영원히 매칭되지 않을 수 있습니다.
| 규칙 | 입력 | 조회가 발생할 수 있나 | 적합한 위치 |
|---|---|---|---|
DOMAIN |
전체 도메인 | 아니요 | 가장 구체적인 규칙 영역 |
DOMAIN-SUFFIX |
도메인 접미사 | 아니요 | 구체적인 서비스 분류보다 앞 |
GEOSITE |
도메인 분류 | 아니요 | 일반 도메인 규칙 다음 |
GEOIP |
대상 IP | 대상이 도메인이면 발생할 수 있음 | 도메인 규칙 다음, 기본 처리 이전 |
MATCH |
그 밖의 모든 연결 | 아니요 | 마지막 규칙 |
no-resolve의 적용 범위 이해하기
no-resolve는 매칭을 위해 이 IP 규칙이 도메인을 능동적으로 조회하지 않도록 합니다. GEOIP,LAN,DIRECT,no-resolve처럼 이미 알고 있는 대상 IP를 주로 처리하는 규칙에 적합하며, 불필요한 DNS 조회를 줄일 수 있습니다. 하지만 연결 대상이 여전히 도메인이고 앞선 규칙이 일치하지 않았다면, 대상 IP를 얻지 못해 이 GEOIP 규칙이 건너뛰어질 수 있습니다.
따라서 모든 GEOIP 규칙에 기계적으로 no-resolve를 추가해서는 안 됩니다. GEOIP,CN을 중국 본토 트래픽의 주요 기본 규칙으로 사용한다면 DNS 모드, 스니핑 결과, 실제 연결 유형을 함께 테스트해야 합니다. TUN 모드를 활성화하면 mihomo가 처리하는 트래픽 범위는 넓어지지만, 규칙 순서와 데이터베이스 조회 로직 자체는 바뀌지 않습니다.
데이터베이스와 규칙이 실제로 적용되었는지 확인하는 방법
검증할 때는 “파일이 로드되었는가”와 “요청이 올바른 규칙과 매칭되었는가”를 함께 확인해야 합니다. 데이터베이스 업데이트 시간만 바뀌었다고 해서 규칙 순서가 올바르다는 뜻은 아닙니다. 연결에 성공했다고 해서 트래픽이 예상한 전략 그룹을 거쳤다는 뜻도 아닙니다.
GeoSite 규칙 테스트
- 일시적으로 대상 분류를 알아보기 쉬운 전략 그룹, 예를 들어
국내 직접 연결로 지정합니다. - 「로그」→「로그 수준」에서 “정보” 또는 “디버그”를 선택합니다.
- 브라우저의 기존 연결을 정리한 뒤 테스트 도메인에 다시 접속합니다.
- 로그에서 규칙 유형, 매칭된 태그, 최종 전략 그룹을 확인합니다.
- 테스트가 끝나면 정식 설정으로 복원하여 임시 규칙을 장기간 남겨 두지 않습니다.
GEOIP 테스트 시 캐시 간섭 피하기
브라우저는 HTTP/2 또는 HTTP/3 연결을 재사용할 수 있고, DNS 결과도 시스템·브라우저·mihomo 캐시에서 가져올 수 있습니다. 규칙을 수정한 뒤 먼저 클라이언트에서 「설정」→「다시 로드」를 실행하고 관련 탭을 닫은 다음 기존 연결이 종료될 때까지 기다리세요. 필요하면 브라우저나 코어를 재시작한 뒤 새 연결로 로그를 확인합니다.
하나의 도메인이 여러 IP를 반환하면 GeoIP 분류 결과가 조회 결과에 따라 달라질 수 있습니다. CDN 서비스에서 특히 흔한 현상으로, 네트워크·DNS 서버·시간대에 따라 서로 다른 지역의 주소가 반환될 수 있습니다. 이런 서비스에는 GEOIP에 전적으로 의존하기보다 DOMAIN, DOMAIN-SUFFIX 또는 GEOSITE 규칙을 우선 사용하는 편이 적합합니다.
자주 발생하는 문제와 처리 순서
GeoSite 태그를 찾을 수 없다는 메시지
먼저 현재 작업 디렉터리의 코어가 geosite.dat을 읽었는지 확인한 다음 태그 철자를 확인하세요. 태그는 데이터 소스가 정의하므로 서비스 이름만 보고 임의로 추측할 수 없습니다. 로그가 특정 태그에서만 오류를 표시한다면 현재 데이터셋에 해당 분류가 없는 경우가 많습니다. 모든 GEOSITE 규칙이 실패한다면 파일 경로, 파일 형식 또는 로드 과정에 문제가 있을 가능성이 큽니다.
업데이트는 성공했지만 규칙 결과가 바뀌지 않음
일부 클라이언트는 새 파일을 다운로드한 뒤 코어를 재시작해야 다시 로드합니다. 먼저 「설정」→「코어」→「코어 재시작」을 실행한 다음 시작 로그에 표시된 데이터 파일 경로를 확인하세요. 로그가 여전히 다른 디렉터리를 가리킨다면 시작 매개변수의 -d와 클라이언트가 구독 설정을 별도 디렉터리에서 실행하는지 확인해야 합니다.
설정 파싱 중 필드 오류 발생
보통 코어 버전이 오래되었거나 클라이언트가 예상한 mihomo 파일이 아닌 다른 파일을 실행하고 있다는 뜻입니다. mihomo -v를 실행한 뒤 클라이언트의 「설정」→「코어」에 표시된 버전과 비교하세요. 코어를 업그레이드하기 전에는 클라이언트가 해당 코어 인터페이스를 지원하는지 확인해야 합니다. 당장 업그레이드할 수 없다면 구버전에서 인식하지 못하는 필드를 다른 YAML 계층으로 옮기지 말고 삭제하세요.
TUN 모드에서도 일부 앱이 지리 규칙에 따라 분기되지 않음
먼저 해당 연결이 mihomo로 들어왔는지 확인한 다음 도메인이 노출되는지 확인하세요. 대상 IP만 있고 도메인이 없으면 GEOSITE가 직접 매칭할 수 없습니다. 이때는 스니핑으로 도메인을 복원하거나 GEOIP 규칙으로 처리해야 할 수 있습니다. 또한 프로세스 규칙이나 IP-CIDR 규칙이 지리 규칙보다 앞에 있는지도 확인하세요. 먼저 매칭된 규칙이 검사를 즉시 종료하기 때문입니다.
전체 문제 해결 순서는 코어 버전 확인, 작업 디렉터리 확인, 데이터베이스 로드 로그 확인, 규칙 순서 확인, DNS 또는 스니핑 결과 확인, 마지막으로 전략 그룹 출구 확인으로 고정할 수 있습니다. 이 순서대로 점검하면 “데이터베이스가 업데이트되지 않음”과 “규칙이 매칭되지 않음”을 서로 독립된 문제로 구분할 수 있습니다.