dns 블록을 먼저 잡아야 하는 이유

프록시 규칙은 아무리 정교해도, 애플리케이션이 최초로 묻는 이름(IP)이 어긋나면 체감은 「사이트가 안 열린다」 한 줄로 압축됩니다. Clash Meta 계열은 dns 섹션에서 누가 질의를 받고, 어떤 서버로 재귀적으로 물어보며, 의심스러운 응답일 때 예비 서버로 넘길지까지 한 파일 안에서 정의할 수 있습니다. 로그에서 DNS 줄만 뒤집기보다, nameserver·fallback·fake-ip-filter를 먼저 고정하면 같은 증상도 재시도 횟수가 줄어듭니다.

이 글의 fallback은 DNS 후보 서버 목록을 뜻합니다. 정책 그룹의 type: fallback과 이름이 비슷하지만 완전히 다른 레이어이니 혼동하지 마세요. DNS가 맞으면 규칙 라우팅과의 정렬도 훨씬 수월해집니다.

ℹ 용어: 본문의 YAML은 Mihomo/Clash Meta 계열에서 흔한 키 이름을 기준으로 합니다. GUI 클라이언트는 같은 옵션을 다른 탭 이름으로 보여 줄 수 있으니, 저장된 프로필 원문을 함께 열어 대조하면 가장 안전합니다.

1단계: enable·listen·기본 동작 켜기

dns.enable: true가 꺼져 있으면 나머지 키는 무시되거나 클라이언트 기본값으로 떨어집니다. 로컬에서 DNS 리스너를 열 계획이라면 listen 주소(예: 0.0.0.0:53 또는 127.0.0.1:1053)를 명시하고, OS 방화벽·다른 리졸버와 포트가 겹치지 않는지 확인합니다. IPv6만 쓰는 환경이면 [::]:53 형태를 검토하되, 권한·보안 정책에 맞는지 함께 봅니다.

dns — enable & listen (minimal) 
dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

enhanced-mode는 fake-ip와 redir-host(또는 구버전 표기) 중에서 고릅니다. Fake-IP는 규칙 엔진과의 궁합이 좋은 대신, LAN·캡티브 포털·일부 스트리밍 검증에 민감할 수 있어 fake-ip-filter가 뒤에서 이어집니다. 모드 선택과 LAN 이슈는 Fake-IP·LAN 우회 글과 겹치는 부분이 있으니 함께 두고 보시면 흐름이 잡힙니다.

2단계: default-nameserver로 DoH 호스트부터 풀기

nameserver에 https://dns.google/dns-query처럼 도메인이 들어간 엔드포인트를 넣으면, 그 도메인을 또 다른 DNS로 먼저 풀어야 합니다. 이 때 쓰는 것이 default-nameserver입니다. 여기를 비워 두거나 ISP DNS가 불안정하면 「DoH URL은 넣었는데 아무 일도 안 일어난다」처럼 보일 수 있습니다. 보통은 OS DHCP가 주는 dhcp://system이나 신뢰할 수 있는 평문 UDP/TCP 리졸버를 1~2개 넣습니다.

default-nameserver example 
dns:
  enable: true
  default-nameserver:
    - dhcp://system
    - 119.29.29.29
  nameserver:
    - https://dns.google/dns-query
    - tls://dns.quad9.net

코어 버전에 따라 키 이름이 default-nameserver 외에도 문서화된 별칭이 있을 수 있습니다. 중요한 것은 의존 관계입니다: DoH/DoT의 호스트 이름을 누가, 어떤 경로로 해석하는지가 먼저 안정되어야 합니다.

3단계: nameserver — 일상 해석의 1차 목록

nameserver는 말 그대로 1차로 시도할 서버 목록입니다. 지연·가용성·프라이버시 정책에 맞게 2~4개 정도를 섞는 경우가 많습니다. 한국·해외 회선을 오가는 사용자라면, 지나치게 한쪽 지역에만 붙어 있는 측정용 호스트만 고집하기보다 실제로 자주 묻는 도메인이 빠르게 풀리는 조합을 택합니다.

nameserver — mixed transports 
  nameserver:
    - https://dns.google/dns-query
    - tls://1.1.1.1
    - dhcp://system

