Xray DNS 설정 가이드: 중국 본토·해외 도메인 분리 및 DNS 오염 방지

1. 내장 DNS의 처리 범위: DNS 조회와 실제 연결을 구분하세요

Xray의 dns 객체는 코어에 도메인 조회 기능을 제공하지만, 운영체제의 모든 DNS 트래픽을 대신 처리하는 것은 아닙니다. 앱이 먼저 시스템 DNS로 IP 주소를 조회한 뒤 그 IP로 프록시에 연결할 수도 있고, 도메인 자체를 프록시 프로토콜에 넘겨 로컬 코어 또는 원격 서버에서 처리할 수도 있습니다. 두 경로는 로그와 진단 결과가 다르게 나타납니다.

내장 DNS 조회가 시작된 경우에만 dns.servers 설정이 서버 선택에 관여합니다. 예를 들어 라우팅 정책에서 도메인을 IP로 변환해 매칭하거나, direct 아웃바운드가 IP 주소로 연결하도록 설정된 경우 코어의 DNS 기능을 사용합니다. 반대로 프록시 아웃바운드가 대상 도메인을 원격으로 전달한다면 로컬 DNS 로그에 해당 도메인이 보이지 않아도 정상일 수 있습니다.

• DNS 분기: 도메인을 어떤 DNS 서버에 조회할지 결정합니다.
• 트래픽 분기: 대상 사이트에 접속할 때 direct와 proxy 중 어떤 아웃바운드를 사용할지 결정합니다.
• DNS 전송 경로 분기: DNS 서버로 보내는 UDP 또는 HTTPS 요청을 어디서 전송할지 결정합니다.
• 시스템 트래픽 가로채기: 브라우저와 다른 앱, 시스템 서비스의 DNS 요청이 같은 처리 경로로 들어오는지 결정합니다.

2. 핵심 필드: servers, domains 및 폴백 정책

servers에는 일반 DNS 주소와 DoH 주소를 함께 지정할 수 있습니다. 객체 형식의 DNS 서버 항목은 도메인 매칭과 폴백 동작도 설정할 수 있습니다. 여기서 ‘현지 DNS 조회’는 현재 네트워크에서 지정한 중국 본토 DNS 서버에 직접 연결한다는 뜻입니다. localhost를 의미하지 않으며, 라우터가 제공하는 DNS를 자동으로 읽는 것도 아닙니다.

UseIP는 IPv4와 IPv6를 모두 조회하고, UseIPv6는 IPv6만 조회합니다. 여기서 UseIPv4를 선택한 것은 문제 해결을 위한 기준 설정일 뿐, 모든 네트워크에서 IPv6를 꺼야 한다는 뜻은 아닙니다. 노드의 외부 연결과 시스템 라우팅, 직접 연결 네트워크가 모두 IPv6를 지원하는지 확인한 뒤 설정을 바꾸고 다시 검증하세요.

geosite:cn은 사용 중인 도메인 데이터 파일을 기반으로 하며, 도메인 소속 지역을 실시간으로 판별하지 않습니다. 데이터 업데이트와 수록 범위에 따라 매칭 결과가 달라질 수 있습니다. geoip:cn은 IP 주소 목록이므로 DNS 항목의 도메인 분류를 대신할 수 없습니다.

3. DNS 설정 예제: 중국 본토 도메인은 지정 DNS로, 나머지는 DoH로

아래 JSON에는 최상위 dns 객체가 포함되어 있습니다. 기존 설정에 같은 객체가 있다면 내용을 병합해야 하며, 하나의 설정에 dns 키를 두 번 추가하면 안 됩니다. 예제에서는 DNS 서버의 도메인을 다시 조회해야 하는 상황을 피하기 위해 IP 형식의 DoH 주소를 사용합니다. 해당 주소도 HTTPS 인증서를 정상적으로 검증해야 합니다.

{
  "dns": {
    "tag": "dns-internal",
    "queryStrategy": "UseIPv4",
    "disableFallbackIfMatch": true,
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  }
}

