Q1. 为什么会有 mihomo 这类工具?
结论: 现代网络环境的难点, 从来不只是 “能不能代理”, 而是 “不同流量该走哪条路”.
只要场景从浏览器扩展到桌面应用、命令行工具、系统服务、移动端、局域网设备, 问题就不再是单纯把流量全塞进某个代理服务器. 真正棘手的是: 哪些请求该直连, 哪些该代理, 哪些该拒绝, 哪些还要绑定特定节点或特定出口.
所以 mihomo 这类工具出现的原因, 本质上是要解决三件事: 接住流量, 识别流量, 决定流量. 代理只是其中的一种执行结果, 不是全部.
Q2. 传统方案为什么不够?
结论: 传统方案能解决 “有无代理”, 但很难解决 “精细分流”.
全局代理最简单, 但它对所有流量一视同仁. 这样虽然省事, 却会把本该直连的请求也一起送进代理链路. PAC 比全局代理聪明一点, 但它主要依赖浏览器按域名做判断, 对 APP、命令行、系统底层流量、局域网转发这些场景覆盖有限.
一旦请求来源变杂, 目标变杂, 协议变杂, 单靠浏览器脚本或一个总开关就不够了. 这时需要的是一个更靠近系统流量入口、又能按多种特征做分流决策的内核.
Q3. 用一句话怎么理解 mihomo?
结论: mihomo = 流量接管 + 特征识别 + 路由决策 + 出站执行.
它不是单一的 “节点管理器”, 也不是单纯的 “翻墙软件”. 更准确地说, 它是一个流量调度内核: 先接住请求, 再尽可能恢复请求的上下文, 然后根据规则决定这条连接该怎么处理, 最后交给对应的出站方式去执行.
所以 mihomo 关注的核心问题不是 “这条连接能不能出去”, 而是 “这条连接到底该怎么出去”.
Q4. 一条请求在 mihomo 里大致会经历什么?
结论: 一条请求通常会经历 入站 -> 域名/目标识别 -> 规则决策 -> 出站执行 这条主链路.
先看入站: 流量总得先被内核接住, 否则后续所有判断都无从谈起. 接住之后, 内核还要尽量知道 “它到底想访问谁”. 有时这一步很直接, 比如系统代理模式下应用会直接交出域名; 有时却很麻烦, 比如 TUN/透明代理场景里先看到的往往只有 IP, 这时就需要 DNS、映射表、嗅探等机制把目标重新补回来.
在目标和上下文尽量明确之后, 才进入规则阶段. 规则会综合域名、IP、进程、端口、入站、规则集等特征做判断, 最终把请求交给某个出站去执行, 例如直连、代理组、具体节点、拒绝等.
入站/出站见 2. 入站 和 出站
域名处理见 4. dns
决策逻辑见 3. 规则
Q5. 为什么 DNS 在代理体系里会变成核心问题?
结论: 因为很多分流决策依赖域名, 但内核接住流量时不一定天然拿得到域名.
在系统代理场景里, 应用往往会把域名直接交给代理内核; 但在 TUN 或透明接管场景里, 很多时候先看到的是已经解析过的 IP. 问题随之出现: 规则想按域名判断, 内核手里却只有 IP. 于是 DNS 不再只是 “查地址” 的附属工具, 而变成整个分流系统的前置依赖.
fake-ip、redir-host、sniffer 这类机制, 本质上都在回答同一个问题: 当内核没有天然拿到目标域名时, 应该如何尽量可靠地把这个上下文找回来. 这也是为什么 4. dns 会比表面看起来重要得多.