V2Ray DNS 설정 가이드: 도메인별 DNS 분리와 DNS 오염 방지

1. 내장 DNS는 연결 과정에서 어디에 쓰일까

“DNS를 설정했는데 브라우저가 왜 시스템 DNS 서버에 질의할까요?” 보통 서버 주소가 잘못된 것이 아니라, 요청이 커널 DNS에 전달되지 않은 경우입니다. V2Ray와 Xray의 내장 DNS는 커널이 호출하는 DNS 모듈입니다. dns 항목을 추가한다고 해서 기기의 모든 UDP 53 요청을 자동으로 처리하지는 않습니다.

앱이 도메인을 SOCKS 프록시에 넘기면 커널은 도메인을 원격 서버로 그대로 전달할 수 있으며, 최종 조회는 원격 서버에서 이루어집니다. 앱이 먼저 시스템 DNS로 IP를 조회한 뒤 그 IP를 프록시에 넘기면, 커널이 받는 것은 원래 도메인이 아니라 IP입니다. 어느 경로도 “클라이언트 내장 DNS가 적용됐다”고 단정할 수 없습니다.

• 라우팅에 IP가 필요한 경우:routing.domainStrategy를 IPIfNonMatch로 설정하면 도메인 규칙에 일치하지 않을 때 라우팅에서 내장 DNS를 호출한 뒤 IP 규칙을 적용할 수 있습니다.
• 직접 연결 아웃바운드에 IP가 필요한 경우:Xray의 freedom 아웃바운드에서 UseIPv4와 같은 DNS 조회 전략을 사용하면 내장 DNS로 연결 주소를 조회합니다.
• 기기에서 일반 DNS 패킷을 보내는 경우:패킷을 수신하거나 전달 또는 가로채는 경로를 별도로 설정해야 합니다. DNS 서버만 지정해서는 처리되지 않습니다.
• 브라우저에서 보안 DNS를 사용하는 경우:브라우저가 HTTPS로 직접 DNS를 조회할 수 있습니다. 요청이 프록시를 거치더라도 여기서 설정한 내장 DNS 서버를 사용한다고 볼 수는 없습니다.

2. DNS 서버, 포트, 커널 경계 확인

이 예시에서는 중국 본토 도메인을 223.5.5.5로 조회하고, 그 외 도메인은 https://1.1.1.1/dns-query로 보내며 후자의 조회는 기존 프록시 아웃바운드를 거치게 합니다. IP 주소를 사용하는 DoH는 DNS 서버 도메인을 연결하기 위해 먼저 조회해야 하는 문제를 줄일 수 있습니다. 단, TLS 인증서 검증은 정상적으로 유지해야 합니다.

v2rayN은 데스크톱 클라이언트이며 특정 커널만 사용하는 것은 아닙니다. v2rayNG는 Xray를, v2flyNG는 V2Fly를 사용합니다. 같은 이름의 필드라도 지원 범위와 기본 동작은 실제 커널에 따라 확인해야 합니다. 특히 DNS 폴백 필드, 특수 주소 접두사, 아웃바운드 DNS 조회 전략은 Xray 설정을 모든 커널에 그대로 적용하지 마세요.

1. 현재 연결 가능한 설정을 백업하고 클라이언트 버전과 시작 로그에 표시된 커널 버전을 기록합니다.
2. 실행 설정에 프록시 아웃바운드가 있는지 확인하고 실제 tag 값을 기록합니다. 아래에서는 proxy를 사용하지만 프로토콜 이름을 바꾸라는 뜻은 아닙니다.
3. geosite.dat를 읽을 수 있고 cn 분류가 포함되어 있는지 확인합니다. 데이터 파일이 없으면 규칙 로드에 실패하며, 이는 DNS 서버 응답 시간 초과와 다른 문제입니다.
4. 설정하는 동안 한 번에 한 부분만 변경합니다. DNS를 먼저 수정하고, 라우팅을 변경한 뒤, 시스템과 브라우저가 별도로 DNS를 조회하는지 확인합니다.

3. 도메인별 DNS 서버 지정 및 실패 시 폴백 제한

아래는 최상위 dns 항목의 일부입니다. 중국 본토용 DNS 서버에는 도메인 일치 목록을 지정해 해당 도메인만 처리하게 합니다. DoH 서버에는 도메인 목록을 지정하지 않아 나머지 도메인의 기본 DNS 서버로 사용합니다. 처음에는 IPv4를 사용해 초기 문제 해결에서 IPv6 연결 가능성을 변수에서 제외합니다. IPv6를 계속 꺼 두라는 뜻은 아닙니다.

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

