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

핵심 내용

먼저 도메인을 어디서 해석하는지 확인한 뒤, 중국 도메인 전용 DNS 서버와 그 외 도메인용 암호화 DNS 서버를 설정하고, 마지막으로 라우팅 규칙에서 DNS 요청의 출구를 지정합니다. 노드 연결에 성공했고 핵심 설정을 변경하려는 사용자를 위한 안내입니다. 예시는 설정 일부이며, 그대로 가져올 수 있는 완성된 노드 파일이 아닙니다.

1. 먼저 DNS 요청이 코어로 전달되는지 확인하기

먼저 두 가지를 구분해야 합니다. DNS 해석은 도메인을 IP 주소로 변환하고, 라우팅 분할은 연결을 직결할지 프록시로 보낼지 결정합니다. dns 항목만 수정해도 모든 앱의 DNS 요청이 자동으로 V2Ray에 전달되지는 않습니다. 프록시 규칙만 추가한다고 해서 앱이 먼저 받아 둔 주소가 올바르다는 보장도 없습니다.

앱이 도메인 전달 코어가 규칙 확인 필요한 주소 해석 연결 출구 선택

위 내용은 앱이 도메인을 코어에 전달하는 일반적인 흐름입니다. 앱이 이미 로컬에서 도메인을 해석한 뒤 IP 주소만 전달하면 코어가 받는 입력은 달라집니다. 브라우저의 보안 DNS, 시스템 DNS, 클라이언트 내장 DNS가 동시에 작동할 수도 있으므로 DNS 입력란 하나만 보고 실제 해석 경로를 판단할 수는 없습니다.

시스템 프록시 환경: 일반적으로 프록시 설정을 따르는 앱에만 적용됩니다. HTTP 프록시 요청에는 대상 도메인이 포함될 수 있지만, 다른 프로그램은 시스템 DNS를 직접 사용할 수 있습니다.
SOCKS 환경: 앱이 도메인을 SOCKS 프록시에 전달해야 합니다. 앱이 먼저 도메인을 직접 해석해 IP를 전달하면 내장 DNS의 도메인별 분할 설정이 적용되지 않을 수 있습니다.
Android VPN 환경: v2rayNG는 Android VPN 인터페이스로 트래픽을 처리하지만, DNS 처리 방식은 앱 설정, 앱별 규칙, 브라우저 동작에 따라 달라질 수 있습니다.
사용자 지정 설정 환경: 내장 DNS는 코어 내부의 도메인 해석에 사용할 수 있습니다. 외부 프로그램에서 보낸 DNS 패킷을 받으려면 해당 인바운드와 DNS 아웃바운드도 설계해야 합니다. dns.servers만 설정해서는 충분하지 않습니다.

2. servers, domains, expectIPs 이해하기

먼저 도메인을 그룹으로 나눈 다음 각 그룹에 사용할 DNS 서버를 지정합니다. servers는 DNS 서버 목록이며, 항목은 단순 주소일 수도 있고 조건을 포함한 객체일 수도 있습니다. 중국·해외 도메인을 나눠 해석하려면 객체 형식으로 설정하는 편이 동작을 확인하기 쉽습니다.

항목	용도	설정 시 참고 사항
`servers`	사용할 DNS 서버 목록	항상 목록의 첫 번째 서버만 사용한다고 볼 수는 없습니다. 매칭 조건과 폴백 설정에 따라 선택 결과가 달라집니다.
`domains`	우선 이 서버에 전달할 도메인 지정	`geosite:cn`을 사용하려면 코어가 해당 도메인 데이터 파일을 읽을 수 있어야 합니다.
`expectIPs`	응답 주소가 예상 범위에 속하는지 확인	`geoip:cn`은 IP 주소의 지역 분류 조건이며, 콘텐츠 안전성이나 도메인의 진위를 증명하지 않습니다.
`skipFallback`	이 서버가 매칭되지 않은 도메인의 폴백 조회에 참여할지 설정	`true`로 설정해도 해당 서버의 `domains`에 매칭되는 조회에는 사용할 수 있습니다.
`queryStrategy`	조회할 주소 유형 선택	`UseIPv4`는 IPv4만 조회하는 옵션이며, 시스템 전체에서 IPv6를 끄는 설정은 아닙니다.
`tag`	내장 DNS 조회에 출처 태그 지정	조회가 코어 라우팅을 거치는 경우 라우팅의 `inboundTag`로 매칭할 수 있습니다.

