프록시는 켰는데 DNS만 불안한 이유

Clash나 Mihomo 계열 클라이언트를 켜 두어도 사용자는 종종 이렇게 느낍니다. 「브라우저 트래픽은 노드를 타는 것 같은데, DNS만 회선 쪽으로 새는 것 아닐까?」 혹은 「해외 사이트인데 응답 지역이 이상하다」는 식의 의심입니다. HTTP·SOCKS 프록시는 애플리케이션 연결을 감싸지만, 도메인을 IP로 바꾸는 질의가 어디서 처리되느냐는 별도의 문제이기 때문입니다. 운영체제가 지정한 리졸버, 브라우저의 DNS over HTTPS, 앱이 박아 둔 고정 DNS 등이 Clash 밖에서 동작하면, 시각적으로는 프록시가 켜져 있어도 DNS 관점에서는 「로컬 경로」가 남을 수 있습니다.

이 글에서는 Clash Fake-IP와 DNS 설정(enhanced-mode, nameserver, fallback 등)을 한 장면으로 묶어 설명하고, DNS 누출 가능성을 줄이기 위한 재현 가능한 점검 순서를 제시합니다. TUN 모드와 dns-hijack을 함께 쓰는 경우는 TUN 모드 가이드와 연결해 이해하면 흐름이 더 분명해집니다. 기본 설치·프로필 구조는 문서의 설치·설정 안내를 함께 보시길 권합니다.

fake-ip와 redir-host를 먼저 구분하기

Clash Meta(Mihomo) 계열에서 도메인 기반 규칙을 빠르게 적용하려면 DNS 단계에서 「가짜 주소」를 쓰는 방식이 흔합니다. fake-ip는 내부 대역(예: 198.18.0.0/16)의 IP를 임시로 돌려 주고, 실제 연결 시점에 코어가 다시 도메인·정책에 맞춰 목적지를 결정합니다. 사용자 입장에서는 브라우저가 먼저 가짜 IP로 연결을 열고, 그다음 Clash가 규칙에 따라 프록시 또는 직접 연결로 나눕니다.

redir-host(또는 호스트를 그대로 넘기는 계열)는 DNS 응답으로 실제 IP(또는 기대에 가까운 응답)를 더 직접적으로 다루는 쪽에 가깝습니다. 규칙 매칭 방식·캐시·지연 특성이 fake-ip와 달라서, 「같은 구독인데 UI에서만 바꿨는데 속도나 매칭이 달라진다」는 체감이 생기기도 합니다. 중요한 점은 둘 다 정답/오답이라기보다 트레이드오프라는 것입니다. fake-ip는 분기와 캐시 측면에서 편한 경우가 많고, redir-host는 특정 앱·특정 도메인에서 호환성을 기대할 때 선택되기도 합니다.

ℹ️
용어: 클라이언트 UI의 「글로벌/규칙」 모드와 DNS의 fake-ip/redir-host는 서로 다른 축입니다. 전자는 rules로 트래픽을 어디로 보낼지, 후자는 이름 해석 단계를 코어가 어떻게 가질 것인지에 가깝습니다.

enhanced-mode가 DNS 파이프라인을 바꾸는 방식

단순히 upstream DNS 서버 몇 개를 적어 두는 것만으로는 「앱이 Clash 밖에서 따로 질의하는 경우」를 항상 막을 수 없습니다. enhanced-mode(문서·빌드에 따라 표기가 조금 다를 수 있음)를 켜면 코어가 도메인 해석과 규칙 매칭을 더 긴밀하게 엮으려 합니다. 사용자가 체감하기 쉬운 변화는 「같은 도메인인데 규칙에 더 잘 맞는다」 혹은 반대로 「설정이 꼬이면 해석이 꼬인다」입니다.

