mihomo DNS 설정 가이드: nameserver, fallback 및 fake-ip DNS 가로채기

먼저 DNS 업스트림, 응답 모드, 요청 가로채기를 구분하세요

mihomo의 DNS 설정은 세 가지 단계로 나뉩니다. 요청을 어디서 받는지, 어떤 업스트림에 질의하는지, 애플리케이션에 어떤 주소를 반환하는지입니다. nameserver와 fallback은 업스트림 조회를 담당하고, enhanced-mode는 실제 주소와 fake-ip 매핑 중 사용할 방식을 결정합니다. tun.dns-hijack은 조건에 맞는 DNS 트래픽을 내장 DNS 리졸버로 전달합니다. 세 단계는 서로 연관되어 있지만 서로를 대체할 수는 없습니다.

설정 파일에 DNS 주소를 입력했다고 해서 브라우저가 반드시 그 주소를 사용하는 것은 아닙니다. 시스템은 여전히 라우터에 질의할 수 있고, 브라우저가 자체 DoH로 암호화된 DNS 조회를 할 수도 있습니다. 문제를 진단할 때는 먼저 요청이 mihomo에 전달되는지 확인한 다음 업스트림의 연결 가능 여부를 살펴보세요.

설정 항목	주요 역할	혼동하기 쉬운 점
`dns.listen`	로컬 DNS 수신 주소를 지정합니다	시스템 DNS를 자동으로 변경하지 않습니다
`nameserver`	기본 DNS 업스트림을 지정합니다	프록시 노드 목록이 아닙니다
`fallback`	응답을 선별할 때 사용할 다른 업스트림을 지정합니다	기본 업스트림 시간 초과 시 재시도하는 서버만을 뜻하지 않습니다
`fallback-filter`	도메인이나 응답 IP 주소를 기준으로 결과를 선별합니다	웹 연결에 사용할 프록시 노드를 직접 결정하지 않습니다
`enhanced-mode`	`fake-ip` 또는 `redir-host` 선택	TUN을 활성화한다는 뜻은 아닙니다
`tun.dns-hijack`	조건에 맞는 DNS 요청을 가로챕니다	임의의 DoH나 DoT를 직접 복호화할 수 없습니다

nameserver와 default-nameserver: DNS 업스트림과 초기 조회

nameserver는 기본으로 사용할 DNS 업스트림 목록입니다. 일반 DNS나 지원되는 DoH 등의 주소를 입력할 수 있습니다. 일반 DNS 예시는 223.5.5.5, DoH 예시는 https://dns.alidns.com/dns-query입니다. DoH는 DNS 서버와 주고받는 조회 트래픽을 암호화할 뿐, 애플리케이션 연결이 자동으로 프록시를 사용하도록 보장하지는 않습니다.

default-nameserver는 왜 필요한가요?

업스트림 주소를 도메인으로 지정했다면 커널이 먼저 해당 DNS 서버의 IP 주소를 알아야 합니다. 예를 들어 dns.alidns.com에 연결하려면 이 도메인부터 조회해야 합니다. default-nameserver는 이 초기 조회에 사용됩니다. IP 주소를 직접 지정하면 “DNS 서버 주소를 확인하려고 같은 DNS 서버에 먼저 접속해야 하는” 순환 문제를 피할 수 있습니다.

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.alidns.com/dns-query
    - https://doh.pub/dns-query

127.0.0.1:1053은 로컬 기기에서만 요청을 받으며, LAN 기기에 DNS 서비스를 노출하지 않습니다.
redir-host는 실제 조회 주소를 애플리케이션에 반환하므로, 첫 번째 연결 테스트의 기준으로 적합합니다.
ipv6: false는 내장 DNS가 AAAA 조회에 빈 응답을 반환하게 합니다. 운영체제의 IPv6를 끄거나 애플리케이션이 기존 IPv6 주소로 직접 연결하는 것을 막지는 않습니다.
업스트림을 여러 개 등록했다고 해서 위에서 아래 순서로 하나씩 엄격하게 시도한다는 뜻은 아닙니다. 목록 순서에 따라 도메인을 분기하는 방식에 의존하지 마세요.

위 내용은 노드와 프록시 규칙을 포함하지 않는 독립적인 dns 설정 예시입니다. 구독 설정 전체를 이 예시로 바꾸지 말고 기존 설정에 합쳐 사용하세요. 네트워크에서 특정 DNS 서비스를 차단한다면 현재 네트워크에서 실제로 접속할 수 있는 업스트림으로 바꿔야 합니다.