geosite는 도메인 분류 데이터이고 geoip는 IP 주소 분류 데이터이므로 서로 바꿔 쓸 수 없습니다. domains에는 domain:example.com처럼 해당 도메인과 하위 도메인을 매칭하는 형식도 사용할 수 있습니다. 특정 사이트 하나를 점검할 때는 분류 데이터 전체를 바꾸기보다 명확한 도메인 규칙을 추가하는 편이 원인을 찾기 쉽습니다.

판단 기준: expectIPs는 필터 조건이지 DNS 오염 방지 스위치가 아닙니다

해당 도메인에서 중국 본토 IP 주소를 명확히 기대하는 경우에만 geoip:cn 조건을 유지하세요. 사이트가 해외 CDN을 사용한다면 차단된 주소와 실제 지역을 먼저 확인한 뒤 규칙 범위를 좁히세요. 중국 본토 밖의 주소를 모두 오염으로 간주해서는 안 됩니다.

3. 중국 도메인은 우선 처리하고 나머지는 암호화 DNS로 조회하기

아래는 동작을 확인하기 쉬운 기본 설정입니다. 중국 도메인 분류는 223.5.5.5로 우선 조회하고, 그 외 도메인은 https://1.1.1.1/dns-query를 사용합니다. 후자는 HTTPS로 DNS 조회를 전송하는 DoH입니다. 예시에서는 IPv4를 사용해 듀얼 스택 환경의 변수를 줄였습니다. IPv6 자체에 문제가 있다는 뜻은 아닙니다.

{
  "dns": {
    "tag": "dns-query",
    "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",
        "skipFallback": false
      }
    ]
  }
}

예시 중국 DNS의 UDP 포트

443

HTTPS 기본 포트

2개

DNS 서버 설정 예시

여기서 skipFallback: true는 중국 DNS 서버가 매칭되지 않은 도메인의 일반 폴백 조회에 참여하지 않도록 하는 설정입니다. ‘중국 DNS 조회가 실패하면 절대 폴백하지 않는다’는 의미는 아닙니다. 중국 DNS 서버가 expectIPs에 맞는 결과를 반환하지 않으면 폴백이 비활성화되지 않은 경우 다른 적용 가능한 서버를 시도할 수 있습니다. 폴백과 강제 분리를 혼동하지 마세요.

설정을 시작하기 전에 코어가 geosite.dat 및 geoip.dat를 읽을 수 있는지 확인하세요. 분류 데이터를 불러오지 못했다는 오류가 나면 연결 품질을 점검하기 전에 데이터 파일 경로나 클라이언트 리소스부터 수정하세요.
일반적인 https:// 형식의 DoH 설정을 유지하면 뒤에서 설명하는 규칙에 따라 조회를 코어 라우팅으로 보낼 수 있습니다. 일부 코어에서 제공하는 로컬 직접 연결 방식은 이 경로를 우회할 수 있으므로, 그대로 바꾼 뒤에도 출구가 같다고 가정해서는 안 됩니다.
원격 DNS 서버에는 IP 주소 형식의 HTTPS 주소를 사용하면 DNS 서버 자체 도메인을 먼저 해석해야 하는 부담을 줄일 수 있습니다. 단, TLS 인증서는 정상적으로 검증해야 합니다. 연결 오류를 감추려고 인증서 검증을 끄지 마세요.
이 설정은 내장 DNS의 서버 선택을 제어하며 운영체제의 DNS 설정을 바꾸지는 않습니다. 모든 앱이 로컬 네트워크의 DNS 서버 사용을 중단했다고 판단해서는 안 됩니다.

4. 라우팅 규칙으로 DNS 요청의 출구 지정하기

