노드를 통해 인터넷에 연결할 수 있고 분할 라우팅 규칙을 수정하려는 v2rayN 사용자를 위한 글입니다. Xray 코어의 라우팅 필드를 기준으로 도메인과 IP 입력 위치를 구분하고, 직접 연결·프록시·차단 규칙의 배치 예시를 소개합니다. 설정과 로그, 개별 요청을 통해 규칙이 적용됐는지 확인하는 방법도 알아봅니다.
1. 라우팅 진입 경로와 실제 코어 확인하기
v2rayN은 설정을 관리하는 클라이언트이며, 실제 연결을 매칭하는 것은 실행 중인 코어입니다. 이 글의 routing.rules, domainStrategy, outboundTag는 Xray 설정 문법을 기준으로 설명합니다. 설정 형식이 다르면 메뉴 이름이 비슷하다는 이유만으로 같은 JSON을 그대로 붙여 넣어서는 안 됩니다.
데스크톱에서 「설정」→「라우팅 설정」을 열고 수정할 라우팅 설정을 선택한 다음 규칙 목록으로 이동해 편집합니다. 버전에 따라 행을 더블클릭하거나 마우스 오른쪽 버튼 메뉴에서 편집을 시작할 수 있습니다. 현재 화면에 도메인, IP, 포트, 아웃바운드 필드가 있는지 확인하세요. 저장한 뒤에는 메인 화면의 「라우팅」 선택 메뉴에서 이 설정을 활성화해야 합니다. 새 설정을 추가하기만 하고 전환하지 않으면 적용되지 않습니다.
- 현재 설정 기록: 라우팅 이름, 활성 노드, 코어 종류를 적어 두고 정상 작동하는 기존 설정을 보관합니다.
- 설정 복사: 복사본에서 규칙을 수정해 평소 사용하는 설정을 바로 덮어쓰지 않도록 합니다.
- 아웃바운드 확인: 직접 연결·프록시·차단에 연결된 실제 태그를 확인합니다. 아래 예시에서는
direct,proxy,block을 사용합니다. - 변경 사항 적용: 저장한 뒤 라우팅을 활성화하고, 코어 로그에 시작 실패나 설정 파싱 오류가 나타나는지 확인합니다.
2. 매칭 순서: 먼저 일치한 규칙의 아웃바운드가 결정됩니다
일반적인 필드 기반 라우팅 규칙은 목록 위에서 아래로 검사하며, 조건에 처음으로 맞는 규칙의 아웃바운드를 사용합니다. '정확한 도메인이 도메인 집합보다 자동으로 우선한다'는 규칙은 없습니다. 아래에 full:을 적어도 위의 포괄적인 규칙이 먼저 일치하면 아래 규칙을 다시 검토하지 않습니다.
같은 필드 안의 여러 값은 보통 '또는'으로 처리되고, 서로 다른 조건 필드는 '그리고'로 결합됩니다. 예를 들어 도메인 목록에 항목이 두 개 있으면 그중 하나와 일치하면 됩니다. 같은 규칙에 포트 443도 입력했다면 도메인과 대상 포트 조건을 모두 충족해야 합니다. domain과 ip를 한 규칙에 함께 넣어도 '도메인 또는 IP 중 하나만 일치하면 된다'는 뜻은 아닙니다.
이 값들은 프로토콜 포트와 주소 범위이며 속도 측정 결과가 아닙니다. 라우팅의 port는 대상 포트를 의미하며 로컬 프록시 수신 포트가 아닙니다. 브라우저가 로컬 프록시에 연결한 뒤 HTTPS 사이트에 접속한다면 규칙은 보통 원격 대상의 443을 확인해야 합니다. 브라우저가 로컬 프록시에 연결할 때 사용하는 포트가 아닙니다.
요점: 예외 규칙은 포괄적인 규칙보다 위에 배치
특정 도메인만 프록시로 연결하려면 해당 도메인의 정확한 프록시 규칙을 이를 덮어쓸 수 있는 직접 연결 규칙보다 위로 옮긴 뒤 새 연결로 테스트하세요. 접두어만 바꾸고 위치를 그대로 두면 위 규칙에 먼저 걸리는 문제를 해결할 수 없습니다.
3. domain, full, regexp, geosite 작성 방법
이 접두어는 도메인 필드에 사용합니다. https://, 경로, 쿼리 문자열, 포트는 입력하지 않습니다. 브라우저 주소 https://api.example.com/account에서 도메인은 api.example.com입니다. 라우팅 도메인 규칙은 웹페이지 경로를 기준으로 트래픽을 나누지 않습니다.
| 작성 방식 | 매칭 방식 | 사용 시 유의점 |
|---|---|---|
domain:example.com | example.com과 그 하위 도메인에 매칭 | 도메인 전체에 적용할 때 적합하며 notexample.com에는 매칭되지 않음 |
full:api.example.com | 이 도메인 전체 이름에만 매칭 | 다른 하위 도메인에는 적용되지 않음 |
regexp:^api[0-9]+\.example\.com$ | 정규식으로 api1, api20 등의 도메인에 매칭 | 시작·끝 앵커, 이스케이프, 코어 정규식 문법에 유의 |
geosite:cn | 도메인 데이터 파일의 cn 집합 참조 | 집합에 포함되는 항목은 실제로 불러온 데이터 파일에 따라 다름 |
example.com | 접두어가 없으면 일반 문자열 포함 방식으로 매칭 | 도메인 접미사 매칭보다 범위가 넓으므로 정확한 매칭 용도로는 부적합 |
domain:은 서비스와 하위 도메인을 한꺼번에 같은 아웃바운드로 연결할 때 적합하고, full:은 개별 엔드포인트에 예외를 지정할 때 적합합니다. 접두어 없이 문자열만 쓰면 example.com.other.test 같은 도메인도 매칭될 수 있습니다. 일반적인 설정에서는 경계가 명확한 접두어를 우선 사용하세요.
{
"type": "field",
"domain": [
"full:api.example.com",
"domain:example.net",
"regexp:^api[0-9]+\\.example\\.org$"
],
"outboundTag": "proxy"
}여기서 세 도메인 조건은 '또는'으로 처리됩니다. 코드는 JSON이므로 정규식의 역슬래시 하나를 두 개로 적어야 합니다. v2rayN 도메인 텍스트 입력란에 규칙을 직접 입력할 때는 보통 regexp:^api[0-9]+\.example\.org$와 같이 쓰며, JSON 문자열용 이스케이프를 추가할 필요는 없습니다. 정규식은 코어가 지원하는 문법을 따라야 하며 브라우저의 모든 정규식 기능을 그대로 사용할 수는 없습니다.
- geosite는 도메인 집합입니다:
geosite:cn은 '서버가 중국에 있다'고 실시간 판별하는 기능이 아니며,.cn으로 끝나는 모든 도메인을 뜻하지도 않습니다. - 집합 이름은 데이터 파일에 따라 달라집니다: 온라인 예시의 분류가 로컬 데이터에 항상 포함되는 것은 아닙니다. 목록을 찾을 수 없다는 오류가 나타나면 데이터 출처와 실제 분류 이름을 확인하세요.
- 데이터 업데이트에 따라 매칭 범위가 달라질 수 있습니다: 규칙 문구를 바꾸지 않아도 도메인 데이터를 업데이트하면 매칭 결과가 바뀔 수 있습니다. 이상 동작을 조사할 때는 데이터 업데이트 시점도 기록하세요.
4. ip 필드, CIDR, geoip의 차이
ip는 규칙의 필드 이름이지 주소 앞에 붙여 쓰는 접두어가 아닙니다. GUI의 IP 입력란에는 단일 주소, CIDR 대역 또는 geoip: 집합을 입력할 수 있습니다. 예를 들어 192.168.0.0/16으로 입력하며 ip:192.168.0.0/16으로 입력하지 않습니다. IPv6 주소도 IP 필드에 입력합니다.
{
"type": "field",
"ip": [
"10.0.0.0/8",
"172.16.0.0/12",
"192.168.0.0/16",
"fc00::/7"
],
"outboundTag": "direct"
}이 규칙은 흔히 쓰이는 사설 주소 대역을 포함하지만 모든 로컬·링크 로컬·예약 주소를 망라하지는 않습니다. geoip:private를 사용하려면 로컬 IP 데이터 파일에 해당 집합이 있는지, 어떤 범위를 포함하는지 확인하세요. LAN 서비스에 접속할 때는 요청이 실제로 프록시 코어에 전달되는지도 확인해야 합니다. 시스템 프록시 우회 대상인 연결은 해당 라우팅의 매칭 기록에 남지 않습니다.
| IP 항목 | 의미 | 점검할 부분 |
|---|---|---|
192.168.1.10 | 단일 IPv4 주소 | 기기 주소가 바뀌면 규칙도 수정해야 함 |
192.168.0.0/16 | 해당 IPv4 대역에 매칭 | 대역이 넓을수록 더 많은 대상에 영향 |
geoip:cn | 데이터 파일의 IP 집합을 기준으로 매칭 | 도메인 소유자나 서비스 운영자를 판별하는 기능이 아님 |
geoip:private | private 주소 집합 참조 | 실제 데이터 파일에 해당 집합이 있는지 확인 |
같은 웹사이트에서도 CDN 주소를 여러 개 사용할 수 있고, DNS 응답은 네트워크에 따라 달라질 수 있습니다. 한 번 조회한 단일 IP로 사이트 전체의 라우팅을 설정하면 도메인 규칙보다 불안정한 경우가 많습니다. 앱이 IP에 직접 접속하거나 고정된 사설 기기 또는 명확한 대역을 지정해야 할 때 IP 항목을 우선 고려하세요.
5. 도메인 해석 전략에 따라 IP 규칙의 적용 시점이 달라집니다
요청에 도메인이 포함된 경우, 코어가 먼저 IP를 조회한 뒤 IP 항목을 라우팅 판단에 사용할지는 routing.domainStrategy 등의 설정으로 결정됩니다. 이 설정은 '최종 연결에서 어떤 DNS를 사용하는가', '트래픽 스니핑을 켰는가'와는 별개의 문제입니다. 스위치 하나만 켜면 모든 문제가 해결된다고 생각해서는 안 됩니다.
| 전략 값 | 라우팅 단계에서의 동작 | 사용 시 유의점 |
|---|---|---|
AsIs | 라우팅 매칭을 위해 도메인을 IP로 조회하지 않음 | 처음부터 IP를 대상으로 한 요청은 IP 규칙에 매칭될 수 있음 |
IPIfNonMatch | 도메인 규칙에 매칭되지 않으면 조회를 시도한 뒤 다시 매칭 | 포괄적인 도메인 규칙이 있으면 요청의 매칭이 먼저 끝날 수 있음 |
IPOnDemand | 매칭 도중 IP 판별이 필요한 조건을 만나면 주소를 조회 | 앞에 있는 IP 규칙이 뒤의 도메인 규칙보다 먼저 매칭될 수 있음 |
예를 들어 '모든 TCP·UDP 트래픽을 프록시로 보낸다'는 규칙을 목록 끝에 두더라도 IPIfNonMatch에서는 구체적인 도메인 항목과 일치하지 않은 요청이 네트워크 기본 규칙에 먼저 매칭될 수 있습니다. 이미 규칙이 매칭되면 이후에 자동으로 IP를 조회해 geoip:cn 규칙을 적용할 것이라고 기대할 수 없습니다. '중국 본토 IP를 직접 연결하도록 설정했는데 적용되지 않는 것 같다'는 문제의 흔한 원인입니다.
- 도메인 규칙을 우선하는 경우: 명확한 도메인 예외와 집합을 먼저 배치해 불필요한 IP 조회가 매칭에 개입하지 않도록 합니다.
- IP 분류에 의존하는 경우: 현재 조회 전략과 DNS 작동 여부, 앞선 규칙의 매칭 여부를 확인합니다.
- 앱이 IP만 전달하는 경우: 도메인 규칙의 매칭 근거가 부족할 수 있습니다. 스니핑으로 도메인을 보완할 수 있는지는 프로토콜과 설정에 따라 다르며 모든 연결을 지원하지는 않습니다.
6. 직접 연결·프록시·차단 규칙 배치 예시
흔히 '명확한 예외를 앞에, 포괄적인 집합을 뒤에, 최종 기본 규칙은 마지막에' 배치합니다. 다만 차단과 예외 중 무엇을 우선할지는 실제 의도에 따라 정해야 합니다. 특정 도메인을 반드시 차단해야 한다면 이를 허용할 수 있는 규칙 위에 차단 규칙을 둡니다. 차단 집합에 포함된 사이트 하나를 허용해야 한다면 해당 집합보다 앞에 정확한 허용 규칙을 둡니다.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["full:blocked.example.org"],
"outboundTag": "block"
},
{
"type": "field",
"domain": ["full:api.example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"ip": ["10.0.0.0/8", "192.168.0.0/16"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}예시의 도메인은 문법 설명용이며 실제 노드나 테스트 서비스가 아닙니다. 설정에는 해당 아웃바운드 태그가 정의되어 있어야 합니다. direct는 직접 연결 아웃바운드, block은 차단 아웃바운드, proxy는 실제 프록시 아웃바운드를 가리킵니다. 태그는 참조 이름일 뿐이며 proxy라는 문자열을 쓴다고 노드가 자동으로 생성되지는 않습니다.
- 명확한 차단: 반드시 거부해야 하는 정확한 대상을 먼저 처리합니다.
- 도메인 예외: 특정 엔드포인트나 사이트의 아웃바운드를 지정해 뒤에 있는 집합 규칙에 덮어쓰이지 않도록 합니다.
- 사설 IP: IP로 접속하는 내부망 대상을 처리합니다. 이 예시는 AsIs를 사용하므로 도메인을 IP로 조회해 이 규칙에 매칭하지 않습니다.
- 집합 직접 연결: 실제 geosite 데이터에 따라 나머지 도메인에 매칭합니다.
- 최종 프록시: 아직 매칭되지 않은 TCP·UDP 트래픽을 프록시로 보냅니다.
어떤 규칙에도 매칭되지 않으면 Xray는 일반적으로 설정의 첫 번째 아웃바운드를 사용합니다. 이 암묵적인 동작을 '기본적으로 항상 프록시를 사용한다'고 생각해서는 안 됩니다. 클라이언트가 생성하는 설정에서는 아웃바운드 순서가 다를 수 있습니다. 기본 규칙을 명시하면 읽기 쉽지만, 앞서 설명한 조회 전략의 영향도 함께 고려해야 합니다.
7. 규칙이 적용되지 않을 때 확인하는 방법과 자주 묻는 질문
먼저 세 가지 상황을 구분하세요. 요청이 코어에 전달되지 않은 경우, 코어에 전달됐지만 잘못된 규칙에 매칭된 경우, 올바른 아웃바운드를 선택했지만 연결에 실패한 경우입니다. 첫 번째는 시스템 프록시와 앱 설정을 확인합니다. 두 번째는 규칙 순서와 매칭 필드를 확인합니다. 세 번째는 노드, DNS, 대상 연결 상태를 확인합니다. 라우팅이 올바르다고 해서 프록시 노드까지 정상 작동한다는 뜻은 아닙니다.
- 한 가지만 변경: 실제 사용하는 도메인을 하나 골라
full:규칙을 추가하고, 이를 덮어쓸 수 있는 규칙보다 앞에 배치합니다. - 새 연결로 테스트: 라우팅을 저장하고 활성화한 뒤 기존 페이지나 앱 연결을 종료하고 요청을 다시 보냅니다. 이미 열린 장기 연결은 규칙을 수정해도 자동으로 경로가 다시 선택되지 않습니다.
- 로그 확인: v2rayN 로그 영역에서 대상, 오류, 아웃바운드 태그를 확인합니다. 필요한 경우 로그 수준을 일시적으로 높이세요. 일반 액세스 로그에는 매칭된 규칙의 행 번호가 표시되지 않을 수 있습니다.
- 생성된 설정 확인: 현재 코어가 실제로 불러온 설정에 새 항목이 포함되어 있고 태그 이름이 outbounds와 일치하는지 확인합니다. 클라이언트가 다시 생성할 임시 설정을 장기간 직접 수정하지 마세요.
- 설정 복구: 원인을 확인한 뒤 임시 테스트 규칙을 취소하고 로그 수준을 원래대로 복구해 불필요한 접속 정보가 기록되지 않도록 합니다.
domain:example.com을 추가했는데 왜 API는 여전히 직접 연결되나요?
먼저 위쪽에 있는 직접 연결 규칙이 이미 매칭됐는지, API의 실제 도메인이 example.com에 속하는지 확인하세요. 해당 API의 full: 프록시 규칙을 관련 직접 연결 규칙보다 앞에 임시로 옮긴 다음 저장하고 새 연결을 만드세요. 현재 활성화된 라우팅이 방금 편집한 설정인지도 확인해야 합니다.
geosite:cn을 저장한 뒤 코어가 시작되지 않습니다. 어디가 잘못됐나요?
코어 로그에서 구체적인 오류를 확인하세요. 데이터 파일이나 목록이 없다는 메시지가 나오면 실제로 사용하는 geosite 데이터 파일과 집합 이름을 확인합니다. JSON 파싱 오류라면 쉼표, 따옴표, 정규식 이스케이프를 확인하세요. 먼저 새 항목을 되돌려 연결을 복구한 뒤 하나씩 수정합니다.
도메인과 IP를 모두 입력했는데 왜 매칭이 줄었나요?
한 규칙 안에 서로 다른 조건 필드를 입력하면 모두 충족해야 합니다. 원래 의도가 '도메인이 일치하거나 IP가 특정 대역에 속하는 경우'라면 규칙을 두 개로 나누고 같은 아웃바운드를 지정하세요. 두 조건을 한 행에 넣고 선택 조건처럼 취급하지 마세요.
프록시로 바꿨는데도 웹페이지가 열리지 않습니다. 라우팅이 적용되지 않은 건가요?
먼저 액세스 로그에서 프록시 아웃바운드가 선택됐는지 확인합니다. 선택됐다면 현재 노드의 연결 오류, 도메인 조회, 대상 서비스 상태를 점검하세요. 로그에 해당 요청이 없다면 앱이 시스템 프록시를 따르는지 확인합니다. 웹페이지가 열리는지만 보고 규칙 매칭 여부를 판단하지 마세요.
문제 해결 기록을 저장할 때는 규칙 순서, 대상 유형, 아웃바운드 태그, 오류 정보만 남기면 됩니다. 스크린샷이나 설정을 공유하기 전에 구독 주소, 노드 인증 정보, 불필요한 접속 도메인을 가리세요. 규칙을 여러 개 한꺼번에 추가하는 것보다 명확한 매칭 결과 하나를 재현하는 편이 원인을 찾기 쉽습니다.