iKuai 与 OpenWrt 网络架构 2.0

博主 2023 年写了一篇 iKuai 和 OpenWrt 网络架构的文章《iKuai与Openwrt的有机结合：传统旁路由方案的完美替代》，里面介绍了如何搭建以 iKuai 作为底层、OpenWrt 作为代理从而实现国内国外网络分流的目的，从而避免了旁路由网络的缺点。

本文是它的全面重写版：核心架构不变，技术栈更新至 2026 年的现状 —— 代理层改用 Nikki（替代 OpenClash），DNS 独立成章；原理从零讲起，搭建步骤均附原理解释。读过原文的读者，可直接从第 4 章搭建部分开始。

1. 传统旁路由的弊端

我们常说的旁路由是一台与主路由并联挂进 LAN、使用固定 IP 供其他设备挂网关/DNS 的设备（可以是虚拟机）。终端把默认网关指向它后，由其统一决定转发/代理；这种方式的特征是按“谁的网关指过来”分流。

使用旁路由模式的情况下，我们一般会通过配置 DHCP 服务器将旁路由的 IP 作为网关下发给内网设备，这样就无须手动修改设备网关即可让设备进行流量代理。

但缺点也很明显：假如旁路由宕机，那么就算物理宽带正常，设备也无法正常联网，唯一的解决办法就是将设备的网关更改为主路由。

除了上述弊端，旁路由还有一个附带的小麻烦：以旁路由为网关的设备要对外暴露服务时，端口映射必须先从主路由映射到旁路由，再由旁路由转给设备（也就是绕两跳），每加一个服务都要配两层转发。

需要指正的是，原文中“旁路由=透明网关”的说法并不严谨。严格来说，旁路由是一种部署形态：一台与主路由并联挂进 LAN、以固定 IP 供其他设备挂网关/DNS 的旁挂设备；而“透明网关”是一种转发工作模式：终端零改动（连默认网关都不变），流量在网络层被透明接管。旁路由并不等同于透明网关——旁路由只是“对应用透明”（终端无需装代理），并不代表网络层透明；透明网关也不一定非要采用旁路由形态，还可以由内联桥接设备或主路由自身的透明代理实现。

2. 方案原理：按目的 IP 分流

内网以旁路由作为网关的设备，会将所有数据发送给旁路由进行处理，假设说我们可以实现将国内、境外流量进行划分，然后发送给不同的网关进行处理，那么将可以解决前面所提到的旁路由弊端。

比如，国内的流量发给运营商宽带，国外的流量发给旁路由，那么即使旁路由下线，也不会影响国内的正常流量（只要主路由不出问题），这即是本文所要实现的网络架构。

区分国内境外流量最直接的方式，就是根据 IP 来进行区分。目前 Github 上面已经有现成的国内 IP 地址数据，例如 mayaxcn/china-ip-list 和 17mon/china_ip_list ，只要数据包的目的 IP 地址不属于国内 IP 网段，那么就默认为境外数据。

iKuai 系统中有一个叫作“多线负载”的功能，可以根据目的 IP 地址实现对数据包的分流，因此本文将以 iKuai 作为主路由、OpenWrt 作为接收境外流量的另一个网关，从而实现一种既可以实现线路冗余，也可以满足流量分流的网络架构。

3. 最终架构总览

这里以最简单的架构图开始，方便读者理解：

对应的地址规划（读者可根据实际自行修改，此处仅作示例）：

角色	地址	说明
iKuai（主路由）	10.0.0.1/24	拨号、DHCP 下发、按目的 IP 分流
逻辑线路 wan2	192.168.3.2 → 192.168.3.1	主路由与代理网关之间的专用线路
OpenWrt（代理网关）	eth0：10.0.0.2； eth1：192.168.3.1	接收 wan2 转来的境外流量，由代理工具处理
内网设备	DHCP 在 10.0.0.0/24 内分配	网关、DNS 由主路由下发，零改动

我们以电脑访问一个国外网站为例，了解这套网络架构的运作过程：

解析：浏览器先向 DNS 层查询域名，拿到网站的 IP（DNS 层如何保证解析正确，见第 7 章，此处不展开）。

出网：电脑把请求发给自己的默认网关（主路由 iKuai）。电脑没有任何改动，网关、DNS 都是主路由下发的原值。

分流：iKuai 检查包里的目的 IP：属于国内网段 → 从 wan1 直接走宽带出口；属于境外网段 → 从 wan2 交给代理网关。

代理：OpenWrt 收到后，代理工具按自身规则做最终判断——该走代理的加密出站，该直连的直连。

第 4 步正是第 2 章说的二次分流判断：即使主路由的国内 IP 表偶尔不完整，最多是多绕一段，不会错得离谱（因此 iKuai 中的国内 IP 网段不需要经常性维护，这一点在后续也会说明）。

对照第 1 章的传统旁路由，可以立刻看出区别：旁路由方案里，它一挂全部设备断网；而在这里，它只是两条路之一，代理网关宕机只影响境外流量，国内流量照常从 wan1 直连，还可以靠 iKuai 的线路自动切换兜底。

