geoip.dat·geosite.dat 업데이트 방법: v2rayN 라우팅 규칙 데이터베이스 관리 가이드

두 dat 파일의 역할: 도메인 매칭과 IP 매칭

geosite.dat에는 지역·용도·서비스별로 분류한 도메인 목록이 저장되고, geoip.dat에는 지역 등의 태그로 분류한 IP 주소 범위가 저장됩니다. 라우팅에서 geosite:cn은 도메인 목록을, geoip:cn은 IP 목록을 조회하므로 서로 바꿔 쓸 수 없습니다. 데이터베이스는 ‘목록에 무엇이 있는지’를 제공하고, 라우팅 규칙은 ‘조건에 맞으면 어떤 출구를 사용할지’를 결정합니다.

예를 들어 브라우저가 도메인을 로컬 프록시에 전달하면 도메인 규칙으로 바로 판단할 수 있습니다. 반면 어떤 앱이 대상 IP만 프록시에 전달하면 도메인 데이터베이스가 적용되지 않을 수 있습니다. 지원되는 트래픽에서는 스니핑을 활성화해 도메인 정보를 보완할 수 있지만, 모든 연결에서 원래 도메인을 복원할 수 있는 것은 아닙니다. geosite 파일만 업데이트해도 앱이 도메인을 전달하지 않는 문제는 해결되지 않습니다.

v2rayN에서 간편 업데이트: 먼저 백업하고 로그 확인

가능하면 클라이언트에 내장된 Geo 업데이트 기능을 사용하세요. 데스크톱 인터페이스에서는 보통 ‘업데이트 확인’ → ‘Geo 파일 업데이트’ 순서로 진행하며, 일부 버전에서는 메뉴가 ‘Geo 파일’로 표시됩니다. 메뉴 위치와 문구는 버전이나 인터페이스에 따라 다를 수 있으므로, ‘구독 업데이트’나 클라이언트 프로그램 업데이트가 아닌 업데이트 메뉴의 Geo 항목을 찾으세요.

1. 기존 설정 보존

   먼저 현재 코어 종류, 사용 중인 라우팅 프리셋, Geo 데이터 소스를 기록하세요. 로컬 설정을 복사해 두려면 클라이언트를 종료한 다음 실제 설정 디렉터리를 복사하세요. 기록 중인 설정 파일을 안정적인 백업으로 간주하지 마세요.

2. 데이터베이스 업데이트

   ‘업데이트 확인’ → ‘Geo 파일 업데이트’를 선택하고 작업이 끝날 때까지 기다리세요. 출력 메시지에 geoip.dat와 geosite.dat가 각각 표시되는지 확인하세요. 다운로드 진행이 끝났다는 이유만으로 창을 바로 닫지 마세요.

3. 업데이트 결과 확인

   로그에서 성공 또는 실패 메시지를 확인하고 실제 데이터 디렉터리에 있는 파일의 수정 시각과 크기도 살펴보세요. 파일이 있다고 해서 내용을 사용할 수 있는 것은 아니며, 파일 시간이 바뀌어도 코어가 다시 읽었다는 뜻은 아닙니다.

4. 코어 다시 불러오기

   클라이언트에서 현재 코어를 다시 시작하거나 클라이언트를 완전히 종료한 뒤 다시 실행하세요. 시작 로그에서 파일 읽기 실패, 분류 누락, 라우팅 설정 오류가 없는지 확인합니다.

5. 라우팅 분리 테스트

   직접 연결해야 하는 사이트, 프록시를 사용해야 하는 사이트, 실제로 사용하는 LAN 서비스를 각각 테스트하세요. 노드, 라우팅 프리셋, 프록시 모드는 그대로 두어 여러 변수를 한 번에 바꾸지 않도록 합니다.

업데이트 시간 초과가 발생하면 먼저 현재 네트워크에서 클라이언트에 설정된 데이터 소스에 접속할 수 있는지 확인하세요. 인터페이스에 프록시를 통한 다운로드 옵션이 있다면 사용 가능한 것으로 확인된 노드를 선택한 뒤 다시 시도하세요. 옵션이 없다면 ‘시스템 프록시 설정’이 반드시 해결책이라고 생각하지 마세요. 업데이트 요청이 시스템 프록시를 따르는지는 클라이언트 구현에 따라 다릅니다. 연결 시간 초과, 권한 부족, 데이터 로드 실패 중 어떤 오류인지 확인한 뒤 다음 조치를 결정하세요.

업데이트 방법 선택: 내장 기능 우선, 수동 교체는 문제 해결용

안내서에 나온 고정 경로만 믿고 파일 위치를 추측하지 마세요. 설치 방법, 운영체제, 클라이언트 버전에 따라 리소스 디렉터리가 달라집니다. 클라이언트 설정과 시작 로그, 실제 파일 위치를 함께 확인해 코어가 읽는 경로를 찾으세요. 실행 파일 옆에 dat 파일이 있어도 실행 중인 코어가 그 파일을 사용한다는 보장은 없습니다.

