2026-10-28 · 프로토콜 선택 · 약 10분

Xray 라우팅 규칙 우선순위와 domainStrategy JSON 설정 가이드

Xray에서 도메인과 IP에 따라 트래픽을 원하는 출구로 보내려면 규칙 순서와 domainStrategy를 함께 이해해야 합니다. 실제로 수정해 쓸 수 있는 JSON 예제로 매칭 동작을 설명하고, DNS 조회 방식과 규칙이 적용되지 않거나 다른 outbound가 선택되는 문제의 점…

Xray 라우팅은 규칙을 위에서 아래로 검사해 먼저 일치한 규칙의 출구를 선택합니다. 따라서 규칙 자체가 맞더라도 더 넓은 조건이 앞에 있으면 뒤의 규칙까지 도달하지 않을 수 있습니다. 도메인 규칙과 IP 규칙을 함께 쓸 때는 `routing.domainStrategy`가 도메인 이름을 IP 조건과 비교하는 방식에 영향을 줍니다. 이 값을 DNS 서버 지정이나 DNS 유출 방지 설정과 혼동하지 말고, 규칙 순서와 실제 요청에 사용된 목적지 정보를 함께 확인하세요.

이 글에서 다루는 내용

Xray의 규칙 우선순위, `AsIs`·`IPIfNonMatch`·`IPOnDemand`의 차이, DNS 설정과 라우팅의 관계를 설명합니다. JSON 예제를 바탕으로 도메인 요청은 프록시로, 지정한 IP 대역은 직접 연결로 보내는 구성을 살펴보고, 규칙이 예상대로 적용되지 않을 때 로그와 DNS 응답을 확인하는 순서도 안내합니다.

라우팅 규칙은 위에서 아래로 평가

Xray는 `routing.rules` 배열을 순서대로 검사합니다. 요청이 규칙의 조건을 모두 만족하면 해당 규칙의 `outboundTag` 또는 `balancerTag`를 사용하고, 이후 규칙은 일반적으로 검사하지 않습니다. 조건이 여러 개 있는 규칙은 이 조건들 사이의 조합도 중요합니다. 예를 들어 `domain`과 `port`가 한 규칙에 함께 있으면 도메인 또는 포트 중 하나가 아니라, 해당 규칙이 정의한 조건을 함께 충족해야 매칭됩니다.

연결 수신 규칙 순회 조건 비교 출구 선택

규칙의 `type`은 보통 `field`이며, 조건에는 `domain`, `ip`, `port`, `network`, `inboundTag`, `protocol`, `source` 등이 사용됩니다. 조건이 생략된 규칙은 사실상 넓은 범위의 요청을 받을 수 있으므로 배열 아래쪽에 두는 편이 안전합니다. 특히 모든 요청을 받는 최종 규칙이 앞에 있으면 그 아래의 세부 규칙은 실행될 기회가 없습니다.

예를 들어 `domain:example.com`은 일반적으로 해당 도메인과 하위 도메인을 대상으로 하는 패턴입니다. 정확히 하나의 호스트만 지정하려면 `full:example.com`을 검토하세요. 반대로 `keyword:example`은 문자열이 포함된 더 넓은 범위에 일치할 수 있으므로, 민감한 분기 규칙에는 의도하지 않은 도메인까지 포함되지 않는지 확인해야 합니다.

domainStrategy 세 값의 차이

`domainStrategy`는 도메인 요청을 IP 기반 규칙과 비교할 때 도메인을 어떻게 처리할지 정하는 항목입니다. `routing` 객체 안에 설정하며, DNS 서버 주소나 도메인 규칙의 우선순위를 대신 지정하지는 않습니다. IP 규칙을 사용한다면 DNS 응답이 어떤 시점에 필요한지와 그 응답이 실제 목적지 선택에 어떤 영향을 주는지 함께 고려하세요.

AsIs

