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

DNS 서버 선택, DNS 아웃바운드, 웹 트래픽 아웃바운드를 구분하세요

‘DNS 분할’에는 최소 두 가지 별도 판단이 필요합니다. 도메인을 어떤 DNS 서버에 맡길지, DNS 요청을 어떤 아웃바운드로 보낼지 정해야 합니다. 웹사이트 연결에는 세 번째 판단이 추가됩니다. 해외 DNS 주소를 설정에 입력했다고 조회가 프록시를 통과하는 것은 아닙니다. 웹 트래픽을 프록시로 라우팅해도 브라우저가 먼저 로컬에서 조회한 DNS 요청까지 자동으로 코어를 거치는 것은 아닙니다.

V2Ray/Xray의 dns 객체는 내장 DNS 서버를 설정하고, routing은 연결에 사용할 아웃바운드를 결정합니다. geosite:cn은 도메인 규칙 모음이고 geoip:cn은 IP 주소 규칙 모음이므로 서로 대체할 수 없습니다. 앱이 도메인을 코어에 전달하지 않으면 IP만 있는 연결은 도메인 규칙으로 바로 매칭할 수 없습니다. 트래픽 스니핑으로 도메인 정보를 복구할 수는 있지만, 모든 프로토콜에 통하는 해결책으로 간주해서는 안 됩니다.

국내 DNS와 원격 DoH: 먼저 각각의 역할을 정하세요

아래 예시에서는 223.5.5.5로 국내 도메인을 조회하고, 그 밖의 요청은 https://1.1.1.1/dns-query로 처리합니다. 다른 공개 DNS 서버로 바꿔 쓸 수 있는 예시일 뿐, 모든 네트워크에 가장 적합한 고정값은 아닙니다. 앞의 서버는 보통 UDP 53을, 뒤의 서버는 HTTPS 443을 사용합니다. 암호화는 클라이언트와 DNS 서버 사이의 조회 전송을 보호하지만, DNS 서버는 처리하는 도메인을 확인할 수 있습니다.

UseIPv4는 초기 점검을 IPv4로 한정해 IPv6 라우팅 문제를 함께 다루지 않도록 합니다. IPv6를 장기간 비활성화하라는 일반적인 권장사항은 아닙니다. 네트워크와 노드가 모두 IPv6를 지원한다면 기본 설정을 확인한 뒤 UseIP로 바꾸고 A 레코드와 AAAA 레코드를 각각 점검할 수 있습니다. DNS 조회 유형 설정은 시스템 수준의 IPv6 라우팅 설정을 대신하지 않습니다.

dns.servers 예시: 도메인 매칭과 대체 동작

다음은 코어 설정 일부로, 단독으로 가져올 수 있는 완전한 노드 설정이 아닙니다. v2rayNG에서 사용하는 Xray 코어를 기준으로 한 예시이며, v2rayN에서도 현재 선택된 코어를 먼저 확인해야 합니다. 설정을 수정하기 전에 백업하세요. 클라이언트가 설정을 생성하는 경우에는 해당 DNS 설정이나 사용자 지정 설정 메뉴에서 수정해야 합니다. 다음 실행 때 덮어써지는 임시 런타임 파일을 편집하지 마세요.

