V2Ray DNS 분할 설정: 중국·해외 도메인별 DNS 및 DNS 오염 방지

이 글의 핵심 내용

DNS 분할 설정에서는 ‘어느 서버가 조회할지’와 ‘조회 요청이 어느 출구로 나갈지’를 함께 정해야 합니다. 노드 연결은 정상이며 중국·해외 도메인 규칙을 세분화하려는 사용자를 위해 시스템 DNS와 코어 DNS의 차이, 서버 선택과 라우팅 정책, 설정 예시를 살펴보고 로그로 결과를 확인합니다. 일반 시스템 프록시 환경에서는 FakeDNS를 바로 켤 필요가 없습니다. 먼저 재현 가능한 기본 설정부터 구성하면 문제를 찾기 쉽습니다.

1. DNS 분할의 전제: 요청이 코어로 전달되어야 합니다

V2Ray에 DNS 주소를 입력해도 컴퓨터의 모든 앱이 해당 주소를 사용하는 것은 아닙니다. 내장 DNS는 라우팅에서 대상 IP를 확인하거나, 일부 아웃바운드에서 도메인을 조회하거나, DNS 인바운드 전달을 설정한 경우처럼 코어가 직접 처리해야 하는 조회에 주로 쓰입니다. 앱이 직접 보내는 DNS 요청은 적절한 가로채기 또는 전달 경로를 거쳐야 이 규칙에 들어옵니다.

앱에서 도메인에 접속 프록시가 대상 수신 라우팅에서 DNS 조회 DNS 서버 선택 아웃바운드 규칙 적용

이 흐름은 ‘앱이 도메인을 프록시에 전달하고 라우팅에서 DNS 조회가 필요한’ 경우를 설명합니다. 도메인 규칙만으로 프록시 아웃바운드가 결정되면 코어는 대상 IP를 로컬에서 조회하지 않고 도메인 자체를 원격 서버로 전달할 수 있습니다. 앱이 먼저 도메인을 조회한 뒤 IP를 프록시에 전달했다면 코어에는 이미 도메인이 아닌 IP가 들어올 수도 있습니다.

연결 방식	일반적인 DNS 동작	확인할 항목
브라우저에서 HTTP 프록시 사용	프록시 요청에는 보통 도메인이 포함되지만, 브라우저가 별도로 DNS 조회나 프리페치를 할 수도 있습니다.	보안 DNS, 프록시 우회 목록
앱에서 SOCKS5 사용	앱이 도메인을 전달하거나 로컬에서 먼저 조회할 수 있습니다.	원격 도메인 조회 사용 여부
데스크톱 TUN 가로채기	가상 네트워크 어댑터의 라우팅과 DNS 가로채기 설정에 따라 달라집니다.	DNS가 실제 가로채기 경로로 들어오는지
Android VPN 모드	클라이언트가 트래픽을 가로챌 수 있지만, 제외된 앱은 기존 네트워크를 사용할 수 있습니다.	앱별 목록, 비공개 DNS 설정

v2rayN은 데스크톱 클라이언트이며, v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 화면에 ‘DNS’가 표시된다는 이유만으로 세 클라이언트의 설정을 그대로 옮겨 쓰면 안 됩니다. 이 글의 코드는 V2Ray/V2Fly에서 흔히 사용하는 기존 JSON 형식입니다. 실제로 불러올 수 있는지는 사용 중인 코어 버전과 클라이언트가 생성한 설정을 기준으로 확인하세요.

2. 내장 DNS는 DNS 서버를 어떻게 선택할까?

dns.servers에는 문자열 주소나 domains가 포함된 서버 객체를 넣을 수 있습니다. 객체에 지정한 규칙에 도메인이 일치하면 해당 서버가 우선 조회 대상이 됩니다. 여러 객체의 규칙이 동시에 일치하면 목록 순서도 영향을 줍니다. 배열의 첫 번째 항목은 항상 주 서버, 두 번째 항목은 항상 예비 서버라고 단순하게 이해하면 안 됩니다.

정적 매핑과 캐시를 확인하세요. 설정의 dns.hosts와 기존 캐시가 결과에 영향을 줄 수 있으므로 DNS 서버를 바꿔도 새로운 네트워크 조회가 바로 발생하지 않을 수 있습니다.
도메인 규칙에 맞는 서버를 선택합니다. 예를 들어 geosite:cn은 규칙 데이터베이스에 있는 도메인 집합을 가리킵니다. 도메인 접미사만 보고 해당 위치를 즉석에서 판단하는 방식이 아닙니다.
실패와 대체 조회를 처리합니다. 우선 서버에서 사용할 수 있는 결과를 얻지 못하면, 대체 조회가 허용된 설정에서 대체 후보 서버를 추가로 시도합니다. skipFallback: true로 표시된 서버는 일반적인 대체 후보에 포함되지 않습니다.
조회 결과를 반환합니다. 결과에는 조회 주소 계열, expectIPs 필터, 버전별 동작도 영향을 줄 수 있습니다. 재시도 여부는 해당 버전의 문서와 로그를 함께 확인하세요.

