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

먼저 Clash DNS의 처리 경로부터 이해하기

Clash DNS 설정은 시스템 DNS를 다른 주소로 바꾸는 단순한 작업이 아닙니다. 내장 DNS를 활성화하면 클라이언트가 도메인 조회를 받아 nameserver, fallback, 규칙 및 향상 모드에 따라 해석 방식을 결정합니다. 연결을 설정할 때 Clash는 도메인, 해석 결과와 프록시 규칙도 연결해야 하므로 DNS 설정은 규칙 매칭, 첫 접속 속도와 일부 앱의 사용 가능 여부에 직접 영향을 줍니다.

일반적인 조회 한 번은 네 단계로 나눌 수 있습니다. 앱이 example.com을 조회하고, 시스템 또는 TUN이 53번 포트 요청을 Clash로 전달합니다. Clash는 설정된 업스트림 서버로 해석한 뒤, 연결 요청이 도메인 규칙, IP 규칙 또는 최종 규칙에 따라 직접 연결이나 프록시를 선택합니다. 어느 한 단계라도 Clash를 우회하면 도메인 규칙이 매칭되지 않거나, 해석 결과가 캐시되거나, 웹페이지는 열리지만 앱 연결은 실패할 수 있습니다.

필드	담당하는 작업	담당하지 않는 작업
`enable`	Clash 내장 DNS 모듈 활성화	시스템의 모든 DNS 트래픽을 자동으로 가로채지는 않음
`listen`	DNS 서비스의 수신 주소와 포트 지정	DNS 하이재킹을 단독으로 수행하지 않음
`nameserver`	주요 해석 결과 제공	프록시 정책 그룹을 자동으로 결정하지 않음
`fallback`	대체 해석 결과 제공	주 서버 시간 초과 후에만 조회하는 단순 백업이 아님
`dns-hijack`	TUN 계층에서 지정 대상의 DNS 요청 가로채기	업스트림 DNS 설정을 대신할 수 없음

enable, listen 및 기본 필드 작성법

enable: 내장 DNS 켜기

enable: true는 Clash의 DNS 모듈을 활성화합니다. false로 설정하면 나머지 dns 필드가 예상대로 해석에 사용되지 않습니다. 설정을 성공적으로 불러왔다고 해서 조회가 이미 이 모듈로 들어온다는 뜻은 아니므로, 시스템 프록시, TUN 또는 클라이언트의 네트워크 확장 기능까지 함께 확인해야 합니다.

listen: 로컬 DNS 수신 포트 제공

listen: 127.0.0.1:1053은 로컬 루프백 주소의 UDP/TCP 1053번 포트에서만 DNS 서비스를 제공한다는 뜻입니다. 1053은 일반적인 비특권 테스트 포트라 시스템이 사용하는 53번 포트와의 충돌도 피할 수 있습니다. 0.0.0.0:1053으로 설정하면 같은 로컬 네트워크의 기기가 이 포트에 접근할 수 있으므로, 모바일 기기에서는 보통 루프백 주소를 사용하거나 클라이언트의 자동 수신 설정을 우선합니다.

listen은 단지 ‘어디에서 조회를 기다릴지’를 정할 뿐, ‘조회 요청을 가로채는’ 설정은 아닙니다. TUN을 사용하는 데스크톱 환경에서는 보통 tun.dns-hijack도 설정해야 합니다. iOS에서는 DNS 가로채기가 대개 클라이언트의 Network Extension을 통해 이루어지며, 일부 클라이언트는 YAML의 tun 섹션을 무시하고 앱 자체의 스위치를 사용합니다.

출발점으로 사용할 수 있는 설정 예시

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

  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1

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

  fallback:
    - https://8.8.8.8/dns-query
    - tls://1.0.0.1:853

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

이 예시는 Clash Meta 또는 mihomo 문법을 지원하는 클라이언트에서 기본 템플릿으로 사용할 수 있습니다. 클라이언트마다 DoH, DoT, IPv6 또는 TUN 필드를 추가로 처리할 수 있으므로 가져온 뒤 설정 검증 결과를 먼저 확인하세요. 코어가 오래된 경우 geoip-code, DoT 주소와 향상 모드 필드를 인식하는지도 확인해야 합니다.

nameserver, default-nameserver, fallback의 차이

default-nameserver: 암호화 DNS 주소의 초기 해석

nameserver에 https://dns.alidns.com/dns-query처럼 도메인이 포함된 DoH 주소를 사용하면, Clash는 먼저 dns.alidns.com이 어떤 IP에 해당하는지 알아야 합니다. default-nameserver는 이런 초기 해석, 즉 bootstrap DNS를 담당합니다. 여기에는 직접 접속할 수 있는 IP 주소를 우선 입력해 ‘DoH 도메인을 먼저 해석해야 하는데 그 해석 자체가 DoH에 의존하는’ 순환을 피하세요.

