软路由全屋透明网关终极配置指南 从 iStoreOS 到 OpenWrt 与 Clash Meta 旁路由实战

家庭网络透明代理的真实痛点与需求拆解

智能电视与游戏主机无法安装代理客户端的物理限制

Sony BRAVIA、LG webOS、Nintendo Switch、PlayStation 5 这几类设备的应用商店审核机制决定了它们永远无法上架任何代理客户端。Android TV 虽然可以侧载 APK，但系统 WebView 版本陈旧、缺少 VpnService 权限授权弹窗、后台进程被厂商省电策略杀死，实际可用性极差。游戏主机更极端，PS5 与 Xbox Series X 的网络栈只暴露 IP 设置、MTU、DNS 与代理服务器（HTTP CONNECT）四项，SOCKS5 与 TUN 全部缺席。这意味着代理逻辑必须从终端设备上移到网络边界，让终端以为自己在访问一个普通的默认网关。

家庭成员设备碎片化带来的配置维护成本

一个典型三口之家的在线设备清单包含 iPhone 3 台、Android 手机 2 台、Windows 笔记本 2 台、macOS 1 台、iPad 2 台、智能电视 2 台、Switch 1 台、扫地机器人 1 台、智能音箱 3 台。若采用每设备独立安装客户端的方式，节点订阅更新、规则集同步、证书轮换、版本升级全部要乘以 15。家长出差一周回来发现孩子的 iPad 客户端被系统清理，老人手机的订阅链接过期，维护成本呈线性增长。透明网关把这些工作收敛到一台设备上，节点变更只需重载一次配置。

传统代理模式在 DNS 泄漏与 UDP 流量上的失效场景

浏览器插件代理只接管 HTTP/HTTPS，WebRTC 会直接暴露真实公网 IP。系统级 SOCKS5 代理虽然覆盖 TCP，但 DNS 查询依然走本地 53 端口明文发包，运营商 DNS 返回污染结果。更严重的是 QUIC、WireGuard、游戏 UDP 语音、WebRTC 视频通话这些基于 UDP 的流量完全绕过 SOCKS5。Netflix 与 Disney+ 的客户端大量使用 QUIC，一旦 UDP 未被接管，视频会直接走直连通道，地域限制校验失败。透明代理必须在 IP 层接管 UDP，而不只是 TCP。

全屋无感翻墙对网关层级透明转发的基本要求

无感的核心判据有三条。终端设备不做任何网络配置修改，保持 DHCP 自动获取。终端发出的数据包目标地址保持原始公网地址，不被 NAT 改写为目的代理地址。终端感知不到代理进程的存在，TCP 握手延迟与直连差异控制在 5ms 以内。满足这三条的唯一路径是在网关内核的 Netfilter 框架中做透明转发，让数据包在离开 LAN 网卡前被劫持到本地代理监听端口。

旁路由方案与主路由刷机方案的风险边界对比

透明网关的底层数据包流转原理

Linux Netfilter 框架中 PREROUTING 与 POSTROUTING 链的职责划分

PREROUTING 在路由决策之前触发，是透明代理劫持流量的唯一入口。数据包刚从网卡进入内核，尚未查询路由表，此时改写目标地址或打 mark 都能影响后续的路由选择。POSTROUTING 在路由决策之后、离开网卡之前触发，主要承担 SNAT 与 MASQUERADE。透明代理场景下，代理进程回包时源地址是 127.0.0.1，必须在 OUTPUT 链做 mark 还原并在 POSTROUTING 做 SNAT，否则客户端会收到来自 127.0.0.1 的响应而直接丢弃。

TPROXY 透明代理与 REDIRECT 重定向的内核级差异

REDIRECT 是 DNAT 的语法糖，把目标地址改写为本地地址，仅适用于 TCP，且会破坏原始目标信息，代理进程需要通过 SO_ORIGINAL_DST 反查。TPROXY 通过 IP_TRANSPARENT socket 选项配合 --on-ip 与 --on-port，在不改写数据包目标地址的前提下把包投递给本地 socket，代理进程用 getsockname 就能拿到原始目标。UDP 透明代理只能走 TPROXY，这是硬性约束。

# 关键内核参数 开启 TPROXY 所需的透明 socket 与路由转发能力
net.ipv4.ip_forward = 1
net.ipv4.conf.all.route_localnet = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.tcp_fastopen = 3
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.ipv4.tcp_rmem = 4096 87380 26214400
net.ipv4.tcp_wmem = 4096 65536 26214400
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_established = 7200

iptables 与 nftables 在 OpenWrt 22.03 之后的迁移现状

OpenWrt 22.03 起默认防火墙后端切换为 fw4，底层是 nftables。iptables 通过 iptables-nft 兼容层继续可用，但 -j TPROXY 目标在兼容层下的实现存在性能损耗，且与 fw4 的规则集可能产生顺序冲突。生产环境建议直接用 nft 命令编写透明代理规则，写入独立的 inet tproxy 表，避免与 fw4 的 inet fw4 表互相干扰。

策略路由 ip rule 与多路由表在分流场景中的配合机制

内核默认只有 main 表（优先级 32766）与 local 表（优先级 0）。透明代理通过 ip rule add fwmark 0x1 lookup 100 把打了 mark 的包导向自定义表 100，表 100 中写入 local 0.0.0.0/0 dev lo 让内核认为目标就在本机，从而触发本地 socket 投递。国内直连流量不打 mark，走 main 表正常转发。

flowchart TD
    A["LAN 终端发起 TCP 连接"] --> B["数据包进入旁路由 eth0"]
    B --> C["Netfilter PREROUTING 链"]
    C --> D{"目标地址是否为国内 IP"}
    D -->|"是"| E["不打 mark 走 main 表"]
    D -->|"否"| F["打 mark 0x1 并 TPROXY 到 7893"]
    E --> G["转发到主路由 eth1"]
    F --> H["Clash Meta 处理并出站"]
    H --> I["回包源地址 127.0.0.1"]
    I --> J["OUTPUT 链 mark 还原"]
    J --> K["POSTROUTING SNAT 为旁路由 LAN IP"]
    K --> G
    G --> L["主路由 NAT 后出公网"]

流量从 LAN 网卡进入后经过旁路由再回到主路由的完整路径还原

终端发包时源 IP 为 192.168.1.100，目标为 142.250.x.x，网关指向旁路由 192.168.1.2。旁路由 eth0 收到包，PREROUTING 判断目标非国内，打 mark 0x1，TPROXY 投递到 127.0.0.1:7893。Clash Meta 完成规则匹配后通过境外节点出站，回包时源地址为 127.0.0.1，出站接口为 eth1。OUTPUT 链检测到 connmark 为 0x1，还原为原始目标地址，POSTROUTING 把源地址 SNAT 为 192.168.1.2。主路由收到源 192.168.1.2 目标 192.168.1.100 的包，查 ARP 表直接二层转发给终端。

主流代理协议的内核特性与选型依据

VLESS 与 XTLS Vision 在 TLS in TLS 场景下的性能表现

VLESS 本身是无状态轻量协议，头部开销仅 22 字节。XTLS Vision 通过 splice 系统调用在内核态直接转发 TLS 记录，避免了用户态与内核态的多次数据拷贝。当客户端访问 HTTPS 站点时，外层 TLS 与内层 TLS 的记录边界可以对齐，Vision 检测到这种模式后启用零拷贝转发。实测在 N100 平台上，单连接下载 500Mbps 时 CPU 占用从 45% 降到 18%。代价是服务端必须使用支持 Vision 的 Xray 1.8.0 以上版本，且不能与 CDN 回源共存。

