V2Ray DNS 분할 라우팅 설정 가이드: 중국 본토·해외 도메인 분리 조회와 오염 방지

이 글의 핵심

구독 가져오기와 기본 연결을 마쳤지만 도메인 조회 오류, 불안정한 분할 라우팅, 첫 접속 지연을 겪는 사용자에게 적합합니다. 목표는 중국 본토 도메인을 로컬 DNS에, 해외 도메인을 암호화 DNS에 맡기면서 DNS 결과에도 라우팅 규칙을 계속 적용하는 것입니다. DNS 조회 전략, 라우팅 도메인 전략, 시스템 DNS가 가로채지는 범위를 구분하고 로그와 명령 출력으로 실제 조회 경로를 확인할 수 있습니다.

DNS 분할은 단순히 속도만 해결하지 않습니다

클라이언트가 웹사이트에 접속할 때는 보통 먼저 도메인을 IP 주소로 변환한 다음, 라우팅 규칙에 따라 직접 연결·프록시·차단 중 하나의 아웃바운드를 선택합니다. 조회 결과가 잘못되면 VMess, VLESS 또는 하위 전송 설정이 모두 올바르더라도 연결이 엉뚱한 주소로 향할 수 있습니다. 적절하지 않은 지역에서 조회된 결과는 먼 서비스 노드를 반환할 수 있어, 핸드셰이크는 정상인데 첫 바이트가 늦어지는 현상으로 나타나기도 합니다.

중국 본토 도메인은 로컬 재귀 DNS를 사용하면 응답 거리가 짧고 현지 네트워크에 적합한 주소를 얻을 수 있습니다. 해외 도메인은 프록시를 통해 접근하는 암호화 DNS를 사용해 조회 변조나 잘못된 캐시의 가능성을 줄입니다. 핵심은 모든 조회를 한 서버에 강제로 맡기는 것이 아니라 도메인 규칙, DNS 서버, 최종 아웃바운드가 같은 방향으로 동작하게 만드는 것입니다.

도메인 요청규칙 판정리졸버 선택주소 반환아웃바운드 매칭

“클라이언트 내장 DNS”와 “운영체제가 실제 사용하는 DNS”도 구분해야 합니다. 시스템 프록시만 켜면 브라우저의 HTTP 트래픽은 v2rayN으로 들어올 수 있지만, 일부 앱은 여전히 시스템 리졸버를 직접 호출합니다. TUN 모드는 더 넓은 범위의 트래픽을 가로챌 수 있지만, 53번 포트 조회까지 처리하는지는 클라이언트가 생성한 인바운드, DNS 하이재킹, 라우팅 설정에 따라 달라집니다. 프록시가 연결되었다고 해서 모든 DNS 조회가 코어로 들어온다는 뜻은 아닙니다.

주의: DNS를 수정하기 전에 현재 작동하는 설정을 먼저 저장하세요. 서버 그룹, 조회 전략, 라우팅 전략 중 한 번에 하나만 조정하고 재연결 직후 테스트하세요. 여러 변수를 동시에 바꾸면 로그만으로 실제 원인을 찾기 어렵습니다.

헷갈리기 쉬운 네 가지 설정 계층부터 나누기

관리하기 쉬운 DNS 설정은 최소 네 계층으로 구성됩니다. 리졸버는 조회에 답하고, 도메인 규칙은 사용할 서버 그룹을 정하며, 조회 전략은 A·AAAA 중 무엇을 요청할지 결정하고, 라우팅 전략은 도메인 또는 IP를 얻은 뒤 어떤 아웃바운드와 매칭할지 정합니다. 이름이 비슷해도 각 계층의 역할은 다릅니다.

중국 본토 조회 그룹

서버: 223.5.5.5
포트: 53
도메인 범위: geosite:cn
주소 제약: geoip:cn

로컬 직접 연결 도메인에 사용하며, 조회 왕복 시간을 줄이는 데 우선순위를 둡니다.

해외 조회 그룹

프로토콜: DNS over HTTPS
전송 포트: 443
도메인 범위: geosite:geolocation-!cn
권장 아웃바운드: 프록시

암호화 조회도 프록시 아웃바운드로 라우팅해야 하며, 서버 주소만 입력해서는 충분하지 않습니다.

조회 전략