1. 중국 본토 도메인에 매칭될 때: 223.5.5.5:53을 사용합니다. 조회에 실패해도 일반 DoH 항목으로 폴백하지 않아 DNS 처리 범위를 분리할 수 있습니다.
2. 도메인 목록에 매칭되지 않을 때: skipFallback: true 설정으로 중국 본토 DNS 항목을 제외하고 DoH 항목에서 조회합니다.
3. 중국 본토 DNS 서버에 연결할 수 없을 때: 현재 네트워크에서 UDP 53이 차단되는지 먼저 확인하세요. 이중화를 원한다면 같은 domains를 사용하는 중국 본토 DNS 서버를 추가하고 전송 경로도 함께 설정하세요.
4. 사내 도메인: 기업 내부 도메인은 보통 기업 DNS가 필요합니다. 실제 사내 도메인 접미사에 전용 매칭 규칙을 추가하고 공용 DNS 서버로 직접 보내지 마세요.

4. 라우팅 설정: DoH를 실제로 프록시를 통해 전송하기

DoH는 조회가 HTTPS로 전송된다는 뜻일 뿐, 연결이 반드시 프록시를 거친다는 의미는 아닙니다. 아래 라우팅 예제는 앞서 설정한 DNS 객체와 함께 사용하며, 기존 설정에 proxy와 direct라는 아웃바운드가 있어야 합니다. 클라이언트가 노드 설정을 생성하는 경우 실제 태그 이름이 다를 수 있으니, 실행 설정을 먼저 확인하고 관련 태그를 일괄 수정하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-internal"],
        "ip": ["223.5.5.5"],
        "port": "53",
        "network": "udp",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["dns-internal"],
        "ip": ["1.1.1.1"],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

앞의 두 규칙은 dns-internal 태그가 붙은 DNS 조회 연결만 매칭하므로 일반 규칙보다 앞에 배치해야 합니다. 세 번째 규칙은 중국 본토 도메인의 실제 연결을, 네 번째 규칙은 사설 IP 주소를 대상으로 하는 연결을 처리하고 마지막 규칙은 나머지를 처리합니다. AsIs는 IP 라우팅 규칙에 매칭하기 위해 도메인을 직접 조회하지 않습니다. 따라서 이 예제는 IP 기반 라우팅과 DNS 분기를 구분합니다.

중국 본토 도메인에 대한 직접 연결에서 위 내장 DNS를 사용하려면 기존 direct 아웃바운드의 관련 부분을 다음과 같이 설정할 수 있습니다. 같은 이름의 아웃바운드를 새로 만들지 말고 기존 객체를 수정하면서 다른 필수 설정은 유지하세요.

{
  "tag": "direct",
  "protocol": "freedom",
  "settings": {
    "domainStrategy": "UseIP"
  }
}

• 일반 HTTPS와 로컬 처리 모드: 이 글에서는 https:// 주소를 사용합니다. https+local://로 임의 변경하지 마세요. 해당 방식의 로컬 처리 경로에는 이 글의 라우팅 전제가 그대로 적용되지 않습니다.
• 노드 연결 시 필요한 DNS: 프록시 서버 주소가 도메인이라면 프록시가 연결되기 전에 해당 주소를 조회할 수 있어야 합니다. 아직 연결되지 않은 프록시에 노드 도메인의 최초 조회를 의존하게 만들지 마세요.
• 규칙 병합: 광고 차단, LAN 또는 사용자 지정 도메인 규칙을 이미 사용 중이라면 하나씩 병합하세요. 기존 라우팅 설정 전체를 덮어쓰면 안 됩니다.

5. 클라이언트 적용 및 검증: 실행 설정을 확인한 뒤 DNS 요청을 점검하세요

