V2Ray DNS 설정 가이드: 도메인별 DNS 분할과 DNS 오염 대응

이 글의 핵심 내용

DNS 분할 설정에서는 ‘어떤 DNS 서버가 도메인을 조회할지’와 ‘조회 요청을 어떤 아웃바운드로 보낼지’를 함께 정해야 합니다. 노드 연결은 되지만 DNS 조회가 시간 초과되거나 도메인별 라우팅이 예상대로 동작하지 않는 사용자를 위해 V2Ray 형식의 JSON으로 필드 관계, 설정 병합, 검증 절차를 설명합니다. 예시는 설정 조각이며 바로 실행할 수 있는 전체 클라이언트 설정이 아닙니다. Xray 코어를 사용하는 경우 현재 코어가 지원하는 필드를 확인하세요.

1. DNS 조회 분할과 연결 분할은 다릅니다

먼저 알아둘 점은 클라이언트에 원격 DNS를 입력해도 모든 앱이 이를 사용하는 것은 아니라는 사실입니다. 브라우저에서 자체 암호화 DNS를 사용할 수 있고, 운영체제에는 별도의 캐시가 있으며, 프록시 프로토콜에 따라 도메인 조회를 서버 측에 맡길 수도 있습니다. 요청이 내장 DNS 모듈에 실제로 전달되어야 아래의 servers 규칙이 적용됩니다.

도메인이 코어에 전달됨 DNS 조회 요청 발생 조회 서버 규칙 확인 조회 경로 선택 주소 결과 반환

이 과정은 내장 DNS가 호출될 때의 흐름을 나타낼 뿐, 모든 프록시 연결이 로컬에서 DNS 조회를 거친다는 뜻은 아닙니다. 클라이언트가 도메인을 받은 뒤 라우팅에서 프록시 아웃바운드를 선택하면 도메인을 서버 측으로 그대로 전달할 수 있습니다. 반면 IP 기준 라우팅이 필요하거나 직접 연결할 대상 주소가 필요하면 로컬 DNS 조회가 발생할 수 있습니다. 실제 동작은 라우팅 정책과 아웃바운드 설정에 따라 달라집니다.

DNS 조회 분할: 도메인별로 어느 DNS 서버에 조회를 맡길지 정합니다. 주요 설정은 dns.servers입니다.
연결 분할: 트래픽을 직접 연결할지 프록시로 보낼지 정합니다. 주요 설정은 routing.rules입니다.
DNS 조회 경로 분할: DNS 서버에 접속할 때 직접 연결할지 프록시를 사용할지 정하며, 라우팅 규칙도 확인해야 합니다.

시스템 프록시는 프록시 설정을 따르는 앱의 요청을 주로 처리하며, 기기 전체의 DNS 요청까지 자동으로 가로채지는 않습니다. TUN을 사용하면 처리 범위를 넓힐 수 있지만 DNS 하이재킹, 라우팅, 제외 항목을 함께 설정해야 합니다. 스위치가 켜져 있는지만 보고 DNS 조회가 코어에 전달되는지 판단해서는 안 됩니다.

2. servers, domains, queryStrategy의 역할

servers는 사용할 DNS 서버 목록입니다. 각 항목의 domains는 해당 서버를 우선 사용할 도메인 범위를 지정하고, queryStrategy는 IPv4, IPv6 또는 두 주소 유형을 조회할지 결정합니다. 서로 다른 단계의 설정이므로 한 필드로 다른 필드를 대신할 수 없습니다.

필드	예시 값	기능
`servers`	IP 주소 또는 DoH 주소	사용할 DNS 서버와 각 서버의 도메인 매칭 조건을 정의합니다.
`domains`	`geosite:cn`	도메인 목록과 일치하면 해당 DNS 서버를 우선 사용합니다.
`queryStrategy`	`UseIP`	A와 AAAA 레코드를 모두 조회할 수 있지만, 두 주소 유형의 연결 가능성을 보장하지는 않습니다.
`queryStrategy`	`UseIPv4`	IPv4 주소만 조회합니다. IPv6 경로 문제를 확인할 때 유용합니다.
`skipFallback`	`true`	일치하는 도메인이 없을 때 일반적인 대체 서버 후보에서 해당 DNS 서버를 제외합니다.

