Xray 라우팅 규칙 심화 설정: domainStrategy와 DNS 분기 실전 가이드

라우팅 문제가 생기면 먼저 도메인 규칙, IP 규칙, DNS 확인이 어느 순서로 작동하는지 분리해서 살펴보세요. Xray의 domainStrategy는 도메인 이름을 IP 규칙과 대조할 때 이름을 해석할지 결정하는 설정이지, 그 자체로 DNS 서버나 DNS 요청의 출구를 정하는 옵션은 아닙니다. 이 글에서는 규칙 평가 순서를 이해하고, JSON 조각을 기존 구성에 적용한 뒤 로그와 연결 결과로 확인하는 방법을 설명합니다.

규칙 평가 순서와 도메인·IP 매칭

Xray는 routing.rules 배열을 위에서 아래로 검사합니다. 연결 정보가 한 규칙의 조건을 만족하면 그 규칙의 outboundTag가 적용되고, 뒤에 있는 규칙은 보통 평가하지 않습니다. 따라서 범위가 넓은 규칙을 앞에 두면 세부 예외 규칙이 실행되기 전에 트래픽이 분류될 수 있습니다. 규칙을 추가할 때는 “어떤 연결을 먼저 예외 처리할지”부터 정하고, 일반적인 프록시 규칙은 그 뒤에 두는 편이 안전합니다.

AsIs는 라우팅 과정에서 도메인을 IP로 해석하지 않는 전략입니다. 명시적인 도메인 규칙은 계속 사용할 수 있지만, IP 규칙만으로는 도메인 연결을 분류하기 어려울 수 있습니다. IPIfNonMatch는 도메인 기준으로 일치하는 규칙이 없을 때 IP 확인을 시도하는 방식입니다. IPOnDemand는 규칙 평가 중 IP 조건이 필요해지는 시점에 이름을 해석합니다. 실제 결과는 연결이 코어에 전달된 형태, DNS 구성, 코어 버전과 규칙에 따라 달라지므로 한 전략이 모든 환경에서 항상 더 빠르거나 정확하다고 단정하지 마세요.

domainStrategy 선택과 규칙 구성 예시

아래 예시는 전체 설정 파일이 아니라 routing 안에 병합할 수 있는 일부입니다. proxy, direct 태그가 실제 아웃바운드에 있는지 먼저 확인하세요. 예시 도메인인 service.example은 설명용이며, 실제 구성에서는 대상 도메인으로 바꿔야 합니다. 지역 IP 목록을 사용하는 경우에는 해당 데이터가 현재 Xray 실행 환경에 설치되어 있는지도 확인해야 합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:service.example", "domain:media.example"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:intranet.example"],
        "outboundTag": "direct"
      }
    ]
  }
}

이 예시에서는 먼저 지정한 도메인을 프록시로 보냅니다. 다음으로 사설 IP 대역에 해당하는 연결을 직접 연결하고, 내부 도메인 규칙을 마지막에 평가합니다. 이 순서는 실제 정책에 맞게 조정해야 합니다. 예를 들어 내부 도메인을 항상 직접 연결해야 한다면 해당 규칙을 프록시 도메인 규칙보다 앞에 두세요. 사설 IP 직접 연결 규칙을 먼저 둘지 뒤에 둘지도 다른 규칙과의 겹침을 고려해 결정해야 합니다.

domainStrategy를 바꿨는데도 결과가 변하지 않는다면 해당 연결이 실제로 어떤 도메인 또는 IP로 코어에 들어오는지 확인하세요. 앱이 이미 IP 주소로 접속하거나 앞단에서 DNS를 해석했다면 코어가 원래 도메인을 알지 못할 수 있습니다. 이런 경우 도메인 규칙은 예상대로 일치하지 않습니다. 또한 domain:과 full:은 매칭 범위가 다르므로, 전체 이름만 일치시킬지 하위 도메인까지 포함할지 확인해야 합니다.

DNS 설정과 라우팅 분기를 함께 점검하기

