GeoIP·GeoSite 규칙 파일 업데이트 및 라우팅 설정 방법

이 글 한눈에 보기

노드를 가져온 뒤 트래픽 분기를 조정하려는 사용자를 위한 안내입니다. 먼저 IP 데이터베이스와 도메인 데이터베이스의 차이를 확인하고, 클라이언트가 실제로 불러오는 파일을 업데이트한 다음, 최소한의 라우팅 규칙으로 매칭 결과를 검증합니다. 예시는 V2Ray／Xray의 기존 JSON 라우팅 문법을 사용합니다. v2rayN UI에서 설정할 때는 각 필드를 라우팅 편집 항목에 입력하세요. 코드를 구독 주소 입력란에 붙여 넣으면 안 됩니다.

GeoIP와 GeoSite: IP와 도메인 매칭

geoip.dat에는 태그별 IP 대역 모음이, geosite.dat에는 태그별 도메인 규칙 모음이 저장됩니다. 두 파일 모두 코어가 읽는 데이터 파일이며, 노드 구독 정보나 프록시 프로토콜이 아닙니다. 파일을 업데이트해도 VMess 또는 VLESS 노드의 서버 주소, 사용자 식별자, 전송 설정은 바뀌지 않습니다.

GeoIP: IP 대역 모음

기본 파일 이름: geoip.dat
라우팅 필드: ip
자주 쓰는 형식: geoip:cn
사설 주소 태그: geoip:private

태그 제공 여부는 파일 출처에 따라 다르며, 지역 분류가 웹사이트 운영 주체의 소재지를 뜻하지는 않습니다.

GeoSite: 도메인 규칙 모음

기본 파일 이름: geosite.dat
라우팅 필드: domain
자주 쓰는 형식: geosite:cn
단일 도메인 지정: full:example.com

도메인 모음에는 접미사, 전체 도메인, 정규식 규칙이 포함될 수 있습니다. 단순한 도메인 접미사 목록으로만 보면 안 됩니다.

geosite:cn은 현재 도메인 데이터베이스의 cn 모음을 참조한다는 뜻이지, .cn으로 끝나는 모든 도메인을 의미하지 않습니다. 마찬가지로 geoip:cn도 특정 웹사이트의 등록 국가를 조회하는 기능이 아닙니다. CDN을 사용하는 사이트는 여러 지역의 IP 주소를 반환할 수 있으므로, 도메인 기준 분기와 DNS 응답 IP 기준 분기는 결과가 다를 수 있습니다.

업데이트 전 확인: 파일 출처, 코어, 적용 경로

업데이트 실패는 주로 세 가지 경우에 발생합니다. 클라이언트가 파일을 업데이트한 디렉터리와 코어가 파일을 읽는 디렉터리가 다른 경우, 새 데이터 소스에 기존 규칙에서 참조하는 태그가 없는 경우, 다운로드한 내용이 올바른 데이터 파일이 아닌 경우입니다. 시작하기 전에 정상적으로 사용 중인 파일 두 개와 라우팅 규칙 또는 클라이언트 설정 내보내기 파일을 백업하세요.

파일 2개

GeoIP와 GeoSite 업데이트 결과를 각각 확인

규칙 3개

이후 트래픽 분기 확인에 사용할 최소 예시

7일

일상 점검 주기로 참고할 수 있으며, 반드시 지켜야 하는 것은 아닙니다

먼저 코어를 확인하세요. 클라이언트의 노드 설정과 시작 로그에서 코어 이름을 확인합니다. 바탕 화면 바로 가기의 이름만 보고 판단하지 마세요.
다음으로 출처를 확인하세요. 우선 현재 클라이언트의 기본 데이터 소스를 그대로 사용하세요. 사용자 지정 소스를 쓴다면 기존 규칙에 필요한 cn, private 등의 모음을 제공하는지 먼저 확인합니다.
실제 파일 경로를 확인하세요. 클라이언트가 관리하는 리소스 디렉터리와 시작 오류에 표시된 경로를 기준으로 합니다. 포터블 디렉터리, 별도 데이터 디렉터리, 여러 설치본은 서로 다른 경로를 사용할 수 있습니다.
문제 발생 시 되돌릴 수 있도록 준비하세요. 기존 출처, 업데이트 날짜, 라우팅 설정도 함께 기록합니다. 규칙 텍스트만 백업하면 새 파일에 필요한 태그가 없는 문제는 해결되지 않습니다.

판단 기준: 먼저 데이터 출처를 통일하고, 규칙 데이터베이스 변경은 그다음에

현재 트래픽 분기가 정상이라면 우선 같은 출처의 데이터를 업데이트하세요. 필요한 분류가 기존 데이터베이스에 없다는 사실을 확인한 경우에만 출처를 변경하고 태그를 하나씩 대조하세요. 파일 업데이트와 규칙 체계 이전을 한 번에 처리하지 않는 것이 좋습니다.