fallback과 fallback-filter: 단순한 예비 서버가 아닌 응답 선별 기능

fallback은 nameserver가 작동하지 않을 때만 쓰인다고 오해하기 쉽습니다. 실제로 fallback을 설정하면 커널이 두 업스트림 그룹에 동시에 질의한 뒤 fallback-filter로 어느 쪽 응답을 사용할지 판단할 수 있습니다. 따라서 평소에도 fallback 조회가 보인다고 해서 기본 업스트림에 문제가 생겼다는 뜻은 아닙니다.

일반적으로 기본 업스트림에서는 로컬 네트워크에 적합한 응답을 처리하고, 특정 도메인에 fallback을 지정했거나 기본 업스트림의 응답 주소가 필터 조건에 맞지 않을 때 fallback 응답을 사용합니다. 이 과정은 DNS 응답을 선택하는 단계이며, 이후 연결에는 프록시 규칙이 별도로 적용됩니다.

GeoIP와 IP 대역 필터를 사용하는 예시

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.alidns.com/dns-query
  fallback:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - '+.google.com'

geoip: true와 geoip-code: CN을 함께 설정하면 GeoIP 데이터로 기본 업스트림의 응답 주소가 지정한 지역에 속하는지 판별합니다. 조건에 맞지 않으면 fallback 응답을 우선 사용할 수 있습니다.
기본 업스트림이 반환한 주소가 ipcidr 목록과 일치하면 fallback 응답을 사용합니다. 예시의 240.0.0.0/4는 주소 필터 조건이며, 노드 대역이나 TUN 주소 풀을 뜻하지 않습니다.
domain에 지정된 도메인은 fallback 응답을 사용합니다. +.google.com은 해당 도메인과 모든 하위 도메인에 일치합니다.
GeoIP 판별은 커널이 사용하는 데이터에 따라 달라집니다. 데이터베이스가 오래되었거나 CDN이 여러 지역에 분산되어 있으면 예상과 다른 업스트림이 선택될 수 있습니다.

모든 사설 IP 주소를 오염된 응답으로 간주하지 마세요. 사내 도메인이 10.0.0.0/8을 반환하거나 가정용 기기가 192.168.0.0/16을 반환하는 것은 정상일 수 있습니다. 이 대역을 모두 ipcidr에 추가하면 내부 도메인이 오히려 공용 DNS로 전달될 수 있습니다. 명확한 사내 도메인은 fallback 필터 범위를 넓히기보다 전용 업스트림을 지정하는 편이 좋습니다.

fake-ip와 redir-host: 매핑 주소와 실제 주소 중 무엇을 반환할까요?

enhanced-mode: fake-ip는 도메인에 주소 풀 안의 매핑 주소를 할당합니다. 애플리케이션이 해당 주소로 연결하면 트래픽이 mihomo에 전달되고, 커널은 매핑을 통해 원래 도메인을 확인한 뒤 규칙을 적용합니다. 애플리케이션에서 실제 IP를 조회할 필요를 줄일 수 있지만, 연결이 실제로 커널에 전달되어야 합니다.

redir-host는 실제 조회 주소를 반환하고 관련 도메인 정보도 유지합니다. 일반적인 DNS 동작에 더 가깝지만 도메인과 IP 주소가 항상 일대일로 대응하는 것은 아닙니다. 연결에서 도메인을 식별하는 방식은 트래픽 가로채기 방식, 캐시, 스니핑 설정에도 영향을 받습니다. 어느 모드도 올바른 프록시 규칙을 대신할 수는 없습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - localhost
    - '*.lan'
    - '*.local'
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

fake-ip-filter에는 어떤 도메인을 추가해야 하나요?

일반적인 블랙리스트 필터 모드에서는 fake-ip-filter에 일치하는 도메인에 fake-ip를 할당하지 않고 실제 주소를 반환합니다. 예시는 로컬 기기와 LAN 이름을 예외로 처리하는 방법을 보여줍니다. 설정에서 fake-ip-filter-mode를 별도로 지정했다면 필터 모드를 먼저 확인하세요. 여기서 설명한 동작이 그대로 적용된다고 가정하면 안 됩니다.

