Clash DNS 설정 완전 정리: nameserver, fallback, DNS 하이재킹 대응법

Clash에서 DNS 항목의 위치와 역할

Clash 설정 파일에서 dns 항목은 proxies나 rules와는 독립된 모듈입니다. 트래픽이 어떤 프록시 노드를 지나는지는 신경 쓰지 않고, 오직 하나의 일만 처리합니다. 바로 도메인을 어떤 IP 주소로 해석할지 결정하는 것입니다. 이 과정은 규칙 매칭보다 먼저 일어납니다 — Clash는 도메인을 받으면 먼저 대응하는 IP를 알아야 GEOIP, IP-CIDR 같은 규칙으로 경로를 판단할 수 있습니다. dns 항목 설정이 잘못되면 규칙 분기의 정확도가 바로 영향을 받으며, 대표적인 증상은 직접 연결 규칙을 설정했는데도 계속 프록시를 거치거나, 반대로 프록시를 타야 하는데 직접 연결되는 경우입니다.

dns 항목의 핵심 필드는 enable(Clash 자체 DNS 처리 사용 여부), listen(리스닝 주소, 보통 TUN 모드와 함께 사용), enhanced-mode(fake-ip 또는 redir-host), nameserver(주 해석 서버 목록), fallback(보조 해석 서버 목록), fallback-filter(fallback을 언제 사용할지 판단하는 규칙)입니다. 이 항목들이 서로 맞물려 전체 해석 흐름을 구성합니다.

nameserver와 fallback의 역할 차이

nameserver는 주 해석 서버 목록으로, Clash는 우선적으로 이 서버들로 도메인을 해석합니다. fallback은 보조 해석 서버 목록으로, 특정 조건이 트리거될 때만 사용되며, 단순히 "nameserver가 실패하면 fallback으로 전환"하는 구조가 아닙니다.

nameserver 설정 팁

통신사 해석 속도가 빠르고 지리적으로 가까운 서버를 넣는 것이 좋습니다. 흔한 조합은 공용 DNS와 현지 통신사 DNS를 함께 쓰는 방식입니다:

nameserver:
  - 223.5.5.5
  - 119.29.29.29
  - 114.114.114.114

fallback이 트리거되는 조건

fallback에는 보통 해외 또는 다른 네트워크의 해석 서버, 예를 들어 1.1.1.1, 8.8.8.8을 넣습니다. 이는 무조건적인 보조가 아니라 fallback-filter와 함께 동작합니다 — nameserver로 해석한 결과가 "믿을 수 없다"고 판단될 때(예: geoip 범위 밖의 주소이거나 특정 규칙에 매칭될 때)만 Clash는 fallback으로 바꿔서 다시 해석합니다. 이 메커니즘의 의미는, 한국 국내 도메인은 국내 DNS로 처리해 가까운 CDN 노드를 받아 접속 지연을 줄이고, 반면 오염되었거나 프록시를 거쳐야 하는 도메인은 깨끗한 해외 DNS로 처리해 잘못된 해석 결과를 받지 않도록 하는 것입니다.

fallback:
  - tls://1.1.1.1:853
  - tls://8.8.8.8:853

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

위 설정의 의미는, nameserver로 해석한 IP가 중국 본토에 속하지 않거나(geoip-code: CN 밖) domain 목록에 있는 도메인과 일치하면 이 해석 결과를 신뢰할 수 없다고 판단하고 fallback 서버로 다시 조회한다는 것입니다. 이렇게 하면 오염된 도메인에 접속할 때는 올바른 해외 해석 결과를 받고, 국내 사이트에 접속할 때는 여전히 가장 빠른 로컬 DNS를 사용하게 됩니다.

fake-ip와 redir-host: 두 가지 강화 모드의 차이

enhanced-mode 필드는 Clash가 DNS 해석 결과를 어떤 방식으로 처리할지 결정하며, 선택 가능한 값은 fake-ip와 redir-host입니다. 두 모드의 설계 목표가 다르고 적합한 상황도 다릅니다.

fake-ip 모드

fake-ip 모드에서는 Clash가 DNS 조회 요청을 가로채, 도메인이 실제로 대응하는 IP를 반환하지 않고 예약된 주소 범위(기본값 198.18.0.0/16) 안의 가상 IP를 반환합니다. 애플리케이션은 이 가상 IP로 연결을 시도하고, Clash는 트래픽이 지나갈 때 가상 IP를 실제 도메인으로 되돌려 규칙 엔진에게 경로를 판단하게 한 뒤, 마지막으로 실제 IP를 해석해 전달합니다.

이 모드의 장점은 해석 속도가 빠르고(매번 실제 DNS 조회 결과를 기다릴 필요가 없음) 규칙 매칭이 IP에 의존하지 않고 도메인으로 바로 처리되어 정확도가 높다는 점입니다. TUN 모드와 함께 사용할 때는 fake-ip가 거의 기본 선택입니다. 단점은 IP 주소에 강하게 의존하는 일부 소프트웨어(예: 특정 게임 온라인 플레이, LAN 검색 프로토콜)가 가상 IP를 받아 오작동할 수 있어, 이런 도메인은 fake-ip-filter에서 개별적으로 제외해야 합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*.*"
    - "time.*.com"

redir-host 모드