클라이언트에서 규칙 파일 업데이트하기: 다운로드 후 코어 다시 불러오기

클라이언트 메뉴 이름은 버전과 UI 언어에 따라 달라질 수 있습니다. 데스크톱 v2rayN에서는 보통 ‘업데이트 확인’ 메뉴 아래에서 Geo 파일 업데이트 항목을 찾을 수 있습니다. 버전에 따라 GeoIP와 GeoSite가 별도 항목으로 표시되기도 합니다. 아래 안내는 기능을 기준으로 확인하세요. 해당 항목이 보이지 않으면 현재 버전의 메뉴와 로그를 살펴보고, ‘구독 업데이트’를 규칙 데이터베이스 업데이트로 착각하지 마세요.

먼저 연결이 정상인지 확인하세요. 노드를 사용할 수 있는지 확인합니다. 현재 네트워크에서 규칙 데이터 소스에 접근할 수 없다면 클라이언트의 업데이트 프록시 옵션으로 프록시 다운로드를 설정할 수 있습니다. 시스템 프록시 적용 여부만으로 업데이트 로그를 판단해서는 안 됩니다.
Geo 파일을 업데이트하세요. v2rayN에서 ‘업데이트 확인’ 메뉴를 열고 Geo 파일 관련 업데이트 항목을 선택합니다. 항목이 나뉘어 있으면 GeoIP와 GeoSite를 각각 업데이트하세요. 각 항목의 완료 표시를 확인한 뒤 라우팅을 수정합니다.
오류 메시지를 확인하세요. 시간 초과는 대개 연결 문제를 가리킵니다. 파싱, 압축 해제, 파일 쓰기 실패라면 다운로드한 내용과 디렉터리 권한, 파일 사용 중 여부를 확인하세요. 파일 수정 시간 변경은 참고 자료일 뿐입니다.
코어를 다시 불러오세요. 클라이언트에서 제공하는 서비스 재시작 또는 코어 다시 불러오기를 실행합니다. 별도 버튼이 없다면 연결을 중지한 후 다시 시작하세요. 그런 다음 시작 로그에서 데이터 파일이나 분류 로딩 오류가 없는지 확인합니다.
트래픽 분기를 테스트하세요. 업데이트 전과 동일한 라우팅 모드와 테스트 대상을 유지하고 실제 아웃바운드를 비교합니다. 이때 노드, DNS, 전체 라우팅 템플릿을 동시에 바꾸지 마세요.

Android에서는 보통 v2rayNG의 사이드 메뉴나 리소스 관련 화면에서 Geo 리소스 업데이트 항목을 찾을 수 있습니다. 해당 화면에서 제공하는 업데이트 기능을 실행하세요. v2flyNG의 메뉴 구성과 업데이트 항목은 설치된 버전에 따라 다르므로 다른 클라이언트의 메뉴 이름을 그대로 적용하지 마세요. 모바일에서 업데이트한 뒤에도 연결을 중지했다가 다시 시작해야 합니다.

라우팅 규칙 작성법: 도메인 우선, IP 보완, 마지막에 기본 규칙

라우팅은 규칙 순서대로 확인하며, 조건에 맞는 규칙이 발견되면 지정된 아웃바운드를 사용합니다. 아래 예시는 ‘중국 본토 도메인은 직접 연결, 사설 및 중국 본토 IP는 직접 연결, 그 외 TCP／UDP는 프록시 사용’의 기본 구조입니다. 여기서 direct와 proxy는 아웃바운드 태그이므로 기존 설정의 outbounds[].tag와 정확히 일치해야 합니다.

요청이 코어에 전달됨 도메인 규칙 매칭 필요한 경우 DNS 조회 IP 규칙 매칭 기본 아웃바운드

이 코드는 설정 일부이며 클라이언트 전체 설정이 아닙니다. V2Ray／Xray JSON을 직접 편집하는 경우에 사용할 수 있습니다. 클라이언트 GUI에서 라우팅을 관리한다면 라우팅 편집기에서 같은 순서로 규칙을 만들고 현재 활성화된 규칙 집합에 저장하세요.

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

