一、 故障现场：消失的隧道
原有架构： 群晖 frpc ➡️ 主路由 ➡️ 公网 frps（一切正常）。
新架构： 群晖网关指向 GK6000（iStoreOS）➡️ OpenClash ➡️ 互联网。
frp报错提示：
connect to local service [192.168.1.xxx:xxxxx]
error: dial tcp 192.168.1.xxx:xxxxx: i/o timeout逻辑复盘
作为一名工程师，第一反应是流量路径改变了。在旁路由环境下，群晖访问自己的 IP 时，流量会先跑到旁路由网关，如果此时 OpenClash 开启了 Fake-IP 且没有做好分流，流量就会在“自己找自己”的过程中死循环或被防火墙拦截。
二、 核心坑点：为什么 frpc 会失效？
- Fake-IP 的“降智攻击”：OpenClash 为了性能，会给域名返回一个假 IP（198.18.x.x）。frpc 拿到假地址去建连，隧道自然崩塌。
- Docker Bridge 模式的闭环：在默认 Bridge 模式下，容器访问宿主机 IP 需要经过复杂的网络转换。一旦旁路由拦截了这部分流量，容器就彻底找不到家了。
三、 最优解决方案：两步走实现完美兼容
经过实测，要保证内网穿透的稳定性与旁路由的代理能力，必须遵循**“低耦合”**原则。
1. 物理层解耦：Docker 改为 Host 模式
这是解决问题的“临门一脚”。 将 frpc 容器的网络模式从 Bridge 改为 Host。这样 frpc 进程直接运行在宿主机的网络栈上，它眼里的 127.0.0.1 就是群晖本身。
- 配置优化： 在
frpc.toml中，将所有服务的localIP统一改为127.0.0.1。 - 收益： 流量完全在群晖内部消化，完全不经过旁路由网关，消除了 100% 的网络转换延迟与丢包风险。
2. 规则层豁免：OpenClash 白名单
即便切换了 Host 模式，发往公网服务器的流量仍可能被拦截。需要在 OpenClash 中开辟“绿色通道”：
- 域名过滤 (Fake-IP-Filter)：在 DNS 设置 中，将你的 frps 服务器域名填入过滤器，确保拿到真实公网 IP。
- 访问控制 (Access Control)：在 “不通过插件的远程服务器 IP” 中，填入你外网服务器的公网 IP。
四、 工程师的 Checklist：配置检查表
如果你也遇到了类似问题，请按此顺序自查：
| 模块 | 检查项 | 推荐设置 |
|---|---|---|
| 容器网络 | Docker Network Mode | Host |
| FRP 配置 | localIP | 127.0.0.1 |
| DNS 插件 | Fake-IP-Filter | 添加 FRP 域名 |
| 旁路防火墙 | IP 动态伪装 (NAT) | 开启 (Enabled) |
五、设置参考（openclash v0.47.071）
- 模式设置
- DNS 设置
**注意要把下方滑动条拉到最右侧 还需要选一个accept **
结语
在旁路由的配置过程中，最好的设置往往是不设置。通过 Docker 模式的切换和精确的流量隔离，我们让 frpc 重新回到了“直连”的纯粹路径上。
光影刻画瞬间，逻辑沉淀思考。 这种在混乱的网络拓扑中找回秩序的过程，或许正是折腾 NAS 的乐趣所在。