GeoIP 및 GeoSite 데이터베이스 업데이트 가이드: 트래픽 분류가 오작동할 때 먼저 확인할 두 파일

노드 연결은 정상인데 원래 직접 연결되어야 할 웹사이트가 갑자기 프록시를 거치거나, 특정 도메인이 예상한 규칙에 매칭되지 않는다면 원인이 구독, VMess, VLESS 또는 노드 자체에 있지 않을 수 있습니다. 라우팅 규칙에서 geoip: 또는 geosite:를 참조한다면 실제 매칭 결과는 로컬에서 불러온 데이터 파일에 따라 결정됩니다.

이 글 한눈에 보기

이 글은 v2rayN, v2rayNG 또는 v2flyNG를 사용하면서 도메인 및 IP 트래픽 분류 규칙을 활성화한 사용자에게 적합합니다. 두 데이터베이스의 역할을 구분하고, 클라이언트에서 업데이트하거나 수동으로 교체한 뒤 로그, 규칙 순서와 테스트 도메인을 통해 현재 코어가 새 데이터를 불러왔는지 확인하는 방법을 다룹니다.

먼저 geoip.dat와 geosite.dat의 매칭 대상을 구분하세요

geosite.dat에는 도메인 분류 목록이 저장됩니다. 규칙의 geosite:cn, geosite:category-ads-all 같은 표현은 네트워크에 실시간 서비스를 조회하는 방식이 아니라 코어가 로컬 파일의 분류 항목을 읽도록 지정하는 것입니다. 도메인이 추가되거나 이전·용도 변경된 뒤에도 로컬 데이터가 오랫동안 업데이트되지 않았다면 이전 분류에 계속 포함될 수 있습니다.

geoip.dat에는 IP 주소 대역 분류 정보가 저장됩니다. 규칙의 geoip:cn은 대상 IP를 데이터베이스의 주소 범위와 비교합니다. 웹사이트의 해석 주소가 바뀌거나 클라우드 서비스가 주소 대역을 재할당했거나 새 대역이 오래된 데이터베이스에 아직 반영되지 않았다면 IP 규칙이 매칭되지 않을 수 있습니다.

애플리케이션이 요청 시작 대상 정보 확인 도메인 규칙 매칭 IP 규칙 매칭 아웃바운드 선택

GeoSite 도메인 분류

파일: geosite.dat
매칭 대상: 전체 도메인 및 도메인 목록
대표적인 표기: geosite:cn
주요 용도: 도메인 직접 연결 및 분류 차단

도메인이 여전히 확인되는 경우 보통 먼저 GeoSite 규칙이 판단에 참여합니다.

GeoIP 주소 분류

파일: geoip.dat
매칭 대상: IPv4 및 IPv6 주소 대역
대표적인 표기: geoip:cn
주요 용도: 대상 주소 직접 연결 또는 프록시

IP 규칙의 적용 여부는 domainStrategy 설정의 영향도 받습니다.

트래픽 분류 이상이 오래된 데이터베이스 때문인지 판단하기

한 번 트래픽이 잘못 분류되었다고 곧바로 파일을 교체하지 마세요. 먼저 코어가 정상적으로 실행 중인지 확인한 다음 규칙 순서, DNS 결과와 아웃바운드 태그 오류를 배제해야 합니다. 라우팅 시스템은 일반적으로 규칙 순서대로 매칭하므로 앞의 포괄적인 규칙이 트래픽을 먼저 처리하면 뒤의 geosite:cn 또는 geoip:cn에는 실행 기회가 없을 수 있습니다.

2개

핵심 데이터 파일

10808

일반적인 SOCKS 수신 포트

10809

일반적인 HTTP 수신 포트

3회

업데이트 전후 확인 횟수

10808과 10809는 v2rayN에서 자주 사용되는 기본값일 뿐 모든 설치 환경에 고정된 값은 아닙니다. 실제 포트는 「설정」→「매개변수 설정」에서 확인해야 하며, 브라우저 프록시를 테스트할 때는 현재 로컬 인바운드와 포트가 일치해야 합니다. 포트를 잘못 입력하면 전혀 접속되지 않으며, 이는 Geo 데이터 오판이 아닙니다.

