고급 설정 약 10분

Clash DNS 설정 완전 정리: nameserver, fallback, DNS 하이재킹 세 가지 항목 채우는 법

dns 섹션의 enable, listen부터 시작해 nameserver와 fallback의 역할 분담, fallback-filter의 필터링 로직, TUN 모드에서 DNS 하이재킹이 Fake-IP와 함께 동작해야 하는 이유까지 필드별로 설명합니다.

Clash의 dns 섹션은 설정에서 가장 헷갈리기 쉬운 부분입니다. 똑같은 설정을 적용해도 어떤 사람은 페이지가 바로 열리고, 어떤 사람은 계속 로딩만 됩니다. 차이는 보통 노드가 아니라 nameserver, fallback, dns-hijack 세 필드의 조합에서 발생합니다. 이 글에서는 dns 섹션의 작성 순서에 따라 각 필드가 왜 필요한지, 언제 동작하는지 하나씩 설명합니다.

dns 섹션 먼저 제대로: enable, listen, enhanced-mode

dns 섹션은 단순한 스위치 묶음이 아니라 Clash에 내장된 DNS 서버의 전체 설정입니다. 쿼리 수신, 반환할 주소 결정, 결과를 라우팅 규칙에 전달하는 세 가지 역할을 담당합니다. 먼저 최소 구성부터 살펴보겠습니다.

dns:
  enable: true
  listen: 127.0.0.1:53
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

enable은 내장 DNS를 실행할지 결정합니다. 꺼져 있으면 시스템 프록시 모드에서 모든 도메인이 시스템 리졸버로 전달되고, 규칙의 GEOIP, IP-CIDR 판정이 오염된 주소를 받을 수 있어 분산이 정확하지 않게 됩니다. 켜면 Clash가 직접 리졸버가 되어 쿼리 결과가 규칙 매칭에도 함께 사용됩니다.

listen은 수신 주소와 포트를 결정합니다. 127.0.0.1:53은 본인 기기만 대상으로 하므로 순수 시스템 프록시 환경에 적합하고, 0.0.0.0:53은 LAN 기기와 TUN으로 가로채진 쿼리까지 처리하므로 TUN 모드에서는 후자를 권장합니다. 53 포트가 다른 프로그램에 점유된 경우 127.0.0.1:5353으로 변경할 수 있지만, 시스템 DNS와 프록시 설정도 함께 맞춰야 합니다.

enhanced-mode는 둘 중 하나를 선택합니다. fake-ip는 예약 대역의 가짜 주소를 반환하고, redir-host는 실제 주소를 반환합니다. 이 필드는 규칙 매칭에 가장 큰 영향을 주므로 4절에서 자세히 다룹니다. 먼저 결론만 기억하세요. TUN 모드에서는 fake-ip를 선택합니다.

필드역할권장 값
enable내장 DNS 실행 여부true
listen수신 주소:포트시스템 프록시는 127.0.0.1:53, TUN은 0.0.0.0:53
ipv6AAAA 쿼리 응답 여부false, IPv6 누출과 해석 지연 방지
enhanced-mode가짜 주소 또는 실제 주소 반환fake-ip
fake-ip-range가짜 주소 예약 대역198.18.0.1/16
default-nameserverDoH 서버 도메인 부트스트랩 해석223.5.5.5、1.1.1.1

nameserver와 fallback의 역할 분담: 메인 경로와 백업 경로

nameserver는 메인 해석 경로입니다. 들어오는 모든 도메인은 기본적으로 먼저 여기로 전달됩니다. fallback은 백업 해석 경로로, nameserver의 결과가 신뢰할 수 없다고 판정될 때만 두 번째 해석을 수행하고 fallback의 결과를 우선합니다.

판정 로직을 한 문장으로 요약하면, nameserver가 반환한 IP가 중국 본토에 속하면 도메인이 오염되지 않은 것이므로 그대로 사용하고, 해외 주소가 반환되면 오염 결과로 의심해 fallback로 다시 조회합니다. 따라서 두 목록의 구성은 명확하게 나뉩니다. nameserver에는 속도를 위해 중국 본토 DNS를, fallback에는 정확성을 위해 해외 신뢰 DNS를 넣습니다.

  nameserver:
    - 223.5.5.5
    - 119.29.29.29

  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  • nameserver는 일반 UDP 쿼리를 사용하는 중국 본토 DNS를 권장합니다. 지연이 수 밀리초 수준이고 중국 CDN 도메인에는 가까운 노드를 반환합니다.
  • fallback은 DoH를 권장합니다. 결과가 신뢰할 수 있고 오염에도 강합니다. 1.1.1.1과 8.8.8.8은 IP를 직접 쓰므로 추가 해석에 의존하지 않습니다.
  • 반대로 구성하지 마세요. nameserver에 해외 DNS를 넣고 fallback에 중국 본토 DNS를 넣으면 모든 쿼리가 느린 해외 해석을 거치고, 실제로 오류를 바로잡아야 할 때 fallback이 여전히 중국 본토 결과를 반환하므로 메커니즘이 무의미해집니다.
  • fallback 목록에도 중국 본토 DNS를 섞지 마세요. 그렇지 않으면 오염된 도메인이 여전히 잘못된 IP를 받게 됩니다.