먼저 기존 아웃바운드 태그를 확인하세요. 아래 예시는 태그가 direct인 직결 아웃바운드와 태그가 proxy인 사용 가능한 프록시 아웃바운드가 이미 있다고 가정합니다. 이는 예시에서 정한 이름일 뿐이며 DNS 설정만으로 생성되지 않습니다. 실제 태그가 다르면 각 항목을 기존 이름에 맞춰 바꾸세요. VMess 및 VLESS 노드 매개변수는 기존 설정을 유지합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-query"],
        "ip": ["223.5.5.5"],
        "port": "53",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["dns-query"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

규칙은 위에서부터 순서대로 적용됩니다. 첫 번째 규칙은 dns-query 태그가 있고 대상이 223.5.5.5:53인 요청만 직결합니다. 두 번째 규칙은 같은 태그가 붙은 나머지 요청을 프록시로 보냅니다. 범위가 넓은 DNS 프록시 규칙을 먼저 두면 중국 DNS 요청이 그 규칙에 먼저 매칭되어 ‘중국 DNS를 설정했는데도 우회 경로로 나가는’ 문제가 생길 수 있습니다.

DNS 전용 규칙을 범위가 넓은 규칙보다 먼저 배치하세요. 기존 설정에 전체 포트 직결, 전역 프록시 또는 인바운드별 일괄 분할 규칙이 있다면 어떤 규칙이 먼저 적용되는지 확인하세요.
IPIfNonMatch의 동작을 이해하세요. 도메인이 적용 가능한 규칙과 매칭되지 않으면 코어가 내장 DNS로 주소를 조회한 뒤 IP 규칙을 적용할 수 있습니다. 모든 도메인을 먼저 해석하라는 설정은 아닙니다.
기존 기본 출구 설정을 유지하세요. 이 예시에는 모든 트래픽에 적용되는 마지막 폴백 규칙이 없습니다. 매칭되지 않은 트래픽은 전체 설정의 기본 아웃바운드에 따라 처리되므로 병합할 때 아웃바운드 순서를 확인해야 합니다.
프록시 서버의 초기 도메인 해석을 확인하세요. 프록시 서버 주소가 도메인이라면 유일한 해석 경로가 아직 연결되지 않은 프록시에 의존해서는 안 됩니다. 해당 서버 도메인에 연결 가능한 별도의 초기 해석 경로를 지정할 수 있습니다.

5. 로그와 비교 요청으로 DNS 분할 결과 확인하기

웹페이지가 열리는지 비교하기 전에 어떤 장치가 해석을 담당하고 요청이 어느 출구로 나가는지 확인하세요. nslookup만 실행하면 보통 시스템에 지정된 DNS 서버를 테스트하게 되므로 V2Ray 내장 DNS가 규칙대로 작동한다는 증거가 되지 않습니다. DNS 누수 검사 페이지에 표시되는 주소도 대개 재귀 DNS 서버의 출구이지, 이 기기의 프록시 출구가 아닙니다.

로그 수준을 잠시 높이세요. 기존 log 객체의 loglevel을 debug로 바꾸고 코어를 재시작합니다. 테스트가 끝나면 warning으로 되돌려 도메인과 연결 정보가 장기간 기록되지 않도록 하세요.
테스트 경로를 다시 시작하세요. 코어를 재시작하면 이번 테스트에 영향을 주는 코어 캐시를 지울 수 있습니다. 테스트 앱도 닫았다가 다시 열고, 필요하면 앱 자체 DNS 캐시를 삭제하세요. 웹페이지 새로고침만으로는 새 조회가 발생하지 않을 수 있습니다.
중국 도메인 규칙에 명확히 매칭되는 도메인을 테스트하세요. 로그에 해당 DNS 조회가 기록되는지 확인하고 223.5.5.5:53으로 가는 요청이 direct를 사용하는지 살펴보세요. 캐시에 저장된 요청이나 도메인 라우팅 규칙에 바로 매칭된 요청은 코어에 새 해석 기록을 남기지 않을 수 있습니다.
중국 도메인 그룹에 없는 도메인을 테스트하세요. DoH 서버로 조회하는지, 연결이 proxy를 사용하는지 확인하세요. 코어마다 로그 형식이 다를 수 있으므로 서버 주소, 대상 도메인, 아웃바운드 태그를 함께 살펴보세요.
앱 경로와 로컬 해석 경로를 각각 테스트하세요. 데스크톱에서는 아래 두 명령을 비교해 볼 수 있습니다. 먼저 포트를 클라이언트에 표시된 실제 SOCKS 수신 포트로 바꾸세요.

curl --socks5-hostname 127.0.0.1:10808 -I https://example.com
curl --socks5 127.0.0.1:10808 -I https://example.com

첫 번째 명령은 SOCKS 프록시가 대상 도메인을 처리하고, 두 번째 명령은 curl이 로컬에서 도메인을 해석한 뒤 주소를 전달합니다. 10808은 명령 예시일 뿐이며 실제 수신 포트와 다를 수 있습니다. 두 명령이 모두 성공해도 코어가 직접 해석했다는 뜻은 아닙니다. 프록시 아웃바운드가 도메인을 원격 서버에 전달할 수도 있으므로 최종적으로 로그를 확인해야 합니다.

작업 판단: 요청이 멈춘 단계를 먼저 확인하세요

로그에 조회 기록이 없다면 캐시와 앱의 도메인 전달 여부부터 확인하세요. 조회 기록은 있지만 시간 초과가 발생한다면 DNS 서버의 연결 출구를 확인하세요. 주소를 받았는데도 연결에 실패한다면 라우팅, 노드, 대상 서비스를 점검하세요. 이 세 단계를 나눠 확인하는 편이 DNS 주소를 계속 바꾸는 것보다 효과적입니다.

6. DNS 분할 관련 자주 묻는 질문과 복구 방법

DNS를 변경한 뒤 모든 사이트가 열리지 않으면 무엇부터 확인해야 하나요?

먼저 백업을 복원해 노드가 여전히 작동하는지 확인한 다음 코어 시작 로그를 살펴보세요. JSON 문법 오류, 분류 데이터 로드 실패, 존재하지 않는 아웃바운드 태그부터 해결하세요. 코어가 시작된 뒤에는 DoH가 아직 초기 도메인 해석을 마치지 못한 프록시 서버 주소에 의존하는지 확인하세요.

중국 사이트가 간헐적으로 열리지 않으면 expectIPs 설정이 잘못된 건가요?

먼저 반환된 주소가 geoip:cn 조건 때문에 제외됐는지 확인하세요. 특정 도메인에 한해 이 조건을 잠시 제거하거나 범위를 좁힌 전용 규칙을 만든 뒤 재시작하고 다시 테스트하세요. 사이트가 실제로 해외 CDN을 사용한다면 DNS 서버가 오염됐다고 단정하지 말고 해당 사이트의 DNS 정책을 조정하세요.

DoH를 사용하는데도 검사 페이지에 현지 통신사가 표시되는 이유는 무엇인가요?

브라우저 ‘설정’의 보안 DNS와 시스템 DNS를 확인하고 앱이 프록시를 우회하는지도 살펴보세요. 코어 로그에 해당 도메인 요청이 실제로 기록되는지도 확인해야 합니다. DoH는 지정된 DNS 서버로 가는 해당 조회 경로만 암호화하며 모든 앱의 DNS를 일괄 처리하지는 않습니다.

구독을 업데이트한 뒤 DNS 설정이 다시 바뀌는 이유는 무엇인가요?

구독 노드 데이터와 클라이언트가 생성하는 코어 설정을 구분하세요. 실행할 때마다 다시 만들어지는 임시 JSON을 수정하지 마세요. 클라이언트에서 설정을 유지하는 DNS 메뉴나 사용자 지정 설정 메뉴에 저장해야 합니다. 업데이트 후 실제 적용된 설정을 다시 확인하고 dns 항목과 규칙 순서를 점검하세요.

IPv4만 조회하면 일부 앱에 문제가 생길 수 있나요?

IPv6가 필요한 대상에는 영향을 줄 수 있습니다. 먼저 UseIPv4로 기본 동작을 확인한 뒤 듀얼 스택을 지원하는 환경에서 UseIP로 변경하고 IPv6 라우팅과 출구도 점검하세요. AAAA 조회만 다시 켜고 해당 연결 경로를 빠뜨리지 않도록 주의하세요.

시작, DNS 해석, 연결이 모두 확인된 설정 사본을 마지막까지 보관하세요. 한 번에 변수 하나만 바꾸세요. 먼저 DNS 서버를 바꾸고, 다음으로 도메인 그룹을 수정한 뒤, 마지막으로 폴백과 주소 필터를 조정하면 됩니다. 설정 항목을 더 확인하려면 이 사이트의 설정 항목 안내를 열어 실제 코어 버전과 하나씩 대조하세요.