V2Ray 사용자 지정 라우팅 규칙 설정법: domain·ip·geosite 매칭 문법과 우선순위

1. 라우팅 규칙의 기본 구조와 매칭 대상

시스템 프록시는 앱의 연결을 인바운드로 전달하고, 라우팅은 트래픽이 코어에 들어온 뒤 아웃바운드를 선택합니다. 브라우저가 시스템 프록시를 사용하지 않으면 규칙이 올바르더라도 라우팅을 우회할 수 있습니다. 사용자 지정 규칙을 점검하기 전에 앱이 클라이언트를 통해 연결되는지 먼저 확인하세요. 웹사이트에 표시되는 출구 IP부터 확인하는 것만으로는 충분하지 않습니다.

일반적인 설정에서는 routing.rules 배열에 규칙을 저장합니다. 각 규칙의 type은 보통 field이며, 매칭 조건으로 domain, ip, port, network 등을 지정하고 결과는 outboundTag로 정합니다. 태그는 설정에서 참조하는 이름일 뿐, 코어에 내장된 고정 동작이 아닙니다.

{
  "type": "field",
  "domain": [
    "full:api.example.com",
    "domain:example.net"
  ],
  "port": "443",
  "network": "tcp",
  "outboundTag": "proxy"
}

이 규칙은 대상 도메인이 배열 항목 중 하나와 일치하고 대상 포트가 443이며 전송 네트워크가 TCP인 경우에만 적용됩니다. 도메인 배열 안에서는 ‘또는’, 서로 다른 조건 필드 사이에서는 ‘그리고’로 판단합니다. 같은 도메인의 UDP 443 연결이나 TCP 80 연결에는 적용되지 않습니다. 아래 숫자 세 개는 설정 의미를 보여주는 예시이지 속도 측정 결과가 아닙니다.

2. domain·full·regexp와 일반 문자열 작성법

domain은 규칙의 필드 이름이고, 필드 배열 안의 domain:은 매칭 방식의 접두사입니다. 둘을 혼동하지 마세요. 배열 항목에는 도메인이나 해당 표현식만 입력하고, URL의 프로토콜·경로·쿼리 매개변수는 넣지 않습니다. 같은 사이트의 URL 경로별로 나누어 라우팅하는 것은 일반 도메인 규칙으로 처리할 수 없습니다.

표의 정규 표현식은 JSON 문자열 형식으로 표시했습니다. 정규식에서 마침표를 문자 그대로 나타내려면 \.를 사용하고, JSON에서는 역슬래시도 이스케이프해야 하므로 설정 파일에는 \\.로 입력합니다. 클라이언트의 일반 텍스트 입력란에는 보통 역슬래시 하나만 입력하면 됩니다. JSON 이스케이프 형식을 모든 UI에 그대로 복사하지 마세요.

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

3. ip·geoip·geosite의 차이

ip 필드에서는 대상 주소를 매칭하며, 단일 IP·CIDR 대역 또는 geoip: 데이터셋 참조를 지정할 수 있습니다. geosite:는 domain 배열에 넣어 도메인 목록을 기준으로 매칭합니다. 두 데이터셋은 구성 항목이 다르므로, 같은 이름의 geosite와 geoip가 반드시 동일한 대상을 가리키는 것은 아닙니다.

{
  "type": "field",
  "ip": [
    "192.168.0.0/16",
    "10.0.0.0/8",
    "geoip:private"
  ],
  "outboundTag": "direct"
}

위 예시는 CIDR을 구체적으로 쓰는 방법과 사설 주소 집합을 보여줍니다. 두 범위는 겹칠 수 있으므로 실제 설정에서는 목적에 맞는 한 가지를 선택하면 됩니다. IPv6 단일 주소에는 /128을 사용할 수 있습니다. IPv4만 다루고 모든 로컬 네트워크 연결을 처리했다고 판단하지 마세요. 듀얼 스택 네트워크에서는 IPv6 대상 주소도 확인해야 합니다.

