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

이 글 미리보기

먼저 앱이 도메인을 어디로 전달하는지 확인하고, 로컬·원격 리졸버를 설정한 뒤 DNS 요청과 실제 연결의 출구를 각각 점검합니다. 설정을 가져왔지만 일부 사이트에 접속할 수 없거나 조회 결과가 이상한 사용자를 위한 안내입니다. 단계별 점검표를 따라 중국 내 도메인은 직접 연결로 조회하고 해외 도메인은 필요에 따라 원격으로 조회하는 구성을 만들고, DNS 오염·유출과 일반적인 연결 장애를 구분할 수 있습니다.

1. DNS 조회, 라우팅, 프록시 연결을 구분하기

DNS는 도메인을 IP 주소로 변환합니다. 라우팅은 연결을 직접 연결할지 프록시를 통할지 결정합니다. 서로 관련은 있지만 같은 설정은 아닙니다. 원격 DNS 주소를 입력했다고 DNS 요청이 반드시 프록시를 통하는 것은 아닙니다. 특정 사이트를 프록시로 연결하도록 설정해도 브라우저가 그 전에 시스템 DNS로 조회하지 않았다는 뜻은 아닙니다.

앱에서 도메인 전달 규칙으로 대상 판별 필요한 경우 주소 조회 연결 출구 선택 대상 서비스에 접속

이 흐름은 점검 순서를 나타내며, 모든 연결이 로컬에서 먼저 DNS 조회를 마쳐야 한다는 뜻은 아닙니다. HTTP 프록시나 SOCKS 프록시는 도메인을 전달받아 원격에서 처리할 수 있습니다. 반면 IP 기준 규칙은 로컬 코어의 DNS 조회를 유발할 수 있습니다. 앱이 먼저 도메인을 조회한 뒤 IP를 프록시에 전달하면 클라이언트가 원래 도메인 정보를 활용하기 어려워질 수 있습니다.

클라이언트와 코어를 구분하세요: v2rayN은 데스크톱 설정 인터페이스입니다. 실제 DNS 동작은 활성화된 코어, 실행 설정, 트래픽 가로채기 방식에 따라 달라집니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용하므로 서로 다른 코어의 DNS 필드를 그대로 혼용할 수 없습니다.
오염과 유출을 구분하세요: DNS 오염은 잘못되었거나 간섭을 받은 조회 결과를 받는 현상이고, DNS 유출은 예상하지 않은 경로로 조회가 나가는 현상입니다. 조회 결과가 정확해도 경로가 유출될 수 있습니다.
DNS 조회 실패와 연결 실패를 구분하세요: 로그에 도메인 조회 시간 초과가 표시되면 먼저 DNS 서버에 연결할 수 있는지 확인하세요. 주소를 정상적으로 받았는데 연결이 시간 초과된다면 라우팅, 노드, 대상 포트, 네트워크 제한도 살펴봐야 합니다.

2. 로컬·원격 DNS와 전송 방식 선택하기

‘로컬 DNS’는 보통 직접 연결에 사용하는 리졸버를 뜻하며, 반드시 컴퓨터에서 실행되는 서비스라는 의미는 아닙니다. ‘원격 DNS’는 대개 프록시 연결에 사용할 리졸버를 뜻하지만, 자동으로 프록시를 통한다는 뜻은 아닙니다. 용도를 먼저 나눈 다음 전송 프로토콜, 서버 주소, 실제 연결 출구를 각각 확인하세요.

일반 DNS에서 주로 사용하는 포트

853

DNS over TLS 표준 포트

443

DNS over HTTPS에서 주로 사용하는 포트

여기 나온 포트는 프로토콜에서 흔히 사용하는 값이지, 클라이언트의 수신 대기 포트로 일괄 입력하라는 뜻이 아닙니다. 입력란에서 DoH 주소를 받을 수 있는지는 사용 중인 버전과 필드 설명을 확인하세요. DoH가 HTTPS를 사용한다고 해서 일반 웹사이트의 홈 주소를 DNS 엔드포인트로 쓸 수 있는 것은 아닙니다. 모든 DNS 입력란이 DoT 주소 형식을 지원하는 것도 아닙니다.