첫 번째 규칙은 도메인 모음을 확인합니다. 요청에 도메인이 포함되어 있고 geosite:cn에 해당하면 direct를 선택합니다. 같은 요청을 분기할 때 GeoIP까지 사용할 필요는 없습니다.
두 번째 규칙은 IP 모음을 확인합니다. 같은 ip 배열에 있는 두 모음은 ‘둘 중 하나에 일치하면 됨’을 뜻하며, 대상이 두 모음에 동시에 포함되어야 한다는 의미가 아닙니다. 사설 주소 모음의 실제 범위는 데이터 파일을 기준으로 확인하세요.
세 번째 규칙은 기본 경로를 명시합니다. 앞선 규칙에 해당하지 않는 TCP와 UDP 요청은 proxy로 보냅니다. 이처럼 조건이 넓은 규칙은 마지막에 배치해야 합니다. 앞에 두면 뒤쪽 규칙이 매칭될 기회가 없어질 수 있습니다.
필드를 무심코 합치지 마세요. 한 규칙에 domain과 ip를 함께 입력해도 ‘도메인 또는 IP 중 하나만 일치하면 됨’이라는 뜻은 아닙니다. 일반적으로 조건 필드는 모두 충족해야 하므로 규칙을 두 개로 나누는 편이 확인하기 쉽습니다.

IPIfNonMatch는 도메인 요청이 도메인 조건으로 라우팅되지 않았을 때 대상 IP를 조회한 다음 IP 조건을 다시 확인한다는 뜻입니다. 마지막의 network 기본 규칙은 도메인 분류가 아니며, 이 IP 조회 과정을 대신하지 않습니다. AsIs로 설정하면 라우팅 모듈이 IP 규칙 적용을 위해 도메인을 직접 조회하지 않습니다. 따라서 도메인 정보만 있는 요청은 기본 아웃바운드로 갈 수 있습니다.

DNS와 규칙 순서: 업데이트에 성공해도 분기 결과가 다를 수 있습니다

GeoSite가 DNS 서버를 자동으로 지정하지 않으며, GeoIP도 잘못된 DNS 응답을 바로잡지 않습니다. 라우팅 모듈은 연결에 사용할 아웃바운드를 결정하고, DNS 설정은 주소를 조회하는 방법을 정합니다. 서로 관련은 있지만 ‘중국 본토 도메인은 직접 연결’이 ‘DNS 조회도 반드시 중국 본토 DNS 서버로 전송’된다는 뜻은 아닙니다. DNS 서버 선택과 조회 트래픽의 아웃바운드는 별도로 확인해야 합니다.

확인된 증상	우선 확인할 사항	대응 방법
도메인 규칙이 계속 매칭되지 않음	코어가 도메인과 IP 중 어떤 정보를 받는지	앱의 프록시 사용 방식을 확인하고 필요하다면 스니핑 설정을 검토하세요. 모든 암호화 연결에서 도메인을 복원할 수 있다고 가정하지 마세요.
모든 웹사이트가 같은 출구를 사용함	라우팅 모드와 첫 번째 규칙	사용자 지정 트래픽 분기가 활성화되어 있는지 확인하고, 모든 트래픽에 해당하는 규칙을 마지막으로 옮기세요.
같은 사이트의 출구가 간헐적으로 바뀜	CDN 주소와 IP 분류	GeoIP에 의존하고 있는지 확인하고, 출구를 고정해야 한다면 앞쪽에 도메인 예외를 추가하세요.
규칙을 바꿨는데 기존 연결의 출구가 그대로임	연결이 이미 설정되었는지	코어를 다시 불러온 뒤 새 테스트 연결을 만드세요. 기존 장기 연결로 새 규칙의 적용 여부를 판단하지 마세요.

IPIfNonMatch를 설정했더라도 앞쪽 도메인 규칙에 이미 일치한 요청은 뒤의 GeoIP 규칙으로 다시 판정되지 않습니다. 반대로 앱이 프록시에 전달하기 전에 도메인을 IP로 변환하면 GeoSite에서 매칭할 도메인 정보가 없을 수 있습니다. 스니핑으로 도메인을 알아낼 수 있는지는 프로토콜과 트래픽 형태, 설정에 따라 달라집니다. 항상 해결되는 방법으로 간주해서는 안 됩니다.

판단 기준: 먼저 요청 정보를 확인하고 데이터베이스가 오래됐는지 살펴보세요

예상과 다른 아웃바운드가 사용되면 먼저 로그에서 대상 도메인 또는 IP, 선택된 아웃바운드, 규칙 순서를 확인하세요. 요청 정보가 올바르고 규칙도 활성화되어 있는데 대상이 모음에 없는 경우에만 데이터를 업데이트하거나 개별 예외를 추가하세요.

업데이트 실패 및 분류 없음: 자주 발생하는 문제 해결

업데이트 성공으로 표시됐는데 시작 시 분류가 없다는 오류가 발생하는 이유는 무엇인가요?

먼저 로그에 표시된 누락 태그를 기록합니다. 예를 들면 geosite:cn입니다. 현재 파일 출처에 해당 모음이 포함되어 있는지 확인한 다음 코어가 파일을 읽는 경로를 살펴보세요. 비슷해 보이는 다른 태그로 무작정 바꾸지 마세요. 백업 파일을 복원해 정상적으로 시작되는지 확인한 뒤 새 데이터 소스에서 제공하는 분류에 맞춰 규칙을 조정할 수 있습니다.

