DNS 유출이란 무엇이며 왜 Meta 코어에서 특히 중요한가
일반적으로 말하는 DNS 유출은 사용자가 기대하는 경로가 아닌 리졸버로 질의가 나가는 현상을 뜻합니다. 시스템이 ISP 기본 DNS를 쓰고 있거나, 특정 앱이 프록시를 무시하고 직접 53번 포트로 묻는 경우, 혹은 브라우저만 Secure DNS를 켜 두고 나머지 트래픽은 다른 스택을 타는 경우 등이 대표적입니다. Clash Meta에서는 rules가 도메인·IP·GEOIP로 분기하지만, 질의가 먼저 어디로 갔는지에 따라 매칭 결과 자체가 달라질 수 있어, “노드는 맞는데 사이트만 이상하다”는 증상으로 나타나기 쉽습니다.
따라서 DNS는 단순한 “부가 옵션”이 아니라 규칙 엔진의 입력 데이터를 만드는 전단입니다. Rule Provider로 가져온 목록과의 정합성을 높이려면 ACL4SSR·Loyalsoldier 규칙 가이드에서 다룬 분기 정책과 함께, 이 글의 DNS 설계를 같은 축에서 생각하는 것이 좋습니다.
Meta 코어에서 DNS가 거치는 기본 파이프라인
개략적으로, 클라이언트는 설정 파일의 dns 블록에 따라 어떤 업스트림에 질의할지, FakeIP 풀을 쓸지, 폴백 순서를 결정합니다. 동시에 스니퍼(sniffer)가 켜져 있으면 TLS SNI·HTTP Host 등에서 도메인을 복원해 규칙 매칭을 돕기도 합니다. 이 세 가지(업스트림, FakeIP, 스니퍼)는 서로 독립이 아니라, 한쪽이 과하면 다른 쪽에서 부작용이 드러나는 구조입니다. 예를 들어 FakeIP를 쓰면서 업스트림을 과도하게 많이 두면 캐시·지연이 불안정해질 수 있고, 스니퍼 없이 FakeIP만 켜 두면 일부 앱에서 호스트 정보가 부족해 규칙이 엇나갈 수 있습니다.
전체 YAML 구조와 필드 의미를 한눈에 보고 싶다면 문서·설정 허브의 링크를 함께 두고 읽는 것을 권장합니다. 여기서는 DNS 블록에 집중합니다.
FakeIP: 가짜 응답으로 로컬 분기를 앞당기기
FakeIP 모드는 도메인에 대해 로컬 대역의 가짜 IP를 먼저 돌려주고, 실제 연결이 일어날 때 코어가 다시 도메인 정보와 매핑해 아웃바운드로 보내는 방식입니다. 이렇게 하면 “먼저 진짜 DNS로 나가서 IP를 받고 나서야 프록시 규칙이 적용된다”는 순서를 바꿀 수 있어, 규칙 기반 분기와의 궁합이 좋아지는 경우가 많습니다. 다만 로컬의 다른 프로그램이 FakeIP 주소를 그대로 캐시해 버리면 혼란이 생길 수 있으므로, 운영체제·앱별로 DNS 캐시를 비우는 습관이 필요합니다.
설정 예시(개념 정리용)
아래는 교육용으로 축약한 예시이며, 실제 프로필에서는 구독·규칙·프로바이더 이름에 맞게 조정해야 합니다.
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://dns.example/dns-query#PROXY
- tls://dns.example:853#PROXY
fallback:
- https://dns.public/dns-query
fallback-filter:
geoip: true
geoip-code: KR참고: #PROXY 같은 태그는 프로필에 정의된 그룹 이름과 일치해야 하며, 업스트림 URL은 신뢰할 수 있는 제공자를 사용하세요.
DoH와 DoT: 암호화된 업스트림 선택 기준
DNS over HTTPS(DoH)는 HTTPS 위에 DNS를 실어 보내고, DNS over TLS(DoT)는 전용 TLS 연결로 853 포트를 쓰는 방식입니다. Meta 코어에서는 보통 https:// 접두사로 DoH, tls:// 접두사로 DoT를 지정합니다. 어느 쪽이 “더 안전”하다고 단정하기보다, 자신의 네트워크에서 막히지 않는지, 지연과 안정성, 신뢰할 수 있는 운영 주체를 기준으로 고르는 편이 현실적입니다. 회사망·캠퍼스망에서는 특정 DoH 도메인이 필터링되는 경우가 있어, 이때는 DoT나 다른 포트 정책을 시험해 봐야 합니다.
업스트림을 여러 개 두었다면 nameserver-policy로 도메인별로 다른 리졸버를 태우는 방법도 있습니다. 국내 CDN은 국내 리졸버로, 해외 전용 도메인만 암호화 DNS로 보내는 식의 분할은 지연과 실패율을 동시에 다루는 데 유리할 수 있습니다. 반대로 정책이 지나치게 복잡하면 디버깅이 어려워지므로, 처음에는 최소 구성에서 시작해 로그로 확인하는 것이 좋습니다.
TUN 모드와 tun.dns-hijack
시스템 전역으로 트래픽을 끌어올릴 때는 앱이 “시스템 DNS 설정”을 우회하지 않도록 53번 UDP/TCP를 코어 쪽으로 하이재킹하는 설정이 중요합니다. Meta 계열 클라이언트에서는 tun.dns-hijack에 any:53 등을 지정하는 패턴이 자주 쓰입니다. 이 부분이 빠지면 FakeIP·DoH를 아무리 YAML에 적어도, 특정 프로세스의 질의만 터널 밖으로 새어 나갈 수 있습니다. 단계별 활성화와 주의사항은 Clash Verge Rev TUN 모드 가이드에 정리되어 있으니, 전역 모드를 쓰는 경우 함께 맞춰 보세요.
스니퍼·규칙과의 정합성
FakeIP를 쓰는 환경에서는 스니퍼가 꺼져 있을 때 도메인 기반 규칙이 기대대로 동작하지 않는 경우가 있습니다. 반대로 스니퍼를 과하게 믿고 규칙을 느슨하게 두면, 예상치 못한 호스트명이 잡혀 분기가 흔들릴 수도 있습니다. 운영 관점에서는 “한 번에 완벽한 프리셋”보다 로그에서 어떤 도메인이 어떤 체인으로 처리됐는지를 확인하는 루프가 더 중요합니다. 브라우저의 Secure DNS와 클라이언트 DNS를 동시에 강하게 켜 두면 이중 경로가 생기기 쉬우니, 테스트할 때는 한쪽만 남기고 비교하는 방식이 안전합니다.
점검 순서와 흔한 오해
- 모드 확인:
redir-host와fake-ip중 무엇을 쓰는지 먼저 고정합니다. - 업스트림 도달성: DoH/DoT URL이 현재 네트워크에서 막히지 않는지 확인합니다.
- TUN 사용 시:
tun.dns-hijack과 방화벽 예외가 충돌하지 않는지 봅니다. - 앱별 예외: 일부 게임·스토어 클라이언트는 자체 DNS를 고집합니다. 증상이 앱 한정이면 그 경로를 의심합니다.
- 캐시: OS·브라우저 DNS 캐시를 비운 뒤 다시 측정합니다.
“한 줄짜리 마법 설정”보다 변수를 하나씩 줄여 가는 방식이 장기적으로 시간을 아껴 줍니다. 노드 속도만 바꿔서는 해결되지 않는 클래스의 문제가 바로 DNS·로컬 정책 충돌입니다.
주의: 공용 DNS 목록은 언제든 바뀔 수 있습니다. 예시 URL은 반드시 자신이 신뢰하는 제공자의 최신 문서로 교체하세요.
GitHub·소스 코드에 대해
Mihomo·Clash 파생 클라이언트의 라이선스, 이슈 트래커, 릴리스 노트는 GitHub에서 확인하는 것이 자연스럽습니다. 다만 설치 패키지를 받는 주 경로는 보안 안내와 일관성을 위해 사이트 다운로드 페이지를 우선하는 습관을 권장합니다. 소스와 릴리스는 투명성 확인용으로 두고, 일상적인 설치·업데이트는 공식 배포 채널을 따르면 혼선이 줄어듭니다.
정리
Meta 코어에서 DNS 유출을 줄이려면 FakeIP 여부, DoH·DoT 업스트림의 실제 도달성, TUN 시 DNS 하이재킹, 스니퍼·규칙과의 정합성을 한 세트로 보아야 합니다. 이 중 하나만 어긋나도 “프록시는 켜졌는데 해석만 이상하다”는 상태가 길게 이어질 수 있습니다. 비슷한 목적의 도구를 여러 겹 쌓기보다, 한 클라이언트 안에서 프로필을 정리하고 로그로 행동을 확인하는 편이 운영 부담이 훨씬 작습니다. 같은 노드라도 DNS 설계가 맞으면 체감 안정성이 달라지는 경우가 많습니다.