Clash DNS 설정 완벽 가이드: nameserver, fallback과 DNS 하이재킹의 관계

DNS 모듈이 Clash에서 차지하는 위치

Clash의 분기 규칙은 두 종류로 나뉩니다. 도메인 기반 매칭(DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD)과 IP 기반 매칭(IP-CIDR, GEOIP)입니다. IP 기반 규칙은 먼저 도메인에 해당하는 주소를 확보해야 방향을 판단할 수 있기 때문에, Clash는 해석 작업을 운영체제에 넘기지 않고 자체적으로 완전한 DNS 해석 모듈을 내장하고 있습니다. 도메인 규칙은 연결이 들어오는 시점에 바로 매칭되지만, IP 규칙은 DNS 모듈이 내놓은 해석 결과에 의존하며, 두 요소가 함께 하나의 연결이 어느 정책 그룹으로 가는지를 결정합니다.

시스템 기본 DNS는 대개 통신사에서 지정한 평문 UDP 53 서비스로, 쿼리 내용이 전 구간에서 그대로 노출되고 중간 장비에 의해 변조될 수 있습니다. Clash가 DNS를 관리하기 시작하면 어떤 경로로, 어떤 프로토콜로 질의하고, 어느 결과를 신뢰할지 모두 설정 파일에서 고정할 수 있습니다. nameserver, fallback, enhanced-mode 같은 항목이 존재하는 이유가 바로 여기에 있습니다.

dns 항목의 전체 스위치는 enable이며, listen은 Clash가 어떤 주소와 포트에서 질의에 응답할지를 정합니다. 흔히 0.0.0.0:53 형태로 씁니다. 데스크톱 클라이언트에서 시스템 프록시나 TUN 모드를 켜면 보통 시스템 DNS가 이 리슨 주소로 자동 전환되며, 같은 네트워크의 다른 기기도 DNS를 이곳으로 수동 지정해 질의를 한곳으로 모을 수 있습니다.

nameserver: 메인 업스트림과 작성 방식

nameserver는 Clash의 메인 해석 경로로, 목록에는 세 가지 형태를 넣을 수 있습니다.

• 223.5.5.5처럼 순수 IP 형태이며, 기존 평문 UDP 53으로 통신해 지연이 가장 낮습니다.
• tls://1.1.1.1:853 형태로, DNS over TLS를 사용해 암호화된 853 포트로 질의합니다.
• https://doh.pub/dns-query 형태로, DNS over HTTPS를 사용해 질의를 HTTPS 요청에 담아 전송합니다.

이 목록의 동작 방식은 동시 경쟁이며, 주-보조 관계가 아닙니다. Clash는 목록에 있는 모든 업스트림에 동시에 질의를 보내고 가장 먼저 응답이 온 결과를 사용합니다. 따라서 nameserver에는 지연이 낮은 업스트림 2~3개만 넣으면 충분하며, 항목을 무작정 늘려도 신뢰성이 높아지지 않고 아웃바운드 트래픽만 늘어납니다.

nameserver와 짝을 이루는 것이 default-nameserver로, 전체 경로의 초기 해석기 역할을 합니다. DoH, DoT 업스트림은 도메인 형태로 지정되는데, “그 해석기 자체의 도메인”을 풀 때 다시 이 업스트림에 의존하면 순환 참조가 발생합니다. default-nameserver에는 직접 UDP로 접근 가능한 순수 IP만 넣어야 하며, 예를 들어 223.5.5.5, 119.29.29.29 같은 값을 사용합니다. 이는 부팅 단계에서만 쓰이며 평소 질의는 이곳을 거치지 않습니다.

fallback과 fallback-filter: 결과를 판정하는 논리

fallback에 대해 가장 흔한 오해는 “메인 업스트림이 죽어야 작동한다”는 것입니다. 실제로는 fallback을 설정하면 Clash가 같은 도메인에 대해 nameserver와 fallback 두 그룹에 동시에 질의를 보내고, fallback-filter 규칙에 따라 어느 결과를 신뢰할지 결정합니다. fallback은 결과 필터링 메커니즘이며 장애 조치 메커니즘이 아닙니다.

