GeoIP·GeoSite 데이터베이스 업데이트 가이드: GEOSITE 규칙이 적용되지 않을 때 확인할 사항

1. GeoSite·GeoIP와 구독 업데이트의 차이

FlClash는 mihomo 코어로 규칙을 처리합니다. 구독에는 설정, 아웃바운드, 정책 그룹이 포함되고, GeoSite와 GeoIP는 규칙에서 참조하는 분류 데이터를 제공합니다. 각각 업데이트하는 내용이 다릅니다. 구독 새로고침에 성공해도 로컬 데이터베이스가 업데이트된 것은 아니며, 데이터베이스 다운로드에 성공해도 현재 연결에 해당 규칙이 반드시 적용되는 것은 아닙니다.

항목	매칭 기준	관련 파일 또는 설정 위치
GeoSite	도메인 목록 기준 분류(예: cn)	`GeoSite.dat` — 출처는 `geox-url.geosite`에서 지정
GeoIP DAT	IP 주소의 소속 분류 기준 매칭	`GeoIP.dat` — 출처는 `geox-url.geoip`에서 지정
GeoIP MMDB	기존 IP 위치 데이터베이스 기준 매칭	`Country.mmdb` — 출처는 `geox-url.mmdb`에서 지정
구독 설정	아웃바운드, 정책 그룹, 규칙 및 기타 설정 항목	FlClash의 설정 목록 및 구독 업데이트 메뉴

GEOSITE,cn,DIRECT는 도메인 목록을 기준으로 판단하며, 서버가 중국 본토에 있는지를 조회하는 규칙이 아닙니다. GEOIP,CN,DIRECT는 대상 IP를 기준으로 판단하며, 웹사이트 운영 회사의 국적을 판별하는 규칙도 아닙니다. 같은 서비스라도 도메인이나 CDN 주소가 다르면 두 조건의 결과가 달라질 수 있습니다.

2. GEOSITE 규칙이 적용되지 않을 때: 먼저 설정이 정상적으로 로드됐는지 확인

먼저 FlClash의 설정 목록에서 대상 설정이 현재 사용 중인지 확인한 다음 실행 로그를 살펴보세요. 버전에 따라 메뉴 이름이 ‘설정’, ‘로그’ 또는 해당 아이콘으로 표시될 수 있습니다. 이 문서는 특정 버전의 고정된 메뉴 구성을 전제로 하지 않습니다. 업데이트 버튼을 계속 누르는 것보다 로그에 기록된 오류 원문을 확인하는 편이 도움이 됩니다.

증상에 따라 다음 단계를 선택하세요

설정을 활성화할 수 없음: YAML 들여쓰기, 존재하지 않는 정책 그룹, 데이터베이스 누락, 카테고리 미존재 등 로드 오류부터 해결하세요. 이 단계에서는 아직 정상적으로 규칙을 확인할 수 없습니다.
설정은 정상적으로 활성화되지만 웹사이트의 아웃바운드가 잘못됨: 먼저 규칙 모드를 사용 중인지 확인하고, 해당 연결에 실제로 적용된 규칙을 살펴보세요. 전역 모드와 직접 연결 모드에서는 rules 전체가 예상대로 적용되지 않습니다.
일부 도메인만 잘못 연결됨: 해당 도메인이 데이터베이스에 포함되어 있는지, 앞쪽 규칙이 먼저 적용되는지 확인하세요. 클라이언트를 바로 재설치할 필요는 없습니다.
업데이트 중 시간 초과 또는 인증서 오류가 발생함: 다운로드 도메인 연결 상태, 시스템 날짜와 시간, 업데이트 요청에 아직 준비되지 않은 프록시가 필요한지 확인하세요.

다음 세 가지 정보를 기록해 두는 것이 좋습니다. 현재 설정 이름, 아웃바운드 모드, 오류 로그의 전체 행입니다. 로그에 구독 주소, 액세스 토큰 또는 노드 인증 정보가 포함된 경우 공유하기 전에 가리세요. ‘업데이트 실패’라는 네 글자만으로는 원격 서버 응답 오류인지 로컬 파싱 실패인지 판단하기 어렵습니다.

3. FlClash에서 데이터베이스 수동 업데이트

