V2Ray 또는 Xray JSON 설정을 직접 편집할 수 있고 도메인 해석 문제를 해결하려는 사용자를 위한 글입니다. 내장 DNS의 적용 범위부터 servers, domains, expectIPs와 라우팅 정책의 관계까지 살펴보고, 점검과 롤백이 가능한 중국 본토·해외 도메인 분리 해석 설정을 제시합니다.
먼저 DNS 조회가 어떤 경로를 거치는지 구분하기
애플리케이션이 도메인에 접속할 때 일반적으로 프록시 연결보다 먼저 도메인을 IP 주소로 변환합니다. 애플리케이션이 시스템 DNS를 직접 호출하면 조회가 V2Ray에 도달하기 전에 이미 끝날 수 있습니다. 이 경우 설정 파일의 dns 항목만 수정해도 애플리케이션이 받은 결과가 바뀌지 않을 수 있습니다. 조회가 내장 DNS, DNS 인바운드, 투명 프록시 캡처 경로 또는 클라이언트의 해당 기능에 의해 인계될 때만 내장 규칙이 적용됩니다.
또 하나 헷갈리기 쉬운 점은 ‘DNS 서버 선택’과 ‘서비스 트래픽 분할’이 서로 다른 단계라는 것입니다. dns.servers는 특정 도메인을 어느 DNS 서버에 맡길지 결정하고, routing.rules는 DNS 요청과 이후 연결이 어느 아웃바운드로 나갈지 결정합니다. 도메인이 해외 DoH 서버로 전달되더라도 해당 DoH 요청이 부적절한 직접 연결 경로로 나가면 시간 초과나 연결 재설정이 발생할 수 있습니다.
전체 경로는 순서대로 점검해야 합니다. 애플리케이션이 조회를 클라이언트에 맡기는지, 도메인이 예상한 서버와 일치하는지, DNS 서버 요청이 어느 아웃바운드로 나가는지, 반환 주소가 검증을 통과하는지, 최종 서비스 연결이 어느 라우팅 규칙에 걸리는지를 확인해야 합니다. 웹페이지가 열리는지만으로는 문제가 발생한 계층을 구분할 수 없습니다.
servers, domains, expectIPs의 역할
servers는 DNS 서버 목록입니다. 각 항목은 일반 주소일 수도 있고 매칭 조건이 포함된 객체일 수도 있습니다. 객체 형식을 사용하면 특정 서버에 domains, expectIPs, 포트와 폴백 제어를 지정할 수 있습니다. 조건이 없는 서버는 보통 기본 또는 폴백 해석을 담당하므로 모든 서버에 동일한 매칭 범위를 지정하는 것은 피해야 합니다.
domains는 어떤 조회를 현재 서버에 우선 전달할지 결정합니다. 자주 사용하는 규칙으로는 geosite:cn, geosite:geolocation-!cn, domain:example.com, full:host.example.com이 있습니다. domain:은 현재 도메인과 하위 도메인에 매칭되고, full:은 완전한 호스트 이름만 매칭합니다. 지역 분류는 클라이언트가 사용하는 데이터 파일에 의존하므로 파일이 오래되면 새 도메인이 분류되지 않을 수 있습니다.
expectIPs는 DNS 서버를 선택하는 기능이 아니라 반환된 IP가 예상 범위에 속하는지 확인하는 기능입니다. 예를 들어 중국 본토 도메인 서버에 geoip:cn을 설정했는데 반환 주소가 해당 집합에 포함되지 않으면 코어가 다음 해석 경로를 시도할 수 있습니다. 이 항목은 명백히 부적절한 응답을 찾는 데 유용하지만 도메인 분류를 대신할 수 없고, 지역 간 서비스를 항상 고정된 지역의 주소로 반환하도록 보장하지도 않습니다.
중국 본토 도메인 해석
- 서버
- 223.5.5.5
- 포트
- 53
- 매칭
- geosite:cn
- 예상 주소
- geoip:cn
가까운 중국 본토 서비스 주소를 우선 가져오는 데 적합합니다.
해외 도메인 해석
- 서버
- 1.1.1.1 DoH
- 전송
- HTTPS
- 매칭
- geolocation-!cn
- 예상 주소
- geoip:!cn
DoH 요청은 해당 서비스에 안정적으로 접속할 수 있는 아웃바운드를 통과하도록 설정하는 것이 좋습니다.
queryStrategy는 조회할 주소 체계를 제어합니다. UseIPv4는 IPv4만 요청하므로 로컬 IPv6 지원이 불완전하거나 프록시 노드에 IPv6 아웃바운드 기능이 없는 환경에 적합합니다. UseIPv6는 IPv6만 요청하고, UseIP는 두 유형의 결과를 모두 사용할 수 있습니다. 주소 체계 선택은 노드, 시스템 네트워크와 라우팅 규칙에 맞아야 합니다. 그렇지 않으면 DNS 결과는 있지만 연결이 계속 시간 초과되는 현상이 나타날 수 있습니다.
조정 가능한 중국 본토·해외 분리 해석 설정
아래 예시는 코어 구조만 보여 주며 노드 인증 정보와 전체 아웃바운드는 포함하지 않습니다. 중국 본토 분류는 UDP 53 DNS 서버에, 해외 분류는 HTTPS 기반 DNS 서버에 맡기고, 마지막 폴백으로 로컬 DNS를 사용합니다. 예시에서는 DoH 주소를 IP 형식으로 작성해 DoH 호스트 이름을 해석하는 과정에서 DNS 조회가 다시 필요해지는 의존 고리를 줄였습니다.
{
"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"
],
"expectIPs": [
"geoip:!cn"
],
"skipFallback": true
},
"localhost"
]
},
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": [
"223.5.5.5"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"1.1.1.1"
],
"outboundTag": "proxy"
}
]
}
}
이 예시는 기존 설정에 direct와 proxy라는 아웃바운드 태그가 이미 있다고 가정합니다. 실제 태그가 freedom, main 또는 다른 이름이라면 기존 설정에 맞게 수정해야 하며 그대로 복사해서는 안 됩니다. 라우팅 규칙의 순서도 적절해야 합니다. 더 구체적인 DNS 서버 주소 규칙을 광범위한 중국 본토 IP 직접 연결 규칙보다 앞에 배치하지 않으면 앞선 규칙이 먼저 매칭될 수 있습니다.
skipFallback은 현재 서버를 일반 폴백 과정에서 제외한다는 뜻입니다. 다만 DNS 폴백 세부 동작과 확장 필드 지원 여부는 코어 버전에 따라 다를 수 있습니다. V2Ray 5.x, Xray 25.x 또는 클라이언트에 포함된 다른 코어를 사용할 때는 실제 코어 시작 로그를 기준으로 판단해야 합니다. 로그에 알 수 없는 필드가 표시되면 먼저 해당 필드를 제거하고 기본 설정을 검증한 다음, 현재 코어 문서에 따라 폴백 제어를 다시 추가하세요.
| 설정 항목 | 예시 값 | 주요 역할 | 자주 발생하는 오류 |
|---|---|---|---|
domains |
geosite:cn |
DNS 서버 선택 | 서비스 라우팅 규칙으로 잘못 이해함 |
expectIPs |
geoip:cn |
반환 주소 범위 검증 | 범위가 지나치게 엄격해 폴백이 자주 발생함 |
queryStrategy |
UseIPv4 |
조회 주소 체계 제어 | 실제 네트워크 기능과 일치하지 않음 |
domainStrategy |
IPIfNonMatch |
라우팅 단계의 도메인 해석 제어 | DNS 서버 선택과 혼동함 |
결론: 먼저 DNS 요청의 아웃바운드를 고정하세요
중국 본토와 해외 서버를 올바르게 작성했는데도 결과가 불안정하다면 먼저 223.5.5.5가 direct에, 1.1.1.1이 proxy에 매칭되는지 확인하세요. DNS 서버 자체가 잘못된 아웃바운드로 나가는 것이 도메인 분류 누락보다 여러 요청을 한꺼번에 실패하게 만드는 경우가 많습니다.
로그로 분할 라우팅이 실제 적용됐는지 확인하기
DNS, 라우팅, 노드와 시스템 프록시를 한 번에 모두 변경하지 마세요. 먼저 현재 작동하는 설정을 백업하고 DNS 항목만 교체한 뒤 코어를 재시작하세요. 문법 오류가 없음을 확인한 다음 DNS 서버의 아웃바운드 규칙을 추가합니다. 단계적으로 수정하면 ‘설정으로 시작할 수 없음’과 ‘DNS 결과가 예상과 다름’을 나누어 처리할 수 있습니다.
v2rayN에서는 「설정」→「매개변수 설정」에서 로그 수준을 확인하고 메인 화면에서 로그 창을 열 수 있습니다. 진단할 때는 정보 수준 로그를 임시로 사용하고 테스트가 끝나면 원래 설정으로 되돌리세요. Android의 v2rayNG 또는 v2flyNG에서는 먼저 연결을 끊고 설정을 저장한 뒤 다시 연결해야 합니다. 그래야 화면만 수정한 채 기존 코어 프로세스가 캐시된 설정을 계속 사용하는 일을 피할 수 있습니다.
- 중국 본토 분류에 속하는 도메인 하나, 해외 분류 도메인 하나, 사용자 지정 완전 일치 도메인 규칙 하나를 준비하세요. 단일 웹사이트만으로 판단하지 않는 것이 좋습니다.
- 운영체제와 브라우저에서 관리할 수 있는 DNS 캐시를 삭제한 뒤 현재 클라이언트 코어를 재시작하고 테스트 시작 시간을 기록하세요.
- 각 도메인 유형을 연속 세 번씩 접속하고, 로그에서 조회 대상, 매칭된 서버와 최종 아웃바운드 태그를 확인하세요.
- 프록시를 켠 상태와 끈 상태를 각각 테스트해 DoH 요청이 프록시를 거쳐야 하는 경우에만 실패하는지 확인하세요.
expectIPs를 잠시 제거하고 다시 테스트하세요. 문제가 사라진다면 반환 주소가 예상 집합과 충돌한다는 뜻이므로 노드를 무작정 바꾸기보다 분류를 조정해야 합니다.
지연 시간도 계층별로 기록해야 합니다. 한 번의 전체 접속에는 DNS 시간, TCP 또는 UDP 연결 수립 시간, TLS 핸드셰이크와 서버 응답 시간이 포함됩니다. 로그에서 DNS가 40밀리초 이내에 완료됐는데 페이지 대기가 3초를 넘는다면 문제는 DNS보다 서비스 연결이나 라우팅에 있을 가능성이 큽니다. 반대로 DNS 요청이 5초 안팎으로 계속 시간 초과될 때는 서버 접근성과 아웃바운드 선택을 우선 점검해야 합니다.
결론: 두 그룹의 도메인과 사용자 지정 규칙 하나로 교차 검증하세요
인기 웹사이트만 테스트하면 캐시와 지역별 트래픽 조정의 영향을 받기 쉽습니다. full: 정확한 규칙을 추가하면 domains 매칭이 작동하는지 직접 확인한 뒤 geosite 데이터를 업데이트해야 하는지 판단할 수 있습니다.
자주 발생하는 문제와 해결 방법
DNS 분할에서 가장 흔한 문제는 JSON 형식보다 규칙이 서로 덮어쓰는 것입니다. 서버 객체의 domains는 DNS 서버 선택을 담당하고, 라우팅의 domain과 ip는 연결 분할을 담당합니다. 두 위치 모두 geosite 또는 geoip를 참조할 수 있지만 실행 단계는 다릅니다. 문제를 찾을 때는 현재 보고 있는 로그가 DNS 조회 로그인지 서비스 연결 로그인지 먼저 구분해야 합니다.
설정을 저장한 뒤 코어가 바로 시작되지 않나요?
먼저 로그의 필드 이름과 줄 번호를 확인하고 쉼표, 괄호와 배열 형식이 올바른지 점검하세요. 알 수 없는 필드가 표시되면 skipFallback 같은 확장 항목을 제거하고 최소한의 servers 설정으로 시작한 다음, 현재 코어가 지원하는 범위에 맞춰 하나씩 다시 추가하세요.
해외 도메인이 여전히 로컬 서버로 전달되나요?
기본 서버가 앞에 배치되어 조회에 먼저 참여하는지 확인한 뒤 geosite:geolocation-!cn 데이터를 사용할 수 있는지 점검하세요. 일시적으로 full:대상 도메인 정확한 규칙을 추가해 지정한 DoH 서버로 전환되는지 확인할 수 있습니다.
주소는 해석되는데 웹페이지가 열리지 않나요?
이후 연결이 매칭된 outboundTag를 확인하세요. DNS가 성공했다는 것은 주소를 얻었다는 뜻일 뿐 서비스 트래픽이 proxy를 사용한다는 의미는 아닙니다. 시스템 프록시, 로컬 수신 포트 10808과 라우팅 규칙 순서도 함께 확인하세요.
expectIPs를 켠 뒤 일부 웹사이트가 느려졌나요?
콘텐츠 전송 네트워크는 지역이 다른 주소를 반환할 수 있으므로 엄격한 geoip:cn 또는 geoip:!cn 설정이 추가 시도를 유발할 수 있습니다. 해당 도메인에 더 정확한 domain: 규칙을 추가하거나, 분류가 안정적인 경우에만 주소 검증을 사용하세요.
컴퓨터에서는 정상인데 Android 클라이언트의 결과가 다른가요?
양쪽에서 사용하는 코어 유형, geosite 데이터와 조회 전략이 동일한지 확인하세요. v2rayNG는 일반적으로 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용합니다. 동일한 JSON이라도 확장 필드와 폴백 세부 동작에는 차이가 있을 수 있습니다.
캐시 때문에 수정 결과가 적용되지 않은 것처럼 보일 수 있습니다. 운영체제, 브라우저, 클라이언트 코어와 상위 DNS 서버가 모두 레코드를 캐시할 수 있습니다. 테스트할 때는 이전에 접속하지 않은 하위 도메인으로 바꾸거나, 관리 가능한 환경에서 레코드의 유효 시간이 끝날 때까지 기다리는 것이 좋습니다. 클라이언트를 반복해서 재시작해도 일부 캐시만 지워질 뿐 모든 상위 서버에 즉시 새 결과를 반환하도록 강제할 수는 없습니다.
또 다른 위험은 여러 DNS 인계 방식을 동시에 활성화하는 것입니다. 예를 들어 브라우저가 자체 보안 DNS를 사용하고 시스템 트래픽은 클라이언트가 인계하면 두 조회 경로에서 서로 다른 결과가 나올 수 있습니다. 진단 단계에서는 진입점을 일시적으로 통일해 조회가 현재 코어를 명확히 거치도록 하세요. 검증이 끝난 뒤 실제 필요에 따라 애플리케이션 자체 DNS 기능을 유지할지 결정하면 됩니다.
- 중국 본토 도메인에서 가끔 해외 주소가 반환됨: 먼저 콘텐츠 전송 네트워크의 트래픽 조정을 확인하고 결과를 바로 오류로 판단하지 마세요.
- DoH가 장시간 응답하지 않음: 443 포트 연결이 프록시 아웃바운드에 매칭되는지 확인하고 노드가 대상 DNS 서비스에 접속할 수 있는지 점검하세요.
- IPv6 주소로만 연결 실패: 조회 전략을 일시적으로
UseIPv4로 바꾼 뒤 노드와 로컬 네트워크의 IPv6 지원 여부를 확인하세요. - 구독 업데이트는 정상인데 웹페이지 DNS 해석에 문제가 있음: 구독 요청과 서비스 DNS는 같은 경로가 아니므로 로그를 따로 확인해야 합니다.
v2rayN, v2rayNG, v2flyNG에 설정 적용하기
v2rayN 데스크톱 버전은 로그 창과 사용자 지정 설정 편집 기능을 활용할 수 있어 전체 설정을 점검하기에 적합합니다. 편집하기 전에 기존 설정을 먼저 내보내고 「설정」→「매개변수 설정」에서 코어 유형을 확인한 다음 DNS 객체를 최상위 JSON에 병합하세요. 하나의 파일에 이름이 같은 dns 객체를 두 개 남겨 두지 마세요. 뒤에 나온 내용이 앞선 설정을 덮어쓸 수 있습니다.
Android 클라이언트는 데스크톱에서 검증을 마친 뒤 설정 원칙을 적용하는 방식이 더 적합하며, 전체 설정을 바로 복사하는 것은 권장하지 않습니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용하므로 필드 지원 범위, 기본 조회 전략과 클라이언트가 설정을 생성하는 방식이 다를 수 있습니다. 클라이언트가 구독으로 실행 설정을 자동 생성한다면 수동으로 추가한 임시 내용이 구독 업데이트 후 다시 생성될 수도 있습니다.
| 클라이언트 | 권장 점검 항목 | 권장 작업 방식 |
|---|---|---|
| v2rayN | 코어 유형, 로그, 라우팅 태그, 10808 로컬 포트 | 먼저 사용자 지정 설정으로 단계별 검증 수행 |
| v2rayNG | Xray 필드 호환성, VPN 모드, 앱별 프록시 적용 범위 | 다시 연결한 뒤 실제 실행 로그 확인 |
| v2flyNG | v2fly 필드 지원, geosite 데이터, 조회 전략 | v2fly 코어 지원 범위에 맞춰 설정 간소화 |
안정적인 구성에는 명확한 폴백 경로가 하나 있어야 하지만, 폴백이 기본 서버의 장기적인 장애를 가려서는 안 됩니다. 먼저 중국 본토 UDP 53과 해외 DoH가 각각 정확히 매칭되도록 한 뒤, 마지막 안전장치로 로컬 DNS를 추가하세요. 기본 서버가 대부분의 조회를 처리한다면 domains 분류나 데이터 파일에 여전히 문제가 있다는 뜻입니다. ‘최종적으로 접속된다’는 사실만으로 분할 라우팅이 올바르다고 판단해서는 안 됩니다.