조회 용도	설정 방향	확인할 사항
중국 내 직접 연결 도메인	현재 네트워크에서 연결할 수 있는 로컬 리졸버를 사용합니다. 예를 들어 통신사 DNS를 사용하거나 필요에 따라 223.5.5.5를 지정할 수 있습니다.	조회 요청이 직접 연결되는지, 반환된 주소가 현재 네트워크에 적합한지 확인
해외 프록시 도메인	프록시를 통해 접근할 수 있는 원격 리졸버를 사용합니다. DoH를 지원하는 필드라면 필요에 따라 https://dns.google/dns-query를 입력할 수 있습니다.	엔드포인트 지원 여부와 연결 가능 여부, 요청이 의도한 대로 프록시를 통하는지 확인
프록시 서버 도메인	프록시 연결 전에 사용할 수 있는 부트스트랩 조회 경로를 유지합니다.	아직 연결되지 않은 프록시에 의존하는지, 순환 의존이 생기는지 확인
로컬 네트워크 기기 이름	라우터나 사설 네트워크 DNS의 조회 기능을 우선 유지합니다.	내부 네트워크 이름이 공용 리졸버로 잘못 전달되는지 확인

판단 기준: 요청이 나가는 경로부터 확인한 뒤 리졸버를 바꾸세요

원격 DNS 요청이 간섭을 받는 직접 연결 경로를 계속 통한다면 주소만 바꿔서는 해결되지 않을 수 있습니다. 로그나 연결 기록으로 요청 경로를 먼저 확인한 뒤 서버와 전송 방식을 조정하세요.

3. v2rayN에서 DNS 및 라우팅 설정 확인하기

현재 실행 모드와 코어를 기록한 다음 ‘설정’ → ‘DNS 설정’을 엽니다. 배포 버전에 따라 관련 옵션이 설정 창의 DNS 탭에 있을 수 있으므로 실제 화면의 필드 설명을 따라 설정하세요. 온라인에 올라온 JSON 전체를 용도가 다른 입력란에 그대로 붙여 넣지 마세요. 코어를 바꾸면 모든 DNS 설정의 의미가 그대로 유지된다고 볼 수도 없습니다.

기존 값을 기록하세요. 현재 로컬 DNS, 원격 DNS, 라우팅 모드, 실행 코어 설정을 기록해 둡니다. 사용자 지정 DNS 설정을 사용 중이라면 테스트 전에 원문을 백업해 두어 변경 후 되돌릴 수 있게 하세요.
직접 연결용 DNS를 설정하세요. 로컬 또는 직접 연결 DNS 필드에 접속 가능한 리졸버를 입력합니다. 223.5.5.5를 사용한다면 현재 네트워크에서 접근할 수 있는지 확인하세요. 기업 네트워크의 내부 도메인은 일괄적으로 공용 주소로 바꾸지 말고 기업 DNS를 우선 사용해야 합니다.
원격 DNS를 설정하세요. 원격 DNS 필드에는 현재 코어가 지원하는 형식을 입력합니다. DoH를 지원한다면 필요에 따라 https://dns.google/dns-query를 사용할 수 있습니다. 이 주소는 설정 예시일 뿐, 모든 네트워크에서 직접 접속할 수 있다는 뜻은 아닙니다.
라우팅 규칙을 확인하세요. ‘설정’ → ‘라우팅 설정’을 열고 중국 도메인 규칙, 프록시 도메인 규칙, 기본 연결 출구를 확인합니다. 도메인별 분기가 필요하다면 IP 규칙만 남기고 도메인 규칙을 빠뜨려서는 안 됩니다.
저장한 뒤 코어를 재시작하세요. 새 설정을 다시 불러온 다음 로그에 DNS 설정 형식 오류, 조회 시간 초과, 서버 연결 실패가 나타나는지 확인합니다. 화면에 저장되었다는 표시는 설정이 기록되었다는 뜻일 뿐, 실제 연결 경로가 올바르다는 의미는 아닙니다.