redir-host 모드에서는 Clash가 nameserver/fallback에 직접 조회해 실제 IP를 애플리케이션에 그대로 반환하며, 가상 주소 치환을 하지 않습니다. 규칙 매칭 단계는 이 실제 IP나 조회 단계에서 기록된 도메인 대응 관계에 의존합니다. 이 모드는 호환성이 더 좋아서 애플리케이션이 "가짜" 주소를 받아 오작동하는 경우가 거의 없지만, 해석 오버헤드가 더 크고 일부 복잡한 상황에서는 규칙 매칭이 fake-ip보다 덜 정확합니다.

DNS 하이재킹 판단 및 대응 상황

DNS 하이재킹이란 해석 요청이 전송 과정에서 중간 노드에 의해 조작되어 잘못된 IP 주소가 반환되고, 그 결과 광고 페이지나 오류 페이지로 리다이렉트되거나 아예 연결이 되지 않는 현상을 말합니다. DNS 하이재킹이 발생했는지 판단하는 흔한 방법은 서로 다른 DNS 서버로 같은 도메인을 각각 해석해 결과를 비교하는 것입니다 — 로컬 통신사 DNS가 반환한 IP가 알려진 공용 DNS의 결과와 크게 다르고 접속에 이상이 있다면 하이재킹이나 오염이 있다고 거의 확신할 수 있습니다.

Clash의 관점에서 fallback-filter 메커니즘 자체가 DNS 하이재킹에 대응하는 수단 중 하나입니다: geoip와 도메인 목록으로 해석 결과의 신뢰성을 판단하고, 신뢰할 수 없으면 다른 서버 그룹으로 재조회합니다. 이 외에 다음과 같은 부분도 고려할 수 있습니다:

• nameserver는 DoH(DNS over HTTPS)나 DoT(DNS over TLS)를 지원하는 서버 주소를 우선 사용해, 평문 조회가 조작될 가능성을 줄입니다. 형식은 https://dns.server/dns-query 또는 tls://dns.server:853입니다.
• 이미 오염된 것으로 알려진 도메인은 hosts 항목에 정확한 IP를 직접 지정해 DNS 조회 단계를 우회할 수 있습니다.
• use-hosts 필드가 켜져 있는지 확인해, hosts 항목의 정적 매핑이 DNS 조회보다 우선 적용되도록 합니다.

dns:
  enable: true
  use-hosts: true
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN

hosts:
  example.local.test: 127.0.0.1

DNS 하이재킹과 프록시 규칙 분기는 서로 다른 차원의 문제라는 점에 유의해야 합니다. 프록시 노드 자체는 정상 작동하는데 특정 사이트 접속에 계속 이상이 있다면, 먼저 DNS 해석 단계에 문제가 있는지 확인하고 노드나 규칙 작성이 틀렸다고 처음부터 의심하지 마세요. 반대로 여러 DNS 서버로 해석해도 결과가 일관되고 정확한데 접속이 계속 실패한다면, 문제는 프록시 노드나 규칙 매칭 쪽에 있을 가능성이 더 큽니다.

누출 방지 포인트와 전체 예시

DNS 누출이란 원래 프록시를 거쳐야 할 도메인 해석 요청이 실제로는 Clash를 우회해 시스템 기본 DNS 서버로 직접 전송되어, 실제 접속 의도가 노출되는 현상입니다. 누출을 막으려면 다음 몇 가지에 주의해야 합니다:

1. 시스템 레벨의 프록시 설정 또는 TUN 모드가 트래픽을 정확히 인계했는지 확인하고, 일부 애플리케이션만 프록시를 켠 채 시스템 수준의 DNS 조회 통로를 빠뜨리지 마세요.
2. dns 항목의 enable 필드는 반드시 true여야 합니다. 그렇지 않으면 Clash는 해석 과정에 개입하지 않고 모든 조회가 시스템 기본 경로를 거칩니다.
3. listen 필드는 명시적으로 지정하는 것을 권장합니다. 예를 들어 0.0.0.0:1053으로 설정하고, 운영체제나 라우터 단계의 DNS 요청이 이 리스닝 포트로 정확히 전달되는지, 시스템 자체 DNS 클라이언트를 거쳐 우회되지 않는지 확인하세요.
4. TUN 모드를 켤 때는 dns의 fake-ip 또는 redir-host 모드와 TUN의 stack 설정이 일치하는지 함께 확인해, 두 해석 로직이 서로 충돌해 일부 요청이 빠져나가는 것을 방지하세요.
5. DoH/DoT를 지원하는 nameserver를 사용해, 통신사가 전송 계층에서 조회 내용을 관찰하고 조작할 기회를 줄이세요.

아래는 본문의 모든 포인트를 종합한 전체 dns 항목 예시입니다. 설정 파일에 바로 적용한 뒤 실제 노드 상황에 맞춰 nameserver와 fallback의 구체적인 주소를 조정하면 됩니다:

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  use-hosts: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*.*"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.github.io

여기서 default-nameserver 필드는 따로 설명할 필요가 있습니다: 이 필드는 nameserver와 fallback에 도메인 형태로 적힌 DoH 서버 주소를 해석하기 위한 전용 필드입니다(위 예시의 223.5.5.5/dns-query 자체는 IP지만, 도메인 형태의 DoH 주소로 바꾸면 default-nameserver가 먼저 이 DoH 서버 자체의 IP를 해석해야 실제 사용자 도메인 조회가 가능해집니다). 자칫 놓치기 쉽지만 해석 흐름이 제대로 작동하는지에 영향을 주는 세부 사항입니다.