Clash GeoIP 및 GeoSite 데이터 업데이트: 규칙 참조, 갱신 주기와 문제 해결

먼저 GeoIP, GeoSite와 규칙 세트를 구분하기

핵심부터 말하면, GeoIP는 대상 IP 주소를 기준으로 분류하고 GeoSite는 도메인을 기준으로 분류하므로 서로 대체할 수 없습니다. 설정에 GEOIP 또는 GEOSITE를 입력했다는 것은 규칙 엔진이 해당 데이터베이스를 조회한다는 뜻일 뿐입니다. 최종적으로 직접 연결할지, 프록시를 사용할지, 거부할지는 규칙 끝에 지정된 정책이 결정합니다. 데이터베이스 자체가 프록시 연결을 만들거나 현재 프록시 모드를 자동으로 바꾸지는 않습니다.

GeoIP 데이터는 IP 대역을 국가, 지역 또는 기타 식별 가능한 분류에 매핑합니다. 일반적인 규칙 GEOIP,CN,DIRECT는 연결 대상 IP가 데이터베이스에서 CN으로 분류될 때 DIRECT 정책으로 처리한다는 의미입니다. 코어에 따라 MMDB, 전용 GeoIP 데이터 파일 또는 변환된 내부 형식을 사용할 수 있으며 파일명과 로드 방식도 완전히 같지 않습니다. 따라서 확장자만 보고 현재 코어가 데이터베이스를 사용 중인지 판단해서는 안 됩니다.

GeoSite 데이터에는 지역별 도메인, 자주 사용하는 서비스, 광고 도메인 등 도메인 집합과 분류 태그가 저장됩니다. GEOSITE,cn,DIRECT 규칙은 연결에 포함된 도메인을 집합과 대조합니다. DNS 해석 전에 도메인별 트래픽을 분기하는 데 적합하며, IP 위치만 의존할 때 CDN, 글로벌 라우팅, 공유 주소 때문에 발생하는 오판도 줄일 수 있습니다.

규칙 세트는 일반적으로 rule-providers가 제공하는 외부 규칙 파일을 뜻합니다. 도메인, IP-CIDR 또는 클래식 규칙 항목을 담은 뒤 RULE-SET으로 참조할 수 있습니다. 규칙 세트와 GeoSite 모두 도메인 분류를 저장할 수 있지만, 다운로드 주소, 업데이트 주기, 동작 유형과 설정 진입점은 서로 다릅니다. 특정 규칙 세트를 업데이트했다고 해서 GeoSite 데이터까지 함께 업데이트되는 것은 아니며, 그 반대도 마찬가지입니다.

설정에서 GeoIP와 GeoSite를 참조하는 방법

규칙은 위에서 아래로 검사하며, 일치하면 이후 매칭을 중단합니다. 데이터베이스 업데이트가 성공했더라도 관련 규칙이 더 포괄적인 규칙 뒤에 있으면 트래픽은 새 규칙까지 도달하지 않습니다. “데이터베이스는 업데이트됐지만 트래픽 분기가 바뀌지 않는” 문제를 점검할 때는 파일을 반복해서 다운로드하기보다 규칙 순서를 먼저 확인하는 편이 효과적입니다.

다음은 GEOSITE를 지원하는 Mihomo에서 사용할 수 있는 설정 예시입니다. 정책 그룹 이름은 현재 기기의 설정과 일치해야 하며, 예시의 노드 선택은 정책 이름일 뿐 고정 키워드가 아닙니다.

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,노드 선택

첫 번째 규칙은 광고 도메인 분류를 처리하고, 두 번째 규칙은 CN 도메인을 처리합니다. 세 번째 규칙은 대상 IP를 확인할 수 있을 때 CN 주소를 매칭하며, 마지막 규칙은 앞에서 매칭되지 않은 연결을 처리합니다. MATCH를 맨 앞에 두면 이후 Geo 데이터베이스 규칙은 절대 매칭될 수 없습니다. 또한 GEOSITE,cn,DIRECT 앞에 범위가 더 넓은 도메인 규칙을 배치하면 직접 연결되어야 할 도메인을 먼저 가로챌 수 있습니다.

