GeoIP 및 GeoSite 데이터베이스 업데이트 방법: 파일 위치, 로딩 방식과 규칙 참조

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

geosite.dat에는 도메인 집합이 저장됩니다. 하나의 분류에는 전체 도메인, 도메인 접미사, 키워드 또는 정규 표현식이 포함될 수 있으며, 실제 구조는 데이터 생성 규칙에 따라 달라집니다. 예를 들어 geosite:cn은 일반적으로 중국 본토 네트워크 환경을 대상으로 하는 도메인 집합을 매칭하고, geosite:category-ads-all은 광고 도메인 분류를 참조합니다. 이는 요청 대상의 도메인을 처리하는 기능이며, DNS가 반환한 주소의 지역과는 다릅니다.

geoip.dat에는 CIDR 네트워크 대역 집합이 저장됩니다. geoip:cn은 대상 IP를 해당 국가 또는 지역의 네트워크 대역과 비교하고, geoip:private는 루프백, 로컬 네트워크 및 기타 사설 주소 범위를 매칭합니다. 이 데이터는 라우팅 단계에서만 사용되며 DNS 결과를 수정하지 않고, 구독 노드 정보도 대체하지 않습니다.

도메인 규칙에서 IP를 추가로 조회할지는 domainStrategy의 영향을 받습니다. AsIs로 설정하면 라우팅은 주로 연결에 이미 포함된 도메인 또는 IP를 사용합니다. IPIfNonMatch에서는 도메인 규칙이 일치하지 않을 때만 조회를 수행하고 IP 규칙을 시도합니다. IPOnDemand에서는 규칙 평가에 IP가 필요할 가능성만 있어도 코어가 조회를 시작할 수 있습니다. 데이터 파일을 업데이트해도 잘못된 전략 조합은 해결되지 않으므로, 문제를 확인할 때는 파일 버전과 규칙 순서, 도메인 전략을 함께 살펴봐야 합니다.

• 도메인을 알고 있는 경우: 주소 조회 결과만으로 서비스 소속을 추정하지 말고 geosite 분류를 우선 사용합니다.
• IP에 직접 접속하는 경우: geoip, 구체적인 CIDR 또는 기타 IP 조건으로만 매칭할 수 있습니다.
• 하나의 요청이 여러 규칙과 일치하는 경우: 라우팅은 위에서 아래로 평가되며, 일반적으로 완전히 일치한 첫 번째 규칙이 아웃바운드를 결정합니다.
• 분류 이름이 존재하지 않는 경우: 코어는 유사한 분류를 자동으로 사용하지 않고 로그에 리소스 또는 태그 로딩 오류를 기록합니다.

데이터 파일 위치와 코어 로딩 방식

포터블 버전 v2rayN의 프로그램 폴더에는 일반적으로 인터페이스 프로그램, 설정 데이터와 하나 이상의 코어 하위 폴더가 함께 들어 있습니다. v2rayN 7.12.7에서 Xray 코어를 사용하는 경우 흔히 v2rayN\bin\Xray\geoip.dat 및 v2rayN\bin\Xray\geosite.dat에 위치합니다. v2fly 코어를 선택했다면 리소스 파일은 해당 코어가 실제로 읽는 폴더에 있어야 하며, Xray 폴더에 기계적으로 복사해서는 안 됩니다.

설치 방식, 아키텍처 패키지와 버전에 따라 폴더 구조가 달라질 수 있으므로 파일 검색 결과는 단서로만 활용해야 합니다. 더 확실한 방법은 먼저 v2rayN의 「설정」→「매개변수 설정」에서 현재 코어 유형을 확인한 뒤, 코어 로그에서 시작 경로를 확인하는 것입니다. 로그의 실행 파일 폴더와 리소스 로딩 오류를 보면 현재 프로세스가 실제로 어떤 데이터를 사용하는지 알 수 있습니다.

코어는 일반적으로 시작하거나 설정을 다시 로드할 때 지리 데이터를 읽습니다. 사용 중인 파일을 직접 덮어써도 기존 프로세스가 즉시 새 내용을 사용하는 것은 아니며, 경우에 따라 프로세스가 이전 파일 핸들을 계속 보유할 수 있습니다. 업데이트가 끝나면 현재 코어를 중지한 뒤 설정을 다시 시작해야 합니다. 시스템 프록시 스위치만 끄는 것은 보통 코어 재시작과 같지 않으므로, 로그에 새로운 시작 시간과 설정 로딩 기록이 나타나는지를 기준으로 판단해야 합니다.