• geosite:cn: 데이터 파일에서 cn이라는 도메인 집합을 참조합니다. .cn으로 끝나는 도메인만 매칭한다는 뜻은 아닙니다.
• geoip:cn: 주소 데이터베이스를 기준으로 대상 IP의 할당 지역을 판단합니다. 웹사이트 콘텐츠의 언어나 접속한 사용자의 위치를 뜻하지는 않습니다.
• geoip:private: 사설 주소 등 로컬 용도의 주소 집합을 참조합니다. 정확한 범위는 사용 중인 데이터 파일에 따라 달라집니다.
• 데이터 파일 필요: 일반적인 데이터셋 설정은 코어가 읽을 수 있는 geosite.dat와 geoip.dat에 의존합니다. 집합 이름이 실제로 존재하는지 확인하고 임의로 분류명을 추측하지 마세요.

하나의 도메인도 여러 지역의 CDN 주소를 사용할 수 있으며, DNS 응답이 바뀌면 IP 기반 규칙의 결과도 달라질 수 있습니다. 특정 서비스의 연결을 항상 지정한 아웃바운드로 보내려면 한 번 조회한 CDN IP를 고정하기보다 명확한 도메인 예외를 추가하는 편이 좋습니다.

4. 적용 우선순위: 정밀도가 아니라 위에서부터 첫 번째 일치 규칙

한 번 규칙을 검사할 때 코어는 rules 배열을 위에서 아래로 확인하고, 일치하는 규칙을 찾으면 해당 규칙의 아웃바운드를 선택합니다. 뒤에 있는 full: 규칙이 더 정확하다고 앞의 geosite: 규칙을 자동으로 덮어쓰거나, CIDR 길이에 따라 순서를 다시 정하지 않습니다. ‘예외 우선’은 설정 작성자가 예외 규칙을 앞쪽으로 옮기는 것을 뜻합니다.

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

이 예시에서는 단일 도메인 예외를 도메인 집합보다 앞에 둡니다. 같은 연결이 두 번째 규칙에 일치하면 세 번째 규칙은 더 이상 적용되지 않습니다. 다만 첫 번째 사설 IP 규칙이 최초 검사에서 매칭되는지는 대상이 이미 IP인지, 현재 도메인 전략이 DNS 조회를 유발하는지에 따라 달라집니다. 규칙이 가장 위에 있다고 해서 DNS 조회도 반드시 먼저 수행되는 것은 아닙니다.

1. 대상이 api.example.com이고 인바운드에서 도메인이 유지되면 두 번째 규칙이 proxy를 바로 선택합니다.
2. 다른 도메인이 geosite:cn에 일치하면 세 번째 규칙이 direct를 선택하므로 IP를 추가로 확인할 때까지 기다릴 필요가 없습니다.
3. 도메인 단계에서 어떤 규칙에도 일치하지 않을 때만 IPIfNonMatch가 도메인을 조회하고, 얻은 IP로 규칙을 다시 검사합니다.
4. 그래도 일치하는 규칙이 없으면 일반적인 설정은 outbounds 배열의 첫 번째 아웃바운드를 사용합니다. 이름이 반드시 proxy인 것은 아닙니다.

5. domainStrategy가 DNS 조회와 라우팅 결과에 미치는 영향

routing.domainStrategy는 라우팅 매칭에 필요한 경우 대상 도메인을 IP로 조회할지 결정합니다. 시스템 DNS 설정이나 직결 아웃바운드에 설정하는 같은 이름의 전략과는 다릅니다. 이름이 비슷해도 설정 위치와 적용 단계가 다릅니다.

예를 들어 첫 번째 규칙이 geoip:private이고 두 번째 규칙이 특정 도메인의 프록시 예외라고 가정해 보겠습니다. 해당 도메인이 사설 주소로 해석되면 IPOnDemand에서는 첫 번째 규칙이 먼저 일치할 수 있습니다. 반면 IPIfNonMatch에서는 두 번째 규칙에 이미 일치하면 추가 조회를 기다리지 않습니다. 전략을 변경한 뒤에는 웹사이트가 열리는지만 확인하지 말고 실제로 선택된 아웃바운드도 점검하세요.

