V2Ray 사용자 지정 라우팅 규칙 문법 완벽 가이드: domain·ip·geosite 매칭 순서

라우팅 처리 흐름과 첫 매칭 원칙

V2Ray과 Xray의 라우팅 모듈은 노드 연결을 직접 생성하지 않습니다. 요청이 코어에 들어오면 대상 도메인, 대상 IP, 포트, 네트워크 유형, 인바운드 태그 등을 바탕으로 아웃바운드를 선택합니다. 최종 선택은 보통 outboundTag가 지정하는 아웃바운드로 결정되며, 예를 들어 proxy, direct, block 등이 있습니다.

규칙은 routing.rules 배열에 저장되며, 코어는 첫 번째 규칙부터 아래로 확인합니다. 특정 규칙의 모든 조건을 만족하면 검색이 즉시 중단되고, 뒤의 규칙은 해당 요청에 적용되지 않습니다. 따라서 구체적인 규칙을 앞에, 포괄적인 규칙을 뒤에 배치하는 것이 안정적인 설정의 기본입니다.

같은 규칙 안의 서로 다른 필드는 일반적으로 '그리고' 관계입니다. 예를 들어 한 규칙에 domain과 port를 함께 작성했다면 대상이 도메인 조건과 포트 조건을 모두 만족해야 합니다. 한 필드 안의 여러 항목은 보통 '또는' 관계입니다. 예를 들어 domain 배열에 도메인 세 개를 나열하면 그중 하나만 매칭되어도 해당 필드가 충족됩니다.

domain: 정확한 도메인, 하위 도메인 및 키워드 매칭

domain 필드는 대상 호스트명을 처리합니다. 자주 사용하는 접두사는 full:, domain:, keyword:, regexp:, geosite:입니다. 접두사에 따라 매칭 범위가 달라지므로 잘못 선택하면 규칙이 지나치게 넓게 적용되거나 전혀 매칭되지 않을 수 있습니다.

full:example.com은 완전한 호스트명 example.com만 매칭하며 www.example.com을 같은 대상으로 취급하지 않습니다. 반면 domain:example.com은 해당 도메인과 하위 도메인을 모두 매칭하므로 같은 사이트 체계를 동일한 아웃바운드로 처리할 때 적합합니다.

{
  "type": "field",
  "domain": [
    "full:api.example.com",
    "domain:static.example.net",
    "keyword:media",
    "regexp:^cdn-[0-9]+\\.example\\.org$"
  ],
  "outboundTag": "proxy"
}

• full: 로그인 API나 업데이트 API처럼 호스트명이 명확한 대상에 적합하며, 매칭 범위가 가장 좁습니다.
• domain: 주 도메인과 모든 하위 도메인에 적합해 일상적인 규칙에서 더 자주 사용됩니다.
• keyword: 대상 도메인에 지정한 문자열이 포함되면 매칭될 수 있으므로, 짧은 키워드는 무관한 도메인까지 잘못 매칭할 수 있습니다.
• regexp: 구조는 일정하지만 번호가 바뀌는 도메인에 적합하며, 표현식이 복잡할수록 유지 관리 비용이 커집니다.
• geosite: 미리 정리된 도메인 분류 집합을 참조하며, 서비스 유형이나 지역별로 대량 라우팅할 때 적합합니다.

정확한 도메인을 분류 규칙의 예외로 지정해야 한다면 정확한 규칙을 앞에 배치합니다. 예를 들어 먼저 full:download.example.com을 직접 연결로 보내고, 그다음 domain:example.com을 프록시로 보냅니다. 순서를 뒤집으면 다운로드 도메인이 사이트 전체 규칙에 먼저 매칭됩니다.

ip와 geoip: 주소 대역 매칭 및 도메인 해석 조건

ip 필드에는 단일 주소, CIDR 주소 대역, geoip: 분류를 작성할 수 있습니다. 단일 IPv4 주소는 198.51.100.20처럼 쓰고, 네트워크 대역은 198.51.100.0/24처럼 작성합니다. IPv6 주소 대역도 CIDR로 표시하며, 예를 들어 2001:db8:1200::/48과 같이 씁니다.

geoip:private는 LAN, 루프백 및 기타 공인망이 아닌 주소를 매칭할 때 자주 사용합니다. 이러한 주소를 직접 연결 규칙 앞에 배치하면 로컬 라우터 관리 페이지, LAN 파일 서비스 또는 로컬 인터페이스가 원격 프록시로 전송되는 것을 막을 수 있습니다.

{
  "type": "field",
  "ip": [
    "geoip:private",
    "192.0.2.0/24",
    "2001:db8:1200::/48"
  ],
  "outboundTag": "direct"
}

IP 규칙이 처음 도메인으로 요청된 트래픽을 처리할 수 있는지는 domainStrategy에 따라 달라집니다. 대상에 도메인만 있고 IP 주소가 없으면, 코어는 해당 도메인을 해석할지 결정한 뒤 그 결과를 ip 규칙과 비교해야 합니다.

geosite와 geoip의 경계

geosite는 도메인 집합이고 geoip는 IP 주소 집합입니다. 서로 다른 단계의 정보 분류를 처리하므로 서로 대체할 수 없습니다. 사이트가 동적 주소, 공유 클라우드 서비스 또는 잦은 DNS 변경을 사용한다면 고정 IP 대역보다 도메인 집합이 서비스 소속을 표현하는 데 더 적합한 경우가 많습니다.

geosite:cn 규칙은 대상 도메인이 해당 분류에 포함되는지를 기준으로 판단하고, geoip:cn 규칙은 대상 IP가 해당 주소 집합에 포함되는지를 기준으로 판단합니다. 도메인과 서버 소재지는 반드시 일치하지 않으므로 두 규칙이 같은 연결에 서로 다른 분류 결과를 낼 수 있습니다.

