V2Ray DNS 설정 완벽 가이드: 중국 본토·해외 도메인 분할 해석과 DNS 오염 방지

DNS 해석과 트래픽 라우팅부터 구분하기

V2Ray 설정에서 DNS와 라우팅은 서로 이어지지만 별개의 단계입니다. DNS는 도메인을 주소로 해석하고, 라우팅은 연결을 어느 아웃바운드로 넘길지 결정합니다. 해석 결과가 올바르다고 해서 트래픽이 반드시 프록시를 통과하는 것은 아니며, 트래픽이 프록시 규칙에 매칭되었다고 해서 앞선 도메인 해석까지 원격 서버를 거쳤다는 뜻도 아닙니다. 분할 라우팅 문제를 점검할 때는 두 단계를 나누어 확인해야 합니다.

애플리케이션이 도메인 대상 주소를 V2Ray에 전달하면 라우팅 모듈은 도메인 규칙만으로 아웃바운드를 바로 판단할 수 있습니다. 규칙에서 대상 주소까지 확인해야 하거나 아웃바운드 연결을 수립하기 전에 주소가 필요할 때에만 내장 DNS 모듈이 해석에 참여합니다. 설정의 routing.domainStrategy가 이 과정에 영향을 줍니다. 일반적인 값은 AsIs, IPIfNonMatch, IPOnDemand이며, 지원 범위와 구체적인 동작은 사용 중인 코어 버전의 문서를 기준으로 확인해야 합니다.

AsIs: 도메인을 우선 유지하며, IP 라우팅 규칙에 매칭하기 위해 적극적으로 해석하지 않습니다.
IPIfNonMatch: 도메인 규칙에 매칭되지 않을 때 주소를 해석한 뒤 IP 규칙을 계속 확인합니다.
IPOnDemand: 라우팅 판단에 주소가 필요할 때 더 일찍 해석을 시작하므로, 설정에 따라 조회량이 늘어날 수 있습니다.

대부분의 “중국 본토는 직접 연결하고 나머지는 프록시로 연결”하는 구성에서는 IPIfNonMatch가 이해하기 쉬운 출발점입니다. 먼저 geosite 도메인 규칙을 적용하고, 매칭되지 않은 대상만 DNS로 주소를 얻은 뒤 geoip 규칙으로 판단합니다. 이렇게 하면 도메인 기반 분할 기능을 유지하면서 주소 기준으로만 판단할 수 있는 연결도 처리할 수 있습니다.

dns 설정의 핵심 필드

dns.servers는 전체 설정의 진입점입니다. 배열 항목에는 서버 주소를 직접 입력할 수도 있고, 매칭 조건이 포함된 객체를 사용할 수도 있습니다. 객체 형식에서는 address, port, domains, expectIPs를 설정할 수 있습니다. 실제 지원 필드는 V2Ray, Xray 및 클라이언트에 내장된 코어 버전에 따라 달라질 수 있으므로, 설정을 옮길 때 클라이언트 화면에 표시되는 버전만 확인해서는 안 됩니다.

필드	역할	설정 포인트
`servers`	사용할 수 있는 DNS 서버와 매칭 조건 정의	`domains`가 있는 서버는 해당 도메인을 우선 처리하고, 나머지는 기본 서버가 처리합니다
`hosts`	지정한 도메인에 정적 매핑 또는 도메인 매핑 제공	고정된 진입점과 초기 해석에 적합하며, 많은 동적 주소를 관리하는 용도에는 적합하지 않습니다
`queryStrategy`	IPv4, IPv6 또는 두 주소 유형을 조회할지 제어	로컬 네트워크 환경과 아웃바운드의 연결 가능 범위에 맞춰야 합니다
`clientIp`	관련 기능을 지원하는 DNS 서비스에 클라이언트 네트워크 대역 정보 제공	위치 판단과 개인정보 보호에 관련되므로, 용도를 이해하지 못한 상태에서 임의로 입력해서는 안 됩니다
`disableCache`	내장 DNS 캐시 제어	장기간 비활성화하면 중복 조회가 늘어나므로 일반적으로 단기 진단에만 사용합니다

hosts 처리는 외부 DNS에 조회를 보내기 전에 수행됩니다. 원격 해석 서비스가 도메인 주소를 사용하고 그 도메인 자체도 먼저 해석해야 하는 경우처럼, 소수의 고정 도메인에 대한 초기 의존성을 해결하는 데 적합합니다. 확인된 고정 주소로 초기 매핑을 제공하면 “원격 DNS에 먼저 연결해야 원격 DNS 도메인을 해석할 수 있는” 순환 의존을 피할 수 있습니다.