• domains는 DNS 서버에 적용하는 일치 조건이지, 전체 트래픽 라우팅 규칙이 아닙니다. 특정 DNS 서버로 도메인을 조회하도록 설정해도 웹 연결이 같은 아웃바운드를 자동으로 사용하는 것은 아닙니다.
• skipFallback: true는 이 DNS 서버를 일치하지 않는 조회의 폴백에서 제외합니다. 중국 본토용 DNS 서버가 다른 도메인의 조회까지 처리하지 않도록 합니다.
• disableFallback: true는 일치하는 DNS 서버의 조회가 실패했을 때 폴백하지 않도록 설정합니다. 전용 도메인 목록에 일치하지 않는 조회는 여전히 기본 DNS 서버가 처리합니다. “모든 조회에서 기본 서버를 사용하지 않는다”는 뜻은 아닙니다.
• queryStrategy: "UseIPv4"는 해당 DNS 조회의 IP 전략을 제한합니다. 시스템 수준의 IPv6 라우팅 관리까지 대신하지는 않습니다.

이 설정에는 localhost나 시스템 DNS를 대체 서버로 추가하지 않았습니다. 프록시 DoH에 연결할 수 없을 때 조회가 피하려던 기존 DNS 경로로 되돌아갈 수 있기 때문입니다. 시작 로그에 알 수 없는 필드가 표시되면 커널 문서와 버전을 먼저 확인하세요. 폴백 제한을 바로 지우고 문제가 해결됐다고 판단해서는 안 됩니다.

4. DoH는 프록시로 보내고 직접 연결에는 내장 DNS 사용

DoH 주소만 지정해서는 조회가 프록시 노드를 거치는지 알 수 없습니다. 일반 https:// 형식의 DoH 요청은 커널 라우팅 규칙을 적용할 수 있습니다. 아래 예시에서는 대상 IP와 포트를 지정해 proxy로 보냅니다. https+local://로 임의 변경하지 마세요. 로컬 조회 방식이 달라져 여기서 설명하는 라우팅 판단을 그대로 적용할 수 없습니다.

아래 규칙을 기존 라우팅 설정에 병합합니다. DNS 서버 규칙은 범위가 넓은 직접 연결 규칙, IP 분류 규칙, 최종 기본 규칙보다 앞에 둡니다. proxy는 실제 프록시 아웃바운드 태그로, direct는 기존 직접 연결 아웃바운드 태그로 바꿔야 합니다. 이 예시에서는 대상 IP로 중국 본토 트래픽을 분리하지 않으므로 AsIs를 사용해 알 수 없는 도메인을 라우팅 목적으로 추가 조회하지 않도록 합니다.

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

이 규칙은 최소한의 로직을 보여 주는 예시일 뿐입니다. 기존의 로컬 네트워크 우회 규칙이나 노드 주소 직접 연결 규칙 등 필요한 항목을 덮어쓰면 안 됩니다. 특히 노드 주소가 도메인인 경우, 노드 연결에 필요한 DNS 조회가 “이미 연결된 프록시”에 의존하면 시작 단계에서 순환 참조가 생깁니다. 클라이언트의 기존 노드 DNS 조회 방식을 유지하고, 해당 방식에서 어떤 DNS 서버를 사용하는지 별도로 확인할 수 있습니다.

직접 연결 아웃바운드도 확인해야 합니다. 아래는 기존 freedom 아웃바운드 객체에 병합하거나 이를 대체하는 설정입니다. 같은 이름의 아웃바운드를 하나 더 추가하라는 뜻은 아닙니다. 설정을 적용하면 중국 본토 도메인을 직접 연결할 때 내장 DNS로 IPv4 주소를 조회합니다.

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

5. v2rayN과 v2rayNG에서 설정 적용하기

그래픽 인터페이스의 DNS 페이지가 전체 Xray JSON을 지원하는 것은 아닙니다. 어떤 입력란은 DNS 서버 주소만 받으며, 어떤 페이지는 기본 설정과 고급 설정을 구분합니다. 먼저 입력란이 주소, DNS 객체, 전체 설정 중 무엇을 요구하는지 확인한 뒤 해당 형식에 맞게 입력하세요. 클라이언트가 임시로 생성한 실행 파일을 직접 편집하면 노드를 바꾸거나 재시작할 때 변경 내용이 덮어써질 수 있습니다.