노드 확인: 사용 가능한 노드 두 개로 각각 테스트해 보세요. 모든 노드가 연결되는데 같은 도메인들이 계속 잘못된 아웃바운드로 전송된다면 라우팅 데이터나 규칙 설정을 의심해야 합니다.
규칙 순서 확인: 정확한 도메인, GeoSite, GeoIP와 최종 대체 규칙을 위에서부터 차례로 점검하세요. 최종 대체 규칙은 분류 규칙보다 뒤에 있어야 합니다.
로그 확인: v2rayN에서 실행 로그를 열고 테스트 도메인에 다시 접속해 매칭된 outboundTag를 확인하세요. 로그 수준이 너무 낮다면 「설정」→「매개변수 설정」에서 임시로 조정한 뒤 코어를 재시작할 수 있습니다.
파일 날짜 확인: 현재 코어가 실제로 사용하는 리소스 디렉터리를 찾아 geoip.dat와 geosite.dat의 수정 시간을 확인하세요. 다운로드 폴더에 있는 복사본만 확인해서는 안 됩니다.
비교 기준 마련: 업데이트 전에 최소 세 개의 테스트 대상을 기록하세요. 직접 연결되어야 하는 도메인, 프록시를 사용해야 하는 도메인, IP를 직접 사용하는 요청을 각각 하나씩 포함합니다.

결론: 먼저 규칙이 실행되었는지 확인한 뒤 데이터베이스가 오래되었는지 판단하세요

로그에서 Geo 규칙보다 앞선 포괄 규칙에 트래픽이 먼저 매칭된 것으로 나타난다면 파일을 업데이트해도 결과는 바뀌지 않습니다. 규칙 순서가 올바르고 대상이 여전히 분류되지 않을 때만 데이터베이스 업데이트가 효과적인 조치입니다.

v2rayN에서 GeoIP 및 GeoSite 업데이트하기

최신 v2rayN은 보통 상단 메뉴에 Geo 파일 업데이트 항목을 제공합니다. 먼저 업데이트 소스에 안정적으로 접속할 수 있는 노드에 연결한 뒤 「업데이트 확인」→「Geo files」를 선택하세요. 일부 버전에서는 GeoIP/GeoSite 업데이트로 표시되는 등 이름이 조금 다를 수 있지만, 업데이트 대상은 현재 코어 디렉터리의 두 데이터 파일입니다.

업데이트 중에는 클라이언트를 종료하거나 같은 이름의 파일을 수동으로 덮어쓰지 마세요. 메뉴에서 완료되었다는 안내가 표시되면 「서비스 재시작」을 실행하거나 v2rayN을 종료한 뒤 다시 시작해야 합니다. 그래야 Xray 또는 V2Ray 코어가 기존 파일을 해제하고 새로 불러옵니다. 기본 창만 닫고 클라이언트를 계속 실행하면 전체 다시 불러오기가 수행되지 않을 수 있습니다.

클라이언트에서 업데이트

사전 조건: 사용 가능한 노드 1개 이상
메뉴 경로: 업데이트 확인 → Geo files
업데이트 대상: geoip.dat、geosite.dat
완료 후 작업: 현재 코어 재시작

가능하면 클라이언트 메뉴를 이용하세요. 잘못된 디렉터리에 파일을 덮어쓸 가능성을 줄일 수 있습니다.

수동 교체

1단계: 클라이언트 완전히 종료
2단계: 기존 두 파일 백업
3단계: 코어 리소스 디렉터리에 덮어쓰기
4단계: 실행 후 로그 확인

파일 이름은 그대로 유지해야 하며 두 파일은 같은 업데이트 버전에서 가져온 것이어야 합니다.

클라이언트에서 업데이트할 수 없다면 수동으로 교체할 수 있습니다. 핵심은 파일을 v2rayN 루트 디렉터리에 넣는 것이 아니라 현재 선택한 코어의 리소스 디렉터리를 찾는 것입니다. v2rayN 버전과 데스크톱판·WPF판에 따라 디렉터리 구성은 다를 수 있으며, 일반적인 설치 환경에서는 코어 이름별로 나뉜 bin 하위 디렉터리를 볼 수 있습니다. 가장 확실한 방법은 실행 로그에서 코어 실행 파일 경로를 확인한 다음 인접한 리소스 디렉터리에서 같은 이름의 기존 파일 두 개를 찾는 것입니다.

Android용 v2rayNG는 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용합니다. 현재 버전의 메뉴에 「Geo 파일 업데이트」가 있다면 네트워크가 연결된 상태에서 실행한 뒤 코어를 재시작하세요. 해당 항목이 없다면 클라이언트 버전에 맞는 리소스를 함께 업데이트해야 합니다. 라우팅 테스트를 할 때는 「설정」→「라우팅 설정」에서 현재 활성화된 규칙 집합을 확인해야 하며, 구독이 새로 고쳐졌는지만 확인해서는 안 됩니다.