最后把两种方案的优缺点放在一起看：

优点：

终端零改动，不需要为任何设备改网关/DNS（对应第 1 章的弊端一）。

端口映射单层单跳，主路由直接映射到内网服务（对应弊端二）。

国内外流量按目的 IP 直接分流，互不干扰（对应弊端三）。

可叠加 iKuai 流控与设备级管控，比如限速、指定某台设备不走代理。

代价：

国内 IP 表需要定期维护（见第 5 章）。

搭建门槛比旁路由方案高，需要先理解虚拟化与分流逻辑，动手前建议通读第 4~7 章。

4. 搭建：虚拟化层

4.1 硬件与网口规划

本章开始，将从实际物理设备出发，介绍具体的搭建过程。以下是博主的主路由设备：

硬件	规格
CPU	Intel Celeron N5105（4C/4T）
内存	32 GB
网卡	4× Intel I225-V（2.5 GbE）

这台 N5105 是博主几年前买的设备（目前仍在服役），网口规划如下：

物理口	iKuai 逻辑口	用途
eth0	wan1	宽带拨号
eth1	lan1	主 LAN（10.0.0.1/24）
eth2	（预留）
eth3	lan2	副 LAN 或其他用途

这台设备使用 iKuai 作为底层，虚拟机也是搭建在 iKuai 上。

我建议读者可以选择使用 PVE 或 ESXi 虚拟化平台作为底层，更易于维护，并且这不影响实际的架构逻辑。两张虚拟网卡的规划完全不变：第一张桥接到宿主机上与物理 LAN 口相连的网桥；第二张则和 iKuai 虚拟机追加的网卡一起，接入一块不绑定任何物理网卡的内网网桥 —— 两卡之间的主机内部链路就是 wan2。

4.2 VM 规划

VM	角色	资源	虚拟网卡
OpenWrt	代理层	2C/1G	2 张：eth0→lan1（角色 WAN）、eth1→wan2（角色 LAN，对应 192.168.3.x）
Alpine	DNS 层（PaoPaoDNS 等）	2C/4G	1 张：→lan1（10.0.0.5）

虚拟机资源分配方面，OpenWrt 本身占用资源不多（尤其是只作为代理角色），因此 1G 的内存已经足够使用；而对于 Alpine 服务器，虽然 PaoPaoDNS 官方建议家用 2G 即可，但博主这台 VM 上还同时跑着 AdGuard Home，因此分配了 4G——这类 DNS/过滤服务的缓存是内存越多命中率越高，如果读者设备 CPU 核心数和内存充足，多给一些也无妨。

4.3 wan2 的实现（虚拟 wan 口）

wan2 的本质是一条“iKuai ↔ 代理虚拟机”之间的专用线路，两端地址固定为 192.168.3.2（iKuai 侧）↔ 192.168.3.1（代理虚拟机侧）。它不需要绑定物理网口，直接绑定到 iKuai 的虚拟机网桥（Kvm Virtual Bridge Ethernet Controller）上。

创建步骤如下：

进入 wan1 口的设置，点击右侧 + 号添加 wan2；

绑定方式选择 Kvm Virtual Bridge Ethernet Controller（虚拟机网桥）；

设置 IP 地址、子网掩码和网关——网关填代理虚拟机 lan 口的 IP（具体配置见 5.2 章节）。

之后创建代理虚拟机时，把其中一张虚拟网卡桥接到这个 wan2 接口即可。

示意图：创建虚拟 wan 口

5. 搭建：iKuai 配置

虚拟机搭好之后，进入 iKuai 系统内配置。这一步是整篇文章的核心，共 6 个小节，前 5 节按顺序完成后，分流逻辑就完整了。本章不涉及 DNS 设置，DNS 在本文作为第 7 章进行单独讲解。

5.1 拨号与 lan 设置

先在 iKuai 内确认 wan1 可以正常拨号上网，lan1 按第 4 章的地址规划设置为 10.0.0.1/24。单线情况下只有一个 lan 口参与主内网，步骤简单，这里不再展开。

5.2 wan2 设置（关键）

wan2 是第 4 章里与代理虚拟机之间的那条专用线路（虚拟 wan 口，网段 192.168.3.x），配置如下（配置截图详情参考 4.3 章节）：

接入方式选择静态 IP（固定 IP）；

IP 地址填 192.168.3.2（代理虚拟机一侧是 192.168.3.1，对端固定）；

网关填代理虚拟机的 lan 口地址 192.168.3.1；

将 wan2 设置为默认网关；

开启线路检测，检测目标填代理虚拟机面向 iKuai 的地址（10.0.0.2）。

示意图：虚拟 wan 口配置

为什么要让 wan2 当默认网关？

因为 iKuai 的多线负载是“先匹配、匹配不到走默认网关”的机制：国内 IP 表负责匹配出直连流量，剩下的境外流量自然落进默认网关，把默认网关指向代理虚拟机，就等于“境外流量默认交给代理处理”。这和旁路由“改终端网关”的思路正好相反：终端什么都不用改，主路由自己就把境外流量分流出去了。

