Clash DNS 설정 상세 가이드: 오염과 유출 해결하기
fake-ip와 redir-host는 어떤 차이가 있을까요? DNS 오염을 막고 DNS 유출을 피하려면 nameserver를 어떻게 설정해야 할까요? 이 글은 DNS 모듈의 원리와 실전 설정을 한 번에 완전히 정리합니다.
DNS 설정이 왜 이렇게 중요한가
많은 사람이 Clash를 설치하고 구독을 가져오면 다 끝났다고 생각하지만, 실제로는 특정 사이트가 열리지 않거나 분명 프록시를 탔는데도 국내 IP로 인식되거나, 반대로 국내 사이트가 해외로 해석되는 경우가 있습니다. 이런 문제는 대부분 DNS 단계에서 발생하며, 프록시 노드 자체의 문제가 아닙니다.
브라우저가 어떤 주소에 접속하기 전에는 먼저 도메인을 IP 주소로 해석해야 하는데, 이 과정이 바로 DNS 조회입니다. 이 단계에서 통신사가 "장난을 치면" 이후 프록시를 아무리 잘 설정해도 소용이 없습니다. 이미 처음부터 잘못된 IP를 받았기 때문입니다. 흔한 두 가지 "장난" 방식은 다음과 같습니다.
-
DNS 오염통신사나 중간 장비가 DNS 응답을 위조해서 잘못된 IP로 유도합니다(예: 접속할 수 없는 주소를 반환하거나 광고 페이지로 리다이렉트).
-
DNS 유출트래픽은 프록시를 타더라도 DNS 조회 요청은 여전히 직접연결로 로컬 통신사에 전송되어, 어떤 사이트에 접속했는지 그대로 기록되며 프록시가 무의미해집니다.
판단 기준은 간단합니다. dnsleaktest.com에서 테스트했을 때, 표시되는 DNS 서버의 소속지가 노드가 위치한 곳이 아니라 여러분의 로컬 통신사라면 DNS 유출이 있다는 뜻입니다.
세 가지 DNS 해석 모드 비교
Clash의 DNS 모듈은 여러 가지 작동 모드를 지원하며, 이들의 차이를 이해하는 것이 DNS를 제대로 설정하는 핵심입니다.
가장 초기의 모드입니다. Clash가 상위 DNS 서버에 실제 IP를 직접 조회한 다음, 규칙에 따라 프록시로 보낼지 직접연결로 보낼지 결정합니다. 장점은 단순하고 직관적이라는 점이고, 단점은 도메인 기반 라우팅이 제대로 동작하지 않을 수 있다는 점입니다—실제 IP를 받은 후 해당 IP 대역이 규칙에 매칭되지 않으면 직접연결이 실패할 수 있고, GEOIP 같은 IP 대역 규칙에 대한 지원도 정밀하지 못합니다.
Clash는 실제 IP를 곧바로 반환하지 않고, 먼저 가상의 사설 IP(예: 198.18.0.1)를 클라이언트에 할당합니다. 실제로 연결을 시도할 때가 되어서야 Clash가 도메인을 기준으로 규칙을 매칭해서 프록시로 보낼지 직접연결로 보낼지 결정하고, 이때 비로소 실제 상위 서버에 IP를 조회합니다. 이런 "먼저 라우팅, 나중에 해석" 방식은 도메인 기반 규칙이 항상 우선 적용되도록 보장하며, 현재 가장 추천되는 모드입니다.
fake-ip 모드에서는 도메인 규칙(DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD)이 100% 매칭됩니다. 라우팅 판단이 실제 IP가 나타나기 전에 이루어지기 때문입니다. 그래서 대부분의 구독이 기본으로 이 모드를 사용합니다.
일부 애플리케이션(예: 로컬 네트워크 장치 검색, 사내 인트라넷 시스템)은 가상 IP를 쓸 수 없고 실제 IP를 받아야만 정상적으로 동작합니다. 이때는 fake-ip-filter로 해당 도메인을 가상 IP 할당 대상에서 제외해서 항상 실제 해석을 거치도록 할 수 있습니다.
# DNS 모듈 핵심 설정 dns: enable: true ipv6: false enhanced-mode: fake-ip fake-ip-range: 198.18.0.1/16 fake-ip-filter: - '*.lan' - '*.local' - '+.market.xiaomi.com' nameserver: - 223.5.5.5 # 알리바바 DNS, 국내 도메인용 - 119.29.29.29 # 텐센트 DNS, 위와 동일 fallback: - tls://8.8.4.4:853 # DoT, 해외 도메인용 - tls://1.1.1.1:853 fallback-filter: geoip: true geoip-code: CN
nameserver와 fallback은 어떻게 골라야 할까
초보자가 가장 헷갈리는 부분입니다. nameserver와 fallback은 둘 다 "상위 DNS 서버 목록"이지만 역할은 완전히 다릅니다.
- nameserver: 기본적으로 우선 사용되는 서버로, 보통 국내 통신사에서 정상적으로 접속되고 속도가 빠른 DNS를 입력합니다(알리바바 223.5.5.5, 텐센트 119.29.29.29, 114 DNS 등).
- fallback:
fallback-filter가 어떤 조회 결과를 "국내 주소 같지 않다"고 판단하면 여기의 서버로 바꿔서 다시 한 번 조회합니다. 보통 오염을 피하기 위해 DoH/DoT 암호화 DNS(예: Google, Cloudflare)를 입력합니다.
fallback-filter.geoip: true와 함께 사용하면 Clash는 먼저 nameserver로 조회하고, 해석된 IP가 geoip-code에 지정된 국가/지역(예: CN)에 속하지 않으면 자동으로 fallback으로 전환해서 다시 조회합니다. 이렇게 하면 "국내 도메인은 국내 DNS로, 해외 도메인은 암호화 DNS로" 보내는 자동 라우팅이 이루어져 도메인 목록을 수동으로 관리할 필요가 없습니다.
여러분의 기기 자체에 해외 직접연결 능력이 없다면(예: 회사 인트라넷에서 강제로 프록시 게이트웨이를 거치는 경우), fallback의 DoT/DoH 요청도 Clash 자체의 프록시를 통해 전달되어야 합니다. 그렇지 않으면 조회가 타임아웃됩니다. 대부분의 클라이언트는 기본적으로 이 부분을 이미 처리해두었으니, 해석 오류가 발생하면 클라이언트 설정에서 "DNS를 프록시로 전달" 옵션이 켜져 있는지 확인해보세요.
검증 및 흔한 문제 해결
-
nslookup / dig 테스트터미널에서
nslookup google.com을 실행했을 때198.18.x.x대역의 주소가 반환되면 fake-ip가 정상 작동하고 있다는 뜻입니다(이는 정상적인 현상이며 오류가 아닙니다). -
DNS 유출 테스트dnsleaktest.com에 접속해서 확장 테스트를 진행하고, 표시되는 DNS 서버 주소가 로컬 통신사가 아니라 프록시 노드가 위치한 곳과 일치하는지 확인하세요.
-
패널 로그컨트롤 패널의 "로그" 페이지에서 레벨을 debug로 전환하면, 정상적으로 사이트에 접속할 때 DNS 조회와 규칙 매칭의 상세 과정이 표시되어 어떤 규칙이 실제로 매칭되었는지 쉽게 파악할 수 있습니다.
nslookup으로 조회한 IP가 198.18로 시작하는데 왜 웹페이지는 정상적으로 열리나요?
이것이 바로 fake-ip 모드의 작동 방식입니다—198.18.0.0/16은 Clash 내부에서 도메인을 식별하는 데만 사용하도록 예약된 가상 주소 대역으로, 실제 네트워크 요청은 연결이 수립되는 순간 Clash가 가로채서 실제 노드로 전달하므로 정상적인 접속에는 영향이 없습니다.
일부 내부 네트워크 장치/로컬 NAS가 갑자기 연결되지 않는데, DNS 문제인가요?
가상 IP 대역이 로컬 네트워크 장치 검색 방식과 충돌하는 경우일 가능성이 높습니다. 해당 도메인(예: *.lan, 라우터 관리 도메인)을 fake-ip-filter에 추가해서 실제 해석을 거치도록 하면 해결됩니다.
DNS 설정을 바꾼 후 클라이언트를 재시작해야 하나요?
대부분의 클라이언트는 설정 핫 리로드를 지원합니다("설정 다시 불러오기"를 클릭하면 됩니다). 다만 캐시된 DNS 기록이 만료되지 않아 잠시 지연되어 적용되는 경우도 있으니, 클라이언트를 재시작하거나 시스템 DNS 캐시를 비워서 완전히 새로고침할 수 있습니다.
더 알아보기
다 배우셨나요? Clash를 설치해서 직접 사용해보세요
모든 플랫폼의 설치 파일을 한곳에서 받을 수 있으며, 추천 태그를 따라 선택하면 실수할 일이 없고 몇 분이면 바로 사용할 수 있습니다.