expectIPs는 조회 결과에서 특정 IP 범위를 걸러낼 수 있지만, 결과가 진짜인지 검증하는 기능은 아닙니다. 공유 CDN, 국경을 넘는 서비스 배포, 규칙 데이터베이스의 분류 차이 때문에 정상적인 결과가 걸러질 수도 있습니다. 처음 적용할 때는 이 옵션을 빼고 조회 경로가 안정된 뒤 따로 테스트하는 편이 좋습니다.

3. 중국·해외 도메인별 DNS 분리: DNS와 아웃바운드를 함께 설정

아래는 기존 설정에 병합할 수 있는 예시입니다. 중국 국내 분류 도메인은 223.5.5.5로 우선 조회하고, 나머지 도메인은 https://1.1.1.1/dns-query를 사용합니다. 후자는 일반 DoH 주소 형식으로 코어 라우팅에 연결하고, 대상 IP 규칙으로 프록시 아웃바운드를 선택합니다. 이 코드는 바로 실행할 수 있는 전체 설정이 아니며 노드 정보도 포함하지 않습니다.

예시 중국 국내 DNS의 UDP 포트

443

예시 DoH의 HTTPS 포트

2개

예시에 사용된 DNS 서버

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "223.5.5.5"
        ],
        "port": "53",
        "network": "udp",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "1.1.1.1"
        ],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:geolocation-!cn"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

먼저 아웃바운드 태그를 확인하세요. 여기서 사용하는 direct와 proxy는 기존 outbounds의 tag와 일치해야 합니다. 직접 연결 아웃바운드에는 보통 freedom을 사용하고, 프록시 아웃바운드에는 정상 작동을 확인한 노드를 연결합니다.
기본 아웃바운드를 확인하세요. 기존 설정 형식에서는 규칙에 일치하지 않는 연결이 보통 첫 번째 아웃바운드를 사용합니다. 이 예시에는 기본 아웃바운드가 정의되어 있지 않으므로 기존 설정에서 명확히 지정해야 합니다. 분류되지 않은 대상이 반드시 프록시를 사용한다고 가정하면 안 됩니다.
기존 규칙을 유지하세요. 클라이언트 설정에 병합할 때는 로컬 네트워크, 차단, 필요한 시스템 규칙을 유지하고 순서도 확인하세요. 라우팅에서는 처음 일치하는 규칙이 적용됩니다.
규칙 파일을 준비하세요. geosite:cn, geosite:geolocation-!cn, geoip:cn을 사용하려면 해당 규칙 데이터가 필요합니다. 분류가 없거나 파일을 읽을 수 없다면 먼저 로드 오류를 해결하세요.

요점: 먼저 DNS 조회의 아웃바운드를 확인한 다음 도메인 분류를 조정하세요

로그에서 DoH 연결이 여전히 직접 연결된다면 먼저 1.1.1.1:443의 라우팅과 아웃바운드 태그를 수정하세요. DNS 주소를 암호화된 주소로 바꾸는 것만으로는 아웃바운드 설정을 대신할 수 없으며 프록시 노드 자체에 연결할 수 없는 문제도 해결되지 않습니다.

예시의 IP 규칙은 같은 주소와 포트로 향하는 다른 연결에도 적용되며 DNS 트래픽만 구분하지 않습니다. 복잡한 설정에서는 코어가 지원하는 DNS 조회 태그를 사용해 구분할 수 있습니다. 일반 https:// 주소를 로컬 처리 의미가 포함된 https+local:// 주소와 바꿔 쓰지 마세요. 두 주소의 라우팅 동작은 다릅니다.

4. domainStrategy: DNS 조회를 시작할 때와 도메인을 유지할 때

routing.domainStrategy는 라우팅 판단 단계에서 IP를 어떻게 사용할지 제어하는 항목이지, ‘모든 DNS 조회를 프록시로 보내는’ 스위치가 아닙니다. 특히 라우팅 모듈의 동명 필드와 freedom 아웃바운드의 domainStrategy를 구분해야 합니다. 앞의 항목은 규칙 매칭 방식을, 뒤의 항목은 직접 연결 아웃바운드에서 대상 도메인을 처리하는 방식을 다루며 지원하는 값도 서로 다릅니다.

