本文说明一套以“DNS 分流 + Fake-IP 静态路由”为核心的旁路由方案。

很多家庭网络一开始是这样的：

光猫 → 主路由 → 交换机 / AP → 手机、平板、电脑、电视、NAS

若把软路由直接放在光猫和主路由之间，所有流量都会经过软路由。它能实现代理，但也意味着软路由成了全网转发瓶颈；设备性能、稳定性和维护成本都会被放大。

旁路由的目标不同：只让需要代理的流量进入代理，其余流量仍由主路由直接出网。

一、传统软路由：部署在光猫之后

最常见的早期方案，是把软路由直接放在光猫之后，再连接硬路由、交换机和 AP。所有设备的流量都会先经过软路由；后面的硬路由通常只负责 Wi-Fi 和交换，也可能继续承担路由功能。

它的优点是路径直观，所有流量都由软路由统一处理；代价是软路由会成为全网性能和可用性的单点。若后面的硬路由仍处于路由模式，还可能形成双 NAT。

二、改进版软路由：接入交换机

把软路由接在主路由后的交换机上。需要代理的客户端，手动把 DNS 和默认网关改为软路由的 LAN IP；软路由的上游网关仍是主路由。

这样不用调整主路由，但每台需要代理的设备都要单独设置，而且这些设备的直连流量和代理流量仍会先经过软路由。也可以准备两个 Wi-Fi：一个下发软路由的 DNS 和网关，另一个保持主路由设置，通过切换 Wi-Fi 改变流量路径。

三、最终网络结构

旁路由接入现有 LAN，不替换主路由，也不承担普通设备的默认网关。

示例地址仅用于说明。实际部署时，10.0.0.1、10.0.1.114 和 10.0.1.120 应替换为自己的地址，并确保主路由可以路由到两个服务地址。

四、它与“把软路由放在前面”有什么不同？

传统全流量软路由：

光猫 → 软路由 → 主路由 / AP → 所有设备

旁路由：

光猫 → 主路由 → 所有设备
             └→ 旁路由（只处理 DNS 与需代理流量）

旁路由模式下，客户端默认网关始终是主路由。绝大多数不需要代理的连接，路径没有变化，因此：

• 不需要逐台设备修改默认网关；
• 不需要为了直连或代理来回切换 Wi-Fi；
• 旁路由只承载 DNS 和需要代理的流量；
• 主路由、交换机和 AP 的既有结构可以保持不变。

五、核心原理：三项服务、两项主路由设置

1. 三项服务

这套方案通常由三个组件构成。它们可以部署在同一台小主机或 NAS，也可以像本文示例一样拆分为 DNS 主机和代理主机。

• AdGuard Home：为局域网提供 DNS 缓存、广告拦截和统一的 DNS 入口。
• MosDNS：按域名规则选择解析路径。
• Mihomo / Surge / Clash 类代理核心：处理代理连接，并提供 Fake-IP DNS 解析。

典型的 DNS 链路如下：

客户端 → AdGuard Home → MosDNS
                         ├─ 直连域名 → 常规 DNS → 真实 IP
                         └─ 代理域名 → Mihomo Fake-IP DNS → 198.18.0.0/15

这里需要区分两个动作：

1. MosDNS 负责判断域名该直连还是代理。
2. Fake-IP 通常由代理核心的 DNS 功能生成。 MosDNS 将需要代理的域名转发给该 DNS 上游后，客户端才会得到 198.18.0.0/15 这类虚拟地址。

代理核心会保存“Fake-IP 与真实域名”的对应关系。后续连接到该 Fake-IP 时，它能够还原域名并按规则转发。

2. 主路由只需要做两项设置

假设：

• 主路由 LAN 地址：10.0.0.1
• AdGuard Home DNS 地址：10.0.1.114
• 代理核心地址：10.0.1.120
• Fake-IP 网段：198.18.0.0/15

则在主路由中设置：

1. LAN / DHCP DNS：下发 10.0.1.114 给客户端。
2. 静态路由：目的网段为 198.18.0.0/15，下一跳为 10.0.1.120。