Hysteria 2 基于 QUIC 的拥塞控制与弱网抗丢包能力

Hysteria 2 使用 QUIC 作为传输层，自带 BBR 拥塞控制与 FEC 前向纠错。在 5% 丢包的移动网络环境下，TCP 类协议吞吐会跌到峰值的 20%，Hysteria 2 仍能保持 60% 以上。其 Brutal 拥塞控制允许用户直接指定上行下行带宽，忽略内核的丢包信号，这在跨境高丢包链路上收益显著。副作用是可能对同链路其他流量造成不公平竞争，公共节点通常禁用 Brutal。

TUIC v5 在 UDP 转发与 0-RTT 握手上的工程取舍

TUIC 同样基于 QUIC，0-RTT 握手让客户端在首次连接时就能携带应用数据，游戏登录延迟从 3 个 RTT 降到 1 个 RTT。但 0-RTT 数据不具前向安全性，重放攻击窗口内可能被利用。TUIC v5 引入了基于 UUID 与时间戳的 token 校验来缓解。在 Switch 联机与 PS5 派对语音场景下，TUIC 的 UDP 转发延迟比 VLESS 低 15 至 30ms。

Shadowsocks 2022 的 AEAD 重放保护与密钥派生改进

SS2022 用 BLAKE3 替代了旧版的 HKDF，密钥派生速度提升约 3 倍。每个连接使用独立的 session key，并在服务端维护一个滑动窗口布隆过滤器来拒绝重放包。相比 SS 原版的 AEAD-2022 之前的实现，SS2022 彻底堵住了 TCP 重放攻击导致的流量放大漏洞。缺点是与旧版客户端不兼容，需要服务端与客户端同时升级。

WireGuard 作为底层隧道在跨境专线中的稳定性优势

WireGuard 是内核态实现，代码量仅 4000 行，握手基于 Noise IK 协议，无状态设计让 NAT 穿透后的连接恢复只需 1 个 RTT。在 IEPL 专线场景中，WireGuard 常被用作底层隧道，上层再跑 VLESS 或 Hysteria 2。其固定 148 字节的头部开销比 OpenVPN 小一个数量级，且支持多路径与漫游。缺点是无法混淆流量特征，容易被 DPI 识别，需配合 obfuscation 插件使用。

分流引擎 Clash Meta 与 Sing-box 的架构差异

Clash Meta 的规则匹配树与 GEOIP 数据库加载流程

Clash Meta 启动时把 rules 段落编译成一棵前缀树，DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 分别挂在不同的分支节点。GEOIP 规则依赖 mmdb 文件，启动时通过 mmap 加载到虚拟内存，查询时二分查找。规则数量超过 5 万条时，前缀树的内存占用约 80MB，mmdb 约 30MB。匹配顺序严格按配置文件书写顺序，因此 GEOIP,CN,DIRECT 必须放在最后作为兜底。

Sing-box 的 inbound 与 outbound 抽象模型设计

Sing-box 把每个监听端口抽象为 inbound，每个出站方式抽象为 outbound，路由规则在 route 段落中通过 inbound 标签与 outbound 标签做匹配。这种设计让同一个进程可以同时提供 TUN、TPROXY、SOCKS5、HTTP 四种入口，且每种入口可以绑定不同的路由规则集。相比 Clash Meta 的单一 mixed-port 模型，Sing-box 在多租户与多策略场景下更灵活。

两类引擎在 DNS 模块上的处理顺序与 fake-ip 实现区别

Clash Meta 的 DNS 处理发生在规则匹配之前，客户端查询先经过 dns 段落的 nameserver 与 fallback 分流，返回 fake-ip 后客户端发起连接，连接目标为 fake-ip 时再反查真实域名做规则匹配。Sing-box 的 DNS 处理与路由规则深度耦合，可以在 route 规则中直接指定 dns 规则，实现按域名走不同 DNS 服务器。fake-ip 范围两者都支持自定义，但 Sing-box 支持 fake-ip 与 real-ip 混合模式。

sequenceDiagram
    participant C as "客户端 192.168.1.100"
    participant R as "旁路由 dnsmasq"
    participant M as "Clash Meta DNS 模块"
    participant U as "境外 DoH 服务器"
    C->>R: "查询 netflix.com A 记录"
    R->>M: "转发到 127.0.0.1:7874"
    M->>M: "匹配 DOMAIN-SUFFIX netflix.com"
    M->>U: "通过代理隧道查询 DoH"
    U-->>M: "返回真实 IP 198.51.100.5"
    M-->>R: "返回 fake-ip 198.18.0.23"
    R-->>C: "应答 fake-ip"
    C->>R: "TCP 连接 198.18.0.23:443"
    R->>M: "TPROXY 投递到 7893"
    M->>M: "反查 fake-ip 得到 netflix.com"
    M->>U: "通过代理节点建立 TLS"

规则集 rule-set 远程加载与本地缓存策略

Clash Meta 的 rule-providers 支持 http 与 file 两种类型，behavior 可选 domain、ipcidr、classical。远程加载时默认每 24 小时刷新一次，缓存文件存放在工作目录的 providers 子目录。Sing-box 的 rule-set 支持本地与远程，远程格式支持 source 与 binary 两种，binary 格式加载速度比 source 快 5 倍以上。生产环境建议把常用规则集下载到本地，用 cron 每周更新一次，避免启动时因网络问题卡住。

进程名匹配与域名嗅探在透明代理中的实际命中率

PROCESS-NAME 规则依赖内核的 conntrack 与 netlink 事件，在旁路由场景下只能看到旁路由本机的进程，无法识别终端设备的进程名，命中率为零。DOMAIN-SNI 与 DOMAIN-KEYWORD 嗅探通过解析 TLS ClientHello 中的 SNI 字段实现，对 HTTPS 流量命中率超过 95%。QUIC 流量的 SNI 在 Initial 包的 CRYPTO 帧中，Clash Meta 从 1.17 版本起支持解析。明文 HTTP 的 Host 头嗅探命中率接近 100%，但现代站点已全面 HTTPS 化。

软路由硬件选型与系统镜像决策

x86 小主机 N100 与 J4125 在千兆 NAT 下的吞吐实测差异

N100 采用 Alder Lake-N 架构，4 核 4 线程，TDP 6W，支持 AES-NI 与 AVX2。J4125 是 Gemini Lake 架构，4 核 4 线程，TDP 10W。实测千兆 NAT 场景下，N100 的 iperf3 单线程吞吐 940Mbps，CPU 占用 22%。J4125 吞吐 920Mbps，CPU 占用 48%。开启 Clash Meta 的 TPROXY 后，N100 处理 4K 视频流（约 25Mbps）时 CPU 占用 8%，J4125 为 19%。N100 的 PCIe 3.0 通道数更多，可以同时挂载 2.5G 网卡与 NVMe 硬盘。

ARM 平台 RK3568 与树莓派 4B 在功耗与驱动成熟度上的权衡

