V2Ray DNS 설정 가이드: 분할 DNS, DoH 서버 및 DNS 오염 방지

1. 먼저 DNS 요청을 처리하는 주체 확인하기

DNS 설정이 적용되지 않는 흔한 원인은 서버 주소가 잘못된 것이 아니라, 조회 요청이 애초에 의도한 리졸버에 전달되지 않는 것입니다. Windows 시스템 리졸버, 브라우저의 보안 DNS, V2Ray 내장 DNS, 프록시 서버가 실행되는 컴퓨터의 리졸버는 서로 다른 단계입니다. 한 곳을 수정해도 다른 단계까지 함께 바뀌지는 않습니다.

위 흐름은 일반적인 사례일 뿐, 모든 연결이 내장 DNS를 사용하는 것은 아닙니다. 예를 들어 브라우저가 HTTP 프록시에 도메인을 전달하면 프록시 아웃바운드가 원격에서 도메인을 처리할 수 있습니다. 반대로 애플리케이션이 먼저 로컬에서 도메인을 조회한 뒤 IP 주소를 프록시에 전달하면 커널에는 IP 주소만 도착할 수도 있습니다. “시스템 프록시 → 시스템 프록시 자동 구성”만 활성화해도 Windows의 모든 DNS 요청이 가로채지는 않습니다.

• 시스템 프록시: 주로 시스템 프록시 설정을 따르는 애플리케이션에 영향을 줍니다. 모든 DNS 요청을 전달하는 전역 스위치는 아닙니다.
• TUN 모드: 트래픽을 가로채는 범위는 넓어지지만, DNS까지 가로채는지는 실제 사용 중인 커널과 TUN 설정, 라우팅에 따라 달라집니다.
• 내장 DNS: 커널이 도메인을 조회해야 하는 경우에 결과를 제공합니다. dns를 설정해도 시스템의 53번 포트에서 자동으로 서비스가 시작되는 것은 아닙니다.
• 브라우저 보안 DNS: 브라우저가 자체적으로 DoH 서버에 연결할 수 있으므로, 브라우저와 클라이언트 중 어느 쪽에서 DNS 조회를 관리할지 먼저 정해야 합니다.

2. servers, domains, expectIPs의 역할

servers는 사용할 업스트림 리졸버를 정의합니다. 서버 객체의 domains는 지정한 도메인을 해당 서버에 우선 조회하도록 설정하고, expectIPs는 그 서버가 반환할 주소의 허용 범위를 지정합니다. 각각 “어디에 물어볼지”, “어떤 도메인을 우선 조회할지”, “어떤 결과를 허용할지”를 제어하므로, 모두 트래픽 라우팅 규칙으로 이해해서는 안 됩니다.

domains는 배타적인 접근 제어가 아닙니다. 해당 서버의 조회가 실패하거나 결과가 expectIPs를 만족하지 않으면 이후 폴백 단계로 넘어갈 수 있습니다. 중국 본토용 리졸버가 지정된 도메인만 처리하게 하려면 skipFallback: true를 설정하고, 기본 후보로 도메인 제한이 없는 원격 리졸버를 하나 남겨 두세요.

3. DNS 분할 예시: 중국 본토 도메인은 현지 DNS 우선, 나머지는 DoH

중국 본토 도메인의 우선 리졸버로 223.5.5.5를, 기본 DoH 업스트림으로 https://1.1.1.1/dns-query를 사용합니다. 여기서 “현지 DNS”란 이 컴퓨터에서 지정한 리졸버에 직접 연결한다는 뜻이며, 라우터나 통신사에서 자동으로 할당한 DNS를 사용한다는 뜻은 아닙니다. 주소는 설정 예시일 뿐이므로 실제 네트워크에서 접속 가능 여부와 응답의 적합성을 확인해야 합니다.

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

geosite:cn에 일치하면 중국 본토용 리졸버를 우선 조회하고, 일치하지 않으면 도메인 제한이 없는 DoH를 후보로 사용합니다. 중국 본토용 리졸버의 결과가 주소 조건을 충족하지 못하면 다음 후보로 넘어갈 수도 있습니다. 도메인 제한이 없는 localhost를 무심코 추가하지 마세요. 시스템 리졸버가 폴백 경로에 다시 포함되어 원래 설정하려던 범위가 무너질 수 있습니다.

