Clash DNS 설정 완벽 가이드: nameserver·fallback 그룹·fake-ip DNS 가로채기

먼저 핵심부터: DNS 업스트림, 응답 주소, 트래픽 가로채기를 따로 점검하세요

Clash DNS 설정에서 헷갈리기 쉬운 부분은 크게 세 가지입니다. 도메인을 어느 DNS 서버에서 조회할지, 앱에 어떤 주소를 돌려줄지, 앱의 DNS 요청이 커널로 들어오는지입니다. nameserver와 fallback은 첫 번째를, enhanced-mode는 두 번째를 처리합니다. 세 번째는 시스템 DNS 설정, 수신 포트, TUN의 dns-hijack 여부에 달려 있습니다. 모드만 fake-ip로 바꾼다고 기기 전체의 DNS가 자동으로 가로채지는 않습니다.

아래 기본 설정은 mihomo를 기준으로 합니다. Clash는 클라이언트 생태계에서 널리 쓰이는 명칭이지만, 그래픽 인터페이스가 비슷하다고 해서 내부 설정 항목까지 모두 같은 것은 아닙니다. 원본 Clash와 과거의 여러 분기 버전, 현재 mihomo는 TUN 및 DNS 확장 항목 지원 여부가 다를 수 있습니다. 클라이언트 정보 화면이나 시작 로그에서 실제 구현을 먼저 확인하세요. 명령줄로 배포했다면 mihomo -v를 실행해 현재 환경을 확인하고, 화면에 표시된 버전만으로 커널 기능을 짐작하지 마세요.

• 구독 가져오기 성공: 설정 파일을 읽을 수 있다는 뜻일 뿐, 시스템이 해당 DNS를 사용한다는 의미는 아닙니다.
• 노드 지연 시간 테스트 성공: 테스트 대상에만 해당합니다. 모든 도메인이 올바르게 조회된다는 뜻은 아닙니다.
• 198.18 대역 주소가 반환됨: fake-ip 모드에서는 정상적인 결과일 수 있으므로, 곧바로 DNS 오염으로 판단하지 마세요.

nameserver와 default-nameserver: 서비스 도메인 조회와 업스트림 주소 조회

dns.nameserver는 일반 도메인 조회에 사용하는 업스트림 목록입니다. 일반 DNS의 IP 주소뿐 아니라 커널이 지원하는 DoH·DoT 주소도 지정할 수 있습니다. 목록은 ‘첫 번째 서버를 항상 우선 사용하고, 두 번째 서버는 연결이 끊겼을 때만 사용’하는 고정 순서가 아닙니다. 커널은 자체 조회 및 응답 선택 방식에 따라 여러 업스트림을 처리하므로, 작성 순서를 엄격한 주·대기 구성으로 간주하지 마세요.

DoH를 설정했는데 일반 DNS도 사용되는 이유는 무엇인가요?

예를 들어 https://dns.alidns.com/dns-query는 DoH 서비스 주소입니다. 하지만 HTTPS 연결을 만들려면 먼저 dns.alidns.com의 IP 주소를 알아야 합니다. default-nameserver는 이런 DNS 서비스 도메인의 초기 조회를 담당합니다. 아래 예시에서는 의존 관계를 분명히 보여주기 위해 223.5.5.5와 119.29.29.29를 사용합니다. 모든 네트워크에 적합한 주소라는 뜻은 아닙니다.

DoH 암호화는 클라이언트와 해당 DNS 서버 사이의 통신에만 적용되며, 요청이 프록시 노드를 거친다는 뜻은 아닙니다. 업스트림 연결 가능 여부, DNS 연결의 아웃바운드 경로, 서비스 연결에 적용되는 규칙을 각각 확인해야 합니다. mihomo는 프록시 서버 도메인 조회를 별도로 처리하는 proxy-server-nameserver 등의 확장 항목도 제공합니다. 의존 관계를 파악하지 않은 채 프록시 노드의 도메인 조회가 다시 해당 노드에 의존하게 설정하지 마세요.

fallback과 fallback-filter: 결과 후보를 거르는 설정이지, 규칙용 프록시 그룹이 아닙니다