UseIP: 환경에 따라 주소 조회
UseIPv4: A 레코드만 요청
UseIPv6: AAAA 레코드만 요청
영향 대상: DNS 반환 유형

로컬 IPv6가 불안정하다면 먼저 UseIPv4로 주소 체인 문제를 배제하세요.

라우팅 도메인 전략

AsIs: 도메인 우선 유지
IPIfNonMatch: 도메인이 매칭되지 않을 때 조회
IPOnDemand: IP 규칙이 필요할 때 조회
영향 대상: 라우팅 규칙 매칭

이는 dns.queryStrategy와 같은 매개변수가 아니므로 서로 대신 사용할 수 없습니다.

expectIPs는 조회 결과가 예상 주소 범위에 맞는지 확인합니다. 예를 들어 중국 본토 도메인을 로컬 서버에 맡긴 뒤 결과가 geoip:cn에 포함되도록 요구할 수 있습니다. 결과가 조건에 맞지 않으면 코어가 다음 서버를 계속 시도할 수 있습니다. skipFallback은 현재 서버와 매칭된 도메인이 폴백에 참여할지 제어하며, 규칙 경계가 이미 명확한 그룹에 적합합니다.

결론: 먼저 트래픽의 귀속을 정한 뒤 조회 서버를 선택하세요

도메인을 직접 연결할 계획이라면 현지에서 접근 가능한 주소를 반환하는 리졸버를 우선 선택하세요. 프록시로 연결할 도메인이라면 조회와 접속 모두 프록시 경로를 거치게 해야 합니다. 단순히 “어느 DNS의 지연 시간이 짧은가”만으로 정렬하면 아웃바운드 지역과 맞지 않는 주소를 얻기 쉽습니다.

읽기 쉬운 그룹 설정 작성법

다음 예시는 Xray 코어에서 자주 사용하는 DNS 그룹 구조를 보여 줍니다. 필드 간 관계를 이해하는 용도로 적합하며, 클라이언트가 자동 생성한 전체 설정을 덮어쓰는 방식은 권장하지 않습니다. v2rayN, v2rayNG, v2flyNG에 탑재된 코어와 버전은 다를 수 있으므로 가져오기 전에 현재 코어가 해당 필드를 지원하는지 확인하세요.