不要把 DHCP 默认网关改为旁路由；客户端的默认网关仍然是 10.0.0.1。

六、一次访问是如何走的？

访问不需要代理的网站

1. 客户端向 AdGuard Home 查询域名；
2. MosDNS 判断该域名走直连 DNS；
3. 客户端拿到真实 IP；
4. 客户端把流量交给默认网关，也就是主路由；
5. 主路由直接出网。

访问需要代理的网站

1. 客户端向 AdGuard Home 查询域名；
2. MosDNS 将该查询交给 Mihomo / Surge 的 Fake-IP DNS；
3. 客户端拿到 198.18.0.0/15 内的 Fake-IP；
4. 客户端仍把流量交给默认网关主路由；
5. 主路由命中静态路由，将此流量转交给 10.0.1.120；
6. 代理核心识别 Fake-IP 对应的域名，并通过代理出口访问目标站点。

因此，网络结构没有被改造成“所有流量先经过软路由”；只有 Fake-IP 段的流量才会被导向代理核心。

七、硬件怎么选？

选择硬件时，应按“需要代理的并发流量”和“是否还承载 DNS”等实际负载决定，而不是只看网口数量。

• 低负载 / 入门：网心云 OEC 这类 ARM 小主机可用于 DNS 与轻量代理。
• 小体积：NanoPi R28S 一类双千兆 ARM 设备。
• 性能优先：NanoPi R76S 一类较新的 ARM 设备，适合更高的代理吞吐与更多规则。
• 多网口需求：EasyPi R1 Pro 一类带多个 1G / 2.5G 网口的设备，适合需要多网段或多线路的场景。
• 高性能代理：Mac mini 可以运行 Surge 或 Mihomo，适合承担高吞吐代理。它虽然也能部署 AdGuard Home 和 MosDNS，但若不能为 DNS 服务提供独立的 LAN IP，就不适合作为局域网统一 DNS 的服务地址；因此这里将它定位为代理主机。

可选系统包括 Armbian、Debian、Ubuntu，以及 NAS 系统上的容器环境。实现本方案的重点不在系统名称，而在于 DNS 链路、Fake-IP 路由和代理核心三者能正确协作。

八、部署建议

1. 先只部署 AdGuard Home，确认局域网 DNS 下发和解析正常。
2. 再加入 MosDNS，验证直连域名仍能返回真实 IP。
3. 启用代理核心的 Fake-IP DNS，并用一个明确需要代理的测试域名确认返回地址位于 198.18.0.0/15。
4. 最后在主路由添加该网段的静态路由，验证 Fake-IP 流量确实到达代理核心。
5. IPv6 应单独设计：若客户端优先获得真实 AAAA 记录，可能绕过 IPv4 Fake-IP 分流。部署时应明确 IPv6 的 DNS、路由与代理策略，而不是默认沿用 IPv4 配置。

九、个人部署参考

我目前的组合是：

• 主站：UniFi UDM Beast + 飞牛（硬酷 R2 Max）+ Mac mini M4 16GB；
• 另外三处宽带：UniFi UDM SE / UCG Ultra / UX7 + 飞牛或网心云 OEC（Armbian）；
• 主站另有一台 NanoPi R76S，运行第二套 AdGuard Home + MosDNS，作为 DNS 备用。

这套模式已稳定运行一年多。实际使用中，备用 DNS 更多是为了覆盖 NAS 重启的短暂窗口；若主机本身很稳定，是否部署备用节点应根据自己的可用性要求决定。

部署脚本与菜单化管理工具：yehbp。

十、外出场景的一体化设备

外出时，同样可以采用本文的 DNS 分流、Fake-IP 和静态路由方案。基于 OpenWrt 的 CPE，例如 GL.iNet Mudi 7 一类产品，可以把蜂窝网络、主路由、AdGuard Home / MosDNS、Mihomo 以及 Wi-Fi AP 集成在一台设备中。网络功能被合并部署，但分流原理不变；是否适合取决于你的吞吐需求和出行时的网络需求。