IP 규칙 비교
도메인을 IP로 조회해 변환하지 않음
주요 용도
도메인 조건 중심 라우팅
확인 사항
IP 대역 규칙이 도메인 요청을 분류하지 못할 수 있음

IP 조건을 만들었는데 도메인 요청이 그 규칙에 들어가지 않는다면 전략과 요청의 목적지 형식을 확인하세요.

IPIfNonMatch

처리 방식
도메인 규칙에 매칭되지 않을 때 IP 비교를 위해 조회
주요 용도
도메인 규칙과 IP 규칙의 조합
확인 사항
도메인 규칙이 먼저 매칭되면 뒤의 IP 분기가 적용되지 않을 수 있음

도메인 우선 분기를 유지하면서, 도메인 규칙에 걸리지 않은 요청을 IP 조건으로 더 분류할 때 검토할 수 있습니다.

IPOnDemand는 라우팅 과정에서 IP 규칙이 필요해지는 시점에 도메인 조회를 요청하는 전략입니다. 세 값 중 어느 하나가 모든 환경에서 더 정확하거나 더 안전한 것은 아닙니다. 예를 들어 도메인 규칙만 사용한다면 불필요한 IP 변환을 기대하지 않도록 `AsIs`를 고려할 수 있고, 도메인과 IP 규칙을 조합한다면 먼저 규칙 순서를 정한 다음 `IPIfNonMatch` 또는 `IPOnDemand`의 실제 동작을 검증해야 합니다.

판단 기준: 규칙 순서를 먼저 고정하세요

IP 기반 직접 연결 규칙을 추가하기 전에 도메인 요청이 앞선 규칙에서 이미 처리되는지 확인하세요. `domainStrategy`를 바꾸는 것만으로는 먼저 일치한 규칙의 결과가 뒤집히지 않습니다.

도메인·IP 조건을 함께 쓰는 JSON 예제

아래 예제에서는 도메인 조건에 해당하는 요청을 `proxy`로 보내고, 사설 IP 대역으로 확인된 요청은 `direct`로 보냅니다. 예시는 라우팅과 DNS의 핵심 구조를 보여 주기 위한 설정이므로, 실제 구성에 붙일 때는 이미 사용하는 inbound, outbound, DNS 서버, 규칙 데이터와 태그를 유지하세요. 배열 순서는 이 예제에서 의도한 정책의 일부입니다.

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:example.com"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

이 조각을 그대로 실행하려면 `proxy`와 `direct`라는 태그를 가진 outbound가 실제 설정에 있어야 합니다. 예제의 DNS 서버 주소는 설명용이므로 사용 중인 네트워크 정책과 접근 가능한 DNS에 맞게 조정하세요. 또한 `localhost`는 실행 환경의 로컬 DNS 처리와 관련될 수 있으므로, 이를 추가했다고 해서 모든 도메인 질의가 Xray 내부에서 같은 경로로 처리된다고 가정하면 안 됩니다.

설정 적용 후 매칭 결과 확인

v2rayN에서는 실제로 실행 중인 코어가 Xray인지 먼저 확인한 뒤, 현재 사용하는 설정의 라우팅과 DNS 구성을 검토하세요. 클라이언트의 메뉴명과 자동 생성 설정은 버전에 따라 다를 수 있으므로, UI에서 JSON을 편집할 수 있다고 단정하지 말고 내보내기·사용자 설정 기능의 제공 여부를 확인합니다. 예를 들어 v2rayN 7.x를 사용하더라도 선택한 코어와 코어 버전은 별도로 확인해야 합니다. 아래 절차는 특정 UI 메뉴가 아닌 설정을 검증하는 일반적인 순서입니다.

  1. 현재 설정 백업

    수정 전에 사용 중인 라우팅 규칙과 DNS 항목을 복사해 보관하세요. 노드 구독 갱신이나 프로필 변경 후 설정이 다시 생성될 수 있으므로, 변경한 파일과 적용 대상을 기록합니다.

  2. 태그 확인

    라우팅 규칙의 `outboundTag`가 실제 outbound의 `tag`와 일치하는지 확인하세요. `proxy`와 `Proxy`처럼 대소문자가 다르면 같은 태그가 아닙니다.

  3. 규칙 순서 점검

    구체적인 도메인·IP 규칙을 위에, 넓은 조건이나 최종 기본 규칙을 아래에 배치합니다. 조건을 하나씩 추가하면서 각 요청이 어느 규칙에 들어가야 하는지 예상 결과를 적어 두세요.

  4. 요청별 비교

    도메인 하나와 알려진 IP 목적지 하나를 각각 시험하고, Xray 로그에서 요청 주소와 선택된 출구를 확인하세요. DNS 응답이 여러 IP를 돌려줄 수 있으므로 한 번의 결과만으로 정책을 단정하지 않습니다.

  5. 한 항목씩 변경

    `domainStrategy`, DNS 서버, 규칙 순서를 동시에 바꾸지 마세요. 한 가지를 수정한 뒤 같은 요청을 다시 시험해야 원인을 구분할 수 있습니다.