수동 업데이트는 최초 로드에 실패했거나, 데이터베이스를 오랫동안 갱신하지 않았거나, 데이터 출처를 방금 변경한 경우에 적합합니다. 먼저 현재 클라이언트 버전에서 리소스 업데이트를 지원하는지 확인하세요. 설정 화면에서 Geo 데이터, 지리 데이터 또는 리소스 업데이트 관련 항목을 찾고 ‘Geo 데이터 업데이트’와 ‘구독 업데이트’를 구분해야 합니다. 버전에 따라 여러 리소스가 하나의 업데이트 작업으로 묶여 있거나 별도의 업데이트 버튼이 제공되지 않을 수 있습니다.

설정을 백업하세요. 현재 사용할 수 있는 설정과 기존 오버라이드를 저장하세요. 구독 주소만 보관하지 마세요. 로컬에서 추가한 규칙은 원격 구독에 포함되지 않을 수 있습니다.
리소스 주소를 확인하세요. 사용자 지정 Geo 데이터 주소를 입력했다면, 해당 주소가 안내 페이지나 로그인 페이지가 아니라 올바른 바이너리 데이터 파일을 반환하는지 확인하세요.
리소스를 업데이트하세요. 화면에 Geo 데이터 업데이트 버튼이 있다면 한 번 실행하고 완료될 때까지 기다리세요. 어떤 작업이 어떤 로그에 해당하는지 파악하기 어려워지지 않도록 업데이트를 연달아 여러 번 실행하지 마세요.
설정을 다시 로드하세요. 업데이트가 끝나면 현재 설정을 다시 로드하세요. 필요하다면 코어를 중지한 뒤 다시 시작해 실행 중인 규칙이 데이터베이스를 새로 읽도록 하세요.
새 연결로 확인하세요. 테스트 페이지의 기존 연결을 닫은 뒤 다시 접속하고, 연결 기록에서 적용된 규칙과 최종 아웃바운드를 확인하세요. 기존 연결에 계속 표시되는 결과만 확인해서는 안 됩니다.

다운로드에 성공했는데도 문제가 계속되면 업데이트 전후의 로그를 먼저 비교하세요. 오류가 ‘다운로드할 수 없음’에서 ‘카테고리를 찾을 수 없음’으로 바뀌었다면 네트워크 문제는 해결됐을 가능성이 있습니다. 다음으로는 프록시 포트를 계속 바꾸기보다 데이터 출처에 어떤 카테고리가 포함되어 있는지 확인하세요.

4. geox-url 설정 및 24시간마다 자동 업데이트

다음은 MetaCubeX의 공개 데이터 배포 주소를 사용하는 mihomo Geo 데이터 설정 예시입니다. 완전한 구독 설정이 아니며 프록시 아웃바운드는 포함하지 않습니다. 병합하기 전에 기존 설정에 같은 이름의 키가 있는지 확인하세요. 이 옵션은 YAML 최상위에 두어야 하며 dns:, rules: 또는 정책 그룹 아래에 들여쓰기해서 넣으면 안 됩니다.

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

geo-auto-update: true: mihomo의 Geo 데이터 자동 업데이트를 활성화합니다.
geo-update-interval: 24: 업데이트 간격의 단위는 시간입니다. 24는 하루를 뜻하며 24분이 아닙니다.
geox-url.geoip: DAT 모드에서 사용할 GeoIP 데이터 출처를 지정합니다.
geox-url.geosite: GEOSITE 규칙에서 사용할 도메인 분류 데이터 출처를 지정합니다.
geox-url.mmdb: MMDB 모드에 해당하는 데이터 출처를 지정합니다. 현재 예시는 DAT 모드를 활성화하므로 모든 GEOIP 규칙이 두 형식의 파일을 동시에 읽는다는 뜻은 아닙니다.

FlClash는 화면 설정을 바탕으로 최종 실행 설정을 생성할 수 있습니다. 따라서 구독 원문을 편집한 뒤에도 해당 필드가 실제 실행 설정에 반영됐는지 확인해야 합니다. 다음 구독 새로고침 때 수정 내용이 덮어써지지 않도록 현재 버전에서 제공하는 오버라이드나 설정 병합 기능을 우선 사용하세요. 화면에서 실행 설정을 확인할 수 없다면 시작 로그와 업데이트 로그를 함께 살펴 옵션이 적용됐는지 확인하세요.

자동 업데이트에는 클라이언트와 코어가 실행 중이어야 하고, 데이터 다운로드 출처에도 접속할 수 있어야 합니다. 컴퓨터가 꺼져 있거나 Android의 백그라운드 프로세스가 시스템에 의해 종료된 경우를 시스템 수준의 예약 작업으로 이해해서는 안 됩니다. 다시 시작한 뒤에는 업데이트 기록을 확인하세요. 설정에 24라고 적혀 있다는 이유만으로 데이터가 반드시 당일 버전이라고 단정할 수 없습니다.