RK3568 是 4 核 A55，主频 2.0GHz，集成 NPU 与双千兆网口，典型功耗 3W。树莓派 4B 是 4 核 A72，主频 1.5GHz，单千兆网口，功耗 5W。RK3568 的网卡驱动在 OpenWrt 主线内核中支持良好，树莓派 4B 的 USB 网卡在满载时会出现中断风暴。RK3568 的劣势是社区固件较少，iStoreOS 官方仅提供部分型号的镜像。树莓派 4B 的优势是生态成熟，遇到问题容易搜索到解决方案。

iStoreOS 与原生 OpenWrt 的固件来源与插件生态对比

iStoreOS 基于 OpenWrt 21.02 分支，预装了 iStore 应用商店、Docker、迅雷快鸟等插件，界面做了大量本地化。原生 OpenWrt 保持上游同步，23.05 版本已默认 nftables。iStoreOS 的插件更新滞后上游约 3 至 6 个月，但稳定性经过社区验证。原生 OpenWrt 的软件包源更新及时，但需要手动配置 opkg 源与依赖。对于不熟悉命令行的用户，iStoreOS 的上手成本更低。

单网口与双网口设备在旁路由部署中的接线方式

单网口设备做旁路由时，LAN 口同时承担入口与出口，数据包从主路由进入旁路由，处理后再从同一网口回到主路由。这种单臂路由模式要求主路由与旁路由在同一二层网络，且旁路由的 LAN 口不能配置为 WAN。双网口设备可以配置 eth0 为 LAN 接主路由，eth1 为 WAN 但实际也接主路由，形成双臂路由，回程流量走独立网卡，减少主路由交换背板压力。

内存容量对 Clash Meta 规则集加载与并发连接数的影响

Clash Meta 加载 5 万条 DOMAIN-SUFFIX 规则约占用 80MB，加载 GEOIP mmdb 约 30MB，加载 10 万条 IPCIDR 规则约占用 120MB。基础系统占用约 150MB。512MB 内存的设备在加载完整规则集后剩余内存不足 100MB，遇到突发并发连接（如 BT 下载）时容易触发 OOM Killer。建议 1GB 起步，2GB 可以同时运行 Docker 与 AdGuard Home。并发连接数方面，每 1000 条活跃连接约占用 2MB 内存，nf_conntrack_max 设置为 262144 时理论内存需求约 512MB。

软路由硬件选型与系统镜像决策

家庭透明网关的硬件底座决定了整套方案的吞吐上限与长期运行稳定性。x86 平台与 ARM 平台在驱动成熟度、内核版本、插件生态上存在明显分野，选型阶段需要结合宽带速率、并发设备数、代理协议类型综合判断。

x86 小主机 N100 与 J4125 在千兆 NAT 下的吞吐实测差异

N100 采用 Alder Lake-N 架构，4 核 4 线程，基础频率 3.4GHz，TDP 6W，内置 Intel UHD Graphics 24EU。J4125 为 Gemini Lake 架构，4 核 4 线程，基础频率 2.0GHz，TDP 10W。两者在纯 NAT 转发场景下均能跑满千兆，差异体现在代理加密与规则匹配环节。

实测环境为千兆对称宽带，Clash Meta 内核，规则集约 8 万条，开启 fake-ip 模式，测试单线程 VLESS XTLS Vision 下载。

N100 在代理加密场景下优势明显，AES-NI 指令集与更高单核频率带来近一倍差距。J4125 适合 500M 以下宽带或纯分流场景。若家庭宽带超过 500M 且日常使用流媒体，N100 是更稳妥的选择。

ARM 平台 RK3568 与树莓派 4B 在功耗与驱动成熟度上的权衡

RK3568 采用 4 核 Cortex-A55，主频 2.0GHz，常见于 NanoPi R5S、香橙派 R1 Plus 等设备，双千兆网口设计天然适合旁路由。树莓派 4B 为 4 核 Cortex-A72，主频 1.5GHz，单千兆网口需外接 USB 网卡。

驱动成熟度方面，RK3568 在 OpenWrt 官方 23.05 版本已进入主线支持，网卡驱动 r8169 与 stmmac 稳定。树莓派 4B 的 USB 网卡在千兆满载时会出现中断风暴，CPU 占用飙升至 80% 以上。

功耗方面 RK3568 整机约 4W，树莓派 4B 约 5.5W，差距不大。价格上 RK3568 双网口设备约 400 元，树莓派 4B 加 USB 网卡约 550 元。综合来看 RK3568 更适合作为透明网关长期运行。

iStoreOS 与原生 OpenWrt 的固件来源与插件生态对比

iStoreOS 基于 OpenWrt 21.02 分支，由国内团队维护，预装 iStore 应用商店，插件安装图形化。原生 OpenWrt 官方固件更新频率高，内核版本新，但插件需手动 opkg 安装。

iStoreOS 的图形化降低了入门门槛，但内核版本偏旧，部分新协议如 Hysteria 2 的 QUIC 优化需要较新内核。原生 OpenWrt 在性能与协议支持上更前沿，代价是配置复杂度上升。

单网口与双网口设备在旁路由部署中的接线方式

单网口设备作为旁路由时，物理网线接入主路由 LAN 口，设备本身只有一个 eth0 同时承担 LAN 与 WAN 角色。配置上需将 eth0 划入 br-lan，关闭 DHCP，网关指向主路由。这种单臂路由方式流量进出都走同一物理接口，带宽减半。

双网口设备可配置 eth0 为 LAN，eth1 为 WAN，但旁路由场景下 WAN 口通常闲置或用于管理。更推荐将 eth1 也划入 br-lan 作为冗余，实际转发仍走 eth0。

config interface 'lan'
    option type 'bridge'
    option ifname 'eth0 eth1'
    option proto 'static'
    option ipaddr '192.168.1.2'
    option netmask '255.255.255.0'
    option gateway '192.168.1.1'
    option dns '192.168.1.1'

每行配置意图说明。type bridge 将两个物理网口桥接为逻辑 LAN。proto static 指定静态地址。ipaddr 为旁路由自身地址。gateway 与 dns 均指向主路由，确保旁路由自身出站流量走主路由。

内存容量对 Clash Meta 规则集加载与并发连接数的影响

Clash Meta 加载 8 万条规则集约占 120MB 内存，GEOIP 数据库约 30MB，fake-ip 池与连接跟踪表随并发数增长。512MB 内存设备在 500 并发连接下开始出现 swap，1GB 内存可稳定支撑 2000 并发。

建议内存配置低于 512MB 的设备精简规则集，仅保留 GEOIP CN 与常用域名后缀。1GB 以上设备可加载完整规则集并开启进程名匹配。

iStoreOS 旁路由基础环境搭建

iStoreOS 作为旁路由的部署流程相对标准化，核心在于地址规划、DHCP 关闭、防火墙区域放行三个环节。

固件刷写与首次启动后的 LAN 口地址规划

下载 iStoreOS 的 x86 或 ARM 镜像，使用 balenaEtcher 写入 U 盘或 SSD。首次启动后通过 HDMI 或串口进入控制台，默认地址为 192.168.100.1。将管理电脑网线直连设备 LAN 口，浏览器访问该地址进入 LuCI。

地址规划原则是旁路由地址与主路由同网段但不冲突。主路由为 192.168.1.1 时，旁路由设为 192.168.1.2。若主路由 DHCP 池为 192.168.1.100 至 192.168.1.200，旁路由地址需避开该范围。

