먼저 도메인을 어느 DNS가 조회하는지 확인한 다음, 중국 본토 도메인은 현지 DNS를 우선 사용하고 그 외 도메인은 프록시를 통해 암호화 DNS에 연결하도록 설정합니다. V2Ray 또는 Xray 설정을 수정하려는 사용자를 위해 DNS와 라우팅 설정 예시를 제공하고, v2rayN 적용 방법과 대체 동작, 확인 시 유의점을 설명합니다. DoH 주소를 입력했다고 모든 앱의 DNS 조회가 이 설정을 따르는 것은 아닙니다.
1. 앱·코어·서버의 DNS 조회 구분하기
DNS 설정에서 먼저 확인할 것은 “조회가 이 설정을 거치는가”입니다. 앱이 도메인을 프록시에 전달하면 코어가 라우팅 판단이나 직접 연결을 위해 DNS를 조회할 수도 있고, 도메인을 프록시 서버에 넘겨 서버 측에서 조회하게 할 수도 있습니다. 앱이 먼저 로컬에서 도메인을 IP 주소로 변환한 뒤 IP만 프록시에 전달한다면, 클라이언트의 dns 설정이 해당 조회에 관여하지 않을 수 있습니다.
이 흐름은 로컬 DNS 조회가 필요한 경우를 설명한 것으로, 프록시 연결마다 로컬 DNS 조회가 선행된다는 뜻은 아닙니다. 도메인 규칙으로 프록시 아웃바운드를 선택할 수 있다면 대상 도메인이 원격 서버로 바로 전달될 수도 있습니다. 이 경우 로컬 DNS 로그에 해당 도메인이 없더라도 설정이 작동하지 않는다고 단정할 수 없습니다.
- 시스템 DNS: 운영체제의 네트워크 설정에서 지정합니다. 시스템 프록시만 켜도 모든 시스템 DNS 요청이 자동으로 V2Ray에 전달되지는 않습니다.
- 코어 DNS: 설정의
dns항목에 정의하며, 코어 내부의 관련 DNS 조회에 사용됩니다. 시스템 53번 포트를 자동으로 수신하는 서비스는 아닙니다. - 브라우저 보안 DNS: 브라우저가 HTTPS로 직접 DNS를 조회해 운영체제의 리졸버를 우회할 수 있습니다.
- 서버 측 DNS: 프록시 아웃바운드가 도메인을 원격 서버로 전달하면, DNS 응답은 원격 서버의 DNS와 네트워크 환경에 따라 달라집니다.
2. servers, domains, queryStrategy의 역할
servers는 사용할 DNS 서버를 정의하고, 서버 객체의 domains는 우선 조회할 도메인을 지정하며, queryStrategy는 조회할 IP 주소 유형을 제어합니다. 각각 “어디에 물을지”, “어느 서버에 우선 물을지”, “어떤 주소를 받을지”를 결정합니다. 웹사이트 연결에 적용되는 아웃바운드 규칙과 혼동하지 마세요.
중국 본토 도메인 우선 조회
- address
223.5.5.5- port
53- domains
geosite:cn- skipFallback
true
중국 본토 도메인 목록과 일치하는 조회를 우선 처리하며, 일치하지 않는 도메인의 일반 대체 조회에는 사용하지 않습니다.
그 외 도메인 조회
- address
https://1.1.1.1/dns-query- 전송 방식
- HTTPS, 기본 포트 443
- domains
- 지정하지 않음. 대체 DNS 서버로 사용
- 조회 전략
- 최상위
UseIPv4설정 상속
이 DoH 서버로 향하는 트래픽에도 프록시 라우팅을 설정해야 합니다. DNS 주소만 입력해서는 충분하지 않습니다.
domains는 “이 서버를 사용할 수 있는 도메인만 허용”하는 접근 제어 목록이 아닙니다. 도메인이 일치하면 보통 우선 조회 대상이 되며, 일치하지 않는 도메인도 대체 동작에 따라 다른 서버를 사용할 수 있습니다. 여기서 중국 본토 DNS 서버에 skipFallback: true를 지정한 것은 일치하지 않는 도메인의 대체 서버 목록에서 제외하기 위해서입니다. 모든 DNS 대체 동작을 끄는 설정은 아닙니다.
| 설정값 | DNS 조회 동작 | 사용 조건 |
|---|---|---|
UseIP | IPv4 및 IPv6 주소 조회 허용 | 실제로 사용할 아웃바운드가 필요한 IP 버전으로 연결되는지 확인하세요. |
UseIPv4 | IPv4 주소만 조회 | IPv6 문제를 우선 분리해 확인할 때 적합 |
UseIPv6 | IPv6 주소만 조회 | 사용 가능한 IPv6 네트워크와 대상 IPv6 주소가 필요합니다. |
이 예시에서는 문제 범위를 좁히기 위해 UseIPv4를 사용합니다. IPv4가 항상 더 빠르다는 뜻은 아닙니다. 네트워크와 노드에서 IPv6가 정상적으로 작동한다면 UseIP로 바꿔 확인할 수 있습니다. 이 설정은 내장 DNS 조회에만 영향을 주며 시스템 전체의 IPv6를 비활성화하지 않습니다.
3. 중국 본토·그 외 도메인 분리 조회를 위한 dns 설정
다음은 설정 최상위에 넣는 dns 항목으로, 단독 실행 가능한 전체 클라이언트 설정이 아닙니다. 기존 JSON에 합칠 때는 같은 이름의 기존 항목을 교체하세요. 하나의 객체에 dns 항목을 중복으로 추가하면 안 됩니다. geosite:cn을 사용하기 전에 실행 디렉터리에서 도메인 규칙 데이터를 사용할 수 있는지도 확인하세요.
{
"dns": {
"queryStrategy": "UseIPv4",
"servers": [
{
"address": "223.5.5.5",
"port": 53,
"domains": [
"geosite:cn"
],
"skipFallback": true
},
{
"address": "https://1.1.1.1/dns-query"
}
]
}
}geosite:cn과 일치하는 도메인은223.5.5.5에 우선 조회해 중국 본토 서비스에서 흔히 사용하는 인접 서버의 응답을 받을 수 있도록 합니다.- 우선 조회 대상과 일치하지 않는 도메인은 대체 목록의 DoH 서버를 사용합니다. 중국 본토 DNS 서버는
skipFallback설정으로 대체 목록에서 제외됩니다. - 중국 본토 DNS를 통한 우선 조회에 실패하더라도 대체 동작을 별도로 끄지 않았다면 DoH를 시도할 수 있습니다. 이 설정은 조회 우선순위를 지정할 뿐, 조회 경로를 완전히 분리하지는 않습니다.
중국 본토 도메인의 조회가 실패했을 때 다른 DNS 서버로 절대 넘어가지 않도록 해야 한다면, 실제 코어의 지원 여부를 확인해 엄격한 대체 정책을 설계해야 합니다. 배열 순서만 바꿔 동작을 추측해서는 안 됩니다. V2Ray와 Xray는 확장 필드와 지원 범위가 항상 같지 않으므로, 다른 코어의 고급 설정을 복사하기 전에 현재 코어 문서와 시작 로그를 확인하세요.
여기서는 IP 주소를 포함한 DoH 주소를 사용해 “DNS 서버의 도메인을 먼저 조회해야 하는” 초기 의존성을 줄입니다. 도메인 형식의 DoH 주소를 사용한다면 해당 도메인의 최초 조회 경로도 마련해야 합니다. 그래야 DNS 서버에 연결하기 위해 자기 자신을 조회하려는 순환 대기가 발생하지 않습니다. DoH의 TLS 인증서 검증은 유지해야 하며, 연결 오류를 해결하려고 검증을 끄면 안 됩니다.
4. DNS 조회 트래픽의 아웃바운드 라우팅 설정
암호화된 DNS 조회와 프록시 전송은 서로 다른 기능입니다. DoH는 DNS 서버까지 전송되는 조회 내용을 보호하고, 라우팅은 DNS 서버 연결에 직접 연결과 프록시 중 어느 경로를 사용할지 결정합니다. 현재 네트워크에서 원격 DoH 서버에 직접 연결할 수 없다면 URL만 입력해도 시간 초과가 발생합니다. 아래 예시에서는 DoH 서버의 IP로 가는 트래픽은 프록시로, 중국 본토 DNS 트래픽은 직접 연결로 보냅니다.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"1.1.1.1/32"
],
"port": "443",
"outboundTag": "proxy"
},
{
"type": "field",
"ip": [
"223.5.5.5/32"
],
"port": "53",
"outboundTag": "direct"
},
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
}
]
}
}proxy와 direct는 이 예시에서 정한 아웃바운드 태그이며, 기존 outbounds의 tag와 정확히 일치해야 합니다. 이 규칙들을 기존 라우팅 규칙의 앞쪽에 추가하되, 기존 전체 규칙을 덮어쓰지 마세요. 일치하지 않는 트래픽은 뒤에 있는 규칙이나 기본 아웃바운드에서 처리됩니다. 이 예시는 기본 아웃바운드를 정의하지 않습니다.
- 일반 HTTPS DNS 주소: 이 예시의
https://조회는 코어의 라우팅에 따라 처리하므로 DoH 서버로 향하는 트래픽의 라우팅 규칙도 설정해야 합니다. - 로컬 직접 연결 의미가 포함된 주소 형식: 해당 형식을 지원하는 코어의
https+local://등이 있습니다. 동작 방식이 다르므로 이 예시의 프록시 라우팅 기준을 그대로 적용하면 안 됩니다. - 프록시 노드 주소가 도메인인 경우: 노드 주소를 별도로 조회할 수 있는 경로를 먼저 마련해야 합니다. 그렇지 않으면 “원격 DNS에 접속하려면 프록시가 필요하지만 프록시를 연결하려면 DNS가 필요한” 의존성 순환이 발생할 수 있습니다.
routing.domainStrategy와 dns.queryStrategy는 서로 다른 설정입니다. 여기서 AsIs는 라우팅이 IP 규칙을 위해 도메인을 능동적으로 조회하지 않는다는 뜻입니다. IPIfNonMatch로 바꾸면 도메인 규칙과 일치하지 않을 때 DNS를 조회한 뒤 IP 규칙과 비교합니다. IP 기반 분할 라우팅이 필요할 때만 활성화하세요. DNS를 적용하려고 무작정 변경할 설정은 아닙니다.
5. v2rayN에 적용하고 확인하기
먼저 현재 설정을 백업한 뒤 DNS를 수정하세요. v2rayN은 인터페이스 설정을 바탕으로 코어 설정을 생성하므로 임시 생성 파일을 직접 편집하면 노드를 전환하거나 코어를 재시작할 때 변경 사항이 사라질 수 있습니다. 일반적인 메뉴 경로는 「설정」→「DNS 설정」입니다. 버전에 따라 메뉴 구성이 달라질 수 있으니, 현재 사용 중인 코어에 해당하는 DNS 설정을 편집하는지 확인하세요. 다른 코어의 설정 항목을 수정하지 않도록 주의합니다.
- 코어와 설정 출처 확인. 현재 노드에서 사용하는 코어를 확인하세요. 이 문서의 JSON은 V2Ray/Xray 설정 구조를 기준으로 합니다. 다른 코어의 DNS 항목을 그대로 복사할 수는 없습니다.
- DNS와 라우팅 설정을 각각 저장. DNS 편집 영역에는 해당 영역에서 요구하는 객체만 입력하세요. 최상위 JSON 전체를 서버 입력란 하나에 넣으면 안 됩니다. 라우팅 태그는 실제 생성된 설정을 기준으로 확인하세요.
- 코어를 재시작하고 시작 로그 확인. 웹사이트를 시험하기 전에 JSON 문법 오류, 지원하지 않는 필드, 규칙 데이터 누락 등을 먼저 해결하세요. 코어가 정상적으로 시작되지 않았다면 네트워크 테스트 결과를 비교할 수 없습니다.
- 테스트 변수를 통제. 중국 본토 서비스 도메인 하나와 프록시가 필요한 도메인 하나를 선택하고, 앱 자체의 보안 DNS 사용 여부를 기록하세요. 설정을 바꾼 뒤에는 테스트 앱을 재시작해 기존 연결을 재사용하지 않도록 합니다.
- 연결 경로 확인. 필요하면 로그 수준을 일시적으로 높여
1.1.1.1:443연결이 프록시 아웃바운드에 매칭되는지,223.5.5.5:53조회가 직접 연결되는지 확인하세요. 점검이 끝나면 로그 수준을 원래대로 되돌립니다.
판단 기준: 먼저 조회 경로를 확인한 뒤 응답 비교
웹페이지가 열린다는 사실만으로 DNS 분리 설정이 올바르다고 볼 수는 없습니다. 먼저 조회가 의도한 DNS 서버로 전달되는지 확인하고, DoH 연결이 프록시를 거치는지도 확인해야 합니다. 두 가지가 모두 확인된 뒤에야 DNS 응답을 비교할 의미가 있습니다.
Windows에서 ipconfig /flushdns를 실행하면 시스템 DNS 캐시는 지워지지만 브라우저 자체 캐시나 코어의 모든 캐시까지 함께 지워지지는 않습니다. nslookup만 실행하면 보통 시스템에서 지정한 DNS 서버를 테스트합니다. 이 결과만으로 코어의 dns 설정이 적용되었다고 증명할 수는 없습니다.
6. DNS 오염 방지의 한계와 자주 발생하는 문제
DNS 오염을 막으려면 대상 도메인의 조회를 신뢰할 수 있는 DNS 서버로 보내고 조회 전송을 보호해야 합니다. 중국 본토 UDP DNS는 여전히 평문 조회입니다. 중국 본토 서비스에 적합한 응답을 얻기 위해 이 경로를 예시에 포함했지만, DoH와 같은 전송 보호 기능을 제공한다는 뜻은 아닙니다. 이 경로에서 문제가 발생하면 현재 코어가 지원하고 네트워크에서 접속 가능한 암호화 DNS 방식으로 바꾼 뒤 라우팅을 다시 확인하세요.
DoH를 설정했는데도 DNS 조회 시간이 초과되는 이유는 무엇인가요?
먼저 프록시 노드가 정상인지 확인한 다음, 1.1.1.1:443 연결이 프록시 규칙에 매칭되는지 살펴보세요. 노드 주소가 도메인이라면 초기 조회 과정에서 의존성 순환이 발생하지 않는지도 확인해야 합니다. 로그에 인증서 시간 오류가 표시되면 시스템 시간을 먼저 맞추고, 인증서 검증을 끄지 마세요.
중국 본토 웹사이트가 느립니다. 도메인 분리 규칙이 적용되지 않은 건가요?
현재 사용 중인 geosite:cn 데이터에 해당 도메인이 포함되어 있는지 확인한 뒤, 시작 로그에 규칙 파일 로드 오류가 있는지 살펴보세요. 웹사이트는 여러 리소스 도메인에 요청을 보낼 수도 있습니다. 주소창의 대표 도메인만 보고 모든 요청의 DNS 조회 경로를 판단하지 말고 각 도메인을 확인하세요.
DNS 검사 페이지에 다른 지역이 표시되면 DNS 유출인가요?
반드시 그렇지는 않습니다. 검사 페이지는 보통 테스트 요청을 처리한 재귀 DNS 서버의 출구 위치를 보여 주며, 클라이언트의 실제 위치를 그대로 나타내지는 않습니다. 브라우저 보안 DNS, 서버 측 DNS, 로컬 코어 DNS의 세 경로를 확인한 뒤 보호되어야 할 조회가 로컬에서 평문으로 전송되었는지 판단하세요.
올바른 IP 주소를 받았는데도 웹페이지가 열리지 않는 이유는 무엇인가요?
DNS는 주소를 반환할 뿐 TCP, TLS 또는 이후의 데이터 전송이 정상적으로 이루어지는지 보장하지 않습니다. DNS 응답을 확인한 다음 아웃바운드 규칙, 노드 연결 상태, 대상 포트를 점검하세요. IPv6를 켰을 때만 실패한다면 UseIPv4로 임시 비교 테스트를 한 뒤 IPv6 연결 문제를 해결할 수 있습니다.
같은 도메인에 서로 다른 DNS 서버가 다른 IP 주소를 반환해도 반드시 DNS 오염은 아닙니다. CDN은 DNS 서버의 위치와 네트워크 정책에 따라 서로 다른 서버를 반환할 수 있습니다. 반대로 그럴듯한 공인 IP 주소가 반환되었다고 해서 응답을 신뢰할 수 있는 것도 아닙니다. 응답 주소가 다르다는 이유만으로 정적 매핑을 추가하지 마세요. 정적 주소는 오래되면 사용할 수 없고 정상적인 서버 선택을 우회하게 됩니다.
- 원인을 찾기 쉽도록 DNS 서버, 조회할 IP 버전, 아웃바운드 라우팅 중 한 번에 하나만 변경하세요.
- 디버그 로그에는 방문한 도메인과 연결 정보가 포함될 수 있습니다. 로그를 공유하기 전에 구독 주소, 인증 정보와 기타 민감한 내용을 삭제하세요.
- 최종 점검에서는 중국 본토 접속, 프록시 접속, 코어 재시작 후 설정 유지 여부를 모두 확인하세요. 웹페이지를 한 번 새로고침하는 것만으로는 충분하지 않습니다.