기본 판정 조건은 geoip: true와 geoip-code: CN입니다. nameserver가 반환한 IP가 중국 본토 소속이면 nameserver의 결과를 사용하고, 그렇지 않으면 fallback의 결과로 바꿔 씁니다. 이 로직의 의도는 명확합니다. 중국 본토 도메인은 낮은 지연의 국내 업스트림을 신뢰하고, 해외 도메인의 해석 결과는 암호화되어 해외로 나가는 업스트림만 신뢰하는 것입니다.

fallback-filter에는 두 가지 보조 조건이 더 있습니다. ipcidr은 신뢰할 수 없는 대역을 나열하며, 반환된 IP가 그 안에 속하면(예: 예약 대역 240.0.0.0/4) 결과가 오염된 것으로 판단해 fallback 결과를 강제 사용합니다. domain은 무조건 fallback 결과를 쓰는 도메인을 나열하며, 특정 대상이 변조당한다는 것을 확인한 경우에 적합합니다.

빠뜨릴 수 없는 전제가 하나 있습니다. fallback 업스트림은 반드시 모두 DoH나 DoT를 사용해야 합니다. fallback에 평문 UDP 주소를 넣으면 해외 도메인 질의도 여전히 평문으로 나가게 되어 하이재킹과 변조 문제가 그대로 남고, fallback 메커니즘이 무력화됩니다.

enhanced-mode: fake-ip와 redir-host의 차이

enhanced-mode는 Clash가 애플리케이션의 DNS 요청에 어떻게 응답할지를 결정하며, 두 가지 값이 서로 다른 경로에 대응합니다.

redir-host는 전통적인 방식입니다. Clash가 도메인 연결을 받으면 먼저 실제 해석을 한 번 수행해 IP를 얻은 뒤 규칙에 따라 전달합니다. 동작이 직관적이고 호환성이 가장 좋지만, 그 대가로 로컬에서 실제 DNS 질의가 발생하며, 이 질의가 네트워크를 거치는 과정에서 하이재킹되거나 기록될 여지가 남습니다.

fake-ip는 기본 권장 방식입니다. Clash는 해석이 필요한 도메인에 대해 fake-ip-range(기본값 198.18.0.1/16) 대역 안의 가상 주소를 바로 반환하고, 애플리케이션이 이 가상 주소로 연결을 시도하면 Clash가 원래 도메인을 역으로 찾아내 도메인 규칙에 따라 분기하며, 실제 해석은 프록시 출구 쪽에서 이뤄지도록 미룹니다. 로컬에서는 거의 실제 도메인 질의가 발생하지 않아 하이재킹 주체가 변조할 평문 요청을 잡아낼 수 없고, 지연도 왕복 한 번만큼 줄어듭니다.

fake-ip-filter에는 가상 주소를 반환하지 않아야 하는 도메인을 나열합니다. 로컬 네트워크 도메인(*.lan, *.local), NTP 시각 동기화, STUN 홀펀칭 같은 서비스는 반드시 실제 IP를 받아야 정상 동작하며, 가상 주소를 받으면 즉시 오류가 발생하므로 이런 항목은 필터 목록에 남겨둬야 합니다. fake-ip는 로컬 네트워크 공유 프록시, 일부 P2P 매칭 시나리오와 호환 문제가 있을 수 있으니 이상 증상이 보이면 redir-host로 되돌리면 되고, 두 모드는 언제든 전환해 비교해볼 수 있습니다.

dns 섹션 필드 빠른 참조

DNS 하이재킹의 원리와 설정 대응책

DNS 하이재킹의 대표적인 방식은 이렇습니다. 평문 UDP 53 질의가 통신사 게이트웨이를 지날 때, 게이트웨이가 실제 업스트림보다 먼저 위조된 응답을 반환해 도메인을 잘못된 IP로 연결시킵니다. 겉으로 드러나는 현상은 정상 사이트에 접속했는데 관련 없는 페이지로 넘어가거나, 같은 도메인이 네트워크 환경에 따라 전혀 다른 결과로 해석되는 것입니다. 하이재킹이 노리는 지점은 “평문”과 “53번 포트” 두 가지 특징이며, 대응책도 이 두 지점을 중심으로 짜야 합니다.