모든 업스트림을 도메인으로 작성했는데 default-nameserver 자체에도 접근할 수 없다면, 로그에 DNS 요청 시간 초과, 시작 직후 인터넷 연결 불가 또는 업스트림 도메인 해석 실패가 반복되는 현상이 나타날 수 있습니다. 문제를 확인할 때는 현재 네트워크에서 접근 가능한 순수 IP DNS 하나를 남겨 두고 DoH 주소를 검증해 보세요.

nameserver: 일반 조회의 주요 업스트림

nameserver는 일반 조회에 사용하는 주요 업스트림입니다. 기존 UDP DNS, TCP DNS, DoT 또는 DoH를 입력할 수 있습니다. UDP 주소는 223.5.5.5, DoT는 tls://1.1.1.1:853, DoH는 https://1.1.1.1/dns-query처럼 작성합니다. 프로토콜을 섞으면 네트워크 제한을 확인하는 데 도움이 되지만 업스트림이 많다고 항상 좋은 것은 아닙니다. 경로가 명확하고 안정적인 서버 두 개가 주소를 예닐곱 개 쌓는 것보다 장애 원인을 찾기 쉽습니다.

fallback: 필터 조건에 따른 대체 결과 선택

fallback은 ‘nameserver가 시간 초과되면 사용하는 예비 DNS’로 이해하기 쉽지만, 실제 동작은 보통 여러 후보 결과를 병렬로 가져온 뒤 fallback-filter로 어느 결과 그룹을 채택할지 판단하는 방식에 가깝습니다. 코어 버전에 따라 동시 요청, 캐시와 결과 선택의 세부 동작이 다르므로 전통적인 주·보조 서버 전환으로 보면 안 됩니다.

예를 들어 geoip: true를 활성화하고 geoip-code: CN을 설정하면, 주요 해석 결과가 필터 조건에 맞지 않을 때 코어가 fallback 결과를 사용할 수 있습니다. domain에 명시한 도메인도 fallback 결과를 우선 사용할 수 있습니다. 규칙 데이터 버전, GeoIP 데이터와 업스트림이 반환하는 CDN 주소가 판단에 영향을 주므로, ‘IP가 현지에 없어 보인다’는 이유만으로 설정 오류라고 단정하지 마세요.

fallback-filter 조건별 작동 방식

geoip 및 geoip-code

geoip: true는 IP 지리 데이터를 기준으로 결과를 필터링하고, geoip-code: CN은 판단에 사용할 지역 코드를 지정합니다. 클라이언트에 포함되거나 다운로드된 GeoIP 데이터에 의존하며 실시간 조회 서비스가 아닙니다. 데이터 파일이 없거나 오래되었거나 경로 설정이 잘못되면 필터 결과가 예상과 달라질 수 있습니다.

ipcidr

ipcidr은 fallback 후보 결과를 사용해야 하는 주소를 CIDR 대역으로 지정합니다. 240.0.0.0/4는 예약 주소 대역을 포함해 명백히 비정상적인 해석 결과를 제외할 때 자주 사용됩니다. 넓은 공인 IP 대역을 함부로 추가하면 정상적인 웹사이트도 계속 fallback으로 처리될 수 있습니다.

domain

domain은 대상 도메인을 지정합니다. mihomo에서 자주 쓰는 +.example.com은 해당 도메인과 하위 도메인을 매칭할 수 있습니다. 소수의 웹사이트에만 별도 업스트림을 지정하려면 최신 mihomo 설정에서 nameserver-policy를 고려할 수도 있습니다. 특정 도메인을 지정 DNS에 직접 연결하므로 대규모 fallback 필터보다 로직이 명확한 경우가 많습니다.

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

  nameserver-policy:
    "+.example.net":
      - https://1.1.1.1/dns-query
    "geosite:cn":
      - https://dns.alidns.com/dns-query

nameserver-policy에서 규칙 집합 문법을 지원하는지는 사용하는 코어와 클라이언트 패키지 버전에 따라 다릅니다. mihomo v1.19 계열 설정을 사용할 때는 클라이언트에 표시된 코어 버전과 설정 검증 결과를 기준으로 판단하세요. 클라이언트가 구형 Clash 코어를 사용한다면 지원되지 않는 규칙 집합 문법을 그대로 복사하지 말고 일반 도메인 목록을 사용하세요.

fake-ip와 redir-host 중 무엇을 선택할까

fake-ip: 예약 주소를 먼저 반환하고 실제 도메인과 연결

enhanced-mode: fake-ip는 지정된 주소 풀에서 매핑 주소를 반환하며, 일반적으로 198.18.0.1/16 대역을 사용합니다. 앱이 이후 이 주소에 연결하면 Clash가 내부 매핑으로 원래 도메인을 복원하고 규칙을 적용합니다. 일부 환경에서 추가적인 해석 대기를 줄이고 도메인 규칙 정보를 유지하는 데 도움이 됩니다.