fallback은 로드 밸런싱도, 동시에 여러 쿼리를 보내 가장 빠른 답을 고르는 것도 아닙니다. nameserver 결과가 의심스러울 때 한 번만 실행되며 평소에는 추가 트래픽이 발생하지 않습니다.

fallback-filter 필터링 로직: geoip, ipcidr, domain

fallback-filter는 언제 fallback을 실행할지 결정합니다. nameserver의 해석 결과만 확인하며 세 가지 조건으로 구성됩니다.

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      - 127.0.0.0/8
    domain:
      - '+.google.com'
      - '+.youtube.com'

geoip와 geoip-code가 메인 스위치입니다. geoip: true는 nameserver가 반환한 IP의 지리적 위치를 판정하고, geoip-code: CN은 중국 본토 IP를 신뢰 가능한 것으로 간주합니다. 이 조건에 해당하면 nameserver 결과를 그대로 사용합니다.

ipcidr는 신뢰할 IP 대역을 추가합니다. 내부 도메인에서 해석된 사설 주소는 국가 귀속이 없어 geoip가 해외 결과로 오판하고 fallback을 반복 실행할 수 있으므로 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8를 넣어야 합니다. 240.0.0.0/4는 원본 Clash 문서 예제에 있는 예약 대역이므로 남겨둬도 문제없습니다.

domain은 예외 목록입니다. 여기 적힌 도메인은 필터를 거치지 않고 바로 fallback으로 갑니다. 문법상 +.google.com은 메인 도메인과 모든 서브도메인을 뜻하고, *.google.com은 서브도메인만 뜻합니다. 자주 쓰는 해외 도메인을 넣으면 geoip 판정 한 번을 아낄 수 있습니다.

전체 판정 순서는 다음과 같습니다.

  1. 도메인이 domain 목록에 해당 → fallback 결과를 바로 사용합니다.
  2. nameserver가 반환한 IP가 geoip-code(CN)에 해당 → nameserver 결과를 사용합니다.
  3. 반환된 IP가 ipcidr에 해당 → nameserver 결과를 사용합니다.
  4. 위 조건을 모두 만족하지 않음(IP가 해외) → fallback으로 다시 해석하고 fallback 결과를 우선합니다.

이 판정 체계의 비용은 해외 도메인이 해석될 때마다 fallback 쿼리가 한 번 더 발생할 수 있다는 점입니다. DoH의 TLS 핸드셰이크는 첫 패킷 지연을 높입니다. 지연에 민감한 환경에서는 nameserver-policy로 특정 도메인에 해석기를 직접 지정해 전체 판정을 건너뛸 수 있습니다.

  nameserver-policy:
    '+.baidu.com': 223.5.5.5
    '+.taobao.com': 223.5.5.5
    '+.google.com': https://8.8.8.8/dns-query

TUN 모드의 DNS 하이재킹: Fake-IP와 함께 써야 하는 이유

TUN 모드는 모든 IP 트래픽을 가상 네트워크 카드로 수집하므로 DNS 쿼리도 가로채질 것처럼 보입니다. 하지만 시스템 리졸버는 쿼리를 임의의 DNS 서버(라우터 주소, 통신사 DNS, 앱 내장 DoH)로 보낼 수 있고, 이런 트래픽은 TUN에 들어오더라도 반드시 내장 DNS를 거치지는 않습니다.

dns-hijack은 바로 이 빈틈을 메웁니다. 가상 네트워크 카드에서 53 포트로 향하는 모든 UDP와 TCP 트래픽을 가로채 내장 DNS로 강제 리다이렉트합니다.

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

하이재킹은 DNS 쿼리가 커널로 들어오는 문제를 해결합니다. 이제 도메인 정보를 연결 단계까지 가져갈 수 있는지가 남은 문제이며, 이것이 enhanced-mode의 역할입니다.