queryStrategy는 네트워크 조건에 맞춰 설정해야 합니다. 사용 중인 네트워크에서 안정적인 IPv4 연결만 가능하다면 UseIPv4부터 시작해 도달할 수 없는 IPv6 주소를 받은 뒤 발생하는 대기 시간을 줄일 수 있습니다. 완전한 듀얼 스택 환경이라면 두 주소 유형을 함께 조회할 수 있습니다. 이는 주소 체계 선택에 대한 설정이지 프록시 분할 설정은 아닙니다. IPv4만 조회하더라도 도메인은 중국 본토·해외 규칙에 따라 서로 다른 DNS 서버를 선택할 수 있습니다.

중국 본토 도메인은 로컬 DNS로, 나머지는 원격 DNS로 해석

다음은 기본 설정에 병합할 수 있는 DNS 예시입니다. 중국 본토 도메인은 geosite:cn으로 로컬 DNS 서버를 선택하고, geoip:cn으로 응답 범위를 확인합니다. 이 전용 규칙에 매칭되지 않는 나머지 도메인은 뒤에 배치한 원격 HTTPS DNS로 전달합니다. 예시 주소는 구조 설명을 위한 것이므로, 실제 배포 전에는 현재 네트워크, 코어 버전, 원격 아웃바운드에서 해당 서비스에 모두 접근할 수 있는지 확인해야 합니다.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

domains가 없는 마지막 항목은 기본 DNS 서버입니다. 앞선 규칙에서 명확히 처리하지 않은 도메인을 담당합니다. 사이트 분류 데이터가 모든 도메인을 포함할 수는 없으므로 기본 항목을 유지하는 것이 중요합니다. 새로 등록된 도메인, 사설 업무용 도메인, 아직 분류 데이터에 반영되지 않은 도메인에도 명확한 처리 경로가 필요합니다.

예시에서 같은 원격 DNS 주소를 “중국 본토 외 도메인 전용 서버”와 “기본 서버”로 각각 작성한 것은 매칭 로직을 명확히 보여주기 위해서입니다. 실제 설정은 사용 중인 코어의 DNS 선택 방식에 따라 간소화할 수 있습니다. 버전에서 동일 주소의 중복 항목을 예상과 다르게 처리한다면 기본 원격 서버만 남겨도 됩니다. 중국 본토 도메인은 첫 번째 항목에 매칭되고, 나머지는 자연스럽게 기본 항목으로 넘어갑니다.

geosite:cn은 도메인 분류이며, 해석 결과가 반드시 중국 본토 주소가 된다는 뜻은 아닙니다. 일부 중국 본토 사이트는 글로벌 CDN을 사용하므로 해석 결과가 네트워크 위치에 따라 달라질 수 있습니다. 반대로 중국 본토 분류에 포함되지 않은 도메인이 중국 본토 노드의 주소를 반환할 수도 있습니다. 따라서 도메인 분류와 주소 지역을 함께 사용해야 하지만 어느 하나도 절대적인 기준으로 보아서는 안 됩니다.

expectIPs로 비정상 응답 식별하기

expectIPs는 특정 DNS 서버가 반환할 것으로 예상되는 주소 범위를 지정합니다. 중국 본토 도메인을 로컬 DNS로 처리할 때 geoip:cn을 설정할 수 있습니다. 응답 주소가 예상 범위와 맞지 않으면 코어는 해당 결과를 조건 미충족으로 판단하고 DNS 서버 선택 로직에 따라 다른 후보를 시도할 수 있습니다. 이는 잘못된 해석의 영향을 줄이는 검사 장치이지, 모든 보호 기능을 단독으로 수행하는 스위치는 아닙니다.

규칙 경계가 명확한 환경에 가장 적합합니다. 예를 들어 중국 본토 분류 도메인만 처리하는 로컬 서버라면 예상 결과 대부분이 중국 본토 주소 범위에 속합니다. 명백히 맞지 않는 주소가 반환될 경우 원격 서버로 다시 조회하는 편이 합리적일 수 있습니다. 다만 CDN, 국경 간 서비스, Anycast 때문에 주소 지역은 복잡해질 수 있으므로 조건을 지나치게 엄격하게 설정하면 정상 응답을 비정상으로 오판할 수 있습니다.