v2rayN은 서로 다른 코어의 설정을 생성할 수 있으며, 이 글의 필드는 Xray 전용입니다. v2rayNG는 Xray를 사용하지만, UI 설정에 따라 DNS 매개변수 일부가 생성되거나 덮어써질 수 있습니다. v2flyNG는 V2Fly를 사용하므로 필드 이름이 비슷하다는 이유만으로 이 설정을 그대로 적용하면 안 됩니다. 설정 메뉴 위치는 클라이언트 버전에 따라 달라질 수 있으므로, 실행 후 생성된 설정과 로그를 기준으로 확인하세요.

1. 백업: 현재 연결 가능한 설정과 라우팅 규칙을 보관하고, 활성 노드와 선택한 코어, 시스템 프록시 또는 VPN 상태를 기록하세요.
2. 병합: 현재 클라이언트에서 제공하는 DNS 편집 또는 사용자 지정 설정 메뉴를 통해 내용을 입력하세요. DNS 객체의 내용만 입력할 수 있다면 바깥쪽 {"dns": ...}까지 붙여넣지 마세요.
3. 확인: 실행 설정에 dns-internal 태그와 DNS 전송 규칙 두 개, 올바른 아웃바운드 태그가 유지됐는지 확인하세요. 코어를 다시 시작한 뒤 알 수 없는 필드, 누락된 데이터 파일 또는 존재하지 않는 아웃바운드 오류가 있는지 살펴보세요.
4. 그룹별 테스트: 현재 geosite:cn 목록에 포함된 것이 확인된 도메인 하나와 매칭되지 않는 도메인 하나를 선택하세요. 관련 캐시를 지우거나 새 테스트 도메인을 사용한 뒤 실제 조회 연결을 확인하세요.
5. 앱별 설정 재확인: 브라우저의 보안 DNS, Android 비공개 DNS, 앱 제외 목록을 각각 확인하세요. 브라우저가 자체적으로 전송한 DoH 요청을 내장 DNS 조회로 오해하지 마세요.

Windows에서는 필요한 경우 아래 명령을 실행해 시스템 DNS 캐시를 비울 수 있습니다. 이 명령은 브라우저의 별도 캐시와 원격 서버 캐시, 코어 자체 캐시를 지우지 않습니다. 따라서 실행 후 새 조회 로그가 없더라도 설정이 작동하지 않는다고 단정할 수 없습니다.

ipconfig /flushdns

nslookup example.com 223.5.5.5는 시스템에서 지정한 DNS 서버까지의 연결을 테스트할 뿐, Xray의 내장 DNS를 자동으로 사용하지 않습니다. 마찬가지로 브라우저에서 사이트가 열린다는 사실은 실제 트래픽 경로가 작동한다는 뜻이지, DNS 분기가 올바르다는 증거는 아닙니다. 도메인이 코어로 전달되는지, 어느 DNS 서버로 조회되는지, 어떤 아웃바운드가 사용되는지를 함께 확인해야 합니다.

6. DNS 오염 및 유출 방지: 장애가 발생한 계층을 구분하세요

DNS 오염은 잘못된 주소나 비정상적인 주소가 반환되거나 조회가 실패하는 형태로 나타날 수 있지만, 한 번의 결과가 다르다고 해서 반드시 오염인 것은 아닙니다. CDN은 재귀 DNS 서버의 위치와 통신사, 네트워크 상태에 따라 서로 다른 주소를 반환할 수 있습니다. 연결 오류와 인증서 이상, 반복 조회 결과를 함께 살펴보세요. DNS 서버 두 곳의 응답이 다르다는 이유만으로 오염이라고 단정하면 안 됩니다.

DNS 유출 여부는 의도한 정책에 따라 판단해야 합니다. 이 글에서는 중국 본토 도메인을 직접 연결 DNS 서버로 조회하도록 설정하므로 해당 조회가 관찰되더라도 정책 실패를 의미하지 않습니다. 확인해야 할 부분은 원래 프록시를 거쳐야 할 조회가 로컬에서 직접 전송되는지, 가로채기 대상이 아닌 앱이 설정을 우회하는지입니다.

7. 자주 묻는 질문: 설정을 바꿨는데 결과가 달라지지 않는 이유