geoip.dat·geosite.dat 업데이트 및 라우팅 규칙 설정

두 dat 파일의 매칭 대상

geosite.dat에는 태그별 도메인 목록이, geoip.dat에는 태그별 IP 주소 대역이 저장됩니다. 두 파일은 라우팅에 사용하는 데이터 파일이지, 노드 구독 파일이 아닙니다. 서버 주소나 계정, 전송 설정을 제공하지도 않습니다. 데이터베이스를 업데이트해도 노드가 추가되거나 라우팅 규칙이 새로 만들어지지는 않습니다.

geosite:cn에 포함되는 항목은 리소스 관리자가 결정합니다. 특정 도메인이나 하위 도메인이 포함되는지는 해당 목록의 데이터에 달려 있으므로, 도메인 확장자만 보고 판단할 수 없습니다. 같은 geosite.dat 파일이라도 데이터 출처가 다르면 태그와 포함 항목이 다를 수 있습니다.

geoip:private는 로컬 네트워크 등 공인망이 아닌 대상에 직접 연결할 때 자주 사용합니다. 대표적인 사설 IPv4 주소 대역은 아래와 같습니다. 일반적인 범위의 예시이며 이 태그의 전체 목록을 보여 주는 것은 아닙니다.

v2rayN: Geo 리소스 업데이트 및 적용 확인

데스크톱에서는 현재 설정이 어떤 코어와 리소스 형식을 사용하는지 먼저 확인하세요. 아래 내용은 Xray 또는 V2Fly 코어에서 dat 리소스를 읽는 설정을 기준으로 합니다. 다른 형식의 리소스를 사용하는 경우 dat 파일을 업데이트해도 해당 규칙에는 영향을 주지 않습니다. 메뉴 이름은 클라이언트 버전에 따라 다를 수 있으니 현재 화면을 기준으로 확인하고, 설치 폴더의 같은 이름 파일을 한꺼번에 교체하지 마세요.

1. 현재 규칙 보관

   메인 화면에서 「설정」→「라우팅 설정」으로 이동해 현재 사용 중인 라우팅 구성과 규칙 순서를 기록하세요. 사용자 지정 설정을 사용한다면 나중에 비교할 수 있도록 원본 JSON 파일도 보관하세요.

2. 리소스 업데이트 실행

   해당 메뉴가 있는 버전에서는 「업데이트 확인」→「Geo 파일 업데이트」를 선택하세요. 업데이트가 끝날 때까지 기다리세요. 「구독 업데이트」는 이 작업을 대신하지 않습니다.

3. 업데이트 로그 확인

   메인 화면 로그에서 다운로드 결과를 확인하고 geoip와 geosite의 처리 상태를 각각 확인하세요. 파일 하나만 성공했다면 라우팅이 정상화됐다고 단정하지 말고 실패한 항목부터 해결해야 합니다.

4. 현재 서비스 재시작

   업데이트가 끝나면 코어 서비스를 재시작하거나 클라이언트를 종료한 뒤 다시 실행하세요. 웹페이지에 새로 접속해 라우팅 로그를 확인하세요. 기존에 유지 중인 연결은 규칙 업데이트를 검증하기에 적합하지 않습니다.

다운로드 실패는 보통 두 가지로 나뉩니다. 리소스 요청이 시간 초과되면 업데이트 경로를 점검해야 하고, 다운로드가 끝난 뒤 실행 오류가 발생하면 파일 형식과 목록 태그를 확인해야 합니다. 클라이언트에서 프록시를 통한 리소스 업데이트를 지원한다면 연결이 가능한 상태에서 시도해 볼 수 있습니다. 데이터 출처를 바꾼 뒤에는 사용자 지정 규칙이 참조하는 태그가 계속 존재하는지도 확인하세요.

v2rayNG: 리소스 파일 메뉴에서 업데이트

안드로이드용 v2rayNG는 Xray 코어를 사용합니다. 리소스 관리 기능이 있는 버전에서는 왼쪽 위 메뉴에서 「리소스 파일」을 열어 항목을 확인하고 화면에 제공되는 업데이트 기능으로 새 파일을 받을 수 있습니다. 버전에 따라 텍스트 버튼이나 업데이트 아이콘이 표시될 수 있습니다. 작업 전에 항목의 파일명을 확인해 geoip만 업데이트하고 geosite를 빠뜨리지 않도록 하세요.

1. 현재 라우팅 설정 확인

   왼쪽 위 메뉴에서 「라우팅 설정」으로 이동해 현재 선택된 모드와 사용자 지정 규칙을 기록하세요. 전체 사용자 지정 JSON을 사용하는 경우 추가 데이터 파일을 참조하는지도 확인해야 합니다.

2. 리소스 파일 열기

   메뉴로 돌아가 「리소스 파일」을 열고 geoip.dat과 geosite.dat에 해당하는 리소스 항목을 확인하세요. 이전 버전에 이 메뉴가 없다면 파일을 시스템 다운로드 폴더에 임의로 복사한 것만으로 가져오기가 완료됐다고 생각하지 마세요.

3. 업데이트하고 결과 확인

   화면의 업데이트 기능을 실행하고 각 리소스의 결과가 표시될 때까지 기다리세요. 실패하면 안내 문구를 기록하세요. 네트워크 시간 초과, 리소스 주소 오류, 파일 로드 실패는 각각 따로 해결해야 합니다.

