고급 설정 예상 읽기 시간 13분

Clash DNS 설정 완벽 가이드: nameserver, fallback, DNS 하이재킹의 역할

주요 DNS 필드의 처리 순서와 사용 환경, 설정 범위를 정리해 DNS 조회 오류와 규칙 매칭의 관계를 이해하도록 돕습니다.

DNS 조회, 프록시 규칙, 연결 출구부터 구분하기

Clash 설정의 DNS 모듈은 도메인을 주소로 변환하고, 특정 향상 모드에서는 도메인과 연결 사이의 대응 관계를 유지합니다. 프록시 규칙은 요청을 DIRECT, REJECT, 특정 프록시 노드 또는 정책 그룹으로 보낼지 판단하며, 실제 연결은 선택된 출구를 통해 수립됩니다. 이 세 부분은 서로 영향을 주지만 같은 기능은 아닙니다.

예를 들어 브라우저가 도메인에 접속하면 운영체제가 먼저 로컬 DNS에 조회를 요청할 수 있습니다. Clash가 이 요청을 가로채면 설정에 따라 상위 DNS를 선택하고, 브라우저에는 실제 주소 또는 Fake IP를 반환합니다. 이후 브라우저가 연결을 시작하면 Clash는 도메인, 대상 주소, 규칙 순서와 현재 모드를 함께 고려해 출구를 결정합니다. 특정 DNS 서버를 설정에 추가했다고 해서 모든 연결이 프록시를 거치는 것은 아니며, 특정 도메인 규칙을 프록시로 지정했다고 해서 애플리케이션이 반드시 Clash의 DNS 모듈을 사용하는 것도 아닙니다.

조회 문제를 점검할 때는 먼저 세 가지를 확인해야 합니다. DNS 요청이 실제로 Clash에 도달했는지, Clash가 어떤 상위 DNS를 선택했는지, 조회 결과가 이후 규칙 매칭에 어떻게 사용됐는지입니다. 단순히 ‘웹페이지가 열리지 않는다’는 현상만 보면 조회 실패, 규칙 오판, 노드 불가, 시스템 프록시 미적용을 구분하기 어렵습니다.

일반 조회와 향상 모드의 차이

일반적인 구현에서는 enhanced-mode로 fake-ip 또는 redir-host를 선택할 수 있습니다. Fake IP 모드는 애플리케이션에 예약 주소 대역의 합성 주소를 반환하고, 커널에 이 주소와 원래 도메인의 매핑을 저장합니다. 애플리케이션이 이 합성 주소로 연결하면 Clash가 도메인을 복원한 뒤 도메인 규칙과 후속 조회를 적용할 수 있습니다. 이 방식은 도메인 정보를 유지하는 데 유리하고, 애플리케이션이 Clash 외부에서 직접 조회해 규칙 판단이 어긋나는 문제도 줄여 줍니다.

Redir-host 모드는 일반적으로 애플리케이션에 실제 조회 결과를 반환합니다. 전통적인 DNS 동작에 더 가깝지만, 이후 연결에서 전체 도메인 정보가 유지되는지는 트래픽 유입 경로, 스니핑 기능, 애플리케이션 프로토콜과 커널 구현에 따라 달라집니다. 어느 모드가 항상 우월한 것은 아닙니다. LAN 장치, 게임, 프린터 서비스, 실제 주소가 필요한 프로그램과 일부 연결 확인 기능은 Fake IP 필터가 필요할 수 있고, 도메인 규칙을 안정적으로 매칭하려면 Fake IP를 먼저 테스트하는 편이 좋습니다.

nameserver와 default-nameserver의 역할

nameserver는 Clash DNS 모듈이 일반 도메인 조회를 처리할 때 사용하는 주요 상위 DNS입니다. 전통적인 UDP/TCP DNS뿐 아니라 커널이 지원하면 DoH 또는 DoT 주소도 사용할 수 있습니다. 여러 상위 DNS를 설정했을 때 실제 병렬 처리, 캐시와 결과 선택 방식은 커널 버전에 따라 달라지므로, 목록을 단순히 위에서 아래로 재시도하는 순서로 이해해서는 안 됩니다.

default-nameserver는 주로 DNS 서버 자체의 도메인을 조회하는 부트스트랩 조회에 사용됩니다. nameserver에 https://dns.example.net/dns-query를 입력했다면 Clash는 DoH 연결을 만들기 전에 먼저 dns.example.net의 주소를 알아야 합니다. 부트스트랩 조회가 아직 연결되지 않은 DoH 서버에 의존하면 순환 의존이 발생합니다. 이를 피하려면 기본 DNS에는 보통 직접 접근할 수 있는 IP 형식의 DNS 주소를 입력합니다.