데이터 파일은 코어 버전 및 설정 기능과 호환되어야 합니다. 'failed to load geosite' 오류가 발생하거나 분류 이름을 인식하지 못하면 먼저 데이터 파일이 코어가 실제로 읽는 디렉터리에 있는지 확인한 다음 분류 이름이 존재하는지 확인하세요. 규칙 순서만 바꿔서는 데이터 파일 누락을 해결할 수 없습니다.

outboundTag와 완전한 규칙 조합

outboundTag의 값은 outbounds 배열에 있는 특정 아웃바운드의 tag와 완전히 일치해야 합니다. 대소문자가 달라도 다른 이름으로 처리됩니다. 규칙을 "outboundTag": "direct"로 작성했다면 설정에 direct라는 태그의 아웃바운드가 있어야 합니다.

일반적인 순서는 네 단계로 나눌 수 있습니다. 사설 주소 직접 연결, 정확한 예외, 분류 기반 라우팅, 최종 처리입니다. 특정 도메인이나 포트와 관련된 차단 규칙은 이를 덮을 수 있는 포괄적인 프록시 규칙보다 앞에 배치해야 합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:updates.example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

1. 첫 번째 규칙은 LAN과 로컬 주소를 처리해 내부 서비스가 프록시 경로로 들어가지 않도록 합니다.
2. 두 번째 규칙은 명확한 예외를 정의해 지정한 업데이트 도메인이 항상 직접 연결을 사용하도록 합니다.
3. 세 번째 규칙은 분류된 사이트를 도메인 집합으로 처리하므로 IP 분류를 기다릴 필요가 없습니다.
4. 네 번째 규칙은 도메인 규칙이 처리하지 못한 경우 해석된 주소 집합으로 보완 판단을 합니다.
5. 매칭되지 않은 요청은 설정의 기본 경로를 계속 사용하며, 실제 출구는 전체 아웃바운드 구조에 따라 결정됩니다.

설정에서 로드 밸런서를 사용한다면 규칙이 단일 아웃바운드를 직접 지정하지 않고 balancerTag로 밸런서를 가리킬 수 있습니다. 일반적인 사용자 지정 라우팅에는 우선 outboundTag를 사용하고, 선택기와 밸런서를 실제로 구성한 경우에만 balancerTag를 도입해 불필요한 확인 단계를 피하세요.

v2rayN의 설정 경로와 검증 단계

v2rayN 7.x에서는 먼저 「설정」→「라우팅 설정」으로 이동해 현재 라우팅 설정과 사전 설정 규칙을 확인할 수 있습니다. 세부 버전에 따라 버튼 위치가 달라질 수 있지만 검증 목표는 같습니다. 현재 활성화된 라우팅 설정, 규칙 순서, 최종 생성된 코어 설정이 서로 일치하는지 확인하세요.

수정 후 브라우저에서 웹페이지가 열리는지만 확인하지 마세요. 브라우저 캐시, DNS 캐시, 기존 연결 재사용이 결과를 가릴 수 있습니다. 코어를 다시 시작하고 새 대상 연결을 사용한 뒤 로그 수준을 일시적으로 info 또는 debug로 조정해 라우팅 기록을 확인하세요.

1. 「설정」→「라우팅 설정」에서 현재 선택된 규칙 세트를 확인하고, 예상되는 매칭 규칙의 위치를 기록합니다.
2. 규칙의 outboundTag를 확인하고 생성된 설정의 outbounds[].tag와 한 글자씩 대조합니다.
3. 「설정」→「매개변수 설정」에서 로컬 리스너와 로그 관련 옵션을 확인합니다. 일반적인 SOCKS 포트는 10808, HTTP 포트는 10809입니다.
4. 설정을 저장하고 코어를 다시 시작한 뒤 기존 브라우저 연결을 닫거나 새로운 테스트 도메인을 사용합니다.
5. 로그에서 대상 도메인, 대상 주소, 아웃바운드 태그를 확인해 요청이 어느 규칙에서 검색을 멈췄는지 판단합니다.
6. 한 번에 규칙 하나만 이동하거나 수정하고 재시험한 뒤 다음 항목을 처리해 여러 변경 사항이 서로 영향을 주지 않도록 합니다.

확인 목록
1. 대상이 도메인인지 IP인지
2. domainStrategy가 해석을 트리거하는지
3. 정확한 규칙이 분류 규칙보다 앞에 있는지
4. outboundTag가 존재하며 대소문자가 일치하는지
5. geosite 및 geoip 데이터가 정상적으로 로드되었는지
6. 테스트 연결이 수정 후 새로 생성된 연결인지

라우팅 규칙이 적용되지 않을 때 자주 묻는 질문

라우팅 문제는 대개 하나의 문법 오류가 아니라 대상 형식, 해석 전략, 정렬 순서, 아웃바운드 태그가 함께 작용한 결과입니다. 먼저 로그에 실제로 표시된 대상을 확인한 뒤 규칙 조건과 대조하는 편이 매칭 범위를 무작정 넓히는 것보다 확실합니다.

최종 설정은 규칙의 목적을 읽기 쉽게 유지해야 합니다. 한 규칙은 하나의 명확한 의도를 처리하고, 태그 이름은 출구 용도를 나타내며, 예외 규칙은 적용 대상 바로 옆에 둡니다. 규칙이 늘어날수록 키워드를 무작정 쌓기보다 명확한 순서와 최소 조건을 유지하는 편이 장기적으로 관리하기 쉽습니다.