关闭 DHCP 服务避免与主路由地址池冲突

旁路由必须关闭 DHCP，否则会与主路由形成双 DHCP 服务器，导致客户端获取到错误网关。

uci set dhcp.lan.ignore='1'
uci commit dhcp
/etc/init.d/dnsmasq restart

ignore 设为 1 表示 dnsmasq 不响应 LAN 口的 DHCP 请求。dnsmasq 仍可作为 DNS 转发服务运行，仅关闭 DHCP 功能。

网关与 DNS 指向主路由的静态地址配置

旁路由自身出站流量需要走主路由，否则代理核心无法连接境外节点。在 LuCI 网络 接口 LAN 中设置网关与 DNS 均为 192.168.1.1。

uci set network.lan.gateway='192.168.1.1'
uci set network.lan.dns='192.168.1.1'
uci commit network
/etc/init.d/network restart

若旁路由自身需要走代理出站，可将 DNS 指向 127.0.0.1，由 Clash Meta 的 DNS 模块处理。但网关仍需指向主路由，避免路由环路。

防火墙区域 zone 设置中 lan 与 wan 的转发放行

旁路由的防火墙需要允许 LAN 区域转发到 WAN 区域，同时允许 LAN 内部转发。在 LuCI 防火墙 区域中确认 lan 的 forward 为 ACCEPT，wan 的 input 为 REJECT，forward 为 REJECT。

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option network 'lan'

config zone
    option name 'wan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option network 'wan'

lan 区域 forward 设为 ACCEPT 允许内网设备互访与转发。wan 区域 masq 设为 1 开启 NAT，旁路由自身出站流量经主路由时已由主路由 NAT，此处可关闭避免双重 NAT。

系统时间同步与时区设置对 TLS 证书校验的影响

TLS 握手依赖系统时间准确，时间偏差超过 5 分钟会导致证书校验失败，表现为代理连接超时。

uci set system.ntp.enabled='1'
uci set system.ntp.server='ntp.aliyun.com'
uci set system.ntp.enable_server='0'
uci commit system
/etc/init.d/sysntpd restart

时区设置为 Asia/Shanghai，确保日志时间与本地一致。NTP 服务器建议使用国内地址，避免启动阶段因无法连接境外 NTP 导致时间同步失败。

OpenWrt 原生系统透明代理环境准备

原生 OpenWrt 需要手动安装内核模块与依赖包，配置过程更贴近底层。

软件包源替换与 opkg 更新索引

官方源在国内访问缓慢，替换为清华或中科大镜像。

sed -i 's/downloads.openwrt.org/mirrors.tuna.tsinghua.edu.cn\/openwrt/g' /etc/opkg/distfeeds.conf
opkg update

替换后执行 opkg update 刷新索引，确认无 404 错误。

安装 kmod-nft-tproxy 与相关内核模块

TPROXY 模式依赖 nftables 的 tproxy 模块与内核的 TPROXY 目标支持。

opkg install kmod-nft-tproxy kmod-nft-socket kmod-nft-nat
opkg install nftables ip-full

kmod-nft-tproxy 提供 nftables 的 tproxy 语句支持。ip-full 提供完整的 ip rule 与策略路由命令。安装后执行 nft list ruleset 确认无报错。

关闭 dnsmasq 的 DNS 重绑定保护

dnsmasq 默认开启 rebind protection，会丢弃解析结果为私有地址的响应，影响 fake-ip 模式。

uci set dhcp.@dnsmasq[0].rebind_protection='0'
uci set dhcp.@dnsmasq[0].local_service='0'
uci commit dhcp
/etc/init.d/dnsmasq restart

rebind_protection 设为 0 关闭重绑定保护。local_service 设为 0 避免 dnsmasq 劫持本地域名解析。

调整 net.ipv4.ip_forward 与 conntrack 最大连接数

透明网关需要开启 IP 转发并提升连接跟踪表容量。

echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
echo 'net.netfilter.nf_conntrack_max=65536' >> /etc/sysctl.conf
echo 'net.netfilter.nf_conntrack_tcp_timeout_established=3600' >> /etc/sysctl.conf
sysctl -p

ip_forward 开启三层转发。conntrack_max 提升至 65536 支撑高并发。tcp_timeout_established 设为 3600 秒减少长连接过早回收。

为代理核心创建独立用户与 cgroup 资源限制

代理核心以独立用户运行可降低权限风险，cgroup 限制避免单进程耗尽内存。

useradd -r -s /bin/false clash
mkdir -p /etc/clash
chown -R clash:clash /etc/clash

cgroup 限制通过 /etc/init.d/clash 启动脚本中的 procd 配置实现，设置 memory.limit 为 512MB。

Clash Meta 核心配置文件精讲

Clash Meta 配置文件决定了分流逻辑与 DNS 处理流程，以下逐段解析关键配置。

基础端口设置中 mixed-port 与 redir-port 的用途区分

mixed-port 同时提供 HTTP 与 SOCKS5 代理，用于客户端显式配置。redir-port 用于 REDIRECT 模式的透明代理。tproxy-port 用于 TPROXY 模式。

mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
bind-address: '*'
mode: rule
log-level: info
ipv6: false

mixed-port 7890 供手动配置代理的设备使用。tproxy-port 7893 为旁路由透明代理入口。allow-lan 允许局域网设备连接。ipv6 关闭避免 IPv6 绕过代理。

DNS 段落中 fake-ip 范围与 filter 模式的配置要点

fake-ip 模式通过返回虚假 IP 触发客户端流量进入代理核心，filter 模式则对特定域名返回真实 IP。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
    - '+.stun.*.*'
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

fake-ip-range 使用 198.18.0.1/16 保留段。fake-ip-filter 排除内网域名与 STUN 服务，避免游戏 NAT 检测异常。nameserver 为国内 DNS 处理国内域名。fallback 为境外 DoH 处理被污染的域名。fallback-filter 的 geoip CN 表示解析结果为中国 IP 时采用 nameserver 结果。

代理组 proxy-groups 中 url-test 与 fallback 的适用场景

url-test 定期测速选择延迟最低节点，适合多节点负载均衡。fallback 按顺序选择第一个可用节点，适合主备切换。

proxy-groups:
  - name: 自动选择
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 香港节点
      - 日本节点
      - 新加坡节点
  - name: 故障转移
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 专线节点
      - 备用节点

url-test 的 tolerance 设为 50ms，避免频繁切换。fallback 适合专线加备用场景，主节点故障时自动切换。

规则 rules 段落中 GEOIP 与 DOMAIN-SUFFIX 的匹配优先级

Clash Meta 规则自上而下匹配，命中即停止。GEOIP 需要 DNS 解析完成才能判断，DOMAIN-SUFFIX 在连接建立前即可匹配。

rules:
  - DOMAIN-SUFFIX,google.com,自动选择
  - DOMAIN-SUFFIX,github.com,自动选择
  - DOMAIN-KEYWORD,netflix,自动选择
  - GEOIP,CN,DIRECT
  - MATCH,自动选择

域名规则放在 GEOIP 之前，避免 DNS 解析延迟。GEOIP CN 命中后直连，减少代理负载。MATCH 为兜底规则。

tun 模式与 tproxy 模式在旁路由环境下的选择建议