线路检测的作用是兜底：当代理虚拟机离线时，iKuai 会自动把默认线路切回 wan1，保证设备仍能正常上网（只是不能走代理）。这正是第 3 章所说“代理网关宕机不拖垮全屋”的实现机制。

5.3 添加国内 IP 表

iKuai 的多线负载功能可实现“自定义运营商”，即可以自行添加 IP 列表，然后根据 IP 列表进行流量分流。

自定义运营商：在 iKuai 官方文档定义中，每个“运营商”标签背后都对应了一批目的 IP 地址段，线路选择好运营商后，命中这批地址段的流量就从该线路出口进行转发。系统只内置了“全部/电信/联通/移动/教育”几个标准运营商，而自定义运营商允许用户自行导入一批 IP 网段（格式如 192.168.6.1/24，一行一条），把它当作一个新的运营商参与到多线负载的匹配中。

我们创建一个自定义运营商，将 mayaxcn/china-ip-list 或 17mon/china_ip_list （或任何其他的国内地址项目）国内 IP 地址段加入其中，就可以区分国内 / 境外流量。

iKuai 的自定义运营商最多只能添加 5000 条目的地址，因此需要分两次添加才能放完全部国内 IP 段（添加第二段 IP 时，运营商名称保持一致即可）

IP 列表的维护方式：我建议读者半年手动维护一次即可，不推荐使用脚本自动更新。原因有二：一是国内 IP 网段变动不大（全球 IPv4 地址枯竭，基本不会出现大变动的情况）；二是由于原因一，单独部署脚本的收益不高，还增加了维护成本和造成配置错误的风险。

5.4 添加多线负载规则

在“多线负载”中新增一条规则：

字段	值
运营商	上一步建好的自定义运营商（国内 IP）
线路	wan1（即运营商线路），负载比例 1，启用
负载模式	源 IP（或源 IP + 目的 IP，单线路下无实质差别）

这条规则的含义：目的 IP 属于国内网段的流量，一律走 wan1 直连；wan2 不需要启用负载规则，境外流量由默认网关兜底进代理。

5.5 添加防环路端口分流

如果到此为止，代理机流量会陷入回环：iKuai → wan2 → 代理 → 回 iKuai → 再次匹配多线负载 → 又回 wan2 → … 。因此需要一条端口分流规则，把代理虚拟机的出站流量直接送进运营商线路：

字段	值
分流对象	代理虚拟机面向 iKuai 的地址（10.0.0.2）
线路	wan1
负载模式	源 IP

当 iKuai 收到来自 10.0.0.2 的数据包（代理处理完毕的返回流量）时，直接走 wan1 出网，不再参与 IP 分流匹配。

示意图：防环路端口分流配置

5.6 添加 NAT 规则保留源 IP

在“网络设置 → NAT 规则”中新增一条规则：

字段	值
动作	过滤（不做 NAT）
出接口	wan2
协议	任意

如果不加这条，iKuai 会把发往 wan2 的流量做 SNAT（源地址转换）：代理虚拟机看到的所有来源 IP 都会变成 192.168.3.2（wan2 的地址），而不是内网设备的真实 IP；加上后代理侧能看到真实的设备 IP，便于后续在代理里做按设备分流/统计。

示意图：NAT 规则

小结

以上五步配置串起来就是完整的分流链路：

拨号上网 → wan2 兜底境外流量 → 国内 IP 表匹配直连 → 多线负载执行分流 → 防环规则避免代理流量回流 → NAT 规则保留真实源 IP。

6. 搭建：OpenWrt 配置

上一章在 iKuai 里完成了分流配置，本章把代理网关这一侧配起来。代理网关就是第 4 章创建的 OpenWrt 虚拟机。

需要特别说明的是，本章节的虚拟机是搭建在 iKuai 中，因此相关的设置与 iKuai 高度绑定，但如果读者能够理解其中的逻辑，那么无论是 PVE、ESXi 或其他平台都可以正确设置。

6.1 静态 IP 配置

有个容易混淆的点需读者注意：网卡角色在两个系统里是反过来的。第 4.2 节虚拟网卡表里“eth0→lan1（角色 WAN）、eth1→wan2（角色 LAN）”是 iKuai 虚拟机网桥的视角；进入 OpenWrt 系统后，这两张卡的角色反过来：

虚拟网卡（iKuai 桥接视角）	OpenWrt 内接口	IP 地址	作用
eth0 → lan1（角色 WAN）	wan	10.0.0.2/24，网关 10.0.0.1	处理完的流量回送主路由出网
eth1 → wan2（角色 LAN）	lan	192.168.3.1/24，不配网关	接收主路由 wan2 转来的境外流量

示意图：OpenWrt 虚拟机网卡配置

换句话说：面向内网（lan1）的那张卡在 OpenWrt 里当 wan，面向 wan2 的那张卡在 OpenWrt 里当 lan。理由正是第 3 章数据流第 4 步——流量从 wan2 进来（对 OpenWrt 而言是从外面进来的流量），处理完从 10.0.0.2 回 iKuai（对它而言是出去的流量）。

