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

먼저 구분할 점: DNS 분할과 트래픽 분할은 다릅니다

도메인에 접속할 때 DNS 조회는 IP 주소를 알아내고, 라우팅은 어느 아웃바운드로 연결할지 결정합니다. 두 가지는 별개의 판단입니다. 중국 내 도메인은 로컬 DNS로, 그 밖의 도메인은 원격 DNS로 조회하도록 설정해도 이는 조회를 어느 서버에 맡길지만 정합니다. 라우팅 규칙이 특정 연결을 직접 연결 아웃바운드로 보내고 있다면 원격 DNS를 썼다는 이유만으로 프록시를 통과하지는 않습니다.

DNS 조회가 코어에 도달하는지도 먼저 확인해야 합니다. 시스템 프록시만 켠 경우 브라우저는 운영체제에 도메인 조회를 맡길 수도 있고, 자체적으로 암호화 DNS 요청을 보낼 수도 있습니다. 터미널 프로그램의 동작은 각 프로그램의 프록시 설정에 따라 다릅니다. V2Ray 또는 Xray의 내장 DNS 설정은 코어가 처리하는 조회 요청만 직접 제어할 수 있습니다. 앱이 로컬에서 도메인을 IP로 먼저 변환한 뒤 IP만 프록시에 전달하면 코어에서 원래 도메인을 확인하지 못할 수 있습니다.

문제를 살필 때는 다음 순서로 확인하세요. 앱이 도메인과 IP 중 무엇을 전달하는지 보고, DNS가 어떤 서버를 선택했는지 확인한 다음, 연결이 어떤 라우팅 규칙에 매칭됐는지 살펴봅니다. 노드가 연결됐다는 이유로 DNS 분할도 제대로 작동한다고 판단하지 마세요. 노드 상태는 연결이 수립됐다는 뜻일 뿐, 브라우저의 DNS 조회 경로까지 보여주지는 않습니다.

중국 내 도메인과 그 외 도메인의 리졸버 설정

내장 DNS는 보통 중국 내 도메인 규칙에 매칭되는 조회는 로컬 리졸버를 사용하고 나머지는 원격 리졸버를 사용하도록 설정합니다. 도메인 규칙은 코어에서 사용할 수 있는 규칙 데이터에 따라 달라지며, 코어와 규칙 데이터 버전에 따라 적용 범위도 달라질 수 있습니다. 어떤 규칙에도 매칭되지 않는 도메인은 기본 리졸버를 사용하므로, 여러 세부 규칙을 추가하기 전에 기본 조회를 어디에 맡길지 확인하는 것이 좋습니다.

여기서 ‘중국 내외’는 도메인 규칙에 따른 분류이며, 매 요청마다 서버의 실제 위치를 확인한다는 뜻은 아닙니다. 도메인이 여러 지역에 걸친 서비스 인프라를 이용할 수도 있고, 규칙 데이터가 갱신되면서 분류가 달라질 수도 있습니다. 업무용 사이트나 사내 도메인은 명시적인 규칙을 우선 추가하고, 도메인 접미사만 보고 네트워크 경로를 정하지 마세요.

v2rayN 설정과 구성 형식 확인

먼저 v2rayN의 ‘설정’ → ‘매개변수 설정’에서 현재 사용하는 코어와 프록시 모드를 확인한 뒤, 클라이언트의 DNS 설정 메뉴를 여세요. 버전에 따라 설정 화면의 배치가 달라질 수 있으므로 현재 화면에 표시되는 옵션을 기준으로 설정하세요. 변경 전에 기존 구성을 보관하세요. 구독, 사전 설정 또는 사용자 템플릿이 코어 구성을 다시 생성한다면 재시작 후에도 변경 사항이 적용 중인지 확인해야 합니다.

아래는 필드 간 관계를 살펴보기 위한 Xray DNS 예시이며, 그대로 실행할 수 있는 완전한 구성은 아닙니다. geosite:cn에 매칭되는 도메인은 localhost가 가리키는 시스템 로컬 리졸버로 보내고, 나머지 조회는 뒤에 지정한 DoH 항목을 사용합니다. 실제로 사용하기 전에 코어가 해당 필드를 지원하는지, 규칙 데이터를 사용할 수 있는지 확인하고 예시 DoH 주소를 유효한 엔드포인트로 바꾸세요.

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:cn"]
      },
      "https://dns.example.net/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategy는 조회할 주소 계열을 정하는 정책이며, 직접 연결과 프록시 중 어느 쪽을 선택하는지는 결정하지 않습니다. 사이트에 IPv6 레코드만 있고 현재 네트워크에서 IPv6를 사용할 수 없다면 주소 계열 선택부터 확인해 보세요. 주소 계열 문제를 원격 DNS 장애로 오인하지 않는 데 도움이 됩니다. 위의 dns.example.net은 예시 도메인이며 실제 DNS 조회 서비스를 제공하지 않습니다.

DoH와 fakedns: 각각 어떤 문제를 해결하나요?

DoH는 HTTPS로 DNS 조회를 전송합니다. 앱과 지정된 리졸버 사이의 일반 평문 DNS 경로에서 조회 내용이 변조될 가능성을 줄일 수 있지만, 라우팅 규칙을 대신하지는 않으며 리졸버가 반환하는 모든 주소가 현재 아웃바운드에 적합하다고 보장하지도 않습니다. 원격 DoH 요청도 연결을 수립해야 합니다. 엔드포인트가 도메인 주소라면 최초 연결 시 해당 도메인의 조회가 필요할 수 있으므로 로그에서 실제 아웃바운드 경로를 확인하세요.