domains는 엄격한 접근 허용 목록이 아닙니다. 조회에 실패한 뒤 다른 서버를 시도할지는 대체 조회 설정에도 영향을 받습니다. 아래 예시에서는 skipFallback을 사용해 도메인이 일치하지 않을 때 로컬 DNS를 일반적인 대체 서버로 사용하지 않도록 합니다. 그렇다고 일치하는 도메인의 조회가 실패하면 다른 DNS 서버를 절대 시도하지 않는다는 뜻은 아닙니다.

로컬 도메인용 DNS 서버

주소: 223.5.5.5
포트: UDP 53
매칭 범위: geosite:cn
대체 조회 역할: skipFallback: true

이 예시에서는 중국 본토 도메인 목록에 사용합니다. 사내 네트워크 전용 DNS를 뜻하는 것은 아닙니다.

기본 원격 DNS 서버

주소: https://1.1.1.1/dns-query
포트: TCP 443
매칭 범위: 로컬 도메인 목록에 일치하지 않는 도메인
조회 경로: 기존 프록시 아웃바운드를 명시적으로 지정

DoH로 조회 내용을 암호화합니다. 연결 가능 여부는 실제 네트워크와 프록시 아웃바운드에 따라 달라집니다.

geosite:cn은 실행 디렉터리의 도메인 규칙 데이터에 의존하며, 코어가 지역을 자동으로 판별하는 기능이 아닙니다. 시작 로그에서 규칙 파일을 찾지 못했다는 메시지가 나오면 먼저 리소스 파일을 복구하세요. 사내 도메인은 해당 domain: 규칙으로 매칭해 사내 DNS에 전달해야 합니다. 공용 DNS에 조회한 뒤 사내 IP가 반환되기를 기대해서는 안 됩니다.

3. 도메인별 DNS 분할 설정 예시

아래 예시에서는 로컬 DNS 서버 하나와 기본 DoH 서버 하나를 사용합니다. 중국 본토 도메인 목록은 로컬에서 우선 조회하고, 나머지 도메인은 원격 서버에서 조회하는 구성입니다. 먼저 설정을 백업한 뒤 최상위 dns 객체를 기존 JSON에 병합하세요. 같은 이름의 객체가 이미 있다면 기존 객체를 수정하고, dns 키를 중복으로 추가하지 마세요.

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

이 예시에서는 숫자 IP 주소 형식의 DoH 엔드포인트를 사용해 DNS 서버 도메인을 먼저 조회해야 하는 의존성을 피합니다. 도메인 형식의 DoH 주소를 사용한다면 해당 도메인을 어떤 DNS 서버가 조회할지, 그리고 조회 요청이 아직 연결되지 않은 DoH 서비스에 다시 의존하는 상황은 아닌지 확인하세요.

코어 확인: v2rayN은 클라이언트 인터페이스이며 V2Ray 코어와 같은 것이 아닙니다. 먼저 코어 시작 로그에서 현재 V2Ray와 Xray 중 무엇을 실행하는지 확인한 다음, 해당 필드의 지원 여부를 점검하세요.
규칙 파일 확인: 시작 로그에 geosite:cn 로드 실패가 없어야 합니다. 실패했다면 도메인 매칭의 전제부터 성립하지 않습니다.
생성된 설정 확인: 인터페이스에서 설정을 생성하는 경우 클라이언트를 재시작하면 수동 변경 사항이 덮어써질 수 있습니다. 클라이언트가 지원하는 사용자 지정 설정 메뉴에 저장한 뒤, 코어에 실제로 전달된 설정을 확인하세요.
주소 유형 확인: 기본적으로 UseIP를 유지해 IPv4와 IPv6를 모두 사용하세요. IPv6 문제를 확인할 때만 일시적으로 UseIPv4로 변경하고 결과를 비교해 기록하세요.

이 설정 조각에는 인바운드, 프록시 서버, 아웃바운드 정의가 없으므로 단독으로 실행할 수 없습니다. Android의 v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 두 앱의 인터페이스에 모두 ‘DNS’ 항목이 있더라도 설정 덮어쓰기 방식과 실행 모드를 각각 확인하세요.

4. DNS 조회를 올바른 아웃바운드로 보내기

DNS 서버 주소만 지정하고 조회 경로를 설정하지 않으면 ‘원격 DNS가 실제로는 직접 연결되는’ 상황이 생길 수 있습니다. 일반적인 https:// DoH 요청은 코어 라우팅을 거칠 수 있습니다. 일부 코어에서 지원하는 https+local://은 로컬 접속 방식이므로 같은 주소 형식처럼 바꿔 쓸 수 없습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "223.5.5.5/32"
        ],
        "port": "53",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32"
        ],
        "port": "443",
        "outboundTag": "proxy"
      }
    ]
  }
}

