노드에 연결할 수 있고 직접 연결과 프록시 적용 범위를 조정하려는 사용자를 위한 안내입니다. 먼저 도메인과 IP 매칭 구문을 살펴보고, ‘세부 예외 → 분류 규칙 → 최종 기본 경로’ 순으로 규칙을 배치한 뒤 도메인 해석 전략과 실제 아웃바운드를 확인합니다. 예시는 V2Fly V2Ray와 Xray에서 흔히 사용하는 field 라우팅 구조를 따릅니다. 클라이언트 편집 화면은 커널 설정 전체를 보여 주지 않으므로 저장 후 생성된 설정도 확인해야 합니다.
라우팅 규칙 기초: 매칭 조건과 아웃바운드 태그
라우팅은 연결을 어떤 아웃바운드로 보낼지 결정합니다. 노드를 만들거나 노드에서 사용하는 VMess·VLESS 프로토콜을 바꾸지는 않습니다. V2Ray는 커널 프로젝트이고 Xray는 별도의 커널 프로젝트입니다. v2rayN은 데스크톱 그래픽 클라이언트로, 화면에서 설정한 값을 선택한 커널이 읽을 수 있는 형식으로 변환합니다.
일반적인 규칙에는 type: "field", 매칭 조건, outboundTag가 포함됩니다. 태그는 outbounds에 이미 정의된 tag와 일치해야 합니다. 이 글에서는 프록시, 직접 연결, 차단 아웃바운드를 각각 proxy, direct, block이라고 부릅니다. 이는 예시 이름일 뿐이므로 모든 클라이언트 설정에서 같은 태그를 사용한다고 가정하면 안 됩니다.
- 같은 필드 안에서는 보통 ‘또는’으로 판정합니다:
domain배열의 도메인 조건 중 하나라도 일치하면 해당 필드가 충족됩니다. - 서로 다른 필드 사이는 ‘그리고’로 판정합니다: 한 규칙에
domain과port를 함께 지정하면 도메인과 대상 포트가 모두 일치해야 합니다. - domain과 ip는 둘 중 하나를 고르는 조건이 아닙니다: 두 필드를 한 규칙에 함께 넣으면 둘 다 일치해야 합니다. ‘도메인 또는 IP’를 뜻하려면 규칙을 두 개로 나누세요.
- 포트는 대상 포트입니다:
port: "443"은 원격 서비스 포트와 매칭하며, 로컬 프록시의 수신 포트와는 다릅니다.
이 값은 예시이며 속도 측정 결과나 클라이언트 기본값을 보장하지 않습니다. 실제 수신 포트는 로컬 설정에서 확인하세요. HTTPS는 다른 포트에서도 사용할 수 있으므로 443만으로 암호화 트래픽 전체를 판단할 수 없습니다.
domain 매칭 방식 4가지: 부분 문자열·정규식·루트 도메인·정확한 도메인
domain 필드와 domain: 접두사는 이름이 비슷해 혼동하기 쉽지만 서로 다릅니다. 전자는 규칙 필드이고, 후자는 필드 안 문자열의 매칭 방식입니다. 자주 쓰는 네 가지 표현 중 일반 문자열에는 접두사가 없으며 나머지 세 가지는 regexp:, domain:, full:을 사용합니다. 형식을 맞추려고 일반 문자열에 접두사를 붙이지 마세요.
| 표기 | 매칭 범위 | 사용 시 참고 |
|---|---|---|
example.com | 도메인에 해당 문자열이 포함됨 | notexample.com도 매칭될 수 있어 루트 도메인 매칭보다 범위가 넓습니다 |
domain:example.com | example.com 및 하위 도메인 | www.example.com은 매칭되지만 notexample.com은 매칭되지 않음 |
full:api.example.com | 정확히 api.example.com만 | cdn.api.example.com은 포함되지 않음 |
regexp:^api[0-9]+\.example\.com$ | 정규식과 일치하는 전체 문자열 | JSON에서는 백슬래시를 한 번 더 이스케이프해야 함 |
사이트 단위로 라우팅할 때는 보통 domain:을 사용하세요. 특정 API 하나만 예외로 지정하려면 full:을 쓰면 됩니다. 도메인 조건에는 도메인만 입력하고 https://, 웹페이지 경로, 쿼리 매개변수는 넣지 마세요. 라우팅 규칙은 특정 페이지의 문서 경로를 기준으로 트래픽을 나누지 않습니다.
{
"type": "field",
"domain": [
"full:api.example.com",
"domain:example.org",
"regexp:^api[0-9]+\\.example\\.com$"
],
"outboundTag": "proxy"
}이 정규식은 api12.example.com과 매칭됩니다. 앞의 ^와 뒤의 $는 문자열의 시작과 끝을 지정하고, 점 앞의 백슬래시는 점 문자를 그대로 나타냅니다. 도메인은 구문 설명용 예시이므로 실제 설정에서는 라우팅할 서비스 도메인으로 바꾸세요.
ip·geoip·geosite: 주소 범위와 데이터 파일
ip 필드에는 단일 주소, CIDR 네트워크 또는 geoip: 참조를 지정할 수 있습니다. 192.168.1.10/32는 IPv4 주소 하나만 포함하고, 192.168.1.0/24는 해당 네트워크 범위를 포함합니다. IPv6 단일 주소에는 /128을 사용할 수 있습니다. 이 필드는 대상 주소를 매칭하며 요청의 출발지를 매칭하려면 해당하는 다른 필드를 사용해야 합니다.
{
"type": "field",
"ip": [
"192.168.1.0/24",
"geoip:private"
],
"outboundTag": "direct"
}geoip:private는 데이터 파일의 사설 주소 분류를 참조하고, geoip:cn은 중국 IP 분류를 참조합니다. 실시간 위치 조회 기능은 아니며 실제 범위는 로드한 geoip.dat에 따라 달라집니다. 네트워크 할당 정보와 데이터 갱신 시점에 따라 결과가 달라질 수 있으므로 분류에 포함됐다는 사실만으로 서버의 물리적 위치를 판단하면 안 됩니다.
- geosite는 domain에 지정합니다: 예를 들어
"domain": ["geosite:cn"]은 도메인 분류를 읽으며 IP 분류를 읽지 않습니다. - geoip는 ip에 지정합니다: 예를 들어
"ip": ["geoip:cn"]은 주소 범위를 읽으며 웹페이지의 도메인 문자열을 매칭하지 않습니다. - 분류가 데이터에 포함되어 있어야 합니다:
geosite:category-ads-all은 일부 데이터 세트에서 제공하는 광고 분류로, 모든 데이터 파일에 들어 있는 것은 아닙니다. - 속성 필터는 데이터에 따라 달라집니다:
geosite:geolocation-!cn및@가 포함된 분류 표기는 현재 파일에 해당 분류나 속성이 있는지 확인해야 합니다. 이름만 보고 의미를 추측하지 마세요.
규칙 적용 우선순위: 먼저 일치하는 규칙에서 종료
규칙은 rules 배열의 위에서 아래 순서로 검사합니다. 조건에 맞는 첫 규칙이 발견되면 연결은 해당 아웃바운드로 전달됩니다. ‘정확한 도메인이 geosite보다 원래 우선한다’거나 ‘IP 규칙이 도메인 규칙보다 원래 우선한다’는 정렬 방식은 없습니다. 앞에 있는 포괄적인 규칙이 구체적인 규칙을 가로막을 수도 있습니다.
- 세부 예외를 먼저 배치: 특정 도메인 하나를 프록시로 보내려면 해당
full:규칙을 앞에 둡니다. - 서비스 분류는 그다음: 프록시 또는 차단할 도메인 분류와 일반 직접 연결 분류를 이어서 배치합니다.
- IP 규칙은 목적에 맞게 배치: 보통 로컬 네트워크 주소는 직접 연결하지만 도메인 규칙과의 순서는 해석 전략에 따라 달라집니다.
- 기본 경로는 마지막에: 일치하는 규칙이 없으면 보통
outbounds배열의 첫 번째 아웃바운드를 사용합니다. 결과를 명시하려면 마지막에 대상 포트 범위를 포괄하는 규칙을 추가하세요.
아래는 routing 설정 예시이며 그대로 실행할 수 있는 완전한 파일은 아닙니다. proxy, direct, block 세 아웃바운드가 이미 정의되어 있고, 참조하는 분류가 데이터 파일에 포함되어 있어야 합니다. 실제 태그 이름이 클라이언트가 생성한 이름과 다르면 먼저 태그를 바꾸세요.
{
"routing": {
"domainStrategy": "IPOnDemand",
"rules": [
{
"type": "field",
"domain": ["full:api.example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:category-ads-all"],
"outboundTag": "block"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"port": "1-65535",
"outboundTag": "proxy"
}
]
}
}이 예시는 정확한 도메인 예외를 먼저 처리한 다음 사설 주소를 처리합니다. IPOnDemand를 사용하므로 앞에 있는 IP 규칙을 확인하는 과정에서 도메인이 해석될 수 있습니다. 광고 분류를 사설 주소 규칙 뒤에 두면 사설 주소 매칭이 우선됩니다. 업무상 차단 분류를 먼저 적용해야 한다면 순서를 조정해야 하며, 커널이 규칙의 중요도를 자동으로 판단할 것이라고 기대하면 안 됩니다.
domainStrategy: 도메인을 언제 해석해 매칭에 사용할까
라우팅의 domainStrategy는 라우팅 판정을 보조하기 위해 도메인을 IP로 해석할지 결정합니다. DNS 서버 설정이나 직접 연결 아웃바운드의 같은 이름 옵션과는 다릅니다. 연결에 처음 전달되는 값이 도메인인지 IP인지에 따라서도 사용할 수 있는 조건이 달라집니다.
AsIs
권장라우팅 단계에서 도메인을 IP로 변환하지 않습니다. 도메인 대상은 주로 domain, geosite 등의 규칙으로 매칭하며, 대상이 처음부터 IP라면 IP 규칙을 사용할 수 있습니다. 동작을 명확하게 파악할 수 있는 도메인 라우팅 기준을 처음 세울 때 적합합니다.
적합한 경우: 도메인 규칙이 중심일 때, 처음으로 매칭 순서를 점검할 때
IPIfNonMatch
도메인이 첫 번째 검사에서 어떤 규칙에도 매칭되지 않으면 해석을 시도한 뒤 다시 매칭합니다. 앞에 일치 가능한 포트 기본 규칙이 있으면 첫 검사에서 바로 종료되어 해석 후 매칭까지 진행하지 않을 수 있습니다.
적합한 경우: 도메인 규칙이 매칭되지 않은 뒤 IP 분류로 판정할 때
IPOnDemand
규칙을 확인하다 IP 판정이 필요한 조건에 도달하면 필요에 따라 도메인을 해석합니다. 앞쪽의 IP 규칙이 이후 도메인 분류의 검사 여부에 영향을 줄 수 있으므로 DNS 동작과 규칙 순서를 함께 설계해야 합니다.
적합한 경우: 도메인 대상 라우팅에 IP 분류를 반드시 적용해야 할 때
요점: 먼저 해석 시점을 정한 뒤 기본 경로를 배치하세요
IPIfNonMatch를 선택했다면 첫 검사에서 항상 일치하는 일반 포트 기본 규칙을 두고 이후 geoip 규칙이 적용되길 기대하지 마세요. 첫 번째 아웃바운드를 기본 경로로 사용하거나 전략을 다시 배치할 수 있습니다. 최종 기본 경로 전에 IP 판정이 필요하다면 IPOnDemand와 실제 DNS 설정을 함께 검토하세요.
앱이 IP에 직접 연결하면 커널은 처음부터 domain 매칭에 사용할 도메인을 받지 못합니다. 지원되는 트래픽에서는 스니핑으로 도메인을 알아낼 수 있지만 모든 프로토콜에서 가능한 것은 아니며 도메인을 완전히 복원하는 기능도 아닙니다. DNS 쿼리가 어디서 나가는지는 커널 DNS, 아웃바운드, 클라이언트 모드도 확인해야 합니다. 라우팅 전략만 바꿔서는 알 수 없습니다.
v2rayN 설정 순서: 수정 후 실제 설정 확인
v2rayN의 라우팅 편집 화면은 버전에 따라 달라질 수 있습니다. 데스크톱 버전에서는 보통 ‘설정’ → ‘라우팅 설정’으로 이동합니다. 화면 구성이 다르면 먼저 ‘도움말’ → ‘정보’에서 버전을 확인하고 해당 버전의 화면을 기준으로 설정하세요. 커널 JSON 전체를 도메인 목록만 입력할 수 있는 칸에 붙여 넣으면 안 됩니다.
-
현재 설정 기록
‘도움말’ → ‘정보’에서 클라이언트 버전을 기록하고, ‘설정’ → ‘매개변수 설정’에서 사용 중인 커널과 로컬 수신 포트를 확인합니다. 기존 라우팅 설정을 백업하고, 전체 프록시로 바로 전환한 것이 아니라 사용자 지정 라우팅 모드를 사용 중인지 확인하세요.
-
예외 추가
‘설정’ → ‘라우팅 설정’으로 이동해 현재 사용 중인 규칙 집합을 편집합니다. 먼저 실제 서비스 도메인의
full:조건을 추가하고 대상 아웃바운드를 선택한 뒤, 포괄적인 분류 규칙보다 앞에 배치합니다. -
전략 확인
라우팅 설정에서
domainStrategy를 확인하고 도메인 배열, IP 배열, 아웃바운드 태그도 점검합니다. 분류 규칙을 사용한다면 현재 커널이 해당 geosite·geoip 데이터 파일을 불러올 수 있는지 확인하세요. -
재시작 후 검증
수정한 규칙 집합을 저장하고 활성화한 뒤 현재 커널 연결을 재시작합니다. 실제 생성된 설정에서 규칙 순서를 확인하고 새로운 요청을 보내 로그를 살펴보세요. 이미 연결된 세션은 규칙을 바꿔도 아웃바운드가 다시 선택되지 않는 경우가 많습니다.
안드로이드에서 v2rayNG는 Xray 커널을, v2flyNG는 V2Fly 커널을 사용합니다. 기본 규칙 형식이 비슷해도 클라이언트에서 편집할 수 있는 필드, 가져오기 메뉴, 데이터 파일 관리 방식은 다를 수 있습니다. 이전할 때는 필드 지원 여부를 확인하고 데스크톱 클라이언트의 설정 파일 전체를 범용 커널 설정으로 취급하지 마세요.
라우팅이 적용되지 않을 때: 요청 경로·데이터·로그 확인
‘웹사이트가 열린다’는 것은 연결에 성공했다는 뜻일 뿐, 올바른 아웃바운드를 사용했다는 증거는 아닙니다. 검증할 때는 정확한 도메인 하나, 로컬 네트워크 대상 하나, 분류에 포함된 대상 하나를 골라 각각 새 연결을 시작하세요. 먼저 트래픽이 커널에 들어오는지 확인하고, 다음으로 매칭된 규칙과 아웃바운드 태그를 살펴본 뒤 DNS와 분류 범위를 점검합니다.
| 증상 | 우선 확인할 항목 | 해결 방법 |
|---|---|---|
| 정확한 도메인 예외가 여전히 직접 연결됨 | 앞에서 geosite 또는 포트 규칙이 이미 매칭되는지 | 해당 full 규칙을 관련 포괄 규칙보다 앞에 옮기고 새 연결을 시작합니다 |
| 도메인 대상에 geoip 규칙이 적용되지 않음 | AsIs 또는 IPIfNonMatch의 도메인 해석 조건 | 전략을 확인하고 첫 검사에서 기본 규칙이 먼저 매칭되는지 점검합니다 |
| 시작 직후 오류가 발생함 | JSON, 분류 이름, 데이터 파일, 아웃바운드 태그 | 추가한 분류 참조를 먼저 제거하고 full 규칙 하나만 남겨 문제 범위를 좁힙니다 |
| 브라우저와 명령줄의 결과가 다름 | 같은 프록시 진입점을 사용하는지, 로컬에서 도메인을 해석하는지 | 같은 SOCKS 진입점을 명시해 도메인 요청과 IP 요청을 비교합니다 |
| 규칙을 바꿔도 결과가 달라지지 않음 | 활성 규칙 집합, 커널 재시작, 연결 재사용 여부 | 수정한 규칙 집합이 활성화됐는지 확인하고 기존 연결을 닫은 뒤 테스트합니다 |
로컬에 SOCKS 인바운드가 제공되고 수신 포트가 예시와 같이 10808이라면 아래 명령을 사용할 수 있습니다. socks5h를 지정하면 curl이 도메인을 로컬에서 먼저 해석하지 않고 프록시 서버로 전달합니다. 테스트 진입점 차이를 줄이는 데 도움이 되지만, 커널이 자체 DNS 설정에 따라 도메인을 다시 해석하지 않는다는 뜻은 아닙니다.
curl --proxy socks5h://127.0.0.1:10808 --head https://example.com/- 먼저 요청 경로를 확인하세요: 커널에 도달하지 않은 요청에는 라우팅 규칙이 적용되지 않습니다. 시스템 프록시 설정을 모든 프로그램이 따르는 것도 아닙니다.
- 다음으로 로그를 확인하세요: 필요한 경우 잠시 액세스 로그를 켜거나 로그 상세도를 높여 대상 주소, 인바운드, 아웃바운드 태그를 살펴보세요. 점검이 끝나면 평소 로그 수준으로 되돌립니다.
- 마지막으로 규칙을 단순화하세요: 도메인 조건 하나와 명시적인 아웃바운드 하나만 남겨 확인합니다. 성공하면 분류와 IP 조건을 하나씩 되돌려 여러 변수를 동시에 바꾸지 않도록 합니다.
로그를 공유하기 전에는 구독 주소, 노드 인증 정보, 서비스 도메인 등 민감한 정보를 가리세요. 클라이언트·커널·아웃바운드의 차이는 용어집에서 확인할 수 있습니다. 연결 진입점부터 설정을 다시 점검하려면 빠른 시작을 참고하세요.