LAN 기기 검색, 일부 게임, 실제 IP가 필요한 애플리케이션은 구체적인 도메인을 예외로 추가하세요. 범위가 지나치게 넓은 와일드카드 규칙은 피하는 것이 좋습니다.
필터는 응답 방식만 바꿀 뿐, printer.lan을 라우터에 자동으로 전달하지 않습니다. 내부 네트워크 이름을 조회하려면 해당 이름을 확인할 수 있는 로컬 업스트림이 필요합니다.
.local은 mDNS와 관련된 경우가 많습니다. 이를 필터 목록에 추가해도 mihomo가 멀티캐스트 검색을 프록시하거나 화면 미러링 문제를 자동으로 해결하지는 않습니다.
198.18.x.x가 보인다고 해서 DNS 응답이 오염되었다고 판단하지 마세요. 이 예시에서는 예상된 fake-ip 응답입니다. 실제 확인 사항은 연결이 커널에 전달되어 도메인을 복원할 수 있는지입니다.

fake-ip에서 redir-host로 전환하거나 반대로 바꾼 뒤에는 시스템 DNS 캐시를 비우고 테스트 중인 애플리케이션을 다시 시작하세요. 브라우저에 이전 매핑 주소가 남아 있으면 설정을 바꿨는데도 연결이 이전 주소를 계속 사용하는 것처럼 보일 수 있습니다.

TUN DNS 가로채기: 53번 포트 요청을 내장 DNS로 전달

“fake-ip 가로채기”라는 표현에는 흔히 두 개념이 섞여 있습니다. fake-ip는 응답 모드이고 DNS 가로채기는 요청을 리디렉션하는 기능입니다. 아래 최상위 tun 설정은 앞에서 소개한 dns 예시 중 하나와 합쳐 TUN으로 들어오는 조건에 맞는 UDP 및 TCP 53번 포트 요청을 가로챕니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53은 UDP DNS에, tcp://any:53은 TCP DNS에 사용합니다. 여기서 53은 일치시킬 트래픽의 목적지 포트입니다. 앞에서 나온 dns.listen의 1053은 로컬 테스트용 수신 포트이며 둘을 같은 값으로 설정할 필요는 없습니다. 커널은 조건에 맞는 요청을 내장 DNS로 전달합니다. 시스템이 먼저 1053에 직접 접속해야 한다는 뜻은 아닙니다.

활성화해도 가로채지 못할 수 있는 트래픽

브라우저 DoH: 일반적으로 HTTPS 443번 포트를 사용하므로 일반적인 53번 포트 DNS 요청에 해당하지 않습니다. 진단 중에는 브라우저의 보안 DNS를 잠시 끄고, 테스트가 끝난 뒤 필요에 따라 다시 켜세요.
애플리케이션 내장 DoT: 흔히 목적지 포트로 853을 사용합니다. 위의 두 규칙만으로는 내장 DNS 요청으로 변환되지 않습니다.
TUN에 들어오지 않는 트래픽: 라우팅 제외, 다른 VPN, 네트워크 인터페이스 선택, 플랫폼 제한 때문에 요청이 가로채기 경로를 우회할 수 있습니다.
LAN 기기: 컴퓨터에서 TUN을 켜도 전체 네트워크의 DNS 게이트웨이가 되는 것은 아닙니다. 다른 기기의 게이트웨이, DNS, 트래픽 전달 경로는 각각 설정해야 합니다.

시스템 프록시만 사용하는 경우 브라우저의 HTTP 요청은 프록시를 통과하더라도 시스템 DNS는 라우터에서 처리될 수 있습니다. 이는 dns.enable이 작동하지 않는 문제가 아니라 요청이 내장 DNS로 전달되지 않은 상황입니다. 사용 방식에 맞춰 시스템 DNS 지정, TUN 가로채기 또는 명시적인 다른 리디렉션 방식을 선택해야 합니다.

내부 네트워크 도메인과 프록시 노드 도메인 조회

가정용 NAS, 사내 서비스, 공용 도메인은 보통 같은 DNS 경로를 공유하기에 적합하지 않습니다. mihomo의 nameserver-policy를 사용하면 도메인별로 업스트림을 지정할 수 있으며, 일반적인 nameserver 및 fallback 조합보다 우선 적용됩니다. 아래 설정은 기존 dns 아래에 추가하세요. 예시에서는 라우터 주소가 실제로 192.168.1.1이라고 가정합니다.

  nameserver-policy:
    '+.home.arpa':
      - 192.168.1.1
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

home.arpa는 가정용 네트워크에서 사용하는 로컬 도메인입니다. 라우터에 해당 레코드가 설정되어 있지 않다면 정책을 입력해도 조회 결과가 저절로 생기지 않습니다. fake-ip를 사용할 때 애플리케이션에 실제 내부 주소가 필요하다면 해당 도메인을 적절한 fake-ip 필터 규칙에도 추가해야 합니다.

