노드를 가져온 뒤 라우팅을 점검하려는 사용자를 위한 안내입니다. 먼저 도메인 카테고리와 IP 주소 데이터베이스의 차이를 살펴보고, 클라이언트에서 실제 사용하는 데이터 파일을 업데이트합니다. 마지막으로 간단한 라우팅 예제와 로그로 규칙 적용 결과를 확인합니다. 파일 다운로드 성공, 카테고리 로드, 올바른 출구로 트래픽 전달을 각각 점검해 업데이트를 반복해도 잘못된 라우팅이 해결되지 않는 상황을 피하세요.
두 데이터베이스는 각각 무엇을 매칭하나요?
geosite.dat에는 태그별 도메인 항목이 저장되고, geoip.dat에는 태그별 IP 주소 대역이 저장됩니다. 둘 다 코어가 읽는 바이너리 데이터 파일입니다. 라우팅 편집기에 바로 붙여 넣는 JSON이 아니며, 구독 링크나 노드 비밀번호, 전송 프로토콜 설정을 저장하지도 않습니다.
예를 들어 geosite:cn은 도메인 데이터베이스의 cn 카테고리를 조회하고, geoip:cn은 IP 데이터베이스의 cn 주소 대역을 조회합니다. 두 목록은 서로 다릅니다. 특정 카테고리에 포함된 도메인이라도 현재 해석된 모든 IP 주소가 같은 지역에 속하는 것은 아닙니다. 해외 CDN을 사용하는 사이트에서 특히 이런 차이가 나타날 수 있습니다.
| 리소스 | 매칭 대상 | 대표 참조 방식 | 한계 |
|---|---|---|---|
geosite.dat | 요청에 포함되거나 코어가 식별한 도메인 | geosite:cn | 카테고리에 등록된 항목을 기준으로 하며 실시간 DNS 조회 결과가 아닙니다 |
geoip.dat | 대상 IP 주소 | geoip:cn | IP 주소 대역을 분류한 것으로, 서비스 운영 주체를 식별하는 정보는 아닙니다 |
geoip.dat | 데이터 소스에서 정의한 사설 또는 예약 주소 목록 | geoip:private | 구체적인 범위는 해당 데이터 소스의 태그 내용을 따릅니다 |
IP만 사용하는 요청은 도메인 카테고리로 직접 매칭할 수 없습니다. 도메인 요청을 IP 규칙으로도 매칭할 수 있는지는 라우팅의 도메인 전략과 DNS 해석에 따라 달라집니다. 따라서 geosite를 업데이트했다고 모든 앱이 도메인 기준으로 라우팅되는 것은 아닙니다. 클라이언트가 대상 정보를 제대로 받는지도 확인해야 합니다.
데이터 출처와 업데이트 방식 선택
일반적으로 커뮤니티에서 관리하는 도메인 목록과 IP 주소 대역 프로젝트의 데이터를 빌드 과정에서 DAT 파일로 컴파일합니다. 도메인 항목에는 전체 도메인, 접미사 매칭, 키워드, 정규식 등 다양한 형식이 포함될 수 있으며, IP 데이터베이스는 주로 CIDR 대역을 태그별로 묶습니다. Xray와 V2Ray 생태계에서는 해당 파일에 정해진 형식을 사용하지만, 파일명이 같다고 해서 출처별 태그까지 동일한 것은 아닙니다.
클라이언트 프로그램, 코어 프로그램, 규칙 데이터, 라우팅 규칙은 서로 다른 네 가지 요소입니다. v2rayN을 업데이트해도 현재 사용하는 Geo 파일이 업데이트되는 것은 아니며, Geo 파일을 업데이트해도 사용자 지정 규칙의 순서가 자동으로 바뀌지는 않습니다. 데이터 출처를 바꾸기 전에 cn, private, 서비스 카테고리 등 규칙에서 참조하는 태그를 기록하고 새 출처에 해당 태그가 있는지 확인하세요.
클라이언트에서 직접 업데이트
권장클라이언트가 설정된 리소스 주소에서 파일을 가져와 관리하는 위치에 저장합니다. 새 파일이 이전 디렉터리에 들어가는 실수를 줄일 수 있고, 업데이트 로그로 실패 지점도 추적하기 쉽습니다.
권장 상황: 정기 관리, 기본 데이터 소스 사용, 첫 문제 해결
수동으로 가져오거나 교체
먼저 코어가 실제로 읽는 리소스 경로를 확인한 뒤, 출처를 확인할 수 있는 파일을 사용합니다. Android에서는 앱의 비공개 디렉터리를 추측하지 말고 클라이언트가 제공하는 리소스 가져오기 기능을 우선 사용하세요.
적합한 상황: 오프라인 업데이트, 내장 다운로드 불가, 특정 데이터 버전 유지
사용자 지정 데이터 소스로 변경
다운로드 주소, 파일 형식, 카테고리 목록을 함께 확인하세요. 파일 크기가 더 크다는 이유만으로 교체하지 마세요. 새 카테고리가 추가되어도 쓸모가 없을 수 있고, 사용 중인 카테고리가 빠지면 코어가 시작되지 않을 수도 있습니다.
적합한 상황: 특정 서비스 카테고리에 의존하며 규칙 참조를 직접 관리할 수 있는 사용자
요약: 출처를 고정한 다음 데이터를 업데이트하세요
기존 리소스와 라우팅 설정을 백업하고, 먼저 같은 출처에서 업데이트한 뒤 결과를 확인하세요. 필요한 태그가 없는 것이 확인된 경우에만 출처 변경을 고려하세요. 한 번의 문제 해결 과정에서 데이터 출처를 바꾸고 DNS와 규칙 순서까지 함께 수정하지 마세요.
v2rayN 업데이트 및 다시 불러오기
데스크톱에서는 현재 연결이 Xray 또는 V2Ray의 DAT 라우팅 설정을 사용하는지 먼저 확인하세요. 이 글의 예제는 다른 형식의 규칙 세트에는 적용되지 않습니다. v2rayN은 버전에 따라 메뉴 배치가 달라집니다. 일반적으로 메인 창의 ‘업데이트 확인’에서 ‘Geo 파일’ 또는 ‘Geo 파일 업데이트’를 선택합니다. 해당 메뉴가 리소스 관리 페이지에 있다면 현재 메뉴 이름과 로그를 기준으로 확인하세요. ‘구독 업데이트’는 규칙 데이터 업데이트와 다릅니다.
-
현재 설정 기록
‘설정’ → ‘라우팅 설정’을 열고 현재 활성화된 라우팅 구성, 규칙 순서, 사용하는 카테고리를 기록하세요. 사용자 지정 설정도 별도로 백업합니다. 일부 버전은 구성을 저장한 뒤 메인 창에서 해당 구성을 선택해야 실제로 적용됩니다.
-
규칙 데이터 업데이트
메인 창에서 ‘업데이트 확인’ → ‘Geo 파일’을 열고 업데이트를 실행합니다.
geoip.dat와geosite.dat의 결과를 각각 확인하고, 첫 번째 파일이 성공했다고 로그를 닫지 마세요. -
다운로드 결과 확인
연결 실패가 표시되면 먼저 리소스 다운로드 주소를 확인하고, 업데이트 작업에 현재 프록시가 필요한지 살펴보세요. 응답을 해석할 수 없다면 웹페이지 주소를 파일 주소로 입력한 것은 아닌지 확인합니다. 파일명이 있다고 해서 실제 내용이 DAT 데이터인 것은 아닙니다.
-
현재 서비스 다시 시작
데이터를 저장한 뒤 현재 연결을 다시 시작해 코어가 리소스를 새로 불러오도록 하세요. 메인 창의 탭만 전환해서는 리소스가 다시 로드되지 않습니다. 이미 연결된 장시간 세션으로는 새 규칙의 처리 결과를 확인할 수 없습니다.
-
시작 로그 확인
리소스 열기 실패, 카테고리 없음, 라우팅 구성 실패가 발생하지 않았는지 확인하세요. 그런 다음 테스트 요청을 새로 보냅니다. 클라이언트가 이전 설정을 자동 복구하도록 되어 있다면 실제로 방금 저장한 구성이 실행 중인지도 확인해야 합니다.
v2rayNG에서 리소스 업데이트하기
Android용 v2rayNG는 Xray 코어를 사용하며 Geo 데이터는 보통 앱에서 관리합니다. 별도의 리소스 관리 페이지가 있는 버전은 사이드 메뉴에서 ‘Geo 리소스 파일’을 열어 업데이트하거나 가져올 수 있습니다. 이전 버전에서는 메인 화면 오른쪽 위 메뉴에 ‘Geo 파일 업데이트’가 있을 수 있습니다. 메뉴 이름이나 위치가 다르면 구독 그룹을 찾기보다 Geo 리소스 관련 항목을 찾아보세요.
- 업데이트 전: 사이드 메뉴의 ‘라우팅 설정’에서 현재 규칙을 기록하세요. 예상한 분할 라우팅 결과를 확인할 수 있도록 전역 프록시나 전역 직접 연결 모드가 임시로 켜져 있지 않은지 확인합니다.
- 업데이트 중: 두 리소스의 업데이트 성공 여부를 각각 확인하세요. 리소스 페이지에서 다운로드 주소를 변경할 수 있다면 원본 파일을 반환하는 주소를 입력하고, 프로젝트 소개 페이지 주소는 사용하지 마세요.
- 업데이트 후: 하단의 연결 서비스를 중지한 다음 다시 시작해 새 코어 프로세스가 데이터를 불러오도록 하세요. 앱으로 돌아오는 것만으로는 연결이 재시작되지 않습니다.
- 수동 가져오기: 리소스 페이지에서 제공하는 가져오기 기능을 사용하고 파일 형식을 확인하세요. 현재 버전에 가져오기 메뉴가 없다면 앱의 비공개 디렉터리를 추측해 리소스를 교체하지 마세요.
업데이트에 프록시가 필요한 경우 먼저 기존 연결로 리소스 서버에 접속할 수 있는지 확인하세요. 리소스 로드 실패로 프록시 자체가 시작되지 않는다면 현재 네트워크에서 접속 가능한 다운로드 출처를 사용하거나 오프라인으로 가져와야 합니다. ‘다운로드 경로에 프록시가 필요함’과 ‘라우팅 파일 업데이트가 필요함’을 혼동해 같은 작업을 반복하지 마세요.
geosite·geoip 참조 방법
Xray 라우팅 JSON에서 geosite: 참조는 domain 배열에, geoip: 참조는 ip 배열에 입력합니다. 카테고리 이름은 임의의 설명 문구가 아니며 현재 파일에 실제로 존재해야 합니다. geoip:cn의 cn은 일반적으로 사용하는 지역 코드 태그입니다. private는 데이터 세트에서 정한 특수 태그이지 국가 코드가 아닙니다.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"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"
}
]
}
}
다음은 라우팅 설정 예제이며 단독으로 실행할 수 있는 전체 설정이 아닙니다. 전체 설정에 direct와 proxy 출구가 이미 정의되어 있다고 가정합니다. 차단이 필요하면 block도 별도로 정의하고 참조해야 합니다. 이 태그들은 이름일 뿐이므로 실제 outbounds와 일치해야 합니다. 그대로 붙여 넣는다고 클라이언트가 출구를 자동으로 만들지는 않습니다. GUI 규칙 편집기에서는 일반적으로 해당 매칭 필드만 입력하며 JSON 전체를 붙여 넣지 않습니다.
- 규칙 순서: 규칙은 순서대로 매칭되며 조건에 처음 일치하는 규칙이 출구를 결정합니다. 조건 범위가 넓은 기본 규칙을 앞에 두면 뒤에 있는 세부 카테고리 규칙이 적용되지 않을 수 있습니다.
- 도메인 전략:
IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 해석을 시도한 뒤 IP 매칭을 수행합니다. 모든 요청을 먼저 해석한다는 뜻도, DNS 서버 주소를 설정하는 항목도 아닙니다. - 접미사와 전체 도메인:
domain:example.com과full:example.com은 데이터베이스 카테고리가 아니라 도메인을 직접 매칭하는 방식입니다. 앞의 형식은 해당 도메인과 하위 도메인을 포함하고, 뒤의 형식은 정확히 일치하는 전체 도메인만 매칭합니다. - 카테고리 차이:
geosite:category-ads-all은 현재 데이터 소스에 해당 태그가 있을 때만 사용할 수 있습니다. 한 출처에서 지원하는 서비스 카테고리를 다른 출처에서도 지원한다고 단정하지 마세요.
다른 파일을 지정해야 하는 경우 Xray에서는 ext:custom-site.dat:cn과 같은 외부 리소스 참조를 지원합니다. 해당 파일이 코어에서 접근할 수 있는 위치에 있어야 하고 지정한 카테고리도 포함해야 합니다. 일반적인 사용 환경에서는 기본 파일명을 그대로 사용하면 되므로 데이터를 업데이트할 때 외부 파일 참조를 추가할 필요는 없습니다.
업데이트 적용 확인 및 문제 해결
‘리소스 로드 → 규칙 매칭 → 트래픽이 예상한 출구로 전달’ 순서로 확인하세요. 웹사이트가 열리는지만 보는 것은 충분하지 않습니다. 프록시와 직접 연결 모두 성공할 수 있고, 웹페이지 캐시가 라우팅 변경을 감출 수도 있습니다. 노드, DNS, 테스트 대상을 바꾸지 말고 업데이트 전후 결과를 각각 기록하는 것이 좋습니다.
| 증상 | 우선 확인할 항목 | 조치 |
|---|---|---|
| 코어 시작 실패 | 리소스 경로, 파일 내용, 카테고리 이름 | 시작 로그에서 파일명과 태그를 확인하고, 이전 리소스로 복구한 뒤 항목별로 수정 |
| 업데이트 성공 후에도 동작이 바뀌지 않음 | 실행 중인 설정, 서비스 재시작 여부, 기존 장시간 연결 | 연결 서비스를 다시 시작하고 새 요청으로 실제 출구 확인 |
| 도메인 규칙이 매칭되지 않음 | 대상 도메인의 확인 가능 여부, 카테고리 등록 여부, 앞선 규칙 | 임시로 전체 도메인 규칙을 추가해 데이터 누락인지 요청 정보 누락인지 구분 |
| IP 규칙이 매칭되지 않음 | 실제 대상 주소, 도메인 전략, 해석 결과 | 로그의 대상 IP를 확인하고 매칭 전에 도메인 해석이 필요한지 점검 |
| 로컬 네트워크 서비스가 프록시를 사용함 | 사설 주소 규칙, 규칙 순서, 로컬 네트워크 도메인 | 먼저 실제 대상 주소를 확인한 뒤 명시적인 직접 연결 규칙 설정 |
자체 테스트 환경에서 192.168.1.10:8080 서비스에 요청해 로컬 네트워크 주소가 직접 연결되는지 확인할 수 있습니다. 주소와 포트는 테스트 예시이므로 네트워크에 실제로 존재하는 서비스 정보로 바꿔야 합니다. 그런 다음 현재 도메인 카테고리에 포함된 사이트 하나와 프록시를 사용해야 하는 사이트 하나를 선택해 접속 로그의 대상과 출구 태그를 각각 확인하세요. 접속 로그가 꺼져 있다면 필요한 로그 수준으로 잠시 활성화하고, 테스트가 끝나면 불필요한 접속 기록을 장기간 저장하지 않도록 원래 설정으로 되돌립니다.
요약: 단일 규칙으로 문제를 분리해 확인하세요
잘못 라우팅되는 도메인에 전체 도메인 규칙 하나를 임시로 추가해 규칙 목록 맨 위에 배치하세요. 출구가 바뀌면 카테고리 등록 여부와 규칙 우선순위를 확인합니다. 바뀌지 않는다면 먼저 트래픽이 현재 클라이언트로 들어오는지, 올바른 설정이 실행 중인지, 코어가 도메인 정보를 받는지 확인하세요.
문제가 해결되면 임시 테스트 규칙을 삭제하고 데이터 출처, 업데이트 날짜, 사용 가능한 카테고리를 기록하세요. Geo 데이터는 주기적으로 관리하면 좋지만 연결 문제가 생길 때마다 업데이트할 필요는 없습니다. 인증 실패, 서버 연결 불가, 전송 설정 불일치는 대개 노드나 프로토콜 설정을 확인해야 하는 문제이며 지리 카테고리를 수정할 사안은 아닙니다.