Fake-IP와 redir-host 차이: mihomo DNS 강화 모드 원리와 설정 가이드
mihomo의 Fake-IP와 redir-host가 DNS 조회와 연결에 미치는 영향을 비교하고, fake-ip-filter의 용도와 호환성 문제를 알아봅니다.
DNS 강화 모드가 바꾸는 것
mihomo 설정에서 dns.enhanced-mode는 내장 DNS의 주소 조회 방식과 이후 연결에서 도메인을 연결하는 방식을 결정합니다. 주로 fake-ip와 redir-host를 사용합니다. 프록시 프로토콜이 아니며, 규칙 모드나 전역 모드 또는 TUN 설정과도 별개입니다.
두 모드를 이해하려면 세 가지 동작을 구분해야 합니다. 앱이 도메인을 조회하고, 운영체제가 연결을 시작하며, 코어가 규칙에 따라 아웃바운드를 선택합니다. DNS 응답 주소가 결정하는 것은 이 과정의 일부뿐입니다. 최종적으로 직접 연결할지 프록시를 사용할지는 규칙, 정책 그룹, 사용 가능한 아웃바운드에 따라 달라집니다.
Fake-IP: 가상 주소로 도메인 연결 정보 유지
DNS 조회부터 연결까지
- 앱이 가로채기 대상 DNS에 도메인의 A 레코드를 조회합니다.
- mihomo가 설정된 주소 풀에서 가상 IPv4 주소를 할당하고, 도메인과 가상 주소의 매핑을 저장합니다.
- 앱은 해당 주소를 받은 뒤 연결을 시작합니다. 연결은 이 매핑을 인식할 수 있는 동일한 코어로 다시 들어와야 합니다.
- 코어가 가상 주소에 해당하는 도메인을 찾아 규칙을 적용한 다음, 선택된 아웃바운드로 대상에 연결합니다.
예를 들어 주소 풀이 198.18.0.1/16으로 설정되어 있으면 앱은 해당 대역의 주소를 받을 수 있습니다. 이 대역은 벤치마크용으로 예약된 주소 공간이며, 대상 웹사이트의 공인 IP나 프록시 서버 주소가 아닙니다. 웹사이트의 고정 IP로 수동 등록하지 마세요.
Fake-IP는 웹사이트 콘텐츠를 위조하는 기능이 아닙니다. 연결이 코어에 도달하기 전에 도메인 정보를 유지하는 방식입니다. 여러 웹사이트가 같은 CDN IP를 사용하더라도 각각의 가상 주소로 도메인을 구분해 도메인 규칙을 적용할 수 있습니다.
DNS 조회 대기 시간이 줄어들 수 있는 이유
가상 주소를 반환할 때는 대상 도메인의 실제 A 레코드를 먼저 기다릴 필요가 없는 경우가 많습니다. 도메인 정보를 전달할 수 있는 프록시 아웃바운드라면 코어가 도메인을 원격지로 넘겨 처리할 수 있어 클라이언트에서 실제 주소를 조회하는 대기 단계를 줄일 수 있습니다. 일부 선행 대기 시간이 줄어드는 것이며, 모든 접속에서 DNS를 생략한다는 뜻은 아닙니다.
- 직접 연결 규칙에 해당하는 경우: 직접 연결을 설정하려면 보통 로컬에서 대상의 실제 주소를 알아야 합니다.
- IP 규칙에 해당하는 경우: 규칙 유형과 순서,
no-resolve사용 여부에 따라 규칙 판정에 DNS 조회가 필요할 수 있습니다. - 프록시 노드가 도메인을 사용하는 경우: 노드 자체도 DNS 조회가 필요하며, 대상 웹사이트의 Fake-IP 매핑으로 이를 해결할 수 없습니다.
- 첫 연결과 원격 네트워크: TCP·TLS 핸드셰이크, 노드 부하, 원격 DNS가 여전히 주요 지연 요인일 수 있습니다.
따라서 DNS 조회가 빨라져도 웹페이지가 반드시 빨리 열리는 것은 아닙니다. 노드 지연 시간 테스트를 DNS 소요 시간으로 간주하거나, 브라우저에서 처음 열 때의 체감만으로 모드의 우열을 판단하지 마세요.
redir-host: 실제 주소를 먼저 반환
redir-host를 사용하면 내장 DNS가 상위 DNS에 조회한 뒤 실제 응답 주소를 앱에 반환합니다. 코어는 DNS 캐시에 저장된 도메인과 주소의 관계를 활용해 이후 연결을 처리할 수 있지만, 여러 도메인이 같은 IP를 공유하는 경우에는 연결을 특정 도메인에 매핑하기가 더 불확실해집니다. 스니핑으로 도메인 정보를 추가로 얻을 수 있지만 모든 프로토콜을 식별할 수 있는 것은 아닙니다.
여기서 ‘실제 주소’란 상위 DNS가 반환한 주소를 뜻합니다. 해당 주소가 접속 가능하거나 최적의 주소라는 보장은 없으며 네트워크 환경의 영향을 받을 수도 있습니다. 상위 DNS 선택, 분할 DNS, 캐시, 아웃바운드 경로는 각각 확인해야 합니다.
| 비교 항목 | Fake-IP | redir-host |
|---|---|---|
| 앱에 반환되는 주소 | 주소 풀의 가상 주소(필터 적용 항목 제외) | 상위 DNS가 반환한 실제 조회 주소 |
| 도메인 연결 방식 | 주로 가상 주소 매핑 사용 | DNS 캐시와 기타 도메인 정보 활용 가능 |
| 주소 반환 전 대기 | 대상 도메인의 실제 주소 조회를 기다리지 않아도 되는 경우가 많음 | 실제 주소 조회 결과 또는 기존 캐시가 필요한 경우가 많음 |
| 앱 호환성 | 앱이 가상 주소를 처리할 수 있어야 함 | 일반적인 DNS 주소 처리 방식에 가까움 |
| 연결 가로채기 조건 | 가상 주소로 연결한 뒤 코어로 돌아와야 함 | 실제 주소 자체는 가상 주소 매핑에 의존하지 않음 |
최소 DNS 설정과 가로채기 범위
아래는 설정 항목을 설명하기 위한 DNS 예시이며, 완성된 구독 설정이 아닙니다. 로컬 127.0.0.1:1053에서 요청을 받고, 평문 상위 DNS 하나를 지정하며, 일부 로컬 도메인에는 실제 주소를 반환합니다. 상위 DNS 주소는 네트워크 환경과 개인정보 보호 요구에 맞게 조정하세요.
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter-mode: blacklist
fake-ip-filter:
- "localhost"
- "+.lan"
- "+.local"
- "+.home.arpa"
nameserver:
- 223.5.5.5listen은 수신 주소만 지정하며 시스템 DNS를 자동으로 변경하지 않습니다. 일반적인 시스템 DNS 설정에는 서버 IP만 입력할 수 있고 포트는 지정할 수 없습니다. IP만 입력 가능한 항목에 127.0.0.1:1053을 그대로 넣으면 안 됩니다. 클라이언트의 DNS 가로채기, TUN DNS 하이재킹 또는 로컬 포워딩을 통해 조회 요청이 이 리스너에 도달하도록 해야 합니다.
TUN과 시스템 프록시의 차이
TUN은 시스템 라우팅을 통해 전달되는 IP 트래픽을 받고, DNS 강화 모드는 DNS를 처리합니다. 두 기능의 역할은 서로 다릅니다. TUN 설정의 dns-hijack은 조건에 맞는 DNS 트래픽을 가로챌 수 있습니다. 예를 들어 일반 DNS 요청에는 any:53을 사용할 수 있으며, TCP DNS는 해당 문법에 맞게 별도로 설정해야 합니다. 443 포트의 DoH는 53 포트만 가로채도록 설정했다고 해서 내장 DNS 조회로 자동 전환되지 않습니다.
시스템 HTTP 프록시만 켜져 있으면 일부 앱은 대상 도메인을 프록시에 직접 전달하지만, 다른 앱은 로컬에서 계속 DNS 조회를 합니다. 이때 실제 IP가 보인다고 해서 설정에 실패한 것은 아닙니다. 반대로 앱이 Fake-IP를 받은 뒤 가로채지 않은 경로로 가상 주소에 직접 연결하면 연결 시간이 초과될 수 있습니다.
fake-ip-filter: 필요한 도메인만 예외 처리
fake-ip-filter는 도메인별로 주소 반환 방식을 다르게 지정합니다. 광고 차단 목록이나 아웃바운드 규칙은 아닙니다. 위 예시처럼 blacklist 모드에서는 목록에 포함된 도메인에 Fake-IP를 할당하지 않고 실제 조회 주소를 반환합니다. whitelist로 바꾸면 목록의 의미가 반대가 되므로 블랙리스트 내용을 그대로 옮기면 안 됩니다.
localhost는 정확한 도메인 이름을 지정하는 예입니다.+.lan은 해당 도메인과 하위 도메인 범위를 의미하며, 일반적인 문자열 포함 여부를 검사하는 방식이 아닙니다.+.home.arpa는 홈 네트워크 내부 도메인에 사용할 수 있지만, 해당 도메인에 응답하는 DNS가 있어야 합니다.+.local은 실제로 내장 DNS에 들어오는 조회에만 영향을 줍니다. mDNS는 보통 UDP 5353을 사용하며, 멀티캐스트 검색은 이 목록만으로 모두 처리되지 않습니다.
도메인을 필터 목록에 추가해도 자동으로 직접 연결되는 것은 아닙니다. 대상이 로컬 네트워크 서비스라면 관련 규칙이 DIRECT를 선택하는지, 라우팅이 사설 IP 주소에 도달할 수 있는지, 적절한 DNS 상위 서버나 nameserver-policy를 통해 내부 레코드를 가져오는지 확인하세요. 필터 목록은 가상 주소와 실제 주소 중 무엇을 반환할지만 제어합니다.
문제 하나를 해결하려고 지나치게 넓은 도메인 접미사를 추가하거나 모든 도메인에 실제 주소를 반환하도록 설정하지 마세요. 먼저 연결 기록에서 실제로 실패한 도메인을 찾고, 필요한 범위만 예외로 지정하세요. 구독 설정에 기존 필터 항목이 있다면 클라이언트의 덮어쓰기 방식이 병합인지 교체인지도 확인해야 합니다.
바로 활성화하기 어려운 앱과 네트워크
실제 IP에 의존하는 도구
네트워크 진단 도구, IP 위치 확인 도구, 조회 주소를 접근 제어 목록에 기록하는 프로그램은 Fake-IP를 실제 서버 주소로 오인할 수 있습니다. 그러면 결과가 원래 의미를 잃습니다. 실제 주소를 진단해야 한다면 대상 도메인을 실제 주소로 조회하거나, 통제된 테스트 환경에서 redir-host로 전환하세요.
로컬 네트워크 검색 및 사내 서비스
NAS, 프린터, 화면 미러링, 사내 도메인은 로컬 DNS, 멀티캐스트, 브로드캐스트 또는 전용 라우팅에 의존하는 경우가 많습니다. 실제 주소를 반환하는 것만으로는 충분하지 않습니다. 기업 VPN의 분할 DNS와 TUN 라우팅이 사설 주소 대역과 충돌하면 가로채기 범위도 조정해야 합니다. 필터 목록만으로 해결할 수는 없습니다.
조회 결과를 다른 기기에 전달하는 프로그램
프로그램이 로컬에서 도메인을 조회한 뒤 주소를 다른 기기에 보내 연결을 시작한다면, 그 기기에는 해당 Fake-IP 매핑이 없는 경우가 많습니다. 일부 P2P, 미디어 또는 제어 앱에서 이런 동작이 나타날 수 있지만, 모든 게임·동영상·UDP 앱이 호환되지 않는다고 단정할 수는 없습니다. 실제 도메인, 연결 경로, 오류 로그를 확인하세요.
또한 실제 IP가 앱에 하드코딩되어 있으면 도메인 조회가 발생하지 않으므로 Fake-IP 필터도 적용되지 않습니다. 이때는 도메인 예외를 더 추가하지 말고 IP 규칙, UDP 지원, 라우팅, 방화벽을 확인하세요.
검증과 문제 해결: 조회·매핑·아웃바운드 순서로 확인
- 실행 중인 설정 확인: 현재 불러온 Profile과 최종 적용된
dns.enhanced-mode를 확인하세요. 원격 구독을 업데이트하면 파일을 직접 수정한 내용이 덮어써질 수 있으므로 클라이언트에서 제공하는 영구 오버라이드 기능을 우선 사용하세요. - 리스너에 직접 질의: 시스템에
dig가 설치되어 있다면 아래 명령으로 시스템 기본 DNS를 거치지 않고 예시 리스너 포트에 직접 질의할 수 있습니다. - 연결 기록 확인: 같은 도메인에 접속한 뒤 코어에 연결이 기록되었는지, 도메인과 연결되었는지, 어떤 규칙이 적용되었는지, 최종 아웃바운드가 무엇인지 확인하세요.
- 우회 DNS 조회 확인: 직접 조회는 정상인데 앱 동작이 다르다면 브라우저의 보안 DNS, 앱 내장 DoH, 시스템 캐시, 다른 VPN을 확인하세요.
- 한 번에 하나씩 비교: 먼저 문제가 있는 도메인만 필터에 추가하고, 그래도 실패하면
redir-host와 비교하세요. 매번 변수 하나만 바꾸고 원래대로 복구할 수 있도록 설정을 보관하세요.
dig @127.0.0.1 -p 1053 example.com A위 Fake-IP 설정에서 필터에 걸리지 않은 A 레코드 조회는 설정된 주소 풀의 주소를 반환해야 합니다. redir-host로 전환하면 상위 DNS의 실제 응답을 받아야 합니다. 이 명령은 DNS 리스너와 반환값만 확인하며 TUN 가로채기나 프록시 아웃바운드가 정상임을 증명하지는 않습니다.
모드를 전환한 뒤에도 앱에 이전 가상 주소가 남아 있을 수 있습니다. Windows에서는 ipconfig /flushdns로 시스템 DNS 캐시를 지울 수 있지만, 브라우저와 앱의 캐시를 비우려면 앱을 재시작해야 할 수도 있습니다. 매핑만 삭제하고 앱이 이전 Fake-IP를 계속 사용하면 새 연결도 실패할 수 있습니다.
속도를 비교하려면 같은 네트워크, 노드, 대상 도메인, 아웃바운드 규칙을 유지하고 캐시가 없는 경우와 캐시가 있는 경우를 각각 기록하세요. 예를 들어 각 모드에서 10회씩 조회하고 첫 결과는 따로 기록한 뒤, 나머지 결과의 중앙값을 비교할 수 있습니다. 이는 테스트 방법일 뿐 이 사이트의 성능 측정 결과가 아닙니다. DNS 조회, 연결 설정, 페이지 로딩 시간은 구분해 기록하세요.
모드 선택과 설정 유지
- Fake-IP 우선 고려: DNS 조회와 앱 트래픽이 같은 mihomo 코어에 안정적으로 들어오고, 명확한 도메인 연결이 필요하며 앱이 실제 조회 주소에 의존하지 않는 경우에 적합합니다.
- redir-host 우선 고려: 작업 흐름에서 실제 IP가 필요하거나 호환성을 우선해야 하는 경우, 또는 가상 주소 연결이 코어로 돌아온다고 보장하기 어려운 네트워크에서 적합합니다.
- 필요한 도메인만 필터링: 대부분의 앱은 정상인데 일부 내부 도메인이나 특정 프로그램에만 문제가 있고, 실제 주소가 필요한 원인을 확인한 경우에 적합합니다.
재시작 후에도 매핑을 최대한 유지하려면 설정의 profile.store-fake-ip를 확인하세요. 매핑을 저장하면 재시작으로 인한 문제를 줄일 수 있지만, 잘못된 라우팅을 고치거나 설정 전환, 주소 풀 변경, 데이터 정리 후에도 이전 주소가 계속 유효하도록 보장하지는 않습니다. 최종적으로 실행 설정, DNS 반환값, 연결 기록이 서로 일치하는지 확인하세요.