Fake-IP 모드 원리와 설정: mihomo DNS 강화 모드 및 사용 사례
Fake-IP가 예약 주소로 DNS 응답 속도와 도메인 기반 라우팅을 개선하는 원리, redir-host와의 차이, fake-ip-filter 설정법과 사용에 적합하지 않은 상황을 알아봅니다.
Fake-IP 작동 과정: 도메인, 가상 주소, 실제 연결
Fake-IP는 mihomo DNS의 강화 모드 중 하나로, dns.enhanced-mode: fake-ip로 활성화합니다. 앱에 가상 IPv4 주소를 반환하고, 커널에는 도메인과 가상 주소의 매핑을 저장합니다. 이 주소는 웹사이트 서버의 실제 주소도 프록시 노드 주소도 아니며, 앱의 연결 대상을 식별하는 인덱스 역할을 합니다.
일반적인 설정에서는 198.18.0.1/16을 할당 범위로 사용합니다. 이 범위는 네트워크 성능 테스트용으로 예약된 198.18.0.0/15 주소 공간에 속하며, 공용 인터넷에서 웹사이트 서비스를 제공하는 데 쓰는 일반 주소 대역이 아닙니다. 기업망이나 테스트망에서 이미 사용 중인지 확인해야 합니다. 예약 주소라는 이유만으로 충돌이 없다고 단정할 수는 없습니다.
- 앱이
example.com을 조회하면 요청은 mihomo의 DNS 서비스로 전달됩니다. - mihomo는 해당 도메인에 주소 풀의 주소를 할당하고 매핑을 저장합니다. 앱에는
198.18.0.2가 반환될 수 있지만, 실제 할당 주소는 고정되어 있지 않습니다. - 앱은 이 가상 주소로 연결을 시도하며, 연결은 다시 동일한 mihomo 커널로 전달되어야 합니다.
- 커널은 매핑을 바탕으로 도메인을 복원하고 규칙을 적용한 뒤, 선택된 직접 연결 또는 프록시 출구를 통해 실제 연결을 설정합니다.
응답 속도 향상과 정확한 라우팅은 무엇을 뜻할까요?
상위 DNS 응답을 기다리는 경우를 줄입니다
로컬에서 가상 주소를 할당할 수 있는 요청이라면 mihomo는 상위 DNS에서 웹사이트의 실제 IPv4 주소를 받을 때까지 기다리지 않고 앱에 응답할 수 있습니다. 이후 도메인 전달을 지원하는 프록시 출구를 이용하면 목적지 도메인의 조회를 원격에 맡길 수도 있습니다. 줄어드는 것은 일부 연결 과정의 DNS 대기 시간이며, 노드 지연 시간이나 다운로드 속도, 서버 응답 속도가 함께 개선되는 것은 아닙니다.
규칙에 따라 최종 출구가 DIRECT로 결정되면 일반적으로 실제 주소가 필요합니다. 필터에 포함된 도메인, 일부 쿼리 유형, 실제 DNS 응답이 필요한 처리도 상위 DNS를 사용합니다. 따라서 Fake-IP를 사용하면 모든 접속에서 DNS 조회가 사라진다고 볼 수 없으며, 어떤 네트워크에서나 적용되는 고정된 속도 향상 수치를 제시하는 것도 적절하지 않습니다.
도메인 정보를 유지해 도메인 규칙을 적용하기 쉽습니다
투명 프록시로 연결을 처리할 때 시스템이 처음 커널에 전달하는 정보는 목적지 IP뿐인 경우가 많습니다. Fake-IP 매핑을 이용하면 커널이 원래 조회한 도메인을 복원한 뒤 DOMAIN, DOMAIN-SUFFIX 등의 규칙을 적용할 수 있습니다. 예를 들어 DOMAIN-SUFFIX,example.com,Proxy는 해당 도메인과 하위 도메인에 적용됩니다. 여기서 Proxy는 설정에 실제로 존재하는 프록시 또는 프록시 그룹 이름이어야 합니다.
- 규칙은 여전히 위에서 아래 순서로 적용되므로, 먼저 일치한 규칙이 출구를 결정할 수 있습니다.
- 앱이 하드코딩된 IP에 직접 연결하면 대응하는 DNS 조회가 없으므로 Fake-IP로 도메인을 복원할 수 없습니다.
- 앱이 mihomo를 우회해 자체 암호화 DNS를 사용하면 커널에 매핑이 전달되지 않을 수 있습니다. 스니핑 기능으로 일부 도메인 정보를 보완할 수는 있지만, 모든 프로토콜을 스니핑할 수 있는 것은 아닙니다.
Fake-IP와 redir-host의 차이
redir-host는 상위 DNS에서 조회한 실제 IP를 앱에 반환하고, DNS 기록을 바탕으로 도메인과 연결을 연관 짓습니다. DNS를 끄는 방식도 아니고 출구 모드도 아닙니다. 두 DNS 강화 모드 모두 규칙 모드와 함께 사용할 수 있으며, 주된 차이는 앱에 반환하는 주소와 커널이 도메인 정보를 보관하는 방식입니다.
| 비교 항목 | Fake-IP | redir-host |
|---|---|---|
| 앱에 반환되는 IPv4 주소 | 조건에 따라 주소 풀의 가상 주소 반환 | 실제 DNS 조회 결과 반환 |
| 도메인 연결 방식 | 가상 주소와 도메인의 매핑으로 복원 | DNS 기록을 바탕으로 연결하며, IP를 공유하는 경우 등에는 모호성이 커질 수 있음 |
| 초기 DNS 대기 시간 | 일부 요청은 로컬에서 바로 응답 가능 | 일반적으로 상위 DNS 응답을 기다림. 캐시 적중 시 제외 |
| 호환성 확인 사항 | 앱이 실제 주소를 요구하는지, 연결이 동일한 커널로 돌아오는지 | 실제 DNS 응답 품질, DNS 캐시, 도메인 연결 정보의 완전성 |
| 로컬 네트워크 앱 | 내부 도메인에 필터와 전용 DNS 설정이 필요할 수 있음 | 내부 도메인을 조회할 수 있는 DNS 설정 필요 |
먼저 필요한 기능에 따라 선택하세요. 트래픽을 투명하게 처리하고 도메인 규칙을 주로 사용한다면 Fake-IP를 우선 테스트할 수 있습니다. 앱에 실제 주소를 제공해야 하거나 기존 소프트웨어가 가상 주소와 호환되지 않는다면 필터 규칙을 사용하고, 필요한 경우 redir-host로 전환하세요. DNS 모드를 바꾼 뒤에는 이전 캐시를 지우고 연결을 새로 설정해야 합니다. 그렇지 않으면 테스트 결과에 이전 주소가 섞일 수 있습니다.
최소 설정: DNS부터 확인한 뒤 시스템 트래픽 처리
아래는 로컬 테스트용 mihomo 설정 예시이며, 완성된 구독 설정이 아닙니다. 루프백 주소의 1053 포트에서만 DNS 서비스를 제공하며, 시스템 DNS를 자동으로 변경하거나 TUN을 자동으로 활성화하지 않습니다. 기존 설정의 해당 항목에 병합하고, 하나의 YAML 문서에 dns를 중복 선언하지 마세요.
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-mode: blacklist
fake-ip-filter:
- "localhost"
- "*.lan"
- "*.local"
- "+.home.arpa"
nameserver:
- 1.1.1.1
- 9.9.9.9listen은 DNS가 수신 대기할 주소를 지정합니다. 시스템 DNS 설정에는 보통 사용자 지정 포트를 입력할 수 없으므로, “127.0.0.1:1053”을 일반 DNS 서버 주소처럼 시스템 설정 화면에 입력하면 안 됩니다.ipv6: false는 이 예시의 DNS 테스트 범위를 좁히기 위한 설정일 뿐, 운영체제의 IPv6를 끄는 것은 아니며 모든 환경에 적용해야 하는 설정도 아닙니다.nameserver는 예시 상위 DNS입니다. 현재 네트워크에서 접속할 수 있는지 확인하세요. 기업 내부 도메인에는 보통 내부 DNS가 필요하며, 공용 DNS가 내부 주소를 반환하리라 기대해서는 안 됩니다.fake-ip-filter-mode는 해당 필드를 지원하는 최신 mihomo를 전제로 합니다. 구형 Clash 브랜치는 필드 지원 여부가 다를 수 있으므로, 먼저 클라이언트에서 사용하는 커널을 확인하고 설정 로드 오류를 살펴보세요.
데스크톱 클라이언트는 ‘오버라이드’ 또는 ‘확장 설정’을 통해 실제 실행 설정을 생성할 수 있으며, 구독을 업데이트하면 직접 편집한 내용이 덮어써질 수도 있습니다. 수정 후에는 클라이언트의 실행 설정 확인 메뉴에서 최종 dns 항목을 확인하고 로그 페이지에서 설정이 정상적으로 로드됐는지 살펴보세요. 편집기에서 저장에 성공했다고 해서 커널이 새 설정을 적용했다고 단정하지 마세요.
fake-ip-filter 설정: 실제 주소를 반환해도 직접 연결되는 것은 아닙니다
위의 blacklist 모드에서 fake-ip-filter에 일치하는 도메인은 Fake-IP를 사용하지 않고 실제 주소로 조회됩니다. "localhost"는 특정 이름을 지정하고, "*.lan"은 해당 하위 도메인에 일치하며, "+.home.arpa"는 home.arpa와 그 하위 도메인에 적용됩니다. 별표가 포함된 문자열은 YAML에서 다른 문법으로 해석되지 않도록 따옴표로 감싸세요.
구체적인 도메인부터 추가하고, 필요할 때 전체 접미사 범위를 고려하세요
예를 들어 NAS의 주소가 nas.home.arpa이고 앱에 실제 내부 네트워크 주소를 제공해야 한다면 필터 목록에 추가할 수 있습니다. 동시에 해당 도메인을 홈 라우터의 DNS에서 조회하도록 설정해야 합니다. 필터만 추가한다고 올바른 내부 DNS가 자동으로 지정되지는 않습니다. 상위 DNS가 공용 DNS라면 도메인을 찾을 수 없다는 결과가 나올 수도 있습니다.
.local은 mDNS에 주로 사용되며, mDNS의 기기 탐색 방식은 일반 유니캐스트 DNS와 다릅니다. "*.local"을 필터 목록에 넣으면 가상 주소를 사용하지 않도록 할 수는 있지만, 네트워크 구간을 넘어 프린터, 화면 전송 기기 또는 다른 로컬 서비스가 검색된다는 보장은 없습니다.
필터 목록과 출구 규칙은 별도로 관리하세요
도메인을 필터 목록에 넣어도 DIRECT 규칙이 자동으로 추가되지는 않습니다. 출구는 여전히 rules에 따라 결정됩니다. 반대로 직접 연결 규칙을 추가했다고 해서 해당 도메인의 Fake-IP를 반드시 비활성화해야 하는 것도 아닙니다. 커널이 먼저 도메인을 복원한 다음 실제 주소를 조회해 직접 연결할 수 있습니다.
TUN, 시스템 프록시, DNS 리디렉션은 어떻게 함께 작동할까요?
Fake-IP는 DNS 계층의 동작이고, TUN은 트래픽을 커널로 전달하는 방식이며, 시스템 프록시는 해당 설정을 따르는 앱에 로컬 프록시 포트를 사용하도록 알립니다. 세 가지는 서로 대체할 수 없습니다. 특히 브라우저가 HTTP 프록시를 통해 목적지 도메인을 전달하면, 목적지 조회는 프록시 경로에서 처리될 수 있어 브라우저의 로컬 Fake-IP 조회를 거치지 않을 수도 있습니다.
- 시스템 프록시: 시스템 프록시 설정을 읽는 앱에 적합합니다. 설정을 읽지 않는 게임, 명령줄 도구 또는 백그라운드 서비스는 기존 네트워크 경로로 계속 연결될 수 있습니다.
- TUN: 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리합니다. 라우팅, 제외 항목, DNS 요청이 커널로 전달되는지도 확인해야 합니다.
- DNS 리디렉션: 예를 들어 TUN 설정의
dns-hijack은 지정된 DNS 트래픽을 처리할 수 있습니다. 하지만 53번 포트 트래픽을 리디렉션한다고 해서 모든 DoH, DoT 또는 앱 내장 DNS 조회까지 가로채는 것은 아닙니다.
여러 네트워크 어댑터, VPN, 기업 보안 소프트웨어를 함께 사용하면 라우팅 우선순위에 따라 가상 주소 연결이 잘못된 인터페이스로 전달될 수 있습니다. 컴퓨터와 라우터에서 각각 별도의 커널을 실행하는 경우도 흔한 문제입니다. DNS 매핑은 라우터에 있지만 연결은 컴퓨터의 커널로 전달될 수 있습니다. 서로 독립된 두 매핑은 자동으로 연동되지 않으므로 DNS 응답과 연결 처리가 동일한 트래픽 처리 경로에서 이루어지도록 해야 합니다.
기본 설정은 시스템 프록시 설정과 규칙 모드 안내를 참고하세요. 문제를 확인할 때는 한 번에 하나의 변수만 바꾸세요. 먼저 DNS를 확인하고, 다음으로 트래픽 처리 여부를 점검한 뒤 규칙과 프록시 그룹 선택을 확인합니다.
확인 방법: 조회 결과, 연결 로그, 캐시
1단계: mihomo 수신 포트로 직접 조회하기
앞서 설명한 로컬 테스트 설정을 사용 중이라면 아래 명령을 실행할 수 있습니다. Windows에서는 nslookup을 사용하고, dig가 설치된 Linux 또는 macOS에서는 두 번째 명령을 사용할 수 있습니다. 테스트 도메인이 필터 목록에 포함되어 있지 않은지 확인하세요.
nslookup -port=1053 example.com 127.0.0.1
dig @127.0.0.1 -p 1053 example.com A응답 주소가 설정한 198.18.0.0/16 범위에 있다면 해당 조회에 Fake-IP 할당이 적용된 것입니다. 실제 공인 IP가 반환된다면 필터 목록, 최종 실행 설정, 조회한 대상을 확인하세요. 응답이 시간 초과되면 DNS 활성화 여부, 수신 포트 사용 여부, 커널의 정상 실행 여부부터 점검하세요.
2단계: 실제 앱 연결 확인하기
트래픽 처리 경로를 설정한 뒤 같은 도메인에 접속하고, 클라이언트의 ‘연결’ 또는 로그 페이지에서 목적지 도메인, 일치한 규칙, 출구 경로를 확인하세요. 조회 명령으로 가상 주소를 받았다는 사실은 DNS 할당이 작동함을 보여줄 뿐입니다. 앱이 연결되고 예상한 규칙이 적용되어야 전체 경로가 정상이라고 볼 수 있습니다. 가상 주소에 ping을 실행한 결과를 웹페이지 접속 가능 여부의 기준으로 삼지 마세요.
3단계: 캐시를 지운 뒤 다시 테스트하기
Windows에서는 ipconfig /flushdns로 시스템 DNS 캐시를 지울 수 있습니다. systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행하면 됩니다. 브라우저와 앱에도 별도 캐시나 장시간 유지되는 연결이 있을 수 있으므로 관련 연결을 닫거나 앱을 다시 시작해야 합니다. 시스템 캐시를 지워도 모든 앱의 캐시가 삭제되는 것은 아닙니다.
mihomo의 profile.store-fake-ip: true 설정은 Fake-IP 매핑을 영구 저장하는 데 사용할 수 있지만, 잘못된 라우팅을 고치거나 여러 기기에서 매핑을 공유해 주지는 않습니다. 매핑을 새로 만들거나 주소 풀을 변경하거나 모드를 전환할 때는 앱에 남아 있는 이전 주소도 함께 처리해야 합니다. 앱에는 이전 주소가 남아 있지만 커널에는 그에 대응하는 기록이 없는 상태가 발생할 수 있습니다.
바로 활성화하기 어려운 상황과 되돌리는 순서
일부 소프트웨어는 DNS 결과를 실제 서비스 주소로 취급합니다. 예를 들어 주소를 시그널링 정보에 넣거나 다른 기기에 전달해 연결하게 하거나, 이를 바탕으로 로컬 네트워크에 있는지 판단할 수 있습니다. 이때 가상 주소가 매핑을 보유하지 않은 기기로 전달될 수 있습니다. 기업 내부망, 테스트망, 일부 게임의 연결 절차도 별도로 확인해야 합니다. 기기 전체에서 활성화한 뒤 브라우저만 점검해서는 충분하지 않습니다.
- 특정 앱 하나에서만 문제가 발생하는 경우: 앱이 사용하는 도메인, 자체 DNS 사용 여부, IP 직접 연결 여부를 확인하세요. 호환성 문제가 확인된 도메인에만 필터 항목을 추가합니다.
- 내부 네트워크 서비스에서만 문제가 발생하는 경우: 내부 DNS, 도메인 필터, 사설망 라우팅, 출구 규칙을 확인하세요. 주소는 올바르게 조회되지만 접속할 수 없다면 라우팅과 접근 권한도 점검합니다.
- 모든 앱에서 동시에 문제가 발생하는 경우: 가상 주소 연결이 동일한 커널로 전달되는지, TUN 라우팅이 적용됐는지, 다른 VPN과 충돌하는지 확인하세요.
- 앱에 실제 주소를 제공해야 하는 경우: 실행 설정을 백업한 뒤
enhanced-mode: redir-host로 전환하고 설정을 다시 불러오세요. 그런 다음 캐시를 지우고 연결을 새로 설정한 뒤 규칙이 의도대로 적용되는지 확인합니다.
마지막으로 개인정보 보호 범위를 구분해야 합니다. Fake-IP는 암호화 DNS가 아니며, 모든 DNS 요청이 프록시를 통해 전송된다는 보장도 없습니다. 상위 DNS 프로토콜, DNS 출구 정책, 앱 자체 조회, 직접 연결 규칙에 따라 실제 경로가 달라집니다. 클라이언트에서 ‘Fake-IP’가 켜져 있는지만 보지 말고 조회 결과와 라우팅, 로그를 함께 확인해 기대한 대로 작동하는지 판단하세요.