fallback은 흔히 ‘보조 DNS’라고 부르지만, nameserver가 완전히 시간 초과될 때까지 기다리는 예비 목록만은 아닙니다. fallback을 설정하면 커널이 일반 그룹과 fallback 그룹에 동시에 조회를 보내고, 필터 조건에 따라 결과를 선택할 수 있습니다. 여기서 말하는 ‘그룹’은 DNS 업스트림 묶음입니다. proxy-groups의 노드 선택이나 자동 지연 시간 측정 그룹과는 다른 계층입니다.

geoip, ipcidr, domain은 각각 무엇을 판단하나요?

• geoip: true와 geoip-code: CN을 함께 설정하면 일반 그룹이 반환한 주소의 지역을 판별합니다. 지정한 지역에 해당하지 않는 결과는 fallback 결과를 사용하도록 처리될 수 있습니다. 이 기능을 사용하려면 커널에서 지리 정보 데이터를 이용할 수 있어야 합니다.
• ipcidr: 240.0.0.0/4처럼 특정 주소 대역을 필터링할 결과로 지정합니다. DNS 조회 결과를 확인하는 설정이지, 서비스 연결에 프록시 규칙을 추가하는 설정은 아닙니다.
• domain: 일치하는 도메인에 fallback 결과를 사용하도록 합니다. 도메인 자체를 기준으로 지정하므로, 일반 그룹이 비정상 IP를 반환할 때까지 기다릴 필요가 없습니다.

이 조건들은 모두 충족해야 작동하는 연쇄 검사 방식이 아닙니다. ‘도메인이 목록에 있고, 주소가 CN에 속하지 않으며, 예약 대역에도 해당해야만 작동한다’고 이해하지 마세요. 놓치기 쉬운 제한도 있습니다. 잘못 반환된 주소가 지리 정보상 CN으로 분류되면 geoip만으로는 이상을 감지하지 못할 수 있습니다. fallback은 결과 선택 방식이지, 올바른 DNS 조회를 보장하는 기능이 아닙니다.

특정 도메인 유형을 어느 DNS 서버로 조회할지 명확히 지정하려면 mihomo의 nameserver-policy가 더 직관적인 경우가 많습니다. 이 설정은 DNS 업스트림을 정하고, rules는 서비스 연결의 아웃바운드를 정합니다. 서로 대체해서 사용하면 안 됩니다. 도메인을 해외 DNS에서 조회하더라도 서비스 연결에 프록시 정책이 자동 적용되지는 않습니다.

fake-ip와 redir-host: 가상 주소와 실제 주소 중 무엇을 반환할까요?

fake-ip: 주소 매핑으로 도메인 정보를 유지합니다

enhanced-mode: fake-ip는 조건에 맞는 조회에 가상 주소를 반환하고, 커널에 도메인과 가상 주소의 매핑을 저장합니다. 앱이 이 주소로 연결하면 같은 커널을 거쳐야 커널이 매핑을 통해 실제 대상을 찾아낼 수 있습니다. 예시의 198.18.0.1/16은 성능 테스트에 쓰이는 예약 주소 공간입니다. 원격 웹사이트의 실제 서버 주소가 아닙니다.

이 방식은 연결 단계에서도 도메인 정보를 유지하는 데 도움이 되며, 실제 대상 주소를 조회하느라 연결이 지연되는 경우를 줄일 수 있습니다. 그렇다고 ‘모든 도메인에 실제 DNS가 더는 필요 없다’는 뜻은 아닙니다. 직접 연결할 대상이나 IP 기반 규칙을 판별할 때, 또는 특정 커널의 처리 경로에 따라 실제 DNS 조회가 필요할 수 있습니다. fake-ip를 업스트림 DNS가 전혀 필요 없는 방식으로 생각하면 원인을 찾기 어려운 연결 오류가 생길 수 있습니다.

redir-host: 실제 주소를 반환하며 도메인 연결 정보를 확인해야 합니다

redir-host는 업스트림이 제공한 실제 IP를 반환하고, 커널은 DNS 캐시 등의 정보를 활용해 도메인과 연결합니다. 실제 주소를 확인해야 하는 프로그램과 호환되기 쉽지만, 비정상 DNS 결과를 막거나 모든 연결에서 도메인 정보가 완전히 유지되도록 보장하지는 않습니다. 앱이 직접 조회하거나 캐시가 만료되거나 연결이 커널을 우회하면 규칙 매칭 결과가 달라질 수 있습니다.