로컬 프록시를 사용하는 환경에서 v2rayN의 혼합 포트가 `127.0.0.1:10808`로 설정되어 있다면, 먼저 해당 포트가 실제로 열려 있는지 확인하세요. 이 포트는 흔히 쓰이는 예시일 뿐 기본값으로 보장되지 않습니다. 요청이 로컬 포트에 도달하지 않으면 Xray 라우팅 로그에도 해당 요청이 나타나지 않을 수 있습니다. 이때 라우팅 JSON부터 바꾸기보다 클라이언트가 사용하는 포트와 연결 방식을 먼저 대조하세요.

DNS와 규칙 불일치 문제 구분

도메인으로 접속했을 때 예상과 다른 출구가 선택된다면, 우선 “요청에 도메인 이름이 전달됐는가”와 “도메인이 IP 주소로 변환됐는가”를 구분하세요. 앱이 처음부터 IP 주소로 연결하면 도메인 규칙은 매칭되지 않을 수 있습니다. 반대로 도메인 이름이 전달되어도 DNS 응답의 IP가 달라지거나 여러 개라면 IP 기반 규칙의 결과가 예상과 다를 수 있습니다. CDN을 사용하는 서비스에서는 지역, 시간, DNS 응답에 따라 주소가 바뀌는 경우도 고려해야 합니다.

IP 규칙을 넣었는데 도메인 요청이 안 잡혀요

`domainStrategy`가 `AsIs`인지 확인하고, 먼저 일치하는 도메인 규칙이 있는지 살펴보세요. IP 조회가 필요한 구성이라면 `IPIfNonMatch`와 `IPOnDemand`를 비교하되 한 번에 하나만 바꿉니다.

DNS 서버를 지정했는데 우회가 달라졌어요

DNS 서버 설정과 라우팅 규칙은 별도 계층입니다. 해당 도메인의 실제 응답 주소, 질의가 처리된 위치, 선택된 outbound를 로그와 함께 확인하세요.

규칙을 바꿨는데 계속 같은 출구를 써요

수정한 설정이 실행 중인 Xray에 적용됐는지 확인한 뒤, 규칙 배열의 앞부분과 outbound 태그를 점검하세요. 변경 후 코어를 재시작해야 적용되는 구성인지도 확인합니다.

오류 로그에 설정 필드나 규칙 데이터 관련 오류가 표시되면 우선 JSON 문법, 괄호, 쉼표, `domainStrategy`의 위치, `geoip`·`geosite` 데이터의 존재 여부를 점검하세요. 설정 파일이 정상적으로 읽혔다는 사실만으로 각 규칙이 의도한 요청에 매칭된다고 보장되지는 않습니다. 규칙마다 기대하는 요청, 예상 출구, 실제 로그 결과를 나란히 기록하면 DNS 문제와 배열 순서 문제를 훨씬 빠르게 나눌 수 있습니다.

v2rayN 다운로드