• 형식 확인: 이 글의 dat 규칙 문법은 Xray와 V2Fly를 대상으로 합니다. 다른 형식의 파일은 확장자만 바꿔 사용할 수 없습니다.
• 데이터 출처 확인: 두 파일은 분류 기준이 서로 달라 문제 해결이 복잡해지지 않도록 동일한 신뢰 가능한 관리 체계에서 가져오는 것이 좋습니다.
• 문제가 생기면 되돌리기: 파일 교체 후 시작되지 않으면 먼저 이전에 정상 작동하던 파일을 복원하고 구체적인 오류를 확인하세요. 클라이언트 재설치, 노드 변경, DNS 수정까지 한꺼번에 하지 마세요.

라우팅 규칙 작성과 순서: 구체적인 규칙을 먼저, 기본 규칙은 나중에

Xray와 V2Fly의 일반적인 field 라우팅은 규칙을 순서대로 확인하며, 처음 매칭된 규칙이 출구를 결정합니다. 모든 TCP·UDP 트래픽을 대상으로 하는 규칙을 맨 앞에 두면 뒤에 있는 한국 국내 직접 연결 규칙이 작동하기 어렵습니다. 아래는 사설 주소 우선, 국내 도메인 직접 연결, 국내 IP 직접 연결, 마지막으로 프록시를 기본 출구로 사용하는 다섯 가지 규칙 예시입니다.

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

여기서 direct와 proxy는 예시용 출구 태그이며, 코어가 자동으로 만드는 키워드가 아닙니다. 완성된 설정에 같은 이름의 outbound가 정의되어 있어야 합니다. 클라이언트가 생성하는 태그는 다를 수 있으므로 현재 설정을 기준으로 확인하세요. 단일 규칙만 입력할 수 있는 칸에 JSON 전체를 붙여 넣지 말고, v2rayN이 자동 생성한 실행 설정을 직접 덮어쓰지도 마세요. 다음 실행 때 설정이 다시 생성될 수 있습니다.

• 사설 주소 우선: LAN 대상이 먼저 직접 연결되도록 합니다. 다만 시스템 라우팅, 방화벽, TUN 제외 설정을 대신하지는 않습니다.
• 도메인 규칙과 IP 규칙은 따로 작성: geosite:cn은 domain 배열에, geoip:cn은 ip 배열에 넣습니다.
• 두 조건을 동시에 만족해야 하는 것으로 잘못 이해하지 않기: field 규칙 하나에 domain과 ip처럼 서로 다른 조건을 함께 쓰면 일반적으로 모든 조건을 동시에 충족해야 합니다. ‘도메인 또는 IP’로 매칭하려면 규칙을 둘로 나누는 편이 명확합니다.
• 사용자 지정 예외는 앞에 배치: 특정 사이트를 반드시 프록시로 보내야 한다면, 해당 도메인 규칙을 범위가 넓은 국내 직접 연결 규칙보다 앞에 두세요.

DNS와 규칙 데이터베이스: 파일을 업데이트해도 결과가 달라지지 않을 수 있습니다

domainStrategy는 라우팅 매칭에서 도메인을 처리하는 방식을 결정하며, DNS 설정 전체와 같은 의미는 아닙니다. AsIs는 라우팅의 IP 매칭을 위해 도메인을 능동적으로 조회하지 않습니다. IPIfNonMatch는 도메인 매칭에 실패하면 주소를 조회한 뒤 계속 판단합니다. IPOnDemand는 매칭 과정에서 IP가 필요할 때 조회합니다. 뒤의 두 옵션은 리졸버, 네트워크 연결 가능성, 개인정보 보호 측면을 함께 고려해야 하므로 ‘국내 사이트가 직접 연결되는지’만 보고 선택하면 안 됩니다.

사이트를 직접 연결할지 판단할 때 IP의 소재 지역만으로 사이트의 소속을 단정하지 마세요. CDN을 사용하면 같은 도메인도 네트워크에 따라 다른 주소로 조회될 수 있고, 데이터베이스마다 업데이트 주기도 다릅니다. 업무상 요구가 분명한 사이트는 지역 규칙을 계속 조정하기보다 구체적인 도메인 규칙으로 관리하는 편이 간편합니다.

1. 먼저 연결이 코어에 들어올 때 도메인인지 IP인지 확인하고, 앱 트래픽이 실제로 프록시를 거치는지 점검하세요.
2. 라우팅 로그에 기록된 대상과 출구 태그를 확인하세요. 필요하면 로그 상세 수준을 일시적으로 높이고, 점검을 마치면 원래 수준으로 되돌립니다.
3. 마지막으로 DNS 조회 결과와 데이터베이스 분류를 확인하세요. 브라우저에 표시되는 출구 주소만으로 모든 리소스 요청의 경로를 판단하지 마세요.

업데이트 후에도 적용되지 않을 때: 오류 유형별 해결 방법

업데이트 주기는 필요에 따라 정하면 되며 연결할 때마다 업데이트할 필요는 없습니다. 데이터 소스를 바꾸거나 분류 누락을 발견했을 때, 또는 규칙 문제를 점검할 때 필요한 항목만 업데이트하세요. 구독 업데이트는 노드 정보를, Geo 업데이트는 규칙 목록을, 라우팅 편집은 트래픽의 출구를 관리합니다. 이 세 가지를 나눠 처리해야 문제 해결 기록도 유용해집니다. 필드를 더 확인하려면 라우팅 설정 레퍼런스를 참고하세요. 연결 자체가 되지 않는다면 먼저 연결 문제 해결에서 기본 연결 상태를 확인하세요.