실행 설정에서 V2Ray/Xray의 routing.domainStrategy를 사용한다면 자주 쓰이는 세 가지 값을 구분해야 합니다. AsIs는 라우팅 단계에서 원래 도메인을 기준으로 처리하며 IP 규칙을 위해 먼저 조회하지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 조회를 시도한 뒤 계속 규칙을 확인합니다. IPOnDemand는 IP가 필요한 규칙을 검사할 때 필요에 따라 조회합니다. 이 값들은 ‘직접 연결’, ‘프록시’, ‘전역’과 같은 뜻이 아닙니다.

4. v2rayNG에서 VPN 가로채기와 DNS 확인하기

v2rayNG에서 사이드 메뉴의 ‘설정’을 열고 ‘원격 DNS’, ‘로컬 DNS’, 그리고 버전에서 제공하는 로컬 DNS 활성화 옵션을 찾습니다. 항목 이름은 버전에 따라 바뀔 수 있습니다. 로컬 DNS를 입력했더라도 해당 기능이 활성화되어 있는지 확인하세요. 입력란에 주소가 있다는 것만으로 설정이 적용되었다고 판단하면 안 됩니다.

연결 모드를 확인하세요. 설정을 시작하고 시스템 VPN 연결 상태를 확인합니다. 프록시 모드만 사용한다면 해당 프록시를 통하지 않는 앱은 이 DNS 설정의 적용을 자동으로 받지 않습니다.
로컬 DNS를 확인하세요. 현재 네트워크에 맞는 직접 연결용 리졸버를 입력하고 활성화 스위치도 확인합니다. 내부 네트워크 조회 요구를 유지하세요. 회사 내부망이나 집 안의 기기 이름은 보통 공용 DNS로 조회할 수 없습니다.
원격 DNS를 확인하세요. 사용 중인 버전이 지원하는 원격 주소를 입력하고 저장한 뒤 연결을 중지했다가 다시 시작합니다. 암호화 DNS가 필요하다면 해당 필드에서 프로토콜을 지원하는지 먼저 확인하세요. 주소 접두사를 임의로 조합하지 마세요.
라우팅과 앱별 설정을 확인하세요. ‘설정’ → ‘라우팅 설정’에서 중국 내 트래픽 처리 방식을 확인하고 앱별 프록시 설정도 점검합니다. 제외된 앱은 시스템 네트워크와 시스템 DNS를 계속 사용할 수 있습니다.
시스템과 브라우저 설정을 확인하세요. Android의 ‘비공개 DNS’와 브라우저의 ‘보안 DNS’가 활성화되어 있는지 기록합니다. 문제를 진단할 때는 한 번에 한 가지 설정만 바꾸고 연결을 다시 설정해 로그와 DNS 동작을 비교하세요.

Android 비공개 DNS, 브라우저 내장 DoH, 코어 DNS가 각각 다른 조회 경로를 만들 수 있습니다. 특정 스위치가 다른 설정을 반드시 덮어쓴다고 단정하지 마세요. VPN이 가로채는 범위, 앱 제외 여부, 실제 연결 기록을 함께 확인해야 합니다. 특히 브라우저 자체 DoH 요청은 일반 HTTPS 트래픽으로 라우팅되면서 클라이언트 내장 리졸버는 사용하지 않을 수 있습니다.

5. DNS 조회 규칙과 연결 규칙 함께 설정하기

‘중국 도메인은 로컬 DNS, 해외 도메인은 원격 DNS’로 구성하려면 두 단계가 함께 맞아야 합니다. DNS 단계에서 조회할 리졸버를 선택하고, 라우팅 단계에서 실제 연결의 출구를 선택합니다. DNS만 바꿔도 연결이 자동으로 프록시를 통하지는 않습니다. 반대로 연결 라우팅만 바꿔도 앱이 시스템으로 이미 보낸 DNS 요청을 되돌릴 수는 없습니다.