v2rayN에서 geoip.dat 및 geosite.dat 업데이트

v2rayN의 메뉴 이름은 버전에 따라 바뀔 수 있지만 7.x의 작업 방식은 대체로 같습니다. 클라이언트에서 Geo 데이터를 업데이트하고, 파일을 해당 코어 폴더에 저장한 다음 코어를 재시작합니다. 업데이트 전에 현재 노드가 정상적으로 연결되는지 확인하세요. 데이터 가져오기에 실패한 것은 라우팅 규칙 자체와 무관하므로 규칙을 반복해서 수정해도 해결되지 않습니다.

1. v2rayN을 실행하고 메인 창에서 사용 가능한 설정을 선택했는지 확인한 뒤 현재 코어 유형을 기록합니다.
2. 「설정」→「매개변수 설정」을 열어 로컬 수신 포트와 코어 옵션을 확인합니다. 일반적인 기본값은 SOCKS 10808, HTTP 10809이지만 실제 값은 로컬 화면을 기준으로 합니다.
3. 메인 화면으로 돌아가 「업데이트 확인」 메뉴를 열고 「Geo 파일 업데이트」 또는 현재 버전에서 이와 비슷한 이름의 Geo 데이터 업데이트 항목을 선택합니다.
4. 상태 표시줄이나 로그에 두 데이터 파일 처리가 완료되었다고 표시될 때까지 기다립니다. 둘 중 하나만 완료되었다면 업데이트 성공으로 간주하지 마세요.
5. 「서비스 재시작」을 실행합니다. 해당 항목이 보이지 않으면 서비스를 먼저 중지한 다음 현재 설정을 다시 시작하세요.
6. 코어 로그를 열어 failed to load geoip, failed to load geosite 또는 분류 없음과 같은 오류가 없는지 확인합니다.

업데이트 중 연결 시간 초과가 표시되면 먼저 구독 업데이트와 일반 웹 요청도 실패하는지 확인하세요. 둘 다 실패한다면 현재 노드, 시스템 시간 또는 로컬 프록시 포트 문제를 우선 처리해야 합니다. Geo 데이터 업데이트만 실패한다면 업데이트 기능이 사용하는 네트워크 경로, 대상 폴더의 쓰기 권한, 보안 소프트웨어가 실행 중인 파일을 일시적으로 잠그고 있는지 확인하세요.

v2rayN\
├─ v2rayN.exe
└─ bin\
   └─ Xray\
      ├─ xray.exe
      ├─ geoip.dat
      └─ geosite.dat

파일을 수동으로 교체할 때는 먼저 코어 프로세스를 완전히 종료하고 이전 파일의 사본을 보관한 뒤, 두 파일을 동일한 코어의 리소스 폴더에 넣어야 합니다. 파일 이름만 보고 검색 결과의 첫 번째 파일을 덮어쓰지 마세요. 교체 후 다시 실행해 로그를 확인하고, 시작 즉시 오류가 발생하면 이전 파일을 복원한 다음 새 파일이 현재 코어가 지원하는 데이터 형식과 분류 규칙에 맞는지 확인하세요.

v2rayNG에서 데이터 업데이트 및 재로딩

v2rayNG는 Xray 코어를 사용하며 Geo 데이터는 보통 앱이 내부 리소스 폴더에 저장합니다. 일반 사용자는 안드로이드 파일 시스템에서 실제 경로를 찾을 필요가 없고, 데스크톱 폴더 구조를 모바일 환경에 그대로 적용해서도 안 됩니다. v2rayNG 1.10.x 화면을 기준으로 메인 화면 오른쪽 상단 메뉴에서 「Geo 파일 업데이트」를 찾을 수 있습니다. 정확한 문구는 빌드 버전에 따라 조금 다를 수 있습니다.

1. 먼저 연결 가능한 설정을 하나 선택하고 시작 버튼을 눌러 실시간 테스트에서 지연 시간이 표시되는지 확인합니다.
2. 오른쪽 상단 메뉴를 열고 「Geo 파일 업데이트」를 선택한 뒤, 완료 안내가 표시될 때까지 앱을 전면에 둡니다.
3. 현재 VPN 서비스를 중지한 다음 선택한 설정을 다시 시작하여 Xray가 리소스 파일과 라우팅 설정을 다시 읽도록 합니다.
4. 「설정」→「라우팅 설정」으로 들어가 현재 활성화된 규칙에 geosite 또는 geoip 참조가 실제로 포함되어 있는지 확인합니다.
5. 로그를 열고 직접 연결될 것으로 예상되는 도메인과 프록시를 사용할 것으로 예상되는 도메인에 각각 접속하여 대상, 규칙 및 아웃바운드 태그를 비교합니다.

