Xray 사용자 지정 라우팅 규칙 문법: domain·IP·geosite 매칭 접두사와 규칙 적용 순서

연결이 코어에 전달된 뒤 라우팅 규칙이 작동합니다

시스템 프록시, TUN 연결, Xray 라우팅은 서로 다른 단계입니다. 시스템 프록시는 해당 설정을 지원하는 앱이 연결을 로컬 진입점으로 보낼지 결정하고, 라우팅 규칙은 코어에 들어온 연결을 처리해 직접 연결·프록시·차단 중 하나를 선택합니다. 브라우저가 시스템 프록시를 우회한다면 라우팅 규칙이 정확해도 해당 규칙에 따른 라우팅 결과는 나오지 않습니다.

이 글에서는 Xray의 기본 JSON 필드를 사용합니다. v2rayN과 v2rayNG는 설정을 코어 구성으로 변환하며, v2flyNG는 V2Fly 코어를 사용합니다. 따라서 Xray의 모든 필드를 그대로 사용할 수 있다고 가정해서는 안 됩니다. 편집하기 전에 현재 사용 중인 코어를 확인하고, 적용된 라우팅 설정을 백업하세요.

• domain은 규칙 필드이며, 배열에는 domain:, full:, regexp:, geosite: 등의 매칭 표현식을 지정할 수 있습니다.
• ip는 별도의 규칙 필드로, IP 주소와 CIDR 대역 및 geoip: 집합을 받습니다. 도메인 배열에 ip: 접두사를 쓰는 것으로 혼동하지 마세요.
• outboundTag는 아웃바운드를 지정하는 값이지 임의로 적는 메모가 아닙니다. 최종 구성에 정의된 아웃바운드의 tag와 일치해야 합니다.

domain, full, regexp: 먼저 매칭 범위를 정하세요

잘못된 트래픽 분할은 대개 매칭 범위를 너무 넓게 잡아서 발생합니다. 접두사 없이 문자열만 입력하면 Xray는 부분 문자열로 매칭합니다. 해당 도메인과 모든 하위 도메인을 매칭하려면 domain:을 명시하세요. 규칙에는 호스트명을 입력하고, 프로토콜·경로·쿼리 매개변수가 포함된 전체 URL은 붙여 넣지 마세요.

정규식에는 JSON 이스케이프도 적용됩니다. 라우팅 편집기에 입력하는 표현식에는 \.을 쓸 수 있지만, JSON 문자열에 넣을 때는 역슬래시를 \\로 작성해야 합니다. 아래는 파싱 가능한 JSON 규칙 객체 예시이며, 이것만으로 코어를 실행할 수 있는 전체 구성은 아닙니다.

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

ip, geoip, geosite: 데이터 출처가 다릅니다

geosite는 도메인 집합을, geoip는 IP 주소 집합을 매칭합니다. 웹사이트가 여러 콘텐츠 전송 주소를 사용하면 도메인 분류와 실제 연결 IP의 지역 분류가 다를 수 있습니다. 특정 사이트를 항상 프록시로 보내려면 IP의 지역 분류에만 의존하지 말고 도메인 예외 규칙을 우선 추가하세요.

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

위 예시의 앞 두 항목은 CIDR 표기법을 보여 주며, geoip:private의 일부 범위와 겹칩니다. 실제로 사용할 때는 중복 항목을 삭제해도 됩니다. IPv4 사설 대역만 지정해도 IPv6 로컬 주소까지 자동으로 포함되지는 않습니다. 듀얼 스택 네트워크라면 사용하는 사설 IP 집합의 범위를 확인하세요.

• 집합 존재 여부: geosite:cn 또는 geoip:cn을 참조하기 전에 코어가 해당 데이터 파일을 읽을 수 있고 파일에 해당 집합이 포함되어 있는지 확인하세요.
• 분류 데이터 업데이트 시점: 클라이언트 설정 업데이트와 geo 데이터 업데이트는 별개입니다. 구독 업데이트에 성공했다고 해서 도메인 분류까지 갱신된 것은 아닙니다.
• 확장 집합 문법: geosite:집합@속성은 데이터 파일에 해당 속성이 있을 때만 유효합니다. 아무 집합에나 접미사를 붙여 쓸 수 있는 것은 아닙니다.
• 문제 증상: 데이터 파일이 없거나 집합이 존재하지 않으면 구성 로드에 실패할 수 있습니다. 노드 연결 문제로 단정하지 말고 먼저 시작 로그를 확인하세요.

규칙 우선순위: 위에서부터 확인하고 매칭되면 종료

라우팅을 한 번 매칭할 때 Xray는 rules 배열의 순서대로 검사하며, 모든 조건을 만족하는 첫 번째 규칙을 적용합니다. 뒤쪽 규칙의 도메인이 더 구체적이라고 해서 자동으로 그 규칙을 선택하지는 않습니다. 정확한 예외 규칙은 포괄적인 분류 규칙보다 앞에, 기본 대체 규칙은 맨 끝에 두세요.

같은 필드의 배열은 일반적으로 OR 조건입니다. 도메인 배열에서는 표현식 중 하나만 매칭돼도 됩니다. 한 규칙 안의 서로 다른 필터 필드는 대체로 AND 조건입니다. domain, port, network를 함께 설정하면 모든 조건을 만족해야 합니다. 도메인 조건과 IP 조건을 한 규칙에 넣어도 둘 중 하나만 매칭되면 직접 연결되는 것은 아닙니다.

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