테스트 환경에서 dig @127.0.0.1 -p 1053 example.com A를 실행했을 때 198.18.x.x가 반환되면 보통 요청이 fake-ip 흐름으로 처리되고 있다는 뜻입니다. 이 값은 웹사이트의 실제 공인 IP가 아니므로 공용 DNS 조회 결과와 항목별로 비교하면 안 됩니다.

fake-ip-filter: 로컬 네트워크와 특수 도메인에는 실제 주소 반환

프린터, 라우터, 로컬 네트워크 검색과 실제 IP에 의존하는 일부 서비스는 fake-ip에 적합하지 않을 수 있습니다. fake-ip-filter로 로컬 도메인을 제외할 수 있지만, 실제 장애가 발생한 도메인부터 추가하고 출처가 불분명한 목록 수백 개를 그대로 복사하지는 마세요.

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "router.asus.com"
    - "time.apple.com"

*.local은 mDNS 및 로컬 네트워크 검색과 관련된 경우가 많습니다. iOS에서 AirPlay, AirPrint 또는 홈 기기 검색에 문제가 생기면 해당 도메인이 fake-ip으로 가로채지고 있는지 먼저 확인하고, 클라이언트의 로컬 네트워크 접근도 허용되어 있는지 살펴보세요. iOS 26에서는 「설정」→「개인정보 보호 및 보안」→「로컬 네트워크」에서 관련 권한을 확인할 수 있습니다.

redir-host: 실제 해석 결과를 그대로 반환

redir-host는 일반적으로 앱에 실제 IP를 반환하므로 호환 경로가 직관적이지만, 도메인과 연결을 연계하는 방식은 트래픽 가로채기 방식에 따라 달라집니다. 은행 앱, 로컬 네트워크 기기 또는 특수 프로토콜이 fake-ip과 호환되지 않을 때 redir-host로 임시 전환해 비교해 보세요. 전환 직후 문제가 해결된다면 노드, 규칙과 DNS를 한꺼번에 바꾸기보다 먼저 fake-ip-filter를 보완하는 것이 좋습니다.

DNS 하이재킹과 TUN 모드 설정법

여기서 DNS 하이재킹은 클라이언트가 다른 DNS 주소로 향하는 53번 포트 요청을 Clash 내장 DNS로 전달하는 것을 뜻합니다. 앱이 시스템 DNS를 우회해 고정 DNS 서버에 직접 접근하는 문제를 해결합니다. listen만 설정한다고 이 패킷의 목적지가 바뀌지는 않습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53은 일반적인 DNS 요청을 가로채는 데 사용하고, tcp://any:53은 TCP DNS까지 대상으로 삼습니다. DoH는 HTTPS의 443번 포트, DoT는 보통 853번 포트를 사용하므로 일반적인 53번 포트 하이재킹만으로는 완전히 식별할 수 없습니다. 앱에 DoH가 내장되어 있다면 도메인 규칙, 연결 정책 또는 앱 자체 설정으로 처리해야 합니다.

iPhone과 iPad에서 클라이언트는 보통 iOS Network Extension으로 VPN 구성을 만듭니다. YAML의 tun 필드가 실제로 적용되는지는 클라이언트 구현에 달려 있습니다. 시스템 상태와 앱 상태가 일치하지 않으면 「설정」→「일반」→「VPN 및 기기 관리」→「VPN」에서 현재 연결을 확인한 뒤, 클라이언트 로그에 DNS timeout, no such host 또는 업스트림 연결 실패가 표시되는지 확인하세요.

설정 후 검증 절차

먼저 문법을 검사합니다. YAML은 공백으로 들여쓰기해야 하며 Tab을 섞으면 안 됩니다. dns와 tun은 올바른 계층에 있어야 하고 목록 항목 앞의 하이픈도 유지해야 합니다.
수신 상태를 확인합니다. 데스크톱에서는 코어가 1053번 포트를 수신 중인지 확인할 수 있습니다. 다른 프로그램이 이미 포트를 사용 중이라면 1054로 바꾸고 테스트 명령도 함께 수정하세요.
캐시되지 않은 도메인을 조회합니다. 명령줄을 사용할 수 있는 기기에서 dig @127.0.0.1 -p 1053 example.com A를 실행하세요. fake-ip 모드에서는 198.18.0.0/16 대역의 주소가, redir-host 모드에서는 공인 주소가 표시되어야 합니다.
첫 조회와 재조회 결과를 비교합니다. 같은 테스트 환경에서 첫 조회가 1800밀리초, 재조회가 20밀리초라면 보통 캐시는 정상이나 업스트림 연결 수립이 느리다는 뜻입니다. 매번 2000밀리초를 넘기며 시간 초과가 발생한다면 DoH 경로와 default-nameserver를 확인하세요.
규칙 매칭을 확인합니다. 도메인 규칙이 명확한 웹사이트를 열고 클라이언트 연결 기록에서 의도한 도메인 규칙이 적용되었는지 확인하세요. 실수로 IP-CIDR이나 MATCH로 처리되어서는 안 됩니다.
기존 캐시를 지운 뒤 다시 테스트합니다. 향상 모드를 변경한 뒤에는 코어를 재시작하거나 클라이언트의 DNS 캐시 새로고침 기능을 사용해야 합니다. 웹페이지만 새로고침하면 앱, 시스템 또는 브라우저에 저장된 이전 결과가 계속 사용될 수 있습니다.

