Clash GeoIP·GeoSite 사용법: 데이터베이스 업데이트와 규칙 참조

GeoIP와 GeoSite는 각각 어떤 문제를 해결하나요?

GeoIP와 GeoSite는 모두 설정 파일에서 규칙을 하나씩 관리하는 부담을 줄여 주지만, 연결을 판단하는 기준은 서로 다릅니다. GeoIP는 대상 IP 주소가 속한 국가, 지역 또는 네트워크 집합을 기준으로 매칭하고, GeoSite는 대상 도메인이 속한 웹사이트 분류를 기준으로 매칭합니다. 전자는 IP를, 후자는 도메인을 대상으로 하므로 두 이름을 같은 데이터베이스의 다른 표기라고 이해하면 안 됩니다.

앱이 도메인에 접속하면 Clash 또는 Mihomo는 보통 먼저 연결 메타데이터를 확보한 뒤 규칙 목록을 위에서부터 순서대로 매칭합니다. 규칙에 적절한 도메인 조건이 있으면 GeoSite가 도메인 단계에서 바로 정책을 결정할 수 있습니다. 앞선 도메인 규칙이 일치하지 않으면 코어가 대상 주소를 추가로 해석한 뒤 GeoIP 규칙으로 판단할 수도 있습니다. 실제 동작은 DNS 모드, 스니핑, 규칙 순서, no-resolve 추가 여부의 영향도 받습니다.

GeoIP는 IP에 직접 연결하는 요청을 처리할 수 있고, 도메인 해석 후의 주소까지 포괄할 수 있다는 장점이 있습니다. 하지만 클라우드 서비스와 콘텐츠 전송 네트워크는 하나의 웹사이트를 여러 지역의 노드로 연결할 수 있으며, IP 등록 지역이 실제 서비스 관할 지역과 일치하지 않을 수도 있습니다. 따라서 GeoIP는 라우팅 기준 중 하나로 활용하는 것이 적절하며, 웹사이트의 정체성을 판단하는 유일한 기준으로 삼아서는 안 됩니다.

GeoSite의 분류는 “이 도메인이 어떤 서비스에 속하는가”에 더 가깝습니다. 예를 들어 하나의 집합에 주 도메인, API 도메인, 정적 리소스 도메인과 콘텐츠 전송 도메인이 함께 포함될 수 있습니다. 일반적으로 DOMAIN-SUFFIX 한 줄만 작성하는 것보다 완전하지만, 분류 결과는 해당 데이터베이스 프로젝트의 관리 방식에 따라 달라집니다. 새 도메인이 추가된 뒤에는 데이터베이스를 업데이트하고 클라이언트가 다시 로드해야 규칙에 반영됩니다.

Clash GeoIP·GeoSite 규칙 작성법

규칙은 설정 파일의 rules 섹션에 작성하며, 표시된 순서대로 매칭됩니다. 규칙 하나가 일치하면 연결은 해당 규칙이 지정한 정책 그룹이나 내장 동작으로 전달되고, 뒤의 규칙은 더 이상 처리되지 않습니다. 따라서 구체적인 도메인 분류는 일반적인 지역 IP 규칙보다 앞에 배치하고, 마지막에는 MATCH로 아직 일치하지 않은 트래픽을 처리하는 것이 일반적입니다.

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

첫 번째 항목은 규칙 유형, 두 번째 항목은 데이터베이스의 분류 코드, 세 번째 항목은 정책 이름 또는 동작입니다. 위 예시는 먼저 광고 도메인 분류를 처리하고, 일반적인 중국 본토 도메인은 직접 연결한 다음, 앞에서 일치하지 않은 중국 본토 대상 주소를 GeoIP로 처리합니다. 마지막으로 나머지 연결은 “노드 선택”이라는 정책 그룹으로 보냅니다. 설정의 정책 이름은 대소문자, 공백, 구두점을 포함해 proxy-groups에 정의된 이름과 완전히 같아야 합니다.

no-resolve는 언제 사용해야 하나요?

GeoIP 규칙에는 no-resolve 매개변수를 추가할 수 있습니다. 일반적인 작성 예시는 다음과 같습니다.

rules:
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,노드 선택

