노드를 가져온 뒤 라우팅을 조정하려는 데스크톱 사용자에게 적합한 글입니다. 먼저 도메인 규칙과 IP 규칙을 구분하고, 구체적인 예외를 일반 규칙보다 앞에 배치한 다음 로그에서 출구를 확인하세요. 예시는 Xray/V2Fly 라우팅 필드의 의미를 따릅니다. v2rayN GUI는 설정을 생성하는 도구이므로, 전체 코어 JSON을 단일 도메인 입력란에 붙여 넣으면 안 됩니다.
1. 라우팅 규칙은 매칭 순서부터 확인
시스템 프록시는 앱이 요청을 v2rayN에 전달할지 결정하고, 라우팅 규칙은 코어가 요청을 받은 뒤 어느 출구를 사용할지 결정합니다. 서로 다른 설정입니다. 앱이 시스템 프록시를 우회해 직접 연결하면 도메인 규칙을 바꿔도 영향을 받지 않습니다. TUN으로 트래픽을 가로채는 경우에는 요청이 실제로 코어에 전달되는지도 확인해야 합니다.
Xray/V2Fly의 일반 라우팅 규칙은 배열 순서대로 검사하며, 처음 조건을 충족한 규칙이 출구를 결정합니다. “더 정확한 규칙이 우선”하는 방식이 아니며 full:이 domain:보다 자동으로 우선하지도 않습니다. 첫 번째 규칙에서 domain:example.com을 프록시로 보내면, 뒤에 있는 full:files.example.com 직접 연결 예외는 적용되지 않습니다.
| 배치 위치 | 규칙 목적 | 출구 예시 |
|---|---|---|
| 가장 앞 | 명확한 도메인 예외 또는 차단 대상 | direct / block |
| 중간 | 서비스 도메인, 사설 IP, 지역별 집합 | proxy / direct |
| 마지막 | 나머지 TCP·UDP 요청의 기본 처리 | proxy 또는 필요에 따라 직접 연결 |
한 규칙의 domain 배열에 항목이 여러 개 있으면 보통 OR 조건으로 처리합니다. ip 배열도 마찬가지입니다. 반면 서로 다른 조건 필드는 AND 조건입니다. 예를 들어 도메인, 대상 포트, 네트워크 유형을 한 규칙에 지정하면 세 조건을 모두 충족해야 적용됩니다. 하나만 충족해도 적용되는 것은 아닙니다.
2. domain·full·regexp 작성법
도메인 규칙에는 호스트 이름만 입력하고 프로토콜, 경로, 쿼리 매개변수는 넣지 않습니다. https://api.example.com:443/v1/status에 접속할 때 도메인 조건에는 api.example.com을 입력합니다. 포트 443은 별도 조건이며, 경로 /v1/status는 이 라우팅 규칙의 매칭 대상이 아닙니다.
| 작성 형식 | 매칭 방식 | 자주 헷갈리는 점 |
|---|---|---|
domain:example.com | 기본 도메인과 하위 도메인 매칭 | api.example.com은 매칭되지만 notexample.com은 매칭되지 않습니다. |
full:api.example.com | 해당 호스트 이름 전체만 매칭 | v2.api.example.com은 매칭되지 않습니다. |
regexp:^api[0-9]+\.example\.com$ | 정규식으로 매칭 | 마침표는 이스케이프하고 앵커로 도메인 전체를 제한합니다. |
example | 유형 접두사가 없으면 일반 문자열 포함 여부로 매칭 | 도메인 접미사 매칭보다 범위가 넓어 의도하지 않은 항목까지 매칭될 수 있습니다. |
domain:은 와일드카드 표현식이 아닙니다. 도메인 전체와 하위 도메인에 적용하려면 domain:example.com을 쓰면 되며, domain:*.example.com은 사용하지 마세요. 특정 호스트 하나에만 별도 출구를 적용하려면 full:을 사용하고, 규칙적인 번호 체계의 호스트를 매칭해야 할 때만 정규식을 고려하세요.
{
"type": "field",
"domain": [
"full:files.example.com",
"regexp:^api[0-9]+\\.example\\.com$"
],
"outboundTag": "direct"
}위 내용은 코어 JSON 일부이므로 백슬래시는 \\로 씁니다. v2rayN의 일반 도메인 입력란에는 보통 백슬래시 하나를 입력합니다: regexp:^api[0-9]+\.example\.com$. JSON의 이스케이프 표기를 일반 텍스트 입력란에 그대로 붙여 넣으면 정규식 의미가 달라질 수 있습니다. 먼저 입력 위치가 JSON 편집기인지 규칙 필드인지 확인하세요.
요점: full로 시작해 범위를 넓히세요
새 서비스 예외를 추가할 때는 먼저 full: 호스트 하나로 출구를 확인하세요. 적용되는 것을 확인한 뒤 domain:으로 범위를 넓히고, 패턴 매칭이 꼭 필요할 때만 regexp:를 사용하면 잘못된 라우팅의 원인을 찾기 쉽습니다.
3. ip·CIDR·geoip의 범위
IP 조건은 ip 필드에 지정하며, 단일 주소·CIDR 대역·geoip: 집합을 주로 사용합니다. 여기서 매칭하는 대상은 목적지 IP입니다. 출발 장치의 사설 네트워크 주소를 목적지 규칙에 잘못 입력하지 마세요. 출발지 기준 라우팅은 다른 조건을 사용하며 목적지 IP 필드로 대체할 수 없습니다.
{
"type": "field",
"ip": [
"192.168.50.0/24",
"203.0.113.10/32",
"2001:db8::10/128",
"geoip:private"
],
"outboundTag": "direct"
}192.168.50.0/24는 해당 IPv4 서브넷을 포함합니다. 203.0.113.10과 2001:db8::10은 문서용 예시 주소이며 실제로 연결할 수 있는 노드가 아닙니다. 실제 설정에는 라우팅할 목적지 대역을 입력하세요. 사설 네트워크를 직접 연결하려면 명확한 대역을 먼저 지정하고, 필요에 따라 geoip:private를 추가하세요.
geoip:cn은 불러온 IP 데이터 집합을 기준으로 판단하고, geoip:private는 해당 데이터 집합에서 정의한 사설 또는 로컬 주소 범위에 사용합니다. 데이터 파일이 바뀌면 집합의 내용도 달라지므로, 특정 집합 규칙을 영구적으로 정확한 지역 판정으로 간주해서는 안 됩니다. 특히 CDN, 지역 간 서비스, 새로 할당된 대역에는 별도 예외가 필요할 수 있습니다.
- 목적지가 도메인일 때 IP 규칙까지 매칭될지는 코어가 목적지 주소를 얻는지, 그리고 라우팅 해석 정책이 어떻게 설정되어 있는지에 따라 달라집니다.
- 목적지가 이미 IP라면 IP 규칙을 적용하기 위해 도메인을 다시 해석할 필요가 없습니다.
- 하나의 서비스가 IPv4와 IPv6를 함께 사용할 수 있습니다. IPv4 규칙만 추가하면 IPv6 연결은 포함되지 않습니다.
- 모든 사설 네트워크 목적지를 직접 연결하기 전에 해당 네트워크의 접근 요구 사항을 확인하세요. 직접 연결은 이 기기의 방화벽을 우회한다는 뜻이 아닙니다.
4. geosite 데이터 집합과 DNS 정책
geosite:cn은 도메인 집합이고 geoip:cn은 IP 집합이므로 서로 바꿔 쓸 수 없습니다. 전자는 “해석된 주소가 반드시 중국 본토에 있다”는 뜻이 아니며, 후자도 “이 도메인이 중국 본토 서비스에 속한다”는 뜻이 아닙니다. 서비스 분류에는 도메인 집합을, 주소 분류에는 IP 집합을 사용하면 판단을 더 명확하게 할 수 있습니다.
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
}기존 Xray/V2Fly 설정에서 이 집합을 참조하려면 코어가 해당 데이터 파일을 찾을 수 있어야 합니다. 일반적인 파일 이름은 geosite.dat와 geoip.dat입니다. 집합 이름은 실제로 불러온 데이터 내용을 기준으로 합니다. 문서에 나온 이름만 보고 기기에 해당 분류가 있다고 단정하지 마세요. 데이터가 없거나 해당 태그가 없으면 설정을 불러오지 못할 수 있습니다.
| domainStrategy | 라우팅 해석 동작 | 주요 확인 사항 |
|---|---|---|
AsIs | 라우팅 단계에서 IP 규칙 매칭을 위해 도메인을 먼저 해석하지 않음 | 도메인 요청이 IP 집합에 매칭되지 않아도 규칙 문법이 잘못된 것은 아닐 수 있음 |
IPIfNonMatch | 도메인 단계에서 규칙이 매칭되지 않으면 도메인을 해석한 뒤 다시 매칭 | 앞에서 일반 규칙이 먼저 적용되면 추가 매칭이 진행되지 않을 수 있음 |
IPOnDemand | 매칭에 목적지 IP가 필요한 경우 도메인을 해석 | DNS가 작동하는지, 해석 결과가 예상과 일치하는지 확인 |
특히 IPIfNonMatch와 기본 규칙의 관계에 유의하세요. 첫 번째 도메인 검사에서 마지막 규칙인 network: tcp,udp가 프록시 출구에 이미 매칭되면, 앞의 geoip:cn이 매칭되지 않았더라도 자동으로 다시 검사하지 않습니다. IP 집합을 기준으로 라우팅하려면 해석 정책과 기본 출구를 함께 설계해야 합니다. IP 규칙 하나만 추가해서는 충분하지 않습니다.
5. 프록시·직접 연결·차단 설정 예시
아래 설정은 먼저 특정 호스트를 차단하고, 파일 호스트는 직접 연결한 다음 같은 도메인의 나머지 요청은 프록시로 보냅니다. 사설 네트워크 목적지는 직접 연결하고, 나머지 TCP·UDP 요청은 프록시를 사용합니다. 도메인 목적지도 IP 조건에 매칭되도록 IPOnDemand를 선택했습니다. 사용하기 전에 코어의 DNS 설정이 작동하는지 확인하세요.
{
"routing": {
"domainStrategy": "IPOnDemand",
"rules": [
{
"type": "field",
"domain": ["full:telemetry.example.com"],
"outboundTag": "block"
},
{
"type": "field",
"domain": ["full:files.example.com"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"ip": ["192.168.50.0/24", "geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}이것은 routing 설정 일부이며 전체 노드 설정이 아닙니다. proxy·direct·block은 실제 outbounds의 tag와 일치해야 합니다. 태그는 이름일 뿐이며 그 자체로 출구를 만들지 않습니다. 직접 연결은 보통 freedom 아웃바운드, 차단은 blackhole 아웃바운드에 연결하고, 프록시 출구에는 기존 노드를 사용합니다.
구체적인 예외를 우선 배치
권장단일 호스트와 명확한 네트워크 대역을 일반 분류보다 앞에 두면 변경 범위를 확인하기 쉽습니다. 예외를 추가할 때는 그 위에 먼저 매칭되는 규칙이 있는지 확인하면 됩니다.
적합한 경우: 기존에 일상적인 라우팅을 사용하며 몇 가지 서비스 예외만 추가하려는 경우
프록시 기본 처리
직접 연결 또는 차단 규칙에 해당하지 않는 요청을 프록시로 보냅니다. 적용 범위가 명확하지만 프록시 노드가 더 많은 요청을 처리해야 하므로 내부망 목적지는 미리 제외해야 합니다.
적합한 경우: 대부분의 외부 서비스에 프록시가 필요하고 직접 연결 목록을 관리할 수 있는 경우
직접 연결 기본 처리
명시한 서비스만 프록시로 보내고 나머지는 직접 연결합니다. 새 서비스나 누락된 도메인이 자동으로 프록시를 사용하지 않으므로 목록을 계속 관리해야 합니다.
적합한 경우: 프록시 대상이 적고 안정적이며 나머지 접속은 주로 직접 연결하는 경우
라우팅 규칙이 하나도 매칭되지 않으면 Xray/V2Fly는 보통 아웃바운드 목록의 첫 번째 출구를 사용합니다. 이를 “반드시 직접 연결된다”고 해석하면 안 됩니다. v2rayN이 설정을 생성할 때 아웃바운드 순서를 바꿀 수 있으므로 실제 설정을 확인하거나 현재 해석 정책에 맞는 명시적 기본 규칙으로 의도를 표현하세요.
6. v2rayN에서 규칙 추가 및 확인
작업 전에 현재 라우팅을 백업하세요. 아래 설명은 「설정」→「라우팅 설정」 메뉴가 있는 v2rayN 데스크톱 화면을 기준으로 합니다. 플랫폼별 화면이나 클래식 인터페이스에서는 버튼 위치가 다를 수 있습니다. 라우팅 프로필 하나를 편집한 뒤 메인 화면의 라우팅 선택 메뉴에서 활성화하세요. 규칙을 저장하고도 해당 프로필을 선택하지 않아 적용되지 않는 경우가 흔합니다.
-
프로필 백업
「설정」→「라우팅 설정」으로 이동해 현재 프로필과 규칙 순서를 먼저 내보내거나 기록하세요. 기존 프로필은 보존하고 테스트용 프로필을 새로 만들어 일상적인 라우팅을 한 번에 망가뜨리지 않도록 합니다.
-
규칙 열기
「라우팅 설정」에서 편집할 프로필을 선택한 다음 규칙 편집 창을 엽니다. 규칙을 추가할 때는 먼저 출구를 선택하고 도메인 필드에
full:files.example.com을 입력하세요. 전체 JSON을 붙여 넣으면 안 됩니다. -
순서 조정
명확한 호스트 예외를
domain:example.com같은 포괄적인 규칙보다 앞에 배치하세요. 도메인 필드와 IP 필드는 별도 규칙으로 만듭니다. 항목이 여러 개라면 화면에 표시된 구분 방식을 따르고, 쉼표로 자동 분리된다고 임의로 가정하지 마세요. -
프로필 활성화
저장한 뒤 메인 화면의 라우팅 선택 메뉴로 돌아가 방금 편집한 프로필을 선택하세요. 코어가 설정을 다시 불러왔는지 확인합니다. 로그에 설정 오류가 표시되면 규칙을 더 추가하지 말고 먼저 백업을 복원하세요.
-
출구 확인
예시 도메인을 테스트 권한이 있는 실제 호스트로 바꾸고 새 연결을 만든 뒤 코어 로그를 확인하세요. 액세스 로그를 사용한다면 목적지와 아웃바운드 태그가 맞는지 확인합니다. 웹페이지가 열리는 것만으로 직접 연결 여부를 판단하면 안 됩니다.
라우팅은 일반적으로 연결을 만들 때 결정됩니다. 브라우저에 이미 열린 연결은 기존 출구를 계속 사용할 수 있습니다. 규칙을 저장한 뒤에는 테스트 사이트의 연결을 닫거나 테스트 앱을 다시 시작하고 재접속하세요. 기존 페이지를 한 번 새로 고친 뒤 규칙이 실패했다고 판단하지 마세요. 로그에 해당 요청이 없다면 정규식을 다시 작성하기보다 시스템 프록시, 앱 프록시, TUN 가로채기부터 확인하세요.
- 먼저 문법 확인: 접두사 표기, 정규식 이스케이프, 집합 이름, 출구 태그를 확인하고 코어가 정상적으로 시작되는지 살펴보세요.
- 다음으로 대상 확인: 실제 요청의 호스트 이름을 확인하세요. 웹사이트 기본 도메인, 로그인 도메인, 다운로드 도메인은 서로 다를 수 있습니다.
- 마지막으로 순서 확인: 첫 번째 규칙부터 살펴보며 처음으로 매칭될 가능성이 있는 규칙을 찾으세요. 특히 포괄적인 도메인 집합과 기본 규칙을 확인해야 합니다.
7. 사용자 지정 라우팅 자주 묻는 질문
full 규칙을 넣었는데 왜 여전히 프록시로 연결되나요?
먼저 「설정」→「라우팅 설정」에서 현재 활성화된 프로필을 확인한 다음, 정확한 매칭 규칙을 포괄적인 도메인 규칙보다 앞에 배치하세요. 기존 연결을 닫고 다시 테스트하면서 요청이 다른 다운로드 또는 로그인 호스트 이름을 사용하지 않는지도 확인하세요.
geosite:cn과 geoip:cn을 모두 설정해야 하나요?
둘을 무조건 함께 추가할 필요는 없습니다. 두 종류의 조건이 모두 필요하면 규칙을 나눠 하나에는 도메인 집합을, 다른 하나에는 IP 집합을 지정하세요. 도메인 요청이 IP 집합에 매칭되려면 라우팅 해석 정책도 확인해야 합니다.
특정 HTTPS 경로만 직접 연결할 수 있나요?
여기서 설명한 도메인 규칙은 암호화된 요청의 URL 경로별로 라우팅할 수 없습니다. 전체 호스트 이름을 기준으로 라우팅하거나, 필요한 경우 목적지 포트 443을 규칙에 추가할 수 있습니다. 그래도 같은 호스트의 서로 다른 경로를 구분할 수는 없습니다.
geosite를 추가한 뒤 코어가 시작되지 않는 이유는 무엇인가요?
먼저 시작 로그에 데이터 파일이 없거나 집합을 찾을 수 없다는 메시지가 있는지 확인하세요. 클라이언트의 라우팅 데이터 업데이트 기능으로 데이터를 관리한 다음 현재 코어의 데이터 경로를 확인합니다. 임시로 full: 규칙으로 바꿔 설정을 점검하고, 집합 이름을 무작위로 바꾸지 마세요.
구독을 업데이트하면 사용자 지정 규칙도 바뀌나요?
노드 구독과 라우팅 프로필은 별도 설정이지만 노드·코어·라우팅 프리셋을 전환하면 생성되는 설정이 달라질 수 있습니다. 업데이트 후 현재 라우팅 프로필과 출구 태그를 확인하세요. 노드 구독 링크를 도메인 규칙 필드에 붙여 넣으면 안 됩니다.
라우팅 문제는 “요청이 코어에 전달됨 → 목적지 정보 확인 가능 → 처음 매칭된 규칙 확인 → 해당 출구 존재 여부” 순서로 점검하세요. 도메인 표기는 대상을 지정하고, 해석 정책은 IP 정보를 보완하며, 규칙 순서는 우선순위를 결정합니다. 한 번에 한 곳만 수정하고 복구 가능한 프로필을 보존하면 프리셋 전체를 반복해서 바꾸는 것보다 문제를 찾기 쉽습니다.