V2Ray와 Xray의 라우팅 모듈은 프로토콜 연결을 수립하지 않습니다. 코어에 이미 들어온 연결 정보를 받아 대상 도메인, 대상 IP, 포트, 네트워크 유형, 인바운드 태그에 따라 어떤 아웃바운드로 보낼지 결정합니다. 구독의 VMess 또는 VLESS 노드는 “어떻게 연결할지”를 정하고, 라우팅 규칙은 “이 요청을 어느 출구로 보낼지”를 정하므로 서로 다른 계층에 속합니다.
가장 흔한 구성은 로컬 네트워크와 자주 쓰는 직접 연결 도메인을 direct로 보내고, 나머지 요청은 proxy로 보내며, 광고 도메인은 block으로 보내는 방식입니다. 규칙 자체가 노드 대역폭을 높여 주지는 않습니다. 제대로 설정하면 불필요한 프록시 트래픽을 줄이고, 사설 주소·로컬 네트워크 장치·지정 사이트가 의도한 출구를 사용하도록 할 수 있습니다.
구독을 정상적으로 가져올 수 있고 이제 분할 라우팅을 설정하려는 사용자에게 적합합니다. domain·IP·geosite의 매칭 범위, 한 규칙 안의 조합 방식, 규칙 배열의 우선순위, v2rayN에서 설정을 저장하고 검증하는 방법을 중점적으로 설명합니다.
먼저 요청이 라우팅 판단에 들어오는 과정을 이해하기
앱이 접속을 시작하면 요청은 먼저 로컬 HTTP, SOCKS 또는 TUN 인바운드로 들어옵니다. 코어는 스니핑 결과, 대상 주소와 현재 domainStrategy를 바탕으로 매칭에 사용할 정보를 수집한 뒤 routing.rules를 하나씩 확인합니다. 모든 조건을 충족하는 첫 번째 규칙이 즉시 아웃바운드를 결정하며, 뒤의 규칙은 더 이상 적용되지 않습니다.
필드 규칙은 보통 type: "field"를 사용합니다. 이 규칙에는 domain, ip, port, network, inboundTag 등의 조건을 넣고, outboundTag로 아웃바운드를 지정할 수 있습니다. 작성하지 않은 필드는 판단에 사용되지 않으며, 서로 다른 필드를 작성하면 일반적으로 모든 조건을 동시에 충족해야 합니다.
- 서로 다른 규칙: 배열 순서에 따라 위에서 아래로 확인하며, 먼저 매칭된 규칙이 적용됩니다.
- 같은 필드의 여러 값: 일반적으로 “또는” 관계입니다. 예를 들어 CIDR 두 개 중 하나만 일치해도 됩니다.
- 한 규칙의 서로 다른 필드: 일반적으로 “그리고” 관계입니다. 예를 들어 도메인과 TCP 포트를 동시에 제한할 수 있습니다.
- 일치하는 규칙이 없는 경우: 코어 설정의 기본 아웃바운드로 이동하며, 보통 아웃바운드 목록의 첫 번째 사용 가능 항목입니다.
domain·full·regexp·geosite 작성법
domain 배열에는 여러 접두사 형식을 사용할 수 있습니다. 접두사가 없는 일반 문자열은 부분 문자열 매칭을 사용하므로 예상보다 넓은 범위가 포함될 수 있습니다. domain:은 지정한 도메인과 하위 도메인을 매칭하고, full:은 완전한 도메인만 매칭합니다. regexp:는 정규 표현식을 사용하며, geosite:는 코어에 포함된 도메인 분류 데이터를 참조합니다.
domain:example.com
- 매칭
- 기본 도메인 및 하위 도메인
- 일치
- www.example.com
- 불일치
- example.com.test
사이트 전체 범위에 출구를 지정할 때 적합합니다.
full:api.example.com
- 매칭
- 완전한 도메인
- 일치
- api.example.com
- 불일치
- www.api.example.com
고정된 단일 API 도메인만 처리할 때 적합합니다.
regexp: 정규 표현식
- 매칭
- 정규식 결과
- 유연성
- 높음
- 유지 관리 비용
- 비교적 높음
일반 도메인 규칙으로 표현하기 어려울 때만 사용하세요.
geosite:cn
- 데이터 유형
- 도메인 분류
- 매칭 대상
- 도메인
- 일반적인 출구
- direct
분류 내용은 로컬 규칙 데이터 버전에 따라 달라집니다.
예를 들어 domain:example.com은 example.com과 cdn.example.com을 매칭하지만, example.com.test을 해당 도메인의 하위 도메인으로 처리하지는 않습니다. 반면 example.com을 그대로 쓰면 부분 문자열 조건이 되므로 이 문자열을 포함한 다른 도메인까지 매칭될 수 있습니다. 따라서 사용자 지정 규칙에는 접두사를 붙인 명확한 형식을 우선 사용하세요.
{
"type": "field",
"domain": [
"full:api.example.com",
"domain:static.example.com",
"geosite:category-ads-all"
],
"outboundTag": "block"
}
geosite는 domain 배열에 작성되지만 온라인 조회 서비스는 아닙니다. 코어가 로컬 도메인 분류 데이터를 읽어 분류 항목을 매칭에 사용합니다. 새 도메인이 현재 데이터 버전에 아직 포함되지 않았다면 분류 규칙 앞에 full: 또는 domain: 사용자 지정 규칙을 추가하면 되며, 분류 데이터 업데이트를 기다릴 필요가 없습니다.
| 문법 | 매칭 범위 | 적용 상황 |
|---|---|---|
키워드 |
도메인 문자열에 해당 내용이 포함됨 | 공통 문자열을 가진 도메인을 빠르게 일괄 매칭 |
domain: |
지정한 도메인과 하위 도메인 | 사이트 전체에 출구 지정 |
full: |
완전한 도메인만 | 단일 호스트명을 정확히 처리 |
regexp: |
표현식에 일치하는 도메인 | 복잡한 명명 규칙 처리 |
geosite: |
로컬 도메인 분류 집합 | 자주 쓰는 도메인 그룹에 일괄 적용 |
ip·CIDR과 domainStrategy의 조합 방법
ip 필드는 대상 IP를 매칭하며, 단일 주소와 CIDR 네트워크를 입력하거나 geoip: 분류를 참조할 수 있습니다. 자주 사용하는 geoip:private는 사설 네트워크 주소를 식별하는 데 쓰이며, 프록시 규칙보다 앞에 배치해 직접 연결로 보내면 라우터 관리 페이지, 로컬 네트워크 저장 장치, 로컬 서비스가 원격 출구로 전송되는 것을 막을 수 있습니다.
위의 300개 테스트 샘플은 도메인 100개, 사설 또는 예약 주소 100개, 공인 주소 100개로 구성됩니다. 규칙 로그를 활성화한 뒤 하나씩 연결해 기록된 아웃바운드 태그를 확인합니다. 이 테스트는 규칙 순서와 매칭 범위를 검증하기 위한 것이며 네트워크 속도를 의미하지 않습니다. 포트 값은 v2rayN에서 흔히 사용하는 기본값이므로, 로컬 설정을 변경했다면 현재 클라이언트에 표시되는 값을 기준으로 하세요.
{
"type": "field",
"ip": [
"geoip:private",
"10.20.0.0/16",
"192.168.50.10"
],
"outboundTag": "direct"
}
도메인 요청이 IP 규칙의 매칭 대상이 될 수 있는지는 domainStrategy에 따라 달라집니다. AsIs는 가능한 한 원래 도메인으로 매칭하며 IP 규칙을 위해 적극적으로 도메인을 조회하지 않습니다. IPIfNonMatch는 먼저 도메인 규칙을 확인하고, 일치하지 않을 때 IP를 조회해 IP 규칙을 계속 확인합니다. IPOnDemand는 대상 IP가 필요한 규칙을 만나면 더 이른 시점에 조회를 시작합니다.
AsIs: 조회가 적어 domain과 geosite를 주로 사용하는 설정에 적합합니다.IPIfNonMatch: 도메인을 먼저 확인한 뒤 IP를 확인하며, geosite와 geoip를 함께 사용할 때 일반적인 시작점으로 적합합니다.IPOnDemand: 더 이른 시점에 조회할 수 있어 대상 IP에 명확히 의존하는 세밀한 규칙에 적합합니다.
규칙 우선순위: 완전히 일치한 첫 번째 규칙 적용
라우팅 규칙에는 별도의 숫자 우선순위 필드가 없으며, 배열 위치가 곧 우선순위입니다. 코어는 첫 번째 규칙부터 확인하고, 어떤 규칙의 모든 조건이 충족되면 해당 규칙이 지정한 아웃바운드를 사용합니다. 범위가 넓은 규칙을 앞에 두면 뒤에 배치한 더 정확한 예외 규칙이 가려집니다.
- 가장 정확한 단일 도메인, 단일 IP와 특수 예외를 가장 앞에 배치합니다.
- 광고, 사설 주소처럼 명확한 분류 규칙은 일반적인 지역 규칙보다 앞에 둡니다.
geosite:cn,geoip:cn처럼 범위가 큰 집합은 중간에 배치합니다.- 모든 TCP, UDP 또는 나머지 요청을 처리하는 최종 대체 규칙은 마지막에 둡니다.
아래 순서는 먼저 광고 도메인을 처리하고, 사설 주소를 허용한 다음, 자주 사용하는 직접 연결 도메인과 해당 IP를 확인하고, 마지막으로 남은 TCP·UDP 트래픽을 프록시로 보냅니다. geosite:cn을 광고 규칙보다 앞에 두면 분류상 직접 연결 조건도 충족하는 광고 도메인이 먼저 direct로 들어가 뒤의 차단 규칙이 실행되지 않을 수 있습니다.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["geosite:category-ads-all"],
"outboundTag": "block"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": [
"full:intranet.example.com",
"geosite:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
한 규칙에 domain과 port를 함께 작성하면 요청이 도메인 조건과 포트 조건을 동시에 충족해야 합니다. 예를 들어 도메인은 일치하지만 대상 포트가 443이 아니면 해당 규칙은 건너뜁니다. 도메인 규칙과 포트 규칙을 각각 적용하려면 하나의 객체에 넣지 말고 독립적인 두 규칙으로 나누세요.
결론: “예외, 분류, 최종 대체” 순서로 배치
정확히 제어해야 하는 예외를 먼저 작성하고, geosite와 geoip 분류를 이어서 배치한 뒤, 마지막에 일반 프록시 규칙을 하나 남겨 두세요. 규칙을 추가할 때마다 앞의 넓은 조건에 의해 먼저 가로채이지 않는지 확인해야 합니다.
v2rayN에서 규칙 입력·저장·검증하기
v2rayN 7.x에서는 메인 창의 「설정」→「라우팅 설정」에서 라우팅 구성을 확인할 수 있습니다. 세부 버전에 따라 버튼 위치는 조금 다를 수 있지만, 핵심 작업은 라우팅 구성을 새로 만들거나 편집하고, 규칙 순서를 조정한 뒤 저장하여 현재 라우팅으로 지정하는 것입니다. 로컬 인바운드 포트를 확인하려면 「설정」→「매개변수 설정」에서 SOCKS 및 HTTP 수신 포트 값을 확인하세요.
기본 직접 연결
- domainStrategy
- IPIfNonMatch
- 도메인 분류
- geosite:cn
- IP 분류
- geoip:cn
- 아웃바운드
- direct
도메인 규칙과 IP 규칙을 함께 사용하는 시작 설정에 적합합니다.
로컬 네트워크 허용
- IP 분류
- geoip:private
- 규칙 위치
- 프록시 규칙 앞
- 아웃바운드
- direct
- 검증 대상
- 192.168.1.1
라우터 페이지와 로컬 네트워크 서비스에 접속할 때 사용합니다.
- 현재 사용 가능한 설정을 먼저 기록하고
proxy,direct,block등의 아웃바운드 태그를 확인하세요. - 「설정」→「라우팅 설정」에서 새 구성을 만들고, 현재 사용 중인 규칙을 직접 덮어쓰지 마세요.
- 먼저
geoip:private직접 연결 규칙을 추가한 뒤, 테스트할 domain, geosite 또는 CIDR 항목을 추가하세요. - 라우팅 구성을 저장하고 선택한 다음 현재 서버에 다시 연결해 코어가 새 설정을 불러오도록 합니다.
- 로그 패널을 열고 정확한 도메인 하나, 하위 도메인 하나, 로컬 네트워크 주소 하나에 각각 접속해 아웃바운드 태그를 확인하세요.
테스트할 때 웹페이지가 열리는지만 확인하지 마세요. 직접 연결과 프록시 모두 접속에 성공할 수 있습니다. 더 확실한 방법은 코어 로그에서 대상 주소와 아웃바운드 태그를 확인하거나, 테스트 도메인 규칙을 잠시 block으로 지정해 요청이 규칙에 포착되는지 확인한 뒤 원하는 출구로 되돌리는 것입니다. 임시 테스트가 끝나면 즉시 정식 설정으로 복원하세요.
자주 발생하는 오매칭과 해결 방법
라우팅 문제는 대개 프로토콜 연결 실패가 아니라 매칭 대상, 조회 전략 또는 규칙 순서가 예상과 다르기 때문에 발생합니다. 문제를 확인할 때는 먼저 노드 자체가 정상인지 확인한 다음 요청이 어느 아웃바운드로 들어갔는지 살펴보세요. VMess·VLESS 매개변수와 라우팅 규칙을 번갈아 수정하는 것은 피하는 것이 좋습니다.
domain 규칙을 작성했는데 왜 여전히 프록시로 연결되나요?
먼저 형식이 domain:example.com인지 확인한 다음, 일반 프록시 규칙보다 앞에 배치했는지 확인하세요. 저장 후 현재 서버에 다시 연결하고, 로그에서 코어가 새 라우팅 구성을 불러왔는지 확인합니다.
geosite:cn이 매칭되면 geoip:cn도 계속 확인하나요?
아니요. 현재 요청이 앞의 geosite 규칙에 완전히 매칭되어 아웃바운드가 결정되면 뒤의 geoip 규칙은 확인하지 않습니다. 도메인 규칙이 매칭되지 않고 전략상 조회가 허용될 때만 IP 판단으로 넘어갈 수 있습니다.
로컬 네트워크 주소가 프록시로 전송되면 어떻게 하나요?
일반 프록시 규칙 앞에 geoip:private를 추가하고 direct로 지정하세요. 특수한 내부 네트워크 대역을 사용한다면 10.20.0.0/16처럼 명확한 CIDR을 추가하세요.
같은 도메인이 어떤 때는 직접 연결되고 어떤 때는 프록시로 연결되는 이유는 무엇인가요?
geoip에 주로 의존하고 있는지, DNS가 서로 다른 주소를 반환하는지 확인하세요. 결과를 고정하려면 full: 또는 domain: 규칙으로 바꾸고, 정확한 규칙을 분류 규칙보다 앞에 배치하세요.
규칙을 저장했는데 아무 변화가 없어요
새 구성을 목록에 저장만 한 것이 아니라 현재 라우팅으로 선택했는지 확인한 뒤 서버에 다시 연결하세요. 로그에 존재하지 않는 아웃바운드 태그가 표시되면 규칙의 outboundTag를 수정해야 합니다.
유지 관리하기 쉬운 라우팅 구성은 세 가지 질문에 답할 수 있어야 합니다. 어떤 필드로 대상을 매칭하는가, 왜 현재 위치에 배치했는가, 매칭 후 어느 아웃바운드로 보내는가입니다. 이 세 가지를 기준으로 확인하면 domain·IP·geosite를 섞어 사용한 구성도 명확하게 유지할 수 있습니다. 문제가 생기면 첫 번째 규칙부터 순서대로 대입해 보는 것이 노드를 반복해서 바꾸는 것보다 원인을 빠르게 찾는 방법입니다.
최종 점검: 페이지 현상보다 로그 결과가 더 정확합니다
설정을 마친 뒤 정확한 도메인, 하위 도메인, 사설 IP, 공인 IP의 네 가지 대상을 최소 한 번씩 검증하고 각각 매칭된 아웃바운드 태그를 기록하세요. 네 가지 결과가 모두 예상과 일치해야 규칙 범위와 우선순위가 올바르게 설정된 것입니다.