no-resolve는 이 규칙을 실행하기 위해 도메인을 IP로 적극적으로 해석하지 말라는 뜻입니다. 현재 연결에 대상 IP가 이미 포함되어 있다면 GeoIP는 계속 매칭할 수 있습니다. 반대로 도메인만 있고 앞선 단계에서 판단에 사용할 주소를 얻지 못했다면 이 규칙은 건너뜁니다. 추가 DNS 조회를 제어하거나 특정 해석 경로를 피할 때 유용하지만, 도메인만 있는 요청에 대한 GeoIP 적용 범위는 줄어들 수 있습니다.

이 매개변수의 추가 여부는 기존 설정만 보고 결정해서는 안 됩니다. Fake-IP, Redir-Host, TUN 모드 또는 도메인 스니핑을 사용할 때 코어가 확보할 수 있는 연결 정보는 서로 완전히 같지 않습니다. 변경 후에는 연결 세부 정보에서 대상 호스트, 규칙 유형과 최종 일치 항목을 확인해 실제 트래픽이 예상대로 라우팅되는지 점검해야 합니다.

데이터베이스 파일, 코어 버전과 호환 범위

코어 분기와 클라이언트에 따라 사용하는 지리 데이터 파일은 완전히 같지 않습니다. 흔히 IP 판단에 사용하는 Country.mmdb와 GeoIP 데이터 파일, 도메인 분류에 사용하는 GeoSite.dat 등이 있습니다. Mihomo는 지리 데이터 로딩 모드, 자동 업데이트 주기와 데이터 주소도 설정할 수 있습니다. 구체적인 파일명, 기본 디렉터리와 사용 가능한 필드는 코어 버전 및 클라이언트 문서를 기준으로 확인해야 합니다.

클래식 Clash 코어, Clash Meta의 후속 분기인 Mihomo, 그리고 Mihomo를 통합한 그래픽 클라이언트는 지원 범위가 서로 다릅니다. 어떤 설정이 GEOIP를 인식한다고 해서 동일한 GEOSITE 분류, 로더 옵션 또는 최신 형식의 데이터베이스까지 지원한다는 뜻은 아닙니다. “지원하지 않는 규칙 유형” 오류가 발생하면 먼저 클라이언트 화면의 이름만 보지 말고 실제로 사용 중인 코어를 확인해야 합니다.

실제 코어와 데이터 디렉터리 확인

1. 클라이언트의 정보, 코어 설정 또는 로그 페이지에서 코어 이름과 버전을 확인합니다.
2. 설치 프로그램이 있는 디렉터리가 아니라 클라이언트 설정 디렉터리를 확인합니다. 포터블 버전과 시스템 설치 버전은 위치가 다를 수 있습니다.
3. 시작 로그에서 GeoIP, GeoSite, mmdb 또는 geodata를 검색해 코어가 최종적으로 어떤 파일을 읽었는지 확인합니다.
4. 클라이언트에 “지리 데이터 업데이트” 기능이 있다면 업데이트 완료 후 파일의 수정 시간과 다음 시작 로그를 기록합니다.

규칙 프로바이더와 지리 데이터베이스를 혼동하지 마세요. rule-providers는 일반적으로 독립된 규칙 집합을 로드한 뒤 RULE-SET으로 참조합니다. 반면 GeoIP와 GeoSite는 코어가 해당 규칙 유형에 따라 지리 데이터를 조회합니다. 둘은 하나의 설정에 함께 사용할 수 있지만 업데이트 경로, 캐시 파일과 오류 메시지는 대체로 다릅니다.

GeoIP·GeoSite 데이터베이스 업데이트 절차

데이터베이스 업데이트는 파일을 아무 디렉터리에나 다운로드하는 것으로 끝나지 않습니다. 코어는 설정에 지정된 위치나 클라이언트가 정한 데이터 디렉터리만 읽으며, 업데이트된 파일도 설정을 다시 로드하거나 코어를 재시작해야 적용됩니다. 그래픽 클라이언트에 내장 업데이트 버튼이 있다면 해당 기능을 우선 사용하세요. 일반적으로 다운로드 위치, 임시 파일 교체와 코어 재로드까지 처리해 줍니다.

클라이언트 내장 업데이트

1. 먼저 현재 설정이 정상적으로 시작되는지 확인하고, 복구할 수 있는 설정을 내보내거나 복사해 둡니다.
2. 코어, 설정 또는 데이터 관리 페이지로 이동해 지리 데이터 업데이트 기능을 찾습니다.
3. GeoIP와 GeoSite 데이터가 각각 완료될 때까지 기다립니다. 기록 중에는 클라이언트를 강제 종료하지 마세요.
4. 설정을 다시 로드하거나 코어를 재시작한 뒤 로그에 데이터베이스 로드 성공 메시지가 나타나는지 확인합니다.
5. 연결 목록에서 확인된 도메인 하나와 특정 지역에 속한 IP 하나를 선택해 어떤 규칙이 일치하는지 확인합니다.

