Clash의 DNS 설정을 처음 접하면 다소 혼란스러울 수 있습니다. 코어에는 자체 DNS 모듈이 있고, 클라이언트에서도 "시스템 프록시"나 "TUN"을 선택할 수 있는데, 도메인은 결국 어떻게 해석되는 걸까요? 이 글은 원리부터 설명하며 dns 설정 항목을 제대로 이해할 수 있게 도와드립니다.
프록시 도구가 DNS까지 관리하는 이유
도메인 해석이 로컬 통신사 DNS를 거치면, 트래픽이 결국 노드를 통해 전달되더라도 해석 결과가 이미 오염되었거나 부정확한 IP를 반환했을 수 있어, 규칙 분기가 잘못된 지역으로 판단(예: GEOIP,KR 오판)될 수 있습니다. 그래서 Clash는 DNS 모듈을 내장하여 해석 과정을 직접 제어함으로써 "해석"과 "전달"을 모두 자신의 관리 범위 안에 둡니다.
두 가지 해석 모드: redir-host와 fake-ip
DNS를 설정하기 전에 반드시 이해해야 할 핵심 개념입니다. 두 방식의 핵심 차이는 "클라이언트가 받는 IP가 실제 IP인가"입니다.
| 모드 | 해석 결과 | 적합한 상황 |
|---|---|---|
| redir-host | 실제 공개 IP | 호환성이 가장 좋아, 실제 IP로 검증이 필요한 앱에 적합 |
| fake-ip | 가상 프라이빗 대역 IP | 해석이 빠르고 DNS 유출을 방지, 현재 주류 권장 설정 |
fake-ip-filter에 추가해 제외해보세요.
DoH / DoT를 도입해 업스트림 DNS 오염 방지하기
nameserver에 평문 UDP DNS(예: 8.8.8.8)만 설정하면, 요청 자체가 경로 중간에서 탈취되거나 변조될 수 있습니다. 암호화 DNS(DoH/DoT)는 쿼리를 HTTPS/TLS로 감싸서 오염될 확률을 크게 낮춥니다.
nameserver는 기본 해석 그룹이고, fallback은 기본 해석 결과가 지정한 지역(fallback-filter로 판단) 밖에 있을 때만 사용되는 예비 해석 그룹으로, 보통 속도가 빠르고 오염 저항성이 강한 해외 DNS로 설정합니다.
nameserver-policy: 도메인별로 DNS 지정하기
특정 도메인만 특정 DNS를 사용하도록 하고 싶다면(예: 내부 도메인은 로컬 DNS, 나머지는 암호화 DNS) nameserver-policy로 개별 지정할 수 있습니다.
IPv4/IPv6 듀얼스택 환경에서 주의할 점
로컬 네트워크에 IPv4와 IPv6가 모두 있고 통신사의 IPv6 출구 품질이 좋지 않다면, 오히려 속도가 느려질 수 있습니다. 브라우저는 Happy Eyeballs 메커니즘으로 두 프로토콜을 동시에 시도하지만, Clash는 기본적으로 IPv6 해석을 특별히 처리하지 않을 수 있습니다. ipv6 필드로 IPv6 결과를 해석하고 사용할지 명시적으로 제어할 수 있습니다.
IPv6 출구 품질이 좋다면 그대로 켜두고 fake-ip가 IPv4/IPv6 결과를 모두 다루게 해도 좋습니다. 어떤 것이 맞는지는 실제 속도 테스트로 비교한 뒤 결정하는 것이 좋으며, 어딘가의 "만능 설정"을 그대로 베끼는 것은 피하세요.
DNS와 로컬 hosts의 우선순위
자체 서비스 테스트나 특정 도메인 임시 차단 같은 상황에서는 시스템 hosts 파일을 직접 편집하고 싶을 수 있습니다. 주의할 점은, Clash가 DNS를 제어하게 되면(dns.enable: true) 시스템 hosts의 매핑이 코어에 인식되지 않을 수 있다는 것입니다. 해석 요청이 시스템 리졸버를 거치지 않을 수 있기 때문입니다. 이런 경우에는 Clash 설정에 직접 hosts 항목을 추가하는 것이 효과는 같으면서 적용 범위가 더 명확합니다.
hosts는 일반적으로 통상적인 DNS 해석 흐름보다 우선순위가 높습니다. 로컬 개발 환경의 도메인 매핑에 적합하며, 시스템 수준의 hosts 파일을 수정할 필요가 없습니다.
클라이언트별 DNS 설정 화면의 차이
대부분의 GUI 클라이언트는 dns 설정을 "기본"과 "고급" 두 단계로 캡슐화합니다. 기본 모드에서는 "향상 모드"(enhanced-mode에 대응)에 대한 드롭다운만 노출되고, 고급 모드에서 nameserver, fallback 같은 구체적인 필드가 표시됩니다. 클라이언트 화면에서 특정 필드를 찾을 수 없더라도, 설정 파일을 직접 편집(또는 "설정" 내의 원본 YAML 편집 항목)해서 추가할 수 있습니다. 클라이언트는 화면에 표시하지 않은 항목이라도 설정을 읽어들일 때 무시하지 않습니다.
도메인 해석 오류 문제 해결 순서
- 먼저 DNS 모듈이 켜져 있는지 확인:
dns.enable이false면 Clash는 해석을 제어하지 않고 시스템에 넘깁니다. - 잘못된 규칙에 매칭되지 않았는지 확인: 일부 도메인 규칙이
DIRECT보다 앞에 배치되어, 프록시를 거쳐야 할 도메인이 직접 해석되는 경우가 있습니다. - fake-ip 충돌을 의심: 내부 기기, LAN 프린터, 게임 콘솔 검색 이상이 발생하면 먼저 해당 도메인을
fake-ip-filter에 추가해보세요. - 외부 도구로 교차 검증: 프록시를 켜고 끈 두 상태에서 각각
nslookup을 실행하거나 온라인 DNS 점검 도구를 사용해 해석 결과의 차이를 비교합니다.
모바일에서 별도 조정이 필요할까
스마트폰은 Wi-Fi와 모바일 네트워크를 자주 전환하기 때문에 DNS 캐시의 동작이 데스크톱보다 더 "민감"하게 나타나는 편입니다. 네트워크를 전환한 후 어떤 사이트가 전환 전 결과로 해석된다면, 대부분 설정 문제가 아니라 시스템이나 클라이언트가 이전 해석 기록을 캐시하고 있는 것일 뿐입니다. 캐시가 만료되거나 프록시 서비스를 한 번 수동으로 재시작하면 해결됩니다. 일부 모바일 앱은 절전을 위해 백그라운드 재연결 빈도를 제한하므로, 장시간 대기 후 해석 오류가 발생하면 클라이언트를 완전히 종료하고 다시 열어보는 것도 시도해볼 만합니다.
TUN 모드에서 DNS 동작은 어떻게 다른가
TUN 모드를 활성화하면 시스템 차원의 모든 트래픽(DNS 쿼리 포함)이 가상 네트워크 어댑터를 통해 처리되며, 이론적으로는 기존 시스템 프록시 방식보다 더 넓은 범위를 커버할 수 있습니다. 시스템 프록시 설정을 따르지 않는 일부 앱(자체 DNS 해석 라이브러리를 사용하는 프로그램 등)도 가로챌 수 있습니다. 다만 이는 DNS 설정에 오류가 생겼을 때 영향 범위도 더 커진다는 의미이기도 합니다. 그러므로 먼저 시스템 프록시 모드에서 dns 설정을 안정화한 뒤 TUN 모드로 전환해 효과를 확인하는 것을 권장하며, 처음부터 TUN 모드에서 반복적으로 시도하는 것은 피하세요.
정리
일상적인 사용에서는 fake-ip와 암호화 DNS 업스트림만으로도 대부분의 상황을 커버할 수 있습니다. 내부망 검색이나 특정 프로토콜 이상을 만났을 때만 fake-ip-filter나 nameserver-policy를 세밀하게 조정하면 됩니다. 이 논리를 이해해두면 "속도 테스트는 되는데 페이지가 안 열린다" 같은 문제도 스스로 원인을 찾아 해결할 수 있게 됩니다.