lan 口（192.168.3.1）：只需填 IP 地址和子网掩码，不配网关、不填 DNS，也不要开启 DHCP 服务 —— 本方案 DHCP 由主路由统一下发，OpenWrt 不承担任何地址分配。

wan 口（10.0.0.2）：填 IP 地址、子网掩码和网关（10.0.0.1）。DNS 可以先填公共 DNS（如 223.5.5.5）保证 OpenWrt 自身能解析；DNS 的正式方案见第 7 章，这里不展开。

示意图：OpenWrt 虚拟机内部网卡配置

6.2 防火墙：wan 区域开启 masquerade（关键）

这是本章最容易踩的坑，请务必照做。

在 OpenWrt 的“网络 → 防火墙 → 区域设置”中，确认 wan 口（10.0.0.2）绑定在 wan 区域、wan2 口（192.168.3.1）绑定在 lan 区域（大多数固件默认如此，没有 wan 区域就新建一个），然后在 wan 区域勾选“IP 动态伪装”（masquerade）。

为什么不勾不行？从 wan 口出站时，如果源 IP 还是内网设备的真实 IP（比如 10.0.0.50），iKuai 收到后无法区分“这是代理返回的流量”还是“新的请求”，会再次丢回 wan2，于是一个包在 10.0.0.1 和 10.0.0.2 之间无限弹跳。

这里与第 5.6 节恰好是一对：第 5.6 节让 iKuai 对进 wan2 的流量不做 NAT（保留真实源 IP 给代理侧看），本节让 OpenWrt 对出 wan 的流量做 NAT（伪装成 10.0.0.2 让主路由认得出），两个方向相反的 NAT 决策配套，整条链路才完整。

注意：“流量卸载类型”（flow offloading）建议关闭，避免可能的兼容问题。代理虚拟机负载很低，关掉没有性能损失。

6.3 代理工具

本教程代理工具用 Nikki，是 mihomo（Clash Meta 内核）在 OpenWrt 上的插件，替代原稿时代的 OpenClash，配置更轻。

这里推荐使用博主的开箱即用 Nikki 配置文件：https://github.com/JackieWuu/mihomo_config/tree/main/nikki

如果你使用博主的配置，那么 Nikki 设定 DNS 服务监听 7874 端口（和原稿 OpenClash 的 DNS 端口一致，老用户可以无缝迁移）。它与独立 DNS 层如何对接，是第 7 章的主题，这里先不展开。

配置完成后做个最小验证：在 OpenWrt 的「状态 → 终端」里执行 curl -I https://www.google.com ，能拿到 HTTP 响应头即说明代理链路通了。完整的验证与排错清单见第 8 章。

小结

代理网关只要确保三件事完成：设置好静态 IP（6.1）→ 防火墙开启 IP 动态伪装保证二次直连不回环（6.2）→ Nikki 代理流量（6.3）。

至此，OpenWrt 的路径是这样的：境外流量从 wan2 进代理网关、处理完从 10.0.0.2 回 iKuai、经防环分流上 wan1 出网。还差最后一块拼图 —— DNS。为什么 DNS 要独立成层、PaoPaoDNS 与 Nikki 怎么对接，见第 7 章。

7. DNS 独立成层

第 5、6 章配置完，分流链路已经通了，但还差最后一块拼图：DNS。第 2 章说过，本方案有一个隐含前提：分流是否正确，取决于 DNS 解析是否正确；而 DNS 由谁来解析，直接决定这套架构靠不靠得住。

7.1 为什么 DNS 不能交给代理网关

最省事的做法，是把 DNS 也交给代理网关：让 iKuai 把 DNS 指向 OpenWrt，靠代理工具的 DNS 功能防污染。早期方案正是这么做的，实践下来有两个问题：

DNS 成了新的隐患。 代理网关一出问题，全屋设备连域名都解析不了，典型症状是微信/QQ 还能收消息（它们直连 IP），网页却打不开。

与按目的 IP 分流互斥。 假如开 Fake-IP 模式：DNS 查询返回一个 198.18.x.x 的假地址。iKuai 拿到假地址判断不出国内还是境外（假地址不在国内 IP 表里），按目的 IP 分流的目的无法实现，因为所有流量都进了代理网关，等于退回旁路由模式。

虽然可以通过配置 mihomo 的 fake-ip-filter 实现 DNS 解析真实地址返回，但部署 DNS 服务器仍具有优势。

综上，DNS 必须从代理网关里拆出来，作为独立的服务运行。

7.2 推荐架构：DNS 层先分流，iKuai 层再分流

解决方案很简单：再虚拟一台 Alpine 服务器跑 PaoPaoDNS（10.0.0.5），DHCP 把内网 DNS 下发为它；PaoPaoDNS 做第一层分流，iKuai 做第二层分流，OpenWrt 只负责代理。

PaoPaoDNS 介绍（PaoPaoDNS 详细说明 | Github 仓库）