먼저 구체적인 예외를 지정하세요. 직접 연결해야 하는 내부 도메인, 기업 서비스, 로컬 네트워크 주소에는 명확한 처리 방식을 지정해 광범위한 프록시 규칙에 덮이지 않도록 합니다.
그다음 도메인 분류 규칙을 추가하세요. 설정에서 geosite:cn 등의 규칙을 사용한다면 실행 중인 코어가 해당 규칙을 지원하고 관련 규칙 리소스를 정상적으로 불러왔는지 확인합니다. 분류 데이터베이스는 실시간 위치 정보를 제공하지 않으며 모든 중국 웹사이트를 포함한다고 보장하지도 않습니다.
IP 기준 예외 규칙을 추가하세요. geoip:cn은 IP 주소를 기준으로 분류하며 도메인 분류 규칙과 의미가 다릅니다. 중국 도메인이 해외 주소를 사용할 수도 있고, 해외 도메인이 중국 CDN 주소를 반환할 수도 있습니다.
규칙 미일치 동작을 확인하세요. 분류 목록에 없는 도메인이 최종적으로 어떤 연결 출구를 사용하는지, DNS가 다른 서버로 대체되는지 확인합니다. 대체 동작을 모른다면 해외 DNS 요청이 로컬 경로로 절대 나가지 않는다고 단정하지 마세요.

프록시 서버 자체의 도메인도 별도로 처리해야 합니다. 노드에 연결하기 전에 먼저 DNS 조회가 필요하지만 그 조회를 아직 연결되지 않은 프록시로만 보내도록 설정하면 시작 과정이 순환할 수 있습니다. 원격 DoH 서버가 도메인 주소를 사용한다면 초기 조회 경로가 필요할 수도 있습니다. 모든 리졸버에 프록시를 강제하기보다 현재 코어가 초기 연결을 어떻게 설정하는지 확인하세요.

판단 기준: 실행에 필요한 경로를 유지한 뒤 분리 규칙을 강화하세요

먼저 노드 도메인과 DNS 서비스가 사용할 수 있는 부트스트랩 경로를 확보한 다음 실제 서비스 도메인의 조회 규칙을 단계적으로 조정하세요. 각 단계를 변경할 때마다 다시 연결해 테스트하면 시작 실패를 노드 장애로 오해하지 않을 수 있습니다.

6. 로그, 캐시, 비교 조회로 결과 검증하기

검증에서는 세 가지를 따로 확인해야 합니다. 요청을 받은 서버가 어디인지, 요청이 어떤 경로를 통했는지, 실제 연결이 어떤 출구를 사용하는지입니다. 사용 가능한 IP 하나를 확인했다고 DNS가 우회되지 않았다는 뜻은 아닙니다. 브라우저에서 웹페이지가 열린다고 모든 앱의 트래픽이 가로채졌다는 의미도 아닙니다.

테스트 대상을 정하세요. 중국 내 공개 도메인 하나, 프록시로 접속해야 하는 도메인 하나, 실제로 사용하는 내부 네트워크 이름 하나를 각각 선택합니다. 매번 같은 대상을 사용해야 결과를 비교하기 쉽습니다.
연결을 새로 설정하세요. DNS 설정을 저장한 뒤 클라이언트 연결을 다시 시작하고 테스트 앱도 종료했다가 다시 엽니다. 브라우저, 시스템, 코어에는 각각 캐시가 있으므로 한 곳만 지우면 이전 결과를 계속 사용할 수 있습니다.
클라이언트 로그를 확인하세요. 먼저 설정을 불러오지 못한 오류가 있는지 확인한 다음 DNS 오류와 연결 출구 기록을 살펴봅니다. 전체 DNS 정보가 로그에 표시되는지는 코어와 로그 수준에 따라 다릅니다. 기록이 없다고 요청이 없었다는 뜻은 아닙니다.
시스템에서 비교 확인하세요. Windows 터미널에서 아래 명령을 실행해 기본 리졸버와 지정한 리졸버의 차이를 확인합니다. 이 명령은 시스템 수준의 조회를 확인하는 것으로, 클라이언트 코어의 DNS 동작을 검증하는 방법을 대신할 수는 없습니다.