{
  "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",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

첫 번째 서버 그룹은 중국 본토 도메인만 처리하고 주소 범위로 반환 결과를 제한합니다. 두 번째 그룹은 중국 본토 이외의 도메인을 처리합니다. 마지막 localhost는 폴백 항목이며 유지 여부는 환경에 따라 결정하세요. 시스템 리졸버가 자주 비정상 결과를 반환한다면 확실히 접근 가능한 다른 서버로 바꿀 수 있지만, 로그 근거 없이 폴백 항목을 과도하게 추가하지는 마세요.

암호화 DNS 주소 자체에 도메인이 포함될 수도 있습니다. 코어는 HTTPS 연결을 설정하기 전에 해당 서버 도메인의 IP를 알아야 하며, 이 과정을 부트스트랩 조회라고 합니다. IP 형식의 엔드포인트를 사용하면 순환 의존성을 줄일 수 있습니다. 도메인 엔드포인트를 사용한다면 로컬 서버가 안정적으로 조회할 수 있는지, 해당 조회가 아직 설정되지 않은 동일한 암호화 연결로 다시 재귀 진입하지 않는지 확인하세요.

도메인 집합에는 경계가 필요합니다:geosite:cn과 geosite:geolocation-!cn의 역할을 명확히 나누어 같은 도메인이 여러 서버 그룹에 동시에 매칭되지 않게 하세요.
DNS 아웃바운드는 별도로 확인하세요:암호화 조회가 원격 443번 포트를 사용하더라도 라우팅 규칙이 이를 실수로 직접 연결 아웃바운드로 보낼 수 있습니다.
최종 폴백을 남겨 두세요:어떤 도메인 목록에도 매칭되지 않을 때 조회에 응답할 수 있는 서버가 필요합니다. 그렇지 않으면 새 도메인의 조회가 즉시 실패합니다.
먼저 IPv4로 제한해 테스트하세요:네트워크에서 IPv6가 안정적이지 않으면 AAAA 결과 때문에 연결이 대기한 뒤 A 레코드로 폴백할 수 있습니다.

설정 안내:구독 업데이트는 보통 노드 정보만 교체하며 로컬 DNS와 라우팅 규칙까지 덮어쓰지는 않습니다. 구독을 업데이트한 뒤 사용자 지정 규칙이 현재 설정에서 계속 참조되는지 확인하세요.

v2rayN 및 Android 클라이언트 설정 순서

v2rayN 7.x에서는 먼저 「설정」→「매개변수 설정」으로 이동해 현재 코어, 시스템 프록시, DNS 관련 옵션을 확인한 다음 라우팅 설정에서 규칙 집합을 점검하세요. 세부 버전에 따라 메뉴 문구는 조금 다를 수 있지만, 트래픽 진입점을 확인하고 DNS를 설정한 뒤 라우팅 아웃바운드를 확인하는 순서는 유지해야 합니다. 수정 후 현재 연결을 중지하고 다시 시작해 새 설정이 재생성되도록 하세요.

진입 모드 기록:현재 시스템 프록시를 사용하는지 TUN을 사용하는지 확인하세요. 시스템 프록시의 로컬 HTTP 포트는 보통 10809, SOCKS 포트는 보통 10808이지만 실제 값은 클라이언트 화면을 기준으로 하세요.
DNS 서버 그룹 확인:중국 본토 그룹에는 현지에서 접근 가능한 서버를 입력하고, 해외 그룹에는 암호화 조회 엔드포인트를 입력한 뒤 각 그룹에 명확한 도메인 범위를 연결하세요.
라우팅 규칙 순서 확인:정확한 도메인 규칙을 광범위한 규칙보다 앞에 배치하고, 차단·직접 연결·프록시 규칙이 서로 겹치지 않게 하세요.
연결 재시작:설정을 저장한 뒤 다시 연결하고, 운영체제와 브라우저에 남아 있는 DNS 캐시도 삭제하세요.
코어 로그 확인:대상 도메인, DNS 서버 주소, 아웃바운드 태그, 실패 원인을 찾으세요. 지연 시간 테스트 결과만 확인해서는 안 됩니다.

v2rayNG는 Xray 코어를 사용하며, 보통 「설정」의 DNS·라우팅·VPN 서비스 관련 항목에서 조정합니다. v2flyNG는 v2fly 코어를 사용하므로 지원되는 설정 필드는 실제 코어 버전을 기준으로 해야 합니다. 두 클라이언트 모두 다른 코어의 전체 설정을 그대로 복사해서는 안 됩니다. 그래픽 인터페이스에서 서버와 조회 전략을 먼저 선택한 뒤 생성된 설정이 예상과 일치하는지 확인하는 편이 안전합니다.

기존 DNS에서 자주 사용하는 포트

443

HTTPS 암호화 조회 포트

853

TLS DNS에서 자주 사용하는 포트

10808

일반적인 로컬 SOCKS 포트

이 포트는 트래픽 위치를 파악하기 위한 기준일 뿐 모든 클라이언트가 같은 기본값을 사용한다는 뜻은 아닙니다. 예를 들어 로컬 리스닝 포트를 변경했는데 터미널 환경 변수가 여전히 10808을 가리키면 브라우저는 정상이고 명령줄만 실패하는 현상이 생길 수 있습니다. DNS를 점검할 때는 앱이 실제로 어느 로컬 진입점에 연결하는지도 함께 확인하세요.

중국 본토·해외 도메인이 실제로 분리 조회되는지 확인하는 방법

웹페이지가 열리는지만으로는 검증할 수 없습니다. 브라우저가 기존 연결을 재사용하거나 자체 DNS 캐시를 유지할 수 있기 때문입니다. 직접 연결이 확실한 중국 본토 도메인 하나와 프록시 연결이 확실한 해외 도메인 하나를 골라 조회 결과, 조회 시간, 코어 로그, 최종 아웃바운드를 각각 확인하세요.

확인 항목	예상 결과	이상 징후
중국 본토 도메인 조회	로컬 서버에 매칭되고 결과가 중국 본토 주소 범위에 맞음	조회가 해외 암호화 그룹으로 들어가 첫 접속 지연이 뚜렷하게 증가함
해외 도메인 조회	암호화 서버에 매칭되고 프록시 아웃바운드를 통해 연결이 설정됨	로그에 조회가 시스템 DNS로 직접 전송된 것으로 표시됨
A 및 AAAA 레코드	반환 유형이 queryStrategy와 일치함	접근할 수 없는 IPv6 주소만 반환되어 연결이 대기한 뒤 폴백함
라우팅 매칭	도메인 규칙과 최종 IP 규칙이 같은 아웃바운드를 가리킴	DNS는 프록시를 사용하지만 대상 연결이 IP 규칙에 의해 직접 연결로 변경됨

Windows 터미널에서는 nslookup으로 서버를 지정해 기준 테스트를 할 수 있습니다. 첫 번째 명령은 로컬 리졸버에 접근할 수 있는지 확인하고, 두 번째 명령은 현재 시스템 조회 경로를 확인합니다. 시스템 명령의 결과는 V2Ray 내장 DNS를 거치지 않을 수 있으므로, 대조 자료로 활용하는 것이 적절하며 코어의 분할 라우팅이 적용되었다는 단독 증거로 볼 수는 없습니다.

nslookup example.cn 223.5.5.5
nslookup example.com
ipconfig /flushdns

브라우저에서 테스트하기 전에 대상 페이지를 닫았다가 다시 열어 기존 연결을 재사용하지 않게 하세요. 그런 다음 v2rayN 실시간 로그에서 대상 도메인이 먼저 어떤 DNS 규칙에 매칭되는지, 이어서 연결이 direct·proxy·block 중 어떤 아웃바운드 태그에 매칭되는지 확인하세요. 로그에 IP만 표시되고 원래 도메인이 보이지 않는다면 트래픽 진입점이 도메인 정보를 유지하는지, 현재 프로토콜에 스니핑 설정이 적용되는지 점검하세요.

결론: 로그의 리졸버와 아웃바운드 태그를 검수 기준으로 삼으세요

같은 도메인을 연속 세 번 테스트하면 캐시 때문에 두 번째와 세 번째 테스트에서는 원격 조회가 거의 발생하지 않습니다. 먼저 캐시를 삭제하고 최초 조회 로그로 서버 그룹을 확인한 다음, 연결 로그로 최종 아웃바운드를 확인하세요. 두 항목이 모두 규칙과 일치해야 분할 라우팅이 완료된 것입니다.

자주 발생하는 실패 현상과 수정 방법

가장 흔한 문제는 암호화 DNS를 설정했지만 해당 DNS 자체가 직접 연결로 라우팅되는 경우입니다. 일반 노드는 연결되는데 해외 도메인은 계속 조회 시간 초과가 발생하는 식으로 나타납니다. 먼저 암호화 DNS 엔드포인트의 도메인 또는 IP가 어떤 규칙에 매칭되는지 확인한 뒤 명확한 프록시 아웃바운드 규칙을 추가하세요. 시간 초과가 발생한다고 백업 서버를 계속 늘리면 실제 조회 경로를 예측하기 어려워집니다.

시스템 프록시를 켰는데 왜 시스템 조회는 여전히 로컬 DNS를 사용하나요?

시스템 프록시는 주로 프록시 설정을 따르는 앱의 연결에 영향을 주며, 운영체제가 보내는 UDP 53 조회까지 반드시 가로채지는 않습니다. TUN, DNS 하이재킹, 앱 자체의 프록시 조회 기능을 함께 고려하고, 로그로 조회가 코어에 들어왔는지 확인해야 합니다.

중국 본토 웹사이트는 열리는데 이미지가 느리게 로드되면 어떻게 하나요?

페이지와 이미지는 서로 다른 도메인에서 제공될 수 있습니다. 정적 리소스 도메인이 geosite:geolocation-!cn 규칙에 의해 해외 조회 그룹으로 전송되는지, 반환 주소가 이후 IP 규칙에 의해 프록시로 변경되는지도 확인하세요. 실제 도메인에 정확한 규칙을 추가하고 최상위 도메인 전체를 무조건 허용하지는 마세요.

UseIPv4를 활성화하니 정상으로 돌아왔습니다. 계속 유지해야 하나요?

IPv6 주소에 접근할 수 없거나 라우팅이 없고 네트워크 품질이 불안정해서 생긴 문제일 수 있습니다. 현재 네트워크에 IPv4만 필요하다면 유지해도 됩니다. 이후 IPv6가 필요해지면 로컬 주소, 기본 라우팅, 프록시 노드의 IPv6 지원을 먼저 확인한 뒤 UseIP 테스트를 다시 진행하세요.

규칙 집합을 업데이트한 뒤 조회 결과가 갑자기 바뀌는 이유는 무엇인가요?

도메인이 새 분류로 이동했거나 클라이언트가 geosite 및 geoip 데이터를 업데이트했을 수 있습니다. 업데이트 전후의 매칭 규칙을 기록하고, 중요한 서비스 도메인에는 우선순위가 높은 정확한 규칙을 추가한 뒤 정상화되는지 확인하세요. 정확한 규칙은 적고 명확하게 유지해 관리하기 어려운 긴 목록이 되지 않게 하세요.

또 다른 흔한 문제는 브라우저에서 별도의 보안 DNS를 사용하면서 클라이언트에도 암호화 DNS를 설정한 경우입니다. 이때 조회가 클라이언트 그룹 로직을 우회해 로그에 대상 도메인이 나타나지 않을 수 있습니다. 문제를 찾는 동안에는 조회 진입점을 하나로 통일하세요. 브라우저 조회를 프록시로 보내 클라이언트가 처리하게 하거나, 브라우저 자체의 조회 엔드포인트와 프록시 경로를 명확히 기록해 두 전략이 동시에 작동하지 않게 해야 합니다.

조회 시간 초과: 조회 서버 접근성, 443 또는 853 포트 경로, 해당 아웃바운드 태그를 확인하세요.
반환 주소 이상: 도메인 그룹, expectIPs 범위, 로컬 캐시를 확인하세요.
웹페이지 간헐적 실패: A 및 AAAA 레코드, IPv6 접근성, Happy Eyeballs 폴백 대기 시간을 확인하세요.
규칙 미매칭: 도메인 규칙 우선순위, 라우팅 domainStrategy, 규칙 집합 버전을 확인하세요.
구독 업데이트 후 작동 중단: 클라이언트가 설정 그룹을 전환했는지, 사용자 지정 DNS가 현재 설정에 계속 연결되어 있는지 확인하세요.

안정적인 설정을 마무리하는 원칙

검증을 마친 뒤에는 중국 본토 조회 서버 그룹 하나, 해외 암호화 조회 서버 그룹 하나, 용도가 명확한 폴백 하나만 남기면 충분합니다. 서버 수가 많다고 안정성이 높아지는 것은 아닙니다. 도메인 경계와 폴백 조건이 없는 긴 목록은 무작위 매칭과 장애 분석 비용만 늘립니다.

라우팅 규칙도 같은 원칙을 따라야 합니다. 먼저 서비스에 필요한 정확한 도메인, 다음으로 geosite 분류, 마지막으로 IP 분류와 기본 아웃바운드를 배치하세요. DNS 그룹과 라우팅 그룹이 “중국 본토는 직접 연결, 해외는 프록시”라는 동일한 의도를 사용해야 조회 단계와 연결 단계가 서로 다른 결과를 내지 않습니다.

검증을 마친 작동 가능한 기본 설정을 저장하세요.
클라이언트 버전, 코어 유형, 진입 모드, 로컬 리스닝 포트를 기록하세요.
중국 본토와 해외에서 각각 고정 테스트 도메인 하나를 선택하세요.
규칙 집합 또는 구독을 업데이트한 뒤 최초 조회 테스트를 다시 실행하세요.
문제가 발생하면 “진입점, 리졸버, 주소 결과, 라우팅 아웃바운드” 순서로 로그를 읽으세요.

최종 검수 기준은 명확합니다. 중국 본토 도메인은 로컬 리졸버가 빠르게 합리적인 주소를 반환하고 직접 연결 아웃바운드에 매칭되어야 합니다. 해외 도메인은 암호화 리졸버로 조회하고, 조회 요청과 대상 연결이 모두 프록시 아웃바운드에 매칭되어야 합니다. 분류되지 않은 도메인에는 안정적인 폴백이 있어야 하며, IPv4와 IPv6 반환 유형은 현재 네트워크 환경의 역량에 맞아야 합니다. 이 네 가지를 충족한 뒤 캐시 시간, 규칙 세분화, 개별 도메인 예외를 조정하세요.