모든 해외 도메인에 일괄적으로 geoip:!cn을 추가하는 것은 권장하지 않습니다. 많은 국제 서비스는 접속 위치에 따라 가까운 노드를 반환하며, 그중에는 중국 본토 주소가 포함될 수 있습니다. 한 도메인이 여러 지역의 주소를 동시에 반환하는 경우도 있습니다. 모든 결과가 중국 본토 외 범위에 속해야 한다고 강제하면 중복 조회, 해석 실패 또는 연결 지연이 발생할 수 있습니다.

expectIPs 설정은 다음 세 단계로 진행할 수 있습니다:

먼저 domains 그룹만 설정하고 각 도메인 유형이 실제로 대상 서버에 들어가는지 확인합니다.
그다음 경계가 안정적인 서버에 expectIPs를 추가하고 자주 사용하는 사이트에서 오판이 발생하지 않는지 관찰합니다.
마지막으로 폴백 동작을 확인해 비정상 응답이 적절한 후보 서버로 전환되고 해석이 즉시 중단되지 않는지 점검합니다.

expectIPs를 추가한 뒤 간헐적인 실패가 발생하면 먼저 실패한 도메인이 실제로 반환한 주소를 확인한 다음, 예상 범위를 넓힐지, 해당 도메인 분류를 제거할지, 아니면 해당 서버의 주소 제한을 취소할지 결정해야 합니다. 서버 순서를 반복해서 바꾸며 분류 오류를 숨기지는 마세요.

원격 DNS 조회를 프록시 아웃바운드로 전달

원격 DNS를 dns.servers에 입력하는 것은 사용할 DNS 서비스를 지정할 뿐, 연결 경로를 자동으로 보장하지는 않습니다. 원격 DNS 네트워크 요청도 라우팅과 아웃바운드를 거쳐야 합니다. 직접 연결하면 로컬 네트워크 경로의 영향을 받을 수 있고, 프록시로 접근하려면 DNS 서비스의 대상 주소에 명확한 규칙을 설정해야 합니다.

다음 라우팅 조각은 원격 DNS 주소를 proxy라는 태그의 아웃바운드로 전달하고, 중국 본토 도메인과 중국 본토 주소는 direct로 보냅니다. 마지막 규칙은 나머지 TCP 및 UDP 트래픽을 처리합니다. 규칙은 순서대로 매칭되므로 원격 DNS 주소를 더 포괄적인 직접 연결 주소 규칙보다 앞에 배치해야 합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "1.1.1.1"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "geoip:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

이는 라우팅 조각일 뿐이며, 기본 설정에는 태그가 정확히 일치하는 proxy와 direct 아웃바운드가 있어야 합니다. 태그는 대소문자를 구분하므로 라우팅에서 존재하지 않는 태그를 참조하면 설정 로드에 실패하거나 연결이 예상대로 수립되지 않을 수 있습니다.

원격 DNS가 도메인 형식의 서비스 진입점을 사용한다면 초기 해석도 고려해야 합니다. 코어는 HTTPS 연결을 수립하기 전에 서비스 진입점의 주소를 알아야 합니다. 주소 형식의 진입점을 사용하거나, 확인된 초기 매핑을 hosts로 제공하거나, 시스템 DNS가 이 단계만 담당하게 하는 방법이 있습니다. 원격 DNS 도메인을 자기 자신만 해석할 수 있는 구조로 만들지 마세요.

프록시 서버 주소에도 같은 초기 의존성이 존재합니다. 구독 노드가 도메인을 사용한다면 V2Ray는 프록시 채널이 아직 수립되지 않은 상태에서 먼저 노드 주소를 얻어야 합니다. 이러한 도메인에는 신뢰할 수 있는 초기 해석 경로를 사용해야 하며, 아직 사용할 수 없는 프록시 아웃바운드를 통해 조회하도록 강제해서는 안 됩니다.

DNS 오염 방지를 위한 핵심 설정

DNS 오염 방지는 로컬 DNS를 다른 주소로 바꾸는 것만으로 해결되지 않습니다. 전체 경로에는 최소한 조회 서버 선택, 전송 경로, 응답 검사, 캐시, 실제 연결이라는 다섯 부분이 포함됩니다. 어느 한 부분이라도 잘못된 경로를 사용하면 “처음에는 열리지만 새로 고침하면 실패”, “해석은 올바른데 직접 연결”, “노드를 바꿔도 이전 주소를 계속 사용” 같은 현상이 나타날 수 있습니다.