• DNS 응답에 주소가 여러 개 포함될 수 있습니다. IP 규칙은 코어가 조회 결과를 처리하는 방식에 따라 판단해야 하며, 명령줄에 표시된 첫 번째 주소만으로 결과를 추정하면 안 됩니다.
• 앱이 IP 주소를 직접 지정해 연결하면 도메인 규칙에 필요한 정보가 없는 경우가 많습니다. 일부 프로토콜에서는 스니핑으로 대상 도메인을 알아낼 수 있지만 모든 연결에서 가능한 것은 아닙니다.
• ‘UDP 53 전체 차단’ 규칙을 추가해도 모든 DNS가 차단되는 것은 아닙니다. 암호화된 DNS는 다른 포트와 전송 방식을 사용할 수 있습니다.

6. v2rayN에서 사용자 지정 규칙 추가 및 확인

아래 설명은 v2rayN 7.x 데스크톱 버전에서 흔히 볼 수 있는 화면을 기준으로 합니다. 세부 버전에 따라 버튼 위치가 다를 수 있으니 규칙 필드는 현재 창을 확인하세요. UI에서 관리하는 규칙과 전체 JSON 설정은 입력 형식이 다릅니다. 전체 routing 객체를 ‘도메인’ 입력란 하나에 붙여 넣지 마세요.

1. 코어 확인

   ‘설정’ → ‘매개변수 설정’을 열어 Core 유형 관련 항목과 현재 설정에 사용 중인 코어를 확인하고, 실행 후 로그에 표시된 코어 이름도 확인합니다. 여기서 설명하는 문법은 V2Ray·Xray의 일반적인 라우팅 설정용입니다. 다른 형식은 변환해야 합니다.

2. 라우팅 설정 열기

   ‘설정’ → ‘라우팅 설정’으로 이동합니다. 먼저 현재 구성의 백업을 보관한 다음 적용할 규칙 집합을 편집하세요. 편집 중인 대상이 기본 화면에서 실제로 선택된 라우팅인지, 사용되지 않는 복사본은 아닌지 확인합니다.

3. 예외 추가

   규칙 편집 창에서 대상 아웃바운드를 선택한 다음 도메인 항목에 full:api.example.com 또는 처리하려는 실제 도메인을 입력합니다. 처음에는 포트와 네트워크 조건을 추가하지 말고, 동작을 확인한 뒤 조건을 단계적으로 좁히세요.

4. 규칙 순서 조정

   예외 규칙을 해당 연결을 가로챌 수 있는 도메인 집합 규칙보다 앞에 둡니다. 저장한 뒤 해당 라우팅 구성을 선택하세요. 클라이언트가 관련 설정을 다시 불러오는 경우가 많습니다. 로그에 변경 사항이 반영되지 않으면 서비스를 다시 시작한 후 테스트하세요.

5. 연결 다시 확인

   기존 테스트 탭을 닫고 새 연결을 만든 다음 연결 로그에서 대상과 아웃바운드 태그를 확인합니다. 더 자세한 기록이 필요하면 ‘설정’ → ‘매개변수 설정’에서 로그 수준을 일시적으로 높이고, 확인이 끝나면 평소 수준으로 되돌리세요.

라우팅 변경은 대개 새 연결부터 적용됩니다. 브라우저의 연결 재사용이나 장시간 연결은 기존 아웃바운드를 계속 사용할 수 있습니다. 새로고침 한 번만으로 규칙이 적용되지 않았다고 판단하지 마세요. 기본 도메인·하위 도메인·직접 IP 연결도 각각 테스트해야 합니다. 홈페이지 하나만 확인하면 페이지 리소스가 다른 도메인으로 연결되는 경우를 놓칠 수 있습니다.

7. 사용자 지정 라우팅 자주 묻는 질문