PaoPaoDNS 是一个递归 DNS 服务器，它针对 China 大陆，还有智能根据 CN 分流加密查询的功能，也可以自定义分流列表，可以自动更新 IP 库，分流使用了 mosdns 程序，加密查询使用 dnscrypt 程序，针对 IPv4/IPv6 双栈用户也有优化处理。

PaoPaoDNS 的作用就相当于你把 114 搭建在了自己家里，你再也不需要使用 114 或者 223 之类的公共 DNS 服务器了，而且解析速度比公共的 DNS 服务器更快。

但需要特别说明的是，PaoPaoDNS 会吃网络环境。以作者的两条家庭宽带为例，其中一条移动宽带是免费送的（且大内网 IP），一到晚高峰网络波动大，随之 PaoPaoDNS 在做递归的时候效果特别差；另外一条宽带是联通宽带，自费开通，PaoPaoDNS 的效果就要比移动宽带好得多。

所以如果读者的家庭网络和作者移动宽带环境类似，那也不必担心，可以通过其他方式解决，虽然效果上会稍微差一点。

PaoPaoDNS 可以通过 Docker 进行快速部署，你只需要调整好相应的变量就可以直接部署到设备上。考虑到本方案的网络架构稳定性，我没有选择将 PaoPao 搭建在 OpenWRT 里面，而是另外再虚拟化一个 Linux 系统进行部署，这样最大化稳定性。甚至如果有条件的话，读者还可以拿单独的设备去搭建 PaoPao DNS 。

Alpine 虚拟机 & PaoPaoDNS 搭建

Alpine 是一个以安全为导向的轻量级 Linux 发行版，基于 musl libc 和 busybox ，它具有体积小、资源消耗低等特点。

Apline 有专门用于虚拟机环境的 .iso 系统安装镜像（下载地址），我下载的 x86 架构的虚拟机安装镜像大小只有 60M ，非常适合用来搭建 PaoPao DNS 。

参考：安装并初始化 Alpine 的流程

由于博主使用的是 iKuai 系统，所以这里就以 iKuai 作为底层系统介绍 Alpine 虚拟机的安装过程。根据 PaoPao 作者的建议，Docker 部署下的环境要求如下：

作者：docker 的运行家用建议内存 2G ，企业环境建议 16G ，再大了意义不太大（实际内存占用差不多达到 4G 已经很厉害了，当然，内存越大性能越好，命中率体验更棒），容器启动的时候会根据可用内存调整配置文件参数，占用内存不会超过上限。根据 Github 的使用者反馈，有最低 512M 内存的 ARM 路由器流畅使用的案例。实际上，在最低参数启动下的缓存也是能满足家庭使用需求的。

根据博主自己的实际情况，我选择给 Alpine 虚拟机分配了 4G 的内存，因为同时间我还需要在 Alpine 上面搭建 Adguard Home ，如果读者的设备上有足量的内存，多分配一些也是不错的。

1️⃣ 在 iKuai 文件管理中新建一个文件夹用来存放 Alpine iso 安装镜像以及虚拟硬盘，然后获取 iso 镜像文件路径。

复制镜像文件地址：

2️⃣ 新建虚拟机

添加虚拟机：

系统类型：Linux ；

CPU 核心数：给到两核心差不多了，CPU 核心数多的话可以多给一点也无所谓；

虚拟机内存：家庭环境给到 2G 即可，其他的可以参考前面 PaoPao 作者的建议；

虚拟机光驱：将前面复制的文件路径地址粘贴到这里面；

UEFI 启动：开启。

添加虚拟硬盘：

开启“半虚拟化模式”。

虚拟硬盘给个 2G 或 3G 即可（如果你还想在 Alpine 中安装别的东西那就给多一点）。

“磁盘名称”就是存放虚拟硬盘的位置，将其存放到与 iso 镜像文件一直的路径即可，虚拟硬盘名称可以参考图片里的命名。

添加虚拟网卡：

开启虚拟机：

3️⃣ 初始化 Alpine

启动 Alpine 虚拟机之后，输入 root 会车登录到命令行界面：

接着按照下面的步骤进行系统的初始化配置：

输入 setup-apline 命令进入初始化流程。

选择选择键盘类型：输入 cn ；

选择选择键盘类型：继续输入 cn ；

配置系统 hostname ：直接回车使用默认值即可；

选择网口：按下回车键使用默认的 eth0 即可；

IP 地址获取方式：按下回车键使用 DHCP 获取 IP 地址方式；

是否需要对网络进行自定义配置：按回车使用默认值 n ，不做自定义配置；

设置 root 用户密码；

设置时区 - 1：输入 Asia ；

设置时区 - 2：输入 Shanghai ；

是否设置 http/ftp 代理：按回车使用默认值 none，不使用代理；

设置 APK 安装包镜像地址：按下回车使用默认值，我们后续再进行修改；

是否创建用户：按下回车键使用默认值 no ；

是否使用 openssh 作为 ssh 服务：按下回车使用默认值 opencssh ；

是否允许 root 用户使用密码登录：输入 yes ；

