Clash Meta DNS에서 fake-ip와 redir-host를 고를 때: 분기 실패 증상 대조와 mihomo 로그로 맞추기 (2026)

1. DNS 모드가 규칙(분기)과 얽히는 이유

Clash는 연결을 만들기 전에 이름을 IP로 바꾸는 단계가 있습니다. 시스템·앱이 Clash의 로컬 DNS(또는 TUN이 붙은 스택)를 쓰면, 그 DNS 응답과 rules에서 보는 키(도메인·IP·지오IP 등)가 같은 「줄」에 서야 합니다. 그런데 브라우저 DoH나 OS의 다른 해석기를 타면, Clash 밖에서 이미 IP가 정해진 뒤 트래픽만 들어오기 때문에 DOMAIN-SUFFIX 같은 규칙이 기대대로 매칭되지 않거나, 매칭은 됐는데 실제 목적지와 어긋난 것처럼 보일 수 있습니다.

fake-ip는 Clash가 이름을 가짜 IPv4 대역으로 빠르게 돌려주고 내부에 도메인 매핑을 쌓는 방식이라, 앱이 Clash를 DNS로 쓰는 전제가 강합니다. redir-host는 상류 DNS에서 받은 실제 A/AAAA를 그대로 돌려주는 쪽에 가까워, 「규칙은 도메인으로 잡고 싶은데 IP 기반 규칙도 섞어 쓴다」 같은 구성과의 상대 관계가 달라집니다. 둘 중 어느 쪽이든 DNS 경로와 프록시 모드(시스템 프록시 vs TUN), fallback 순서가 틀어지면 체감 증상은 비슷하게 「분기가 깨진 것」으로 나타납니다.

2. fake-ip: 빠른 가짜 응답과 도메인 일치

enhanced-mode: fake-ip를 켜면 Clash는 많은 이름 질의에 대해 지정된 풀(예: 198.18.0.0/15)에서 응답을 내고, 실제 연결 시점에 도메인을 다시 풀어 연결합니다. 장점은 응답이 매우 빠르다는 점과, 앱이 Clash DNS를 일관되게 쓸 때 도메인 기반 규칙과의 정렬이 잘 맞는 경우가 많다는 것입니다.

반대로 패널티도 있습니다. UDP STUN, 일부 게임·통화·LAN 서버처럼 「이름이 실제로 즉시 실제 IP여야 하는」 트래픽은 가짜 응답과 충돌할 수 있어, 보통 fake-ip-filter에 도메인·루트 존·geoip:private류 예외를 넣습니다. 예외가 부족하면 「특정 앱만 자꾸 실패한다」 패턴이 납니다.

또 한 가지, HTTPS는 애플리케이션 레이어에서 SNI로 서버 이름을 실어 보냅니다. DNS 단계에서는 도메인이 보였는데 이후 TLS에서만 IP로 보이는 환경이라면, DOMAIN 규칙이 비는 것처럼 느껴질 수 있습니다. 이때는 DNS 모드만 바꾸기보다 Sniffer와 규칙 순서를 함께 보는 편이 안전합니다.

3. redir-host: 실제 해석과 IP 기반 규칙

enhanced-mode: redir-host는 상류 nameserver에서 받은 결과를 Clash가 처리하는 흐름에 가깝습니다. 「가짜 IP 풀」을 쓰지 않으므로 fake-ip-filter는 그대로 fake-ip 전용 이슈는 줄어듭니다. 대신 이름 해석이 상류 DNS 품질·지연·필터링에 더 민감해지고, IP-CIDR·GEOIP 같이 주소로 판단하는 규칙과의 관계를 규칙 목록 순서와 함께 더 의식해야 합니다.

사용자 입장에서 흔한 오해는 「redir-host면 무조건 분기가 정확해진다」인데, 실제로는 Clash 밖 DNS 누수나 이중 스택 AAAA 때문에 기대와 다른 출구가 나올 수 있습니다. IPv6가 동시에 켜진 환경에서는 AAAA가 직행으로 빠지며 규칙이 건너뛰어지는 것처럼 보이기도 하므로, 증상이 IPv4만의 문제가 아닌지 IPv6·TUN 글과 교차해 보는 것이 좋습니다.

4. 어떤 때 어느 쪽을 택하면 좋은가