다음은 설정 병합을 위한 별도 예시입니다. 기존 아웃바운드 태그가 실제로 direct와 proxy라고 가정합니다. 태그는 설정에서 참조하는 이름일 뿐 코어가 자동으로 생성하는 객체가 아닙니다. 예시의 이름을 실제 태그로 바꾸고, 조회 규칙 두 개는 먼저 일치할 수 있는 포괄적인 규칙보다 앞에 배치하세요. 이 두 규칙으로 기존 트래픽 분할 규칙을 덮어쓰지 마세요.

이 예시의 일반 DNS UDP 포트

443

이 예시의 DoH TCP 포트

2개

조회 경로를 명시하는 규칙

핵심은 조회 아웃바운드를 먼저 확인한 뒤 DNS 서버의 속도를 비교하는 것입니다

로그에서 DoH 연결이 직접 연결 아웃바운드를 선택한 것으로 확인되면 규칙 순서와 태그 참조부터 수정하세요. DNS 서버 주소를 바꿔도 잘못된 조회 경로는 해결되지 않습니다.

AsIs는 라우팅 단계에서 IP 규칙을 위해 도메인을 먼저 조회하지 않는다는 뜻이지, 트래픽 연결에 DNS 조회가 전혀 필요 없다는 뜻은 아닙니다. IPIfNonMatch로 바꾸면 도메인 규칙에 일치하지 않는 요청을 IP로 비교하기 전에 먼저 조회할 수 있습니다. IPOnDemand를 사용하면 IP가 필요한 규칙을 만났을 때 조회가 발생할 수 있습니다. 값을 바꾸기 전에 IP 규칙을 실제로 사용해야 하는지 확인하세요.

프록시 서버 자체의 도메인 조회도 확인해야 합니다. 프록시 서버에 연결하려면 그 프록시를 통해 DoH를 먼저 조회해야 하는 구성은 순환 의존성을 일으킵니다. 명확한 초기 조회 경로를 지정하거나 서비스 제공업체가 확인한 서버 주소를 사용하세요. 구독 설정의 서버 정보를 임의로 바꾸지 마세요.

5. DNS 오염 대응: 암호화, 조회 경로, 캐시를 함께 점검

DoH는 클라이언트와 DNS 서버 사이의 조회 내용을 보호하지만, 예상한 결과가 반환된다고 보장하지는 않습니다. DNS 서버의 지역별 정책, 웹사이트의 CDN 연결, 기기 캐시, IPv6 연결 상태에 따라 ‘주소가 다르거나’ ‘조회는 성공했지만 사이트가 열리지 않는’ 상황이 생길 수 있습니다. 두 DNS 서버가 반환한 IP가 다르다는 이유만으로 오염이라고 단정할 수는 없습니다.

먼저 조회 시작점을 확인하세요: 브라우저의 보안 DNS 기능이 운영체제의 DNS 설정을 우회할 수 있습니다. 문제를 확인하는 동안에는 이 기능을 잠시 끄고 비교한 뒤, 다시 사용할지 결정하세요.
그다음 조회 출구를 확인하세요: 코어 로그의 DNS 오류와 연결 아웃바운드를 확인하세요. 필요하다면 기기에서 패킷을 캡처해 의도하지 않은 UDP 53 요청이 나가는지도 점검하세요.
시스템 캐시를 구분하세요: Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지울 수 있습니다. 다만 이 명령으로 브라우저와 코어가 각각 보관하는 캐시까지 모두 삭제되지는 않습니다.
한 번에 한 가지씩 비교하세요: 같은 대상, 같은 노드, 같은 실행 모드에서 DNS 서버나 주소 유형 중 한 가지만 바꾸세요. 그래야 프록시 경로의 변경을 DNS 개선으로 잘못 판단하지 않습니다.

이 예시의 로컬 DNS 서버는 일반 UDP 조회를 사용하므로 해당 구간은 암호화되지 않습니다. 네트워크 환경상 평문 조회가 적절하지 않다면 연결 가능한 암호화 로컬 DNS를 선택하고 라우팅도 함께 설계하세요. 주소만 DoH로 바꾸고 연결 가능 여부, 인증서 검증, 아웃바운드 정책을 빠뜨리지 마세요.

핵심은 DNS 조회 성공과 서비스 연결 가능 여부를 따로 확인하는 것입니다

