이 글은 Clash 공식 사이트에서 제공합니다. Clash와 Mihomo의 규칙 기반 라우팅 체계에서 DNS는 가장 간과하기 쉬우면서도 「일부 사이트가 열리지 않음」, 「해석 속도 저하」, 「규칙 미적용」 등의 문제를 가장 많이 일으키는 구성 요소입니다. 노드와 정책 그룹을 아무리 정교하게 설정해도, DNS가 잘못된 IP를 반환하거나 잘못된 해석 경로를 타면 분류 규칙이 제대로 적용되지 않습니다. 이 글에서는 원리부터 실전까지 Clash DNS 모듈의 설정 방법을 체계적으로 설명하여, 안정적이고 빠르며 스푸핑에 강한 해석 체인을 구축할 수 있도록 돕겠습니다.
Clash에 독립적인 DNS 설정이 필요한 이유
운영체제의 기본 DNS는 보통 라우터나 ISP가 제공하는데, 해석 결과가 하이재킹되거나 캐시 오염 또는 크로스보더 해석 지연의 영향을 받을 수 있습니다. 로컬 프록시 코어인 Clash는 트래픽이 규칙 매칭 단계에 진입하기 전에 대상 도메인에 대응하는 실제 또는 가상 주소를 이미 알고 있어야만 DOMAIN, GEOSITE 등의 규칙을 올바르게 실행할 수 있습니다.
DNS와 프록시 체인이 연동되지 않으면 로컬 사이트가 불필요하게 프록시를 타거나, 해외 사이트의 직접 연결이 실패하거나, TLS 핸드셰이크 오류 또는 브라우저가 「확인 중...」에서 멈추는 현상이 자주 발생합니다. 따라서 고급 설정에서 DNS 모듈을 별도로 계획하는 것은 전체 사용 경험을 보장하는 핵심 단계입니다.
DNS 모듈은 분류 규칙의 「상류 정보 시스템」이라고 생각하면 됩니다. 정보가 잘못되면 아무리 좋은 정책 그룹도 소용없습니다.
fake-ip와 redir-host: 두 가지 핵심 모드
Mihomo / Clash Meta 계열 코어는 두 가지 고급 DNS 모드를 지원하며, 차이를 이해하는 것이 올바른 설정의 전제입니다.
fake-ip 모드
각 도메인에 가상 IP(보통 198.18.0.0/15 대역)를 할당합니다. 애플리케이션이 해당 IP로 연결을 시도하면 코어가 도메인 정보를 기반으로 실제 대상을 복원하여 규칙을 매칭합니다. DNS 누출 방지, 해석 대기 시간 단축, TUN 모드 호환성 향상이 장점입니다. 단점으로는 실제 IP에 의존하는 일부 애플리케이션(LAN 기기 검색, 특정 게임 등)에서 문제가 발생할 수 있습니다.
redir-host 모드
DNS 쿼리가 실제 IP를 반환하며, 코어는 해당 IP를 기반으로 GEOIP 등의 규칙 매칭을 계속 진행합니다. 전통적인 프록시 방식에 더 가깝고 호환성이 높지만, 상위 DNS가 스푸핑되어 있으면 잘못된 IP를 받아 규칙 매칭이 예상에서 벗어날 수 있습니다. 일반적으로 신뢰할 수 있는 원격 DNS와 dns-hijack을 함께 사용해야 안정적으로 작동합니다.
| 비교 항목 | fake-ip | redir-host |
|---|---|---|
| 반환 주소 | 가상 IP | 실제 IP |
| DNS 누출 방지 | 강함 | 추가 설정 필요 |
| TUN 호환성 | 우수 | 양호 |
| 특수 앱 호환성 | 간혹 문제 | 대체로 양호 |
DNS 분류 라우팅: 로컬/원격 도메인을 다른 채널로 처리
효율적인 설정에서는 로컬 도메인과 해외 도메인을 서로 다른 DNS 서버로 처리합니다. 로컬 도메인은 ISP 또는 공용 DNS(예: 223.5.5.5; Cloudflare의 1.1.1.1이나 Google의 8.8.8.8도 사용 가능)를 이용해 빠르고 정확한 해석을 얻고, 해외 도메인은 프록시 터널을 통해 원격 DNS(예: tls://8.8.8.8 또는 구독 서비스 제공자가 제공하는 DNS)로 쿼리하여 DNS 스푸핑을 피하고 더 합리적인 라우팅을 확보합니다.
설정 파일에서는 nameserver-policy를 통해 특정 도메인이나 도메인 접미사에 해석 서버를 지정할 수 있습니다. 예를 들어 geosite:cn은 로컬 DNS로, geosite:geolocation-!cn은 프록시 DNS로 지정합니다. fallback과 fallback-filter를 함께 사용하면, 기본 DNS가 의심스러운 IP를 반환할 때 자동으로 백업 해석으로 전환되는 실전에서 가장 많이 쓰이는 스푸핑 방지 조합이 완성됩니다.
권장 설정 방향
enhanced-mode: fake-ip를 활성화합니다(TUN 사용자 우선). 시나리오에 따라 redir-host를 선택할 수도 있습니다.nameserver에는 신뢰할 수 있는 로컬 DNS를,fallback에는 프록시를 경유하는 원격 DNS를 입력합니다.nameserver-policy로 분류 라우팅을 세분화하여 모든 쿼리가 해외 DNS를 거쳐 로컬 접속이 느려지는 현상을 방지합니다.fake-ip-filter에 LAN 도메인, NTP, 일부 로컬 서비스 도메인을 추가하여 가상 IP가 로컬 서비스를 방해하지 않도록 합니다.
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://223.5.5.5/dns-query
fallback:
- tls://8.8.8.8:853
nameserver-policy:
"geosite:cn": [https://223.5.5.5/dns-query]
"geosite:geolocation-!cn": [tls://8.8.8.8:853]자주 묻는 질문과 문제 해결
프록시 활성화 후 로컬 사이트가 느려짐: 모든 DNS 쿼리가 fallback을 타고 있는지 확인하세요. nameserver-policy를 통해 로컬 도메인이 로컬 DNS를 사용하도록 설정해야 합니다.
일부 앱이 연결되지 않음: 해당 도메인을 fake-ip-filter에 추가하거나 redir-host 모드로 전환하여 테스트해 보세요.
DOMAIN 규칙을 작성했는데 적용되지 않음: DNS 모듈이 활성화되어 있는지, 해석 단계에서 잘못된 IP로 인한 간섭이 없는지 확인하세요. 로그에서 실제로 매칭된 대상 주소를 확인하세요.
해석 타임아웃: 원격 DNS가 프록시를 통해 나가야 하는지 확인하고, DNS 쿼리 트래픽이 프록시 노드에 도달할 수 있는지 확인하세요. https 또는 tls 유형의 DNS로 변경하면 안정성이 향상됩니다.
정리
Clash DNS 설정은 한 번 복사해두면 끝나는 템플릿이 아니라, 클라이언트 모드(시스템 프록시 / TUN), 구독 서비스 회선 품질, 자주 사용하는 애플리케이션 환경에 맞춰 미세 조정해야 합니다. fake-ip는 효율성과 누출 방지를 중시하는 사용자에게, redir-host는 최대 호환성이 필요한 환경에 적합합니다. 어떤 모드를 선택하든 로컬/원격 분류 DNS 해석 + 신뢰할 수 있는 fallback은 안정적인 분류 라우팅 체계를 구축하는 기본입니다.
클라이언트와 코어 프로그램은 공식 다운로드 페이지에서 다운로드할 수 있으며, 처음 설정하는 분은 설정 가이드를 참고하여 구독 가져오기와 규칙 모드 설정을 완료하세요.
관련 글