두 필드는 ‘선호 DNS’와 ‘보조 DNS’ 관계가 아닙니다. 일반 조회는 주로 nameserver가 담당하고, default-nameserver는 기본 부트스트랩 역할을 합니다. 주요 상위 DNS가 223.5.5.5처럼 순수 IP 주소라면 부트스트랩 단계가 눈에 띄지 않지만, 호스트명이 포함된 DoH 또는 DoT 엔드포인트를 사용하면 기본 DNS의 중요성이 커집니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

이 예시는 AAAA 결과 처리를 비활성화했지만 운영체제의 IPv6 기능을 끄거나 모든 애플리케이션이 AAAA 조회를 중단한다는 뜻은 아닙니다. 해당 설정에서 Clash DNS 모듈이 호출자에게 IPv6 조회 결과를 제공하지 않는다는 의미입니다. 네트워크의 IPv6 출구가 안정적이고 규칙과 프록시 노드도 IPv6을 완전히 지원한다면 다시 활성화한 뒤 직접 연결과 프록시 경로를 각각 확인할 수 있습니다.

nameserver-policy의 적용 범위

Mihomo 같은 최신 커널은 nameserver-policy도 제공하여 도메인, 규칙 집합 또는 Geosite 분류별로 DNS를 지정할 수 있습니다. 로컬 도메인은 LAN DNS로, 특정 서비스 도메인은 지정한 DoH로 보내는 등 도메인마다 다른 조회 출구가 필요할 때 유용합니다. 정책 매칭이 성공하면 지정된 DNS가 일반적인 nameserver 선택을 대신합니다.

이 필드는 커널 지원과 규칙 데이터에 의존하므로 설정을 옮길 때 클라이언트가 실제로 사용하는 커널 버전을 확인해야 합니다. 규칙 집합이 로드되지 않았거나, 분류 이름이 지원되지 않거나, 다른 분기의 문법을 사용하면 정책이 예상대로 적용되지 않을 수 있습니다. 기본 설정을 검증하기 전에는 도메인별 DNS 분기 정책을 한꺼번에 많이 추가하지 않는 편이 좋습니다.

프록시 노드의 도메인도 조회가 필요합니다

프록시 서버 주소를 도메인으로 입력했다면 커널은 노드에 연결하기 전에 해당 도메인을 먼저 조회해야 합니다. Mihomo 설정의 proxy-server-nameserver는 이 유형의 조회를 전담하여 노드 도메인 조회가 일반 서비스 조회 경로에 의존하지 않도록 합니다. 노드 도메인을 조회할 때 다시 해당 노드를 통해 원격 DNS에 접속하려 하면 시작 단계에서 순환 의존이 발생할 수 있습니다.

마찬가지로 direct-nameserver를 지원하는 커널에서는 직접 연결 트래픽에 사용할 DNS를 지정할 수 있습니다. 이러한 확장 필드가 필요한지는 설정 규모와 네트워크 환경에 따라 다릅니다. 대부분의 입문 설정에서는 먼저 default-nameserver와 nameserver가 정상 작동하는지 확인한 다음 노드 조회와 직접 연결 조회를 단계적으로 분리하는 편이 문제를 찾기 쉽습니다.

fallback은 단순한 장애 대비용이 아닙니다

fallback은 ‘nameserver 시간 초과 후에만 사용하는 보조 서버’로 오해하기 쉽습니다. 클래식 Clash DNS 설계에서는 주요 DNS와 fallback DNS가 병렬로 조회될 수 있으며, fallback-filter가 fallback 결과를 사용할지 판단합니다. 따라서 fallback은 전통적인 네트워크 장비처럼 순서대로 전환되는 보조 DNS라기보다 별도의 후보 조회 경로에 가깝습니다.

일반적인 필터 기준에는 GeoIP, 지정 대역과 도메인 목록이 있습니다. geoip: true를 활성화하고 geoip-code: CN을 설정하면 커널이 주요 조회 결과의 지역을 기준으로 fallback 후보를 사용할지 결정할 수 있습니다. domain에는 fallback 판단을 항상 거치게 할 도메인을 지정할 수 있고, ipcidr은 특정 주소 범위를 결과 전환 조건으로 지정할 수 있습니다.

dns:
  enable: true
  enhanced-mode: fake-ip

  default-nameserver:
    - 223.5.5.5

  nameserver:
    - https://dns.alidns.com/dns-query

  fallback:
    - https://1.1.1.1/dns-query
    - tls://8.8.4.4:853

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.github.com