1. 데스크톱에서는 설정 메뉴부터 확인:v2rayN에서 「설정」→「DNS 설정」을 열고 현재 커널에 해당하는 DNS 항목을 확인합니다. 이어서 「설정」→「라우팅 설정」에서 규칙 순서를 점검합니다. 버전에 따라 설정 탭을 사용하는 경우에는 화면에 표시된 실제 항목 설명을 따르세요.
2. 복잡한 규칙은 사용자 설정으로 구성:dns, routing, outbounds를 함께 제어해야 한다면 v2rayN의 「서버」→「사용자 지정 설정 서버 추가」에서 병합한 전체 설정을 가져옵니다. 기존 노드의 인증, 전송 방식, TLS 설정은 유지합니다.
3. Android에서는 실행 방식 확인:v2rayNG의 「설정」에서 VPN 모드와 DNS 관련 옵션을 확인합니다. 전체 사용자 지정 설정을 가져왔다면 목록에 저장만 된 것이 아니라 실제 실행 중인지 확인하세요.
4. 설정 형식을 섞어 쓰지 마세요:v2rayNG의 사용자 지정 원본 설정은 Xray 구조를 따라야 합니다. v2flyNG에서는 V2Fly의 필드 지원 범위를 확인해야 합니다. 구독 링크, 단일 노드 공유 링크, 전체 JSON은 서로 다른 입력 형식입니다.
5. 저장한 다음 연결을 다시 시작:시작 로그에서 JSON 파싱 오류, 알 수 없는 태그, 데이터 파일 읽기 오류가 있는지 확인합니다. 시작에 실패하면 먼저 백업을 복원하세요. 오류를 가리기 위해 여러 설정을 연달아 바꾸지 마세요.

6. DNS 분리와 오염 방지 설정 검증

검증 과정에서 세 가지를 확인해야 합니다. 어떤 DNS 서버가 조회를 받았는지, 조회가 어떤 아웃바운드를 거쳤는지, 앱이 최종적으로 어떤 주소에 연결했는지입니다. nslookup에서 사용 가능한 IP가 보인다고 커널 DNS가 적용됐다는 뜻은 아닙니다. 기본적으로 시스템 DNS 경로를 테스트하므로 비교 기준으로 활용할 수 있습니다.

테스트 전에 관련 캐시를 비웁니다. Windows에서는 아래 명령으로 시스템 DNS 캐시를 비운 다음 커널을 다시 시작해 프로세스 내부 캐시를 지울 수 있습니다. 브라우저에도 별도의 캐시가 있을 수 있습니다. 캐시된 도메인을 연달아 새로 고친 뒤 새 조회가 보이지 않는다는 이유로 설정이 작동하지 않는다고 판단하지 마세요.

ipconfig /flushdns
nslookup www.example.com

문제 원인을 찾을 때는 최상위 log.loglevel을 잠시 debug로 설정하고 연결 로그를 확인할 수 있습니다. DNS 관련 로그의 상세 내용은 커널 버전에 따라 다르므로 특정 문구 하나만 검색하지 마세요. 테스트가 끝나면 warning 또는 원래 수준으로 되돌립니다. 방문 도메인, 서버 주소, 인증 정보가 포함된 전체 로그를 공개하지 마세요.

• DoH가 계속 시간 초과되는 경우:프록시 노드의 연결 상태, proxy 태그, 규칙 순서를 먼저 확인한 다음 DNS 서버 주소에 연결할 수 있는지 점검합니다.
• 인증서 오류가 발생하는 경우:기기 시간과 TLS 인증서 검증 환경을 확인하세요. 인증서 검증을 끄는 것은 DNS 문제 해결 방법이 아닙니다.
• 중국 본토 웹사이트의 DNS 조회는 성공했지만 접속이 느린 경우:적절하지 않은 CDN 주소를 받았는지, 웹 트래픽도 직접 연결 규칙에 일치하는지 확인합니다.
• 테스트 페이지에 해외 DNS 서버가 표시되는 경우:예상한 경로와 비교해 판단하세요. 프록시 DoH를 사용하면 해외 재귀 DNS 서버가 표시될 수 있습니다. 서버의 지리적 위치만으로 DNS 유출이라고 단정할 수는 없습니다.

7. 자주 묻는 설정 질문