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

1. DNS 분리와 프록시 분리는 서로 다른 설정입니다

DNS 분리는 도메인을 IP 주소로 변환할 DNS 서버를 정하고, 라우팅 분리는 연결이 어느 출구로 나갈지 정합니다. 해외 도메인을 원격 DNS 서버에 지정해도 그 DNS 서버에 보내는 요청까지 프록시를 거친다는 뜻은 아닙니다. 반대로 웹 페이지가 프록시를 통해 열려도 브라우저가 그 전에 시스템 DNS로 도메인을 조회했을 수 있습니다. 두 경로를 각각 확인해야 합니다.

이 흐름은 앱이 도메인을 코어에 전달하고 라우팅 정책상 DNS 조회가 필요한 경우를 설명합니다. 도메인 규칙에서 프록시 아웃바운드가 바로 결정되면 라우팅 단계에서 DNS를 조회하지 않을 수 있으며, 목적지 도메인을 프록시 서버에서 조회할 수도 있습니다. 앱이 IP 주소만 전달하면 코어가 처음 조회한 도메인을 정확히 복원하기는 어렵습니다.

• DNS 오염: 잘못되었거나 외부 개입을 받은 조회 결과를 말합니다. IP 주소가 달라졌다는 사실만으로 오염이라고 단정할 수는 없습니다. CDN은 지역에 따라 서로 다른 주소를 반환할 수 있습니다.
• DNS 유출: 예상하지 못한 경로로 DNS 조회가 전달되는 현상입니다. 계획에 따라 중국 본토 도메인을 중국 본토 DNS로 직접 조회하는 것은 단순히 유출로 분류할 일이 아닙니다.
• 비효율적인 DNS 경로: 중국 본토 서비스에 원격 DNS가 멀리 있는 CDN 주소를 반환하면 연결이 완전히 끊기기보다 이미지 로딩이 느려지거나 동영상이 버퍼링될 수 있습니다.

2. 설정 위치에 따라 달라지는 세 가지 domainStrategy

V2Ray DNS 설정을 검색하다 보면 같은 이름의 필드가 여러 곳에서 보입니다. 필드의 위치에 따라 역할이 다릅니다. 라우팅의 domainStrategy, 직접 연결 아웃바운드의 같은 필드, DNS의 queryStrategy를 혼동하지 마세요.

처음 설정을 조정할 때는 IPIfNonMatch부터 적용해 보세요. 명시적인 도메인 규칙으로 먼저 출구를 정하고, 일치하는 규칙이 없을 때 IP 지리 규칙을 보완적으로 적용합니다. 모든 도메인을 먼저 조회하는 옵션도 아니며, 시스템의 모든 앱에서 발생하는 DNS 요청을 처리하지도 않습니다.

3. 도메인별로 중국 본토 DNS와 원격 DoH 지정하기

dns.servers의 서버 객체에서 domains로 우선 처리할 도메인 목록을 지정할 수 있습니다. 이 도메인 매칭은 DNS 서버를 선택할 뿐, 웹사이트에 접속하는 라우팅 규칙을 함께 만들지는 않습니다. 여기서는 중국 본토 UDP DNS와 원격 DoH를 사용해 각각의 선택 조건과 전송 방식을 설명합니다.

geosite:cn과 geosite:geolocation-!cn은 규칙 데이터에 등록된 분류이며, 서로 완전히 보완하는 전체 집합은 아닙니다. 일부 새 도메인은 두 목록 어디에도 없을 수 있으므로 원격 DNS 서버가 미분류 도메인의 대체 조회도 담당합니다. 두 목록이 겹치거나 데이터가 누락된 경우 현재 데이터 파일과 로그를 함께 확인하세요. 도메인 접미사만 보고 규칙 적용 여부를 추측해서는 안 됩니다.

• skipFallback: true라고 해서 이 서버를 절대 조회하지 않는 것은 아닙니다. 명시적으로 일치하는 도메인은 여전히 이 서버를 사용할 수 있으며, 이 설정은 주로 대체 서버 후보 선택에 영향을 줍니다.
• https://와 https+local://은 요청 경로가 다릅니다. 후자는 로컬 모드로 동작하므로 이 글에서 설명하는 코어 라우팅 가정을 그대로 적용할 수 없습니다.
• DoH 주소를 도메인 이름으로 지정하면 DoH 서버 도메인 자체를 처음 조회할 방법도 마련해야 합니다. 여기서는 IP 주소를 직접 지정해 이러한 의존성을 줄입니다.
• DoH는 DNS 조회가 DNS 서비스까지 전달되는 구간을 암호화합니다. DNS 서비스가 항상 적절한 결과를 반환한다고 보장하지 않으며, 라우팅 확인을 대신하지도 않습니다.

4. DNS와 라우팅 설정 병합하기: DNS 서버의 출구부터 지정

아래는 핵심 JSON 설정을 기존 구성에 병합하는 예시입니다. 기존 설정에 proxy라는 이름의 프록시 아웃바운드와 direct라는 이름의 직접 연결 아웃바운드가 있다고 가정합니다. 실제 이름이 다르면 해당 항목을 모두 바꾸고, 기존 inbounds, 노드 인증, 전송 및 TLS 설정은 유지하세요. 이 조각만으로 완성된 설정을 만들어 실행해서는 안 됩니다.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      }
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "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",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:geolocation-!cn"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

라우팅은 위에서부터 규칙을 확인해 먼저 일치하는 규칙을 적용합니다. DNS 전용 규칙을 일반 지리 규칙보다 앞에 두면 DNS 전송 경로를 더 쉽게 예측할 수 있습니다. 이 규칙은 목적지 IP와 포트로 일치 여부를 판단하므로 같은 주소와 포트로 전송되는 다른 연결에도 적용됩니다.