구독 업데이트와 Geo 데이터 업데이트는 서로 독립된 두 절차입니다. 구독은 서버 주소, 포트, 사용자 식별자, 전송 방식 등의 노드 정보를 담당하고, Geo 업데이트는 라우팅 분류를 담당합니다. 구독을 업데이트했다고 지리 데이터베이스까지 업데이트된 것은 아니며, 지리 데이터베이스를 업데이트해도 VMess 또는 VLESS 노드 매개변수는 바뀌지 않습니다.

모바일 네트워크와 Wi-Fi는 서로 다른 DNS와 IPv6 경로를 사용할 수 있습니다. 테스트할 때는 한 가지 네트워크 환경을 고정하고 업데이트 전후의 로그를 각각 기록하는 것이 좋습니다. Wi-Fi에서는 올바르게 매칭되지만 모바일 네트워크에서 잘못되면 문제는 Geo 파일 자체가 아니라 DNS 응답 차이, IPv6 규칙 누락 또는 프라이빗 DNS 설정 때문일 수 있습니다.

규칙에서 geosite와 geoip를 참조하는 방법

지리 데이터 파일은 라우팅 규칙에서 참조될 때만 매칭에 참여합니다. 아래 구조는 먼저 광고 분류를 차단하고, 사설 주소와 중국 본토 네트워크 대역을 허용한 다음 중국 본토 도메인을 직접 연결합니다. 일치하지 않는 트래픽은 뒤쪽의 프록시 규칙 또는 기본 아웃바운드로 전달됩니다. 실제 설정의 아웃바운드 태그는 클라이언트가 생성한 태그와 일치해야 하며, 예시 이름을 그대로 사용할 수는 없습니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

분류 수보다 규칙 순서가 더 중요합니다. 첫 번째 규칙이 이미 network: tcp,udp로 모든 연결을 매칭해 프록시로 보낸다면 뒤의 중국 본토 직접 연결 규칙에는 매칭 기회가 없습니다. 광고 차단 규칙은 일반 직접 연결 규칙보다 앞에 두고, 사설 네트워크 대역 허용 규칙은 앞쪽에, 최종 프록시 규칙은 마지막에 배치하는 것이 일반적입니다.

geosite:cn과 geoip:cn은 서로 대체할 수 없습니다. 국제 서비스가 중국 본토에 노드를 배치했더라도 도메인 분류는 서비스 특성에 따라 정리되며, 조회된 주소는 geoip:cn에 포함될 수 있습니다. 설정이 IPIfNonMatch를 사용하면 도메인 분류가 먼저 일치한 경우 IP 소속에 의존하지 않습니다. 따라서 규칙의 의도를 명확히 정해야 합니다.

• 로컬 네트워크 장치에 직접 연결해야 한다면 geoip:private를 최종 프록시 규칙보다 앞에 배치합니다.
• 특정 도메인에 분류를 덮어써야 한다면 정확한 도메인 규칙을 포괄적인 geosite 규칙보다 앞에 배치합니다.
• IPv6을 처리해야 한다면 현재 geoip 데이터와 사용자 지정 CIDR 규칙에 해당 주소 체계가 포함되어 있는지 확인합니다.
• 사용자 지정 규칙을 수정한 뒤에는 먼저 코어를 재시작하고 로그로 확인하세요. 웹 페이지가 우연히 열리는지만 보고 판단해서는 안 됩니다.

데이터 만료, 규칙 충돌과 로딩 실패를 구분하는 방법

데이터 만료의 가장 흔한 증상은 새로 추가된 일부 도메인이나 네트워크 대역, 최근 인프라가 변경된 서비스만 비정상적으로 라우팅되고 오래된 규칙 대부분은 정상적으로 작동하는 것입니다. 규칙 충돌은 일관되게 나타납니다. 같은 대상에 접속할 때마다 앞의 포괄적인 규칙에 계속 가로막힙니다. 로딩 실패는 더 명확하며 코어 시작 로그에 파일 누락, 읽기 실패 또는 존재하지 않는 태그 등의 정보가 표시됩니다.