GeoIP 업데이트는 완료됐지만 GeoSite 다운로드가 시간 초과되면 어떻게 하나요?

두 업데이트 결과를 따로 확인하고 실패한 항목의 출처와 네트워크 연결부터 점검하세요. 클라이언트에서 프록시 업데이트를 지원한다면 정상 작동을 확인한 노드로 다시 시도합니다. 정상적으로 사용할 수 있는 기존 파일을 계속 덮어쓰거나 한 파일을 복사해 다른 이름으로 저장하지 마세요.

구독을 업데이트했는데 라우팅 데이터베이스는 왜 그대로인가요?

구독에는 주로 노드 정보가 포함되며, Geo 파일은 별도 메뉴에서 업데이트해야 합니다. 클라이언트의 Geo 리소스 업데이트 항목에서 업데이트한 뒤 연결을 다시 시작하세요. 구독 서비스에서 라우팅 설정도 제공한다면 규칙 텍스트와 데이터 파일의 업데이트 상태를 각각 확인합니다.

업데이트 후 일부 웹사이트가 열리지 않으면 바로 노드를 바꿔야 하나요?

먼저 코어가 정상적으로 시작됐는지 확인하고 해당 웹사이트의 아웃바운드가 바뀌었는지 살펴보세요. 업데이트 전에는 접속됐고 데이터 파일 두 개를 되돌린 후 다시 접속된다면 태그 차이와 분류 변경을 우선 확인합니다. 모든 연결이 실패한다면 노드 연결, DNS, 로컬 프록시 설정을 점검하세요.

최신 데이터를 유지하려고 매일 데이터 소스를 바꿀 필요는 없습니다. 일반적인 사용 환경에서는 일주일에 한 번 확인하고, 분류가 바뀌었거나 로그 오류가 있을 때 더 일찍 조치하면 됩니다. 규칙 데이터베이스 업데이트로 노드 대역폭이 늘어나거나 서버의 프로토콜 지원 여부가 달라지지는 않습니다. 바뀌는 것은 라우팅 판단의 근거가 되는 데이터입니다.

적용 확인: 테스트 대상 3개를 고정하고 이전 상태로 되돌릴 수 있도록 준비

검증할 때는 직접 연결될 것으로 예상되는 도메인 하나, 프록시로 연결될 것으로 예상되는 도메인 하나, 접근 권한이 있는 LAN 서비스 하나를 선택하세요. 속도를 측정하는 것이 아니라 세 연결 유형이 각각 예상한 아웃바운드로 들어가는지 확인하는 것이 목적입니다. LAN 서비스는 실제로 존재하는 주소를 사용하고, 임의의 주소로 테스트 요청을 반복해서 보내지 마세요.

연결 지점이 일치하는지 확인하세요. 예를 들어 앱에서 127.0.0.1:10808을 사용한다면 해당 포트가 현재 클라이언트의 수신 포트인지, 어떤 프록시 프로토콜을 지원하는지 먼저 확인합니다. 10808은 예시일 뿐이므로 실제 설정을 대신할 수 없습니다.
설정이 불러와졌는지 확인하세요. 라우팅 설정을 저장하고 코어를 다시 불러온 뒤 파일 읽기, 태그 누락, 설정 파싱 오류가 발생했는지 확인합니다. 시작에 실패했다면 브라우저 동작만 보고 라우팅을 추측하지 마세요.
대상별로 새 연결을 만드세요. 대상, 시간, 로그에 표시된 아웃바운드 태그를 기록합니다. 클라이언트에 direct／proxy만 표시된다면 출구 확인에는 도움이 되지만, 어떤 규칙이 매칭됐는지까지 알 수는 없을 수 있습니다.
문제 범위를 좁히세요. 필요한 경우 최소 규칙만 잠시 남기거나 로그 상세도를 높여 짧게 재현합니다. 점검이 끝나면 평소 로그 수준으로 되돌리고, 로그를 공유하기 전에 노드 주소와 사용자 식별자, 접속 기록을 삭제하세요.
정상 작동 버전을 보관하세요. 세 대상이 모두 예상대로 연결되는 것을 확인한 뒤 오래된 백업을 정리합니다. 문제가 생기면 기존 파일과 규칙을 복원하고, 업데이트와 설정 변경을 각각 다시 진행하세요.

마지막으로 규칙 파일 출처, 라우팅 순서, 실제 사용 중인 코어를 기록해 두세요. 기기를 바꾸거나 클라이언트를 다시 설치하더라도 먼저 동일한 트래픽 분기 방식을 복원한 다음 분류와 DNS를 조정할 수 있습니다. 기본 설정은 설정 가이드에서, 필드별 의미는 프로토콜 레퍼런스에서 확인하세요.