routing 작성 방식과 domainStrategy 확인

데이터베이스를 업데이트했는데 결과가 바뀌지 않는다면 다음으로 설정 참조가 올바른지 확인해야 합니다. GeoSite 항목은 규칙의 domain 배열에, GeoIP 항목은 ip 배열에 넣어야 하며 서로 바꿔 사용할 수 없습니다. 또한 규칙은 실제로 존재하는 outboundTag를 가리켜야 합니다. 그렇지 않으면 코어에서 오류가 발생하거나 예상대로 아웃바운드를 선택하지 못합니다.

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

위 순서는 먼저 도메인을 확인하고, 다음으로 IP를 확인한 뒤 나머지 TCP와 UDP 트래픽을 proxy로 보냅니다. 이때 direct와 proxy는 outbounds의 tag와 대소문자까지 완전히 일치해야 합니다. 설정에서 실제 이름이 direct-out이라면 라우팅에도 같은 이름을 사용해야 합니다.

AsIs: 요청에 포함된 원래 도메인을 우선 매칭하며 IP 규칙을 위해 도메인을 능동적으로 해석하지 않습니다. 대상이 도메인 형식으로 전달되면 이후 GeoIP 규칙이 적용되지 않을 수 있습니다.
IPIfNonMatch: 도메인 규칙이 매칭되지 않을 때 대상 주소를 해석한 뒤 IP 규칙을 다시 시도합니다. GeoSite와 GeoIP를 함께 사용하는 일반적인 트래픽 분류 구성에 적합합니다.
IPOnDemand: IP가 필요한 규칙을 만나면 더 일찍 해석을 시작할 수 있습니다. DNS 조회 시점이 달라지므로 활성화하기 전에 DNS 설정이 예상과 일치하는지 확인해야 합니다.

어떤 프로그램이 IP 주소에 직접 연결하면 GeoSite는 해당 주소에서 원래 도메인을 역추적할 수 없으므로 주로 GeoIP에 의존하게 됩니다. 반대로 원격 DNS, 내장 DNS 또는 특수 전달을 거치면 코어가 확인할 수 있는 정보가 달라질 수 있습니다. 따라서 같은 웹사이트라도 브라우저와 명령줄 도구의 트래픽 분류 결과가 다르다고 해서 데이터베이스가 손상되었다고 단정할 수는 없습니다.

routing 읽기 규칙 순서 확인 전략 값 확인 아웃바운드 태그 매칭 코어 재시작

로그와 비교 요청으로 업데이트 결과 확인

검증할 때 웹페이지가 열리는지만 확인해서는 안 됩니다. 직접 연결과 프록시 모두 성공할 수 있기 때문입니다. 실제로 확인해야 할 것은 업데이트 후 대상이 예상한 규칙에 매칭되는지, 예상한 아웃바운드를 선택하는지, 재시작 후에도 결과가 안정적으로 재현되는지입니다. 테스트할 때마다 먼저 브라우저 연결을 정리하거나 기존 연결이 종료될 때까지 기다려 연결 재사용이 판단에 영향을 주지 않도록 하세요.

현재 버전 상태 기록: 두 데이터 파일의 수정 시간, 현재 코어 유형과 현재 라우팅 설정 이름을 기록하세요.
코어 재시작: v2rayN에서 서비스 재시작을 실행하세요. Android 클라이언트는 현재 연결을 중지한 뒤 다시 시작합니다.
요청을 하나씩 전송: 먼저 GeoSite에 매칭되어야 하는 도메인을 테스트하고, 다음으로 직접 입력할 수 있는 IP를 테스트한 뒤, 마지막으로 대체 프록시 대상를 테스트하세요.
로그 읽기: 대상 주소, 규칙 매칭 결과와 최종 아웃바운드 태그를 확인하세요. 연결이 성공했다는 사실만 확인해서는 안 됩니다.
세 차례 반복: 일정한 간격으로 연결을 다시 수립해 결과가 DNS 캐시나 장시간 연결로 인한 우연이 아닌지 확인하세요.

Geo 파일을 업데이트했는데 트래픽 분류가 바뀌지 않는 이유는?

먼저 코어를 완전히 재시작한 뒤 로그의 outboundTag를 확인하세요. 요청이 앞쪽의 포괄적인 domain, ip 또는 network 규칙에 먼저 매칭되었다면 파일을 계속 다시 다운로드할 것이 아니라 규칙 순서를 조정해야 합니다.