이 예시는 결과를 선별하는 방식을 보여 줄 뿐 모든 네트워크에 그대로 적용해야 한다는 뜻은 아닙니다. 원격 DoH 또는 DoT 엔드포인트에 연결할 수 있는지는 라우팅, 프록시 출구, 인증서 검증, 시스템 시간과 커널의 프로토콜 지원에 따라 달라집니다. fallback 서버 자체에 접근할 수 없다면 필터 규칙을 아무리 추가해도 사용할 수 있는 결과가 나오지 않습니다.

GeoIP 필터의 한계

GeoIP 판단은 데이터베이스 내용에 의존하며, 대형 웹사이트는 CDN, Anycast와 지역별 라우팅을 자주 사용합니다. 같은 도메인도 지역에 따라 다른 주소를 반환할 수 있고, 주소의 지리적 태그만으로 현재 네트워크에 적합한지 완전히 판단할 수는 없습니다. 따라서 GeoIP는 선별 신호로 활용해야 하며 절대적으로 정확한 사용 가능성 검사로 봐서는 안 됩니다.

업무 목적이 분명하다면 광범위한 GeoIP 전환에 의존하기보다 도메인별로 조회 정책을 지정하는 편이 설명하기 쉽습니다. 예를 들어 LAN 도메인은 라우터 DNS로, 사내 도메인은 기업 DNS로, 특정 공용 서비스는 지정한 DoH로 보낼 수 있습니다. 이때는 모든 조회를 두 그룹의 DNS에 동시에 보내고 결과 지역으로 판단하기보다 nameserver-policy를 우선 검토하는 것이 좋습니다.

TUN 모드에서 DNS 하이재킹의 역할

여기서 말하는 ‘DNS 하이재킹’은 공용 DNS 레코드를 수정하는 것이 아니라, 로컬 프록시 커널이 TUN 인터페이스로 들어오는 DNS 요청을 능동적으로 가로채는 것을 뜻합니다. TUN을 활성화하면 애플리케이션 트래픽이 가상 네트워크 인터페이스로 들어갑니다. dns-hijack을 설정하면 지정된 주소와 포트로 향하는 기존 DNS 요청을 Clash 내장 DNS 모듈로 전달할 수 있습니다. 따라서 시스템이 계속 라우터나 다른 주소로 DNS 요청을 보내더라도 커널이 Fake IP, 캐시와 상위 DNS 선택을 일관되게 처리할 수 있습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

any:53은 일반적으로 대상 주소와 관계없이 포트 53으로 향하는 DNS 트래픽을 가로챈다는 의미입니다. UDP, TCP와 구체적인 표기 방식에 대한 지원은 운영체제, 커널 버전과 TUN 스택에 따라 다르므로 클라이언트가 생성한 유효 설정과 시작 로그를 기준으로 확인해야 합니다. TUN만 활성화하고 DNS 요청을 내장 DNS로 전달하지 않으면 시스템이 기존 DNS 경로를 계속 사용할 수 있으며, Fake IP와 도메인 규칙도 예상과 다르게 작동할 수 있습니다.

DNS 하이재킹으로 모든 암호화 DNS를 가로챌 수는 없습니다

브라우저나 애플리케이션이 DoH를 내장하고 HTTPS의 443 포트로 자체 DNS 서비스에 직접 연결할 수 있습니다. 이런 트래픽은 네트워크 계층에서 일반 HTTPS 연결로 보이므로 포트 53 하이재킹만으로 Clash DNS 조회로 자동 변환되지 않습니다. DoT는 보통 853 포트를 사용하므로 일반적인 53 포트 가로채기 범위에도 포함되지 않습니다. 특정 브라우저의 결과가 시스템 조회 결과와 다르다면 애플리케이션에서 별도의 보안 DNS 기능을 활성화했는지 확인해야 합니다.

애플리케이션 자체의 DoH 트래픽이 프록시 규칙으로 전달되더라도 도메인 조회는 Clash 설정의 nameserver가 아니라 애플리케이션이 선택한 DoH 서비스가 수행합니다. 그 결과 애플리케이션이 실제 IP를 받은 뒤 연결하거나, 규칙이 대상 IP를 기준으로만 매칭되는 두 가지 상황이 생길 수 있습니다. DNS 경로를 통일하려면 애플리케이션 설정, 시스템 DNS와 TUN 가로채기 범위를 함께 점검해야 합니다.

LAN과 특수 도메인은 필터링이 필요합니다