순서를 설명하기 위한 routing 구성 예시입니다. direct, proxy, block 아웃바운드가 이미 있고 데이터 파일에 예시 집합이 포함되어 있다고 가정합니다. 태그 이름 자체는 코어의 예약된 동작 이름이 아닙니다. 일반적으로 직접 연결에는 freedom, 차단에는 blackhole 아웃바운드를 사용하고, 프록시 아웃바운드에는 실제 노드 프로토콜을 지정합니다.

domainStrategy: 도메인이 IP 매칭에 참여하는 시점

도메인 대상에 IP 규칙을 적용할 수 있는지는 라우팅의 domainStrategy에 따라 달라집니다. 이 필드는 라우팅 단계에서 매칭을 위해 도메인을 해석할지 결정합니다. 클라이언트 전체의 DNS 설정과 같은 의미도 아니고, 직접 연결 아웃바운드가 최종적으로 대상 주소를 해석하는 방식과도 다릅니다.

따라서 앞 절의 5개 규칙에는 IPIfNonMatch가 설정되어 있지만, 도메인 대상이 마지막 TCP/UDP 대체 규칙에 도달하면 첫 번째 라운드에서 이미 매칭이 끝납니다. 그러면 앞에 있는 geoip:cn 규칙을 위해 도메인을 해석하지 않습니다. 원래 IP인 대상은 네 번째 규칙에 계속 매칭될 수 있습니다. 이는 “geoip를 설정했는데 도메인은 여전히 프록시를 거치는” 흔한 원인입니다.

• IP 추가 매칭이 필요하다면: 전체 매칭 대체 규칙을 제거하고, 어떤 규칙에도 매칭되지 않을 때 사용할 첫 번째 아웃바운드가 원하는 기본 아웃바운드인지 확인하세요.
• IP 규칙을 만나면 해석해야 한다면: IPOnDemand를 검토해 보세요. IP 정보가 필요한 규칙을 매칭할 때 해석을 시도하지만, DNS가 라우팅에 관여할 가능성이 커집니다.
• 특정 사이트 하나만 고정 경로를 사용하면 된다면: 앞쪽에 full: 또는 domain: 규칙을 추가하는 편이 전체 해석 전략을 바꾸는 것보다 대개 검증하기 쉽습니다.

또한 인바운드에 대상 IP만 들어오면 도메인 규칙은 원래 호스트명을 알 수 없습니다. 스니핑은 식별 가능한 트래픽에서 도메인 정보를 보완할 수 있지만, 모든 프로토콜에서 도메인을 복원하는 기능은 아닙니다. 문제를 확인할 때는 인바운드 대상, 스니핑 설정, 최종 아웃바운드를 함께 살펴보세요.

v2rayN에서 규칙 순서 조정 및 결과 확인

v2rayN에서 「설정」→「라우팅 설정」을 열고 사용할 라우팅 프로필을 선택한 뒤 규칙 편집으로 이동합니다. 편집, 위로 이동, 아래로 이동 버튼의 위치는 버전마다 다를 수 있습니다. 프로필 이름이나 규칙 메모가 아니라 최종 생성된 routing.rules의 순서를 기준으로 확인하세요.

1. 프로필 복사: 기존 프로필을 되돌리기용으로 보관하고 복사본에 테스트 도메인의 full: 규칙 하나만 추가하세요. 먼저 DNS, 스니핑, 코어 설정은 함께 변경하지 마세요.
2. 필드별로 입력: full:example.com은 도메인 조건에, geoip:cn은 IP 조건에 입력하세요. 한 줄씩 입력하는 인터페이스라면 각 줄에 매칭 항목 하나만 적고 JSON 객체 전체를 붙여 넣지 마세요.
3. 아웃바운드 확인: 아웃바운드 옵션에서 사용할 경로를 선택하세요. 기본 구성을 사용한다면 outboundTag와 아웃바운드의 tag가 대소문자까지 완전히 일치하는지 확인하세요.
4. 순서 조정: 테스트 규칙을 먼저 매칭될 가능성이 있는 규칙보다 위로 옮기세요. 저장한 뒤 해당 라우팅 프로필이 선택되어 있는지 확인하고, 화면 안내에 따라 코어를 다시 불러오거나 재시작하세요.
5. 새 연결로 테스트: 기존 웹페이지 연결을 닫고 다시 접속하세요. 이미 연결된 장시간 세션은 규칙을 바꿔도 아웃바운드가 자동으로 바뀌지 않는 경우가 많습니다. 필요하다면 브라우저를 종료한 뒤 다시 테스트하세요.
6. 로그 기록: 코어가 정상적으로 시작됐는지 확인한 다음 테스트 대상의 접속 기록과 아웃바운드 태그를 살펴보세요. 필요하면 로그 설정에서 상세 수준을 잠시 높이고, 테스트가 끝나면 되돌려 연결 정보가 계속 대량 기록되지 않도록 하세요.

“HTTPS만 직접 연결”을 확인하려면 테스트 규칙에 도메인 조건과 port: "443", network: "tcp"를 함께 설정할 수 있습니다. UDP를 사용하는 HTTP/3은 TCP 조건에 맞지 않으므로 브라우저에서 같은 사이트가 열린다는 이유만으로 규칙이 적용되지 않았다고 판단해서는 안 됩니다. 테스트 조건과 프로토콜 및 포트가 일치해야 합니다.