expectIPs: ["geoip:cn"]은 엄격한 정책입니다. 일부 중국 본토 사이트는 해외 CDN을 사용하므로 정상적인 결과도 거부되어 조회 시간이 길어질 수 있습니다. 이런 사이트에서는 해외 IP를 곧바로 “오염”으로 단정하지 말고, 해당 도메인과 반환 IP를 확인한 뒤 도메인 그룹이나 이 서버의 예상 범위를 조정하세요.

4. DoH를 프록시로 연결하려면 라우팅 규칙도 설정하세요

DoH는 리졸버까지의 전송을 암호화하지만 요청이 자동으로 프록시를 통과하도록 보장하지는 않습니다. V2Ray에서는 일반 https:// DoH 요청을 라우팅할 수 있지만, https+local:// 로컬 모드는 같은 방식으로 라우팅 처리되지 않습니다. 원격 DoH가 노드의 아웃바운드를 사용하게 하려면 두 방식을 혼용하지 마세요.

아래는 기존 설정에 병합해야 하는 구성 조각입니다. outbounds에 태그가 direct인 직접 연결 아웃바운드와 태그가 proxy인 사용 가능한 프록시 아웃바운드가 이미 있어야 합니다. 실제 태그가 다르면 해당 태그로 바꾸세요. 두 업스트림 주소 규칙은 먼저 일치할 수 있는 포괄적인 규칙보다 앞에 배치하세요.

{
  "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"
      }
    ]
  }
}

• 두 전략 이름을 혼동하지 마세요: dns.queryStrategy는 조회할 주소 계열을 제어하고, routing.domainStrategy는 라우팅을 매칭할 때 도메인을 어떻게 처리할지 제어합니다. 두 설정의 역할은 서로 다릅니다.
• AsIs는 IP 규칙을 위해 도메인을 직접 조회하지 않습니다: 일반 웹 연결에 도메인만 포함되어 있다면 geoip:cn만으로 모든 사이트가 자동 분할 라우팅될 것으로 기대할 수 없습니다. 사이트별 도메인 라우팅 규칙을 별도로 설정해야 합니다.
• 규칙은 주소와 포트를 모두 지정합니다: 모든 443 트래픽을 같은 아웃바운드로 보내는 예시가 아니라, 지정한 리졸버에 연결하는 트래픽만 처리합니다.
• IP 형식의 DoH 주소 사용: 업스트림 호스트 이름을 먼저 조회해야 하는 단계를 줄일 수 있지만, 해당 서비스는 IP 주소에 맞는 유효한 TLS 인증서를 제공해야 합니다. 임의의 DoH 도메인을 IP 주소로 바꾸면 안 됩니다.

기본적으로 어떤 규칙에도 일치하지 않는 연결은 기본 아웃바운드로 전송되며, 일반적으로 아웃바운드 순서에 영향을 받습니다. DoH의 아웃바운드 확인을 생략한 채 “응답이 왔다”는 이유만으로 “프록시를 통해 조회했다”고 판단하지 마세요. 노드 서버가 도메인을 사용한다면 노드 주소를 조회할 수 있는 별도의 부트스트랩 경로도 마련해야 합니다. 노드에 연결해야 노드 주소를 조회할 수 있는 순환 의존을 피할 수 있습니다.

5. v2rayN에 적용하기 전, 되돌릴 수 있는 기준 설정을 보관하세요

v2rayN은 설정을 관리하는 클라이언트이지 DNS 프로토콜 자체가 아닙니다. 클라이언트 화면에서 저장한 옵션은 최종적으로 커널 실행 설정으로 변환됩니다. 임시 생성 파일을 직접 수정하면 노드를 바꾸거나 커널을 다시 시작할 때 변경 내용이 덮어써질 수 있습니다. 또한 V2Ray JSON을 다른 커널용 설정 영역에 입력하면 시작에 실패할 수 있습니다.