5. 카테고리 누락: 파일 다운로드와 규칙 사용은 별개입니다

데이터 세트에 따라 관리 주체와 카테고리 이름, 수록 범위가 다를 수 있습니다. 특정 데이터 출처에만 있는 카테고리를 참조하는 설정에서 다른 데이터베이스로 바꾸면 카테고리를 찾을 수 없다는 오류가 발생할 수 있습니다. 최신 파일을 받아도 해당 출처에 현재 포함된 데이터만 얻을 수 있으며, 다른 출처의 모든 카테고리가 자동으로 추가되지는 않습니다.

데이터 출처·카테고리·규칙이 서로 일치하는지 확인하세요

로그에서 오류가 난 카테고리 이름을 복사하고 @ 등의 속성 필터 부분도 남겨 두세요. 앞부분만 기억해서는 안 됩니다.
현재 데이터 출처 프로젝트의 카테고리 목록이나 설명에서 해당 카테고리가 실제로 있는지 확인하세요. 웹페이지에 표시된 이름을 규칙 식별자로 그대로 사용하지 마세요.
구독에서 원래 요구한 데이터 출처를 확인하세요. 구독이 특정 데이터 세트에 의존한다면 용량이 더 작은 축약판으로 임의 교체하지 말고 호환되는 데이터를 사용하세요.
상위 데이터에서 해당 카테고리가 삭제되거나 이름이 바뀌었다면 관련 규칙을 수정하세요. 특정 도메인만 누락된 경우에는 범위를 명확히 지정한 도메인 규칙을 추가할 수 있습니다.

규칙을 임시로 추가할 때는 전체 도메인을 지정하는 것이 좋습니다. 예를 들어 아래 규칙은 www.example.com에만 적용되므로 정확한 매칭을 설명하는 데 사용할 수 있습니다. 실제로 사용할 때는 직접 연결이 필요한 것으로 확인된 도메인을 입력하고, 먼저 적용될 수 있는 범위가 넓은 규칙보다 앞에 배치하세요.

rules:
  - DOMAIN,www.example.com,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 프록시

여기서 해외 프록시는 현재 설정에 이미 존재하는 정책 그룹 이름이어야 합니다. 정책 그룹 이름이 다르다면 실제 이름으로 바꾸세요. 예시 전체로 구독의 rules를 덮어쓰면 기존 앱별 라우팅과 예외 규칙이 사라지므로 그대로 교체하지 마세요.

6. 데이터베이스 업데이트 후에도 규칙이 잘못 적용될 때 확인할 순서

먼저 규칙 적용 순서를 확인한 뒤 DNS와 대상 주소를 살펴보세요

mihomo는 rules를 위에서부터 순서대로 확인하며, 먼저 일치하는 규칙이 이후 처리를 결정합니다. 목록 위쪽에 적용 범위가 더 넓은 도메인 규칙이 있으면 아래쪽의 GEOSITE 규칙은 매칭 기회를 얻지 못합니다. MATCH는 일반적으로 마지막에 두는 기본 규칙입니다. 앞쪽에 배치하면 뒤의 카테고리 규칙이 가려집니다.

위 예시의 no-resolve는 이 GEOIP 규칙이 매칭을 위해 도메인 조회를 직접 시작하지 않도록 합니다. 이때 연결에 도메인만 있고 사용할 수 있는 대상 IP가 없다면 해당 IP 조건을 건너뛰고 다음 규칙을 확인할 수 있습니다. 이는 규칙 옵션의 동작이며 데이터베이스 업데이트 실패가 아닙니다. 문제를 확인할 때는 연결 기록의 도메인, 대상 IP, 적용 규칙을 함께 살펴보세요.

연결 기록에 표시된 현상	우선 확인할 사항	대응 방법
앞쪽의 DOMAIN-SUFFIX 규칙이 적용됨	규칙 순서와 도메인 범위	필요한 정확한 예외 규칙을 앞에 배치하고 직접 연결 범위는 넓히지 마세요
MATCH 규칙이 적용됨	도메인이 데이터에 포함되어 있는지, 대상 IP를 사용할 수 있는지	카테고리 내용과 no-resolve의 영향 확인
해당 앱의 연결이 보이지 않음	앱 트래픽이 클라이언트를 통과하는지	시스템 프록시, 앱 프록시 또는 TUN의 처리 범위 확인
규칙은 맞지만 최종 아웃바운드가 예상과 다름	현재 선택된 정책 그룹	그룹에서 DIRECT 또는 다른 아웃바운드가 선택됐는지 확인