dhcp://system는 편리하지만, 공유기가 느리거나 가짜 IP를 돌려주는 환경에서는 오히려 병목이 됩니다. 이때는 시스템 대신 명시적인 리졼만 남기고, 문제가 재현되는지 비교해 보는 것이 좋습니다. DNS와 무관해 보이는 TLS 타임아웃이 반복되면 연결 로그·TLS 해석으로 넘어가기 전에, 이 절의 목록부터 좁혀 보세요.

4단계: fallback + fallback-filter 체인

fallback은 「항상 마지막에 쓰는 서버」가 아니라, fallback-filter 조건을 만족할 때 추가로 시도하는 예비 서버 묶음으로 이해하는 편이 안전합니다. 대표적으로 GEOIP 기반 필터가 켜져 있으면, 1차 nameserver가 돌려준 IP가 특정 국가/대역으로 분류될 때 fallback 쪽으로 재질의하는 흐름이 만들어집니다. 운영 목적과 데이터베이스 경로가 맞지 않으면 기대와 다른 「자꾸 fallback만 탄다/안 탄다」가 생깁니다.

fallback-filter를 짤 때의 기준

geoip·geoip-code·ipcidr·domain 등 필터 항목은 코어 문서의 최신 설명을 한 번 확인하는 것이 좋습니다. 예시는 형태를 보여 주기 위한 것이며, 본인이 거주·근무하는 관할의 법령과 회사 정책에 맞게 서버 위치와 로깅 정책을 선택해야 합니다.

fallback chain — example shape 
  nameserver:
    - https://dns.google/dns-query
    - dhcp://system
  fallback:
    - tls://dns.quad9.net
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.google.com"

위 예에서 geoip-code는 샘플입니다. 한국 기준으로 조정하고 싶다면 데이터베이스가 어떤 코드를 쓰는지에 맞춰 바꿉니다. ipcidr에 넣은 보류 대역은 「이 응답은 신뢰하기 어렵다」는 신호로 쓰는 패턴이며, 환경마다 후보 대역이 다릅니다. domain 리스트는 특정 접미사를 fallback 경로로 보내고 싶을 때 활용합니다.

⚠ 주의: fallback 체인을 길게 늘리면 질의당 지연이 누적됩니다. 「안전」과 「속도」 사이에서 후보 수를 과하게 늘리지 말고, 로그로 실제로 어떤 서버가 선택됐는지 확인하며 조정하세요.

5단계: fake-ip-filter와 redir-host 선택

enhanced-mode: fake-ip일 때 특정 이름은 가짜 IP로 돌려주지 않고 실제 응답을 받아야 하는 경우가 있습니다. 대표적으로 *.local, *.lan, 공유기 호스트명, NTP, 일부 캡티브 포털 검출용 도메인 등입니다. 이런 항목을 fake-ip-filter(또는 동등 옵션)에 넣으면 Fake-IP 풀에서 제외됩니다.

fake-ip-filter — common entries 
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.home.arpa"
    - "router"
    - "time.windows.com"
    - "+.stun.l.google.com"

목록은 집·사무실마다 다릅니다. 스마트 기기·NAS·프린터가 짧은 호스트명만 쓰는 경우가 있어, 실제로 실패한 이름을 한두 개씩 추가하는 방식이 실전에서 가장 확실합니다. Fake-IP 대신 redir-host를 고집할지, 필터로 Fake-IP를 유지할지는 트래픽 패턴과 클라이언트 기능에 따라 갈립니다. LAN과의 충돌을 줄이는 다른 각도는 앞서 인용한 Fake-IP 글을 참고하세요.

TUN·시스템 DNS와 DNS 누수 체크

TUN을 켜면 운영체제의 기본 라우트가 가상 어댑터 쪽으로 기울고, 일부 OS는 여전히 자체 DNS 설정(공유기에서 받은 DNS, DHCP 옵션)을 애플리케이션에 노출합니다. Clash 쪽 dns가 완벽해도, 특정 앱이 시스템 API로 다른 리졸버를 직접 부르면 「누수」로 관측될 수 있습니다. 대응은 (1) OS DNS를 루프백/Clash 리스너로 맞추기, (2) TUN 스택에서 hijack·route 옵션을 검토하기, (3) 문제 앱만 예외 처리하기 같은 층을 나누는 것입니다.