엄격한 한 줄 규칙은 없고, 클라이언트가 Clash DNS를 일관되게 쓰는지가 먼저입니다. 대부분의 GUI 프로필은 기본이 fake-ip인 경우가 많고, 도메인 규칙 중심 구독과 잘 맞습니다. 반면 특정 앱이 fake-ip와 충돌하거나, 운영자가 GEOIP·CIDR을 앞세운 보수적 분기를 선호하면 redir-host를 실험해 볼 만합니다. 어느 쪽이든 dns.nameserver·fallback·nameserver-policy가 비어 있거나 순서만 복사해 온 상태면 둘 다 불안정합니다.

고급 라우팅 가이드에서 말하는 것처럼 규칙은 위에서 아래로 스캔됩니다. DNS 모드를 바꿨다면 「도메인 규칙이 먼저인지, IP·GEOIP가 먼저인지」를 다시 읽어야 합니다. 같은 YAML이라도 DNS 모드에 따라 매칭되는 줄이 달라 보이는 것이 정상입니다.

5. 흔한 증상과 원인 가설

아래는 실무에서 자주 듣는 패턴과, DNS·라우팅 쪽에서 먼저 의심할 가설입니다. 한 가지에만 고집하지 말고 로그로 확인하세요.

6. mihomo 로그로 순서대로 확인

클라이언트에 따라 패널 이름은 다르지만, 코어 로그에는 보통 DNS 질의, 선택된 policy/outbound, rules hit 힌트가 남습니다. 다음 순서를 추천합니다.

1. 문제 재현 직후 같은 호스트로 DNS가 Clash로 들어왔는지 확인합니다. 아예 질의가 없으면 앱·OS가 다른 해석기를 쓰는 것입니다. 보안 DNS를 잠시 끄고 대조해 보세요.
2. 같은 시각에 어느 줄 규칙에 걸렸는지, 어떤 노드/출구로 나갔는지 로그에 찍히는지 봅니다. 찍히지 않으면 로그 레벨을 올려 보거나, API·패널의 연결 상세를 사용합니다.
3. HTTPS인데 도메인 대신 IP만 보이면 Sniffer 허용 목록과 충돌·우선순위를 점검합니다. 자세한 해석은 Sniffer 글을 따릅니다.
4. rule-providers·GEOIP 자체가 비어 있거나 갱신 실패면 규칙이 통째로 어색해집니다. 규칙·GEOIP 갱신 글로 경로와 권한을 먼저 확인하세요.

7. 수정 절차 체크리스트

아래를 위에서부터 적용해 보세요. 한 단계씩 바꾼 뒤 재현 테스트를 하는 편이 원인 고립에 유리합니다.

• 앱·OS가 Clash DNS를 쓰도록 시스템 프록시·TUN·「시스템 DNS 위임」 옵션을 클라이언트 문서대로 맞춥니다.
• 브라우저·OS의 DoH/타 써드파티 DNS를 끄거나, Clash와 충돌하지 않는지 확인합니다.
• fake-ip 사용 시 fake-ip-filter에 LAN·필수 서비스·문제 앱 도메인을 추가해 대조합니다.
• redir-host로 바꿔 보고 같은 증상인지 확인합니다. 증상이 반대로 바뀌면 DNS·규칙 순서 가설이 강해집니다.
• nameserver와 fallback, 필요 시 nameserver-policy를 정리해 오탐·누락을 줄입니다. DoT/DoH 상류가 막힌 네트워크면 폴백이 비정상 동작할 수 있습니다.
• IPv6가 의심되면 이중 스택 글과 같이 AAAA·직행을 점검합니다.

8. YAML 스니펫: DNS 블록 정렬

아래는 이해를 돕기 위한 예시입니다. 상류 서버·정책 이름은 본인 환경에 맞게 바꾸고, GUI를 쓰면 동일 키가 프로필 머지 어디에 쓰이는지 확인하세요. 구독 가져오기로 받은 베이스 YAML 위에 오버라이드하는 순서도 흔한 원인입니다.

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip  # or redir-host
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
    - geoip:private
    # add STUN / game / LAN host patterns as needed
  nameserver:
    - 223.5.5.5
    - tls://dns.quad9.net
  fallback:
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

enhanced-mode만 바꾸고 nameserver 구성을 그대로 두면 체감이 거의 없을 수 있습니다. 반대로 모드는 그대로 두고 상류 DNS·폴백 조건만 고쳐서 지역 판정이 바로잡히는 경우도 많습니다.