Fake IP 모드에서는 일부 로컬 도메인, 장치 검색 도메인, NTP 서비스, 게임 플랫폼 연결과 실제 주소에 의존하는 프로그램을 fake-ip-filter에 추가해야 할 수 있습니다. 필터링된 도메인은 일반적으로 실제 조회 결과를 반환하며 Fake IP를 할당하지 않습니다. 실제 장애가 발생한 항목만 하나씩 추가해야 하며, 많은 최상위 도메인을 통째로 제외하면 Fake IP 모드가 도메인 매핑을 유지하는 장점이 약해집니다.

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"
    - "ntp.*.com"

.local은 mDNS 장치 검색과 관련된 경우가 많으며 실제 조회가 일반 유니캐스트 DNS를 거치지 않을 수 있습니다. 이를 필터 목록에 추가하면 Fake IP 할당을 피할 수 있을 뿐, LAN 멀티캐스트 전달, 시스템 방화벽 또는 장치 검색 서비스를 대신할 수는 없습니다. LAN 장치에 접근할 수 없다면 TUN 라우팅, 우회 대역과 로컬 인터페이스 선택도 확인해야 합니다.

DNS 결과가 프록시 규칙 매칭에 미치는 영향

Clash는 일반적으로 규칙을 위에서 아래로 매칭합니다. DOMAIN, DOMAIN-SUFFIX와 RULE-SET의 도메인 규칙은 요청 도메인을 바로 사용할 수 있지만, IP-CIDR와 GEOIP 같은 규칙에는 대상 주소가 필요합니다. 연결 입구에서 IP만 제공될 때 커널이 도메인을 복원할 수 있는지는 Fake IP 매핑, 프로토콜 스니핑과 연결 방식에 따라 달라집니다. DNS 설정의 목적 중 하나는 연결 단계에서도 도메인 정보가 규칙에 최대한 활용되도록 하는 것입니다.

규칙의 no-resolve 매개변수는 해당 IP 유형 규칙을 매칭할 때 주소를 얻기 위해 추가 DNS 조회를 발생시키지 말라는 뜻입니다. 불필요한 조회와 일부 순환 문제를 줄일 수 있지만, 현재 연결에 대상 IP가 없다면 규칙이 예상한 판단을 완료하지 못할 수도 있습니다. 사용하기 전에 앞쪽에 이미 도메인 매칭 규칙이 있는지, 연결 입구에서 실제 대상 주소를 제공하는지 확인해야 합니다.

DNS 서버의 출구 규칙도 중요합니다. DoH 서버는 HTTPS 대상이므로 그 자체가 Clash 규칙의 매칭 대상이 됩니다. 특정 DoH를 프록시로 접속하려면 프록시 노드가 이미 연결 가능한지 확인하고, 노드 도메인 조회가 아직 수립되지 않은 DoH 경로에 의존하지 않도록 해야 합니다. 로컬 DNS를 직접 연결하려면 해당 주소가 광범위한 프록시 규칙에 잘못 포함되지 않는지도 확인해야 합니다.

캐시 때문에 변경 사항이 적용되지 않은 것처럼 보일 수 있습니다

DNS 결과는 브라우저, 운영체제, Clash 커널과 상위 DNS의 캐시에 동시에 남을 수 있습니다. nameserver를 변경한 직후 다시 접속했을 때 이전 주소가 보인다고 해서 설정이 로드되지 않았다는 뜻은 아닙니다. 먼저 클라이언트가 설정을 다시 불러왔는지 확인하고, 영향을 받는 애플리케이션의 기존 연결을 종료한 뒤 필요하면 시스템 DNS 캐시를 비워야 합니다. 또한 상위 DNS 레코드의 TTL이 만료될 때까지 기다려야 할 수 있습니다.

HTTP/2, HTTP/3와 연결 풀은 이미 수립된 연결을 재사용하기도 합니다. 새 DNS 조회에서 다른 주소가 반환되어도 브라우저가 기존 연결을 계속 사용할 수 있습니다. 문제를 점검할 때는 시크릿 창, 애플리케이션 완전 종료, Clash 연결 목록과 로그 타임스탬프를 함께 확인해 문제가 새 조회에서 발생했는지 기존 세션에서 발생했는지 판단할 수 있습니다.

처리 경로에 따라 조회 오류 점검하기