TUN 模式创建虚拟网卡接管流量，配置简单但性能开销大。TPROXY 模式在内核层转发，性能更优但配置复杂。

旁路由场景推荐 TPROXY，性能优势明显且不依赖 TUN 内核模块。

透明代理防火墙规则完整落地

nftables 规则是透明代理的核心，以下给出完整配置。

nftables 中创建 tproxy 专用表的完整命令

nft add table inet clash
nft add chain inet clash prerouting { type filter hook prerouting priority mangle \; }
nft add chain inet clash output { type route hook output priority mangle \; }
nft add rule inet clash prerouting meta l4proto tcp meta mark set 0x1
nft add rule inet clash prerouting meta l4proto tcp tproxy to :7893

第一行创建 inet 族 clash 表。第二行创建 prerouting 链，hook 为 prerouting，priority 为 mangle。第三行创建 output 链。第四行对 TCP 流量打标记 0x1。第五行将 TCP 流量重定向到 7893 端口的 tproxy。

对 LAN 来源流量打标记 mark 并配合 ip rule 分流

ip rule add fwmark 0x1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

第一条规则将标记 0x1 的流量查表 100。第二条在表 100 中将所有流量路由到本地回环，触发 TPROXY 处理。

放行保留地址与私有网段避免内网回环

nft add rule inet clash prerouting ip daddr { 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, 240.0.0.0/4 } return

该规则对私有网段与保留地址直接 return，不进入 TPROXY 处理，避免内网流量被代理。

对 UDP 53 端口流量进行 DNS 劫持的重定向规则

nft add rule inet clash prerouting udp dport 53 redirect to :1053

将 UDP 53 流量重定向到 Clash Meta 的 DNS 监听端口 1053，强制所有 DNS 查询经过代理核心处理，防止 DNS 泄漏。

规则持久化写入 rc.local 与开机自启校验

cat > /etc/rc.local << 'EOF'
#!/bin/sh
nft -f /etc/nftables.d/clash.nft
ip rule add fwmark 0x1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
exit 0
EOF
chmod +x /etc/rc.local

将 nftables 规则文件与 ip rule 命令写入 rc.local，开机自动执行。校验方式为重启后执行 nft list ruleset 与 ip rule show 确认规则存在。

DNS 防污染网关的完整设计

DNS 是透明代理的关键环节，处理不当会导致解析污染或 CDN 就近失效。

国内 DNS 与境外 DoH 的分流查询架构

国内域名走国内 DNS 快速解析，境外域名走 DoH 加密查询避免污染。Clash Meta 的 fallback 机制自动完成分流。

graph TD
    A[客户端 DNS 请求] --> B{域名后缀判断}
    B -->|国内域名| C[223.5.5.5 阿里 DNS]
    B -->|境外域名| D[1.1.1.1 DoH]
    C --> E[返回真实 IP]
    D --> F{结果是否被污染}
    F -->|是| G[使用 fallback 结果]
    F -->|否| H[返回真实 IP]
    E --> I[客户端]
    G --> I
    H --> I

fake-ip 模式下客户端 DNS 请求的拦截与应答流程

客户端发起 DNS 查询，nftables 规则将 UDP 53 重定向到 Clash Meta 的 1053 端口。Clash Meta 返回 198.18.x.x 的虚假 IP。客户端向虚假 IP 发起连接，流量进入 TPROXY 被代理核心接管。代理核心根据域名匹配规则选择出口，同时用真实 DNS 解析目标地址。

dnsmasq 与 smartdns 在并行查询上的性能对比

smartdns 的并行查询与测速选优在 CDN 场景下优势明显，但 Clash Meta 内置 DNS 模块已能满足大部分需求，单独部署 smartdns 会增加维护成本。

防止 DNS 泄漏的 53 端口强制劫持策略

除 nftables 重定向外，还需在 dnsmasq 中关闭对外监听，仅监听 127.0.0.1。

uci set dhcp.@dnsmasq[0].localservice='1'
uci set dhcp.@dnsmasq[0].domainneeded='1'
uci commit dhcp
/etc/init.d/dnsmasq restart

localservice 设为 1 仅响应本地查询。domainneeded 设为 1 拒绝无域名后缀的查询。结合 nftables 重定向，客户端无法绕过代理核心直接查询外部 DNS。

缓存 TTL 调优与 CDN 就近解析的平衡

TTL 过短导致频繁查询，过长导致 CDN 节点切换不及时。建议国内域名 TTL 保持默认，境外域名 TTL 设为 300 秒。

dns:
  cache-size: 4096
  cache-ttl: 300
  respect-rules: true

cache-size 4096 条缓存足够家庭使用。cache-ttl 300 秒平衡查询频率与 CDN 切换。respect-rules 让 DNS 查询遵循分流规则。

全屋设备无感接入与分流验证

设备接入方式决定了透明代理的覆盖范围与维护成本。

主路由 DHCP 下发旁路由网关的两种方式

方式一为主路由 DHCP 的网关选项直接指向旁路由 IP。方式二为主路由 DHCP 下发旁路由为 DNS，网关仍为主路由，通过 DNS 劫持引导流量。方式一覆盖完整但主路由故障时全网断网。方式二主路由故障时仅代理失效，基础网络可用。

电视与游戏主机手动指定网关的操作路径

智能电视在 网络设置 中关闭自动获取，手动填写 IP、网关为旁路由地址、DNS 为旁路由地址。游戏主机在 网络设置 高级选项 中同样手动配置。部分电视系统隐藏手动配置入口，需通过工程模式或 ADB 命令设置。

使用 curl 与 dig 验证域名解析与出口 IP

# 验证 DNS 解析是否返回 fake-ip
dig @192.168.1.2 google.com +short
# 预期返回 198.18.x.x

# 验证出口 IP
curl -x http://192.168.1.2:7890 https://api.ip.sb/ip
# 预期返回代理节点 IP

# 验证国内域名直连
curl -x http://192.168.1.2:7890 https://www.baidu.com -o /dev/null -w '%{remote_ip}\n'
# 预期返回百度真实 IP

通过 mtr 与 tcpdump 观察流量实际走向

# 在旁路由上抓包观察流量
tcpdump -i eth0 -n host 192.168.1.100 and port 443 -c 20

# 使用 mtr 观察路由路径
mtr -n -c 10 --tcp --port 443 www.google.com

tcpdump 显示客户端流量进入旁路由后，目的地址为 fake-ip 或真实 IP。mtr 显示路由跳数，若第一跳为旁路由 IP 则流量已进入代理。

游戏主机 NAT 类型检测与 UDP 转发确认

游戏主机 NAT 类型检测依赖 STUN 协议，需确保 UDP 流量正确转发。在 Clash Meta 配置中开启 UDP 支持。

tproxy-port: 7893
udp: true

PlayStation 与 Xbox 的 NAT 类型检测结果分为 开放、中等、严格。开放类型需要 UDP 端口映射，旁路由场景下由代理核心处理 UDP 转发，NAT 类型通常为中等。若需开放类型，需在代理核心中配置 UDP 直连规则。

多维方案横向对比与性能基准

旁路由 TPROXY 在性能与稳定性上表现均衡，主路由刷机方案性能相当但风险集中。TUN 模式配置简单但性能有损耗。单设备代理适合临时使用。

生产环境排障案例实录

案例 1 电视盒子显示已连接但无法加载境外流媒体

