Clash Meta(mihomo)에서 DoH를 설정하고 fake-ip 분기와 맞추기: Windows·macOS 실무 순서 (2026)

1. DoH를 코어 안에 두는 이유와 fake-ip와의 관계

DoH는 일반 DNS 패킷 대신 HTTPS로 질의를 보내 ISP나 공용 와이파이에서의 스니핑·변조 가능성을 줄이려는 방식입니다. Clash Meta에서는 상류 해석기를 dns.nameserver, 장애·오탐 대비용으로 dns.fallback 등에 나열하고, 코어가 직접 요청을 만듭니다. 사용자 입장에서는 「운영체제 설정 앱에 DoH를 넣었다」와 「YAML에 https://…/dns-query를 넣었다」가 비슷해 보이지만, 후자는 mihomo가 규칙·정책과 같은 프로세스 안에서 DNS를 처리한다는 점이 큽니다.

fake-ip 모드에서는 많은 이름에 대해 먼저 가짜 주소 풀에서 응답을 내고, 실제 연결 시점에 상류와 매핑을 맞춥니다. 그래서 애플리케이션이 반드시 Clash가 제공하는 DNS 리스너를 바라보는 전제가 강합니다. 이때 브라우저가 자체 보안 DNS(DoH)로 Cloudflare나 Google에 직접 물어보면, 화면에는 잘 열려도 DOMAIN-SUFFIX 줄이 기대대로 안 먹는 것처럼 보일 수 있습니다. 즉 DoH를 YAML에 넣는 것과 「전 구간에서 Clash DNS를 쓰게 만드는 것」은 별도 작업입니다.

2. YAML에서 DoH 한 줄 쓰는 법(nameserver·fallback)

mihomo 계열에서는 보통 https://호스트/경로 형식으로 DoH 엔드포인트를 적습니다. 프로바이더 문서에 맞는 전체 URL을 쓰고, 자체 인증서를 쓰는 내부 서버가 아니라면 기본 TLS 검증을 유지하는 편이 안전합니다. nameserver에는 평소 쓰는 상류를, 중국 대륙 등 특정 조건에서만 다른 서버를 타게 하려면 fallback과 fallback-filter, 또는 도메인별로 nameserver-policy를 씁니다.

구독 베이스 YAML 위에 덮어쓰기를 할 때는 머지 순서를 확인하세요. 같은 키가 아래쪽 설정에서 덮이면 의도한 DoH가 빠질 수 있습니다. 여러 프로필을 합치는 패턴은 프로필 병합 글과 함께 보는 것이 좋습니다.

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query
  fallback:
    - https://dns.quad9.net/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
  # optional: per-domain upstream
  nameserver-policy:
    "+.corp.example.com": tls://dot.example.com

위 예시의 서버 목록은 설명용입니다. 거주 지역·공항 정책·회사 방화벽에 맞게 바꾸세요. 일부 네트워크는 비표준 포트나 특정 DoH 주소만 막으므로, 막혔을 때를 대비해 tls://(DoT)나 평문 UDP 상류를 fallback에 섞는 선택도 있습니다.

3. fake-ip와 함께 맞출 때 체크할 옵션

DoH를 새로 넣었다고 해서 fake-ip-range나 fake-ip-filter를 반드시 바꿀 필요는 없지만, 다음은 빠지기 쉬운 부분입니다. 첫째, LAN 호스트명·mDNS·사내 도메인 등은 가짜 응답과 충돌할 수 있어 필터에 포함하는 경우가 많습니다. 둘째, STUN·일부 게임·영상 통화는 즉시 진짜 주소가 필요할 수 있습니다. 셋째, IPv6가 동시에 활성화되어 있으면 AAAA 경로가 규칙과 따로 놀 수 있으므로 IPv6·TUN 교정 글과 교차 확인하는 편이 안전합니다.

HTTPS 연결에서 도메인 대신 IP만 보여 DOMAIN 규칙이 비는 느낌이 들면 DNS만 건드리기보다 Sniffer·SNI 설정을 함께 봐야 합니다. 해당 흐름은 HTTPS Sniffer 글에서 다룹니다.