• 데스크톱에서 TUN을 일상적으로 사용하는 경우: 먼저 fake-ip를 테스트해 DNS 조회와 후속 연결이 같은 커널에서 처리되는지 확인하세요.
• LAN 기기, 프린터 또는 내부 서비스에 문제가 생긴 경우: 모드를 바꾸기 전에 LAN DNS와 필터 목록부터 확인하세요.
• 특정 프로그램에 실제 IP가 필요한 경우: 모든 앱을 redir-host로 바꾸기보다 해당 도메인을 fake-ip-filter에 추가할 수 있습니다.

fake-ip-filter는 ‘이 도메인에는 fake-ip를 반환하지 않는다’는 뜻이지, ‘이 도메인은 프록시를 거치지 않는다’는 뜻이 아닙니다. 아래 설정 예시는 localhost, *.lan, *.local을 제외합니다. 하지만 제외 설정만으로 공용 DNS가 공유기의 사설 도메인을 조회할 수 있게 되지는 않습니다. 내부 도메인을 조회하려면 사용할 수 있는 LAN DNS 서버가 필요합니다. .local은 mDNS와 관련되는 경우가 많아 일반 DNS 업스트림만 바꿔서는 해결되지 않을 수 있습니다.

바로 적용할 DNS 설정 예시: 먼저 127.0.0.1:1053에서 확인

아래 설정은 전체 설정 파일 중 dns: 부분만 대체합니다. 노드, 프록시 그룹, 서비스 규칙은 포함하지 않습니다. 현재 구독의 나머지 설정은 유지하세요. 이미 dns:가 있다면 병합하거나 교체해 최상위 키가 중복되지 않도록 합니다. 그래픽 클라이언트가 시작할 때 구독 설정을 덮어쓸 수 있으므로, 지속적으로 적용되는 오버라이드 기능을 사용하고 최종 적용된 설정을 확인하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 0.0.0.0/8

먼저 로컬 기기에서만 테스트할 수 있도록 루프백 주소로 수신하게 설정했습니다. 0.0.0.0:53으로 수신하거나 LAN에 DNS 서비스를 공개하지 않습니다. ipv6: false는 이번 DNS 점검 범위를 좁히기 위한 설정입니다. 운영체제의 IPv6를 끄는 것도 아니며, 모든 IPv6 연결이 차단된다는 뜻도 아닙니다.

먼저 문법을 확인한 뒤 수신 상태를 점검하세요

명령줄 환경에서는 설정 파일이 있는 디렉터리에서 다음 검사를 실행할 수 있습니다. 그래픽 클라이언트가 설정 경로를 관리한다면 이 명령으로 클라이언트 실행 인자를 직접 바꾸지 마세요. 클라이언트에서 제공하는 설정 검사 기능을 사용하고, 로그에서 DNS 서비스가 정상적으로 시작되었는지 확인하세요.

mihomo -t -f config.yaml

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +tcp

example.com은 조회 경로 테스트에 사용할 수 있는 공개 예시 도메인입니다. fake-ip를 지원하는 환경에서 조회 결과로 198.18.x.x가 반환되는 것은 정상일 수 있습니다. UDP와 TCP가 모두 시간 초과되면 수신 상태, 포트 충돌, 커널 로그를 먼저 확인하세요. Windows에 dig가 설치되어 있지 않다면 대화형 nslookup에서 서버와 포트를 지정할 수 있습니다:

nslookup
server 127.0.0.1
set port=1053
set type=A
example.com
exit

TUN DNS 가로채기 조건: 포트 53 요청이 커널을 거쳐야 합니다

운영체제의 일반 DNS 조회는 보통 UDP 또는 TCP 53 포트를 사용합니다. 앞에서 설정한 1053은 테스트용 수신 포트이며, 시스템이 포트 53의 요청을 자동으로 전달하지는 않습니다. 대부분의 시스템 DNS 설정 화면에서는 사용자 지정 포트도 지정할 수 없습니다. 일반 DNS를 가로채려면 클라이언트의 TUN DNS 가로채기 기능을 사용하거나 명시적인 로컬 포워딩을 설정해야 합니다. 시스템 DNS를 127.0.0.1로 지정하는 것만으로 1053 포트에 연결된다고 생각하지 마세요.

