무엇을 해결하려는 설정인가
rules에서 프로시·직접 연결을 나눠도, 첫 질의가 어느 리졸버로 갔는지에 따라 돌아오는 A·AAAA 레코드가 달라집니다. 해외 공용 DoH 하나에만 의존하면 국내 사이트가 먼 유럽 엣지로 붙었다가 느려지거나, 반대로 국내 리졸버만 쓰면 특정 글로벌 API가 필터링된 응답을 주는 식의 해석 경로 불일치가 남을 수 있습니다. nameserver-policy는 바로 이 지점에서 도메인 접두·접미 규칙이나 geosite 라벨을 키로 삼아 업스트림 목록을 덮어 씌웁니다.
Clash Meta·Mihomo 계열에서 이 키는 dns 블록 안에 있으며, GUI가 별도 필드로 빼 주지 않는 경우가 많아 원시 YAML 편집이 잦습니다. 서브스크립션 템플릿이 이미 긴 dns 덩어리를 가져오고 있다면, mixin·프로필 병합 순서를 헷갈리지 않도록 한 번에 합친 결과만 믿지 말고 실제 로딩된 설정을 Export 해 확인하는 습관이 안전합니다.
언제 기본 nameserver만으로는 부족한가
nameserver 항목은 “특별한 정책이 없을 때 어디로 묻는가”의 기본열입니다. 여기서 두세 개의 DoH를 적어 두어도, 그것만으로는 도메인 클래스마다 다른 신뢰도·지리 최적화를 동시에 만족시키기 어렵습니다. 예를 들어 국내 포털 계열과 해외 클라우드 콘솔을 같은 해외 리졸버에 보내면, 체감 지연이 아니더라도 규칙에서 DIRECT로 빼 준 트래픽이 실제 패킷 경로와 맞지 않는 이상한 조합이 됩니다.
또 다른 패턴은 보안 정책입니다. 회사 VPN 아래에서는 특정 DoH 호스트가 차단되지만, 다른 호스트만 통과할 때가 있습니다. 이때 정책 테이블로 살아 있는 경로만 골라 붙이는 것이 장애 시간을 줄입니다. 마지막으로 테스트 목적입니다. 새 레코드 전파나 분산 CDN 변경을 볼 때, 동일 브라우저 세션에서도 업스트림만 바꿔 비교할 수 있게 분리해 두면 재현이 빨라집니다.
nameserver-policy 문법 감각
핵심은 맵 형태입니다. 왼쪽은 매칭 키, 오른쪽은 그 질의에 쓸 서버 문자열 배열입니다. 도메인 계열에서는 종종 +.example.com처럼 앞에 더하기를 붙여 하위 도메인까지 포함합니다. 단일 호스트만 지정하고 싶으면 더하기 없이 적을 수 있습니다. 대량 분류에는 geosite:cn 같은 태그가 자주 등장하는데, 이는 규칙에서 쓰는 것과 같은 데이터 소스 계열입니다.
값 목록 안의 각 줄은 nameserver와 같은 표기법을 따릅니다. 즉 https://로 DoH를, tls://로 DoT를 지정합니다. 문자열 끝에 #프록시그룹이름을 붙이면 해당 질의 채널을 노드가 대신 여는 패턴을 만들 수 있습니다. 다만 여기서 실수하면 자기 참조 DNS(프록시가 DNS를 타려는데 DNS가 다시 같은 프록시를 필요로 함)가 나올 수 있으므로, 최소 한 줄은 순환 없이 도달 가능한 경로로 두는 편이 좋습니다.
교육용 축약 예시
아래는 개념을 보여 주기 위한 예시입니다. 실제 엔드포인트는 신뢰하는 제공자 문서로 교체하고, 프로필 안의 아웃바운드 이름과도 일치시켜야 합니다.
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://dns.example-global/dns-query
nameserver-policy:
geosite:cn:
- https://dns.example-cn/dns-query
- tls://dns.example-cn-alt:853
'+.cdn-provider.example':
- https://dns.example-edge/dns-query#DIRECT
'+.internal.corp':
- tls://10.0.0.53:853참고: 내부 IP DoT처럼 터널 밖으로 그대로 나가야 하는 경로가 있다면, 그에 맞게 rules의 DIRECT·TUN 범위가 뒷받침되는지 함께 봐야 합니다.
분할을 쌓는 권장 순서
- 기본열 고정: 먼저
nameserver에 “어느 경우에도 최소 한 번은 성공해야 하는” 업스트림을 둡니다. 전부 해외만 있으면 국내 필터링 환경에서 첫 부팅이 괴로울 수 있습니다. - 가장 넓은 geosite부터: 국내 직통 대역처럼 면적이 큰 묶음을 먼저 policy에 올립니다. 나중에 예외 도메인을
+.특정행으로 덧씌우기 쉽습니다. - 좁은 서픽스로 덮기: CDN·모바일 앱 API처럼 문제를 일으키는 소수 도메인만 별도 DoH로 옮깁니다. 여기까지가 “해석 분기”의 80퍼센트입니다.
- 프록시 태그 점검:
#PROXY류를 붙인 줄이 루프를 만들지 않는지 확인합니다. 막히면 타임아웃이 전체 DNS에 전염되듯 보이기도 합니다. - 재시작 후 한 도메인씩 검증: 캐시를 비운 뒤 대시보드 로그에서 질의와 응답 지연이 바뀌는지 확인합니다.
DoH를 고를 때 현실적인 기준
공용 목록을 그대로 복사해 붙이기보다, 지연·필터 정책·로그 보존 정책을 제공자 공지에서 읽고 고릅니다. 운영자 입장에서는 “가장 빠른 Ping”보다 “장애 때 응답이 절제되는 방식”이 더 큰 차이를 만드는 경우가 많습니다. 또한 ECS(클라이언트 서브넷)나 QNAME 최소화 같은 세부 기능이 트래픽 경로에 영향을 줄 수 있으니, 같은 사이트라도 업스트림을 바꾸면 POP이 달라지는 현상은 이상이 아니라 기대 가능한 결과일 수 있습니다.
암호화 DNS는 스니핑 위험을 줄이지만 리졼 자체의 가시성은 남습니다. 민감한 이름을 정책으로 쪼개고 싶다면 도메인 단위 분리가 의미 있고, 단순히 “국내 빠르게”가 목표라면 지리에 강한 리졼을 geosite 행에 두는 편이 낫습니다.
fake-ip-filter·규칙과의 정렬
FakeIP 모드를 쓰면 많은 이름이 로컬 대역으로 매핑되지만, 어떤 이름은 진실한 IP가 필요합니다. 이때 쓰는 것이 fake-ip-filter입니다. 반면 nameserver-policy는 여전히 어떤 업스트림으로 실제 질의를 보낼지를 고릅니다. 즉 “FakeIP에서 빼 낼 이름”과 “그 이름을 어디 DNS로 보낼지”는 다른 레버입니다. 한쪽만 만지고 속도 문제를 호소하면 원인 추적이 꼬입니다.
규칙 파일과의 정렬도 중요합니다. GEOIP나 PROCESS 규칙이 DIRECT인데 해석만 해외로 나가면, 브라우저 입장에서는 빠른 노드를 타도 첫 SYN까지 시간이 길어집니다. 반대로 PROXY 그룹인데 국내 리졼만 고집하면 노드 위치와 레코드가 어긋납니다. 세 벌의 표(규칙, DNS 정책, fake-ip-filter)를 같은 테이블에 적어 두고 변경하면 세 줄을 동시에 고치는 방식이 유지 보수에 유리합니다. 필터 목록 작성에는 fake-ip-filter 설명 글을 참고할 수 있습니다.
TUN·하이재킹과 함께 검증하기
데스크톱 클라이언트에서 전역 모드를 열면 OS가 던지는 53번 UDP가 코어 밖으로 빠져나가지 않도록 tun.dns-hijack 설정이 필요합니다. 이 글의 초점은 nameserver-policy이지만, 질의 자체가 코어에 들어오지 않으면 아무리 정책 표를 예쁘게 적어도 효과가 없습니다. 절차는 Clash Verge Rev TUN 가이드와 함께 보시길 권합니다.
검증 루틴은 간단합니다. 문제 도메인 하나를 고르고, 정책 적용 전후로 코어 로그의 업스트림 선택 로그를 비교합니다. 브라우저 확장 프로그램 Secure DNS와 클라이언트 DNS가 동시에 켜져 있으면 경로가 갈라져 피곤해지므로, 테스트 순간에는 한쪽만 남기고 재측정합니다.
자주 나오는 함정
- 중복된 dns 블록: 구독본과 로컬 오버레이가 합쳐지며 키가 덮였는데 모르는 상태입니다.
- 오타 난 그룹 이름:
#GROUP태그가 실제 존재하지 않으면 조용히 실패하기도 합니다. - 지나치게 긴 체인: 정책 행마다 서버를 열 두 개 이상 두면 타임아웃 누적이 됩니다. 꼭 필요한 이중화만 두세요.
- geosite 의존만: 라벨이 비어 있거나 늦게 갱신되면 예상과 다른 기본열로 떨어집니다.
짧게 묻는 질문
정책이 없으면 어디로 가나요?
매칭되는 policy 키가 없으면 nameserver·fallback 등 기본 경로가 이어집니다. 따라서 정책을 비우거나 잘못 지우면 “기본열로 되돌아갔는지”를 먼저 의심합니다.
규칙 프로바이더와 같이 써도 되나요?
네. 다만 목적이 다릅니다. Rule Provider가 L3·L7 트래픽 아웃바운드를 고른다면, nameserver-policy는 DNS 계층에서 먼저 갈림을 만듭니다. 대규모 목록 운영 관점에서는 ACL4SSR·Loyalsoldier 비교 글도 함께 읽어 갱신 주기를 맞추는 것이 좋습니다.
정리
nameserver-policy는 “한 벌의 DNS”로는 부족한 도메인·지역 기반 분기를 Clash Meta·Mihomo 안에서 표현하는 도구입니다. 기본열·geosite·서픽스 예외·프록시 태그를 순서대로 쌓고, FakeIP 필터와 규칙, TUN 하이재킹까지 한 번에 검증하면 대부분의 체감 이슈를 빠르게 좁힐 수 있습니다. DNS 전반이 걱정된다면 앞서 인용한 유출 방지 글과 짝으로 읽으면 맥락이 더 선명해집니다.
문자열만 만지던 옛 클라이언트에 비해 Meta 계열은 정책 옵션이 많아졌지만, 그만큼 GUI 한 화면에 다 올라오지 않습니다. 반복 가능한 편집 흐름과 로그 확인이 가능한 패널을 쓰면 시행착오 비용이 줄어듭니다. 아직 클라이언트를 고르지 않았다면 Clash 공식 다운로드 페이지에서 Meta 코어 기반 빌드를 받아 위 예시를 그대로 옮겨 테스트해 보세요.