proxy-server-nameserver는 프록시 노드 서버 자체의 도메인을 조회하는 설정이며, 모든 프록시 사이트의 도메인을 처리하지는 않습니다. 노드에 직접 연결할 수 있는 DNS 조회 경로를 제공하면 “DNS 업스트림은 프록시에 의존하고, 프록시는 연결에 DNS가 필요한” 순환 위험을 줄일 수 있습니다.

DNS 요청에 프록시 규칙을 적용하려면

respect-rules: true를 설정하면 DNS 업스트림 연결에도 라우팅 규칙을 적용할 수 있습니다. 이 설정을 사용할 때는 proxy-server-nameserver도 함께 구성하고 최종적으로 어떤 규칙이 선택되는지 확인하세요. DNS 실패를 해결하는 만능 스위치는 아닙니다. 노드 도메인 조회, 업스트림 연결, 규칙 선택이 서로 의존하면 각 주소가 개별적으로 올바르더라도 전체 구성이 시작되지 않을 수 있습니다.

수신, 조회, 가로채기, 규칙 순서로 설정 확인

문제를 진단할 때는 되돌릴 수 있는 설정을 따로 보관하고 한 번에 한 단계씩만 변경하세요. 먼저 redir-host로 실제 DNS 조회를 확인하고, 다음에 fake-ip를 테스트한 뒤 fallback이나 DNS 아웃바운드 규칙을 추가하면 모든 기능을 동시에 켜는 것보다 문제를 찾기 쉽습니다.

1단계: YAML 설정이 로드되었는지 확인

같은 계층에는 dns:를 하나만 두세요. 키가 중복되면 오류가 발생하거나 앞서 작성한 설정이 뒤의 설정으로 덮어써질 수 있습니다.
들여쓰기에는 Tab이 아닌 공백을 사용하세요. tun:과 dns:는 같은 계층의 키이므로 TUN 전체 설정을 DNS 안으로 들여쓰면 안 됩니다.
구독을 업데이트하면 로컬에서 수정한 설정이 덮어써질 수 있습니다. 지속적으로 사용할 설정은 클라이언트가 지원하는 덮어쓰기 기능에 넣고, 업데이트 후 최종 생성된 설정을 확인하세요.

2단계: 로컬 1053 포트에 직접 질의

dig를 사용할 수 있는 macOS 또는 Linux 환경에서는 아래 두 명령어로 UDP와 TCP를 각각 테스트할 수 있습니다. 도구가 설치되어 있지 않다면 해당 시스템의 패키지 관리 방법으로 설치하거나 DNS 포트를 지정할 수 있는 다른 조회 도구를 사용하세요.

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +tcp

redir-host 모드에서는 실제 조회 결과가 반환되어야 합니다. fake-ip 모드에서는 필터에 걸리지 않은 도메인에 보통 설정된 주소 풀의 매핑 주소가 반환됩니다. 두 명령어가 모두 시간 초과되면 프록시 규칙부터 바꾸지 말고 1053 수신 상태, 설정 로드 여부, 로컬 방화벽을 먼저 확인하세요. SERVFAIL이 반환되면 로그를 살펴 초기 조회, 업스트림 연결, 인증서 검증 문제를 확인하세요.

3단계: 시스템 DNS 요청이 커널에 전달되는지 확인

Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비우세요. systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행하면 됩니다. 그런 다음 테스트 브라우저를 완전히 종료했다가 다시 열어 애플리케이션 자체 캐시의 영향을 줄이세요. 1053에 직접 질의하면 성공하지만 일반 애플리케이션에서는 실패한다면 TUN 라우팅과 애플리케이션 자체 DNS를 중점적으로 확인하세요.

4단계: DNS 조회 성공과 연결 성공 구분

클라이언트 연결 기록에서 대상 도메인, 일치한 규칙, 아웃바운드 정책, 오류 로그를 확인하세요. DNS에서 주소를 반환했다는 것은 조회 단계가 끝났다는 뜻일 뿐입니다. 노드에 연결할 수 없거나, 규칙이 대상을 잘못된 경로로 보내거나, 대상 포트가 차단되어도 웹페이지가 열리지 않을 수 있습니다. fake-ip 주소에서 도메인을 복원할 수 있어도 선택한 프록시 노드가 정상이라는 의미는 아닙니다.

시스템 프록시, 포트 또는 TUN 환경을 더 확인하려면 문제 해결을 참고하세요. 구독을 처음 가져오거나 모드를 전환하는 순서는 설정 가이드에서 확인할 수 있습니다. DNS 설정은 현재 네트워크 경로에 맞춰야 하며, DNS 서버를 무작정 더 추가하는 방식으로 해결되지 않습니다.