구체 키 이름은 플랫폼·클라이언트마다 다르지만, 점검 질문은 공통입니다. 「지금 이 앱의 질의가 Clash 로그에 찍히는가?」, 「시스템 resolv.conf 또는 Windows NIC DNS가 무엇을 가리키는가?」, 「브라우저만 이상한가, 터미널도 그런가?」를 나누면 원인이 dns 블록인지 OS·앱 경로인지 빨리 갈립니다. TUN 내부 동작을 더 깊게 보고 싶다면 TUN 모드 심화 글의 DNS 관련 절을 이어서 읽으면 전체 그림이 잡힙니다.

외부 사이트에서 DNS 누수 테스트를 돌릴 때는, 테스트 자체가 어떤 프로토콜·어떤 네트워크 경로를 쓰는지 확인하세요. VPN/프록시와 동시에 여러 도구를 돌리면 결과가 섞여 보일 수 있습니다.

자주 하는 실수와 점검 순서

  1. DoH 호스트를 풀 default가 없음: default-nameserver를 먼저 채웁니다.
  2. DNS fallback과 프록시 fallback 혼동: 한쪽만 손대고 다른 쪽을 기대합니다. 레이어를 구분합니다.
  3. fake-ip-filter 누락: LAN·포털·게임·VoIP 관련 이름이 가짜 IP로 매핑되어 이상 증상이 납니다.
  4. fallback-filter와 GEOIP DB 불일치: 코드·경로·업데이트 주기를 확인합니다.
  5. 포트 충돌: listen이 다른 리졸버와 겹치면 조용히 실패합니다.
  6. 규칙과 DNS 불일치: 도메인 규칙은 맞는데 실제 연결 IP가 다른 출구를 탑니다. Fake-IP·스니퍼·규칙 순서를 함께 봅니다.

위 순서는 로그를 보기 전에도 적용할 수 있는 설정 점검 루틴입니다. 막힌 뒤에야 로그를 연다면, 이미 여러 변수가 동시에 바뀐 뒤인 경우가 많습니다.

준수 알림

⚠ 준수 알림: 현지 법령·서비스 약관·고용주·학교·공공망 정책을 준수하세요. 본문은 허용된 네트워크에서 Clash Meta(Mihomo) DNS 설정을 이해하기 위한 기술 설명이며, 무단 감시·과금 우회·타인에게 피해를 주는 트래픽 조작을 조장하지 않습니다.

기업망·제로 트러스트·SSL 검사 환경에서는 동일한 YAML도 동일하게 동작하지 않을 수 있습니다. 기술적으로 가능하다고 해서 정책상 허용된다는 뜻은 아닙니다.

맺음말

Clash Meta DNS는 nameserver 한 줄로 끝나지 않고, default-nameserver·fallback·fallback-filter·fake-ip-filter가 같은 스토리 안에서 맞물립니다. 1차 서버가 돌려준 응답이 신뢰할 만한지, Fake-IP를 쓸 때 어떤 이름을 실제 해석으로 빼야 하는지, TUN을 켠 뒤 OS가 여전히 다른 DNS를 노출하는지까지 순서대로 보면 「연결 실패 로그」에 끌려 다니는 시간이 줄어듭니다. 한 번에 다 바꾸지 말고, 한 블록씩 수정한 뒤 질의가 기대한 서버로 가는지 확인하는 습관이 장기적으로 가장 큰 이익을 줍니다.

같은 코어라도 클라이언트 UI가 DNS 탭을 어떻게 노출하느냐에 따라 실수 빈도가 달라집니다. YAML 원문을 함께 열어 두면 fallback이 DNS인지 프록시인지, fake-ip-filter가 빈 값은 아닌지 한눈에 잡히는 편이 좋습니다. 다른 도구에 비해 Clash는 규칙과 DNS를 한 프로필에 서술할 수 있어, 재현성이 높다는 장점이 있습니다.

→ Clash를 무료로 다운로드하고, Meta DNS·nameserver·fallback·fake-ip-filter를 한 프로필에서 정리해 보세요.