{
  "dns": {
    "tag": "dns-internal",
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

• domains는 매칭된 도메인에 우선 사용할 DNS 서버를 지정하는 설정이지, 해당 서버가 다른 도메인을 알 수 없게 제한하는 접근 제어 규칙이 아닙니다.
• skipFallback: true는 해당 서버를 일반 대체 처리에 사용하지 않는다는 뜻입니다. “이 서버가 실패하면 다른 서버도 시도하지 않는다”는 의미는 아닙니다.
• domains 제한이 없는 DoH 서버는 기본 DNS 서버 역할을 합니다. 위 설정에서는 국내 DNS 조회가 실패한 뒤 이 서버로 대체될 수 있으므로, 엄격한 격리가 아니라 대체 처리가 가능한 분할 설정입니다.
• tag는 내장 DNS에서 보낸 조회를 라우팅 규칙으로 식별하는 데 사용합니다. 로컬 53번 포트에서 대기하는 DNS 서비스 태그는 아닙니다.

매칭된 도메인이 지정된 서버만 사용하도록 엄격히 제한하려면 Xray의 disableFallbackIfMatch를 검토할 수 있습니다. 적용하기 전에 현재 코어가 해당 필드를 지원하는지 확인하고, 지정한 DNS 서버에 문제가 생기면 조회도 실패할 수 있음을 고려하세요. 대체 처리와 캐시, IPv6 설정을 한꺼번에 크게 바꾸면 한 번의 실패에도 원인을 좁히기 어려워집니다.

routing 예시: 원격 DNS 요청을 프록시로 보내기

아래 예시는 기존 설정에 사용 가능한 프록시 아웃바운드 태그 proxy와 직결 아웃바운드 태그 direct가 이미 있다고 가정합니다. 태그는 실제 outbounds[].tag와 정확히 일치해야 합니다. 이 예시에는 마지막 전체 매칭 규칙이 없으므로, 매칭되지 않은 연결에는 첫 번째 아웃바운드가 사용됩니다. 따라서 첫 번째 아웃바운드가 proxy여야 합니다. 기존 설정의 기본 정책이 다르면 원래 구조에 맞게 조정하고 그대로 덮어쓰지 마세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "dns-internal"
        ],
        "ip": [
          "223.5.5.5"
        ],
        "port": "53",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": [
          "dns-internal"
        ],
        "ip": [
          "1.1.1.1"
        ],
        "port": "443",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

앞의 두 규칙은 내장 DNS 조회만 식별하므로, 같은 IP에 사용자가 직접 접속하는 다른 연결까지 DNS 요청으로 처리하지 않습니다. 뒤의 두 규칙은 웹사이트 연결에 적용됩니다. IPIfNonMatch는 도메인 연결이 기존 규칙에 매칭되지 않을 때 IP를 조회해 IP 규칙과 다시 매칭한다는 뜻입니다. 사용할 DNS 서버를 정하거나 DNS 요청을 자동으로 프록시로 보내는 설정은 아닙니다.

DoH와 FakeDNS: 암호화된 조회와 가상 IP는 다릅니다

DoH는 DNS 메시지를 HTTPS 연결로 전송해 조회 과정의 전송을 보호합니다. FakeDNS는 앱에 가상 IP를 반환하고 도메인과 가상 주소의 매핑을 유지해, 이후 연결도 도메인을 기준으로 처리할 수 있게 합니다. FakeDNS는 실제 웹사이트를 가상 주소에 배치하는 기능이 아니며, 원격 DNS에서 실제 주소를 조회했다는 뜻도 아닙니다.

예를 들어 FakeDNS의 IPv4 주소 풀로 198.18.0.0/15를 사용하는 경우, 시스템은 해당 주소 풀로 향하는 연결을 코어에 전달하고 코어가 원래 도메인을 복원해야 합니다. 연결이 VPN이나 TUN 경로를 우회하면 가상 IP로 실제 공인 IP처럼 접속할 수 없습니다. 기능을 켠 뒤 일부 앱에서만 문제가 생긴다면 바로 노드를 바꾸기보다 앱별 프록시 설정, 트래픽 캡처 범위, 매핑 처리부터 확인하세요.

• 일반 DNS 분할이 제대로 작동하는지 아직 확인하지 못했다면 FakeDNS를 켜지 말고, 문제를 점검할 기준으로 실제 주소를 유지하세요.
• 앱이 대상 IP만 전달해 도메인 규칙이 제대로 적용되지 않는다면 FakeDNS와 현재 인바운드 및 스니핑 설정의 연동을 검토하세요.
• FakeDNS를 끈 뒤에도 가상 주소가 계속 나타나면 관련 앱과 시스템의 캐시를 비우고 연결을 다시 생성해 이전 매핑이 계속 사용되지 않도록 하세요.