DNS 분기에는 서로 다른 두 작업이 포함될 수 있습니다. 하나는 Xray DNS 설정에서 질의 도메인에 따라 사용할 DNS 서버를 선택하는 것이고, 다른 하나는 연결된 트래픽을 라우팅 규칙으로 특정 아웃바운드에 보내는 것입니다. 두 설정은 연관될 수 있지만 같은 기능은 아닙니다. 특히 클라이언트나 운영체제가 코어 밖에서 먼저 도메인을 해석하면 Xray 내부 DNS 설정이 그 질의에 관여하지 않을 수 있습니다.

Xray의 DNS 서버 목록은 도메인 조건이 있는 서버 항목을 포함할 수 있습니다. 다음은 형식을 보여 주는 예시 조각입니다. 실제 DNS 서버 주소와 도메인 조건은 사용하는 환경에 맞게 바꾸고, 같은 설정을 중복해서 추가하지 마세요.

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["domain:service.example"]
      },
      "8.8.8.8"
    ]
  }
}

이 조각은 DNS 질의에 사용할 서버를 지정하는 예이며, 그 자체로 특정 웹 연결의 프록시 출구를 결정하지 않습니다. 또 routing에 포트 53 규칙을 추가하면 모든 종류의 DNS 요청이 반드시 그 규칙을 지난다고 가정해서는 안 됩니다. 운영체제의 암호화 DNS, 애플리케이션 자체 DNS, Xray 내부 DNS는 처리 경로가 다를 수 있습니다. 먼저 실제 질의가 어느 구성 요소에서 발생하는지 확인한 뒤 그 경로에 맞는 설정을 적용하세요.

v2rayN에서 적용하고 결과를 검증하기

JSON 편집 전에는 현재 구성 파일을 백업하세요. v2rayN의 메뉴 위치와 라우팅 편집 방식은 버전에 따라 달라질 수 있으므로, 아래 단계는 특정 버튼 위치를 단정하지 않고 안전한 검증 순서를 제시합니다. 클라이언트에서 규칙을 생성하는 방식과 직접 JSON을 수정하는 방식을 한 번에 섞지 말고, 변경 경로를 하나로 정해 결과를 비교하세요.

1. 현재 상태 기록

   v2rayN의 서버 목록에서 활성 구성을 확인하고, 실행 중인 코어가 Xray인지 확인합니다. 현재 라우팅 모드, DNS 관련 설정, 최근 연결 로그를 기록해 변경 전 기준을 남기세요.

2. 설정 백업

   수정할 JSON을 복사해 별도 파일로 보관합니다. 구독으로 관리되는 설정은 다음 업데이트에서 일부 값이 바뀔 수 있으므로, 클라이언트가 생성한 설정과 직접 수정 가능한 설정을 구분하세요.

3. 규칙 한 개 적용

   먼저 도메인 규칙 하나만 추가하고, 이어서 필요한 경우 IP 규칙과 domainStrategy를 적용합니다. 여러 항목을 동시에 바꾸지 않아야 오류가 생긴 단계와 원인을 구분할 수 있습니다.

4. 코어 재시작

   설정을 저장한 뒤 현재 코어를 다시 시작합니다. 시작 로그에 JSON 파싱 오류나 알 수 없는 필드 오류가 있는지 확인하고, 오류가 있으면 최근 변경 부분부터 되돌려 검증하세요.

5. 대상별 비교

   도메인 규칙에 해당하는 대상, IP 규칙에 해당하는 대상, 어느 규칙에도 해당하지 않는 대상을 각각 시험합니다. 같은 앱과 네트워크에서 비교하고, 로그의 매칭 규칙과 선택된 아웃바운드를 함께 확인하세요.

v2rayN 로그는 코어가 시작됐는지 확인하는 데 유용하지만, 표시되는 로그가 모든 연결에서 규칙 매칭 결과를 상세히 보여 주는 것은 아닙니다. 해당 연결의 목적지, 코어가 인식한 도메인 또는 IP, 선택된 아웃바운드 정보를 함께 확인하세요. 규칙을 바꾼 뒤 브라우저에 남아 있는 연결이 재사용되면 새 설정이 적용된 결과를 바로 보기 어려울 수 있으므로, 테스트 연결을 새로 만들어 비교하는 편이 좋습니다.