routing.domainStrategy	라우팅 단계의 동작	적용 방법
`AsIs`	도메인 대상에 대해 라우팅용 IP 조회를 별도로 시작하지 않습니다.	주로 도메인 규칙을 사용해 추가 조회를 줄입니다.
`IPIfNonMatch`	도메인이 라우팅 규칙에 일치하지 않으면 IP 조회 후 IP 규칙에 적용합니다.	도메인 규칙을 먼저 적용하고 IP 규칙으로 보완합니다.
`IPOnDemand`	매칭 중 IP가 필요한 규칙을 만나면 조회를 시작합니다.	IP 분류를 더 일찍 적용해야 할 때 사용합니다.

위 예시는 IPIfNonMatch를 사용합니다. 중국 국내 또는 중국 외 분류가 명확한 도메인은 먼저 도메인 규칙으로 분할하고, 미분류 대상만 조회한 뒤 geoip:cn으로 판단할 수 있습니다. 따라서 ‘해외 사이트에 접속했는데 로컬 DNS 조회가 보이지 않는’ 현상이 반드시 설정 오류를 뜻하는 것은 아닙니다.

로컬 DNS 조회를 줄이려면 신뢰할 수 있는 도메인 규칙부터 보완하세요. 처음부터 더 적극적인 조회 정책으로 바꾸지 않는 것이 좋습니다.
규칙이 잘못 분할되는 것 같다면 DNS 서버만 바꾸지 말고 먼저 실제로 적용된 첫 번째 규칙과 조회 결과를 확인하세요.
이미 대상이 IP로 들어왔다면 이 세 가지 옵션만으로 원래 도메인을 되살릴 수는 없습니다. 복원 가능 여부는 스니핑 정보와 FakeDNS 매핑 등의 조건에 따라 달라집니다.

5. FakeDNS: 가상 IP 매핑에는 전체 가로채기 경로가 필요합니다

FakeDNS는 웹사이트의 실제 서버 주소가 아니라 로컬에서 매핑을 관리하는 가상 IP를 반환합니다. 앱이 이 주소에 연결하면 코어가 매핑을 바탕으로 도메인을 복원해 라우팅이나 이후 프록시 처리에 사용합니다. 이 기능은 ‘앱이 먼저 DNS를 조회해 프록시에는 IP만 전달되는’ 정보 손실을 해결하는 것이지, DNS 요청을 자동으로 암호화하는 기능은 아닙니다.

DNS 요청이 가로채지는지 확인하세요. 앱의 조회가 FakeDNS에 도달하지 않으면 해당 매핑도 생성되지 않습니다. 설정에 주소 풀만 추가하는 것으로는 효과가 없습니다.
가상 IP 트래픽이 코어로 돌아오는지 확인하세요. 데스크톱 TUN이나 Android VPN의 라우팅이 해당 주소 풀을 포함해야 하며, 트래픽이 물리 네트워크로 나가면 안 됩니다.
도메인을 복원할 수 있는지 확인하세요. 해당 인바운드에는 코어가 지원하는 FakeDNS 스니핑 설정이 있어야 합니다. 관련 필드로는 sniffing.destOverride의 fakedns가 흔히 사용됩니다.
직접 연결 경로에서 실제 주소를 얻을 수 있는지 확인하세요. 도메인을 복원한 뒤에도 직접 연결 대상은 적절한 DNS 조회가 필요합니다. 가상 주소를 실제 서버 주소로 간주해 연결하면 안 됩니다.

일반 시스템 프록시 환경에서 앱이 도메인을 전달할 수 있다면 실제 DNS 조회 방식을 유지하는 편이 좋습니다. FakeDNS가 꼭 필요하다면 해당 클라이언트와 코어의 기능 설명을 먼저 읽고 가로채기 방식 하나만 켜세요. TUN, DNS 하이재킹, 스니핑, 라우팅 정책을 한꺼번에 바꾸면 어느 단계에서 연결이 끊겼는지 알기 어렵습니다.

6. 설정 확인: 먼저 로드 상태, 다음으로 DNS 조회와 라우팅 확인

DNS 문제를 해결할 때는 먼저 설정 로드 실패, 조회 시간 초과, 조회 성공 후 연결 실패를 구분해야 합니다. VMess 또는 VLESS 노드를 사용할 수 없다면 해당 노드를 경유하는 DoH도 시간 초과될 수 있습니다. 반대로 DNS에서 주소를 받아 왔다고 해서 노드 핸드셰이크, TLS 또는 대상 포트가 정상이라는 뜻은 아닙니다.

