노드를 연결할 수 있고 트래픽 분할을 세밀하게 조정하려는 사용자를 위한 글입니다. 먼저 도메인 항목과 IP 필드를 구분한 뒤, 세 가지 규칙 예시로 첫 일치 규칙, 필드 조합, DNS 조회의 관계를 살펴봅니다. 마지막으로 v2rayN에서 필요할 때 되돌릴 수 있는 사용자 지정 구성을 저장하는 방법을 알아봅니다. 예시는 문법 설명용 예약 도메인을 사용하며, 해당 도메인 접속을 네트워크 테스트로 간주하지 않습니다.
먼저 구분하기: 도메인 접두사와 IP 필드
Xray의 routing.rules는 순서가 있는 규칙 배열입니다. 각 규칙은 어떤 연결을 어떤 아웃바운드로 보낼지 지정합니다. domain, ip, port는 일치 조건이고, outboundTag는 이미 정의된 아웃바운드를 가리킵니다. 여기서 말하는 라우팅은 구독 노드 목록의 순서를 바꾸는 것이 아니며, VMess 또는 VLESS 노드의 인증 매개변수도 수정하지 않습니다.
| 방식 | 입력 위치 | 일치 범위 |
|---|---|---|
full:api.example.com | domain 배열 | 해당 도메인과 정확히 일치하며 하위 도메인은 포함하지 않습니다. |
domain:example.com | domain 배열 | 루트 도메인과 하위 도메인에 일치합니다. 예를 들어 www.example.com은 일치하지만 notexample.com은 일치하지 않습니다. |
regexp:^api[0-9]+\.example\.com$ | domain 배열 | 정규식에 맞는 도메인에 일치합니다. 예: api12.example.com |
geosite:cn | domain 배열 | 현재 도메인 데이터베이스의 분류를 참조하며, 실제 범위는 사용하는 파일에 따라 달라집니다. |
192.168.0.0/16 | ip 배열 | 이 IPv4 대역과 일치합니다. 앞에 ip:를 붙이지 마세요. |
geoip:private | ip 배열 | IP 데이터베이스의 사설 주소 집합을 참조하며, 해당 데이터가 있어야 합니다. |
혼동하기 쉬운 부분은 ‘ip 접두사’입니다. 여기서 ip는 JSON 필드명이지, domain:과 짝을 이루는 범용 도메인 항목 접두사가 아닙니다. 도메인 목록에 ip:192.168.1.1을 입력해도 대상 IP를 매칭할 수 없습니다. 접두사 없는 도메인 문자열은 보통 부분 문자열로 매칭되므로, example.com의 범위는 명확한 domain:example.com보다 넓습니다.
일치 범위에 맞는 방식 선택
특정 API만 프록시로 보내는 데 보통 정규식은 필요하지 않습니다. 사이트 전체와 하위 도메인을 같은 방식으로 처리할 때도 호스트명을 하나씩 나열할 필요가 없습니다. 먼저 범위가 명확한 방식을 쓰면 나중에 문제를 해결할 때 혼란을 줄일 수 있습니다.
도메인 범위를 명확히 지정
권장단일 호스트에는 full:을, 루트 도메인과 하위 도메인에는 domain:을 사용하세요. 두 방식 모두 규칙을 하나씩 확인하기 쉬워 직접 규칙을 작성할 때 좋은 출발점입니다.
적합한 경우: 특정 사이트의 라우팅을 수정하거나 특정 API에 예외를 설정할 때
분류 집합 참조
여러 도메인을 묶을 때 geosite:를 사용하세요. 분류명은 임의로 붙이는 태그가 아니며, 현재 사용하는 데이터베이스에 실제로 있어야 합니다. 데이터 업데이트에 따라 포함 항목이 바뀔 수도 있습니다.
적합한 경우: 지역 또는 서비스별 분류를 관리하고, 소수의 개별 도메인으로 예외를 추가할 때
정규식으로 패턴 지정
번호가 붙은 호스트처럼 일정한 패턴에는 regexp:를 사용하세요. Xray의 정규식 문법은 브라우저 정규식 기능과 완전히 같지 않으므로, 전방·후방 탐색이나 역참조가 포함된 표현식을 그대로 가져오면 안 됩니다.
적합한 경우: 여러 호스트명이 일정한 규칙을 따르고, 일치·불일치 테스트 사례를 준비할 수 있을 때
정규식은 입력 형식을 구분해야 합니다. 그래픽 인터페이스의 일반 텍스트 도메인 입력란에는 보통 regexp:^api[0-9]+\.example\.com$을 입력합니다. JSON 문자열로 작성할 때는 아래와 같이 백슬래시를 한 번 더 이스케이프해야 합니다. 앞의 ^와 끝의 $는 도메인 전체를 대상으로 제한해 더 긴 문자열이 잘못 매칭되는 것을 방지합니다.
{
"type": "field",
"domain": [
"regexp:^api[0-9]+\\.example\\.com$"
],
"outboundTag": "proxy"
}규칙 순서: 예외를 먼저, 집합은 나중에
규칙은 위에서 아래로 확인하며, 조건에 처음 일치한 규칙의 아웃바운드가 선택됩니다. 이후에 더 ‘정확한’ 규칙이 있어도 계속 검색하지 않습니다. full:이 앞에 있는 domain:보다 자동으로 우선하는 것은 아니며, 분류 항목도 배열 순서와 별개인 우선순위가 없습니다.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["full:api.example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["192.168.0.0/16"],
"outboundTag": "direct"
}
]
}
}이 코드는 라우팅 조각이며 전체 클라이언트 구성이 아니므로, 구성 전체로 가져오면 안 됩니다. 기존 구성에 proxy와 direct 아웃바운드가 정의되어 있어야 합니다. 도메인 대상의 경우 api.example.com은 첫 번째 규칙에, www.example.com은 두 번째 규칙에 일치합니다. IP로 직접 연결하는 대상인 192.168.1.20은 세 번째 규칙에 일치합니다.
- 앞의 두 규칙을 바꾸면: API 도메인이 도메인 전체 집합에 먼저 포함되어, 뒤에 있는 정확한 예외 규칙은 적용되지 않습니다.
- 한 배열에 여러 값 지정:
domain에 있는 항목 중 하나라도 일치하면 됩니다. 같은 아웃바운드를 사용할 도메인 몇 개를 하나로 묶을 때 적합합니다. - 한 규칙에 여러 조건 지정: 예를 들어
domain과port를 함께 입력하면, 둘 중 하나가 아니라 보통 두 조건을 모두 충족해야 합니다. - 어떤 규칙에도 일치하지 않으면: 보통 구성에서 첫 번째 아웃바운드가 사용되며, 반드시 직결인 것은 아닙니다. 클라이언트가 생성한 기본 대체 규칙도 확인하세요.
정리: 예외를 먼저 옮기고 분류를 확장하세요
특정 도메인이 잘못된 아웃바운드로 연결되면, 먼저 해당 도메인의 정확한 규칙을 포괄적인 집합 규칙보다 앞에 배치한 뒤 로그를 확인하세요. 중복 분류를 추가하면 기존 규칙이 가려지는 문제만 늘어날 수 있습니다.
IP 대역과 DNS 정책은 어떻게 연동될까
IP 규칙은 대상 주소에 적용되며, 컴퓨터의 현재 공인 IP에는 적용되지 않습니다. 클라이언트가 도메인을 받았을 때 먼저 DNS 조회를 하고 그 결과를 라우팅에 사용할지는 domainStrategy에 따라 달라집니다. 이 설정만으로 DNS 구성이 모두 정해지는 것은 아닙니다. 어떤 리졸버를 사용할지, DNS 요청을 어떻게 보낼지는 DNS 및 관련 라우팅 설정을 확인해야 합니다.
| 정책 값 | 처리 방식 | 확인할 사항 |
|---|---|---|
AsIs | 라우팅 단계에서 도메인을 IP로 변환하지 않습니다. | 도메인이 규칙에 일치하지 않으면 IP 규칙이 자동으로 대신 적용되지 않습니다. 처음부터 IP인 대상은 계속 매칭할 수 있습니다. |
IPIfNonMatch | 도메인이 현재 조건으로 규칙에 일치하지 않으면 DNS 조회 후 다시 매칭을 시도합니다. | 앞에서 포괄적인 도메인 규칙이 이미 일치했다면 더 적합한 IP 규칙을 찾기 위해 다시 선택하지 않습니다. |
IPOnDemand | 매칭 과정에서 IP가 필요한 규칙을 만나면 필요한 DNS 조회를 수행합니다. | IP 규칙의 위치에 따라 조회 시점이 달라집니다. 포괄적인 IP 규칙을 너무 앞에 두면 도메인 예외의 결과가 바뀔 수 있습니다. |
예를 들어 사무실 기기 192.168.1.20의 관리 페이지를 직결하려면 IP 필드에 192.168.1.20/32를 입력하면 됩니다. 사설 주소 대역 전체를 추가할 필요는 없습니다. 도메인으로 페이지에 접속한다면 연결이 코어에 도메인으로 전달되는지 IP로 전달되는지도 확인하세요. 애플리케이션의 프록시 방식, DNS 캐시, 스니핑 설정에 따라 확인 가능한 대상 정보가 달라질 수 있습니다.
v2rayN에서 되돌릴 수 있는 규칙 만들기
아래 단계는 중국어 데스크톱 인터페이스에서 흔히 볼 수 있는 메뉴를 기준으로 합니다. 버전에 따라 편집 기능이 버튼이나 마우스 오른쪽 메뉴에 있을 수 있으니, 먼저 ‘라우팅 설정’과 현재 활성화된 구성을 확인하세요. 라우팅 조각을 노드의 서버 주소, 구독 링크 또는 전송 매개변수에 붙여 넣으면 안 됩니다.
-
코어 확인
‘설정’ → ‘매개변수 설정’을 열고 현재 노드 프로토콜에 해당하는 코어가 Xray인지 확인합니다. 버전에서 코어 매핑을 별도 설정 페이지에 표시한다면 해당 페이지에서 확인하세요. 먼저 노드 자체가 연결되는지 확인해야 합니다.
-
구성 백업
‘설정’ → ‘라우팅 설정’으로 이동해 현재 사용하는 라우팅 구성을 기록하고, 인터페이스의 내보내기 또는 복사 기능으로 사본을 보관합니다. 사용자 지정 규칙이 이미 있다면 수정 전에 순서도 저장하세요.
-
예외 추가
사용할 구성에서 규칙을 추가합니다. 도메인에는
full:api.example.com을 입력하고, 아웃바운드는 프록시를 선택합니다. 필요하지 않은 조건은 비워 두세요. 그래픽 양식에는 각 필드의 값만 입력하고 JSON 전체를 붙여 넣지 마세요. -
순서 조정
도메인이
domain:example.com이고 아웃바운드가 직결인 규칙을 추가합니다. 인터페이스의 이동 기능을 사용해 정확한 예외를 사이트 전체 규칙보다 앞에 배치하세요. 더 앞에 있는 분류 규칙이 예외를 덮는지도 확인합니다. -
활성화 및 확인
구성을 저장하고 현재 라우팅으로 설정한 다음, 인터페이스 안내에 따라 서비스를 다시 불러오거나 재시작합니다. 예시 도메인을 실제로 제어할 수 있는 대상으로 바꾼 뒤 기존 연결을 닫고 새 요청을 보냅니다. 문제가 생기면 백업 구성으로 되돌려 변경 사항을 확인하세요.
확인할 때는 한 번에 조건 하나만 바꾸세요. 프록시를 사용해야 하는 도메인 하나, 직결해야 하는 도메인 하나, 로컬 네트워크 IP 하나를 선택해 각각 새 연결을 만들고 시각과 대상을 기록합니다. 규칙을 수정해도 이미 열린 장기 연결이 즉시 다른 아웃바운드로 옮겨가지는 않습니다. 브라우저가 기존 연결을 재사용하면 ‘저장이 적용되지 않은 것처럼’ 보일 수 있습니다.
- 코어 로그 확인: 기본 창의 로그 영역에서 새 연결의 대상과 아웃바운드 정보를 확인합니다. 기본 로그에 규칙 번호가 매번 표시되는 것은 아니므로, 필요하면 테스트 중에만 로그 상세 수준을 높이고 테스트 후 원래대로 되돌리세요.
- 요청이 코어에 전달되는지 확인: 시스템 프록시를 사용하는 경우 애플리케이션이 실제로 시스템 프록시를 따라야 합니다. 코어를 완전히 우회하는 연결에는 이 라우팅 규칙이 적용되지 않습니다.
- 생성된 구성 확인: 사용 중인 버전에 실행 구성 보기 또는 내보내기 기능이 있다면
routing.rules의 순서와 실제 아웃바운드 태그를 확인하세요. 편집기에서 보이는 순서만으로 최종 결과를 판단하면 안 됩니다.
자주 묻는 질문: 규칙을 제대로 썼는데 왜 적용되지 않을까?
full을 사용했는데 왜 직결될까요?
먼저 앞에 있는 domain:, geosite: 또는 다른 포괄 규칙이 이미 일치하는지 확인하고, 실제 연결에 사용된 호스트명도 확인하세요. 웹페이지와 API, 이미지, 로그인 서비스가 서로 다른 도메인을 사용할 수 있으므로 메인 페이지에만 예외를 추가하면 모든 요청이 처리되지 않을 수 있습니다.
geosite 분류를 추가한 뒤 코어가 시작되지 않으면 어떻게 해야 하나요?
로그에서 파일 로드 오류나 분류가 없다는 메시지를 확인하고, 현재 데이터 파일에 해당 분류가 포함되어 있는지와 코어가 실제로 읽는 위치를 점검하세요. 먼저 새 항목을 제거해 연결을 복구한 뒤 클라이언트의 규칙 데이터 업데이트 기능을 사용하세요. 분류명만 보고 존재 여부를 추측해서는 안 됩니다.
도메인과 IP는 각각 매칭되는데 함께 넣으면 안 되는 이유는 무엇인가요?
한 규칙에 여러 조건을 넣으면 보통 모든 조건을 동시에 충족해야 합니다. ‘이 도메인이나 이 대역은 모두 직결’하려는 목적이라면 규칙 두 개로 나누세요. 같은 대상에만 적용하려는 것이라면 DNS 정책과 코어가 실제로 받은 주소도 확인해야 합니다.
정규식 테스트는 통과했는데 JSON에 붙여 넣으면 오류가 나는 이유는 무엇인가요?
먼저 백슬래시 이스케이프를 확인하세요. JSON에서 마침표 문자 하나를 매칭하려면 보통 \\.으로 쓰고, 일반 텍스트 입력란에서는 \.으로 씁니다. 그런 다음 현재 정규식 엔진에서 지원하지 않는 문법을 제거하고, 일치해야 하는 도메인과 일치하면 안 되는 도메인을 각각 하나씩 테스트하세요.
안정적인 사용자 지정 라우팅은 소수의 정확한 예외, 명확한 집합 규칙, 이해하기 쉬운 기본 동작으로 구성됩니다. 규칙을 수정할 때마다 ‘대상, 규칙 위치, 예상 아웃바운드, 실제 아웃바운드’를 기록하면 비슷한 항목을 계속 쌓는 것보다 관리하기 쉽습니다. 데이터베이스를 업데이트한 뒤에는 이전에 예외 처리가 필요했던 도메인도 다시 확인하세요.