Clash DNS 설정 완전 가이드: Fake-IP, DNS 변조, 자체 DNS 구축
규칙을 아무리 정확하게 작성해도 도메인이 해석되는 IP 자체가 잘못됐다면 분기는 애초에 성립하지 않습니다. 이 글에서는 DNS 변조의 원리, Clash의 두 해석 모드 차이, 암호화 DNS와 도메인별 해석 전략까지 깊게 다뤄, "규칙은 분명 맞는데 여전히 잘못된 경로로 간다"는 문제를 근본 원인부터 진단할 수 있게 돕습니다.
분기 실패의 원흉이 왜 DNS인 경우가 많을까
많은 사람이 한참 규칙을 조정하다가 특정 사이트가 여전히 잘못된 경로로 가는 걸 발견하면 "규칙을 잘못 썼나 보다"라고 먼저 생각하지만, 진짜 원인은 그보다 한 단계 앞——DNS 해석에 있는 경우가 많습니다.
규칙 기반 분기는 "이 도메인/IP가 프록시를 타야 하는지"를 먼저 판단하는 것을 전제로 하며, 이 판단에는 두 가지 입력이 있습니다: 도메인 자체(DOMAIN, DOMAIN-SUFFIX 등의 규칙)와 해석된 IP(IP-CIDR, GEOIP 등의 규칙)입니다. DNS 해석 단계에서 문제가 생기면 이후의 모든 IP 기반 판단도 함께 틀어집니다:
- DNS 변조 / 하이재킹: 일부 네트워크는 특정 도메인에 대해 잘못되었거나 접근할 수 없는 IP를 반환합니다. 차단되거나 제한된 도메인에서 특히 자주 나타납니다.
- ISP DNS의 "가장 가까운" 결과 반환: CDN 가속을 위해 반환된 IP가 실제로 연결하려던 엔드포인트와 다를 수 있어
GEOIP기반 판단에 영향을 줄 수 있습니다. - 로컬 hosts / 캐시 오염: OS나 라우터 단계에 잘못된 결과가 캐시된 경우입니다. 클라이언트를 재시작해도 해결되지 않는 이유는 문제가 Clash에 있지 않기 때문입니다.
"규칙이 적용되지 않는" 문제를 진단할 때, DNS는 규칙 문법 자체 다음으로——맨 마지막이 아니라 가장 먼저 확인해야 할 항목입니다.
Fake-IP와 Redir-Host: 두 모드의 트레이드오프
Clash의 dns.enhanced-mode는 해석 동작의 근본적인 로직을 결정하며, 두 모드에는 각각 트레이드오프가 있습니다:
Fake-IP 모드
- 각 도메인에 로컬에서만 유효한 가상 IP를 할당하고, 실제 해석은 실제 연결이 발생할 때까지 지연시킴
- 규칙을 도메인명으로 직접 매칭할 수 있어 호환성이 가장 좋으며, TUN 모드에서 기본으로 권장됨
- 단점: "실제 IP를 받아 검증"하는 프로그램(일부 게임, 기업 VPN 클라이언트 등)은 호환되지 않을 수 있음
Redir-Host 모드
- 실제 해석 결과를 그대로 반환해 전통적인 네트워크 동작과 더 가까움
IP-CIDR/GEOIP규칙 판단이 더 정확해지며, 라우터/게이트웨이 환경에서 더 자주 사용됨- 단점: 어떤 프록시를 사용할지 결정하기 위해 실제 DNS 조회가 한 번 필요해, 왕복 지연이 하나 추가됨
절대적으로 "더 나은" 쪽은 없습니다. 일반적인 기준: 데스크톱 클라이언트 + TUN 모드에서는 fake-ip를 우선 사용하고, 특정 앱에서 연결 이상이 발견되면 모드 전체를 바꾸는 대신 fake-ip-filter에서 해당 도메인만 개별적으로 제외하세요.
암호화 DNS로 변조에 대응하기: DoH와 DoT
전통적인 DNS 조회는 평문 UDP 53번 포트 통신이라 중간 네트워크 장비가 식별하고 변조하기 쉽습니다. 이는 "DNS 변조"의 흔한 원인 중 하나입니다. 해결책은 DNS 조회를 암호화 채널로 감싸는 것입니다:
| 방식 | 정식 명칭 | 특징 |
|---|---|---|
DoH | DNS over HTTPS | 일반 HTTPS 트래픽으로 위장되어 식별하기 어려움. https://1.1.1.1/dns-query 형태로 작성 |
DoT | DNS over TLS | 전용 853 포트로 암호화되며 DoH보다 특징이 조금 더 드러남. tls://8.8.8.8 형태로 작성 |
| UDP(전통 방식) | DNS over UDP | 평문이라 가장 빠르지만 경로에 완전히 노출됨. 이미 신뢰하는 네트워크——예를 들어 본인 ISP 자체의 DNS——에 쓰는 정도라면 괜찮음 |
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 9.9.9.9
- 208.67.222.222
fallback:
- https://1.1.1.1/dns-query
- tls://8.8.8.8
fallback-filter:
geoip: true
geoip-code: KR고급 설정 가이드에서 소개한 것과 같은 원리입니다: 평소 해석 속도를 위해 nameserver에는 빠른 평문 DNS를 쓰고, 정확성을 위해 fallback에는 암호화 DNS를 쓰며, fallback-filter가 언제 fallback으로 전환할지 판단합니다. geoip-code는 본인의 국가/지역 코드로 설정하세요 — fallback-filter는 이를 이용해 해당 지역에 맞지 않는 결과를 탐지하고 암호화 DNS로 전환합니다.
도메인별로 해석 서버 분기하기: nameserver-policy
"기본 vs. 대체"라는 굵은 단위의 구분으로는 부족하고, 특정 도메인만 전용 DNS 서버로 보내고 싶을 때가 있습니다 — 예를 들어 사내 도메인은 반드시 사내 DNS로만 정확히 해석되는 경우입니다. 이럴 때 필요한 것이 nameserver-policy입니다:
dns:
nameserver-policy:
'geosite:private': '9.9.9.9'
'+.internal.company.com': '10.0.0.1'
'+.google.com': 'https://1.1.1.1/dns-query'nameserver-policy는 전역 nameserver / fallback보다 우선순위가 높습니다. 특정 도메인에 대한 "예외 규칙"이라고 이해하면 쉽고, 사내 네트워크나 자체 운영 서비스처럼 전용 해석이 필요한 상황에 매우 적합합니다.
사내 도메인이 Fake-IP에 잡혀 올바른 사내 DNS로 라우팅되지 않으면, 해당 사내 서비스는 "연결은 되는 것처럼 보이지만 계속 타임아웃되는" 상태가 됩니다. 이런 증상이 나타나면 먼저 nameserver-policy와 fake-ip-filter가 사내 도메인을 제대로 제외하고 있는지 확인하세요.
해석 결과가 올바른지 확인하는 방법
"왠지 느린 것 같다 / 연결이 안 되는 것 같다"는 느낌만으로는 문제가 DNS인지 아닌지 판단하기 어렵습니다. 더 확실한 방법은 실제로 해석된 주소를 직접 확인하는 것입니다:
- Dashboard 패널: 거의 모든 Clash 클라이언트의 패널에서 각 연결이 실제로 사용 중인 목적지 IP를 확인할 수 있습니다. 별도 도구 없이도 가장 직접적으로 확인 가능합니다.
- 커맨드라인 도구: Windows에서는
nslookup 도메인, macOS/Linux에서는dig 도메인또는nslookup 도메인을 사용해 Clash를 켜기 전과 후의 동일 도메인 해석 결과를 비교합니다. - Fake-IP 모드의 특이 현상: 이 모드에서는 OS 레벨의
nslookup이 가짜 IP(보통198.18.0.0/16범위)를 반환하는데, 이는 정상적인 동작이며 해석 오류가 아닙니다. 실제 해석은 연결이 발생하는 순간 코어가 수행합니다.
"DNS가 변조됐는지" 확인하는 가장 간단한 방법: 시스템 DNS나 Clash의 nameserver를 일시적으로 암호화 DNS(DoH 등)로 바꿔봅니다. 같은 도메인이 바꾼 후 정상적으로 접속된다면, 원래 DNS가 변조되거나 하이재킹됐을 가능성이 큽니다.
DNS 서버를 직접 구축해야 할까?
대부분의 경우, 공개된 암호화 DNS(1.1.1.1, 8.8.8.8 등)만으로 변조 문제를 충분히 해결할 수 있으며 직접 구축할 필요는 없습니다. 다만 여러 기기에 통일된 해석 서비스를 제공해야 하는 홈 게이트웨이나 라우터를 운영 중이라면, 자체 DNS(AdGuard Home, dnsmasq 등과 결합)가 더 적합합니다:
- 광고 필터링과 분기 해석을 게이트웨이 단계에서 통합 관리할 수 있어 기기마다 개별 설정할 필요가 없음
- 로컬 호스트명을 직접 정의할 수 있고(LAN 내 기기에 알기 쉬운 이름 지정 등), Clash의
nameserver-policy와 연결해 자체 DNS로 향하게 할 수 있음 - 요청 로그와 통계를 확보할 수 있어 어떤 기기, 어떤 도메인의 해석이 비정상인지 조사하기 쉬움
단일 기기에서 일상적으로만 사용한다면 Clash 내장 DNS 모듈에서 nameserver / fallback만 설정해도 충분합니다. 자체 DNS 구축은 게이트웨이 레벨 운영자를 위한 고급 옵션으로 생각하면 됩니다.
DNS 관련 문제 3단계 진단법
- Dashboard에서 문제가 있는 연결의 상세 정보를 열어 실제로 어떤 IP로 해석됐는지 확인합니다. "해석 자체가 잘못됐는지" 아니면 "해석은 맞는데 규칙이 매칭되지 않았는지"를 판단합니다.
enhanced-mode를fake-ip에서redir-host로(또는 반대로) 일시적으로 전환해 비교 테스트를 하며 문제 범위를 좁힙니다.fallback-filter.geoip가 활성화되어 있는지,geoip-code가 본인 지역으로 올바르게 설정되어 있는지 확인합니다. 이 부분이 가장 자주 놓치는 디테일입니다.
위 사항을 모두 확인해도 원인을 찾지 못했다면, FAQ의 연결 문제 진단 체크리스트를 참고하거나 고급 설정 가이드의 DNS 섹션과 대조하며 전체 설정을 다시 확인해보세요.