no-resolve는 IP 유형 규칙에서 주로 사용되며, 해당 규칙을 매칭하기 위해 규칙 엔진이 추가로 도메인 해석을 수행하지 않도록 합니다. 이미 존재하는 대상 IP를 건너뛴다는 뜻도 아니고 DNS 모듈을 끈다는 뜻도 아닙니다. IP로 직접 연결하는 경우 GeoIP는 계속 매칭할 수 있습니다. 당시 도메인만 있고 실제 대상 IP를 아직 얻지 못한 연결에서는 이 규칙이 매칭되지 않을 수 있으며, 트래픽은 다음 규칙을 계속 검사합니다.

도메인 규칙과 IP 규칙을 모두 유지해야 할까?

지역별 트래픽 분기 설정에서는 대부분 두 규칙을 함께 유지합니다. GeoSite는 도메인을 확인할 수 있을 때 먼저 판단하고, GeoIP는 IP로 직접 접속하거나 도메인 정보가 없거나 도메인 규칙이 처리하지 못한 연결을 보완합니다. CDN 노드는 서로 다른 지역에 있을 수 있으므로 서비스의 도메인 소속 지역과 대상 IP의 위치가 항상 일치하지는 않습니다. 서비스 단위로 안정적인 분기를 원한다면 명확한 도메인 또는 GeoSite 분류를 앞에 배치하고, 나머지 연결은 GeoIP가 처리하도록 구성하세요.

TUN 및 Fake-IP 모드에서의 판단 위치

TUN 모드는 더 많은 시스템 트래픽을 가로채지만 규칙 데이터베이스의 정확도를 자동으로 높여 주지는 않습니다. Fake-IP DNS를 사용하면 클라이언트가 애플리케이션에 내부 매핑 주소를 반환하고, 코어는 원래 도메인을 최대한 복원해 도메인 규칙을 실행합니다. 이후 실제 연결을 만들 때는 대상 IP를 얻을 수도 있습니다. 애플리케이션이 하드코딩된 IP에 직접 연결하거나 자체 해석 방식을 사용하거나 복원 가능한 도메인 정보가 부족한 경우에는 GeoSite가 적용되지 않을 수 있습니다. 이때는 IP 규칙과 최종 폴백 정책이 더 중요합니다.

TUN을 켠 뒤 규칙 동작이 달라졌다고 해서 곧바로 데이터베이스 손상으로 판단해서는 안 됩니다. 먼저 일반 시스템 프록시와 TUN 환경에서 해당 연결의 도메인 정보가 유지되는지 비교한 다음 DNS 모드, 스니핑 설정, Fake-IP 필터와 규칙 순서를 확인하세요. 데이터베이스는 매칭 데이터를 제공할 뿐이며, 연결 컨텍스트는 코어가 트래픽을 가로채는 방식에 따라 달라집니다.

문제 발생 시 되돌릴 수 있는 데이터 업데이트 방식 선택

업데이트 방식은 크게 클라이언트 관리, 코어 자동 업데이트, 수동 교체 세 가지로 나뉩니다. 데이터 디렉터리, 파일명과 리로드 절차를 알고 있는 경우가 많으므로 우선 클라이언트나 코어에서 제공하는 업데이트 기능을 사용하세요. 수동 다운로드는 특정 버전 고정, 사내망 배포 또는 업데이트 오류 분석에 적합하지만, 교체 전에 파일 형식이 현재 코어와 호환되는지 반드시 확인해야 합니다.

클라이언트 관리 업데이트

일부 데스크톱 및 모바일 클라이언트는 설정 화면에 GeoIP, GeoSite 또는 규칙 데이터 업데이트 버튼을 제공합니다. 버튼을 누르면 클라이언트가 데이터를 다운로드해 자체 실행 디렉터리에 저장합니다. 구현에 따라 코어를 자동으로 재시작하기도 하고, 다음 설정 로드 시점에만 적용하기도 합니다. 작업 후에는 업데이트 결과, 파일 날짜와 코어 로그를 확인해야 하며 버튼 상태만으로 성공 여부를 판단해서는 안 됩니다.