nslookup www.qq.com
nslookup www.qq.com 223.5.5.5
ipconfig /flushdns

첫 번째 명령은 일반적으로 현재 시스템 리졸버를 사용하고, 두 번째 명령은 지정한 주소로 조회하며, 세 번째 명령은 Windows DNS 캐시를 지웁니다. 리졸버마다 다른 CDN 주소를 반환하는 일은 흔하므로 주소가 다르다는 이유만으로 DNS 오염이라고 판단하면 안 됩니다. 주소가 적절한지, 조회가 안정적인지, 대상에 연결할 수 있는지, 클라이언트 로그가 어떤지 함께 살펴보세요.

7. 증상별 DNS 문제 해결하기

원격 DNS를 바꿨는데도 웹페이지가 열리지 않나요?

먼저 로그에서 DNS 조회 시간 초과와 연결 시간 초과를 구분하세요. 원격 DNS 주소 형식이 지원되는지, 서버에 연결할 수 있는지, 요청이 올바른 경로로 나가는지 확인합니다. IP 주소를 이미 받았다면 노드 연결과 실제 서비스 라우팅을 점검하세요. DNS 서버를 계속 바꾸지는 마세요.

브라우저는 정상인데 다른 앱에서 DNS 조회에 실패하나요?

먼저 해당 앱이 VPN 또는 앱별 프록시 대상에서 제외되어 있는지 확인한 다음 앱 자체 DNS를 사용하는지도 살펴보세요. 데스크톱에서 시스템 프록시만 켰다면 앱이 시스템 프록시 설정을 읽는지 확인해야 합니다. 브라우저에서 접속된다는 사실만으로 기기 전체의 트래픽이 가로채졌다고 볼 수는 없습니다.

DNS를 바꾼 뒤 중국 웹사이트가 오히려 느려졌나요?

중국 도메인의 조회가 원격 리졸버로 전달되는지, 실제 서비스 연결은 직접 연결인지 확인하세요. DNS 조회 위치와 연결 출구가 맞지 않으면 적절하지 않은 CDN 주소를 받을 수 있습니다. 중국 도메인을 직접 연결용 DNS로 되돌리고 연결을 새로 설정한 뒤 같은 사이트에서 속도를 비교하세요.

일부 사이트만 실패하는데 IPv6를 꺼야 하나요?

먼저 A 레코드와 AAAA 레코드의 연결 결과를 비교하고 현재 연결 출구에서 IPv6에 접근할 수 있는지 확인하세요. IPv6 조회 옵션을 임시로 바꿔 비교할 수 있지만 원래 값을 기록해 두세요. IPv6를 끄는 것으로 IPv6 라우팅과 트래픽 가로채기 범위 점검을 대신하지 마세요.

구독을 업데이트하면 DNS 설정도 함께 동기화되나요?

일반적인 노드 구독은 주로 서버 설정을 업데이트하며 클라이언트 전역 DNS와 라우팅 설정은 포함하지 않을 수 있습니다. 업데이트 후 로컬 설정을 다시 확인하세요. 전체 사용자 지정 설정을 사용한다면 실행 설정이 화면의 DNS 옵션을 덮어쓰는지도 확인해야 합니다.

나중에 복구할 수 있도록 설정 기록을 남겨 두세요. 실행 코어, 트래픽 가로채기 모드, 로컬·원격 리졸버, 라우팅 정책, 브라우저 DNS 설정, 변경 날짜를 적으면 됩니다. 문제가 다시 발생하면 노드, DNS, 라우팅을 한꺼번에 바꾸기보다 가장 최근에 변경한 설정부터 되돌리는 편이 원인을 찾기 쉽습니다.