Clash DNS 설정 완전 정리: 오염과 유출 해결하기

Clash 클라이언트를 설치했는데도 특정 페이지가 계속 안 열린다면, 원인이 노드가 아니라 DNS에 있는 경우가 많습니다. 도메인이 처음부터 잘못된 IP로 해석되면 프록시가 아무리 잘 되어 있어도 소용이 없습니다. 이 글에서는 Clash의 DNS 모듈을 어떻게 설정해야 하는지, 오염과 유출이라는 두 가지 문제를 어떻게 한 번에 해결할 수 있는지 정리합니다.

DNS를 왜 별도로 신경 써야 할까

평소 인터넷을 쓸 때 브라우저는 먼저 DNS 서버에 "이 도메인의 IP가 뭐야?"라고 묻고, 받은 IP로 접속을 시도합니다. 문제는 이 과정의 두 지점에서 생깁니다.

DNS 오염(DNS Poisoning): 통신사나 네트워크 경로 중간에서 특정 도메인 조회에 조작된 IP를 돌려주는 경우로, 이 경우 접속은 당연히 실패하거나 타임아웃이 발생합니다.
DNS 유출(DNS Leak): 트래픽은 프록시를 타는데 DNS 조회만 로컬에서 평문으로 나가는 경우로, 어떤 사이트에 접속했는지가 그대로 노출되는 셈입니다.

그래서 Clash에는 DNS 모듈이 내장되어 있습니다. 이를 활성화하면 기기의 모든 DNS 조회가 먼저 Clash를 거치고, 어떤 서버로 해석할지, 프록시를 통해 해석할지를 Clash가 결정합니다.

fake-ip와 redir-host의 차이

enhanced-mode에는 두 가지 값이 있으며, 이 값에 따라 시스템의 DNS 조회에 응답하는 방식이 달라집니다.

모드	동작 방식	장단점
`fake-ip`	예약된 대역의 가짜 IP(198.18.x.x)를 즉시 반환하고, 실제 해석은 연결이 맺어질 때로 미룹니다	응답이 빠르고 유출이 없음; 실제 IP를 직접 검사하는 일부 프로그램(특정 게임, 인터넷뱅킹 등)과 호환되지 않을 수 있음
`redir-host`	실제 IP를 끝까지 조회한 뒤 반환합니다	호환성이 가장 좋음; 다만 해석 결과가 오염될 수 있고 규칙 매칭 시점도 더 늦어짐

결론: 평소에는 fake-ip를 우선 사용하세요. 호환되지 않는 앱을 만나면 fake-ip-filter로 해당 도메인만 제외하면 되고, 전체를 redir-host로 되돌릴 필요는 없습니다.

fake-ip-filter 예시

dns:
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "+.stun.*.*"
    - "+.battle.net"       # game launchers often need real IP
    - "time.windows.com"

nameserver와 fallback의 역할 분담

DNS 설정 전체에서 가장 헷갈리기 쉬운 부분입니다. 올바른 사고방식은 다음과 같습니다.

nameserver: 주 해석 그룹으로, 평소 쓰는 빠른 DNS(이용 중인 통신사의 DNS나 공용 DNS)를 넣어 대부분의 도메인을 빠르게 해석합니다.
fallback: 보조 해석 그룹으로, 암호화된 해외 DNS(DoH/DoT)를 넣어 조작되었을 가능성이 있는 도메인을 전담 처리합니다.

두 그룹은 동시에 조회를 수행합니다. 조회 결과가 fallback-filter의 조건에 걸리면(예: 해석된 IP가 한국 IP 대역이 아닌 경우) fallback 쪽 결과를 채택해 오염을 피합니다.

추천하는 전체 DNS 설정

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1                         # Cloudflare
    - 8.8.8.8                         # Google
  fallback:
    - https://1.1.1.1/dns-query       # Cloudflare DoH
    - https://dns.google/dns-query    # Google DoH
  fallback-filter:
    geoip: true
    geoip-code: KR
    ipcidr:
      - 240.0.0.0/4                   # bogus IPs returned by poisoning

이 설정의 효과는 다음과 같습니다. 대부분의 도메인은 빠른 기본 DNS로 순식간에 해석되고, 해석 결과가 의심스러울 때는 자동으로 암호화 DNS 결과로 바꿔 씁니다. 오염은 막고, 조회 내용도 평문으로 유출되지 않습니다.

설정이 제대로 적용됐는지 확인하는 방법

제어판의 "로그" 페이지를 열고 레벨을 debug로 바꾸면, 각 DNS 조회가 어떤 서버를 사용했는지 확인할 수 있습니다.
dnsleaktest.com에 접속해 유출 테스트를 해 보세요. 표시되는 DNS 서버가 fallback에 설정한 것(또는 노드 측 DNS)이어야 하고, 로컬 통신사 DNS가 나오면 안 됩니다.
nslookup으로 오염되기로 알려진 도메인을 조회했을 때 198.18로 시작하는 가짜 IP가 나오면 fake-ip가 정상 동작하고 있다는 뜻입니다.

