模块一 · 应用层
DNS 与 Fake-IP
你会设 DNS，但不知道你设的 DNS 有没有真的被用上。
本章要解决的问题：你会设 DNS，但不知道你设的 DNS 有没有真的被用上。
本章的证据来源：历史实测记录（四个不同 DNS 服务器返回同一个答案）
和 captures/snapshot-20261012-220243.md。
先从一个例子理解概念
你记住的是网站名字，连接时却需要目标地址。先区分“查名字得到什么”和“随后连接走哪条路”，才不会把相同答案误判成劫持。
名字与地址不同：域名与DNS
域名是example.com这样的名字；DNS（域名系统）提供名字相关记录，例如对应地址。它不只存IP，也不是替你建立网页连接的程序。
谁负责回答：递归解析器与权威服务器
客户端常把问题交给递归解析器，它利用缓存或继续查询；权威服务器提供自己负责区域的记录。不同递归解析器可以正常得到同样答案。
先用临时地址记住名字：fake-IP
某些代理返回由自己管理的假地址并维护域名映射，叫fake-IP。程序随后连接该地址时，再由代理按配置处理；假地址不是任意公网服务器地址。
进入软件接口与最终出口：TUN和分流
TUN是一种向软件交付IP包的虚拟接口；分流规则决定后续连接采用哪种出口。DNS给了fake-IP不自动证明最后走远端代理。
记录可以缓存多久：DNS TTL
DNS记录的TTL是缓存期限，常以秒计；IP头TTL限制继续转发。缩写相同但用途不同，别混成一个计时器。
下面再用这些概念看原理、命令和结果。规范与官方资料列在本章末尾，类比只帮助理解，不代替协议规则。
DNS 做的事，一句话
把域名翻译成 IP 地址。就这么简单。
细节上分两种查询方式，知道区别就行：
- 递归查询：客户端问本地 DNS「example.com 的 IP 是多少」，本地 DNS 负责一路问到答案
- 迭代查询：被问的服务器可能只回「你去问下一个服务器」，由提问方自己继续追
你的电脑只做最外层那一问（叫 stub 查询），把麻烦事交给配置里的 DNS 服务器。
本机的 DNS 配置（实测）
InterfaceAlias ServerAddresses
-------------- ---------------
FlClash {198.18.0.2}
WLAN {192.168.31.1}nslookup 也会告诉你它实际在用哪个：
Server: UnKnown
Address: 198.18.0.2注意 UnKnown：DNS 服务器地址是 198.18.0.2，是一个私有/保留地址， 反向解析不出域名，所以显示 UnKnown。这本身已经是个信号。
核心反常现象：四个不同的服务器，同一个答案
原教程分别指定系统默认、8.8.8.8、223.5.5.5和198.18.0.2查询example.com，记录中都返回198.18.0.205。
答案相同本身很正常。 多个递归解析器可以查询同一权威记录或持有相同缓存；这里值得调查的是公网域名返回了基准测试保留段地址，以及当时存在TUN代理。它们与fake-IP相容，但不能仅凭相同答案说“查询必然没到达指定服务器”。RFC 1034 §4.3
Resolve-DnsName example.com -Type A -NoHostsFile -DnsOnly
Resolve-DnsName example.com -Type A -Server 8.8.8.8 -NoHostsFile -DnsOnly
Resolve-DnsName example.com -Type A -Server 223.5.5.5 -NoHostsFile -DnsOnly指定Server只表示请求意图；透明代理、系统缓存和网络策略仍需排查。确认某个外部解析器实际收到请求，需要结合物理出口抓包、对端日志或退出代理的受控对照。
原因：Fake-IP
代理软件（Clash / mihomo 这类）常用一种叫 fake-IP 的做法。
工作方式
传统方式：
浏览器问「example.com 的 IP？」→ 真解析 → 拿到 93.184.216.34
→ 浏览器连 93.184.216.34 → 代理再根据 IP 或域名决定怎么走
→ 问题：DNS 阶段就已经把真实 IP 暴露了，且 DNS 本身可能被污染
Fake-IP 方式：
浏览器问「example.com 的 IP？」→ 代理【不解析】，直接返回假的 198.18.0.205
→ 浏览器连 198.18.0.205 → 流量进入代理的 TUN 网卡
→ 代理拿 198.18.0.205 反查出「哦，这是 example.com」
→ 此时才真正解析域名、再按规则决定直连还是走代理核心思想：把「解析」这一步推迟到连接建立的时刻， 这样代理手里同时有「域名」和「连接意图」，分流决策更准， 也绕开了本地 DNS 可能被污染的问题。
为什么假地址挑 198.18.x.x
实测确认，198.18.0.0/15 的范围是：
198.18.0.0 ~ 198.19.255.255这个网段是 RFC 2544 定义的网络设备基准测试保留段， 也被 RFC 6890 登记为特殊用途地址 （来源：ARIN whois NET-198-18-0-0-1、 RFC 6890bis 草案）。
选它的理由：198.18.0.0/15是基准测试特殊用途段，不应在公共互联网传播；但本地实验网络可能合法使用它，因此仍可能与本地地址冲突，不能说绝对不会撞车。
验证：
198.18.0.205 在 /15 内? True
198.18.0.207 在 /15 内? True
198.19.37.34 在 /15 内? True
198.20.0.1 在 /15 内? False
FlClash 网卡 198.18.0.0/30 也在 /15 内? True注意最后一行：代理自己的 TUN 网卡地址 198.18.0.1/30 也在这个 /15 里（见《IP 地址与子网划分》）。 这很方便 —— 假地址和代理网卡同属一个保留段，天然就在代理的势力范围内。
验证：流量真的进了代理
光说「假地址会被代理接管」不够，得看内核怎么决策（实测）：
Find-NetRoute -RemoteIPAddress 198.18.0.205IPAddress InterfaceAlias NextHop RouteMetric
--------- -------------- ------- -----------
198.18.0.1 FlClash
FlClash 198.18.0.2 0源地址取 198.18.0.1（FlClash 网卡），下一跳 198.18.0.2 —— 流量确实交给代理了。
再补一个细节，用最长前缀匹配算一下 198.18.0.205 命中哪条路由：
命中 0.0.0.0/0 接口=FlClash 前缀长度=0
=> 最长前缀匹配选中：0.0.0.0/0它只命中默认路由。 为什么不是 198.18.0.0/30？
因为 /30 的范围是 198.18.0.0 ~ 198.18.0.3，而 .205 早就出了这个范围。 所以假地址是走默认路由进 TUN 的 —— 这和「FlClash 那条默认路由赢了 WLAN」直接相关， 《路由与最长前缀匹配》会详细讲这场竞争。
但不是所有域名都被 Fake
历史记录：example.com和www.baidu.com得到198.18段地址，github.com得到20.205.243.166。这只说明DNS返回的地址形式不同。
DNS的fake-ip-filter和连接最终选择DIRECT/代理是不同决策。 fake-IP可经映射后直连，真实IP也可进入TUN再走代理；不能看到真实IP就断言直连，或看到fake-IP就断言一定经过远端代理。Mihomo DNS配置：fake-ip-filter、Mihomo 路由规则
历史DNS记录TTL=1表示该记录的缓存期限，与IP头中的TTL不是同一个字段。TTL=1不是fake-IP的标准判据，也不能决定连接采用哪个出口；具体映射和规则应查配置与连接日志。
谁在应答 53 端口？一个反直觉的发现
按常识，有人能回答 DNS 查询，就说明有程序在监听 53 端口。查一下：
Get-NetUDPEndpoint -LocalPort 53LocalAddress LocalPort 进程 OwningProcess
------------ --------- -- -------------
0.0.0.0 53 svchost 3960历史端点列表显示svchost监听0.0.0.0:53。 进程名本身不能确定哪个服务；通配绑定也可能覆盖本机各地址。198.18.0.2当时是TUN的下一跳地址，不是本机普通地址，本机端点表不能查询另一端实际监听情况。
但 nslookup 明明从 198.18.0.2 拿到了答案。
怎么解释？ 关键在于：198.18.0.2 不是本机地址，它是 FlClash 网段 （198.18.0.0/30）里的网关。发往它的包会被路由进 TUN 网卡（见 3.5 节的实测）， 然后由运行在用户态的代理程序从 TUN 设备直接读走并应答。
也就是说，代理根本不需要「监听 53 端口」，它靠的是接管网卡。 这也解释了为什么 Get-NetUDPEndpoint 里看不到它。
怎么判断自己被 Fake-IP 了
三条判据，从强到弱：
① 解析结果落在保留段里 198.18.0.0/15（覆盖198.18和198.19），或者代理文档里写的其他 fake-ip-range。
② 换 DNS 服务器，答案不变 不同解析器答案相同不证明fake-IP，答案不同也不能排除代理处理；要与保留段地址、配置、路由和抓包综合判断。
Find-NetRoute -RemoteIPAddress 198.18.0.205如果接口是某个 TUN / 虚拟网卡而不是你的物理网卡，基本可以确认。
排错命令速查
# 用系统默认解析器
Resolve-DnsName example.com -Type A
# 指定服务器（记住：不等于查询真的到了那里！）
Resolve-DnsName example.com -Type A -Server 8.8.8.8 -DnsOnly
nslookup example.com 8.8.8.8
# 看本机 DNS 服务器配置
Get-DnsClientServerAddress -AddressFamily IPv4
# 看 DNS 缓存（能看到近期解析过的域名和结果）
ipconfig /displaydns
# 清缓存 —— 改完 DNS 或怀疑缓存被污染时
Clear-DnsClientCache
ipconfig /flushdns
# 列出NS记录，不是完整委派链追踪
Resolve-DnsName example.com -Type NS -DnsOnly
# 完整追踪可在装有dig的Linux/WSL执行：dig +trace example.comDnsOnly限制查询为DNS，不使用LLMNR/NetBIOS；NoHostsFile另行控制hosts读取。 Resolve-DnsName没有Trace参数，列NS记录也不等于完整委派追踪。Microsoft 命令参数
本章小结
| 结论 | 性质 |
|---|---|
| 不同递归解析器可正常返回同一权威答案 | DNS机制 |
| 历史公网域名返回198.18段，与本地fake-IP处理相容 | 历史观察与推测 |
| 198.18.0.0/15覆盖198.18与198.19，仍需排除本地使用冲突 | 地址范围 |
| fake-IP过滤、TUN路由和连接出口规则不是同一决策 | Mihomo配置 |
| DNS TTL与IP TTL含义不同，TTL=1不是fake-IP标准定义 | 协议区别 |
| 本机端点列表不能证明TUN下一跳的监听和代答实现 | 证据限制 |
| Resolve-DnsName无Trace参数；完整委派追踪需相应工具 | 官方参数 |
自测题
4 题 · 先自己答，再展开对照
你用
nslookup example.com 8.8.8.8得到了结果。这能证明 8.8.8.8 可达吗？不能。 在本机（有 TUN 代理）的情况下，这个查询很可能被本地代理截获应答了。
要证明 8.8.8.8 可达，得看 8.8.8.8 那一侧的日志，或者抓包确认请求真的出去了。
本教程 3.3 节就是这个陷阱的实证：-Server 8.8.8.8返回了和代理一模一样的答案。为什么 fake-IP 要选一个"永远不在公网上出现"的网段？
该段是非全球可路由的基准测试用途段，可降低与公网服务冲突的风险；本地实验网络仍可能使用它，不能保证绝对无冲突。某域名解析出
198.18.0.7。你想知道它实际对应哪个真实 IP，该怎么办？本机直接查是查不到的 ——198.18.0.7就是个假地址，没有真实对应关系。
可行的做法：① 用不走代理的解析器查（直连的 DNS，或临时关掉代理）；
② 在代理软件的面板/日志里看它的 fake-ip 映射表；
③ 在代理进程里开启日志，观察它把该域名解析成了什么。把 DNS 改成
1.1.1.1后，解析结果完全没变。有哪些可能的原因？可能是权威记录本来相同、缓存、改错接口、DNS转发、透明代理或应用自用DNS。相同答案不是劫持证据，须核对请求来源、配置及实际出口。
参考资料与适用范围
- RFC 1034 §4.3：域名服务器、缓存与查询
- Microsoft Resolve-DnsName：完整参数与语义
- Mihomo官方DNS配置：fake-IP过滤与解析策略
- Mihomo官方路由规则：连接出口选择
修订核对日期：2026-10-13。规则按所列协议与实现范围理解；文中的原始命令输出是历史观察，不表示本次重新实测。跨版本、代理/隧道及不同捕获位置需要另行核对。