프록시 체인에서 DNS 해석의 위치
프록시 소프트웨어 자체는 이미 수립된 네트워크 연결만 처리하며, 도메인 이름 해석은 연결이 수립되기 전에 발생합니다. DNS 요청이 시스템 기본 리졸버를 거치고 Clash 내장 DNS 모듈을 거치지 않으면 두 가지 문제가 생깁니다. 첫째, 로컬 기기의 DNS 요청이 통신사나 로컬 네트워크의 해석 서버로 그대로 전송되어 어떤 도메인에 접속했는지가 노출되는, 이른바 DNS 유출이 발생합니다. 둘째, 규칙 엔진의 DOMAIN, DOMAIN-SUFFIX 같은 도메인 기반 규칙이 올바른 대상과 매칭되지 않을 수 있습니다. 클라이언트가 받은 IP와 규칙이 기대하는 도메인 간의 대응 관계가 일치하지 않아 트래픽 분기가 잘못될 수 있기 때문입니다.
Clash와 Clash Meta(mihomo 코어)는 모두 독립적인 dns 설정 블록을 제공해 클라이언트의 도메인 해석 흐름을 대신 처리하며, 시스템 hosts나 시스템 네트워크 설정에 지정된 DNS에 더 이상 의존하지 않습니다. 이 모듈의 핵심 설정 항목으로는 enhanced-mode(해석 모드), nameserver(상위 DNS), fallback(대체 DNS), 그리고 fake-ip 관련 필터 규칙 활성화 여부가 있습니다. 이 항목들의 역할을 이해하는 것이 트래픽 분기 이상과 DNS 유출을 진단하는 전제 조건입니다.
설명: dns.enable이 켜져 있고 클라이언트가 시스템 프록시나 TUN 모드로 트래픽을 넘겨받는 상태여야만 DNS 모듈이 실제로 요청을 가로챌 수 있습니다. 시스템 프록시를 거치지 않고 DNS 설정만 켜면 효과가 제한적입니다.
fake-ip와 redir-host, 두 모드의 선택 기준
Clash의 enhanced-mode는 두 가지 값을 지원하며, 동작 원리와 적합한 사용 시나리오가 크게 다릅니다. 모드를 잘못 선택하면 트래픽 분기 이상이나 접속 실패 문제의 원인이 되는 경우가 많습니다.
fake-ip 모드
클라이언트가 특정 도메인을 조회하면 DNS 모듈은 실제로 이 도메인을 해석하지 않고, 사전에 정해둔 주소 범위(예: 198.18.0.1/16)에서 가상의 IP를 하나 골라 시스템에 반환합니다. 애플리케이션은 이 가짜 IP로 연결을 시도하고, Clash는 TCP/UDP 연결을 수립하는 시점에 이 가짜 IP로 원래 도메인을 역조회해 규칙 엔진에 넘겨 어떤 프록시 경로를 사용할지 판단합니다. 실제 도메인 해석은 이 단계에서 비로소 이루어집니다. 이 방식의 장점은 어떤 상위 DNS에도 실제 접속 기록이 유출되지 않는다는 점과, 규칙 엔진이 해석된 IP가 아니라 원본 도메인을 받으므로 규칙 매칭이 더 정확하다는 점입니다. 단점은 가짜 IP와 도메인 간의 매핑 테이블에 의존한다는 점으로, 클라이언트 IP를 엄격히 검증하는 일부 서비스, 로컬 네트워크 기기 검색 프로토콜, 그리고 실제 해석 결과가 필요한 일부 시나리오(예: 일부 다운로드 프로그램의 멀티스레드 속도 측정)에서 이상 동작이 발생할 수 있습니다. 이런 경우 fake-ip-filter로 해당 도메인을 가짜 IP 대상에서 제외하고 실제 해석을 사용하도록 해야 합니다.
redir-host 모드
이 모드에서는 DNS 모듈이 설정된 상위 서버로 도메인을 실제 IP로 바로 해석해 시스템에 반환하므로, 클라이언트는 실제 주소를 받게 됩니다. 이 모드는 초기 투명 프록시(iptables REDIRECT, TPROXY) 환경에서 사용되던 방식으로, 투명 프록시는 IP 연결만 가로채고 도메인을 알지 못하므로 프록시 서버가 Host 헤더나 SNI로 목적지 도메인을 복원해 규칙과 매칭해야 했습니다. 이 모드의 한계도 뚜렷합니다. 실제 해석 결과가 Clash에 설정된 상위 DNS를 거치기 때문에 상위 서버를 잘못 고르면 해석된 IP가 실제로 가까운 노드와 일치하지 않을 수 있어 CDN 다중 라우팅 서비스에 불리합니다. 또한 클라이언트가 실제 IP를 그대로 받기 때문에 IP 대역 기반 탐지 방식에 프록시 흔적이 더 쉽게 노출됩니다.
종합해 보면, 요즘 주류 방식은 fake-ip를 기본으로 사용하고 실제 IP가 정말 필요한 극히 드문 경우에만 fake-ip-filter로 부분적인 예외를 두는 것이며, 전체를 redir-host로 전환하지는 않습니다. redir-host는 도메인 스니핑 기능이 없는 오래된 투명 프록시 체인에 더 적합하며, 일반 사용자가 TUN 모드나 시스템 프록시 모드를 쓸 때는 거의 필요하지 않습니다.
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- '*.lan'
- '*.local'
- 'localhost.ptlogin2.qq.com'
- 'time.*.com'
- 'ntp.*.com'상위 DNS 서버 선정 원칙
nameserver 항목은 도메인을 최종적으로 어떤 서버로 해석할지 결정하고, fallback 항목은 대체 해석 소스로 사용되며 보통 fallback-filter의 지역 판단과 함께 쓰입니다. 상위 DNS를 선택할 때는 다음 원칙들을 참고할 수 있습니다.
- 암호화를 지원하는 프로토콜을 우선 사용합니다. 일반적인 평문 UDP 53번 포트 조회는 중간 네트워크 노드에 관찰되거나 조작될 수 있으므로, 여건이 되면
DoH(DNS over HTTPS)나DoT(DNS over TLS)를 우선 설정합니다. 형식은 각각https://도메인/dns-query와tls://도메인:853입니다. - 국내와 해외 해석 경로를 구분합니다. 중국 본토 사이트에 접속할 때는 중국 본토의 퍼블릭 DNS를 사용해 해석 속도와 CDN 근접 효과를 보장하고, 해외 사이트에 접속할 때는 해외 또는 암호화 DNS를 사용해 중국 본토 DNS의 해석 결과가 적합하지 않은 노드를 가리키는 일을 피합니다. 이 작업은 보통
nameserver-policy로 도메인 접미사에 따라 분기하거나,fallback-filter.geoip로 해석 결과가 중국 본토 IP 대역인지 판단해 적용 여부를 결정하는 방식으로 이루어집니다. - 프록시 노드가 위치한 지역과 해석 서버 지역이 심하게 어긋나는 조합은 피합니다. 모든 도메인을 일괄적으로 해외 DNS로 해석하면 중국 본토 사이트가 접속에 불리한 노드로 해석되어 접속이 느려지거나 캡차가 자주 뜨는 문제가 생길 수 있습니다.
- 최소 하나의 fallback을 유지합니다. 기본 DNS에 접속할 수 없거나 타임아웃이 발생해도 fallback이 해석이 끊기지 않도록 보장해 줍니다. 주 서버와 백업 서버는 서로 다른 통신사나 프로토콜을 사용해 동시에 장애가 나는 상황을 피하는 것이 좋습니다.
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://doh.pub/dns-query
- tls://223.5.5.5:853
fallback:
- https://1.1.1.1/dns-query
- tls://8.8.4.4:853
fallback-filter:
geoip: true
geoip-code: CN
nameserver-policy:
'geosite:cn': 'https://doh.pub/dns-query'
'geosite:geolocation-!cn': 'https://1.1.1.1/dns-query'위 예시의 아이디어는 기본적으로 중국 본토 암호화 DNS를 사용하고, 해외 도메인 분류(geosite 규칙 세트)에 해당하면 해외 DNS로 전환하며, 동시에 fallback-filter로 해석된 IP가 중국 본토 주소 대역인지 최종적으로 판단해 도메인 분류 데이터베이스가 제때 업데이트되지 않아 생기는 오판을 방지하는 것입니다. 이 조합은 중국 본토 사이트의 접속 속도와 해외 사이트의 올바른 트래픽 분기를 대체로 함께 만족시킵니다.
DNS 요청이 프록시를 우회해 유출되는지 확인하기
DNS 모듈을 설정한 뒤에는 요청이 실제로 Clash를 거치고 시스템 기본 리졸버를 거치지 않는지 실제 방법으로 확인해야 합니다. 자주 쓰이는 방법은 다음과 같습니다.
방법 1: 클라이언트 연결 로그 확인하기
대부분의 Clash GUI 클라이언트(Clash Verge, Mihomo Party, FlClash 등)에는 연결 로그나 활성 연결 패널이 있으며, 정상적인 경우 프록시를 거친 모든 연결에서 IP만 노출되지 않고 대상 도메인이 함께 표시됩니다. 만약 다수의 항목에서 도메인 없이 IP만 표시된다면, 해당 요청이 프록시 엔진에 도달하기 전에 도메인 정보가 이미 사라졌다는 뜻입니다. 대개 요청을 보낸 애플리케이션이 시스템 프록시 범위에 포함되지 않았거나, 해당 애플리케이션이 시스템 프록시 설정을 거치지 않는 직접 연결 방식을 사용하기 때문입니다. 이런 트래픽은 TUN 모드로 전환해 일괄적으로 처리하는 것이 좋습니다.
방법 2: 패킷 캡처로 평문 DNS 트래픽 유출 확인하기
패킷 캡처 도구(Wireshark나 커맨드라인의 tcpdump 등)로 UDP 53번 포트와 흔히 쓰이는 DoH 포트를 필터링해, 로컬 네트워크 인터페이스에서 Clash에 설정되지 않은 상위 서버로 나가는 조회 패킷이 있는지 확인합니다. 프록시가 켜진 상태에서도 시스템 네트워크 설정에 지정된 통신사 DNS 주소로의 조회 기록이 잡힌다면 우회 유출이 존재한다는 뜻이며, 시스템 프록시가 UDP 트래픽까지 처리하고 있는지, 아니면 TUN 모드로 전환해 네트워크 계층의 모든 트래픽을 처리해야 하는지 확인해야 합니다.
방법 3: 커맨드라인에서 해석 결과 직접 비교하기
터미널에서 시스템 기본 리졸버와 Clash에 지정된 상위 서버를 각각 사용해 같은 도메인을 해석하고, 반환된 IP가 일치하는지, 요청에 걸린 시간이 예상 경로와 맞는지 비교합니다.
# 시스템 기본 리졸버 사용
nslookup example.com
# 서버를 강제로 지정해 해석, 결과 일치 여부 비교
nslookup example.com 223.5.5.5fake-ip를 켠 상태에서 시스템 기본 도구로 도메인을 조회하면 실제 공인 IP가 아니라 fake-ip-range 범위 안의 주소가 나오는 것이 정상입니다. 이는 가짜 IP 메커니즘이 정상 동작하고 있다는 뜻이며 해석 실패를 의미하지 않습니다.
방법 4: 온라인 DNS 유출 검사 페이지 이용하기
브라우저에서 전용 DNS 유출 검사 사이트에 접속하면 실제로 해석 요청을 보낸 서버 정보가 나열됩니다. 정상적인 경우 설정된 상위 DNS나 해당 암호화 해석 노드만 표시되어야 합니다. 목록에 로컬 네트워크 통신사의 해석 서버 정보가 나타난다면 일부 트래픽이 프록시를 거치지 않고 직접 조회하고 있다는 뜻이므로, 시스템 프록시 범위, TUN 모드 활성화 상태, 또는 브라우저 자체에 별도의 DoH 설정이 켜져 있어 Clash의 DNS 모듈과 충돌을 일으키는지 다시 확인해야 합니다.
흔한 오해: 일부 브라우저에 내장된 보안 DNS 기능은 시스템 프록시를 우회해 지정된 암호화 DNS 서버에 직접 연결하므로, Clash 설정이 올바르더라도 도메인 조회가 프록시를 건너뛰게 됩니다. 유출을 점검할 때는 브라우저 자체의 DNS 설정이 꺼져 있는지, 아니면 시스템을 따르도록 설정되어 있는지도 함께 확인해야 합니다.
자주 발생하는 설정 문제와 진단 방법
실제 사용 중 겪는 DNS 관련 문제는 대부분 다음 몇 가지 유형에 집중되어 있으며, 하나씩 확인하면 빠르게 원인을 찾을 수 있습니다.
- 규칙 매칭이 정확하지 않은 경우. 대부분
redir-host를 사용했거나fake-ip를 켜지 않아서, 규칙 엔진이 원본 도메인이 아니라 해석된 IP를 받게 되어 도메인 기반 규칙이 무력화된 경우입니다.fake-ip로 되돌리면 대체로 해결됩니다. - 로컬 네트워크 기기끼리 서로 발견하거나 접속할 수 없는 경우. 이는
fake-ip모드의 대표적인 부작용으로, 로컬 네트워크 관련 도메인(예:*.lan, 라우터 관리 도메인)을fake-ip-filter에 추가해 해당 요청이 가짜 IP 대신 실제 해석을 사용하도록 해야 합니다. - 중국 본토 사이트 접속이 느려지거나 추가 인증이 뜨는 경우. 보통 중국 본토 도메인이 해외 DNS로 해석되어 적합하지 않은 IP가 나온 경우이므로,
nameserver-policy나fallback-filter의 지역 판단이 올바르게 설정되어 있는지 확인해야 합니다. - 해석이 오랫동안 타임아웃되는 경우. 설정된 상위 DNS 서버 자체에 접속이 가능한지 확인합니다. 암호화 프로토콜(DoH/DoT)은 일부 네트워크 환경에서 방해를 받을 수 있으므로, 우선 평문 UDP 서버로 바꿔 프로토콜 자체의 문제인지 확인한 뒤 암호화 설정을 유지할지 결정합니다.
- 시스템 프록시 모드에서 UDP 기반 애플리케이션(게임, 영상 통화)의 해석이 비정상적인 경우. 시스템 프록시는 보통 TCP 트래픽만 처리하며, 일부 DNS 조회를 포함한 UDP 요청은 제어되지 않을 수 있습니다. 이런 상황에서는 TUN 모드를 직접 사용해 네트워크 계층에서 모든 프로토콜의 트래픽과 해석 요청을 일괄 처리하는 것을 권장합니다.
DNS 모드를 올바르게 선택하고 상위 서버를 지역별로 분기해 설정한 다음, 연결 로그, 패킷 캡처, 온라인 검사라는 세 가지 방법으로 교차 검증하면 해석 경로가 프록시를 우회하지 않았는지 대체로 확인할 수 있으며, 규칙 엔진도 트래픽 분기 판단에 필요한 정확한 도메인 정보를 확보할 수 있습니다.