fakedns는 다른 방식으로 동작합니다. 코어가 먼저 앱에 매핑용 가상 주소를 반환하고, 앱이 해당 주소에 연결하면 원래 도메인을 찾아 처리합니다. 도메인 정보를 보존해야 하는 특정 투명 프록시 환경에 적합합니다. 공용 DNS 서버도 아니고 모든 실제 조회를 한 번에 암호화하는 기능도 아닙니다. TUN, 인바운드 가로채기, 스니핑 설정을 함께 고려해 사용 여부를 결정하세요.

이 두 포트 번호는 요청 유형을 파악하는 단서일 뿐 모든 조회가 코어를 통과한다고 단정할 수는 없습니다. 예를 들어 브라우저에서 자체 DoH를 사용하면 요청이 일반 HTTPS 연결처럼 보일 수 있습니다. 53번 포트 트래픽이 있는지만 확인해서는 브라우저가 최종적으로 어떤 리졸버를 사용했는지 알 수 없습니다.

DNS 조회 결과와 라우팅 규칙 연동

라우팅의 도메인 규칙과 IP 규칙은 서로 다른 역할을 합니다. 도메인 규칙은 도메인을 기준으로 아웃바운드를 바로 결정할 수 있지만, IP 규칙은 사용할 수 있는 대상 IP가 있어야 합니다. Xray의 domainStrategy를 예로 들면 IPIfNonMatch는 도메인 규칙에 매칭되지 않을 때 IP 규칙을 이어서 적용할 수 있도록 조회를 시도합니다. IPOnDemand는 라우팅 판단에 IP가 필요할 때 조회합니다. 라우팅의 domainStrategy와 DNS의 queryStrategy를 같은 설정으로 혼동하지 마세요.

• 도메인 규칙: 먼저 사내 서비스나 업무 도메인처럼 명확한 규칙을 작성한 다음 일반 분류 규칙을 적용하세요. 규칙 순서와 실제로 매칭된 아웃바운드도 확인해야 합니다.
• IP 규칙: 조회된 주소를 기준으로 판단해야 할 때 라우팅이 DNS 조회를 수행하는지 확인하세요. 모든 도메인 요청이 미리 IP 조회를 거친다고 가정하지 마세요.
• 앱이 IP를 전달하는 경우: 프록시에 도달하기 전에 앱이 직접 DNS 조회를 끝냈다면 도메인 규칙이 바로 매칭되지 않을 수 있습니다. 프록시 모드와 원래 도메인을 확인할 수 있는지 다시 살펴보세요.

실용적인 테스트 방법은 접속 결과를 직접 확인할 수 있는 도메인 두 개를 고르는 것입니다. 하나는 로컬 조회 규칙에 명시적으로 추가하고, 다른 하나는 기본 원격 리졸버에 맡기세요. 웹페이지 로딩 속도만 비교하지 말고 DNS 조회, 라우팅 매칭, 최종 아웃바운드를 각각 기록하세요. DNS가 올바른 리졸버를 선택했는데도 연결 경로가 잘못됐다면 라우팅 규칙을 조정하세요. 반대로 라우팅은 맞지만 조회 주소가 이상하다면 DNS 규칙 매칭과 상위 리졸버부터 확인하세요.

증상별 문제 해결: 클라이언트에서 코어 로그까지

테스트 전에 v2rayN의 현재 로컬 프록시 포트를 기록하고 시스템 프록시가 같은 포트를 가리키는지 확인하세요. 포트 값은 기기와 구성에 따라 다를 수 있으므로 예시 포트를 장기 설정에 넣지 마세요. 브라우저로 테스트할 때는 브라우저 자체 DNS 설정과 확장 프로그램의 동작도 확인하세요. 터미널에서 테스트할 때는 명령이 프록시를 명시적으로 사용하는지 확인해야 코어 DNS를 거치지 않은 직접 연결 결과를 잘못 검증하는 일을 피할 수 있습니다.

1. 먼저 요청이 진입하는지 확인하세요. 브라우저와 터미널에서 각각 테스트하고 v2rayN 로그에서 해당 시간의 연결 기록을 찾으세요. 기록이 없다면 시스템 프록시, 앱의 프록시 설정 또는 TUN 가로채기 상태부터 확인하세요.
2. 다음으로 도메인 정보가 보존되는지 확인하세요. 로그에 대상 IP만 표시된다면 앱이 미리 DNS 조회를 했는지 살펴보세요. 도메인이 표시된다면 DNS 규칙과 라우팅 규칙이 각각 매칭됐는지 확인하세요.
3. 마지막으로 결과를 비교하세요. 같은 도메인을 여러 번 테스트할 때 시간, 사용한 리졸버, 반환된 주소 계열, 아웃바운드를 기록하세요. 네트워크를 바꾼 뒤에는 다시 테스트해 이전 네트워크의 캐시 결과를 그대로 사용하지 않도록 하세요.

브라우저에서는 열리지만 터미널에서 열리지 않는다면 바로 DoH를 바꾸지 마세요. 터미널 프로그램이 시스템 프록시를 사용하지 않거나 자체 프록시 환경 변수를 읽지 않을 수 있습니다. 중국 내 사이트의 연결이 원격으로 우회된다면 도메인 분류와 라우팅 매칭부터 확인하세요. 일부 도메인만 실패한다면 DNS 반환값, IPv4·IPv6 사용 가능 여부, 해당 도메인에 별도 규칙이 필요한지 살펴보세요.