V2Ray 라우팅 규칙 설정 실전: 중국 본토는 직접 연결하고 해외 사이트는 프록시로 보내는 방법

분할 라우팅의 핵심: 요청마다 아웃바운드 선택하기

V2Ray 라우팅은 별도의 프록시 프로토콜이 아니라 코어가 요청을 처리할 때 사용하는 조건 집합입니다. 애플리케이션 요청이 로컬 SOCKS, HTTP 또는 투명 프록시 인바운드로 들어오면 코어는 대상 도메인, 대상 IP, 포트와 네트워크 유형을 확인한 뒤 routing.rules의 위에서부터 차례로 매칭합니다. 처음 일치한 규칙이 요청에 사용할 outboundTag를 결정하며, 뒤의 규칙은 실행되지 않습니다.

일반적인 설정에는 세 가지 아웃바운드 태그를 준비합니다. proxy는 구독 노드에 연결하고, direct는 대상에 직접 접속하며, block은 연결을 거부합니다. 라우팅 규칙 자체에는 노드 주소가 저장되지 않고 VMess, VLESS 등의 노드 매개변수도 변경하지 않습니다. 이미 존재하는 아웃바운드로 트래픽을 전달할 뿐입니다. 따라서 클라이언트에서 설정을 내보낸 뒤 실제 태그 이름을 먼저 확인하고 규칙을 복사해야 합니다.

“중국 본토는 직접 연결하고 나머지는 프록시로 전송”하는 구성은 보통 세 가지 조건으로 완성됩니다. 사설 주소는 직접 연결하고, 중국 본토 도메인과 중국 본토 IP도 직접 연결하며, 남은 TCP와 UDP 요청은 프록시로 보냅니다. 마지막 규칙은 최종 폴백이므로 반드시 규칙 목록의 맨 아래에 둬야 합니다. 폴백 프록시를 앞에 배치하면 모든 요청이 즉시 매칭되어 뒤의 직접 연결 규칙은 실행되지 않습니다.

routing 설정: geosite, geoip와 최종 폴백 규칙

geosite는 도메인 분류 데이터이고, geoip는 IP 주소 대역 분류 데이터입니다. 도메인 요청은 먼저 geosite:cn으로 판단할 수 있습니다. 도메인 규칙에 일치하지 않을 때 domainStrategy를 IPIfNonMatch로 설정하면 대상 주소를 해석한 뒤 IP 규칙으로 넘겨 판단합니다. 이 방식은 도메인으로 접속하는 프로그램과 IP로 직접 접속하는 프로그램을 모두 고려할 수 있습니다.

아래 조각에는 routing 객체만 포함되어 있습니다. 기존의 전체 설정에 병합해야 하며 독립적인 설정 파일로 실행하면 안 됩니다. 광고 분류 규칙은 block 아웃바운드에 의존합니다. 현재 설정에 해당 아웃바운드가 없다면 첫 번째 규칙을 삭제하고 직접 연결 및 프록시 분할 라우팅만 남겨도 됩니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainMatcher: hybrid는 도메인 규칙 매칭에 사용됩니다. 일부 구버전 코어가 이 필드를 인식하지 못하면 해당 줄을 삭제하고 기본 매처를 사용하세요. 분류 데이터도 코어 버전에 맞아야 합니다. 로그에 데이터셋이 없다고 표시되지만 설정 철자가 올바르다면 클라이언트에서 사용하는 코어와 규칙 데이터를 업데이트해야 하며, 이 오류를 노드 장애로 판단해서는 안 됩니다.

v2rayN에 적용하기: 구독부터 사용자 지정 라우팅까지

v2rayN은 구독을 저장하고, 활성 노드를 선택하며, 코어 설정을 생성합니다. GUI에서 라우팅을 관리하면 클라이언트가 코어를 시작하기 전에 노드 아웃바운드와 규칙 세트를 조합하므로, 임시로 생성되는 config.json을 반복해서 수정하는 것보다 안정적입니다. 임시 파일은 노드 전환, 구독 업데이트 또는 클라이언트 재시작 후 다시 생성될 수 있습니다.