데이터베이스 수동 교체

클라이언트에 업데이트 기능이 없거나 데이터 버전을 고정해야 할 때만 수동 교체를 권장합니다. 작업 전에 코어를 완전히 종료하고 기존 파일명, 디렉터리와 설정 참조를 확인한 뒤 같은 용도의 새 파일로 교체하세요. 확장자만 보고 파일을 서로 바꿀 수 있다고 판단해서는 안 됩니다. MMDB, DAT 및 기타 압축 규칙 형식은 데이터 구성 방식이 서로 다르므로 현재 코어의 로딩 방식과 일치해야 합니다.

클라이언트에서 자동 업데이트를 활성화했다면 업데이트 주기와 데이터 출처 설정도 함께 확인해야 합니다. 자동 업데이트 성공은 파일을 가져와 저장했다는 뜻일 뿐이며, 실제 적용 여부는 이후 로딩 로그를 확인해야 합니다. 장시간 절전 상태, 클라이언트 미실행, 시스템 시간 오류 또는 네트워크 정책에 따른 업데이트 연결 차단으로 예약 작업이 예상대로 실행되지 않을 수 있습니다.

업데이트 주기는 어떻게 정하나요?

지리 데이터는 연결할 때마다 업데이트할 필요가 없습니다. 일반적인 개인 설정에서는 클라이언트 기본 주기로도 충분합니다. 규칙 프로젝트의 변경이 잦거나 최근 분류되지 않는 새 도메인이 발견되었다면 직접 한 번 업데이트할 수 있습니다. 기업 네트워크나 고정된 환경에서는 먼저 새 데이터를 테스트해 분류 변경으로 많은 연결의 정책이 바뀌지 않는지 확인하는 편이 좋습니다.

데이터베이스 버전과 설정 규칙은 하나의 변경 기록으로 관리해야 합니다. 업데이트 후 라우팅 결과가 달라졌다면 최소한 업데이트 날짜, 코어 버전, 설정 버전과 일치한 분류 코드를 기록해야 데이터 내용, 규칙 순서와 코어 동작 중 어디에서 문제가 발생했는지 판단할 수 있습니다.

로딩 실패와 규칙 미일치 점검 순서

GeoIP 또는 GeoSite 문제는 대체로 세 가지 형태로 나타납니다. 설정이 시작되지 않거나, 데이터베이스 로드 오류가 발생하거나, 설정은 실행되지만 연결이 예상한 규칙과 일치하지 않는 경우입니다. 세 문제는 점검할 부분이 다르므로 먼저 로그로 유형을 확인한 뒤 설정을 수정해야 합니다.

1. 데이터베이스 파일을 찾을 수 없다는 메시지가 표시되는 경우

먼저 로그에 표시된 전체 경로를 확인하고, 코어를 실행하는 계정에 해당 디렉터리의 읽기 권한이 있는지 점검합니다. 여러 클라이언트를 함께 사용하면 파일을 다른 클라이언트의 설정 디렉터리에 넣기 쉽습니다. 파일명의 대소문자도 확인해야 합니다. 대소문자를 구분하는 파일 시스템에서는 GeoSite.dat와 geosite.dat를 서로 다른 파일로 인식할 수 있습니다.

2. 형식이 잘못되었거나 로드에 실패했다는 메시지가 표시되는 경우

이는 대개 데이터 파일과 로더가 맞지 않거나, 파일 다운로드가 완전하지 않거나, 코어 버전이 해당 형식을 인식하지 못한다는 뜻입니다. 기존 파일을 복원했을 때 정상적으로 시작된다면 새 파일의 출처 유형과 대상 코어의 요구 사항을 추가로 확인할 수 있습니다. 규칙 이름을 반복해서 바꾸는 방법으로 하위 파일 형식 오류를 해결하려 해서는 안 됩니다. 규칙 매칭 단계에 아직 진입하지 않았기 때문입니다.

3. GeoSite 분류가 일치하지 않는 경우

