1 언제 Mihomo DNS를 redir-host로 두는가
Clash Meta(Mihomo)에서 DNS enhanced-mode는 대략 두 갈래로 이해하면 됩니다. 하나는 fake-ip로 애플리케이션이 보는 주소를 가짜 대역으로 통일해 규칙 엔진과의 정렬을 쉽게 하는 방식이고, 다른 하나는 redir-host로 실제 A/AAAA 응답을 유지한 채 연결 단계에서 흐름을 맞추는 방식입니다. 게임·증권·일부 음성 앱처럼 소켓이 받은 IP에 민감한 프로그램이 있거나, 내부망 호스트명을 자주 쓰는 환경에서는 fake-ip 대신 redir-host를 택하는 사례가 많습니다. 반대로 규칙 분기가 복잡하고 앱 호환만 허용된다면 fake-ip 쪽이 운영이 단순한 경우도 있습니다. 이 글은 «fake-ip를 전 구간에 쓰기 어렵다」는 전제에서 redir-host DNS만 다룹니다.
redir-host를 쓰면 애플리케이션은 통상적인 리졸버 응답을 받습니다. 그래서 상류 DNS가 무엇인지, 비정상 응답이 왔을 때 어디로 재질의할지가 곧바로 체감 품질로 이어집니다. 특히 통신사나 캠퍼스에서 특정 도메인에 대해 조작된 응답을 돌려주는 경우, 단일 리졸버만 두면 «브라우저는 되는데 API만 실패» 같은 증상이 남습니다. 이때 nameserver와 fallback을 분리하고 fallback-filter로 조건부 전환을 거는 패턴이 자주 쓰입니다.
2 nameserver와 fallback이 나뉘는 이유
Mihomo의 DNS 플러그인은 질의를 받으면 우선 nameserver에 적힌 서버들로 해석을 시도합니다. 응답이 fallback-filter 조건에 걸리면 fallback 목록으로 넘깁니다. 즉 nameserver는 일상적인 1차 상류이고, fallback은 필터에 걸린 «의심 응답»을 다시 물을 2차 상류입니다. 이 둘을 한 배열에만 넣어 두면 필터가 기대대로 동작하지 않거나, 모든 질의가 느린 서버로만 새는 구성이 되기 쉽습니다.
default-nameserver는 이름이 헷갈리기 쉬운데, DoH·DoT처럼 TLS·HTTPS 형태의 상류 자체가 다른 호스트 이름을 풀어야 붙을 수 있는 경우에 필요한 «최소 직통」 상류입니다. 이걸 비워 두면 부팅 직후 첫 질의에서 상류 선택이 불안정해지거나, 특정 OS/클라이언트 조합에서 간헐적으로 실패하는 패턴이 나올 수 있습니다. UDP 기반 공인 DNS를 하나 이상 여기에 두는 방식이 흔한 출발점입니다.
3 1단계: default-nameserver로 부트스트랩 고정
먼저 dns.enable: true를 켠 뒤 enhanced-mode: redir-host를 명시합니다. listen은 127.0.0.1:1053처럼 로컬에서만 듣는 주소를 쓰는 경우가 많고, 이미 다른 리졸버가 같은 포트를 쓰면 충돌하므로 OS와 GUI 클라이언트 설정을 함께 확인합니다. 그다음 default-nameserver에 지연은 있어도 신뢰할 수 있는 평문 DNS를 둡니다. 예를 들면 지역에 맞는 공인 리졸버를 UDP·TCP 형식으로 적습니다. 이 단계의 목적은 «TLS·HTTPS 상류의 호스트 이름을 누가 먼저 풀 것인가」를 안정화하는 것이지, 최종 사용자 응답 속도를 최우선으로 하라는 뜻은 아닙니다.
구독 프로필이 이미 dns 블록을 포함하고 있다면 동일 키가 중복 정의될 수 있습니다. GUI에서는 «프로필 병합 순서»나 mixin 규칙에 따라 나중 값이 앞을 덮습니다. redir-host로 바꿨는데도 동작이 fake-ip처럼 보이면, 실제로 로딩된 통합 설정에서 enhanced-mode가 무엇으로 해석되는지를 로그나 내보내기 기능으로 한 번 확인하는 것이 안전합니다.
4 2단계: nameserver에 일상 상류 배치
nameserver에는 평소 대부분의 도메인을 맡길 서버를 둡니다. 지연과 필터링 정책이 다른 서버를 한꺼번에 나열하기보다, 실패율과 응답 시간을 로그로 본 뒤 2–4개 정도로 압축하는 편이 디버깅에 유리합니다. DoH URL을 쓰면 전송 구간 암호화 이점이 있지만, 엔드포인트 자체가 막힌 환경에서는 오히려 첫 질의부터 막히는 경우가 있으니 그때는 tls://나 평문으로 한 단계 낮추는 선택도 고려합니다.
nameserver-policy는 특정 도메인 접미사나 정규식에 대해 별도 상류를 강제할 때 씁니다. 회사 VPN 뒤의 내부 존, 스트리밍 CDN, 특정 국가 전용 authoritative가 필요한 호스트 등은 여기서 분기하면 fallback으로 과도하게 넘어가는 것을 줄일 수 있습니다. 정책이 너무 세분화되면 관리 부담이 커지므로, 먼저 기본 nameserver와 fallback-filter만으로 해결되는지 확인한 뒤 점진적으로 추가하는 것을 권합니다.
5 3단계: fallback과 fallback-filter
fallback에는 1차 응답이 필터에 걸렸을 때 재시도할 서버를 둡니다. 지리적 위치가 다른 공인 리졸버, 혹은 검열 우회에 강한 경로를 택하는 경우가 많습니다. 다만 모든 질의가 fallback으로만 나가도록 filter 조건을 과하게 넓히면 지연만 커집니다. geoip: true와 geoip-code 조합은 «이 국가 코드로 돌아온 응답은 신뢰하지 않는다»는 식으로 쓰이는데, 거주 지역과 실제 트래픽 패턴에 맞게 조정해야 합니다. 중국 본토 직접 트래픽을 쓰지 않는다면 해당 키를 단순화하거나 생략하는 편이 나을 수도 있습니다.
ipcidr 목록은 블랙홀·더미 대역을 지정해 «이런 답이면 fallback으로」 같은 실무 규칙을 넣을 때 씁니다. domain 조건을 지원하는 빌드라면 특정 키워드 응답만 재질의하도록 좁힐 수 있습니다. 설정을 바꾼 뒤에는 반드시 로그에서 어느 단계에서 어떤 상류가 선택됐는지를 확인하세요. 클라이언트마다 로그 키워드 표기가 조금씩 다를 수 있으나, «DNS » 또는 «failed to resolve」 계열 메시지를 기준으로 삼으면 됩니다.
6 통합 예시: redir-host + nameserver / fallback 분리
아래는 교육용 출발점입니다. 서버 주소·필터·지역 코드는 반드시 본인 환경에 맞게 바꿔야 하며, 특정 공인 DNS를 추천하는 것이 아니라 구조를 보여 주기 위한 예입니다. IPv6를 쓰지 않으면 ipv6: false로 AAAA 노이즈를 줄이는 경우가 많습니다.
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: redir-host
default-nameserver:
- 223.5.5.5
- 119.29.29.29
nameserver:
- https://dns.example/dns-query
- tls://dns.example:853
fallback:
- https://dns.fallback.example/dns-query
- tls://8.8.8.8:853
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
- 0.0.0.0/32
예시의 dns.example 같은 호스트는 실제로 존재하지 않을 수 있으니, 사용 중인 안내서나 제공자 문서의 엔드포인트로 교체해야 합니다. nameserver-policy를 덧붙여 내부 접미사만 직통 DNS로 보내고 싶다면 다음과 같이 확장할 수 있습니다.
nameserver-policy:
"+.corp.example":
- 10.0.0.53
"geosite:private":
- system
system 키워드 지원 여부는 빌드와 클라이언트에 따라 다릅니다. 지원되지 않으면 OS 리스너 주소를 직접 적거나, 내부 리졸버 IP를 명시하세요. 헤드리스 Linux에서는 systemd 연동 가이드의 기본 템플릿을 기준으로 dns 블록만 교체해도 같은 원리가 적용됩니다.
7 예외와 운영 팁
redir-host에서도 IPv6 AAAA가 우회 경로를 만들면 «규칙은 IPv4만 본 것 같은데 실제 연결은 IPv6로 간다»는 상황이 생깁니다. 환경에 따라 ipv6: false로 막거나, 방화벽에서 IPv6를 일관되게 처리하세요. 또한 브라우저 Secure DNS가 켜져 있으면 OS가 Clash 리스너를 우회하는 경우가 있어, 문제 재현 시에는 확장·브라우저 DNS·OS 스텁을 순서대로 끄며 비교하는 것이 좋습니다.
규칙 세트가 GEOIP나 GEOSITE에 많이 의존한다면, DNS 응답 IP의 국가 코드가 기대와 다를 때 분기가 흔들립니다. 이는 redir-host에서 특히 두드러지므로, 장기적으로는 과도한 지리 기반 의존을 줄이고 도메인 규칙을 보강하는 편이 안정적입니다. 연결 로그 분석 절차는 로그·DNS 트러블슈팅 글과 함께 보면 원인 분리가 빨라집니다.
8 자주 보는 증상과 점검 순서
- 첫 질의만 실패:
default-nameserver가 비었거나 막혔는지 확인합니다. - 특정 사이트만 무한 로딩: 해당 도메인 응답이 필터에 걸려 fallback으로 넘어가는지, 혹은
nameserver-policy가 없어 잘못된 상류를 쓰는지 봅니다. - 지연 폭증: fallback이 기본 경로처럼 자주 타는지 로그로 확인하고 filter 조건을 좁힙니다.
- 내부 호스트만 깨짐: 사설 접미사를 policy로 내부 DNS에 붙였는지, VPN split DNS와 충돌하지 않는지 확인합니다.
한 번에 여러 클라이언트를 겹쳐 쓰면 어떤 프로세스가 로컬 DNS 포트를 잡았는지조차 헷갈리기 쉽습니다. 가능하면 단일 코어 + 단일 프로필로 증상을 재현한 뒤 설정을 옮기세요.
9 짧은 질문과 답
redir-host에서도 DoH를 쓰면 되나요?
됩니다. 다만 DoH URL의 호스트를 풀 bootstrapping이 필요하므로 default-nameserver를 함께 두는 구성이 일반적입니다. 엔드포인트가 프록시 뒤에서만 열리는 환경이면 순환 의존을 피하기 위해 직통 가능한 상류를 하나 남겨 두세요.
fake-ip로 돌아가면 이 설정을 그대로 쓰나요?
상류 목록 자체는 재사용할 수 있지만 enhanced-mode를 바꾸면 fake-ip-range, fake-ip-filter 같은 키가 추가로 필요합니다. 모드 전환 후에는 클라이언트 재시작과 캐시 flush를 한 번씩 하는 편이 안전합니다.
10 정리
Mihomo에서 redir-host를 쓸 때는 nameserver와 fallback을 역할에 맞게 나누고, fallback-filter가 과도하게 동작하지 않게 조정하는 것이 핵심입니다. default-nameserver로 DoH·DoT 부트스트랩을 고정한 뒤, 일상 상류와 보조 상류를 로그 기반으로 다듬으면 해석 이상이 크게 줄어듭니다. 더 넓은 DNS·유출 주제는 FakeIP·DoH 가이드를 참고하면 됩니다.
일부 GUI나 라우터 패키지는 DNS 화면이 단순해 보이지만, 결국 동일한 YAML 키를 덮어씁니다. 반대로 설정 파일만 덤으로 보는 앱은 규칙·DNS·TUN을 한 코어에서 다루지 못해 증상이 생길 때 원인 추적이 더 오래 걸리는 경우가 있습니다. 프로필 편집·구독 동기·플랫폼 패키지를 한 곳에서 비교하려면 다운로드 허브를 쓰는 편이 낫습니다. redir-host처럼 상류 DNS를 손으로 맞춰야 하는 순간에, Mihomo 기반 클라이언트는 로그와 YAML 편집 경로가 열려 있어 운영 부담이 상대적으로 적은 편입니다. 여러 단편 앱을 번갈아 쓰며 증상만 덮는 방식보다, 한 코어에 nameserver 체인을 고정해 두고 노드·규칙만 바꾸는 쪽이 장기적으로 안정적입니다.