1. 노드 연결 확인. 구독을 업데이트하고 노드를 하나 선택한 다음 “서버 실제 연결 지연 시간 테스트”로 연결이 가능한지 먼저 확인합니다. 라우팅은 트래픽을 배분할 뿐 노드 주소, 포트 또는 인증 매개변수 문제를 해결하지 못합니다.
2. 라우팅 설정 열기. v2rayN 7.12.7에서 「설정」→「라우팅 설정」으로 이동해 규칙 세트를 새로 만들고 현재 사용할 라우팅 설정으로 지정합니다. 세부 버전에 따라 버튼 위치는 달라질 수 있지만 라우팅 메뉴 이름은 동일합니다.
3. 정확한 규칙 추가. 광고 차단, 사설 IP 직접 연결, 중국 본토 도메인 직접 연결, 중국 본토 IP 직접 연결 규칙을 순서대로 만듭니다. 아웃바운드 태그를 입력할 때는 클라이언트에 실제로 존재하는 block, direct 또는 proxy를 선택하고 노드 별칭은 입력하지 마세요.
4. 최종 프록시 규칙 추가. 네트워크 유형을 TCP와 UDP로 설정하고 아웃바운드를 proxy로 지정한 뒤 이 규칙을 맨 아래로 이동합니다. 최종 폴백이 없으면 일치하지 않은 요청이 코어의 기본 동작으로 처리되어 결과를 파악하기 어렵습니다.
5. 저장 후 코어 재시작. 규칙을 저장한 다음 서비스를 한 번 재시작하고 로그 창에서 설정이 정상적으로 로드되었는지 확인합니다. 설정 창만 닫고 재시작하지 않으면 실행 중인 코어가 계속 이전 설정을 사용할 수 있습니다.

v2rayNG와 v2flyNG도 라우팅 설정을 제공하지만 사용하는 코어 계열은 다릅니다. v2rayNG는 일반적으로 Xray 코어와 함께 사용하고, v2flyNG는 V2Fly 코어에 대응합니다. 기본적인 field, domain, ip, network 및 outboundTag 로직은 같지만 사용할 수 있는 확장 필드는 다를 수 있습니다. 클라이언트 간에 이전할 때는 기본 규칙을 먼저 유지한 뒤 코어별 기능을 하나씩 확인하세요.

규칙 우선순위: 구체적인 조건은 앞에, 포괄적인 조건은 뒤에

라우팅 규칙은 위에서 아래로 내려가며 처음 일치한 규칙을 사용하는 방식입니다. 여러 규칙을 합친 뒤 가장 적합한 결과를 다시 계산하지 않습니다. 하나의 도메인이 사용자 지정 프록시 목록과 geosite:cn에 동시에 해당한다면 어느 규칙이 앞에 있는지에 따라 최종 경로가 달라집니다. 순서는 “수동 예외, 특수 분류, 사설 주소, 지역 분류, 최종 폴백”으로 구성하는 것이 좋습니다.

특정 도메인을 항상 프록시로 보내려면 사용자 지정 규칙을 geosite:cn보다 앞에 배치해야 합니다. 도메인 매칭 방식도 다릅니다. full:은 완전한 호스트명만 매칭하고, domain:은 해당 도메인과 하위 도메인을 매칭하며, regexp:는 정규 표현식을 사용합니다. 일반적인 분할 라우팅에서는 full 또는 domain을 우선 사용하고, 패턴 판단이 꼭 필요할 때만 정규 표현식을 사용하세요.

{
  "type": "field",
  "domain": [
    "full:status.example.net",
    "domain:service.example.net"
  ],
  "outboundTag": "proxy"
}

반대로 특정 다운로드 사이트를 항상 직접 연결해야 한다면 별도의 direct 규칙을 만들고 최종 프록시 규칙보다 앞에 배치해야 합니다. 하나의 예외 때문에 전체 geosite 또는 geoip 규칙을 삭제하지 마세요. 국소적인 문제를 전체 라우팅 변경으로 확대할 수 있습니다.

DNS와 도메인 식별: 규칙이 맞아도 잘못된 경로로 가는 이유

라우팅이 도메인으로 매칭될 수 있는지는 코어가 원래 대상 도메인을 확보했는지에 달려 있습니다. 브라우저가 로컬 SOCKS5를 통해 도메인을 전달하면 코어가 geosite와 바로 매칭할 수 있습니다. 반대로 상위 계층이 이미 해석된 IP만 코어에 전달하면 도메인 규칙은 적용되지 않고 geoip에 의존해야 합니다. 투명 프록시 환경에서는 트래픽 탐색을 통해 HTTP 호스트명이나 TLS Server Name을 복원할 수도 있습니다.