실무에서는 enhanced-mode를 켠 상태에서 nameserver와 fallback을 어떻게 나누는지가 중요합니다. 일반적으로 nameserver는 빠른 질의용, fallback은 필터링·검열 회피 등이 필요할 때 쓰는 보조 서버로 두는 패턴이 많습니다. 여기에 fallback-filter로 지연·지오IP 조건을 걸면 「언제 fallback으로 넘어갈지」를 제어할 수 있습니다. 다만 이 조합은 네트워크 환경과 노드 품질에 민감하므로, 한 번에 여러 값을 바꾸기보다 한 단계씩 바꾸고 로그로 확인하는 편이 안전합니다.

nameserver·fallback·proxy-server-nameserver 역할 정리

YAML 예시는 이해를 돕기 위한 것이며, 실제 키 이름과 기본값은 사용 중인 코어 버전·프로필 템플릿을 따르세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://dns.google/dns-query
    - tls://dns.quad9.net:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
  # proxy-server-nameserver: ...  # when proxy DNS must differ

nameserver는 말 그대로 1차로 시도하는 목록입니다. 국내에서 지연을 줄이려면 지역에 맞는 DNS를 넣는 경우가 많습니다. fallback은 nameserver 응답이 신뢰하기 어렵거나 차단된 것으로 판단될 때 이어서 물어보는 풀입니다. proxy-server-nameserver는 이름 그대로, 프록시 터널 안에서 DNS를 따로 밀어 넣어야 하는 시나리오에서 등장합니다. 여기까지가 「설정 문자열」이고, 실제로 누출이 줄었는지는 아래 절차로 확인합니다.

TUN과 dns-hijack을 쓸 때의 포인트

시스템 프록시만 쓰는 경우에도 Clash의 DNS 블록은 동작하지만, 앱이 OS가 아닌 자체 경로로 53번 UDP·TCP를 박아 두면 빗나갈 수 있습니다. TUN 모드를 켜고 dns-hijack으로 any:53 등을 코어로 끌어오면 「터널 안에서 일관되게 처리」하려는 의도가 분명해집니다. 다만 다른 VPN·필터 드라이버와 경로가 겹치면 충돌이 나기 쉬우므로, TUN 가이드의 권장 순서대로 한 번에 하나씩 켜 가며 테스트하는 것이 좋습니다.

tun:
  enable: true
  dns-hijack:
    - any:53

fake-ip와 TUN을 동시에 다룰 때 흔한 혼란은 「브라우저에는 가짜 IP가 보이는데, 외부 DNS 테스트 사이트는 여전히 ISP를 가리킨다」처럼 측정 도구가 무엇을 보고 있는지를 헷갈리는 경우입니다. 다음 절에서는 그 구분을 명확히 합니다.

재현 가능한 점검 순서(실측)

아래 순서는 대부분의 데스크톱 환경에서 반복할 수 있도록 단순화했습니다. 중요한 원칙은 한 번에 한 가지 변수만 바꾸는 것입니다.

1) 코어 로그에서 DNS 질의가 코어를 통과하는지

클라이언트의 로그 뷰에서 도메인 질의·응답이 기록되는지 확인합니다. 아무 것도 찍히지 않는데 브라우저만 빠르게 열린다면, 브라우저가 DoH로 우회하거나 OS 캐시를 쓰는 경로를 의심합니다. 이때는 브라우저의 보안 DNS 설정을 잠시 끄고 다시 시도해 보는 식의 대조 실험이 유효합니다.

2) 터미널에서 리졸버 동작 보기

운영체제에 따라 nslookup, dig, PowerShell의 Resolve-DnsName 등을 사용해 동일 도메인에 대해 어떤 서버에 묻는지 확인합니다. TUN을 켠 상태에서는 53번이 터널로 흡수되는지, 혹은 여전히 로컬 게이트웨이로 나가는지가 갈립니다. 여기서 결과가 환경마다 달라질 수 있으므로, 「내 PC에서의 전후 비교」만이라도 기록해 두면 다음 설정 변경의 기준이 됩니다.

3) 웹 기반 DNS 누출 테스트는 참고용으로