도메인 분류에 따른 DNS 서버 선택

중국 본토 도메인은 우선 로컬 DNS를 사용하면 현재 네트워크에 더 가까운 CDN 주소를 얻는 경우가 많습니다. 그 밖의 도메인은 원격 DNS를 사용해 로컬 재귀 해석 경로가 결과에 미치는 영향을 줄입니다. 분류되지 않은 도메인도 처리할 서버가 있도록 분류 규칙에 기본 출구를 둬야 합니다.

원격 조회는 제어 가능한 아웃바운드로 전달

일반 UDP 조회는 대상 서버가 달라도 중간 네트워크 경로의 영향을 받을 수 있습니다. HTTPS DNS는 암호화된 전송을 제공하지만, 예상한 아웃바운드를 통과하는지 여전히 확인해야 합니다. 서버 주소만 바꾸고 라우팅을 확인하지 않는 것만으로는 최종 경로를 판단할 수 없습니다.

캐시 조정은 장기 우회가 아닌 진단용

V2Ray 내장 DNS, 운영체제, 애플리케이션 모두 해석 결과를 저장할 수 있습니다. 설정을 변경한 직후 테스트하면 이전 결과가 계속 적용될 수 있습니다. 코어를 다시 로드하고 시스템 DNS 캐시를 비운 다음 관련 애플리케이션을 재시작해 보세요. 캐시 비활성화 옵션을 일시적으로 사용하면 문제 확인에 도움이 되지만, 장기간 캐시를 끄면 조회 횟수와 첫 연결 대기 시간이 늘어납니다.

브라우저와 애플리케이션의 독립 DNS 해석

일부 애플리케이션은 자체 암호화 DNS 설정을 사용하므로 도메인 조회를 시스템이나 V2Ray에 전달하지 않을 수 있습니다. 이 경우 V2Ray는 이후 연결 주소만 확인할 수 있고 도메인 라우팅 기능도 제한됩니다. 테스트하기 전에 애플리케이션의 해석 방식을 확인하고 내장 DNS가 실제로 사용되는지 판단해야 합니다.

v2rayN에서의 적용 및 검증 순서

v2rayN 구독은 서버 설정을 제공하며, DNS와 라우팅은 일반적으로 클라이언트 측 실행 설정에 속합니다. 구독을 업데이트한다고 사용자 지정 DNS 규칙이 원래대로 유지된다는 보장은 없습니다. 이는 사용 중인 설정 방식, 라우팅 설정, 클라이언트 버전에 따라 달라집니다. 변경 전에는 현재 정상 작동하는 설정을 저장하고, 변경 후에는 시스템 프록시 스위치만 전환하지 말고 코어를 다시 로드해야 합니다.

검증할 때 한 번에 많은 웹사이트를 테스트하지 마세요. 먼저 중국 본토 분류에 명확히 속하는 도메인 하나를 고르고, 원격 DNS로 해석되어야 하는 도메인 하나를 선택해 각각 DNS 로그와 라우팅 로그를 관찰합니다. 확인할 항목은 매칭된 DNS 서버, 해석된 주소, 매칭된 아웃바운드 태그, 최종 연결 성공 여부입니다.

설정이 정상적으로 로드되고 로그에 알 수 없는 필드, 누락된 태그 또는 JSON 형식 오류가 없는지 확인합니다.
중국 본토 도메인을 조회해 geosite:cn이 포함된 로컬 서버 객체에 매칭되는지 확인합니다.
그 밖의 도메인을 조회해 원격 기본 서버로 들어가는지 확인하고, 원격 DNS 연결이 프록시 아웃바운드를 통과하는지도 점검합니다.
실제 연결의 라우팅 결과를 확인해 DNS는 프록시를 통과하지만 실제 트래픽이 이후 규칙에 의해 직접 연결로 바뀌지 않는지 점검합니다.
테스트 도메인을 한 번 바꾸거나 캐시를 비워 이전 결과의 영향을 배제합니다.

v2rayNG 또는 v2flyNG를 사용하는 경우에도 판단 방법은 같지만, 설정 필드의 사용 가능 여부는 앱에 내장된 Xray 또는 v2fly 코어 버전에 따라 달라집니다. 버전을 확인하지 않은 상태에서 데스크톱 설정을 Android에 그대로 복사해서는 안 됩니다. 필드를 인식하지 못하면 먼저 코어 종류와 버전을 확인한 뒤 해당 설정 형식에 맞게 조정하세요.