Mihomo 코어 자동 업데이트

Geo 데이터 자동 업데이트를 지원하는 Mihomo 버전에서는 설정으로 업데이트 여부와 주기를 제어할 수 있습니다. 버전에 따라 필드, 데이터 형식과 기본 주소 처리 방식이 달라질 수 있으므로 현재 코어 문서와 클라이언트가 생성한 설정을 기준으로 삼아야 합니다. 일반적인 설정 구조는 다음과 같습니다.

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

geo-update-interval은 일반적으로 시간 단위로 이해합니다. 일반적인 사용 환경에는 24시간이면 충분하며 업데이트 간격을 몇 분으로 줄일 필요는 없습니다. Geo 데이터는 실시간 라우팅 테이블이 아니므로 지나치게 자주 요청하면 시작 실패, 네트워크 시간 초과와 파일 쓰기 충돌 가능성만 커집니다. 안정성이 중요한 기기는 일주일에 한 번 또는 클라이언트 유지보수 시간에 업데이트하고 로그로 결과를 확인하는 방식을 사용할 수 있습니다.

설정에 geox-url도 정의되어 있다면 코어는 해당 주소에서 GeoIP, GeoSite 또는 MMDB 데이터를 가져옵니다. 데이터 소스는 현재 코어가 인식할 수 있는 콘텐츠를 제공해야 합니다. 웹페이지 주소, 압축 파일 다운로드 페이지 또는 다른 형식의 파일을 입력하면 요청 자체는 성공해도 로드 단계에서 실패할 수 있습니다. 구독 변환 서비스가 설정을 생성하는 경우 원격 업데이트가 로컬 자동 업데이트 필드를 덮어쓰지 않는지도 확인해야 합니다.

데이터베이스 수동 교체

1. 데이터베이스를 읽는 중 덮어써지지 않도록 클라이언트에서 코어를 중지합니다.
2. 설치 패키지의 압축 해제 폴더나 브라우저 다운로드 폴더가 아니라 클라이언트가 실제로 사용하는 데이터 디렉터리를 찾습니다.
3. 현재 정상적으로 사용할 수 있는 파일을 백업하고 코어 버전과 기존 파일의 수정 시간을 기록합니다.
4. 형식이 일치하는 새 파일을 넣고 클라이언트가 요구하는 파일명과 접근 권한을 유지합니다.
5. 코어를 다시 시작하고 설정을 로드한 뒤 로그에 파싱, 파일 열기 또는 권한 오류가 나타나는지 확인합니다.
6. 구체적인 도메인과 IP로 규칙 매칭을 테스트하며, 파일 크기가 커졌다는 사실만으로 업데이트 성공을 판단하지 않습니다.

업데이트 실패 또는 규칙 미적용 시 단계별 점검

점검할 때는 “다운로드 실패”, “파일 로드 실패”, “규칙 미참조”, “규칙은 매칭됐지만 정책 결과가 예상과 다름”을 구분해야 합니다. 화면에서는 모두 웹사이트가 잘못된 경로로 연결되는 것처럼 보일 수 있지만 해결 방법은 전혀 다릅니다. 데이터 다운로드, 코어 로드, 설정 파싱, 규칙 매칭, 정책 실행의 다섯 단계로 확인하는 것이 좋습니다.

1단계: 데이터 다운로드 완료 여부

• 로그에서 요청 상태, 시간 초과, DNS 해석과 연결 오류를 확인합니다.
• 업데이트 트래픽 자체가 데이터 소스에 접근할 수 있는지 확인합니다. 시작 단계에 아직 프록시가 연결되지 않았다면 다운로드가 직접 연결 네트워크만 사용할 수 있습니다.
• 시스템 시간을 확인합니다. 시간이 크게 어긋나면 TLS 연결을 수립하지 못할 수 있습니다.
• 저장 공간과 디렉터리 쓰기 권한을 확인합니다. 모바일 기기에서는 시스템이 앱 데이터를 정리했는지 또는 백그라운드 네트워크를 제한했는지도 살펴보세요.
• 클라이언트가 다운로드 결과를 다른 설정 인스턴스의 데이터 디렉터리에 저장하고 있지 않은지 확인합니다.