아래 항목을 지원하는 mihomo 환경이라면 기존 tun: 설정에 이 부분을 병합할 수 있습니다. 활성화하기 전에 클라이언트나 운영체제의 안내에 따라 가상 네트워크 인터페이스 생성 및 라우팅 변경 권한을 부여하세요. 클라이언트가 이미 TUN을 관리한다면 클라이언트의 설정 메뉴를 우선 사용해 화면 설정과 직접 작성한 설정이 서로 덮어쓰지 않도록 하세요.

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53은 UDP DNS를 대상으로 하고, tcp://any:53은 TCP DNS를 대상으로 합니다. 여기서 가로채기란 TUN 처리 경로로 들어온 DNS 요청을 커널의 DNS 모듈에 전달하는 것입니다. 모든 요청을 로컬 1053 포트로 단순히 바꿔 보내는 방식은 아닙니다. 요청이 이 경로에 들어오는지는 시스템 라우팅, 다른 VPN, 인터페이스 선택, 플랫폼 제한에 따라서도 달라집니다.

dns-hijack을 설정해도 다음 트래픽까지 모두 가로채지는 않습니다

• 브라우저 자체 DoH: 보통 HTTPS 트래픽으로 처리되므로 포트 53 규칙만으로 일반 DNS 요청처럼 식별할 수 없습니다.
• 시스템이나 앱의 DoT: 보통 포트 853을 사용하므로 포트 53을 대상으로 한 두 규칙에는 해당하지 않습니다.
• TUN을 거치지 않는 트래픽: 다른 VPN이 처리하거나 별도 라우팅을 사용하거나 플랫폼 구현의 제한을 받는 요청 등이 해당합니다.
• 캐시에 저장된 결과: 앱은 새로 조회하지 않고 이전 주소나 기존 연결을 계속 사용할 수 있습니다.

시스템 프록시와 TUN도 같은 것으로 보면 안 됩니다. 브라우저가 HTTP 프록시에 도메인을 전달하면 프록시 쪽에서 대상 도메인을 조회할 수 있습니다. 반면 시스템 프록시를 따르지 않는 앱은 시스템 DNS를 직접 사용할 수 있습니다. 문제를 확인할 때는 브라우저 자체의 보안 DNS를 잠시 끄고 통제된 기본 상태에서 테스트한 뒤, 확인을 마치면 필요한 설정을 다시 켜세요.

문제별 확인 방법: 증상에 맞춰 점검하고 여러 설정을 동시에 바꾸지 마세요

모드를 바꿀 때 DNS 캐시도 함께 정리하세요

fake-ip에서 redir-host로 전환하거나 TUN을 끈 뒤에도 앱에 가상 주소가 남아 있을 수 있습니다. Windows에서는 ipconfig /flushdns를 실행할 수 있고, systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행할 수 있습니다. 두 명령은 각각 해당 환경에서만 사용할 수 있으며, 모든 운영체제에서 통하는 명령은 아닙니다. 브라우저의 DNS 캐시와 연결 풀도 별도로 정리해야 합니다. 필요하면 앱을 완전히 종료한 뒤 다시 실행하세요.

테스트할 고정 도메인 하나를 정해 먼저 조회한 다음 해당 페이지에 접속하세요. 동시에 연결 패널에서 대상 도메인, 일치한 규칙, 아웃바운드 정책을 확인합니다. 공용 IP 조회 페이지만으로 DNS를 판단하지 마세요. 외부에 표시된 IP는 해당 웹 연결이 어느 출구를 사용했는지만 보여줄 뿐, DNS 조회가 어느 서버를 거쳤는지는 정확히 알려주지 않습니다.

구독 가져오기와 기본 연결 과정을 다시 확인하려면 입문 가이드의 구독 안내를 참고하세요. DNS와 규칙의 관계는 사용 설명서의 DNS 항목에서 확인할 수 있습니다. 기본 원칙은 같습니다. 먼저 요청이 커널에 들어오는지 확인하고, 다음으로 업스트림과 필터 조건을 점검한 뒤, 마지막으로 호환성 목록을 조정하세요.