应用产生请求
应用可能使用系统解析、自带DNS或已有地址;代理行为也由应用与环境共同决定。
Mihomo网络设置 · 技术手册NETWORK / FIELD GUIDE
像调音台上的信号通道一样,网络连接也需要清楚的入口与去向。先找到请求经过的环节,再调整对应设置。
应用可能使用系统解析、自带DNS或已有地址;代理行为也由应用与环境共同决定。
系统代理、TUN或其他入站负责接入。尚未进入Mihomo的请求,不会因规则存在而自动改道。
DNS按需要参与解析,规则判断目标与策略。命中规则之后,仍需验证远端连接。
这是概念上的分层视角;不同应用、入站与DNS模式,不一定按完全相同的顺序处理请求。

系统代理依赖应用遵循代理设置。TUN通过虚拟网络接口与系统路由处理适用流量,权限、接口和路由表缺一不可。
listen查询从哪里进入,先确认DNS模块和监听。nameserver一般域名的解析上游,不等于所有应用的系统DNS。default-nameserver解析DNS服务器自身的域名,职责不同。nameserver-policy为匹配域名选择解析服务器,影响后续处理。
缓存、应用自带DoH与系统设置,都可能改变观察结果。更换上游之前,先确认这次查询经过了哪里。

Fake-IP把域名关联到映射地址,redir-host采用不同的DNS处理行为。地址池、过滤规则与应用兼容性,需要放在同一条查询路径里理解。
理解Fake-IP与redir-host
目标域名、目标IP与规则顺序决定处理方向。DIRECT或代理策略被选中之后,出口、协议和远端服务仍然可能影响结果。
追踪请求的路由决策打印机无法发现、NAS的IP不可达、文件共享连接失败,是三个不同的问题。先区分私有地址、mDNS发现与实际服务,再决定是否调整TUN例外。
检查本地设备访问

从虚拟接口到本地设备,沿着实际现象进入对应的检查路径。

把“已启用”拆成五个可观察的状态,检查权限、虚拟接口和系统路由。
阅读技术文章 ↗
解析得到198.18开头的地址,意味着什么?从地址映射理解两种DNS模式。
阅读技术文章 ↗
换了nameserver仍然没有变化?先确认查询经过哪里,再检查字段与缓存。
阅读技术文章 ↗
从活动配置、入站证据、目标信息与顺序四个角度定位规则不生效。
阅读技术文章 ↗
打印机消失与NAS无法连接可能来自不同环节,先把三类现象分开。
阅读技术文章 ↗
核心在运行,浏览器却连接失败。按六层检查,把错误证据对应到具体阶段。
阅读技术文章 ↗一项配置只影响特定环节。准确区分现象,是排查的第一步。
配置启用、接口创建、流量进入和远端连接是不同状态。检查程序是否使用预期路径、路由是否被其他VPN改变,再查看DNS和连接错误。参考TUN虚拟接口检查。
Fake-IP是核心维护的虚拟映射,不代表网站真实公网IP,也不是用户出口IP。后续连接需要能够使用映射信息。详见地址映射机制。
应用可能使用独立DoH,查询可能命中缓存,或先匹配nameserver-policy。修改上游也不自动改变应用查询入口。沿DNS查询路径确认实际经过的环节。
先比较设备IP访问、名称访问和自动发现;核对本地子网、mDNS组播、接口选择与防火墙。公网DNS与局域网发现不同,参考局域网设备检查。