1. 기본 아웃바운드 확인: 어떤 규칙에도 일치하지 않는 트래픽은 보통 outbounds의 첫 번째 아웃바운드를 사용합니다. 분류되지 않은 트래픽을 기본적으로 프록시로 보내려면 규칙만 바꾸지 말고 첫 번째 아웃바운드가 실제로 원하는 프록시인지 확인하세요.
2. 규칙 데이터 확인: 시작 로그에 geosite 분류나 데이터 파일을 찾을 수 없다는 오류가 표시되면 규칙 데이터의 출처와 경로를 수정하세요. 오류가 난 규칙을 삭제하고 계속 실행하는 것으로 설정이 정상이라고 판단해서는 안 됩니다.
3. 직접 연결의 DNS 확인: 직접 연결 아웃바운드에서도 내장 DNS를 사용하려면 기존 freedom 아웃바운드의 settings에 "domainStrategy": "UseIP"를 설정하고, 현재 코어에서 지원하는지 확인하세요.
4. 노드 주소의 초기 조회 확인: 프록시 서버 주소가 도메인이라면, 아직 연결되지 않은 프록시에만 의존해 해당 도메인을 조회할 수는 없습니다. 시작 과정이 순환하지 않도록 사용할 수 있는 초기 DNS 조회 경로를 마련하세요.

5. 클라이언트에 설정 적용하기: 인터페이스 설정이 JSON을 덮어쓰지 않도록 확인

v2rayN은 인터페이스의 노드, DNS, 라우팅 설정을 바탕으로 실행 설정을 생성합니다. 임시로 생성된 파일을 직접 수정하면 노드를 바꾸거나 클라이언트를 다시 시작할 때 변경 사항이 사라질 수 있습니다. 현재 버전에서 제공하는 DNS 설정, 라우팅 설정 또는 사용자 지정 설정 메뉴를 우선 사용하세요. 메뉴 이름은 버전에 따라 다르므로 특정 버전의 경로를 모든 버전에 적용되는 고정 메뉴로 생각하면 안 됩니다.

1. 복구 지점 저장: 현재 노드, 시스템 프록시 모드, 라우팅 모드를 기록하고 설정을 내보내거나 관련 항목을 백업하세요. 한 번에 DNS와 필요한 라우팅만 변경하고 프로토콜이나 전송 매개변수는 함께 바꾸지 마세요.
2. 실행 설정 확인: 설정을 저장하고 코어를 다시 시작한 뒤 클라이언트에서 실행 설정이나 설정 미리보기를 확인해 dns.servers, 규칙 순서, 아웃바운드 태그가 실제로 반영되었는지 점검하세요.
3. 앱 연결 방식 확인: 데스크톱 앱은 시스템 프록시를 사용하거나 로컬 HTTP/SOCKS 포트에 명시적으로 연결해야 합니다. SOCKS를 테스트할 때는 클라이언트에 표시된 실제 포트를 사용하세요. 안내서의 포트 번호가 내 컴퓨터의 기본값이라고 가정하지 마세요.
4. Android의 VPN 적용 범위 확인: v2rayNG와 v2flyNG에서는 VPN 모드, 앱별 설정, DNS 옵션도 확인해야 합니다. 제외된 앱은 기존 네트워크 경로를 계속 사용할 수 있습니다.
5. 다른 DNS 설정과 분리: 테스트 전에 브라우저의 보안 DNS와 Android의 비공개 DNS 설정을 기록하세요. 필요하면 테스트하는 동안만 일시적으로 끄고 결과를 비교한 뒤 원래 의도한 설정으로 되돌리세요.

브라우저 내장 암호화 DNS는 코어의 도메인 분류를 우회할 수 있지만, 해당 연결 자체는 프록시를 거칠 수도 있습니다. 어떤 DNS 서버를 사용했는지와 연결이 어느 출구로 나갔는지를 각각 확인하세요. DoH를 사용한다는 사실만으로 DNS 분리가 제대로 적용되었다고 볼 수는 없습니다.

6. 포트, 로그, 비교 테스트로 분리 설정 확인하기

아래 숫자는 프로토콜 포트와 테스트 횟수이며, 성능 측정 결과가 아닙니다. 검증할 때는 중국 본토 규칙과 원격 규칙에 확실히 일치하는 도메인을 각각 하나 이상 선택하세요. 실제 사용하는 데이터셋에서 분류를 확인해 목록에 없는 도메인으로 규칙이 작동하지 않는다고 오판하지 않도록 합니다.

Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비울 수 있지만 브라우저와 코어에도 별도 캐시가 남을 수 있습니다. nslookup을 실행하면 일반적으로 시스템 DNS나 지정한 DNS 서버를 테스트합니다. 시스템 프록시를 켰다고 해서 코어의 DNS를 자동으로 테스트하는 것은 아닙니다. 로컬 DNS 수신 대기를 명시적으로 설정하고 조회가 실제로 해당 주소로 전송되는 경우에만 이 명령으로 해당 경로를 검증할 수 있습니다.

7. DNS 분리 설정 문제와 해결 순서

최종 설정으로 다음 세 가지를 설명할 수 있어야 합니다. 어떤 도메인이 중국 본토 DNS를 사용하는지, 어떤 DNS 조회가 프록시를 거쳐 원격 DNS 서버에 도달하는지, 분류에 일치하지 않는 도메인은 어떤 대체 경로를 사용하는지입니다. DNS 경로를 더 엄격하게 제어하려면 시스템 DNS, 브라우저 자체 DNS 조회, 네트워크 적용 범위도 별도로 계획해야 합니다. dns.servers 설정 하나만으로 기기 전체의 DNS를 제어할 수는 없습니다.