为 root 用户输入密钥或者 url 地址：按下回车键表示不设置；

选择安装盘：输入虚拟硬盘的名称（如 vda ）；

硬盘用途：输入 sys 表示用作系统盘使用；

是否清空硬盘数据并进行安装：输入 y 表示格式化硬盘并安装系统文件；

此时系统安装已经完成。

此时输入 poweroff 命令关闭系统，然后编辑 iKuai 虚拟机，把安装镜像去掉并启动 Alpine 虚拟机：

4️⃣ 配置 Apline 并安装 Docker 服务

打开虚拟机，输入 ifconfig 命令查看 Alpine 当前的 IP 地址：

（1）设置固定 IP 地址以及修改 DNS 服务器

此时可以通过 SSH 工具登录到 Alpine，然后通过下面的步骤更改为静态 IP 地址。

Alpine 自带有 vi 命令可以进行文本编辑，如果你需要使用 nano 命令，可以通过 apk add nano 来安装。

设置静态 IP 地址的格式如下：

修改好 IP 地址之后，使用下面的命令重启网络来生效：

修改下面的配置文件来修改 DNS 服务器：

可以参照下面的格式来添加公共 DNS 服务器：

如果你已经搭建了好 PaoPao DNS，那么实际上你也可以将这里的 DNS 服务器设置为本机地址（127.0.0.1），这样表示使用本机的 PaoPao DNS 服务器进行解析：

（2）更改 APK 镜像源

使用下面的命令将 Alpine 的 APK 镜像源设置为中国科技大学的镜像源：

更新 apk 安装包：

（3）安装 Docker 或 Docker-Compose

输入以下命令检查 docker 是否已经正确安装：

将 docker 服务设置为开机启动：

搭建好 Alpine 之后，参考下面的参数搭建 PaoPao DNS

docker-compose 搭建（推荐）

参数说明（更多参数请查看 Github 仓库）

CNAUTO ：是否开启 CN 大陆智能分流，如果位于境外可配置为 no ；

IPV6 ：仅在 CNAUTO=yes 时生效，是否返回 IPv6 的解析结果，默认为 no ，如果没有IPv6环境，选择 no 可以节省内存。

设置为 yes 返回 IPv6 的查询（为分流优化，非大陆双栈域名仅返回 A 记录）。
如果设置为 only6 ，则只对 IPv6 only 的域名返回 IPv6 结果。
如果设置为yes_only6，则对大陆域名返回 IPv6 的解析结果（相当于 yes ），对非大陆域名只对 IPv6 only 的域名返回 IPv6 结果（相当于 only6 ）。
如果设置为raw，则不对IPv6结果做任何处理，直接返回原始记录。

CNFALL ：仅在 CNAUTO=yes 时生效，在遇到本地递归网络质量较差的时候，递归查询是否回退到转发查询，默认为 yes 。配置为 no 可以保证更实时准确的解析，但要求网络质量稳定（尽量减少 nat 的层数），推荐部署在具备公网 IP 的一级路由下的时候设置为 no ；配置为 yes 可以兼顾解析质量和网络质量的平衡，保证长期总体的准确解析的同时兼顾短时间内网络超时的回退处理。

USE_MARK_DATA ：该项默认值为 no ，当设置为 yes 的时候，将会自动更新下载预先标记处理的全球百万域名库，在判断大陆分流的时候优先使用该数据，该功能仅标记数据，后续如何处理取决你的设置（比如默认分流或者自动转发）。域名数据库来源于 paopao-pref 项目定期更新。该功能：

优点：可以优化DNS泄漏问题、提供更快速精准高效的分流
缺点：会占用更多内存，增加容器启动时间

CUSTOM_FORWARD ：仅在 CNAUTO=yes 时生效，将 force_forward_list.txt 内的域名列表转发到到 CUSTOM_FORWARD DNS服务器。该功能可以配合第三方旁网关的 fake ip ，域名嗅探 sniffing 等特性完成简单的域名分流效果。这里的 openclash的IP地址:7874 指的是 OpenWRT 的 7874 端口，也就是 OpenClash 的 DNS 监听端口，也就是说当 PaoPao DNS 发现所请求的域名属于国外的域名时，就会将其发送给 OpenClash 进行解析：

AUTO_FORWARD_CHECK ：在 AUTO_FORWARD=yes 时，转发前是否检查域名是否有效，避免产生无效查询。默认值为 yes ，设置为 no 则不检查。

AUTO_FORWARD ：仅在 CNAUTO=yes 时生效，配合 CUSTOM_FORWARD 功能使用，默认值为 no ，当设置为 yes 的时候，解析非 CN 大陆IP的域名将会直接转发到 CUSTOM_FORWARD 所设置值的 IP 设备。

TZ ：时区。

HTTP_FILE ：http 静态文件服务器端口，设置为 yes 之后可以通过浏览器访问 http://ip:7889 访问到 PaoPao DNS 的配置文件。

DNS_SERVERNAME ：DNS的服务器名称，你使用windows的nslookup的时候会看到它。