자주 놓치는 부분 DNS 설정을 바꾼 뒤에는 설정을 다시 불러오고 브라우저의 DNS 캐시도 비워야 합니다(Chrome 주소창에 chrome://net-internals/#dns 입력). 안드로이드에서는 VPN 연결을 한 번 재시작해야 완전히 적용됩니다.

공유기에서 전역 프록시로 쓸 때 더 신경 써야 할 부분

Clash를 공유기나 NAS에서 돌려 집 안의 모든 기기를 투명 프록시로 묶는다면 DNS 설정의 중요성이 한 단계 더 올라갑니다. 이때는 "각 기기가 스스로 해석한다"는 도피처가 없고, 모든 기기의 도메인 해석이 Clash 한 곳을 거쳐야 하기 때문입니다. 이런 환경에서는 두 가지를 챙기세요.

listen을 공유기 내부 네트워크 인터페이스에 바인딩하세요: 기본값인 127.0.0.1만 듣게 두면 다른 기기의 DNS 요청이 아예 들어오지 못합니다. 0.0.0.0:53으로 바꾸고, 공유기 DHCP 옵션에서 게이트웨이를 DNS 서버로도 지정해 두세요.
스마트 TV나 게임기는 따로 화이트리스트를 두세요: 이런 기기는 네트워크 검증 로직이 꽤 엄격해서, DNS 결과가 기대하는 지역과 다르면 곧바로 동작을 멈추는 경우가 있습니다. 이럴 땐 집 전체의 fake-ip를 끄기보다 해당 도메인을 fake-ip-filter에 추가하는 쪽이 낫습니다.

참고로 많은 분들이 간단하다는 이유로 8.8.8.8을 주 DNS로 바로 넣는데, 네트워크 환경에 따라 Google DNS로의 경로가 우회되거나 느려질 수 있어 주 해석기로 쓰면 오히려 손해일 수 있습니다. 앞서 설명한 역할 분담 원칙을 기억하세요. nameserver는 평소 쓰는 빠른 DNS에, fallback은 암호화 DNS에 맡기는 것이 기본입니다.

흔히 하는 두 가지 오해

마지막으로 초보자가 자주 하는 오해 두 가지를 짚고 넘어가겠습니다.

"fake-ip를 켜면 실제 IP를 다시는 볼 수 없다" — 그렇지 않습니다. fake-ip는 시스템 단에서 보이는 IP만 가짜 주소로 바꿔주는 것이고, Clash 내부적으로는 연결이 맺어질 때 실제 해석을 그대로 수행합니다. 로그와 연결 페이지에서는 여전히 실제 목적지 IP를 확인할 수 있어 문제 진단에는 영향이 없습니다.
"DNS 설정이 복잡할수록 안전하다" — 오히려 반대입니다. nameserver와 fallback에 각각 두세 개면 충분하고, 서버를 너무 많이 넣으면 동시 조회 결과를 기다려야 해서 첫 조회 속도만 느려집니다. 간결하고 명확한 구성이 "크고 복잡한" 구성보다 실전에서 훨씬 유리합니다.

위 DNS 설정을 config.yaml에 그대로 옮기고 한 번 다시 불러오면, 오염과 유출이라는 두 가지 골칫거리와는 대체로 작별할 수 있습니다.

규칙 분기와의 연동: DNS도 판단에 참여한다

규칙 목록에서 GEOIP 판단을 쓰고 있다면 DNS 해석 결과가 분기 정확도에 직접 영향을 줍니다. IP가 잘못 해석되면 GEOIP 판단도 자연히 틀어져서, 국내 사이트가 프록시로 나가거나 프록시를 타야 할 사이트가 직결로 빠지는 일이 생길 수 있습니다. 그래서 "먼저 DNS를 제대로 맞추고, 그다음에 규칙을 다듬는다"는 순서가 중요합니다. 기초가 흔들리면 위에 아무리 정교한 규칙을 쌓아도 소용이 없습니다. 특정 사이트의 분기 결과가 기대와 다르다면, 규칙을 뜯어고치기 전에 먼저 DNS 해석 자체가 잘못된 건 아닌지 의심해 보는 게 순서입니다.

정리

이 글에서 하고 싶은 이야기는 사실 하나입니다. 가야 할 도메인은 가야 할 길로 보내고, DNS가 발목을 잡지 않게 하자는 것입니다. 핵심을 다시 정리하면, 기본값은 fake-ip로 하고 호환 안 되는 앱은 필터로 제외할 것, nameserver는 일반 도메인을, fallback은 오염 가능성이 있는 도메인을 각각 맡아 역할을 분명히 나눌 것, 설정을 바꾼 뒤에는 캐시 삭제·재적용·검증까지 세 단계를 모두 거쳐야 진짜로 적용된 것이라는 점입니다. 이 원칙들을 기억해 두면 나중에 기기나 클라이언트를 바꿔도 매번 처음부터 헤매지 않고 금방 안정적인 DNS 설정을 만들 수 있습니다.

Clash를 이제 막 쓰기 시작했다면, 우선 이 글의 전체 설정 예시를 그대로 적용해 얼마간 문제없이 돌려 보고, 이후 자신의 네트워크 환경에 맞춰 nameserver와 fallback의 서버 주소를 조금씩 조정하는 순서를 추천합니다. 일단 돌아가게 만들고 그다음에 최적화하는 편이, 처음부터 완벽을 추구하는 것보다 훨씬 마음 편합니다.