증상	우선 확인할 항목	조치
모든 도메인에서 시간 초과	enable, 업스트림 접근성, default-nameserver	순수 IP UDP DNS 하나로 임시 변경해 기본 경로 확인
IP는 접속되지만 도메인은 접속되지 않음	DNS 가로채기와 수신 포트	TUN, Network Extension 및 dns-hijack 확인
로컬 네트워크 기기만 작동하지 않음	fake-ip-filter, 로컬 네트워크 권한	.local, .lan 및 기기의 실제 도메인 제외
일부 웹사이트가 다른 지역으로 비정상 해석됨	fallback-filter, GeoIP 데이터	데이터 파일을 업데이트하고 domain, ipcidr 범위 축소
구독 업데이트 후 설정이 사라짐	설정 저장 위치	DNS 섹션을 오버라이드 또는 병합 설정으로 이동

흔한 오해와 권장 조정 순서

업스트림을 많이 추가하면 더 안정적이라고 생각하기

업스트림 서버가 많아질수록 경로 차이, 병렬 결과와 로그 노이즈도 늘어납니다. 문제를 확인하는 단계에서는 UDP DNS 하나와 DoH 하나만 사용해 각각 접근 가능한지 확인한 뒤 유지 여부를 결정하세요. 모바일 네트워크, 회사 Wi-Fi와 가정용 인터넷은 53, 853, 443번 포트에 서로 다른 제한을 적용할 수 있으므로 안정성은 현재 네트워크에서 직접 측정해야 합니다.

fallback, policy와 다수의 필터를 동시에 활성화하기

fallback-filter, nameserver-policy와 프록시 규칙은 하나의 접속에 함께 영향을 줄 수 있습니다. 조건을 한꺼번에 많이 추가하면 최종 결정을 내린 설정이 무엇인지 파악하기 어렵습니다. 권장 순서는 nameserver를 먼저 정상 작동시킨 다음 fake-ip 또는 redir-host를 선택하고, 소수의 policy를 추가한 뒤 마지막으로 fallback 필터를 도입하는 것입니다.

DNS 문제를 노드 문제로 오인하기

DNS 조회는 노드 연결보다 먼저 또는 동시에 발생합니다. 프록시 노드를 바꾼 뒤 일시적으로 복구되었다면 캐시가 갱신되었거나 업스트림 연결이 새로 수립된 것일 수 있습니다. 로그를 확인할 때 해석 단계에서 context deadline exceeded 또는 no such host가 나타나면 DNS를 먼저 처리하세요. 대상 IP까지 확인됐는데 프록시 핸드셰이크가 시간 초과될 때 노드와 회선을 점검하면 됩니다.

IPv6 설정의 앞뒤 불일치 무시하기

ipv6: false는 보통 DNS 모듈이 AAAA 결과를 반환하지 않도록 한다는 뜻이지만, 시스템, TUN과 프록시 노드는 각자 IPv6 설정을 가질 수 있습니다. IPv6 경로가 불안정한 네트워크라면 먼저 DNS IPv6을 끄고 비교해 보세요. IPv6 전용 서비스에 반드시 접속해야 한다면 로컬 네트워크, 노드와 규칙이 모두 IPv6을 지원하는지 확인해야 하며, 이 필드만 true로 바꿔서는 충분하지 않습니다.

안정적인 설정의 핵심은 경로를 명확히 하는 것입니다. default-nameserver로 초기 해석을 수행하고, 소수의 nameserver로 주요 조회를 처리한 뒤, 지역별 필터링이 필요할 때만 fallback을 추가하세요. fake-ip 또는 redir-host로 도메인과 연결의 관계를 유지하고, 마지막으로 TUN 또는 iOS 네트워크 확장이 실제 트래픽을 가로채도록 합니다. 이 순서로 조정하면 DNS 시간 초과, 규칙 미매칭과 로컬 네트워크 오류를 대체로 계층별로 분리해 원인을 찾을 수 있습니다.