TUN 모드는 트래픽이 코어로 들어오는 방식을 처리할 뿐, GeoSite에 카테고리를 추가하지 않습니다. 시스템 프록시는 해당 프록시를 따르는 앱에만 적용됩니다. 앱이 시스템 프록시를 우회한다면 데이터베이스를 반복해서 업데이트해도 아웃바운드는 달라지지 않습니다. 먼저 연결 화면에서 요청이 실제로 FlClash에 전달되는지 확인한 뒤 규칙 적용 여부를 살펴보세요.

DNS 캐시와 브라우저의 연결 재사용도 재테스트 결과에 영향을 줄 수 있습니다. 규칙을 수정하거나 새 데이터를 불러온 뒤에는 새 연결을 만드세요. DNS 또는 Fake-IP 설정도 함께 바꿨다면 현재 버전에서 지원하는 방법으로 관련 캐시를 비우세요. 카테고리 업데이트를 한 번 시험해 보려고 모든 앱 데이터를 함부로 삭제하지 마세요.

7. 업데이트 실패, 롤백 및 일상적인 관리

다운로드 오류는 유형별로 해결하세요

HTTP 404: 파일 이름, 배포 경로, 대소문자를 확인하세요. 배포 페이지 주소와 데이터 파일 주소는 다릅니다.
시간 초과 또는 연결 중단: 다운로드 도메인과 리디렉션 대상에 네트워크로 접속할 수 있는지 확인하세요. 브라우저에서 프로젝트 홈을 열 수 있다고 해서 데이터 파일을 끝까지 다운로드할 수 있는 것은 아닙니다.
인증서 검증 오류: 먼저 시스템 시간을 동기화하고 네트워크 인증 페이지나 로컬 HTTPS 검사 환경을 확인하세요. 보안 검증을 바로 비활성화하지 마세요.
다운로드 후 파싱 실패: 파일 형식 불일치, HTML로 바뀐 응답 내용, 다운로드 중단, 데이터 파일과 코어의 호환성 문제 등을 확인하세요.

‘코어를 시작하려면 데이터를 먼저 다운로드해야 하지만, 다운로드에는 코어의 프록시가 필요한’ 순환 문제가 발생하면 우선 사용할 수 있는 네트워크로 호환되는 데이터를 받거나 직접 연결할 수 있는 데이터 출처를 선택하세요. 접속할 수 없는 주소를 여러 필드에 반복해서 입력하지 말고, 공개 구독 주소를 정체를 알 수 없는 온라인 변환 서비스에 전달하지 마세요.

업데이트 후 설정을 불러올 수 없다면 이전에 정상 작동하던 데이터 파일이나 출처로 되돌리고 관련 설정 옵션도 복원하세요. 작업 전에 코어를 중지하고, 복원한 뒤 설정을 다시 로드하세요. 비교할 수 있도록 오류 로그도 보관하세요. 데이터 출처를 바꿨다면 카테고리 이름도 다시 확인해야 합니다. 파일만 되돌리고 다른 데이터 세트에 맞춘 규칙을 그대로 남겨서는 안 됩니다.

업데이트 후 확인 목록

설정이 정상적으로 활성화되고 로그에 Geo 데이터 다운로드 또는 카테고리 로드 오류가 없어야 합니다.
자동 업데이트 옵션이 실제 실행 설정에 반영되고 업데이트 간격이 시간 단위로 입력되어야 합니다.
직접 연결되어야 하는 도메인과 프록시를 거쳐야 하는 도메인을 각각 하나 이상 테스트하고 적용된 규칙을 확인하세요.
새 연결로 다시 테스트하고 정책 그룹의 최종 아웃바운드가 예상과 일치하는지 확인하세요.
다음에 문제가 생겼을 때 되돌리고 비교할 수 있도록 정상 작동하는 설정과 데이터 출처를 저장해 두세요.

규칙, 데이터 출처, 실행 설정을 일관되게 유지하는 것이 중요합니다. 다운로드, 로드, 매칭 중 어느 단계에서 문제가 발생했는지 먼저 확인하고 그에 맞게 조치하면 DNS, TUN, 전체 규칙을 한꺼번에 바꾸는 것보다 결과를 검증하기 쉽습니다.