공개 테스트 페이지는 브라우저의 DoH/Tor 여부, WebRTC, 확장 프로그램 영향으로 결과가 흔들릴 수 있습니다. 한 번의 스크린샷보다 같은 조건을 세 번 반복하고, Clash의 DNS·TUN 설정을 바꾼 뒤 차이가 재현되는지 보는 편이 안전합니다. 테스트가 ISP DNS를 가리키더라도, 그것이 「항상 치명적 누출」이라기보다 측정 방식의 한계일 수 있음을 기억하세요.

4) fake-ip-filter와 예외 도메인

LAN 주소·특정 스트리밍·사내 도메인 등은 가짜 IP를 타면 오히려 깨지는 경우가 있습니다. 이런 도메인은 fake-ip-filter(또는 템플릿의 동등 설정)에 넣어 예외 처리합니다. 이 목록이 과하면 규칙 매칭이 기대와 달라지고, 너무 적으면 앱이 깨집니다. 변경 후에는 반드시 위 1)~3)을 다시 돌려 재현성을 확인하세요.

⚠️
주의: DNS와 TUN을 동시에 크게 손대다 보면 순간적으로 이름 해석이 멈춘 것처럼 보일 수 있습니다. 원격 프로필만 의존하는 환경이라면, 유선 테더링 등 복구 경로를 마련한 뒤 시도하세요.

자주 있는 오해와 실수

첫째, 「프록시 그룹이 해외 노드면 DNS도 자동으로 안전하다」는 보장은 없습니다. 프록시는 연결을 태우는 경로이고, DNS는 이름을 묻는 경로입니다. 둘을 의도적으로 맞추려면 enhanced-mode·TUN·브라우저 설정을 함께 맞춰야 합니다.

둘째, fallback 목록만 늘린다고 해서 항상 품질이 좋아지지는 않습니다. 서버가 많을수록 지연·실패 패턴만 복잡해질 수 있으니, 실제로 fallback이 발동하는지 로그로 확인하는 것이 먼저입니다.

셋째, Windows와 macOS는 시스템 리졸버 정책이 달라서 동일 YAML이라도 체감이 다를 수 있습니다. 문서의 플랫폼별 주의점과 클라이언트 FAQ를 함께 보는 것이 좋습니다.

✅
팁: 규칙 세트를 자주 바꾼다면, DNS 관련 키워드가 포함된 로그만 필터링해 저장해 두면 나중에 「언제부터 이상해졌는지」를 추적하기 쉽습니다.

신뢰할 수 있는 클라이언트와 프로필

DNS 설정은 네트워크 관찰 지점에 가깝습니다. 출처가 불분명한 구독·바이너리를 그대로 신뢰하기보다, 검증된 릴리스와 투명한 프로필을 쓰는 것이 우선입니다. 오픈 소스 저장소는 신뢰 형성에 도움이 되지만, 설치 패키지를 받는 주 경로는 혼선을 줄이기 위해 공식 다운로드 페이지를 권장합니다.

정리

Clash에서 Fake-IP와 DNS 설정은 규칙 분기와 함께 움직이는 한 세트로 이해하는 것이 좋습니다. redir-host로 바꾸는 것, enhanced-mode를 켜는 것, nameserver와 fallback을 나누는 것, TUN에서 dns-hijack을 쓰는 것은 각각 다른 문제를 겨냥합니다. 이 글의 점검 순서대로 한 단계씩 확인하면 「프록시는 켰는데 DNS만 불안한」 상태를 재현 가능한 형태로 줄일 수 있습니다.

동일한 Mihomo 코어를 쓰는 GUI라도 스위치 이름은 다르지만, 개념은 동일합니다. YAML에 의도를 명확히 남기고, 로그와 터미널로 전후를 비교하면 설정이 길을 잃지 않습니다. 다른 도구에 비해 구독·규칙·DNS·TUN을 한 앱에서 정리할 수 있다는 점은 일상 사용에서 큰 장점입니다.

환경에 맞는 클라이언트는 Clash 공식 다운로드 페이지에서 고를 수 있습니다. → Clash를 무료로 내려받아 DNS와 Fake-IP 설정을 안정적으로 맞춰 보세요.