1. 현재 상태를 기록하세요. 기존 DNS 설정, 현재 노드, 라우팅 모드를 저장해 두세요. 설정을 변경하기 전에 기존 구성으로 자주 사용하는 웹사이트를 열 수 있는지 확인하세요.
2. 설정 메뉴를 확인하세요. “설정 → DNS 설정”에서 현재 커널에 맞는 설정 영역을 선택하세요. 해당 버전에 전체 DNS JSON 편집기가 있다면 요구되는 DNS 객체 부분만 입력하고, 예시 파일 전체를 붙여 넣지 마세요.
3. 전체 설정은 별도로 관리하세요. 라우팅과 아웃바운드를 직접 관리하려면 “서버 → 사용자 지정 구성 서버 추가”를 사용해 전체 커널 설정을 가져올 수 있습니다. 이 글의 두 구성 조각에는 인바운드와 프록시 아웃바운드 등이 빠져 있어 완성된 설정으로 바로 실행할 수 없습니다.
4. 커널을 다시 시작하고 로그를 확인하세요. 네트워크를 테스트하기 전에 JSON 구문 오류, 규칙 데이터, 아웃바운드 태그 오류를 먼저 확인하세요. 저장에 성공했다고 실행까지 성공한 것은 아닙니다.
5. 기능을 하나씩 추가하세요. 먼저 기본 DoH를 확인하고, 다음으로 중국 본토 도메인 우선 조회를 추가한 뒤 TUN이나 브라우저 자체 DNS 설정을 점검하세요. 한 번에 한 가지 요소만 변경하면 문제 발생 지점을 찾기 쉽습니다.

로컬 혼합 리스닝 포트는 DNS 포트가 아닙니다. 애플리케이션의 HTTP 또는 SOCKS 프록시를 해당 포트에 연결하는 것과 DNS 서버 주소로 해당 포트를 입력하는 것은 전혀 다른 작업입니다. “설정 → 매개변수 설정”에서 “로컬 혼합 리스닝 포트”를 확인하고, 예시의 53, 443, 10808을 서로 바꿔 사용하지 마세요.

6. DNS 분할과 오염 방지 확인: 조회, 아웃바운드, 결과를 각각 점검하세요

검증의 목표는 “항상 올바른” 조회 IP를 찾는 것이 아닙니다. 요청이 의도한 업스트림에 전달되는지, 연결이 의도한 아웃바운드를 통과하는지, 반환 주소가 사이트의 실제 배포 환경과 맞는지를 확인하는 것입니다. CDN은 리졸버의 위치, 노드의 아웃바운드, 시간에 따라 서로 다른 주소를 반환할 수 있습니다. 두 리졸버의 결과가 다르다는 사실만으로 DNS 오염을 증명할 수는 없습니다.

nslookup www.baidu.com 223.5.5.5
ipconfig /flushdns
curl.exe --proxy http://127.0.0.1:10808 --head https://www.microsoft.com/

위 명령은 각각 별도의 확인 작업입니다. 첫 번째는 지정한 리졸버를 테스트하고, 두 번째는 Windows DNS 캐시를 비우며, 세 번째는 로컬 HTTP 프록시 연결을 테스트합니다. 세 번째 명령을 실행하기 전에 포트를 설정 화면에 표시된 실제 값으로 바꾸세요. 이 명령들은 내장 DNS의 자동 검증 스크립트가 아닙니다. 특히 nslookup 결과만으로 “DoH 분할이 적용됐다”고 판단해서는 안 됩니다.

시스템 캐시를 비워도 브라우저와 커널의 모든 캐시가 함께 삭제되는 것은 아닙니다. 다시 테스트할 때는 커널과 테스트 애플리케이션을 재시작할 수 있습니다. 로그 수준을 일시적으로 높였다면 테스트 후 평소 설정으로 되돌리세요. 디버그 로그에 방문한 도메인이 포함될 수 있으므로 로그 전체를 공개 업로드하지 마세요.

7. DNS 분할 관련 자주 묻는 질문