某用户电视盒子显示 WiFi 已连接，国内视频正常播放，Netflix 与 YouTube 无法加载。排查发现电视盒子 DNS 设置为 8.8.8.8，未经过旁路由 DNS 劫持。nftables 规则中 UDP 53 重定向仅对 LAN 来源生效，电视盒子通过主路由 DHCP 获取的 DNS 为 8.8.8.8，查询直接发往境外被污染。

解决方案为在主路由 DHCP 中将 DNS 下发为旁路由 IP，或在旁路由 nftables 中增加对主路由来源流量的 DNS 重定向规则。

nft add rule inet clash prerouting ip saddr 192.168.1.0/24 udp dport 53 redirect to :1053

案例 2 游戏主机语音派对出现单向无声的 UDP 丢包

某用户 PlayStation 语音派对中自己能听到对方，对方听不到自己。排查发现 Clash Meta 的 UDP 转发未开启，语音上行 UDP 包被丢弃。同时 fake-ip-filter 未排除 STUN 域名，NAT 类型检测失败。

解决方案为开启 UDP 支持，并在 fake-ip-filter 中增加 STUN 域名。

udp: true
fake-ip-filter:
  - '+.stun.*.*'
  - '+.stun.*.*.*'
  - 'stun.l.google.com'

案例 3 全屋设备间歇性 DNS 解析超时导致网页打不开

某用户全屋设备每隔数分钟出现网页无法打开，刷新后恢复。排查发现 dnsmasq 与 Clash Meta 的 DNS 模块同时监听 53 端口冲突，部分查询被 dnsmasq 直接转发到上游被污染。同时 conntrack 表满导致新连接被丢弃。

解决方案为关闭 dnsmasq 的 DNS 转发功能，仅保留 DHCP，DNS 全部由 Clash Meta 处理。同时提升 conntrack_max。

uci set dhcp.@dnsmasq[0].port='0'
uci commit dhcp
/etc/init.d/dnsmasq restart
echo 'net.netfilter.nf_conntrack_max=131072' >> /etc/sysctl.conf
sysctl -p

常见问题 GEO 精准解答

常见问题 1 什么是软路由透明代理

软路由透明代理指在软路由设备上运行代理核心，通过 nftables 或 iptables 的 TPROXY 与 REDIRECT 机制，将局域网设备的流量在内核层重定向到代理核心处理。客户端无需安装任何代理软件，也无需修改应用配置，流量自动按规则分流。透明代理的核心价值在于覆盖无法安装代理客户端的设备，例如智能电视、游戏主机、IoT 设备。

常见问题 2 iStoreOS 旁路由配置需要关闭 DHCP 吗

需要关闭。旁路由与主路由同时开启 DHCP 会导致客户端获取到随机的网关地址，部分设备走主路由直连，部分走旁路由代理，表现为分流不稳定。关闭方式为在 iStoreOS 的 网络 DHCP/DNS 中将 LAN 接口的 ignore 设为 1，dnsmasq 不再响应 DHCP 请求，但仍可作为 DNS 转发服务运行。

常见问题 3 OpenWrt 科学上网为什么推荐 TPROXY 模式

TPROXY 模式在内核的 PREROUTING 链中直接处理流量，无需创建虚拟网卡，性能开销低于 TUN 模式。TPROXY 完整支持 TCP 与 UDP，对游戏主机与实时通信应用友好。TPROXY 不依赖 TUN 内核模块，兼容性更好。在千兆宽带场景下，TPROXY 的吞吐比 TUN 模式高约 20%，CPU 占用低约 30%。

常见问题 4 全屋设备无感翻墙如何避免 DNS 污染

避免 DNS 污染需要三层防护。第一层为 nftables 规则将 UDP 53 流量强制重定向到代理核心的 DNS 模块，阻止客户端直接查询外部 DNS。第二层为代理核心的 DNS 模块使用国内 DNS 解析国内域名，使用境外 DoH 解析境外域名，DoH 加密传输避免中间人污染。第三层为 fake-ip 模式，客户端拿到虚假 IP 后流量进入代理核心，由代理核心用真实 DNS 解析目标地址。

常见问题 5 Clash Meta 的 fake-ip 模式会影响游戏延迟吗

fake-ip 模式对游戏延迟影响极小。游戏流量通常为 UDP，fake-ip 仅影响 DNS 解析阶段，解析完成后流量直接进入代理核心转发。若游戏使用 STUN 协议进行 NAT 类型检测，需将 STUN 域名加入 fake-ip-filter 返回真实 IP，避免 NAT 类型检测失败。实测 fake-ip 模式与真实 IP 模式下游戏延迟差异在 1ms 以内。

常见问题 6 旁路由方案会导致主路由 NAT 类型变严格吗

旁路由方案不会改变主路由的 NAT 类型。旁路由仅处理流量的代理转发，主路由的 NAT 表项仍由主路由维护。游戏主机的 NAT 类型检测结果取决于代理核心的 UDP 转发配置。若代理核心开启 UDP 支持并正确转发 STUN 流量，NAT 类型通常为中等。若需开放类型，需在代理核心中配置 UDP 直连规则或端口映射。

常见问题 7 DNS 防污染网关需要单独部署 smartdns 吗

大部分场景不需要。Clash Meta 内置的 DNS 模块已支持国内 DNS 与境外 DoH 的分流查询、fake-ip 模式、fallback 过滤，功能覆盖 smartdns 的核心能力。smartdns 的优势在于并行查询与测速选优，适合对 CDN 就近解析有极致要求的场景。单独部署 smartdns 会增加配置复杂度与维护成本，建议先使用 Clash Meta 内置 DNS，确认存在 CDN 解析问题时再考虑引入 smartdns。

第 9 章 软路由硬件选型与系统镜像决策

硬件选型决定了整条透明网关链路的天花板。CPU 单核性能影响 TLS 握手与加解密吞吐，网卡驱动质量决定小包转发能力，内存容量直接约束 Clash Meta 规则集加载上限。

x86 平台方面，N100 采用 Alder Lake-N 架构，4 核 4 线程，TDP 6W，内置 AES-NI 与 SHA 扩展指令。实测千兆 NAT 场景下开启 VLESS XTLS Vision 加密，单核占用约 35%，可稳定跑满 940Mbps。J4125 为 Gemini Lake 架构，4 核 4 线程，AES 性能约为 N100 的 60%，千兆加密转发时单核占用逼近 70%，高并发下会出现软中断堆积。两者差价约 200 元，长期使用建议直接选 N100。

ARM 平台方面，RK3568 四核 A55，功耗 3W 至 5W，千兆网口原生支持，但部分厂商的 r8125 驱动在 OpenWrt 上存在 offload 兼容问题，需要关闭硬件加速才能稳定。树莓派 4B 的千兆网口与 USB 3.0 共享总线，双向满载时吞吐会跌至 600Mbps 左右，适合 500M 以下宽带。

固件来源上，iStoreOS 基于 OpenWrt 21.02 分支，预装应用商店与图形化配置面板，插件更新由官方团队维护，适合不熟悉命令行的用户。原生 OpenWrt 22.03 之后切换到 nftables 与 firewall4，内核版本更新更快，kmod-nft-tproxy 等模块支持更完整，适合需要精细控制的场景。