자주 발생하는 문제와 진단 방법

중국 본토 사이트가 느리게 열림

먼저 중국 본토 도메인이 원격 기본 서버로 넘어갔는지 확인합니다. geosite 데이터가 로드되지 않았거나 분류 파일 버전이 맞지 않거나 도메인 자체가 목록에 없으면 기본 항목으로 들어갑니다. 또한 expectIPs가 지나치게 엄격해 로컬 서버가 반환한 정상적인 CDN 주소를 거부하고 원격 조회를 시작하는지도 확인해야 합니다.

원격 DNS를 설정했는데도 해석이 비정상임

원격 요청이 어느 아웃바운드를 통과하는지 중점적으로 확인합니다. 대상 주소가 geoip 규칙에 먼저 매칭되어 직접 연결로 처리되었거나, 규칙 순서가 잘못되어 proxy로 들어가지 않았을 수 있습니다. HTTPS DNS 연결 실패는 시스템 시간 오류, 대상 주소에 대한 네트워크 도달 불가, 프록시 노드가 아직 수립되지 않은 상태 때문에 발생할 수도 있습니다.

설정 시작 시 순환 해석이 발생함

대개 프록시 노드 도메인이나 원격 DNS 도메인이 프록시를 통해서만 해석되는데, 프록시 자체도 해당 해석 결과에 의존할 때 발생합니다. 해결 방법은 독립적인 초기 해석 경로를 마련하는 것입니다. 노드 도메인, 로컬 DNS 서버, 원격 DNS 진입점 사이의 의존 관계가 직접 연결 단계에서부터 차례로 성립해야 합니다.

주소는 올바른데 웹사이트가 잘못된 아웃바운드를 사용함

DNS와 실제 트래픽 라우팅을 나누어 확인해야 합니다. 도메인은 올바르게 해석되었지만 이후 geoip:cn 규칙이 반환 주소를 직접 연결로 보냈을 수 있고, 도메인 규칙이 더 앞에서 이미 다른 아웃바운드를 지정했을 수도 있습니다. 라우팅 규칙을 위에서부터 확인해 처음 매칭되는 항목을 찾고, 마지막 기본 규칙만 보아서는 안 됩니다.

변경 후 잠시 동안 결과가 반복해서 달라짐

대개 여러 계층의 캐시, CDN의 다중 주소 응답, 또는 애플리케이션 자체 DNS 해석과 관련이 있습니다. 관련 애플리케이션을 종료 후 다시 시작하고 V2Ray 코어를 다시 로드한 다음, 단일 테스트 도메인으로 반복 검증하세요. 로그에 새로운 조회 요청이 표시되지만 매번 주소가 다르다면 DNS 서비스가 정상적으로 부하 분산을 수행하는 것일 수 있으므로 주소가 바뀐다는 이유만으로 오염이라고 판단해서는 안 됩니다.

설정 마무리 점검

DNS 분할을 완료한 뒤 중국 본토 도메인, 로컬 네트워크 주소, 원격 도메인에 각각 명확한 처리 경로가 있는지 확인합니다. 이어서 원격 DNS의 연결 아웃바운드, 프록시 노드의 초기 해석, 기본 서버, 최종 기본 라우팅이 모두 존재하는지 점검합니다. 마지막으로 웹페이지가 열리는지만 보지 말고 로그로 검증하세요.

유지 관리하기 쉬운 설정은 대체로 단순합니다. 소수의 DNS 서버, 명확한 도메인 그룹, 제한적인 expectIPs 조건, 순서가 분명한 라우팅 규칙을 유지하세요. 분류를 세분화할수록 유지 비용이 커지고, 조건을 엄격하게 할수록 CDN과 동적 주소로 인한 오판이 늘어납니다. 먼저 작동하는 두 개의 해석 그룹을 만든 뒤 실제 로그를 보며 예외를 추가하는 편이 한 번에 많은 규칙을 넣는 것보다 안정적입니다.

전체 JSON 구조를 계속 확인해야 한다면 이 사이트의 JSON 매뉴얼을 참고해 dns, routing, outbounds의 계층 관계를 점검할 수 있습니다. 클라이언트 설정이 성공적으로 로드된 뒤 구독 노드, 시스템 프록시, 라우팅 분할을 항목별로 테스트해 연결 문제를 모두 DNS 탓으로 돌리지 않도록 하세요.