软路由是什么，谁真正需要它
"软路由"这个词经常出现在各类极客论坛和硬件评测里，但许多人对它的实际定位其实是模糊的。简单来说，软路由是一台跑着路由器操作系统的通用计算机——它可以是一台 x86 工控机、一台 ARM 开发板，甚至是虚拟机里的一个实例。与传统消费级路由器相比，软路由最大的不同不在于硬件，而在于它可以运行完整的 Linux 发行版，允许用户安装任意软件包，把路由器变成一个可编程的网络节点。
普通消费级路由器（比如小米、TP-Link）的固件是封闭的，厂商提供什么功能就只有什么功能，用户几乎无法干预底层行为。软路由则不同——在 OpenWrt 环境下，你可以精确控制每一条流量的走向：哪些流量直连，哪些走代理隧道，哪些打 QoS 标记，甚至可以对不同 VLAN 施加完全不同的策略。
那么，谁真正需要软路由？以下几类家庭场景比较契合：
- 家里有多台"哑设备"：Apple TV、智能电视、游戏主机（PS5、Switch）这些设备本身不能安装代理客户端，要让它们走代理，只能在网关层统一处理。
- 希望全家流量零配置自动分流：不想在每台手机、电脑上分别安装客户端，软路由可以做到设备接入 Wi-Fi 就自动享受透明代理。
- 有 NAS、有服务器、需要精细化网络管理：比如 NAS 走直连降低延迟、工作电脑走代理、内网开发设备走独立 VLAN。
- 有一定折腾能力和时间：软路由不是"买来即用"的产品，配置过程需要对 Linux 网络有基本了解。
如果你只是一个人用电脑偶尔看 YouTube，在电脑上装一个 Clash 客户端 就已经够用，完全没必要引入软路由的复杂度。
OpenWrt 系统简介：它运行在什么硬件上
OpenWrt 是目前最流行的开源路由器操作系统，基于 Linux 内核，有着成熟的包管理系统（opkg），社区维护了大量扩展插件。它最早为嵌入式路由器设计，但如今已经能良好运行在各类硬件平台上。
x86 工控机是目前软路由圈最主流的选择。N100、N5105 这类低功耗 Intel 处理器工控机，具备 2 到 4 个 2.5G 网口，满载功耗不超过 15W，性价比突出。这类机器运行 OpenWrt 的 x86_64 固件，与标准 PC 架构完全兼容，安装过程类似装普通 Linux。
ARM 开发板方面，Rockchip RK3588 平台的 NanoPi R6S、友善 R4S（RK3399）是常见选择。R4S 双核 A72 + 四核 A53，内存 4GB，有两个 USB 3.0 和两个千兆口，足以运行 OpenClash + SmartDNS 的完整组合。AX6000（Redmi AX6000）等家用路由器也可以刷入 OpenWrt，但受限于 flash 和 RAM 容量，可安装的插件数量有限。
虚拟机部署也是企业和高阶用户常用方式：在 PVE（Proxmox VE）或 ESXi 上跑 OpenWrt 虚拟机，可以充分利用物理机的硬件资源，同时灵活调整 CPU 和内存分配。虚拟网卡直通是这类部署的关键技术点。
选择硬件时有一个务实原则：如果你只用 PassWall 跑少量节点，N100 工控机绰绰有余；如果要跑 OpenClash + 大量规则集 + SmartDNS + AdGuardHome，建议至少选 4 核处理器和 2GB 内存，否则规则加载和 DNS 查询会出现明显卡顿。
主路由 vs 旁路由：两种部署方式的实际区别
在家庭网络里部署软路由，最先需要做的决定是：让软路由当主路由，还是以旁路由（旁挂网关）方式接入。这两种部署的网络拓扑完全不同，各有适用场景。
主路由模式
光猫（或 ONU）→ 软路由 → 交换机 / AP
软路由直接承担 PPPoE 拨号（或 DHCP 上联）、DHCP 分配、NAT 转换等所有核心路由任务。所有家庭设备的网关都指向软路由，流量必然经过软路由处理。
优点：拓扑清晰，流量路径最短，透明代理效果最佳，不存在"双重 NAT"问题。缺点：软路由一旦崩溃或配置出错，全家断网。对稳定性要求更高，建议先在测试环境中完成调试再上线。
旁路由模式
光猫/主路由 → 交换机 → 旁路由（同时连接到交换机作为普通设备）
旁路由本身不承担 PPPoE 或 DHCP 主分配，而是将自己的 IP 设置为局域网某台设备的网关，或通过主路由的 DHCP 选项把全网的"默认网关"和"DNS"都指向旁路由。
优点：主路由继续工作，旁路由挂了顶多代理失效，局域网通信基本不受影响。适合"家里有人不允许动主路由"的场景，也适合在已有成熟 Wi-Fi 系统（Mesh AP）上叠加代理功能。
缺点：流量需要多走一跳，路由配置容易出错（最常见的就是旁路由不生效），且双重 NAT 在某些场景下会影响 UPnP 和 P2P 连接。
对于初次尝试软路由的用户，建议先从旁路由开始，风险更低。等熟悉 OpenWrt 网络配置后，再考虑换成主路由模式。
OpenClash 插件详解：以 Mihomo 为内核的完整代理方案
OpenClash 是 OpenWrt 上最知名的科学上网插件之一，本质上是将 Mihomo（原 Clash Meta）内核打包进 OpenWrt，并提供一套 Web UI 来管理配置。如果你曾经在 Windows 或 macOS 上用过 Clash Verge 或 Mihomo Party，OpenClash 的逻辑与它们高度一致。
关于 Clash 工作原理的底层逻辑，可以参考这篇 Clash 模式解析，理解规则分流与代理模式的区别有助于正确配置 OpenClash。
OpenClash 的核心能力
订阅管理：支持导入标准 Clash YAML 订阅，也支持通过内置的订阅转换器（Sub-Converter）将 SIP002、Trojan、VLESS 等格式转为 Clash 配置。
规则分流：这是 OpenClash 的核心卖点。用户可以使用 GeoIP 数据库、DOMAIN-SUFFIX、IP-CIDR 等多种匹配方式，精确控制每一条流量的出口。社区维护的 Loyalsoldier/clash-rules 规则集可以直接引用，涵盖广告拦截、国内直连、流媒体解锁等分类。策略组（proxy-group）支持 url-test、fallback、load-balance 等多种选择策略，可以针对 Netflix、ChatGPT 等服务单独配置出口节点。
透明代理：OpenClash 支持在 iptables/nftables 层面拦截所有经过软路由的流量，无需在每台设备上配置代理。局域网内任何设备只要网关指向软路由，就自动享受分流效果。
Fake-IP 与 Real-IP 模式：Fake-IP 模式下 DNS 响应延迟极低（直接返回保留地址段），适合追求响应速度的日常使用；Real-IP 模式则在真实 DNS 解析完成后再路由，更适合对 IP 一致性有要求的场景（如部分游戏服务）。
外部控制面板：OpenClash 内置了 Yacd 或 Meta Cube 等 Web 面板，可以实时查看节点延迟、切换策略组、查看流量日志，操作直观。
OpenClash 的局限
OpenClash 的配置文件是标准 Clash YAML，这意味着 provider 语法、策略组嵌套、rule-set 引用这些高级用法都需要用户具备一定的 YAML 编辑能力。另外，Mihomo 内核本身占用内存不小，加载完整规则集后可能需要 200–400MB 内存，低端设备要认真评估。
PassWall 与 PassWall2 插件详解：轻量灵活的多协议方案
PassWall 是另一个在 OpenWrt 社区非常活跃的科学上网插件，与 OpenClash 的思路截然不同。它不依赖单一内核，而是作为一个"协议调度层"，根据用户配置调用底层的 Xray、Sing-box 或 Hysteria 可执行文件来处理不同协议的连接。
PassWall2 是 PassWall 的分支版本，在节点管理和 UI 交互上做了优化，支持更多新兴协议（如 TUIC、Hysteria2）和更灵活的分组配置，二者逻辑相近，本文统称 PassWall。
PassWall 的核心能力
协议覆盖广：Shadowsocks、ShadowsocksR、Trojan、VLESS（含 XTLS/Reality）、VMess、Hysteria2、Naive、Brook 等协议均可支持，背后调用对应的可执行文件处理。这意味着即使机场订阅里有各种较新协议，PassWall 也能直接添加节点使用。
节点管理直观：PassWall 的 Web UI 以单节点为核心，用户可以手动填写服务器地址、端口、协议参数，也可以通过订阅链接批量导入。界面风格接近传统路由器管理页，对不熟悉 YAML 的用户来说门槛相对低。
分流规则简洁：PassWall 的分流规则基于内置的 dnsmasq 规则集和 ipset/nftset，把被墙域名走代理、国内域名直连这一逻辑处理得比较轻量。虽然规则灵活性不如 Clash 的 YAML 语法，但对于普通用户来说已经足够日用。
资源占用低：因为不需要常驻一个完整的 Clash 进程，PassWall 的内存占用通常更小。在 256MB RAM 的低端路由器上，PassWall + Xray 的组合依然可以稳定运行；而 OpenClash + Mihomo 在同样硬件上可能会显得吃力。
PassWall 的局限
PassWall 没有 Clash 那样成熟的策略组系统，无法做到"对同一个目标域名，根据时段或延迟自动在多个节点之间切换"这类精细操作。规则集的颗粒度也比 Clash 的 rule-set 系统粗一些。如果你的机场订阅格式是标准 Clash YAML，还需要额外转换或手动填写节点信息。
OpenClash vs PassWall：如何做出选择
这是很多人在部署软路由时最纠结的问题。以下是一个务实的对比框架：
| 维度 | OpenClash | PassWall | |------|-----------|----------| | 内核 | Mihomo（Clash Meta） | Xray / Sing-box / Hysteria（多内核） | | 订阅兼容 | 标准 Clash YAML 最佳 | 多格式，手动节点更灵活 | | 规则分流 | 强大，支持完整策略组 | 基础，满足日常分流 | | 内存占用 | 较高（200MB+） | 较低（50–150MB） | | 配置复杂度 | 较高，需懂 YAML | 较低，Web UI 即可完成 | | 适合人群 | 有折腾经验、追求精细分流 | 快速上手、设备性能一般 | | 新协议支持 | 跟随 Mihomo 更新 | 覆盖更广（Hysteria2、TUIC 等） |
建议选 OpenClash 的情况：你的机场提供标准 Clash YAML 订阅；你需要为 Netflix、Disney+、ChatGPT 等服务配置独立的节点策略组；你的设备内存在 1GB 以上；你愿意花时间调整 YAML 配置文件获得更精确的分流效果。
建议选 PassWall 的情况：你的设备内存只有 256–512MB；你的机场提供的是 SIP008 或原始节点信息，不是 Clash 格式；你希望尽快上手，不想研究 YAML 语法；你需要用 VLESS+Reality 或 Hysteria2 这类较新的协议，且希望在图形界面里直接配置。
两者并不互斥——有经验的用户也可以同时安装，在不同时期切换使用，但同时启用两个插件会导致 iptables 规则冲突，需要避免。
透明代理：为什么软路由用户如此青睐它
透明代理（Transparent Proxy）是软路由科学上网方案最核心的优势所在。所谓"透明"，指的是客户端设备完全感知不到代理的存在——设备既不需要配置代理地址，也不需要安装任何软件，流量在到达软路由时已经被自动分类处理。
从技术角度，透明代理通过 iptables（或 nftables）的 PREROUTING 链拦截所有经过软路由的 TCP/UDP 流量，根据目标 IP 或域名的分类，决定是交给 Xray/Mihomo 进程处理（走代理），还是直接放行（直连）。整个过程对源设备完全不可见。
这一机制对家庭网络的实际意义是：Apple TV 连上 Wi-Fi，打开 Disney+ 直接看，不需要在电视上配置任何代理；PS5 或 Nintendo Switch 联机游戏，出口 IP 可以根据规则自动选择合适节点；智能家居设备、IoT 设备也受到统一的网络策略保护；局域网内所有 Android 或 iOS 设备无需单独配置，新设备加入即生效。
关于 Apple TV 在透明代理环境下的具体使用体验，可以参考这篇配置建议了解机场节点选型和网络架构的配合要点。
DNS 防泄漏配置：dnsmasq 与防污染实践
DNS 是软路由代理方案里最容易被忽视、也最容易出问题的环节。即使代理隧道完全正常，一个配置错误的 DNS 就能让整个方案失效，甚至导致访问历史外泄。
DNS 污染的本质：当你访问一个被墙域名时，GFW 会在真实 DNS 响应抵达之前率先返回一个虚假 IP（通常是不可用地址），导致解析结果直接错误。即使流量走了代理，如果 DNS 先被污染，浏览器拿到错误 IP 后会把连接请求发往错误地址，代理自然无效。
OpenClash 的处理方式：在 Fake-IP 模式下，OpenClash 接管局域网的 DNS 请求，对所有被代理的域名返回一个虚拟 IP（如 198.18.0.x），同时在内部维护一张"虚拟 IP → 真实域名"的映射表。当流量抵达代理内核时，内核通过这张映射表还原出真实域名，再由远端节点进行真实解析。这样不仅绕过了 DNS 污染，还能让代理规则基于域名而非 IP 做判断，更精准。
PassWall 的处理方式：PassWall 通常依赖 dnsmasq + ChinaList 的组合。国内域名走运营商 DNS（或 114）直接解析，其余域名走一个加密的上游（如通过代理隧道查询 8.8.8.8，或使用 DoH）。这种方式可靠性略低于 Fake-IP，但配置相对简单，在资源有限的设备上运行稳定。
通用防泄漏建议：
- 不要把路由器的上游 DNS 直接设为运营商提供的 DNS（如
114.114.114.114），这类 DNS 对被墙域名有可能直接返回污染结果 - 为代理内核配置一个可信的境外 DNS（建议走 DNS over HTTPS 或 DNS over TLS），并确保该 DNS 查询本身也经过代理隧道
- 启用 SmartDNS 或 AdGuardHome 作为本地 DNS 中间层，可以进一步提升解析速度和准确性
- 定期检查是否有 DNS 泄漏：访问
dnsleaktest.com或ipleak.net，确认查询只显示境外出口的 DNS 服务器
TProxy 模式与 TUN 模式的区别
在透明代理的实现层面，OpenClash 和 PassWall 都提供了不止一种工作模式。两个最核心的选项是 TProxy（透明代理模式）和 TUN（虚拟网卡模式），选错了会导致 UDP 丢包、游戏延迟高或某些 App 无法走代理。
TProxy 模式
TProxy 是在 Linux iptables 层面实现的透明代理机制，工作在网络层（第三层）。它通过 TPROXY target 将流量重定向到本地监听端口，代理进程以原始目标地址为目标建立出站连接。
优点：TCP 和 UDP 都能处理，性能开销小，延迟低，是软路由透明代理的推荐模式。缺点：需要 Linux 内核支持 TPROXY 模块，部分老旧固件可能缺少此模块；iptables 规则链较复杂，排查问题时需要一定经验。
TUN 模式
TUN（Tunnel）模式是在操作系统中创建一个虚拟网络接口（如 utun0），代理进程接管发往该接口的所有 IP 包。软路由将所有需要代理的流量路由到这个虚拟接口，由代理进程统一处理后发出。
优点：兼容性好，几乎不依赖 iptables 细节；对 ICMP 和部分游戏协议的透明处理更完整。缺点：每个数据包需要额外经历用户态/内核态的复制，吞吐量和延迟略逊于 TProxy；高并发场景下 CPU 占用更高。
选择建议：日常科学上网优先用 TProxy，性能更好；如果 TProxy 出现 UDP 不通或特定 App 无法代理的问题，可以切换到 TUN 模式尝试解决。OpenClash 在 Meta 内核下同时支持两种模式，可以在插件设置里切换；PassWall 则通过底层调用 Xray 的 dokodemo-door 或 Sing-box 的 tun 入站来实现。
家庭设备全自动代理：哪些设备最受益
软路由透明代理方案最能发挥价值的，往往是那些"本身没有代理能力"的设备。
Apple TV：这是促使很多人购买软路由的直接原因之一。Apple TV 的 tvOS 不支持安装代理 App，也没有系统级代理设置。唯一可行的方案是网关层的透明代理——这正是软路由的用武之地。Apple TV 4K 接入家庭 Wi-Fi 后，Netflix、Disney+、Apple TV+ 的流量会自动根据规则分流，无需任何额外操作。
游戏主机：PS5 联机时，部分服务器（如北美 PSN）走代理能降低延迟；Nintendo Switch 的某些区域限定 eShop 内容需要特定出口 IP。软路由可以针对游戏主机的 MAC 地址单独设置策略，与其他设备的流量策略完全隔离。
智能电视和电视盒子：国产安卓盒子和智能电视通常无法安装科学上网 App，或即使安装了也只有 App 内流量走代理。透明代理让这类设备访问 YouTube、Twitch 成为可能。
NAS：Synology、群晖等 NAS 设备在访问 GitHub、DockerHub、Backblaze 等境外服务时，走透明代理可以显著改善速度。让软路由统一处理比在 NAS 上额外折腾代理更简洁，也方便统一管理。
IoT 设备：智能家居设备的 OTA 更新服务器有时在境外，透明代理可以在不影响正常局域网通信的前提下让这些更新顺利完成，无需手动介入。
性能要求：CPU 与内存对代理能力的影响
选择软路由硬件时，许多人只看"能不能跑 OpenWrt"，而忽略了"跑多少节点、跑什么协议"对性能的实际需求。
CPU 的影响：代理协议的加解密是 CPU 密集型操作。VLESS+Reality 和 Trojan 依赖 TLS 握手，对单核性能有要求；Hysteria2 和 TUIC 基于 QUIC（UDP），对 CPU 的并发处理能力要求更高。如果同时跑 10 个以上节点的自动测速（URL-test），后台的探测请求也会持续消耗 CPU，可能影响实际转发性能。
内存的影响：OpenClash 加载完整的 Mihomo 配置（包含大量规则 + GeoIP 数据库 + GeoSite 数据库）通常需要 300–500MB 内存。PassWall + Xray 的组合则轻量得多，基础运行约 50–100MB，加上 nftset 规则集也很少超过 200MB。
实际参考配置：
- 入门级（N100 / RK3399，2GB RAM）：跑 OpenClash + SmartDNS，日常家庭使用无压力
- 中档（N5105 / RK3588，4GB RAM）：完整规则集 + AdGuardHome + 旁路由模式，流畅运行
- 高端（i5/i7 小主机，8GB+ RAM）：同时运行 OpenWrt 虚拟机 + NAS + 其他服务，代理只是其中一个功能
如果你打算用专线（IPLC/IEPL）节点，可以阅读这篇专线解析文章了解专线节点的延迟特性和适合的使用场景。
常见故障与排查思路
部署 OpenWrt + 代理插件的过程中，以下几类问题出现频率最高，每一类都有其特定的排查路径。
插件安装失败（opkg 报错）：最常见原因是 opkg 源不可用，或固件版本与插件不兼容。先执行 opkg update 确认源可达；如果报 SSL 错误，通常是系统时间不同步导致，执行 ntpdate -u ntp.aliyun.com 同步时间后重试。手动安装 .ipk 文件时，注意 CPU 架构（x86_64 和 aarch64 的包不通用）。
旁路由模式不生效：这是旁路由部署里最高频的问题。根本原因几乎都是回程路由不对：旁路由收到流量、处理完之后，回包没有经过旁路由原路返回，而是直接从主路由出去了，导致会话状态不一致。解决方法是在旁路由上确认默认网关设置，同时确保主路由的 DHCP 已将"默认网关"选项改为旁路由 IP，所有设备重新申请 IP 后生效。
DNS 污染导致代理形同虚设：症状是：ping 境外域名解析到国内 IP，或代理开着但 YouTube 打不开。检查方法：在客户端设备上执行 nslookup google.com 旁路由IP，如果返回的是污染 IP（如 127.0.0.1 或随机国内 IP），说明 DNS 没有走代理内核处理。OpenClash 用户检查"DNS 设置"页是否启用了"追加上游 DNS"且上游走了代理；PassWall 用户检查是否开启了"代理 DNS"选项。
UDP 流量无法代理（游戏、视频通话卡顿）：部分协议（如 QUIC、DNS over UDP）在 TProxy 模式下需要额外配置。确认 Xray 或 Mihomo 配置里的 UDP 拦截已开启；同时检查 iptables 规则是否有漏掉 UDP 的部分。切换到 TUN 模式通常可以快速验证是否是 TProxy 配置问题。
OpenClash 内存占用过高，路由器频繁重启：尝试精简规则集——删除不需要的广告拦截规则（改用 AdGuardHome 处理）；关闭高频的 GeoIP/GeoSite 数据库自动更新定时任务；将策略组中的 URL-test 探测间隔从默认的 3 分钟改为 30 分钟，减少后台请求频率。
软路由不适合哪些人（需要提前说清楚）
软路由圈子有一种氛围，让人觉得"不用软路由就是落后"。但现实是，软路由对多数普通用户来说是过度方案，带来的麻烦可能远大于收益：
只有一台设备：用 Clash Verge 或 Mihomo Party 在电脑上直接跑，效果不输软路由，配置难度低一个数量级，出问题的概率也小得多。
租房住，没有自己的路由器：无法部署主路由，旁路由在租房环境里接线麻烦且不稳定，每次搬家都要重新折腾。
不会使用 SSH 或 Linux 命令行：OpenWrt 出问题时，命令行是唯一的排查手段。不熟悉 Linux 的用户遇到故障会非常被动，搜索到的教程也大多假设用户有基本命令行能力。
预算有限且需求单一：一台 N100 工控机裸机要 300–500 元，再加上固件、调试时间成本，如果需求只是让一台电脑翻墙，这个投入并不合算。
家庭成员对断网零容忍：软路由调试期间难免出现配置错误导致断网，如果家里有人在视频会议或在线直播，这类风险需要提前充分沟通。
总结：如果你家里有 Apple TV、游戏主机、NAS，或者有多台设备想统一管理代理，软路由的价值就非常明显。否则，先从适合自己的客户端工具入手，用熟了再考虑是否升级到软路由方案，是更理性的路径。新手可以参考新手快速上手指南选择适合自己当前阶段的方式。
常见问题解答（FAQ）
Q1：OpenClash 和 PassWall 可以同时启用吗？
可以同时安装，但不能同时启用。两个插件都会向 iptables 写入流量拦截规则，同时运行会导致规则冲突，表现为流量被重复处理、某些设备代理失效或完全断网。在切换插件前，务必先把当前使用的插件完全停止（关闭服务），再启动另一个。
Q2：旁路由的 IP 应该怎么设置？
旁路由应该使用与主路由同一网段的静态 IP，不要让主路由通过 DHCP 动态分配给它（否则重启后 IP 可能变化，导致全网断网）。例如主路由是 192.168.1.1，旁路由可以设为 192.168.1.2，子网掩码 255.255.255.0，网关和 DNS 都填主路由 IP。在 OpenWrt 的网络接口设置里，将 LAN 接口设为静态协议，填入上述参数即可。禁用旁路由的 DHCP 服务，避免与主路由冲突。
Q3：OpenClash 订阅更新失败怎么处理？
先确认软路由本身的网络是否正常（能否 ping 通外网）。如果软路由本身没有出口，更新当然会失败。常见解法是：在 OpenClash 的覆写设置里启用"允许 LAN 代理请求"后重试；或者在订阅 URL 前加上 Sub-Converter 的代理前缀；或者手动下载配置文件后通过 SFTP 上传到 /etc/openclash/ 目录，再在界面里选择本地文件。
Q4：PassWall 支持导入 Clash 格式的订阅吗？
原生支持有限。PassWall 的订阅解析器可以识别 SIP002（Shadowsocks）格式和部分 Base64 编码的节点列表，但 Clash YAML 里的策略组、规则集等信息会被忽略，只提取其中的节点信息。如果机场只提供 Clash 订阅格式，建议通过 Sub-Converter 转换一次，或者切换到 OpenClash 插件。
Q5：软路由会对家庭网速产生多大影响？
理论上有影响，实际很小。TProxy 模式下，单纯转发流量的额外延迟在微秒级，对千兆家宽几乎无感知。主要瓶颈来自协议加解密的 CPU 消耗：跑 Hysteria2 在弱 CPU 上高并发时会出现 CPU 瓶颈，表现为大文件下载速度上不去。N100 及以上的处理器在家庭宽带（500Mbps 以内）场景下通常不会成为瓶颈。
Q6：OpenWrt 上能使用 Reality 协议吗？
可以。PassWall2 内置了对 Xray 的调用，而 Xray 完整支持 VLESS + XTLS-Reality 协议。在 PassWall2 的节点添加页面，选择协议为 VLESS，传输方式选 TCP，安全选 Reality，然后填入 serverName、publicKey、shortId 等参数即可。OpenClash 则需要依赖 Mihomo 内核的 VLESS-Reality 支持，在 Meta 版内核中可用，但需要手动编写节点的 YAML 配置。
Q7：旁路由模式下局域网设备间的访问速度会变慢吗？
不会，前提是配置正确。局域网内设备之间的通信（如 PC 访问 NAS）走的是直接的二层交换，不经过旁路由。只有发往外网的流量才会经过旁路由处理。如果你发现局域网内通信变慢，通常是因为旁路由的路由表配置有误，把局域网流量也路由进了代理进程，检查旁路由的 LAN 接口路由表，确认局域网直连规则是否正确配置。
Q8：OpenClash 的 Fake-IP 模式会影响哪些应用？
极少数应用在 Fake-IP 模式下表现异常。常见症状包括：某些游戏服务器报"区域限制"（因为 DNS 没有返回真实 IP，服务端验证出错）；某些 P2P 软件（如 BitTorrent 客户端）无法正常连接 tracker。解决方法是在 Fake-IP 的过滤列表（fake-ip-filter）里加入这些域名，让 OpenClash 对它们返回真实解析结果而非虚拟 IP，而不需要完全放弃 Fake-IP 模式。
Q9：如何判断当前透明代理是否真的在工作？
最直接的方法：在一台没有单独安装代理客户端的手机或平板上，用浏览器访问 ip.sb 或 ipinfo.io，如果显示的 IP 是境外节点 IP 而非本地运营商 IP，说明透明代理生效。同时可以访问 dnsleaktest.com 验证 DNS 没有泄漏。如果 IP 没有变化，先检查该设备的网关是否已指向软路由，再排查 iptables 规则是否正确加载。
Q10：固件选哪个版本合适，稳定版还是快照版？
对于生产环境（家里主力路由），推荐使用 OpenWrt 稳定版（如 23.05.x 系列），驱动兼容性和稳定性经过充分验证。快照版（snapshot）包含最新驱动和修复，但有时会引入新 bug，且部分第三方插件（如 OpenClash）可能因为内核版本差异出现编译不兼容。如果你在测试新硬件或需要某个稳定版尚未合并的驱动，才考虑使用快照版，并做好随时重刷的心理准备。
想进一步了解如何为家庭不同设备选择合适的机场节点，可以参考机场和工具选购入口与新手上手指南。如果你对专线和 BGP 线路的区别还有疑问，推荐阅读专线详解：IPLC 与 IEPL 是什么。