A 또는 AAAA 레코드를 받았다는 사실은 DNS 조회 단계에서 결과가 나왔다는 뜻일 뿐입니다. 다음으로 실제 서비스 연결에 사용된 주소와 아웃바운드, 오류 유형을 확인한 뒤 DNS 문제인지, IPv6 경로 문제인지, 프록시 연결 실패인지 판단하세요.

6. DNS 오류 검증 절차와 자주 묻는 질문

먼저 연결이 확인된 설정을 저장한 뒤 ‘코어 시작, 조회 전송, 결과 수신, 서비스 연결’ 순서로 확인하세요. 로그 상세도를 일시적으로 높이고 대상 하나만 재현해 동시 요청이 중요한 기록을 덮지 않게 합니다. 점검을 마치면 평소 로그 수준으로 되돌리고, 로그를 공유하기 전에는 구독 주소와 연결 자격 증명을 삭제하세요.

nslookup -type=A example.com 223.5.5.5
nslookup -type=AAAA example.com 223.5.5.5
ipconfig /flushdns

example.com은 설명을 위한 예약 예시 도메인입니다. 앞의 두 명령은 지정한 일반 DNS 서버에 직접 질의해 조회 경로가 작동하는지 확인합니다. 이 명령들은 V2Ray 내장 DNS를 자동으로 사용하지 않으며 DoH 요청이 프록시를 통해 전송되었음을 증명하지도 않습니다. 코어의 도메인별 라우팅을 확인하려면 실제 앱 요청을 보내고 코어 로그와 적용된 설정을 함께 확인하세요.

DNS를 바꿨는데 브라우저에는 왜 이전 결과가 표시되나요?

먼저 브라우저에서 자체 보안 DNS를 사용 중인지 확인하세요. 그런 다음 시스템 캐시를 지우고 브라우저를 다시 시작합니다. 코어가 실제로 실행 중인 설정에 새 주소가 포함되어 있는지도 확인하세요. 로드되지 않은 JSON 파일만 수정해도 현재 연결에는 반영되지 않습니다.

일반 DNS는 되는데 DoH는 계속 시간 초과되는 이유가 뭔가요?

먼저 DoH 주소의 TCP 443 연결이 예상한 아웃바운드를 선택하는지 확인한 다음, 노드가 정상인지와 시스템 시간이 올바른지 점검하세요. 로그에 인증서 오류가 있다면 인증서 검증을 끄지 말고 시간, 엔드포인트, 네트워크 간섭을 확인하세요.

UseIPv4로 바꾸니 사이트가 열립니다. 무엇을 확인해야 하나요?

대개 IPv6 경로를 점검해야 한다는 의미이지, 기존 DNS가 오염되었다는 증거는 아닙니다. A와 AAAA 결과를 비교하고 기기의 기본 경로, 노드의 IPv6 아웃바운드 지원 여부, 대상 연결 오류를 확인한 뒤 주소 유형을 계속 제한할지 결정하세요.

공용 DNS에서 사내 도메인을 찾을 수 없는 이유는 무엇인가요?

사내 도메인 접미사를 별도로 매칭해 사내 DNS에 전달하고, 조회가 사내망을 통해 직접 연결되는지 확인하세요. 관련 주소가 TUN을 거친다면 로컬 네트워크 라우팅과 제외 항목도 점검해야 합니다. 공용 DNS에는 일반적으로 사내 영역의 데이터가 없습니다.

구독을 갱신한 뒤 설정이 사라졌습니다. 생성된 파일을 다시 수정해야 하나요?

먼저 사용자 지정 DNS 설정이 클라이언트 전역 설정, 설정 템플릿, 개별 프로필 중 어디에 속하는지 확인하세요. 클라이언트가 지원하는 영구 설정 메뉴에 저장한 뒤 코어를 재시작하고 생성 결과를 확인하세요. 실행 중 임시 파일을 반복해서 수정하지 마세요.

최종 확인 기준은 ‘DNS 서버를 몇 개 입력했는지’가 아니라 다음 세 가지입니다. 로컬 도메인은 예상한 DNS 서버에 매칭되고, 원격 조회는 예상한 아웃바운드를 사용하며, 서비스 연결은 기존 라우팅에 따라 완료되어야 합니다. 인터페이스의 설정 위치와 구성 형식을 더 확인하려면 클라이언트 설정 가이드와 기술 참고서를 참조하세요.