현재 상태를 기록하세요. 작동 중인 설정을 저장하고 클라이언트 버전, 실제 코어와 버전, 시스템 프록시 또는 VPN 모드, 앱별 제외 항목을 기록하세요. 구독을 업데이트하기 전후에는 사용 중인 노드가 바뀌지 않았는지도 확인해야 합니다.
설정을 바꾼 뒤 코어를 다시 시작하세요. 클라이언트의 DNS 또는 사용자 지정 설정 메뉴에서 저장한 다음 시작 로그를 확인합니다. 알 수 없는 필드, 규칙 데이터 로드 실패, 아웃바운드 태그를 찾을 수 없다는 오류가 있으면 웹사이트를 테스트하기 전에 먼저 해결하세요.
로그 상세도를 일시적으로 높이세요. 클라이언트 로그 설정에서 디버그 수준을 잠시 선택하고 대상 도메인, DNS 연결 주소, 아웃바운드 태그를 확인합니다. 테스트가 끝나면 평소 수준으로 되돌리고, 로그를 공유하기 전에는 노드 주소와 접속 기록을 삭제하세요.
분류별로 따로 테스트하세요. 중국 국내 규칙에 속하는 것으로 확인된 도메인 하나와 중국 외 분류에 속하는 도메인 하나를 고른 다음, 미분류 도메인도 테스트합니다. 각 유형은 연속으로 3회 접속하고 첫 조회와 캐시 적중 결과의 차이를 살펴보세요.
마지막으로 캐시를 배제하세요. 앱이나 코어를 다시 시작한 뒤 재시험하고, 필요하면 시스템 DNS 캐시를 지우세요. 매번 DNS 서버, 노드, 규칙 파일을 동시에 바꾸지는 마세요.

ipconfig /flushdns
nslookup www.baidu.com 223.5.5.5

아래는 Windows에서 확인할 때 사용하는 보조 명령입니다. 첫 번째 줄은 시스템 DNS 캐시를 지우고, 두 번째 줄은 지정한 서버에 직접 질의합니다. 두 번째 명령은 이 글에서 설명한 내장 DNS 서버 선택 과정을 거치지 않으므로 해당 서버에 기본적으로 연결할 수 있는지만 확인할 수 있습니다. DNS 분할이 제대로 작동하는지는 입증하지 못합니다. 조회에 실패하면 로컬 네트워크에서 UDP 53 직접 연결을 제한하는지도 확인하세요.

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

먼저 테스트 페이지를 닫았다가 다시 열고, 브라우저의 보안 DNS가 별도로 작동하는지 확인하세요. Windows에서는 ipconfig /flushdns를 실행한 뒤 클라이언트 코어를 다시 시작할 수 있습니다. 코어 캐시와 시스템 캐시는 별개입니다. 그래도 달라지지 않으면 앱이 시스템 프록시를 우회하는지 확인하세요.

중국 국내 사이트도 원격 DNS를 사용하는데 규칙을 반대로 쓴 건가요?

먼저 해당 도메인이 현재 geosite:cn 분류에 포함되는지 확인한 다음, 우선 서버의 조회 실패로 대체 조회가 발생했는지 살펴보세요. skipFallback: true를 대체 조회 금지로 간주하면 안 됩니다. DNS 연결이 더 앞에 있는 규칙에 의해 다른 경로로 빠지지 않는지도 확인하세요.

Android VPN에 연결했는데 일부 앱에서만 DNS 문제가 생기는 이유는 무엇인가요?

v2rayNG 또는 v2flyNG의 앱별 프록시 목록을 확인하고 시스템 ‘설정’에서 ‘비공개 DNS’ 상태를 기록하세요. 제조사에 따라 시스템 메뉴 이름이 다를 수 있습니다. 앱 자체의 암호화 DNS가 영향을 주는지 확인하려면 해당 기능을 잠시 제외하고 다시 테스트한 뒤, 원인을 확인하면 필요한 설정을 복원하세요.

DoH 요청이 시간 초과되는데 인증서 검증을 꺼야 하나요?

먼저 시스템 시간과 프록시 노드의 연결 상태를 확인하고, 1.1.1.1:443이 프록시 아웃바운드에 일치하는지 살펴보세요. 로그에서 연결 시간 초과와 인증서 오류를 구분하세요. 인증서 검증은 켜 둔 상태로 유지하고 라우팅 문제를 숨기기 위해 TLS 검증 조건을 낮추지 마세요.

목표는 모든 도메인을 같은 서버에서 조회하는 것이 아니라 도메인 분류, DNS 조회 아웃바운드, 실제 서비스 아웃바운드를 서로 일치시키는 것입니다. DNS 오염 방지 설정은 신뢰할 수 없는 조회 경로의 영향을 줄여 주지만 규칙 분류의 정확성을 보장하지는 않습니다. 연결 로그와 인증서 검증, 정기적인 관리도 계속 필요합니다.