아래 네 가지가 동시에 충족돼야 하이재킹 방지가 완결됩니다.

1. nameserver와 fallback 모두 DoH, DoT를 사용해 질의 내용을 암호화하면, 중간 장비가 내용을 읽지도 변조하지도 못합니다.
2. enhanced-mode에서 fake-ip를 사용하면 프록시로 나가는 도메인에 대해 로컬에서 실제 해석을 하지 않아 공격 표면이 한층 줄어듭니다.
3. 시스템 DNS를 Clash의 listen 주소로 지정하거나 TUN 모드를 켜서 모든 트래픽을 넘기면, 모든 질의가 Clash 내부로 모이게 됩니다.
4. fallback-filter에서 geoip 판정을 유지하면, 해외 도메인 결과는 암호화된 업스트림에서만 나오고 국내 결과는 지연이 낮은 로컬 업스트림에서 나옵니다.

그대로 적용 가능한 전체 예시

아래 dns 설정은 위에서 다룬 항목들을 실제로 쓸 수 있는 예시로 정리한 것으로, 각 줄이 앞의 설명과 일대일로 대응합니다. 업스트림 주소만 원하는 것으로 바꿔 사용하면 됩니다.

dns:
  enable: true
  listen: 0.0.0.0:53
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - https://dns.google/dns-query
    - tls://1.1.1.1:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.example.com"

핵심 정리: default-nameserver의 순수 IP 두 개는 초기 해석을 담당하고, nameserver의 국내 DoH 두 개는 동시 경쟁하며, fallback의 암호화된 해외 업스트림 두 개가 뒤를 받칩니다. fallback-filter는 geoip-code CN으로 신뢰 여부를 가르고, ipcidr로 예약 대역 오염을 막으며, domain 목록은 필요에 따라 개별 도메인을 추가·삭제합니다. fake-ip-filter의 항목은 실제 로컬 네트워크 환경에 맞춰 보완하고, 특정 서비스에 이상이 생기면 먼저 필터 항목이 빠졌는지 의심해 보세요.

mihomo(Clash Meta)에서의 발전 사항

mihomo 커널은 위에서 다룬 필드를 그대로 완전히 지원하므로 기존 dns 설정을 그대로 옮겨 쓸 수 있습니다. 그 위에 더 세밀한 필드가 몇 가지 추가되어 있어 단계적으로 마이그레이션하기에 좋습니다.

• nameserver-policy: 도메인 접미사 규칙에 따라 업스트림을 지정하는 기능으로, fallback의 이분법적 판정보다 세밀합니다. 특정 도메인 그룹을 지정 DoH로 고정해 여러 해석 경로를 동시에 유지할 수 있습니다.
• proxy-server-nameserver: 설정 안의 노드 서버 도메인만 전용으로 해석하는 항목으로, 노드 도메인이 오염되어 전체 프록시 그룹이 먹통이 되는 상황을 막아 줍니다.
• direct-nameserver: 직결 트래픽 전용 해석 경로를 별도로 지정해 프록시 도메인 해석과 분리할 수 있습니다.
• respect-rules: DNS 질의 자체도 분기 규칙에 따라 출구를 선택하게 만들어, 해외 업스트림의 DoH 요청이 프록시를 거쳐 나가도록 해 간섭받을 확률을 한층 낮춥니다.

마이그레이션 권장 사항: 새로 작성하는 mihomo 설정은 nameserver-policy로 분기 의도를 표현하는 것을 우선하고, fallback은 최종 보완용으로 남겨두세요. 기존 설정을 급하게 다시 쓸 필요는 없으니, 먼저 fallback-filter 동작이 기대한 대로인지 확인한 뒤 하나씩 옮기면 됩니다.