2단계: 코어의 파일 로드 성공 여부

다운로드 완료가 곧 로드 가능을 의미하지는 않습니다. 로그에 데이터베이스 형식 오류, 존재하지 않는 태그, 파일 열기 실패 또는 파싱 오류가 나타나면 먼저 이전에 정상 작동하던 데이터 파일로 되돌리세요. 흔한 원인은 실제 파일 내용이 오류 페이지인 경우, 코어와 데이터 형식이 호환되지 않는 경우, 다운로드 중단으로 불완전한 파일이 남은 경우, 파일명 또는 디렉터리가 클라이언트의 규칙과 다른 경우입니다.

코어를 교체한 뒤에야 오류가 발생하기 시작했다면 클라이언트에 이전 코어의 데이터 옵션이 남아 있지 않은지도 함께 확인해야 합니다. 예를 들어 일부 클라이언트는 MMDB와 다른 Geo 데이터 로드 방식 사이를 전환할 수 있습니다. 코어만 바꾸고 모드를 조정하지 않으면 파일은 존재하지만 읽히지 않는 상황이 발생할 수 있습니다.

3단계: 현재 설정이 실제로 데이터베이스를 참조하는지

실제로 실행 중인 설정에서 GEOIP, GEOSITE 또는 관련 RULE-SET을 검색합니다. 구독 페이지에 표시된 원본 YAML이 코어가 최종적으로 로드한 설정과 항상 같은 것은 아닙니다. 클라이언트가 규칙, 스크립트 또는 로컬 패치를 병합하거나 덮어쓸 수 있기 때문입니다. 클라이언트에서 내보낸 실행 설정을 우선 확인해 규칙 이름, 정책 그룹 이름과 들여쓰기가 올바른지 점검하세요.

GeoSite 분류 이름은 현재 데이터에 존재해야 합니다. 데이터 소스를 업데이트하면 분류가 추가, 분리 또는 변경될 수 있습니다. 설정이 데이터에 없는 태그를 참조하면 코어가 로드 단계에서 바로 오류를 내거나 해당 규칙이 예상대로 작동하지 않을 수 있습니다. 분류 이름은 데이터 소스의 설명과 일치해야 하며, 화면에 표시된 문구만 보고 추측해서는 안 됩니다.

4단계: 규칙이 매칭될 기회가 있었는지

연결 로그 또는 클라이언트의 연결 상세 정보에서 대상 호스트, 규칙 유형, 규칙 페이로드와 최종 정책을 확인합니다. MATCH가 매칭된 것으로 표시된다면 앞선 Geo 규칙이 일치하지 않았거나 아예 실행되지 않았을 가능성이 큽니다. 다른 DOMAIN-SUFFIX, IP-CIDR 또는 RULE-SET이 매칭됐다면 데이터베이스를 계속 교체하기보다 규칙 순서를 조정해야 합니다.

GeoIP를 테스트할 때는 대상 주소도 확인해야 합니다. 하나의 도메인이 여러 IPv4 또는 IPv6 주소를 반환할 수 있고, 지역·네트워크·시간에 따라 결과가 바뀔 수 있습니다. 브라우저의 기존 연결, DNS 캐시와 QUIC 세션 때문에 테스트가 이전 주소를 계속 사용할 수도 있습니다. 설정을 변경한 뒤에는 해당 애플리케이션을 재시작하거나 연결을 정리한 다음 새로 접속해 테스트하세요.

5단계: 매칭 후 정책을 사용할 수 있는지