SOCKS5 ：为分流非 CN IP 的域名优先使用 SOCKS5 查询（如 10.10.10.8:7890 ，强制使用 socks5 查询则加上 @ ，比如 @10.10.10.8:7890 ），但没有也能查，非必须项。仅在 CNAUTO=yes 时生效。SOCKS5 初始化会有大概 3 分钟的延迟连接测试过程，期间的解析结果并非最优延迟。

CN_TRACKER ：仅在 CNAUTO=yes 时生效，默认值为 yes ，当设置为 yes 的时候，强制 trackerslist.txt 里面 tracker 的域名走 dnscrypt 解析。更新数据的时候会自动下载最新的 trakcerlist 。该功能在一些场景比较有用，比如 AUTO_FORWARD 配合 fakeip 的时候可以避免使用 fakeip 连接 tracker 。

SAFEMODE ：安全模式，仅作调试使用，内存环境存在问题无法正常启动的时候尝试启用。

UPDATE ：更新的频率，此处设置为按月更新。

搭建好 PaoPao DNS 之后，你需要先给 PaoPao 指定一个固定线路出口避免被分流（参考下文的 13.4 章节内容），再通过下面的命令简单验证所有 DNS 组件是否工作正常：

如果测试正常，那么你会得到 ALL TEST PASS 的输出结果：

如果测试后提示 yy[DNS hijack]127.0.0.181yyyyyyyyyy 不影响使用

如果你遇到 127.0.0.181 这一类环回地址的 DNS 劫持报错，那么实际上这是误报，不影响正常的使用：

以访问一个国外网站为例，完整路程变为：

解析：设备向 DNS 层（10.0.0.3）查询域名。PaoPaoDNS 先本地递归解析，看解析出的 IP 属于哪边：国内网段 → 直接把真实 IP 返回给设备；境外网段 → 丢弃这个结果，把查询转给 OpenWrt 上 Nikki 的 DNS 端口（192.168.3.1:7874），Nikki 返回一个 fake-ip（198.18.x.x），由 PaoPaoDNS 转交设备。

出网：设备拿着解析结果发给默认网关 iKuai —— 设备侧依旧零改动，网关和 DNS 都是 DHCP 下发的原值。

分流：iKuai 检查目的 IP：国内 IP → 走 wan1 直连；fake-ip 不在国内网段 → 落进默认网关 wan2，交给 OpenWrt。

代理：Nikki 拦下 fake-ip 流量，凭借解析时记录的“fake-ip↔域名映射”反查出真实域名，再按代理规则决定加密出站还是直连。

总的来说：PaoPaoDNS 负责把域名分对（按解析结果归属），iKuai 负责把数据包分对（按目的 IP）。fake-ip 恰好落在中国大陆 IP 表之外，于是返回 fake-ip 就等于这条流量该进代理。也正因为域名判断提前到了 DNS 层，Fake-IP 模式不再是第 7.1 说的坑，反而成了理想选择。

容错方面：OpenWrt 宕机 → DNS 层照常工作，国内域名正常解析、正常上网，境外流量由第 5.2 节的线路检测切回 wan1，只是不能走代理。PaoPaoDNS 服务器宕机 → 全屋域名解析失败，这是本方案唯一剩下的单点隐患；想要极致冗余，可以把 PaoPaoDNS 部署到独立物理设备（如树莓派）。

7.3 完成搭建之后工作

iKuai 的 DHCP 把 DNS 下发为 10.0.0.3（PaoPaoDNS 的地址）。

给 PaoPaoDNS（10.0.0.3）加一条端口分流，固定走宽带线路出网—；权威 DNS 服务器要靠查询的源 IP 判断来自境内还是境外，如果 PaoPaoDNS 的递归查询误走代理线路，解析结果会受到影响。

关闭 iKuai DNS 加速服务：不严谨测试，我发现 iKuai 在开启 DNS 加速的情况下会影响内网 DNS 解析，作者强烈建议关闭，避免出现不明问题难以排查。

示意图：iKuai DHCP 服务器配置

示意图：PaoPaoDNS 端口分流配置

UDP 协议走宽带直连，源地址填写 DNS 服务器 IP，目的端口填 53。

测试 PaoPao 解析效果会提示 PASS

示意图：iKuai 关闭 DNS 加速功能

8. 验证与排错

8.1 第一步：DNS 验证

第 7 章反复强调，本方案的根基是 DNS 解析正确。主路由匹配的是数据包里的目的 IP，域名解析错一步，即会又大概率导致分流失效。所以验证也从 DNS 开始。在任意一台内网设备上打开命令行（Windows 的 CMD/PowerShell、macOS/Linux 的终端均可），执行两个查询：

上面的 nslookup 不带参数，用的正是设备从 DHCP 拿到的 DNS 。

预期结果：

查询	预期返回	说明
www.baidu.com	真实 IP（如 119.75.217.x）	国内域名由 PaoPaoDNS 直接递归解析，返回真实地址
www.google.com	198.18.x.x	境外域名被转给 Nikki（192.168.3.1:7874），返回 fake-ip

