구독을 가져올 수는 있지만 일부 사이트의 DNS 해석 오류, 첫 연결 지연, 중국 본토 사이트의 우회 연결을 겪는 사용자에게 적합합니다. DNS 해석 경로와 프록시 트래픽 경로를 구분하고, 중국 본토 도메인은 로컬 상위 DNS로, 해외 도메인은 DoH로 처리한 뒤 로그·해석 결과·라우팅 규칙으로 문제를 찾는 것이 핵심입니다.
먼저 이해해야 할 DNS와 라우팅의 두 가지 선택
도메인에 접속할 때 클라이언트는 보통 먼저 IP 주소를 확인한 뒤 해당 IP에 TCP 또는 UDP 연결을 엽니다. DNS는 “도메인을 어떤 주소로 해석할지” 결정하고, 라우팅 규칙은 “어느 출구로 연결을 보낼지” 결정합니다. 두 선택은 서로 연관되지만 같은 작업은 아닙니다. 도메인 분할 규칙만 설정했다고 해서 DNS 조회가 반드시 같은 경로로 전송되는 것은 아닙니다.
V2Ray 또는 Xray 설정의 dns 객체는 상위 DNS 서버 선택, 결과 캐시, 조회 정책 제한을 담당하고, routing 객체는 도메인·IP·포트·프로토콜·인바운드 태그를 매칭합니다. 애플리케이션이 이미 로컬에서 해석을 완료했다면 코어가 받는 값은 대상 IP뿐일 수 있으므로, 도메인만 포함한 규칙이 반드시 적용된다고 볼 수 없습니다.
시스템 프록시와 TUN 모드도 연결 경로에 영향을 줍니다. 브라우저가 SOCKS 또는 HTTP 프록시로 도메인을 전달하면 코어가 원래 도메인을 확인할 수 있는 경우가 많습니다. TUN 모드에서는 클라이언트가 시스템 트래픽과 DNS 요청을 가로채 처리해야 합니다. v2rayN, v2rayNG, v2flyNG의 화면 구성은 서로 다르지만 판단 기준은 같습니다. 먼저 조회를 누가 시작했는지 확인한 다음 어느 경로를 거쳤는지 확인하세요.
중국 본토·해외 분할 해석이 유용한 이유
중국 본토 서비스는 지역별로 CDN을 분배하는 경우가 많습니다. 같은 도메인도 어느 지역의 DNS 서버에 맡기느냐에 따라 서로 다른 데이터센터 주소가 반환될 수 있습니다. 중국 본토 도메인을 가까운 로컬 상위 DNS로 조회하면 적절한 엣지 노드를 받을 가능성이 커지고, 해외 도메인을 안정적으로 접속할 수 있는 DoH 상위 서버로 조회하면 잘못된 응답, 조회 시간 초과, 변조된 결과로 인한 연결 문제를 줄일 수 있습니다.
핵심은 모든 조회를 하나의 공용 DNS 서버에 몰아넣는 것이 아니라, 조회 경로를 접속 목적에 맞추는 것입니다. 일반적으로 geosite:cn으로 중국 본토 도메인을 매칭하고 geoip:cn으로 반환 주소를 확인한 뒤, 나머지 도메인은 지정한 DoH 상위 서버로 보냅니다. 규칙 데이터가 클라이언트나 코어와 함께 업데이트되지 않으면 새 도메인이 기본 규칙으로 빠질 수 있습니다.
중국 본토 도메인 해석
- 도메인 모음
- geosite:cn
- 상위 서버 주소
- 223.5.5.5
- 포트
- 53
- 결과 범위
- geoip:cn
중국 본토 네트워크에 적합한 CDN 주소를 우선적으로 얻습니다.
해외 도메인 해석
- 도메인 모음
- geolocation-!cn
- 상위 서버 프로토콜
- DoH
- 서비스 주소
- 1.1.1.1
- 연결 포트
- 443
HTTPS로 조회를 전송하고, 현재 라우팅에 따라 연결 출구를 결정합니다.
expectIPs는 결과 필터 조건이지 도메인을 특정 지역에 강제로 매핑하는 기능이 아닙니다. 중국 본토 상위 DNS가 geoip:cn에 맞지 않는 주소를 반환하면 코어는 다음 DNS 서버를 시도할 수 있습니다. 중국 본토 사이트가 원래 해외 주소를 사용하는 경우 조건을 지나치게 엄격하게 설정하면 조회만 반복될 수 있으므로, 전체 검사를 삭제하기보다 해당 도메인에 더 정확한 예외를 추가해야 합니다.
- 자주 사용하는 로컬 네트워크 이름은
hosts에 등록할 수 있습니다. 예를 들어 라우터 관리 도메인을192.168.1.1에 고정할 수 있습니다. - IPv4 네트워크만 사용하는 경우
UseIPv4를 우선 적용하면 AAAA 레코드를 받은 뒤 연결할 수 없는 IPv6 연결을 기다리며 시간 초과되는 문제를 피할 수 있습니다. - 안정적인 IPv6 출구가 있을 때만 듀얼 스택 조회를 활성화하고, 직접 연결과 프록시 출구 모두 IPv6에 접속할 수 있는지 각각 확인하세요.
읽기 쉬운 분할 DNS 설정 예시
아래 예시는 Xray에서 흔히 사용하는 DNS 필드 형식으로 구조를 이해하기 위한 것입니다. V2Ray 또는 Xray 코어 버전에 따라 지원 필드가 조금씩 다를 수 있으므로 가져오기 전에 현재 클라이언트가 생성하는 설정 형식을 기준으로 삼으세요. v2rayN에서는 먼저 「설정」→「매개변수 설정」에서 현재 코어 유형을 확인한 다음, 「서버」→「사용자 지정 설정 서버 추가」에서 전체 JSON을 불러올 수 있습니다.
{
"dns": {
"hosts": {
"domain:router.local": "192.168.1.1"
},
"queryStrategy": "UseIPv4",
"servers": [
{
"address": "223.5.5.5",
"port": 53,
"domains": [
"geosite:cn"
],
"expectIPs": [
"geoip:cn"
]
},
{
"address": "https://1.1.1.1/dns-query",
"domains": [
"geosite:geolocation-!cn"
]
},
"localhost"
]
}
}
목록 순서와 도메인 조건이 함께 DNS 서버 선택을 결정합니다. 첫 번째 항목은 중국 본토 도메인을 처리하고, 두 번째 항목은 명확히 해외로 분류된 도메인을 처리하며, localhost는 어느 분류에도 맞지 않을 때의 기본값입니다. 모든 미분류 도메인도 DoH를 사용하게 하려면 먼저 현재 코어가 fallback과 도메인 매칭을 처리하는 방식을 확인한 뒤 기본값 순서를 조정하세요. 배열 순서만 감으로 바꾸면 안 됩니다.
- 현재 연결 가능한 설정을 먼저 백업하고, 유일한 설정을 계속 덮어쓰지 마세요.
- 중국 본토 DNS 상위 서버 하나만 추가한 뒤, 자주 사용하는 중국 본토 사이트가 정상적으로 해석되고 열리는지 테스트하세요.
- 그다음 DoH 상위 서버를 추가하고, 이전에 문제가 있었던 해외 도메인을 테스트하면서 코어 로그의 조회 오류를 확인하세요.
- 마지막으로
expectIPs, IPv4 정책, hosts 규칙을 추가하되 한 번에 한 항목만 변경하세요. - 완료한 뒤 코어를 재시작하거나 설정을 다시 불러와 기존 연결과 DNS 캐시가 결과에 영향을 주지 않게 하세요.
DNS 분할은 라우팅 규칙과 함께 설정해야 합니다
DNS가 올바른 주소를 반환하는 것은 “어디에 연결할지”만 해결합니다. 중국 본토 연결은 직접 연결하고 나머지는 프록시로 보내려면 매칭 순서가 명확한 라우팅 규칙이 추가로 필요합니다. 일반적으로 로컬 네트워크와 예약 주소를 먼저 처리하고, 중국 본토 도메인과 IP를 다음으로 처리한 뒤, 매칭되지 않은 트래픽을 프록시 출구로 보냅니다.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "direct"
},
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"geoip:cn"
],
"outboundTag": "direct"
}
]
}
}
IPIfNonMatch는 도메인 규칙이 매칭되지 않았을 때 코어가 대상 도메인을 해석한 뒤 IP 규칙을 다시 시도할 수 있음을 뜻합니다. “모든 도메인을 미리 해석”하는 스위치가 아니며 중국 본토·해외 DNS 상위 서버를 자동으로 구성하지도 않습니다. AsIs를 사용하면 코어는 도메인 매칭 흐름을 유지하는 쪽으로 동작하며, IP 대상만 IP 규칙에 바로 매칭될 수 있습니다.
결론: DNS 규칙과 트래픽 규칙을 함께 점검해야 합니다
중국 본토 도메인을 로컬 상위 서버로 보낸 뒤에는 geosite:cn과 geoip:cn이 최종적으로 직접 연결 출구를 가리키는지도 확인해야 합니다. 해외 도메인에 DoH를 사용할 때는 DoH의 HTTPS 연결과 대상 사이트 연결이 모두 예상한 출구에서 수립되는지 확인하세요.
| 현상 | 우선 확인할 항목 | 판단 기준 |
|---|---|---|
| 도메인 규칙이 간헐적으로 매칭되지 않음 | 애플리케이션이 먼저 해석했는지 여부 | 로그 대상에 도메인이 없고 IP만 표시됨 |
| 중국 본토 사이트 로딩이 느림 | DNS가 반환한 CDN 주소 | 주소의 지역이 현재 네트워크와 멂 |
| DoH 조회가 계속 시간 초과됨 | 443 포트와 출구 라우팅 | 로그에 연결 시간 초과 또는 핸드셰이크 실패가 표시됨 |
| 연결이 몇 초간 멈춘 뒤 성공함 | AAAA 레코드와 IPv6 연결 가능 여부 | IPv6 시도 실패 후 IPv4로 전환됨 |
DoH 설정의 핵심은 주소 하나만 바꾸는 것이 아닙니다
DoH는 DNS 메시지를 HTTPS 요청에 담으며, 일반적으로 443 포트를 사용합니다. 전송 중 일반 평문 UDP 조회가 관찰되거나 변조될 가능성을 낮출 수 있지만 라우팅 설정을 대신할 수 없고 상위 서버 자체의 잘못된 응답을 고쳐 주지도 않습니다. 실제 성능은 상위 서버의 접근성, 출구 경로, 캐시 정책에 따라 달라집니다.
v2rayN에서 사용자 지정 설정을 수정한 뒤 「설정」→「매개변수 설정」에서 로그 수준을 확인하고, 메인 창의 로그 영역을 열어 코어 시작 정보를 살펴볼 수 있습니다. Android에서 v2rayNG 또는 v2flyNG를 사용할 때는 먼저 현재 설정의 라우팅 및 DNS 화면을 확인한 뒤 다시 연결하여 VpnService 세션에 새 설정을 적용하세요.
- 조회 시간 초과: 먼저 DoH 주소의 443 포트에 예상 출구를 통해 연결할 수 있는지 확인한 다음, 도메인 초기 해석 문제가 있는지 살펴보세요.
- 순환 의존성: DoH 서비스 도메인을 해석하는 데 필요한 DNS 조회가 아직 수립되지 않은 동일한 DoH 연결에 다시 의존하도록 설정하지 마세요.
- 캐시가 갱신되지 않음: 상위 서버를 변경한 뒤 코어를 재시작하고 테스트 애플리케이션을 다시 여세요. 브라우저와 시스템이 각각 DNS 캐시를 보관할 수 있습니다.
- IPv6 가용성 착각: 시스템이 IPv6 주소를 받았다고 해서 출구에 연결할 수 있는 것은 아닙니다. 일시적으로
UseIPv4를 사용해 비교 테스트를 진행하세요. - 오래된 규칙 데이터: 클라이언트에 포함된 geosite 및 geoip 데이터를 업데이트한 뒤 코어를 다시 불러오고, 도메인 분류가 잘못되었는지 판단하세요.
결론: 먼저 단일 DoH 상위 서버의 작동을 확인한 뒤 예비 서버를 추가하세요
상태가 확인되지 않은 DNS 서버를 여러 개 동시에 입력하면 시간 초과, fallback, 캐시 결과가 뒤섞입니다. 먼저 확실히 연결 가능한 443 상위 서버 하나로 테스트를 끝낸 다음 예비 DNS 서버를 추가하면 로그를 훨씬 쉽게 읽을 수 있습니다.
테스트 대상은 세 종류를 선택하세요. 안정적인 중국 본토 CDN 도메인 하나, 프록시 접속이 필요한 해외 도메인 하나, 로컬 네트워크 이름 하나입니다. 첫 접속과 두 번째 접속을 연속으로 테스트하면 최초 해석 시간과 캐시 후 연결 시간을 구분할 수 있습니다. 처음만 느리고 이후 빨라진다면 DNS와 핸드셰이크를 중점적으로 확인하고, 매번 느리다면 라우팅·노드 지연 시간·패킷 손실을 추가로 점검하세요.
DNS 오염과 연결 오류를 점검하는 순서
DNS 오염은 대상 서비스와 관계없는 주소가 반환되거나, 같은 도메인이 서로 다른 조회 경로에서 뚜렷하게 충돌하는 결과를 얻거나, 해석은 성공했지만 연결이 즉시 재설정되는 형태로 나타나는 경우가 많습니다. “웹페이지가 열리지 않는다”는 이유만으로 DNS 문제라고 단정해서는 안 됩니다. 노드 장애, 시스템 프록시 미활성화, 잘못된 라우팅, 연결할 수 없는 IPv6도 비슷한 현상을 만들 수 있습니다.
점검은 가장 짧은 경로부터 시작해야 합니다. 먼저 코어가 정상적으로 시작했는지 확인하고, 다음으로 도메인이 해석되는지, 결과가 합리적인지, 마지막으로 대상 연결이 어느 출구를 사용했는지 확인하세요. v2rayN 로그에 설정 필드 오류가 표시되면 먼저 JSON을 수정하고, DNS timeout이 표시되면 상위 서버를 점검하세요. 이미 IP를 받았는데 연결에 실패한다면 라우팅과 노드를 확인해야 합니다.
연결은 성공하지만 일부 도메인만 열리지 않을 때는 어떻게 하나요?
문제가 있는 도메인과 정상 도메인을 따로 기록하고 로그에서 대상이 도메인인지 IP인지 확인하세요. IP만 표시된다면 애플리케이션이 프록시 밖에서 먼저 해석했는지 확인하고, 도메인이 표시되지만 직접 연결로 매칭된다면 geosite 분류와 규칙 순서를 점검하세요.
DoH로 바꾼 뒤 모든 조회가 시간 초과되면 어떻게 하나요?
먼저 작동하는 일반 DNS fallback 하나를 복원한 다음, 현재 출구를 통해 DoH 주소의 443 포트에 연결할 수 있는지 확인하세요. 도메인 형식의 DoH 주소를 사용할 때는 초기 해석을 수행할 수 있는 상위 DNS 서버도 남겨 두어야 합니다.
중국 본토 사이트가 프록시 경로로 분류되는 이유는 무엇인가요?
라우팅 규칙이 위에서부터 더 포괄적인 프록시 규칙에 먼저 매칭되지 않았는지 확인하세요. 로컬 네트워크, geosite:cn, geoip:cn 규칙을 기본 프록시 규칙보다 앞에 배치한 뒤 설정을 다시 불러오세요.
IPv6를 켠 뒤 웹사이트 첫 접속이 느린 이유는 무엇인가요?
일시적으로 queryStrategy를 UseIPv4로 변경해 비교하세요. 대기 시간이 사라진다면 로컬 네트워크, 직접 연결 출구, 프록시 노드 모두에 사용 가능한 IPv6 경로가 있는지 계속 확인하세요.
구독을 업데이트한 뒤 사용자 지정 DNS가 사라졌다면 어떻게 하나요?
구독 서버 설정과 클라이언트 전역 DNS 설정은 서로 다른 위치에서 관리될 수 있습니다. 업데이트 전에 「설정」→「매개변수 설정」의 코어 옵션을 기록하고, 사용자 지정 설정이 구독으로 생성된 설정에 덮어쓰이지 않았는지 확인하세요.
최소 구성으로 비교 테스트를 한 번 더 진행할 수도 있습니다. 작동이 확인된 노드 하나, DNS 상위 서버 하나, 가장 기본적인 직접 연결 규칙만 잠시 남겨 두세요. 최소 설정이 정상이라면 광고 필터, 복잡한 도메인 모음, 여러 상위 서버, 사용자 지정 hosts를 하나씩 복원하세요. 한 번에 한 항목만 추가하는 편이 설정 전체를 반복해서 지우는 것보다 충돌 원인을 찾기 쉽습니다.
안정적인 설정을 위한 최종 점검
DNS 분할을 완료한 뒤에는 특정 웹사이트가 열리는지만 확인해서는 안 됩니다. 중국 본토 CDN이 직접 연결되는지, 해외 도메인이 예상한 DNS 서버를 사용하는지, DoH 연결에 순환 의존성이 없는지, 코어 재시작 후 설정이 정상적으로 로드되는지도 확인해야 합니다. 구독·클라이언트·규칙 데이터가 업데이트된 뒤에도 주요 도메인 테스트를 다시 진행하세요.
데스크톱 점검
- 클라이언트
- v2rayN
- 메뉴 경로
- 설정 → 매개변수 설정
- 시스템 프록시
- 활성화 상태 확인
- 로그 대상
- DNS 및 routing
사용자 지정 JSON을 수정한 뒤 코어를 다시 불러오고 첫 접속 테스트를 진행하세요.
Android 점검
- 클라이언트
- v2rayNG / v2flyNG
- 연결 방식
- VpnService
- 배터리 절전 정책
- 백그라운드 실행 허용
- 다시 불러오는 방법
- 연결 해제 후 다시 연결
시스템이 백그라운드 연결을 중단하지 않았는지 확인한 뒤 DNS가 계속 시간 초과되는지 판단하세요.
- 코어 시작 로그에 알 수 없는 필드, 형식 오류, 포트 사용 중이라는 메시지가 없어야 합니다.
- 중국 본토 도메인은 지정한 로컬 상위 서버에서 해석되고, 반환 주소가 예상 지역과 일치해야 합니다.
- 해외 도메인의 DoH 조회는 예상한 출구를 통해 443 포트에 접속할 수 있어야 합니다.
- 로컬 네트워크와 예약 주소는 우선 직접 연결하고 기본 프록시 규칙에 들어가지 않아야 합니다.
- 현재 네트워크에서 IPv6를 사용할 수 없다면 AAAA 연결이 반복해서 시간 초과될 때까지 기다리지 않도록 해야 합니다.
- 구독과 규칙 데이터 업데이트 후에도 사용자 지정 DNS 및 라우팅 설정이 유지되어야 합니다.
최종적으로 안정적으로 작동하는 구성은 대개 복잡하지 않습니다. 중국 본토 도메인은 지연 시간이 짧은 로컬 DNS 서버로, 해외 도메인은 안정적인 DoH로 보내고, 상위 서버 선택과 라우팅 출구를 일치시킨 뒤 로그로 각 단계를 검증하면 됩니다. 문제가 생기면 “코어 시작, DNS 조회, 반환 주소, 규칙 매칭, 출구 연결” 순서로 확인하는 것이 노드나 DNS 서버를 계속 바꾸는 것보다 원인을 빠르게 찾는 방법입니다.