4. 재연결 후 테스트

   연결을 중지했다가 다시 시작한 뒤 「로그」에서 시작 및 접속 기록을 확인하세요. 메인 화면의 연결 버튼이 켜져 있는지만 보지 말고 브라우저에서 새로 접속해 테스트하세요.

Android 앱의 전용 저장 공간은 일반 다운로드 폴더와 다릅니다. 파일을 수동으로 다운로드했다면 클라이언트가 지원하는 가져오기나 리소스 관리 절차를 통해 코어가 읽도록 해야 합니다. 분할 터널링 설정도 놓치기 쉽습니다. 브라우저가 VPN 적용 대상에서 제외돼 있다면 코어 라우팅을 수정해도 해당 브라우저의 연결 경로는 바뀌지 않습니다.

• 구독 업데이트: 노드 정보와 구독 내용을 갱신하는 작업이며, 일반적으로 코어의 Geo 리소스를 업데이트하지는 않습니다.
• 리소스 업데이트: 목록 데이터를 교체하는 작업이며, 라우팅 모드를 자동으로 활성화하지는 않습니다.
• 라우팅 변경: 매칭에 사용할 규칙을 결정하는 작업이며, 손상되거나 누락된 리소스 파일을 자동으로 복구하지는 않습니다.

라우팅 JSON: 필드, 출구 태그, 매칭 순서

아래는 Xray/V2Fly 형식의 설정을 참고하기 위한 routing 예시이며, 단독으로 실행할 수 있는 전체 설정은 아닙니다. direct와 proxy라는 이름의 아웃바운드가 이미 있다고 가정합니다. 전자는 직접 연결 아웃바운드, 후자는 기존 노드를 가리킵니다. 태그는 참조 이름일 뿐이며 direct라고 작성해도 직접 연결 기능이 자동으로 만들어지지는 않습니다.

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

규칙은 위에서부터 확인하며 처음 일치한 규칙이 연결 경로를 결정합니다. 마지막 규칙은 일반 TCP·UDP 트래픽을 처리하므로 구체적인 규칙 뒤에 배치해야 합니다. 이 규칙을 첫 번째로 옮기면 뒤에 있는 중국 본토 직접 연결 규칙이 해당 연결을 처리할 기회를 얻지 못합니다.

동작을 명확히 설명하기 위해 여기서는 AsIs를 선택했습니다. 라우팅에 도메인이 전달되고 해당 도메인이 geosite:cn에 없으면, 코어는 geoip:cn에 매칭하기 위해 주소를 다시 조회하지 않습니다. 따라서 최종적으로 프록시 규칙에 도달합니다. 요청에 IP가 포함된 경우에는 여기서 IP 조건을 바로 확인할 수 있습니다.

하나의 규칙에서는 보통 domain, ip, port 등 서로 다른 조건을 모두 만족해야 합니다. 같은 필드의 배열에 여러 항목을 넣으면 그 필드에서 후보가 여러 개 있다는 뜻입니다. ‘도메인이 중국 본토에 속하거나 IP가 중국 본토에 속하는 경우’를 표현하려면 예시처럼 규칙을 두 개로 나누세요. 두 필드를 하나의 객체에 넣으면 안 됩니다.

자동 업데이트와 수동 교체: 관리 방식에 맞게 선택

일상적인 사용에는 태그 구성을 매번 바꾸기보다 안정적인 데이터 출처와 명확한 업데이트 결과가 중요합니다. 기본 리소스에 필요한 목록이 실제로 없거나 특정 업데이트로 달라진 점을 확인해야 할 때 수동 관리가 유용합니다.

업데이트 후에도 연결 경로가 잘못될 때: 로그를 기준으로 점검

세 가지 대상만 골라 확인하면 됩니다. 실제로 접속 가능한 로컬 네트워크 서비스, 직접 연결해야 하는 웹사이트, 프록시를 사용해야 하는 웹사이트입니다. 테스트 대상과 예상 경로, 실제 로그를 기록하세요. 복잡한 속도 측정표를 만들기보다 각 연결이 올바른 아웃바운드로 전달되는지 먼저 확인하면 됩니다.

• 시작 단계: 리소스 파일을 찾을 수 없음, 목록을 로드할 수 없음, 아웃바운드 태그를 찾을 수 없음 등의 메시지를 확인하세요. 시작에 실패했다면 웹 요청이 어떤 규칙에 매칭됐는지 논하기 전에 오류부터 해결해야 합니다.
• 접속 단계: 로그 수준에서 접속 기록을 표시하도록 설정한 뒤 대상과 아웃바운드 태그를 확인하세요. 기록이 없다면 시스템 프록시, VPN 적용 여부, 앱별 설정을 먼저 점검하세요.
• 매칭 단계: 프록시 아웃바운드로 표시된다면 앞쪽 도메인 목록에 대상이 포함됐는지, 더 먼저 적용되는 포괄적인 규칙이 있는지 확인하세요.
• 연결 단계: 직접 연결 규칙에 매칭됐는데도 접속되지 않는다면 로컬 DNS, 대상 서비스, 직접 연결 네트워크를 계속 점검하세요. 모든 실패를 데이터베이스 탓으로 돌려서는 안 됩니다.

마지막으로 정상 작동하는 설정과 리소스 출처 기록을 보관하세요. 다음에 라우팅 문제가 생기면 먼저 규칙 순서와 리소스 변경 사항을 비교한 뒤 연결 경로를 점검하세요. 목록 내용이 바뀐 것인지, 설정의 참조가 잘못된 것인지, 아니면 트래픽이 코어에 전달되지 않은 것인지 구분할 수 있습니다.