判别标准：

两条都符合预期 → DNS 层正常，进入第二步；

境外域名返回了真实 IP（且是国内网段）→ 解析被污染，或第 7.3 节的三件事没做全（常见坑：DHCP 没下发 10.0.0.5、强制客户端 DNS 代理没关），回去按 7.3 逐项核对；

两条都解析失败 → PaoPaoDNS 宕机或不通，这是本方案唯一剩下的单点隐患（见第 7.2 节容错），恢复后无需改任何配置。

8.2 第二步：分流验证

DNS 层确认无误后，轮到 iKuai 的分流是否真的按目的 IP 生效。在终端执行（Windows 用 tracert，macOS/Linux 用 traceroute，Linux 需自行安装该包）：

预期结果（作者实测）：

目标	预期路径	说明
www.google.com	10.0.0.1 → 10.0.0.2 → …（此后基本超时）	境外流量确实被交给了代理网关
www.baidu.com	10.0.0.1 → 运营商网关 → 一路到站	国内流量直连，全程没有 OpenWrt 的身影

判断标准：trace 境外域名时第二跳是 10.0.0.2（OpenWrt）→ 分流成功；第二跳直接是运营商网关 → 分流没生效，查 8.4 排查表。

8.3 第三步：宕机演练

第 1 章里提到过：代理网关宕机，国内流量不受影响，这是本方案的优势之一。

把 OpenWrt 虚拟机正常关机（模拟宕机）；

等待 iKuai 的线路检测发现 wan2 失联，默认线路自动切回 wan1；

验证：打开国内网站 → 正常；微信/QQ 等国内服务 → 正常；访问境外网站 → 打不开；

重新开机 OpenWrt 虚拟机，线路检测探测通过后境外访问自动恢复，全程不需要动任何配置。

对照第 1 章的传统旁路由：它一挂，全部设备断网，唯一的解决办法是手动改设备网关；如今代理网关宕机时，内网设备全程没有感知，网关、DNS 都是主路由下发的原值。

8.4 常见问题排查表

症状	可能原因（按概率排序）	排查方法
境外网站全打不开，国内正常	① 代理网关宕机 ② Nikki 未运行或订阅过期 ③ wan2 线路状态异常	查 iKuai 线路状态；在 OpenWrt 终端执行 `curl -I <https://www.google.com`>（第 6.3 节的最小验证）；重启 Nikki
分流没生效（tracert 境外域名直接见运营商）	① 默认线路不是 wan2（第 5.2 节漏做）② DNS 被污染或第 7.3 节没做全 ③ 被更高优先级的分流规则拦截（如第 5.5 节的端口分流）	按 8.1 → 8.2 顺序重验；检查默认线路设置；检查端口分流规则列表
全屋网页打不开，但微信/QQ 能收发	PaoPaoDNS 宕机（本方案唯一单点）	检查 10.0.0.5 虚拟机，恢复后无需改配置
想让某台设备不走代理	iKuai 端口分流：把该设备源 IP 固定走 wan1 直连	与第 5.5 节同款操作，分流对象改为目标设备
只有两个物理网口，能搭建吗	可以。wan2 是虚拟网口（见第 4.3 节），不占用物理口	按第 4、5 章照做即可

9. 使用体验

前面几章从原理讲到底层搭建，再到配置与验证，整条链路已经完整。这套架构博主从 2023 年一直用到现在（中间迁移过一次底层系统，见附录 A），本章说说实际用起来怎么样——对应第 3 章对比表里的承诺，看哪些兑现了。

流畅度。 分流明确之后，国内外流量各走各路：国内流量由主路由直接走宽带出口，不经过代理网关，速度就是宽带本身的速度；境外流量进代理网关加密出站，能跑多快取决于代理线路与服务商。两类流量互不挤占，不再像旁路由那样“所有流量挤一条代理链路”。

稳定性。 第 8.3 章的宕机演练已经验证过：代理网关离线时，国内流量照常，境外流量由 iKuai 的线路检测自动切回宽带直连（只是不能走代理）。这几年用下来网络基本没出过问题——博主唯一一次全屋断网是自己操作失误造成广播风暴（CPU 过载），与这套架构本身无关。

端口映射。 内网服务对外暴露时，主路由直接映射到服务所在设备，单层单跳。

可控性。 iKuai 的端口分流与流控可以直接叠加在这套架构上：想让某台设备不走代理，加一条“源地址 = 该设备”的端口分流规则指向运营商线路即可（与第 5.5 节防环规则是同一机制的正反两面）；限速、连接数限制等流控手段照常可用，博主就用连接数限制治理过一台疑似跑 PCDN 的设备。

小结

这套架构的收益是终端零改动、故障隔离、端口映射简化，代价是搭建门槛与国内 IP 表的定期维护（第 5.3 节）。对家庭网络来说，收益远大于成本。

10. 进阶：多线运营商分流

（施工中）

附录 A：演进时间线（写作中）

（待写）

附录 B：OpenClash 老用户指路（写作中）