v2rayN DNS 설정: 중국 본토·해외 도메인 분리 해석과 DNS 오염 방지 설정

시스템 DNS, 코어 DNS, 원격 DNS를 먼저 구분하기

먼저 v2rayN에서 “설정” → “파라미터 설정”을 열고 현재 활성화된 코어 유형, 시스템 프록시 모드와 TUN 상태를 확인합니다. DNS 분리가 적용되는지는 어떤 서버를 입력했는지만으로 결정되지 않고, 도메인 요청이 Xray 코어로 들어갔는지에도 좌우됩니다. 일반 시스템 프록시는 주로 애플리케이션의 HTTP 또는 SOCKS 트래픽을 처리하므로 일부 앱은 운영체제 DNS를 직접 호출할 수 있습니다. TUN 모드는 더 많은 네트워크 요청을 포괄하지만 DNS 하이재킹과 라우팅 규칙도 함께 점검해야 합니다.

시스템 DNS는 네트워크 어댑터나 운영체제가 현재 사용하는 해석기입니다. 코어 DNS는 생성된 설정의 최상위 dns 객체로, 도메인 규칙에 따라 DNS 서버를 선택합니다. 원격 DNS는 단순히 서버 주소를 해외 주소로 바꾸는 것이 아니라, 프록시 아웃바운드를 통해 대상 해석기로 쿼리를 보내는 방식입니다. 쿼리 패킷이 여전히 직접 연결로 전송된다면 원격 서버를 입력했어도 원격 해석이 된 것은 아닙니다.

중국 본토 로컬 DoH와 해외 원격 DNS 설정하기

먼저 중국 본토 도메인용으로 지연 시간이 짧은 로컬 DoH를 지정하고, 나머지 도메인에는 프록시를 통해 접근해야 하는 원격 DoH를 지정합니다. 분리 기준은 해석이 끝난 뒤 반환 IP가 아니라 도메인 목록을 사용해야 합니다. 쿼리를 보내기 전에 해석기를 선택할 수 있어 해외 도메인이 로컬 DNS에 먼저 노출되거나 잘못된 결과를 받는 일을 막을 수 있습니다.

1. “설정” → “파라미터 설정”으로 이동해 Xray 코어가 활성화되어 있는지 확인하고 로컬 SOCKS 수신 포트를 기록합니다. 일반적인 기본값은 10808이지만 실제 값은 현재 파라미터 화면을 기준으로 합니다.
2. v2rayN의 DNS 설정 화면으로 들어가 현재 코어에 해당하는 설정 영역을 선택합니다. 버전에 따라 화면의 명칭이 조금 다를 수 있으므로 변경 후에는 편집창만 보지 말고 생성된 실행 설정을 확인해야 합니다.
3. 중국 본토용 DoH 서버를 geosite:cn과 같은 도메인 규칙에 연결하고, 예상 반환 주소는 geoip:cn으로 제한합니다.
4. 원격 DoH는 뒤쪽 매칭 위치에 배치해 해외 도메인과 미매칭 도메인의 해석기로 사용합니다. 동시에 해당 DoH 도메인 또는 대상 연결이 프록시 아웃바운드를 거치도록 설정해야 합니다.
5. 설정을 저장하고 코어를 재시작합니다. 먼저 중국 본토 도메인을 명확히 하나 테스트한 다음 해외 도메인을 테스트해 단일 사이트만으로 결론을 내리지 않도록 합니다.

