Fake-IP는 오류 주소가 아니라 임시 전화번호입니다
애플리케이션이 웹사이트에 접속할 때는 보통 먼저 DNS에 도메인에 해당하는 IP 주소를 조회한 뒤, 해당 IP로 TCP, UDP 또는 QUIC 연결을 시작합니다. 기존 흐름에서는 DNS가 실제 주소를 반환해야 연결을 계속할 수 있습니다. Fake-IP는 바로 이 단계를 바꿉니다. Clash 또는 mihomo의 내장 DNS가 먼저 예약 주소 풀에서 주소를 할당하고, ‘도메인—가상 주소’ 매핑을 메모리에 저장합니다.
자주 사용하는 주소 풀은 198.18.0.0/16입니다. 이 IPv4 대역은 RFC 2544에 따라 네트워크 장비 벤치마크 테스트용으로 예약되어 있으며 공용 인터넷에서 라우팅되어서는 안 됩니다. mihomo 설정에는 보통 198.18.0.1/16으로 작성하며, 약 65534개의 주소를 할당할 수 있습니다. 브라우저에는 198.18.0.23이 보일 수 있지만, 실제로 인터넷에서 이 호스트를 찾는 것은 아닙니다.
이후 애플리케이션이 198.18.0.23:443에 연결하면 Clash 코어가 매핑 테이블에서 원래 도메인(예: www.example.com)을 가져옵니다. 이제 규칙 엔진은 DOMAIN, DOMAIN-SUFFIX, GEOSITE 등의 규칙으로 도메인을 직접 매칭한 뒤 프록시, 직접 연결 또는 차단을 선택할 수 있습니다. 트래픽이 프록시를 거치면 도메인을 프록시 경로에서 처리할 수 있고, 직접 연결 규칙이면 코어가 설정된 DNS 서버를 통해 실제 주소를 조회합니다.
한 번의 접속에서 일어나는 과정
- 브라우저가
api.example.com의 A 레코드를 조회합니다. - Clash DNS가 Fake-IP 주소 풀에서
198.18.0.23을 반환하는 동시에 매핑을 저장합니다. - 브라우저가
198.18.0.23:443에 연결을 수립합니다. - 시스템 프록시, 투명 프록시 또는 TUN 모드가 이 연결을 코어로 전달합니다.
- 코어가 도메인을 복원하고 규칙 그룹에 따라
DIRECT,PROXY또는 다른 정책을 선택합니다. - 실제 IP가 필요하면 코어 또는 프록시 서버가 주소를 조회한 뒤 대상 사이트에 연결합니다.
‘DNS 왕복을 한 번 줄인다’는 것은 애플리케이션이 공용 권한 DNS의 응답을 기다리지 않고 로컬 응답을 먼저 받아 연결을 시작할 수 있다는 뜻입니다. 실제 조회가 사라지는 것이 아니라 지연되거나 통합되거나 프록시 측으로 옮겨집니다. 최종 지연 시간은 여전히 DNS 서버, 프록시 노드와 대상 네트워크의 영향을 받습니다.
Fake-IP와 Redir-Host의 핵심 차이
Redir-Host는 널리 사용되는 또 다른 향상 DNS 모드입니다. 먼저 실제 DNS 조회를 완료한 뒤 실제 IP를 애플리케이션에 반환합니다. 애플리케이션이 실제 IP에 연결하면 코어가 DNS 매핑, 연결 정보 또는 도메인 스니핑을 조합해 도메인을 복원하려고 시도합니다. 일반 네트워크 동작에 더 가깝기 때문에 LAN 장치나 DNS 결과를 엄격하게 검사하는 일부 애플리케이션과의 호환성이 좋습니다.
Fake-IP는 도메인 정보를 우선 보존합니다. 규칙을 판단할 때 코어가 연결이 처음 향한 도메인을 이미 알고 있으므로 대상 IP에만 의존할 필요가 없고, 하나의 IP에서 여러 사이트를 호스팅하는 환경의 영향도 적습니다. CDN에서는 차이가 특히 분명합니다. 수백 개의 도메인이 하나의 엣지 주소를 공유할 수 있어 IP만으로는 서비스를 정확히 구분하기 어렵기 때문입니다.
| 비교 항목 | Fake-IP | Redir-Host |
|---|---|---|
| 애플리케이션에 반환되는 주소 | 대개 198.18.0.0/16 내 예약 주소 | DNS 조회로 얻은 실제 주소 |
| 도메인 규칙 식별 | 매핑으로 직접 복원되어 대체로 안정적 | DNS 매핑 또는 스니핑에 의존해 보완 |
| 최초 DNS 응답 | 로컬에서 빠르게 주소 할당 | 상위 DNS 응답을 기다림 |
| LAN 호환성 | 일부 도메인을 필터 목록에 추가해야 함 | 대체로 시스템의 기존 동작에 가까움 |
| 적합한 환경 | TUN, 투명 프록시, 세밀한 도메인별 분기 | 간단한 시스템 프록시, 특수 장치 호환성 |
두 모드 사이에 절대적인 우열은 없습니다. 데스크톱에서 TUN으로 전체 트래픽을 가로채고 규칙이 주로 도메인 기반이라면 Fake-IP가 대체로 관리하기 편합니다. 라우터에서 우회 라우터를 함께 사용하거나 LAN 검색, 프린터 제어, 오래된 애플리케이션이 많다면 먼저 필터 규칙을 테스트하세요. 문제가 계속되면 Redir-Host로 전환해 비교해 볼 수 있습니다.
mihomo에서 Fake-IP 설정하는 방법
다음 예시는 mihomo 1.19 계열에서 흔히 사용하는 설정 구조입니다. 그래픽 클라이언트에 따라 옵션이 화면에 나뉘어 있을 수 있지만 최종적으로는 해당 YAML이 생성되어야 합니다. 수정 전 현재 설정을 복사해 두세요. 구독 설정은 업데이트 시 로컬 내용을 덮어쓸 수 있으므로 클라이언트에서 제공하는 오버라이드, Mixin 또는 확장 스크립트 기능을 우선 사용해야 합니다.
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:
- "*.lan"
- "+.local"
- "localhost.ptlogin2.qq.com"
- "+.pool.ntp.org"
nameserver:
- https://223.5.5.5/dns-query
- https://1.12.12.12/dns-query
proxy-server-nameserver:
- https://223.5.5.5/dns-query설정 항목별 이해
enable: true: 내장 DNS를 활성화합니다.enhanced-mode만 작성하고 DNS를 활성화하지 않으면 예상대로 동작하지 않습니다.listen: 127.0.0.1:1053: 로컬 1053 포트에서만 수신합니다. 일반 사용자 프로세스가 53 포트를 직접 열면 권한 제한이 발생하거나 시스템 DNS 서비스와 충돌할 수 있습니다.ipv6: false: 애플리케이션에 AAAA 결과를 반환하지 않습니다. IPv6가 안정적으로 제공되고 규칙도 IPv6를 지원한다면 활성화할 수 있지만, 직접 연결과 프록시 경로를 함께 확인해야 합니다.enhanced-mode: fake-ip: Fake-IP 향상 모드를 선택합니다.redir-host로 작성하면 DNS가 실제 주소를 반환합니다.fake-ip-range: IPv4 주소 풀을 지정합니다. 일반적으로 기본값을 유지하고, 가정용 LAN에서 사용하는192.168.0.0/16또는10.0.0.0/8로 변경하지 마세요.fake-ip-filter-mode: blacklist: 목록에 포함된 도메인은 Fake-IP를 건너뛰고 실제 조회 결과를 반환합니다. 가장 일반적으로 사용하는 동작입니다.nameserver: 일반 도메인 조회를 처리합니다. 예시는 DoH를 사용하며 연결 포트는 보통 443입니다.proxy-server-nameserver: 프록시 노드 서버의 도메인을 전용으로 조회해 노드 주소를 확인할 때 순환 의존이 발생하지 않도록 합니다.
Fake-IP 적용 여부 확인
macOS 또는 Linux에서는 dig로 로컬 DNS 포트를 지정할 수 있습니다. Windows에서는 사용자 지정 포트를 지원하는 DNS 도구를 사용하거나, 테스트를 위해 수신 포트를 시스템 조회가 가능한 53으로 임시 변경하세요. 다음 명령은 시스템 설정을 변경하지 않습니다:
dig @127.0.0.1 -p 1053 www.example.com A
# 예상 결과 예시:
# www.example.com. 1 IN A 198.18.0.2공용 인터넷의 실제 IP가 반환되면 먼저 실제로 불러온 설정에서 여전히 redir-host인지 확인하고, 해당 도메인이 fake-ip-filter에 포함되었는지 점검하세요. 조회가 시간 초과되면 lsof -nP -iUDP:1053 또는 ss -lunp로 포트가 수신 중인지 확인합니다. 그래픽 클라이언트에서는 구독 원본 파일이 아니라 현재 실행 중인 설정도 확인해야 합니다.
mihomo에서 external-controller: 127.0.0.1:9090을 활성화하면 제어 인터페이스로 DNS를 조회할 수도 있습니다. 제어 인터페이스에 인증 키를 설정하지 않은 경우 요청 예시는 다음과 같습니다:
curl "http://127.0.0.1:9090/dns/query?name=www.example.com&type=A"제어 인터페이스에 secret이 설정되어 있다면 요청에 해당 Bearer 자격 증명을 반드시 포함해야 합니다. 9090 제어 포트를 인터넷에 직접 노출해서는 안 되며, 가정 내 LAN에서 공유할 때도 접근 제한을 설정해야 합니다.
fake-ip-filter 작성 방법
fake-ip-filter는 특정 도메인이 가상 주소 할당을 우회하고 실제 DNS 결과를 직접 받도록 합니다. 필터링 대상은 보통 ‘접속되지 않는 웹사이트’가 아니라 실제 주소, LAN 주소 또는 특수 DNS 레코드에 의존하는 서비스입니다. 목록이 지나치게 크면 Fake-IP의 도메인 매핑 장점이 오히려 약해집니다.
필터 목록에 추가하기 적합한 유형
- LAN 이름:
*.lan,+.local, 라우터 관리 도메인 및 NAS 사용자 지정 도메인. - 시간 동기화: 일부 NTP 클라이언트는 직접 조회한 UDP 대상만 허용하므로
+.pool.ntp.org를 필터링할 수 있습니다. - 네트워크 연결성 확인: 일부 시스템은 고정 도메인과 응답 내용을 사용해 호텔, 공항 또는 학교 네트워크 인증 페이지를 표시할지 판단합니다.
- 장치 검색 및 화면 전송: 프린터, TV, 스피커와 화면 전송 장치는 mDNS, 유니캐스트 DNS 및 LAN 주소의 조합에 의존할 수 있습니다.
- DNS 주소를 명시적으로 검증하는 애플리케이션: 일부 프로그램은 DNS 결과와 실제 연결 주소를 비교하므로 예약 주소가 오류를 유발할 수 있습니다.
dns:
enhanced-mode: fake-ip
fake-ip-filter-mode: blacklist
fake-ip-filter:
- "*.lan"
- "+.local"
- "router.asus.com"
- "miwifi.com"
- "+.pool.ntp.org"
- "time.windows.com"
- "time.apple.com"*.lan은 일반적으로 하위 도메인 매칭에 사용하고, +.local은 mihomo 도메인 매칭 문법에서 루트 도메인과 하위 도메인을 모두 포함할 수 있습니다. 커널 버전에 따라 와일드카드 표현식 지원이 다를 수 있으므로 기존 Clash 설정을 이전할 때 실행 로그를 확인하세요. 가장 안전한 점검 방법은 먼저 전체 도메인을 작성해 복구 여부를 확인한 다음 매칭 범위를 넓히는 것입니다.
화이트리스트 모드는 만능 최적화가 아닙니다
mihomo에서는 fake-ip-filter-mode를 whitelist로 설정할 수 있습니다. 이때 로직이 반대로 동작합니다. 목록에 있는 도메인만 Fake-IP를 사용하고 나머지는 실제 주소를 반환합니다. Fake-IP를 단계적으로 활성화하려는 특수한 환경에 적합하지만 규칙 동작이 일관되지 않기 쉬우므로 ‘가상 주소를 줄이기 위해’ 임의로 활성화하는 것은 권장하지 않습니다.
dns:
enhanced-mode: fake-ip
fake-ip-filter-mode: whitelist
fake-ip-filter:
- "+.example.com"
- "+.example.net"필터 목록을 조정할 때는 한 번에 한두 항목만 추가하세요. 설정을 저장하고 코어를 다시 불러온 다음 시스템 DNS 캐시를 삭제하고 문제를 재현합니다. macOS에서는 sudo dscacheutil -flushcache, Windows에서는 ipconfig /flushdns를 실행할 수 있습니다. 브라우저가 별도의 DNS 캐시를 보유할 수도 있으므로 브라우저를 완전히 종료한 뒤 테스트하는 편이 더 정확합니다.
어떤 환경에 Fake-IP가 더 적합한가
TUN 모드로 전체 기기 트래픽 가로채기
TUN은 가상 네트워크 인터페이스를 만들어 시스템 프록시보다 더 넓은 범위의 트래픽을 네트워크 계층에서 수신합니다. 명령줄 도구, 일부 게임 런처와 시스템 프록시를 읽지 않는 애플리케이션도 코어로 들어올 수 있습니다. Fake-IP가 반환한 예약 주소는 코어가 가로채야 하므로 TUN, 투명 프록시 또는 라우터 리디렉션과 함께 사용하는 것이 가장 자연스럽습니다.
Fake-IP만 활성화하고 시스템 프록시, TUN 또는 투명 전달을 켜지 않으면 애플리케이션이 198.18.0.0/16으로 직접 패킷을 보내 연결 시간이 초과될 수 있습니다. 이때 DNS는 정상처럼 보이지만 실제로는 트래픽 가로채기 경로가 빠진 것입니다. 문제를 확인할 때 DNS 조회 로그와 연결 로그를 함께 살펴봐야 합니다.
규칙이 주로 도메인 기반으로 구성됨
설정에서 DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOSITE 또는 규칙 세트를 많이 사용한다면 Fake-IP는 연결 수립 단계에서 도메인 컨텍스트를 보존할 수 있습니다. CDN IP만 받은 뒤 도메인을 추측하는 것보다 규칙이 매칭된 이유를 이해하기 쉽습니다.
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT,no-resolve
- MATCH,PROXYGEOIP,CN,DIRECT,no-resolve에서 no-resolve는 해당 IP 규칙을 매칭하기 위해 추가 DNS 조회를 일부러 실행하지 않는다는 뜻입니다. Fake-IP 환경에서는 불필요한 조회를 줄일 수 있지만, 앞선 도메인 규칙의 순서와 함께 사용 여부를 판단해야 합니다. 규칙은 위에서 아래로 매칭되며 첫 번째로 일치한 규칙에서 중단됩니다.
로컬 DNS 오염의 영향을 줄이고 싶은 경우
애플리케이션은 통신사 DNS가 반환한 대상 주소에 직접 의존하지 않고 먼저 로컬 Fake-IP를 받습니다. 실제 조회는 암호화 DNS 또는 프록시 경로에 맡길 수 있으므로 잘못된 응답과 조회 경로 노출을 더 쉽게 제어할 수 있습니다. 다만 Fake-IP는 단독 보안 스위치가 아닙니다. nameserver가 여전히 불안정한 평문 DNS를 가리키거나 프록시 노드의 도메인 조회 설정이 잘못되면 문제는 계속될 수 있습니다.
Fake-IP가 맞지 않거나 주의가 필요한 환경
LAN 장치와 기업 내부 도메인이 많은 경우
기업 내부 DNS가 git.company.test를 10.20.0.15로 조회할 수 있고, 가정용 NAS가 라우터에서 전달한 검색 도메인에 의존할 수도 있습니다. 모든 조회를 공용 DoH로 보내면 내부 도메인 조회가 바로 실패합니다. Fake-IP 할당에 성공하더라도 이후 실제 서비스를 찾을 수 없습니다.
이 경우 모든 도메인을 무작정 필터 목록에 넣지 말고 nameserver-policy로 내부 접미사에 내부 DNS를 지정해야 합니다. 예를 들어 내부 DNS가 10.20.0.53에 있다면:
dns:
enhanced-mode: fake-ip
nameserver:
- https://223.5.5.5/dns-query
nameserver-policy:
"+.company.test":
- 10.20.0.53
fake-ip-filter:
- "+.company.test"우회 라우터가 예약 대역을 완전히 회수하지 못하는 경우
라우터가 클라이언트에 Fake-IP를 반환한 뒤에는 198.18.0.0/16으로 향하는 트래픽이 mihomo를 실행하는 장치로 돌아오도록 해야 합니다. 정책 라우팅, iptables 또는 nftables 규칙에서 UDP를 빠뜨리면 웹페이지는 열리지만 QUIC, 음성 통화 또는 게임 연결이 실패하는 경우가 많습니다. 이때 TCP와 UDP가 모두 TUN 또는 투명 프록시 경로로 들어가는지 확인해야 합니다.
애플리케이션이 실제 DNS 응답을 필요로 하는 경우
네트워크 진단 도구, DNS 관리 도구, 일부 안티치트 또는 장치 검색 프로그램은 실제 A, AAAA, PTR 또는 SRV 레코드를 확인해야 할 수 있습니다. 이런 프로그램 때문에 전체를 Redir-Host로 전환하는 것은 대개 과도합니다. 먼저 해당 도메인을 필터 목록에 추가하거나 프로그램의 DNS 조회가 Clash를 우회하도록 설정하세요.
자주 발생하는 문제와 점검 순서
DNS가 198.18 주소를 반환하지만 웹페이지가 열리지 않음
- 내장 DNS만 활성화한 것이 아니라 시스템 프록시 또는 TUN도 켜져 있는지 확인하세요.
- 연결 로그에 대상 도메인이 나타나는지 확인하세요. 로그가 전혀 없다면 대개 트래픽이 코어로 들어오지 않은 것입니다.
198.18.0.0/16이 다른 VPN, 가상 머신 소프트웨어 또는 회사 라우팅에서 사용되고 있지 않은지 확인하세요.- QUIC를 임시로 끄고 TCP 443으로 비교 테스트해 UDP만 누락된 문제인지 판단하세요.
- 대상 도메인을
fake-ip-filter에 추가하세요. 즉시 복구된다면 애플리케이션 호환성 문제를 계속 점검합니다.
LAN 도메인만 열리지 않음
먼저 내부 DNS로 직접 조회하세요. 예를 들어 dig @192.168.1.1 nas.lan을 실행합니다. 192.168.1.20을 얻는다면 내부 조회는 정상입니다. 이어서 해당 접미사에 nameserver-policy를 설정하고 필터 목록에도 추가하세요. 규칙에서 사설 대역이 프록시 기본 규칙보다 앞에 있는지도 확인해야 합니다:
rules:
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- MATCH,PROXY구독 업데이트 후 설정이 되돌아감
구독은 원격 설정의 스냅샷입니다. 클라이언트가 구독을 업데이트하면 로컬에서 직접 편집한 YAML이 덮어써질 수 있습니다. 클라이언트의 오버라이드 기능에서 DNS 섹션을 관리하세요. 예를 들어 ‘설정’ → ‘구성’ → ‘전역 확장’ 또는 해당 Mixin 페이지로 이동합니다. 정확한 메뉴 이름은 클라이언트 버전에 따라 달라지지만 원칙은 같습니다. 구독에는 노드와 규칙을 저장하고, 로컬 확장에는 장치별 DNS, TUN 및 수신 포트를 저장합니다.
모드를 바꿨는데도 이전 결과가 계속 표시됨
DNS 캐시는 운영체제, 브라우저, Clash 코어의 세 계층에 존재할 수 있습니다. 먼저 설정을 다시 불러오거나 코어를 재시작한 다음 시스템 DNS 캐시를 지우고 마지막으로 브라우저를 완전히 종료하세요. Fake-IP 레코드의 TTL은 짧게 설정되는 경우가 많지만 이미 수립된 연결은 DNS 모드를 바꾼다고 즉시 다시 만들어지지 않습니다.
설정 결론: 먼저 트래픽을 가로채고 DNS를 최적화하세요
Fake-IP의 가치는 특수한 주소를 반환하는 데 있지 않고, 규칙 매칭 단계까지 도메인 정보를 안정적으로 보존하는 데 있습니다. TUN과 투명 프록시가 도메인 기준으로 트래픽을 분기하기 쉬워지고, 실제 조회를 더 적절한 네트워크 경로에서 처리할 수도 있습니다. 198.18.x.x가 보인다고 DNS 장애라는 뜻은 아닙니다. 이후 연결이 실제로 Clash 코어에 들어온다는 전제가 충족되어야 합니다.
실용적인 설정은 기본 주소 풀, 블랙리스트 필터 모드와 신뢰할 수 있는 DNS 상위 서버 두 곳에서 시작할 수 있습니다. LAN 도메인은 nameserver-policy로 처리하고 실제 주소가 필요한 도메인은 fake-ip-filter에 추가하세요. 문제가 발생하면 ‘DNS 수신 여부—조회 응답 여부—연결 가로채기 여부—규칙 매칭 여부—실제 조회 성공 여부’ 순서로 확인하는 것이 노드를 반복해서 바꾸는 것보다 빠릅니다.