fake-ip 모드에서는 내장 DNS가 쿼리에 198.18.0.0/16 예약 대역의 가짜 주소를 반환하고, 커널에 도메인과 가짜 주소의 매핑을 기록합니다. 앱이 가짜 주소로 연결을 시작하면 트래픽이 TUN에 들어온 뒤 커널이 매핑을 통해 원래 도메인을 복원해 규칙 영역에 전달합니다. DOMAIN-SUFFIX, DOMAIN-KEYWORD 같은 규칙이 계속 유효한 이유입니다.

redir-host 모드에서는 내장 DNS가 실제 주소를 반환합니다. 앱이 실제 IP로 직접 연결하므로 트래픽이 TUN에 들어올 때 IP 패킷만 남고 규칙 영역에서 매칭할 도메인이 없어 GEOIP, IP-CIDR로만 처리하게 됩니다. CDN 도메인이나 정밀한 분산이 필요한 환경에서는 규칙이 대부분 무력화됩니다. 이 모드는 시스템 프록시에서는 문제가 없습니다. 도메인이 HTTP CONNECT 요청에 포함되기 때문이며, 문제는 TUN 모드에서만 발생합니다.

결론: 하이재킹은 쿼리가 커널로 들어오는 것을 보장하고, fake-ip는 도메인 정보가 유실되지 않도록 보장합니다. 둘 중 하나라도 빠지면 규칙이 전부 직결되거나 전부 프록시로 가는 극단적인 현상이 나타나고, 로그만으로는 원인을 찾기 어렵습니다.

dns-hijack만 켜고 enhanced-mode를 redir-host로 유지하는 것은 TUN 모드에서 가장 알아채기 어려운 설정 오류입니다. 웹은 열리지만 모든 도메인 규칙이 매칭되지 않습니다.

fake-ip에는 fake-ip-filter라는 보조 필드도 있습니다. 실제 주소가 필요한 도메인은 제외해야 합니다. LAN 기기, .lan과 .local 접미사, 로컬 서비스 도메인을 여기에 넣지 않으면 가짜 주소를 받아 접근할 수 없게 됩니다.

바로 적용 가능한 완전한 설정

앞서 설명한 필드들을 하나의 사용 가능한 설정으로 합치면 값 선정 논리는 다음과 같습니다. nameserver는 중국 본토 일반 DNS로 속도를 확보하고, fallback은 해외 DoH로 오염 도메인을 교정하며, fake-ip는 TUN 모드에서 도메인 규칙이 계속 동작하게 하고, dns-hijack은 any:53으로 모든 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
    - 1.1.1.1
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      - 127.0.0.0/8
    domain:
      - '+.google.com'
      - '+.youtube.com'
      - '+.github.com'

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

적용한 뒤 다음 여섯 위치를 하나씩 확인하는 것이 DNS 문제를 진단하는 기본 절차입니다.

  • default-nameserver는 생략할 수 없습니다. DoH 서버 자체의 도메인을 해석하는 역할을 하며, 없으면 doh.pub 같은 도메인 형식의 DoH가 연결을 만들 수 없습니다. IP를 직접 쓰는 1.1.1.1은 영향을 받지 않지만 남겨두는 편이 안전합니다.
  • dns-hijack은 any:53으로 쓰고 8.8.8.8:53으로 쓰지 마세요. 후자는 해당 주소로 향하는 쿼리만 가로채므로 시스템 DNS가 바뀌면 바로 무효화됩니다.
  • fake-ip-filter에는 반드시 내부 도메인을 제외해야 합니다. 그렇지 않으면 LAN 기기 접근이 비정상적으로 동작합니다.
  • TUN 모드에서 redir-host를 사용하지 마세요. 도메인 규칙이 무력화되는 것은 인터넷은 되는데 분산이 전부 틀어지는 가장 흔한 원인입니다.
  • 53 포트가 점유된 경우 listen을 127.0.0.1:5353으로 바꾸고 시스템 DNS도 함께 변경하세요. 한쪽만 바꾸면 안 됩니다.
  • 설정을 바꾼 뒤에는 먼저 디버그 로그의 dns 출력을 확인하고, dig나 nslookup으로 내장 DNS를 조회해 가짜 주소가 반환되는지 실제 주소가 반환되는지 확인하세요.

DNS 설정에 만능 템플릿은 없고, 일관된 논리만 있습니다. nameserver는 속도, fallback은 정확성, fallback-filter는 전환 시점, fake-ip는 도메인 정보를 규칙 영역에 전달하는 역할을 담당합니다. 이 순서대로 확인하면 대부분의 해석 이상이 특정 필드로 좁혀집니다.

Clash Verge 다운로드