• 로그에 알 수 없는 규칙 유형이나 분류 코드가 표시되지 않았는지 확인합니다.
• 해당 도메인이 현재 데이터베이스 버전의 대상 분류에 실제로 포함되어 있는지 확인합니다.
• 앞에 있는 DOMAIN, DOMAIN-SUFFIX, RULE-SET 또는 다른 GeoSite 규칙이 먼저 일치하지 않았는지 확인합니다.
• 연결 세부 정보에 대상 도메인이 남아 있는지 확인합니다. IP 정보만 있다면 도메인 분류를 판단할 수 없습니다.
• 화면에는 YAML이 저장된 것으로 보이더라도 실행 중인 코어가 이전 설정을 사용하고 있을 수 있으므로 설정을 다시 로드합니다.

4. GeoIP 지역 판단이 예상과 다른 경우

먼저 연결 세부 정보에 표시된 것이 최종 대상 IP인지 확인합니다. 로컬 Fake-IP, 프록시 노드 주소 또는 DNS 서버 주소일 수 있습니다. 콘텐츠 전송 네트워크는 같은 서비스를 여러 지역으로 연결할 수 있고, 데이터베이스의 네트워크 귀속 지역이 실제 데이터센터 위치와 다를 수도 있습니다. 특정 서비스가 반드시 특정 정책을 사용해야 한다면 명확한 도메인 규칙이나 관리 범위가 분명한 규칙 집합을 우선 사용하고, GeoIP는 후속 대체 규칙으로 활용하는 것이 좋습니다.

5. TUN 모드에서 결과가 달라지는 경우

TUN 모드는 시스템 프록시 설정을 따르지 않는 더 많은 트래픽을 가로챌 수 있으므로 연결 수, 프로토콜 유형과 확인 가능한 대상이 달라집니다. TUN을 활성화한 뒤 일치 결과가 달라졌다고 해서 반드시 데이터베이스가 손상된 것은 아닙니다. DNS 하이재킹, Fake-IP 범위, 도메인 스니핑과 라우팅 제외 항목을 함께 확인해야 합니다. 같은 대상에 대해 일반 시스템 프록시와 TUN 모드의 연결 세부 정보를 각각 기록한 뒤 대상 도메인, 대상 IP와 일치 규칙을 비교하세요.

업데이트 후 검증 방법

검증은 클라이언트에 “업데이트 완료”가 표시되는지만 확인해서는 부족합니다. 전체 점검은 파일 로드, 규칙 파싱과 실제 연결 일치의 세 단계로 진행해야 합니다. 첫째, 시작 로그에서 현재 코어가 데이터베이스를 읽었는지 확인합니다. 둘째, 설정 파싱 결과를 확인해 GeoIP, GeoSite 분류와 정책 그룹 이름이 유효한지 점검합니다. 셋째, 테스트 트래픽을 발생시키고 연결 목록에서 최종 규칙과 정책을 확인합니다.

비교 테스트에는 몇 가지 유형의 대상을 선택하는 것이 좋습니다. 명확한 GeoSite 분류로 처리되어야 하는 도메인 하나, IP에 직접 접속하는 연결 하나, 특정 분류와 일치하지 않아야 하는 일반 도메인 하나를 준비합니다. 테스트 중에는 브라우저 자체의 프록시 확장 기능과 보안 DNS를 잠시 끄고, 결과에 영향을 주는 추가 경로를 줄이세요. 터미널에서 테스트할 때는 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY가 설정되어 있는지도 확인해야 합니다. 이러한 변수는 요청이 Clash로 들어오는 방식을 바꿀 수 있습니다.

규칙 결과가 예상과 다르면 설정 사본에서 테스트할 규칙을 잠시 더 앞쪽으로 이동해 볼 수 있습니다. 이동 후 일치한다면 문제는 대개 순서나 우선 적용 관계에 있습니다. 그래도 일치하지 않으면 분류 내용, 대상 정보와 데이터베이스 로딩 상태를 확인하세요. 원인을 파악한 뒤에는 합리적인 순서로 되돌려 특정 도메인 하나 때문에 범위가 넓은 규칙이 계속 최우선으로 남지 않게 해야 합니다.

GeoIP와 GeoSite를 안정적으로 사용하려면 네 가지 조건이 필요합니다. 코어가 해당 규칙 유형을 지원하고, 데이터베이스 형식과 로딩 방식이 일치하며, 규칙 순서가 라우팅 목적에 맞고, 업데이트된 데이터를 실행 중인 코어가 다시 로드해야 합니다. 이 네 단계에 따라 하나씩 확인하는 편이 데이터베이스를 계속 바꾸거나 설정 전체를 복사하는 것보다 원인을 찾기 쉽습니다.