확인할 때는 최소 네 가지 대상을 선택해야 합니다. 로컬 네트워크 주소, 알려진 중국 본토 도메인, 프록시를 사용할 도메인, IP 직접 요청을 각각 테스트하세요. 먼저 브라우저의 연결 재사용 영향을 없앤 다음 새 연결을 하나씩 시작합니다. v2rayN에서는 코어 로그와 로컬 포트 연결을 함께 관찰할 수 있고, v2rayNG에서는 로그 화면에서 대상 주소와 아웃바운드 결과를 확인할 수 있습니다. 한 번의 지연 시간만으로 라우팅 매칭을 증명할 수는 없습니다. 네트워크 혼잡도 응답 시간에 영향을 주기 때문입니다.

1. 현재 코어 유형, 데이터 파일 수정 시간과 라우팅 모드를 기록합니다.
2. 코어를 재시작하고 로그에 Geo 리소스 로딩 오류가 없는지 확인합니다.
3. 127.0.0.1 또는 로컬 네트워크 대상을 테스트하여 사설 주소가 직접 연결되는지 확인합니다.
4. 안정적인 중국 본토 도메인을 테스트하여 직접 연결 아웃바운드와 일치하는지 확인합니다.
5. 프록시로 설정된 도메인을 테스트하여 프록시 아웃바운드로 전달되는지 확인합니다.
6. 임시 정확한 규칙을 가장 앞에 배치해 다시 테스트하고, 결과를 통해 분류 데이터 문제와 규칙 순서 문제를 구분합니다.

정확한 도메인 규칙으로 라우팅이 정상화되지만 해당 geosite 분류가 계속 일치하지 않을 때에만 GeoSite 내용이나 버전을 추가로 확인할 이유가 있습니다. 정확한 규칙도 적용되지 않는다면 클라이언트가 다른 라우팅 모드를 사용하고 있는지, 구독으로 생성된 설정이 사용자 지정 항목을 덮어썼는지, 수정 후 실제로 코어를 재시작했는지를 먼저 확인해야 합니다.

업데이트 주기와 유지 관리 범위

Geo 데이터에는 모든 환경에 맞는 고정 업데이트 주기가 없습니다. 일반적인 사용에서는 한 달에 한 번 확인하는 것만으로도 보통 네트워크 대역과 도메인 변화를 충분히 반영할 수 있습니다. 새로운 서비스의 라우팅 이상, 통신사 주소 변경 또는 분류 누락 로그가 발생하면 즉시 업데이트할 수 있습니다. 자주 업데이트한다고 잘못된 규칙 순서가 해결되거나 노드 회선 품질이 좋아지는 것은 아닙니다.

팀 또는 여러 기기 환경에서는 클라이언트 버전, 코어 유형, 업데이트 시간과 규칙 버전을 기록해야 합니다. 데스크톱과 안드로이드에서 같은 규칙 의도를 사용할 수는 있지만 동일한 실제 파일을 로드한다고 가정해서는 안 됩니다. v2rayN, v2rayNG 및 v2flyNG는 코어, 리소스 폴더와 업데이트 메뉴가 각각 독립적이므로 확인 결과도 따로 보관해야 합니다.

• 업데이트 전에 현재 정상 작동하는 규칙 설정을 보관하여 실패 시 되돌릴 수 있도록 합니다.
• 업데이트 후에는 반드시 코어를 재시작하고 새 시작 로그를 확인합니다.
• GeoSite만 또는 GeoIP만 확인하지 않도록 도메인과 IP를 함께 테스트합니다.
• 구독 변경, DNS 변경과 Geo 데이터 변경을 따로 기록합니다.
• 규칙에 이상이 있으면 먼저 순서와 활성화 상태를 확인한 뒤 데이터 만료 여부를 판단합니다.

안정적인 유지 관리 절차는 파일을 반복해서 교체하는 것이 아니라 코어 경로를 확인하고, 클라이언트 메뉴에서 업데이트한 뒤 프로세스를 다시 로드하고 로그를 확인한 다음, 고정된 테스트 대상으로 검증하는 것입니다. 파일 버전, 로딩 과정과 규칙 매칭을 연결해서 확인해야 라우팅 변화가 데이터베이스, 설정 또는 네트워크 환경 중 어디에서 비롯되었는지 판단할 수 있습니다.