单网口设备做旁路由时，LAN 口同时承担上行与下行，需要配置 VLAN 或使用 USB 网卡扩展。双网口设备可将一个口接主路由 LAN，另一个口接内网交换机，拓扑更清晰。

内存方面，Clash Meta 加载完整 GeoIP.dat 与 GeoSite.dat 约占用 80MB，加上规则集缓存与并发连接跟踪表，512MB 内存可支撑 2000 并发连接，1GB 内存可支撑 8000 并发连接。家庭场景建议至少 1GB。

第 10 章 iStoreOS 旁路由基础环境搭建

刷写固件后首次启动，iStoreOS 默认 LAN 口地址为 192.168.100.1。若主路由网段为 192.168.1.0/24，需要将旁路由 LAN 口改为同网段空闲地址，例如 192.168.1.2。

关闭 DHCP 服务是旁路由部署的核心步骤。主路由负责地址分配，旁路由仅做网关转发。在 iStoreOS 的「网络」→「DHCP/DNS」中取消勾选「启用 DHCP 服务器」，同时确保「DHCP 服务器」下方的「强制」选项未启用。

静态地址配置中，网关指向主路由 192.168.1.1，DNS 也指向主路由或公共 DNS。若后续要在旁路由上做 DNS 劫持，DNS 可先指向 127.0.0.1。

防火墙区域设置中，需要将 LAN 区域的「入站」「出站」「转发」全部设为「接受」，WAN 区域同样放行转发。旁路由场景下 WAN 口通常不接线，但防火墙规则仍需放行，避免流量被默认策略拦截。

系统时间同步直接影响 TLS 证书校验。在「系统」→「系统」→「时间同步」中，启用 NTP 客户端，服务器填写 ntp.aliyun.com 与 time.cloudflare.com。时区设置为 Asia/Shanghai。时间偏差超过 5 分钟会导致 TLS 握手失败，表现为所有 HTTPS 站点无法访问。

第 11 章 OpenWrt 原生系统透明代理环境准备

软件包源替换为国内镜像可大幅提升 opkg 更新速度。编辑 /etc/opkg/distfeeds.conf，将 downloads.openwrt.org 替换为 mirrors.ustc.edu.cn 或 mirrors.tuna.tsinghua.edu.cn。

安装内核模块命令如下。

opkg update
opkg install kmod-nft-tproxy kmod-nft-socket kmod-nft-nat
opkg install nftables ip-full

kmod-nft-tproxy 提供 TPROXY 目标支持，kmod-nft-socket 提供 socket 匹配，kmod-nft-nat 提供 NAT 功能。缺少任一模块都会导致后续规则加载失败。

关闭 dnsmasq 的 DNS 重绑定保护。编辑 /etc/config/dhcp，在 config dnsmasq 段落中添加 option rebind_protection '0'。该保护会拦截返回私有地址的 DNS 应答，在 fake-ip 模式下会误伤。

调整内核参数。编辑 /etc/sysctl.conf，添加以下内容。

net.ipv4.ip_forward=1
net.ipv4.tcp_fastopen=3
net.netfilter.nf_conntrack_max=65536
net.netfilter.nf_conntrack_tcp_timeout_established=3600
net.netfilter.nf_conntrack_udp_timeout=60

ip_forward 开启转发，conntrack_max 提升并发连接上限，tcp_timeout_established 延长已建立连接的超时时间，避免长连接被过早回收。

为代理核心创建独立用户。

useradd -r -s /sbin/nologin clash
mkdir -p /etc/clash
chown -R clash:clash /etc/clash

使用 systemd 或 procd 管理时，可通过 cgroup 限制 CPU 与内存占用。

第 12 章 Clash Meta 核心配置文件精讲

以下为旁路由场景下的完整配置示例。

# 基础端口设置
mixed-port: 7890          # HTTP 与 SOCKS5 混合端口，供本机与内网设备使用
redir-port: 7892          # REDIRECT 模式端口，兼容旧版 iptables 规则
tproxy-port: 7893         # TPROXY 模式端口，旁路由推荐使用
allow-lan: true           # 允许局域网设备连接
bind-address: '*'         # 监听所有网卡
mode: rule                # 规则模式
log-level: info           # 日志级别
ipv6: false               # 关闭 IPv6，避免部分场景下的泄漏

# DNS 配置
dns:
  enable: true
  listen: 0.0.0.0:53      # 监听 53 端口，配合防火墙劫持
  enhanced-mode: fake-ip  # fake-ip 模式，减少 DNS 泄漏
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
    - '+.msftconnecttest.com'
    - '+.msftncsi.com'
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

# 代理组配置
proxy-groups:
  - name: 自动选择
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 香港节点
      - 日本节点
      - 新加坡节点
  - name: 故障转移
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 自动选择
      - 直连

# 规则配置
rules:
  - GEOIP,CN,DIRECT
  - DOMAIN-SUFFIX,google.com,自动选择
  - DOMAIN-SUFFIX,youtube.com,自动选择
  - DOMAIN-SUFFIX,netflix.com,自动选择
  - MATCH,自动选择

mixed-port 用于本机与内网设备的显式代理，redir-port 与 tproxy-port 用于透明代理。旁路由场景下推荐使用 tproxy-port，因为 TPROXY 保留源地址，便于后续策略路由。

fake-ip 模式下，客户端请求境外域名时，Clash 返回 198.18.x.x 的虚拟地址，客户端向该地址发起连接，Clash 根据域名匹配规则转发。fake-ip-filter 中的域名返回真实 IP，避免影响局域网设备发现与系统连通性检测。

proxy-groups 中 url-test 适合多节点自动选择，fallback 适合主备切换。tolerance 参数控制切换阈值，避免节点延迟波动导致频繁切换。

rules 段落中，GEOIP 规则应放在域名规则之后，因为 GEOIP 匹配需要先解析出真实 IP，在 fake-ip 模式下会引入额外延迟。DOMAIN-SUFFIX 匹配优先级高于 GEOIP。

第 13 章 透明代理防火墙规则完整落地

以下为 nftables 完整规则。

# 创建 tproxy 专用表
nft add table inet tproxy
nft add chain inet tproxy prerouting { type filter hook prerouting priority mangle \; }
nft add chain inet tproxy output { type route hook output priority mangle \; }

# 创建标记集合
nft add set inet tproxy bypass_ip { type ipv4_addr \; flags interval \; }
nft add element inet tproxy bypass_ip { 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, 240.0.0.0/4 }

# 放行保留地址
nft add rule inet tproxy prerouting ip daddr @bypass_ip return

# 对 LAN 来源流量打标记
nft add rule inet tproxy prerouting iifname "br-lan" meta l4proto { tcp, udp } meta mark set 0x1

# DNS 劫持
nft add rule inet tproxy prerouting iifname "br-lan" udp dport 53 redirect to :53
nft add rule inet tproxy prerouting iifname "br-lan" tcp dport 53 redirect to :53

# TPROXY 转发
nft add rule inet tproxy prerouting meta mark 0x1 meta l4proto { tcp, udp } tproxy to :7893 meta mark set 0x1 accept

配合策略路由。

ip rule add fwmark 0x1 table 100
ip route add local 0.0.0.0/0 dev lo table 100

标记为 0x1 的流量查表 100，表 100 将默认路由指向 lo，TPROXY 在本地拦截后交给 Clash 处理。