• listen 주소: 다른 DNS 클라이언트와 53번 포트가 겹치면 한쪽이 실패합니다. GUI가 로컬 전용 포트를 쓰는 경우도 있어 문서를 확인하세요.
• prefer-h3 등 실험적 옵션은 환경별로 편차가 큽니다. 불안정하면 끄고 단순 구성으로 되돌려 테스트하세요.
• fallback 지연: 상류 DoH가 느리면 체감 지연이 커집니다. 로그에서 타임아웃이 반복되면 지역 가까운 미러나 DoT로 바꿔 보세요.

4. Windows: 시스템·브라우저와 순서대로 정렬

Windows 10·11에서는 「설정 → 네트워크」에서 NIC별 DNS가 박혀 있고, 브라우저는 또 다른 DoH 스위치를 가집니다. Clash 계열 GUI(시스템 프록시 또는 TUN)를 켠 뒤에도 브라우저 보안 DNS가 켜져 있으면 질의 일부가 코어를 우회합니다. 권장 순서는 다음과 같습니다.

1. 클라이언트에서 DNS 하이재킹·시스템 DNS 위임·TUN 중 문서가 안내하는 방식을 활성화합니다. 메뉴 이름은 제품마다 다르지만 목표는 「일반 앱의 질의가 로컬 리스너로 들어오게 하는 것」입니다.
2. Chrome·Edge 설정에서 보안 DNS를 사용 안 함으로 두거나, Clash와 같은 상류를 쓰도록 조정합니다. 자세한 클릭 경로는 전용 글을 따르세요.
3. 윈도우 설정 앱의 「암호화된 DNS」가 켜져 있으면 충돌할 수 있으므로, 테스트 단계에서는 끄고 증상을 비교합니다.
4. 방화벽에서 클라이언트와 코어 프로세스의 로컬 수신을 허용했는지 확인합니다. 사설 프로필만 허용되어 있으면 공용 네트워크에서 DNS 리스너가 막힐 수 있습니다.

시스템 프록시만 쓰고 TUN을 끈 상태에서는 일부 데스크톱 앱이 프록시를 무시하고 시스템 DNS로 직행하는 경우가 있습니다. 그럴 때는 TUN 모드를 검토하거나, 해당 앱에 프록시 환경 변수를 명시합니다. Windows 전반 설정은 Verge Rev Windows 글과 맞춰 읽으면 흐름이 이어집니다.

5. macOS: 네트워크 DNS와 클라이언트(TUN) 동선

macOS는 Wi-Fi 프로필마다 DNS 서버 목록이 있고, 일부 VPN·보안 제품이 자체 DNS를 주입합니다. Clash Meta 기반 앱을 켠 뒤에도 시스템이 여전히 라우터가 준 ISP DNS를 쓰면, 일부 프로세스만 코어 밖으로 새 나갑니다. 설정 순서를 단순화하면 다음과 같습니다.

1. 클라이언트에서 시스템 프록시·TUN·DNS 보조 옵션을 켭니다. 메뉴명은 앱마다 다르지만, 목표는 동일합니다.
2. 시스템 설정의 네트워크에서 활성 인터페이스 DNS가 이상하게 고정되어 있으면, 테스트 동안 자동(DHCP)으로 되돌리거나 127.0.0.1을 가리키도록 바꿉니다. 단, 클라이언트가 요구하는 값이 있으면 그 안내를 우선합니다.
3. Safari·Chrome 등에서 별도 DoH 확장이나 「보안 DNS」류 기능을 쓰고 있다면 잠시 끄고 재현 여부를 비교합니다.
4. iCloud 프라이버티 릴레이나 다른 VPN과 동시에 켜 두면 DNS 순서가 꼬일 수 있으므로, 문제 재현 시에는 한 번에 하나의 터널만 켭니다.

Apple Silicon과 Intel 모두에서 동일한 논리가 적용됩니다. 메뉴바 아이콘만으로는 DNS 위임이 안 된 경우도 있어, 코어 로그에 질의가 찍히는지 반드시 확인하세요. 맥에서 시스템 프록시와 TUN을 처음 맞출 때는 macOS 프록시·TUN 글을 함께 보는 것을 권합니다.

6. 적용 후 확인과 흔한 오류

설정을 고친 뒤에는 브라우저 캐시만 지우는 것으로는 부족하고, 실제로 DNS 질의가 mihomo로 들어왔는지를 봐야 합니다. 클라이언트 로그에서 문제 도메인을 검색하고, 동시에 어떤 규칙 줄에 매칭됐는지 확인합니다. 아무 질의도 없으면 앱이 다른 해석기를 쓰는 것입니다.

7. 자주 묻는 질문