DNS 설정 완벽 가이드: fake-ip vs redir-host 심층 분석

DNS는 모든 네트워크 요청의 첫 번째 단계이며 프록시 설정에서 가장 많은 문제가 발생하는 부분입니다. Clash에는 완전한 기능의 DNS 처리 엔진이 내장되어 있습니다. "프록시는 작동하는데 일부 사이트가 느림", DNS 누출, "노드 핑은 통하는데 연결이 타임아웃됨" 같은 문제를 진단하려면 작동 방식을 이해하는 것이 필수입니다. 이 글에서는 두 가지 DNS 모드(redir-host와 fake-ip)를 비교하고 실전에서 바로 사용할 수 있는 설정 템플릿을 제공합니다.

프록시 환경에서 DNS가 까다로운 이유

일반적인 브라우징에서는 단순합니다: DNS 조회 → 실제 IP 획득 → TCP 연결. 프록시가 개입하면 복잡해집니다. DNS 쿼리가 프록시를 거치지 않고 로컬 리졸버로 전송되면, 프록시를 통해 접근하려는 도메인의 결과가 부정확할 수 있습니다. 반면 모든 것을 프록시 서버를 통해 해결하면 레이턴시가 늘어나고 직접 연결해도 되는 트래픽에는 불필요합니다.

Clash는 실제 IP 주소를 알기 전에 트래픽을 프록시할지 직접 연결할지 결정해야 합니다. 이 긴장감이 DNS 모드 설계를 이끌어냅니다.

redir-host 모드: 실제 IP를 먼저

redir-host는 Clash의 원래 DNS 모드입니다. 작동 방식은 다음과 같습니다:

앱이 DNS 쿼리 발행 (예: openai.com 조회)
Clash가 여러 업스트림 DNS 서버에 병렬로 쿼리하고 가장 빠른 결과를 반환
실제 IP가 앱에 반환됨
앱이 해당 IP로 연결을 시도; Clash는 IP-CIDR 또는 GEOIP 규칙을 적용해 라우팅 결정

redir-host의 단점은 규칙 매칭이 실제 IP에 의존한다는 것입니다. 그런데 그 IP를 얻는 과정 자체가 DNS 하이재킹이나 오염의 영향을 받을 수 있어, 트래픽이 잘못된 경로로 가게 됩니다. 또한 연결마다 완전한 DNS 라운드트립이 필요해 첫 연결 레이턴시가 증가합니다.

fake-ip 모드: 즉시 임시 IP 할당

fake-ip는 Mihomo(구 Clash.Meta)가 권장하는 현대적 접근법으로, TUN 모드와 최적으로 결합됩니다. 핵심 아이디어: 실제 IP를 기다리지 말고 즉시 가짜 프라이빗 IP를 반환하고, 실제 DNS 해석은 프록시 측에 위임합니다.

앱이 DNS 쿼리 발행
Clash가 즉시 fake-ip-range 풀(기본값: 198.18.0.0/15)에서 가짜 IP를 할당해 반환하고, 내부적으로 "가짜 IP ↔ 도메인" 매핑 유지
앱이 가짜 IP로 연결 시도
Clash가 연결을 가로채 매핑에서 원래 도메인을 복원한 후 도메인 기반 규칙으로 프록시/직접 결정
프록시 경유 시: 프록시 서버 측에서 DNS 해석. 직접 연결 시: Clash가 실제 DNS 쿼리 발행 후 연결 포워딩

fake-ip가 유리한 이유: 규칙이 IP가 아닌 도메인 이름으로 매칭되므로 DNS 하이재킹을 완전히 우회합니다. 실제 DNS 응답을 기다릴 필요가 없어 첫 연결 레이턴시도 낮아집니다. 프록시 대상 도메인은 프록시 서버에서만 해석되므로 DNS 누출 위험이 최소화됩니다.

fake-ip-filter: 실제 IP가 필요한 도메인

모든 앱이 가짜 IP로 정상 작동하는 것은 아닙니다. 데스크톱 게임, VoIP 클라이언트, P2P 소프트웨어 등 서비스 검색이나 직접 연결을 위해 실제 IP가 필요한 앱들은 가짜 IP를 반환하면 작동하지 않습니다. fake-ip-filter 필드로 해당 도메인을 제외하면 정상적인 DNS 해석으로 실제 IP를 받을 수 있습니다.

권장 fake-ip 설정 템플릿

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

  # fake-ip에서 제외할 도메인 (실제 IP 할당)
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - +.stun.*.*
    - +.stun.*.*.*
    - +.xbox.*.microsoft.com
    - *.msftncsi.com

  nameserver:
    - 1.1.1.1           # Cloudflare — 기본 리졸버
    - 8.8.8.8           # Google DNS

  fallback:
    - tls://1.1.1.1:853  # Cloudflare DNS over TLS
    - tls://8.8.8.8:853  # Google DNS over TLS

  fallback-filter:
    geoip: true
    geoip-code: KR      # 자신의 국가 코드로 변경하세요
    ipcidr:
      - 240.0.0.0/4

nameserver vs fallback: 연동 방식

nameserver는 모든 초기 쿼리에 사용되는 기본 DNS 리졸버입니다. fallback은 보조 리졸버 세트로, fallback-filter 조건이 충족될 때(예: 해석된 IP가 GEOIP 범위 밖) nameserver 결과를 fallback 결과로 교체합니다. 이 설계 덕분에 직접 연결할 트래픽은 빠른 로컬 리졸버를 사용하고, 프록시할 트래픽은 암호화 DNS로 해석되어 차단이나 변조를 방지합니다.

fallback을 설정하지 않으면 모든 DNS 쿼리가 nameserver를 통합니다. 리졸버에 따라 GEOIP 분류가 부정확해지고 프록시를 통해도 일부 사이트에 접근할 수 없게 됩니다.

DNS 누출 확인 방법

dnsleaktest.com에 접속해 확장 테스트를 실행하세요. 알 수 없는 DNS 서버가 표시되면(예: Cloudflare나 Google DNS 대신 ISP 리졸버) DNS 누출이 발생한 것입니다. fake-ip와 fallback을 올바르게 설정하면 프록시 서버의 DNS 또는 설정한 암호화 리졸버만 표시되어야 합니다.

또 다른 확인 방법: Clash 설정에서 log-level: debug를 활성화하고 재시작합니다. 프록시를 통해 접근해야 하는 사이트에 연결할 때 디버그 로그에서 해당 도메인의 DNS 쿼리가 fallback 리졸버로 전송되는 것을 확인할 수 있습니다.