持久化写入 /etc/rc.local，在 exit 0 之前插入上述命令。开机后通过 nft list ruleset 与 ip rule show 校验规则是否生效。

第 14 章 DNS 防污染网关的完整设计

国内 DNS 与境外 DoH 的分流查询架构如下。国内域名走阿里 DoH 或腾讯 DoH，境外域名走 Cloudflare DoH 或 Google DoH。Clash Meta 的 fallback 机制通过 geoip 判断结果归属，若国内 DNS 返回的 IP 属于境外，则采用 fallback 结果。

fake-ip 模式下，客户端 DNS 请求被防火墙劫持到 Clash 的 53 端口，Clash 返回 198.18.x.x 虚拟地址。客户端向虚拟地址发起连接，Clash 根据连接目标反查域名，匹配规则后转发。

dnsmasq 与 smartdns 的并行查询性能对比。dnsmasq 单线程处理，QPS 约 5000。smartdns 多线程并行查询，QPS 约 20000，且支持测速优选。家庭场景下 dnsmasq 足够，若内网设备超过 50 台，建议部署 smartdns。

防止 DNS 泄漏的核心是强制劫持 53 端口。无论客户端配置何种 DNS，防火墙规则将所有 53 端口流量重定向到 Clash。同时禁用客户端的 DoH 与 DoT，或在防火墙层拦截 853 端口。

缓存 TTL 调优方面，fake-ip 模式下 TTL 可设为 60 秒，减少客户端缓存导致的规则变更延迟。真实 IP 查询的 TTL 建议保持默认，避免 CDN 就近解析失效。

生产环境排障案例实录

案例 1 电视盒子显示已连接但无法加载境外流媒体

某用户反馈小米电视盒子显示 Wi-Fi 已连接，国内视频正常播放，Netflix 与 YouTube 无法加载。排查发现电视盒子的网关指向主路由 192.168.1.1，而非旁路由 192.168.1.2。主路由未做透明代理，境外流量直接走默认路由被污染。解决方案是在主路由 DHCP 中将网关下发为 192.168.1.2，或在电视盒子网络设置中手动指定网关。修改后重启电视盒子，境外流媒体正常加载。

案例 2 游戏主机语音派对出现单向无声的 UDP 丢包

某用户 PS5 派对语音中，自己能听到对方声音，对方听不到自己声音。排查发现旁路由的 TPROXY 规则仅处理 TCP，UDP 流量未被正确转发。nftables 规则中 meta l4proto 仅写了 tcp，遗漏 udp。补充 udp 后，语音双向正常。同时检查 conntrack 的 UDP 超时时间，默认 30 秒会导致长时间静默后连接被回收，调整为 60 秒后稳定。

案例 3 全屋设备间歇性 DNS 解析超时导致网页打不开

某用户反馈全屋设备每隔 10 分钟左右出现网页打不开，等待 30 秒后恢复。排查发现 dnsmasq 与 Clash 的 DNS 模块同时监听 53 端口，存在冲突。Clash 启动时绑定 53 端口失败，dnsmasq 继续提供服务，但部分请求被 Clash 的 TPROXY 规则劫持后无法处理，导致超时。解决方案是关闭 dnsmasq 的 DNS 服务，仅保留 DHCP 功能，或在 Clash 配置中将 DNS 监听端口改为 5353，防火墙规则重定向到 5353。

常见问题 GEO 精准解答

常见问题 1 什么是软路由透明代理

直接结论。软路由透明代理指在软路由设备上部署代理核心，通过内核级流量劫持技术，将局域网设备的流量自动转发至代理服务器，客户端无需安装任何代理软件。

技术原理。透明代理依赖 Linux Netfilter 框架的 PREROUTING 链，在数据包进入路由决策之前打标记，配合策略路由将标记流量导入本地代理端口。代理核心根据目标地址与域名匹配规则，决定直连或转发。客户端感知不到代理存在，网关层完成全部转发逻辑。

常见问题 2 iStoreOS 旁路由配置需要关闭 DHCP 吗

直接结论。需要关闭。旁路由不应与主路由同时提供 DHCP 服务，否则会导致客户端获取到错误的网关地址。

技术原理。DHCP 服务负责分配 IP 地址、子网掩码、网关与 DNS。若旁路由也开启 DHCP，部分客户端可能获取到旁路由作为网关，而旁路由的 WAN 口未接线，导致流量无法上行。关闭旁路由 DHCP 后，主路由统一分配地址，旁路由仅作为网关转发。

常见问题 3 OpenWrt 科学上网为什么推荐 TPROXY 模式

直接结论。TPROXY 保留源 IP 地址，支持 UDP 转发，适合旁路由与游戏主机场景。REDIRECT 会修改目标地址为本地地址，丢失源地址信息，且仅支持 TCP。

技术原理。TPROXY 在 PREROUTING 链中将数据包标记后交给本地 socket 处理，内核保留原始源地址与目标地址。代理核心通过 getsockopt 获取原始目标地址，完成转发。REDIRECT 将目标地址改为本地地址，代理核心无法获取原始目标，且 UDP 流量无法处理。

常见问题 4 全屋设备无感翻墙如何避免 DNS 污染

直接结论。强制劫持所有 53 端口流量到本地 DNS 模块，境外域名走加密 DoH 查询，国内域名走国内 DNS 并行查询。

技术原理。DNS 污染发生在明文 UDP 查询阶段，攻击者伪造 DNS 应答。通过防火墙规则将 53 端口重定向到本地 Clash 或 smartdns，客户端无法直接与外部 DNS 通信。Clash 的 fallback 机制通过 geoip 判断结果归属，若国内 DNS 返回境外 IP，则采用境外 DoH 的结果。

常见问题 5 Clash Meta 的 fake-ip 模式会影响游戏延迟吗

直接结论。fake-ip 模式对游戏延迟影响极小，通常在 1ms 以内。但需要将游戏域名加入 fake-ip-filter，避免虚拟 IP 导致游戏内 NAT 检测异常。

技术原理。fake-ip 模式下，Clash 返回虚拟 IP 给客户端，客户端向虚拟 IP 发起连接，Clash 根据连接目标反查域名。该过程在本地完成，不引入额外网络延迟。游戏主机的 NAT 类型检测依赖真实 IP 与端口映射，虚拟 IP 会导致检测失败，因此需要将游戏相关域名加入白名单。

常见问题 6 旁路由方案会导致主路由 NAT 类型变严格吗

直接结论。旁路由方案不会改变主路由的 NAT 类型。游戏主机的 NAT 类型取决于主路由的 UPnP 与端口映射配置。

技术原理。旁路由仅作为网关转发流量，不参与 NAT 转换。主路由负责公网地址与内网地址的映射。若游戏主机需要开放 NAT，需在主路由上启用 UPnP 或手动配置端口映射。旁路由的 TPROXY 规则不影响主路由的 NAT 表。

常见问题 7 DNS 防污染网关需要单独部署 smartdns 吗

直接结论。家庭场景下 Clash Meta 内置的 DNS 模块已足够。内网设备超过 50 台或需要测速优选时，建议单独部署 smartdns。

技术原理。Clash Meta 的 DNS 模块支持 fake-ip、fallback 与 geoip 过滤，可满足基本防污染需求。smartdns 支持多线程并行查询、测速优选与缓存共享，在高并发场景下响应更快。两者可配合使用，smartdns 作为上游，Clash 作为下游。