DNS 장애는 요청 유입부터 연결 출구까지 단계별로 확인하는 것이 좋습니다. 한 번에 하나의 변수만 변경하면 여러 설정 문제가 겹치는 것을 피할 수 있습니다. 다음 순서는 ‘도메인은 열리지 않지만 IP는 연결되는 경우’, ‘시스템 프록시는 정상인데 TUN이 작동하지 않는 경우’, ‘Fake IP 활성화 후 일부 애플리케이션이 작동하지 않는 경우’에 적용할 수 있습니다.

  1. 커널이 설정을 받아들였는지 확인합니다.

    먼저 Clash Verge의 설정 검사 결과와 시작 로그를 확인합니다. YAML 들여쓰기 오류, 필드 오타 또는 현재 커널이 지원하지 않는 옵션 때문에 DNS 모듈이 예상대로 시작되지 않을 수 있습니다. 수신 주소, 향상 모드와 상위 DNS가 정상적으로 로드됐는지 중점적으로 확인합니다.

  2. 조회 요청이 Clash에 도달했는지 확인합니다.

    시스템 프록시는 프록시 설정을 지원하는 애플리케이션의 트래픽만 가로채며 운영체제의 모든 DNS 요청을 자동으로 가로채지는 않습니다. DNS 하이재킹을 사용하려면 TUN이 활성화되어 있고 자동 라우팅이 정상인지, 요청이 가상 인터페이스로 들어가는지 확인해야 합니다. Clash의 nameserver만 수정하고 애플리케이션이 시스템 DNS에 직접 조회를 보내면 두 결과는 계속 달라집니다.

  3. 상위 DNS에 연결할 수 있는지 확인합니다.

    일반 DNS는 53번 포트의 UDP 또는 TCP 연결 가능성을 확인하고, DoH는 HTTPS 연결, 인증서와 시스템 시간을 확인하며, DoT는 853번 포트와 TLS 핸드셰이크를 확인합니다. 호스트명이 포함된 상위 DNS라면 default-nameserver가 부트스트랩 조회를 완료할 수 있는지도 검증해야 합니다.

  4. 결과 유형을 확인합니다.

    Fake IP 모드에서 198.18.0.0/16과 같은 예약 주소가 보이는 것은 일반적으로 정상적인 동작이며 곧바로 조회 오류로 판단해서는 안 됩니다. 실제로 확인해야 할 부분은 이후 연결이 Clash로 들어가는지, 커널이 Fake IP에서 원래 도메인을 복원할 수 있는지입니다.

  5. 규칙과 DNS 출구를 대조합니다.

    조회 대상 DNS의 도메인 또는 IP가 최종적으로 DIRECT에 매칭됐는지, 프록시 정책 그룹에 매칭됐는지 확인합니다. 원격 DoH가 사용할 수 없는 노드로 배정되면 조회가 시간 초과되고, 내부 DNS가 공용 프록시로 전송되면 LAN 도메인도 조회되지 않을 수 있습니다.

  6. 설정을 줄인 뒤 항목별로 복원합니다.

    우선 사용 가능한 nameserver 한 그룹만 남기고 복잡한 fallback 필터와 도메인별 정책을 끈 상태에서 기본 조회를 확인합니다. 이후 fallback, nameserver-policy, 프록시 노드 전용 DNS와 Fake IP 필터를 차례로 복원하고, 변경할 때마다 로그와 조회 결과를 확인합니다.

설정 방식을 선택하는 간단한 원칙

  • 일반 조회를 통일하기만 하면 신뢰할 수 있는 default-nameserver와 nameserver부터 설정합니다.
  • 도메인 매핑을 유지하면서 TUN을 함께 사용해야 한다면 fake-ip와 DNS 하이재킹을 테스트한 뒤 특수 도메인에 필터를 추가합니다.
  • 두 그룹의 후보 결과를 선별해야 할 때 fallback과 fallback-filter를 사용합니다.
  • 업무 도메인별로 DNS를 지정해야 한다면 커널이 지원하는 nameserver-policy를 우선 검토합니다.
  • 프록시 노드 주소가 도메인이고 시작 시 조회가 복잡하다면 노드 도메인 전용 조회 경로를 따로 설정합니다.

안정적인 Clash DNS 설정은 필드가 많을수록 좋은 것이 아니라 각 조회 경로의 출처, 출구와 사용 조건을 설명할 수 있어야 합니다. 먼저 작동하는 기본 경로를 만든 뒤 LAN, IPv6, TUN과 특정 애플리케이션 요구에 맞춰 확장해야 장애가 발생했을 때 문제가 시스템 DNS, Clash 커널, 상위 DNS 또는 프록시 규칙 중 어디에 있는지 빠르게 판단할 수 있습니다.

Clash Verge 계속 설치하기

다운로드 페이지에서 운영체제와 아키텍처를 선택하거나 전체 설치 단계를 먼저 확인하세요.

다운로드 페이지로 이동 설치 가이드 보기
Clash 다운로드