규칙 매칭은 연결을 어느 정책에 넘길지만 결정합니다. 정책 그룹에서 현재 사용할 수 없는 노드를 선택했거나 지연 시간 테스트가 끝나지 않았거나 직접 연결 네트워크 자체가 대상에 도달하지 못하면 최종 연결은 실패할 수 있습니다. 이 경우에도 로그에는 규칙이 정상적으로 매칭됐다고 표시될 수 있습니다. Geo 데이터 탓으로 돌리기보다 정책 그룹의 현재 선택, 노드 상태, DNS 결과와 시스템 프록시가 가로채는 범위를 계속 확인해야 합니다.

규칙 매칭 기록으로 업데이트 결과 검증

신뢰할 수 있는 검증에는 최소한 설정 로드, 대표 도메인, 대상 IP와 폴백 트래픽 확인이 포함되어야 합니다. 먼저 코어 시작 로그에 Geo 데이터 오류가 없는지 확인한 다음, 대상 분류에 확실히 속하는 도메인으로 GEOSITE 매칭 여부를 확인합니다. 이어서 알려진 IP를 사용해 GEOIP 분류 결과를 확인하고, 마지막으로 앞의 분류에 속하지 않는 연결을 테스트해 예상한 MATCH 또는 다른 폴백 규칙으로 처리되는지 확인하세요.

클라이언트가 규칙 테스트나 연결 상세 정보를 지원한다면 “대상, 매칭 규칙, 정책 그룹, 실제 출구” 네 가지 항목을 기록하세요. 웹페이지가 열리는 것만으로는 트래픽 분기가 올바르다고 증명할 수 없습니다. 직접 연결과 프록시 모두 접속에 성공할 수 있기 때문입니다. 반대로 웹페이지가 열리지 않는다고 해서 규칙 오류라는 뜻도 아닙니다. 정책 노드, DNS, IPv6와 애플리케이션 캐시가 결과에 영향을 줄 수 있습니다.

권장 업데이트 주기

• 일반 개인 기기: 일주일 또는 한 달에 한 번 확인하면 충분하며, 위치 정보가 뚜렷하게 바뀔 때 수동으로 새로고침합니다.
• 설정을 자주 바꾸는 기기: 클라이언트 관리 업데이트를 사용하고, 코어를 업그레이드할 때마다 데이터 로드 로그를 확인합니다.
• 장기간 실행하는 라우터: 안정적인 자동 업데이트 시간을 설정하고 직전의 정상 파일을 보관하며, 업데이트와 기기 재시작이 동시에 진행되지 않도록 합니다.
• 규칙이 고정된 환경: 검증된 데이터 버전을 고정하고 예정된 유지보수 시간에 일괄 업데이트해 분류 변경으로 인한 트래픽 변동을 줄입니다.

업데이트 후 최소 점검 목록

1. 현재 코어가 설정에서 사용하는 Geo 규칙 유형을 지원합니다.
2. 데이터 파일이 실제 실행 인스턴스가 읽는 디렉터리에 있습니다.
3. 시작 로그에 다운로드, 파싱, 권한 또는 분류 이름 오류가 없습니다.
4. 실행 설정에 예상한 GEOIP 및 GEOSITE 규칙이 포함되어 있습니다.
5. 규칙 순서에 모든 트래픽을 먼저 가로채는 지나치게 포괄적인 항목이 없습니다.
6. 연결 상세 정보에 예상한 규칙과 정책이 매칭된 것으로 표시됩니다.
7. 변경 후 연결을 새로 생성해 이전 DNS와 세션 캐시가 판단을 방해하지 않도록 합니다.

GeoIP와 GeoSite 유지관리의 핵심은 가장 짧은 업데이트 주기를 추구하는 것이 아니라 데이터 형식, 코어 기능, 설정 참조와 규칙 순서를 일관되게 유지하는 데 있습니다. 업데이트가 끝난 뒤 “파일 다운로드 완료, 코어 로드 완료, 규칙 참조 확인, 연결 매칭 확인, 정책 실행 가능”의 흐름을 차례대로 점검하면 대부분의 문제를 명확한 단계로 좁힐 수 있습니다.