v2rayN과 v2rayNG에서 단계별로 확인하기

클라이언트 화면 설정과 코어 설정은 서로 다른 계층입니다. 같은 ‘원격 DNS’ 입력란이라도 클라이언트 버전에 따라 생성되는 설정 구조가 다를 수 있으므로, 코어가 실제로 불러온 설정을 기준으로 확인하세요. v2rayN에서는 ‘설정’ → ‘매개변수 설정’에서 로그 관련 항목을 확인한 뒤, 메인 창의 로그 영역에서 시작 결과를 살펴볼 수 있습니다. DNS 편집 메뉴 이름은 버전에 따라 달라질 수 있습니다. 일반 한 줄 입력란을 전체 JSON 편집기로 착각하지 마세요.

1. 기준 상태를 기록합니다. 노드와 현재 라우팅 모드, DNS 주소, 시스템 프록시 또는 VPN 상태를 저장하세요. v2rayNG에서는 ‘설정’에서 DNS 관련 항목을 확인하고, 수정 후 서비스를 중지했다가 다시 시작해 로그에 설정 파싱 오류가 없는지 확인합니다.
2. 시작 오류를 확인합니다. 알 수 없는 필드, 존재하지 않는 아웃바운드 태그, geosite 데이터 로드 실패 등의 오류부터 해결하세요. 코어가 정상적으로 시작되지 않은 상태에서 웹페이지를 테스트하면 잘못된 결론을 내릴 수 있습니다.
3. 앱이 도메인을 전달하는지 확인합니다. 데스크톱에서는 원격 DNS를 지원하는 SOCKS 요청으로 테스트할 수 있습니다. 아래 명령은 로컬 SOCKS 포트가 10808이라고 가정합니다. 실행 중인 설정이 다르면 실제 포트로 바꿔야 합니다.
4. 라우팅 규칙 적용 여부를 확인합니다. 잠시 로그 상세도를 높이고 국내외 도메인에 각각 접속해 DNS 조회와 웹사이트 연결이 어떤 아웃바운드로 나가는지 확인하세요. 검증이 끝나면 평소 로그 수준으로 되돌려 불필요한 접속 정보가 장기간 기록되지 않도록 합니다.
5. 캐시 영향을 분리합니다. 코어를 다시 시작하고 기존 연결을 끊은 뒤 재시도하세요. Windows에서는 ipconfig /flushdns를 실행해 시스템 캐시를 비울 수 있지만, 브라우저나 앱 자체 캐시는 별도로 삭제해야 할 수 있습니다.

curl --proxy socks5h://127.0.0.1:10808 --head --max-time 15 https://www.example.com/

socks5h를 사용하면 curl이 도메인을 SOCKS 프록시에 전달합니다. socks5로 바꾸면 보통 로컬에서 먼저 DNS 조회가 이루어지므로 두 테스트의 경로는 서로 다릅니다. 이 명령은 도메인이 프록시 경로로 들어가는지 확인할 뿐, 모든 DNS가 예상대로 분할 처리되는지를 단독으로 증명하지는 않습니다. 또 자주 생기는 오해는 nslookup www.example.com 223.5.5.5만 실행하는 것입니다. 이 명령은 지정한 DNS 서버에 직접 질의해 서버 연결 여부는 확인할 수 있지만, 내장 DNS 규칙이 적용됐다는 증거는 아닙니다.

자주 묻는 문제: DNS 시간 초과, 비정상 주소, 설정 미적용

최종 설정에는 각 항목의 역할이 명확히 드러나야 합니다. 어떤 도메인에 국내 DNS를 사용할지, 기본 DNS 요청을 어디에 맡길지, DNS 연결을 어떤 아웃바운드로 보낼지, 규칙에 매칭되지 않은 웹사이트를 어떻게 처리할지 설명할 수 있어야 합니다. 한 번에 하나씩만 바꾸고 시작 로그와 연결 결과로 확인하면 여러 공개 DNS를 한꺼번에 추가하는 것보다 문제 원인을 찾기 쉽습니다.