방금 구독을 업데이트했는데 GeoIP도 따로 업데이트해야 하나요?

각각 별도로 판단해야 합니다. 구독은 보통 노드와 그룹 정보를 제공하고, Geo 데이터는 코어의 라우팅 리소스입니다. 「업데이트 확인」→「Geo files」에서 별도로 업데이트한 뒤 서비스를 재시작하세요.

수동으로 교체한 뒤 geosite 분류를 찾을 수 없다는 메시지가 표시되면 어떻게 하나요?

파일 이름이 여전히 geosite.dat인지 확인하고, 현재 코어가 실제로 읽는 디렉터리에 덮어썼는지 확인한 다음 규칙에 지정한 분류명이 존재하는지 점검하세요. 백업 파일을 복원하면 문제가 파일에 있는지 규칙 이름에 있는지 빠르게 판단할 수 있습니다.

도메인 규칙은 매칭되는데 GeoIP 규칙은 계속 매칭되지 않나요?

routing.domainStrategy를 확인하세요. AsIs를 사용하면 도메인 대상이 이후 IP 규칙을 위해 자동으로 해석되지 않습니다. 설정 목적에 따라 IPIfNonMatch로 변경할지 검토하고 DNS 설정도 함께 확인하세요.

업데이트 중 네트워크 시간 초과가 발생하면 어떻게 처리하나요?

먼저 현재 노드가 정상적으로 작동하는지 확인한 뒤 클라이언트의 업데이트 메뉴에서 다시 시도하세요. 계속 실패한다면 기존 파일을 보관한 상태로 잠시 후 재시도하세요. 사용 중인 데이터 파일을 삭제한 뒤 코어를 시작해서는 안 됩니다.

결론: 업데이트가 완료되었다고 판단하는 기준은 매칭 결과의 변화입니다

파일 날짜가 새로워진 것은 첫 번째 확인 단계일 뿐입니다. 코어가 새 데이터를 다시 불러오고, 로그에 대상이 예상한 Geo 규칙에 매칭되며, 세 차례 연속 올바른 아웃바운드를 선택해야 이번 업데이트가 실제로 적용되었다고 확인할 수 있습니다.

되돌릴 수 있는 업데이트 습관 만들기

GeoIP와 GeoSite를 실행할 때마다 업데이트할 필요는 없지만, 오랫동안 업데이트하지 않으면 분류 오차가 점차 커질 수 있습니다. 안정적으로 재현되는 오분류가 발견되었거나 클라이언트 코어를 업데이트했거나 대규모 라우팅 규칙 집합을 변경했을 때 한 번 확인하는 방식이 적절합니다. 네트워크가 불안정할 때마다 즉시 파일을 교체하는 것은 피하세요.

이전 버전의 geoip.dat와 geosite.dat를 보관하고, 코어가 자동으로 검색하지 않는 별도 디렉터리에 백업 파일을 저장하세요.
두 파일은 같은 업데이트 버전으로 함께 처리하고 교체 날짜와 현재 코어 유형을 기록하세요.
도메인 직접 연결, IP 직접 연결과 프록시 대체를 각각 검증할 수 있도록 세 개의 고정 테스트 대상을 유지하세요.
규칙 수정과 데이터 업데이트는 따로 진행해 어느 단계에서 결과가 바뀌었는지 판단할 수 있도록 하세요.
업데이트에 실패하면 먼저 전체 백업을 복원한 뒤 네트워크 또는 디렉터리 권한 문제를 처리하세요.

특정 도메인을 즉시 수정해야 하지만 데이터베이스에 아직 반영되지 않았다면 GeoSite 규칙 앞에 정확한 도메인 규칙을 추가할 수 있습니다. 예를 들어 full:example.com은 하나의 전체 도메인과 매칭하고, domain:example.com은 해당 도메인과 하위 도메인에 매칭합니다. 정확한 규칙 수는 관리 가능한 수준으로 유지하고 데이터베이스에 반영된 뒤 다시 검토해 임시 규칙이 영구적으로 쌓이지 않게 하세요.

전체 문제 해결 순서는 다음처럼 고정할 수 있습니다. 노드와 로컬 포트 확인, 규칙 순서 확인, Geo 파일 날짜 점검, 업데이트 실행, 코어 재시작, 로그 확인, 비교 요청 반복. 이 순서는 Xray와 v2fly 코어 모두에 적용되며, 차이는 리소스 디렉터리와 클라이언트 메뉴 위치뿐이고 GeoIP와 GeoSite의 기본 매칭 역할은 같습니다.