• AsIs: 요청의 원래 형식 그대로 매칭합니다. 대상이 도메인이면 도메인 규칙을 확인하고, 대상이 IP뿐이면 라우팅을 위해 도메인을 임의로 해석하지 않습니다.
• IPIfNonMatch: 먼저 도메인 규칙을 시도하고, 도메인 규칙에 일치하지 않으면 IP를 해석한 뒤 IP 규칙을 확인합니다. 이 글의 지역 분할 라우팅 구조에 적합합니다.
• IPOnDemand: IP 판단이 필요한 규칙을 만나면 더 이른 시점에 해석할 수 있습니다. 규칙이 많거나 DNS 경로가 복잡하다면 테스트 환경에서 먼저 동작을 확인하세요.
• 트래픽 탐색: 인바운드의 sniffing은 HTTP 또는 TLS 트래픽에서 대상 도메인을 식별할 수 있습니다. 설정에 필요한 대상 덮어쓰기 유형만 활성화하고 코어 로그에서 식별 성공 여부를 확인하세요.

DNS 조회 자체가 어느 출구를 사용하는지도 별도의 문제입니다. 시스템 DNS가 중국 본토 도메인을 정상적으로 해석하고 프록시 노드가 다른 대상에 연결한다면 기본 분할 라우팅으로 충분한 경우가 많습니다. DNS 오염, 국내외 응답 차이 또는 UDP 조회 시간 초과가 발생하면 코어 DNS를 추가로 설정하고 DNS 서버 주소, 조회 도메인 범위, 조회 트래픽의 아웃바운드를 명확히 지정해야 합니다.

IPIfNonMatch를 사용한다고 모든 도메인이 먼저 해석되는 것은 아닙니다. 이미 geosite:cn 또는 사용자 지정 도메인 규칙에 일치한 요청은 바로 아웃바운드를 선택할 수 있습니다. 도메인 조건으로 결과가 나오지 않고 뒤에 IP 규칙이 있을 때만 해석 후 추가 판단이 필요합니다. 이것이 무조건 IP 판단에 의존하는 방식보다 일반적인 설정에 적합한 이유입니다.

로그 문제 해결: 설정 로드부터 규칙 매칭까지

분할 라우팅이 실패하면 먼저 “코어가 시작되지 않음”과 “코어는 시작했지만 잘못된 아웃바운드로 전송됨”을 구분해야 합니다. 전자는 시작 후 몇 초 안에 error 또는 failed가 나타나는 경우가 많으며, 흔한 원인은 JSON 쉼표 오류, 잘못된 필드 계층, 존재하지 않는 아웃바운드 태그와 누락된 규칙 데이터 파일입니다. 후자는 로그 수준을 높여 대상 주소와 최종 아웃바운드를 확인해야 합니다.

1. JSON 구조 확인. routing은 inbounds, outbounds와 같은 설정 루트 계층에 있어야 합니다. 조각을 복사할 때 불필요한 쉼표와 중복된 중괄호가 자주 발생합니다.
2. 태그 철자 확인. outboundTag는 문자열을 구분하므로 outbounds 배열의 tag와 완전히 일치해야 합니다. proxy 노드 별칭은 아웃바운드 태그를 대신할 수 없습니다.
3. 규칙 데이터 확인. 로그에 geosite 또는 geoip 항목을 로드할 수 없다고 표시되면 데이터 파일이 존재하는지, 현재 코어가 해당 분류 이름을 지원하는지 확인하세요.
4. 로그 수준을 임시로 높이기. loglevel을 warning에서 info로 변경하고 코어를 재시작한 뒤 중국 본토 도메인 하나와 프록시가 필요한 도메인 하나에 접속해 연결 기록을 확인합니다. 문제 해결이 끝나면 warning으로 되돌려 일상적인 로그 양을 줄일 수 있습니다.
5. 규칙 집합 줄이기. 먼저 private, cn, 최종 proxy 세 가지 기본 규칙만 남깁니다. 기본 분할 라우팅이 정상 작동한 뒤 광고 분류, 사용자 지정 도메인과 포트 규칙을 하나씩 복원하세요.