아래 예시는 Xray dns 객체의 핵심 구조를 보여 줍니다. 구조 예시이므로 v2rayN이 자동 생성한 전체 설정을 그대로 덮어쓰면 안 됩니다. 실제 사용 시에는 클라이언트의 사용자 지정 DNS 영역을 통해 병합하고 기존 로그, 인바운드, 아웃바운드, 라우팅 설정을 유지해야 합니다.

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableCache": false,
    "hosts": {
      "dns.local.example": "223.5.5.5"
    },
    "servers": [
      {
        "address": "https://dns.alidns.com/dns-query",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

queryStrategy가 UseIP이면 코어는 네트워크 상태에 따라 A 및 AAAA 결과를 요청할 수 있습니다. 로컬 네트워크에서 IPv6가 안정적이지 않은데 IPv6 조회 전략을 강제하면 해석은 성공해도 연결이 시간 초과될 수 있습니다. IPv4만 사용하는 환경에서는 현재 코어가 지원하는 범위에서 적절한 전략을 선택하되, 조회 전략과 라우팅 아웃바운드를 하나의 설정으로 혼동하지 마세요.

원격 DNS 쿼리가 실제로 프록시 아웃바운드를 거치게 하기

원격 DoH도 본질적으로는 HTTPS 연결입니다. 대상 주소가 라우팅 규칙에 의해 직접 연결로 보내지면 쿼리는 로컬 네트워크에서 전송됩니다. 라우팅 설정에서 원격 해석기 도메인의 프록시 방향을 명확히 지정하고, 로컬 DoH까지 프록시로 보내지 않도록 하여 중국 본토 쿼리의 짧은 지연 시간을 유지합니다.

• “설정” → “라우팅 설정”에서 사용자 지정 규칙 순서를 확인합니다. 원격 DoH 도메인의 프록시 규칙은 범위가 넓은 직접 연결 규칙보다 앞에 있어야 합니다.
• 로컬 DoH 도메인은 geosite:cn 또는 명시적 도메인 기준으로 직접 연결을 설정할 수 있으며, 연결 포트는 일반적으로 443입니다.
• 기존 DNS가 UDP 53을 사용한다면 TUN과 방화벽 때문에 패킷이 코어를 우회하지 않는지 확인해야 합니다. DoH는 HTTPS를 사용하므로 일반 TCP 트래픽과 함께 라우팅 규칙을 적용하기가 더 쉽습니다.
• 구독 노드의 서버 주소가 도메인이라면 최초 연결을 수립하는 데 필요한 기본 해석 경로를 유지해야 합니다. 그렇지 않으면 “프록시에 먼저 연결해야 노드를 해석할 수 있고, 노드를 먼저 해석해야 프록시에 연결할 수 있는” 순환이 발생합니다.

문제를 해결할 때 v2rayN의 로그 창을 열고 코어 로그 수준을 DNS 및 라우팅 매칭을 확인할 수 있는 단계로 일시적으로 올립니다. 그런 다음 시스템 캐시를 비우고 테스트 도메인을 차례로 방문합니다. 쿼리 유형, 매칭된 DNS 서버, 라우팅 아웃바운드 태그, 반환 주소와 시간 초과 원인을 확인하세요. 테스트가 끝나면 일상적인 출력량을 줄이기 위해 로그 수준을 다시 낮춰도 됩니다.

hosts, fakeDNS, 캐시 우선순위 다루기

hosts는 일반 DNS 조회에 들어가기 전에 지정 도메인을 덮어쓰는 데 사용합니다. 내부 서비스의 고정 주소 지정, 일시적인 해석 장애 우회 또는 한 도메인을 다른 도메인에 매핑할 때 적합합니다. 자주 바뀌는 대형 사이트의 주소를 관리하는 용도로는 적합하지 않습니다. 고정 IP가 최적의 서버 선택을 우회할 수 있고, 서버 주소가 바뀌면 연결이 실패할 수도 있습니다.

fakeDNS는 TUN 환경에서 자주 사용됩니다. 먼저 앱에 합성 주소를 반환하며, 일반적인 주소 풀은 198.18.0.0/15에 있습니다. 이후 코어가 합성 주소에서 원래 도메인을 찾아 라우팅을 수행합니다. 이를 통해 도메인 정보를 유지하고 앱이 시스템 계층에서 실제 해석을 끝낸 뒤 IP만 코어에 전달하는 상황을 줄일 수 있습니다. 활성화 여부는 현재 TUN 설정과 코어 지원 여부를 기준으로 결정해야 합니다.

캐시는 TTL이 만료될 때까지 해석 결과를 저장하여 반복 조회와 페이지 최초 로딩 대기 시간을 줄입니다. DNS 규칙을 바꾼 뒤에도 이전 결과가 보인다면 새 설정이 적용되지 않은 것이 아니라 시스템 캐시, 앱 캐시, 코어 캐시 중 한 계층에 이전 기록이 남아 있을 수 있습니다. 먼저 코어를 재시작하고 운영체제 DNS 캐시를 비운 뒤 테스트 앱을 완전히 종료했다가 다시 시작해야 합니다.

hosts 덮어쓰기

일반 서버에 조회하기 전에 지정한 주소 또는 별칭을 반환합니다. 적은 수의 명확하고 관리 가능한 도메인 매핑에 적합합니다.

fakeDNS

앱에 합성 주소를 반환하고 코어에 원래 도메인 매핑을 유지합니다. 주로 TUN 트래픽에서 도메인을 식별하는 문제를 해결합니다.

DNS 캐시

TTL에 따라 기존 결과를 재사용합니다. 지연 시간을 줄일 수 있지만 설정을 변경한 뒤에도 이전 결과가 잠시 계속 나타날 수 있습니다.

{
  "dns": {
    "hosts": {
      "internal.example": "192.168.10.20",
      "alias.example": "target.example"
    },
    "disableCache": false,
    "disableFallback": false
  }
}

hosts를 설정한 뒤에는 도메인 해석과 실제 연결을 따로 확인해야 합니다. 해석 결과는 올바른데 웹페이지가 열리지 않는다면 대상 서비스가 올바른 TLS 도메인, 리버스 프록시 진입점 또는 특정 포트를 요구하는 것일 수 있습니다. hosts는 주소 선택만 바꾸며 인증서 검증, HTTP Host 또는 서버의 수신 설정은 변경하지 않습니다.

증상별로 해석 실패와 규칙 미매칭 진단하기

먼저 문제를 “조회가 전송되지 않음”, “잘못된 아웃바운드로 전송됨”, “예상과 다른 결과 반환”, “해석은 정상이나 연결 실패”의 네 가지로 나눕니다. 웹페이지가 열리는지만으로 DNS를 판단하지 마세요. TLS 핸드셰이크, 라우팅 규칙, 노드 상태와 대상 서비스도 같은 증상을 만들 수 있습니다.

명령줄 테스트는 보조 근거로 사용할 수 있지만 nslookup은 기본적으로 시스템 DNS에 질의하므로 Xray 코어를 거치지 않을 수 있습니다. 운영체제가 현재 사용하는 해석기를 확인하는 데는 유용하지만 원격 DoH 경로를 단독으로 입증할 수는 없습니다. 코어 DNS 분리를 검증할 때는 명령 결과, v2rayN 코어 로그와 네트워크 출구를 함께 확인해야 합니다.

1. 변경 전 DNS 설정, 라우팅 모드, 코어 유형과 수신 포트를 기록합니다.
2. 한 번에 변수 하나만 변경합니다. 예를 들어 먼저 해석기를 조정한 뒤 라우팅 규칙을 바꿉니다.
3. 코어를 재시작하고 JSON 해석 오류, 포트 사용 중 또는 DNS 초기화 실패가 없는지 확인합니다.
4. 중국 본토 도메인 하나와 해외 도메인 하나를 각각 테스트하고 매칭된 서버와 아웃바운드 태그를 기록합니다.
5. 마지막으로 일반 로그 수준으로 되돌리고 정상 작동하는 설정 사본을 저장합니다.