{
  "log": {
    "loglevel": "info"
  }
}

중국 본토 도메인이 계속 프록시로 전송되면 먼저 최종 proxy 규칙이 geosite 규칙보다 앞에 있는지 확인하고, 요청에 IP만 포함되어 있는지도 확인하세요. IP만 있다면 geoip:cn이 정상적으로 로드되었는지 점검합니다. 해외 서비스가 direct로 연결되면 사용자 지정 직접 연결 규칙이나 지역 데이터에 잘못 매칭되었는지 확인하고 로그로 실제 대상 도메인을 검증하세요.

UDP 요청에 문제가 생기면 현재 노드 프로토콜과 전송 설정이 UDP를 허용하는지 확인하고, 최종 폴백 규칙의 network에 udp가 포함되어 있는지도 점검하세요. tcp만 작성하면 웹페이지는 대체로 정상처럼 보이지만 UDP를 사용하는 DNS, 실시간 통신 또는 일부 네트워크 검사에서 시간 초과가 발생할 수 있습니다. 라우팅이 UDP를 허용한다고 해서 노드가 반드시 UDP를 받아들이는 것은 아니며, 양쪽 모두 지원해야 합니다.

검증 결과: 고정된 대상 목록으로 회귀 테스트하기

규칙을 저장한 뒤 웹페이지 하나만 테스트하지 마세요. 브라우저 캐시, 연결 재사용과 DNS 캐시가 이전 결과를 유지할 수 있습니다. 코어를 재시작하고 기존 연결을 닫은 다음 고정된 테스트 목록으로 LAN 주소, 중국 본토 도메인, 직접 IP, 해외 도메인, TCP와 UDP를 각각 확인하는 것이 좋습니다. 규칙을 수정할 때마다 같은 목록을 반복해야 결과를 비교할 수 있습니다.

• 라우터 관리 주소나 로컬 서비스에 접속해 geoip:private가 direct에 매칭되고 LAN 연결이 프록시로 들어가지 않는지 확인합니다.
• 자주 사용하는 중국 본토 도메인 5개를 선택하고 연결을 정리한 뒤 하나씩 접속해 로그의 아웃바운드가 direct인지 확인합니다.
• 프록시가 필요한 도메인 5개를 선택해 최종적으로 proxy에 매칭되는지 확인합니다. 포괄적인 직접 연결 규칙에 먼저 가로채여서는 안 됩니다.
• 설정의 SOCKS 포트 10808과 HTTP 포트 10809를 각각 사용해 테스트를 실행하고 애플리케이션이 이전 포트에 연결되지 않는지 확인합니다.
• UDP 요청 하나를 테스트하고 노드 측에서 해당 전달을 지원하는지 확인합니다. 실패하면 UDP 결과를 별도로 기록하고 TCP 웹 접속과 한데 묶어 판단하지 마세요.
• 구독 노드를 한 번 전환한 뒤 코어를 재시작하고 사용자 지정 라우팅이 계속 선택되어 있는지, 임시 설정이 갱신될 때 규칙이 사라지지 않는지 확인합니다.

관리하기 쉬운 기본 구성에는 보통 적은 수의 규칙만 필요합니다. 사설 주소 직접 연결, 중국 본토 도메인 직접 연결, 중국 본토 IP 직접 연결, 명확한 예외와 최종 프록시가 핵심입니다. 규칙이 많아질수록 분류 간 중복과 순서 충돌을 해결하기 어려워집니다. 새 규칙을 추가하기 전에 어떤 구체적인 목표를 해결하는지 설명하고 기존 어느 규칙보다 앞에 둘지 기록하세요.

geosite와 geoip 데이터는 네트워크 리소스 변화에 따라 업데이트되므로 지역 분류가 모든 도메인과 주소 대역을 영구적으로 포함할 수는 없습니다. 일부만 잘못 분할 라우팅되면 정확한 예외를 우선 추가하고 지역 규칙보다 위에 유지하세요. 여러 대상에서 동시에 문제가 발생할 때만 규칙 데이터 버전, 코어 호환성과 DNS 경로를 점검하면 됩니다.