局域网代理环境下 Cloudflare Tunnel 出口 IP 异常排查与解决

在网络折腾的圈子里，爱快主路由搭配 OpenWrt/软路由作为旁路由，是一个非常经典的“无痛科学上网”组合。这种架构下，通过策略路由，我们可以轻松实现让局域网内的特定设备或流量“翻墙”。

然而，这种“全局或半局”的代理环境偶尔也会带来一些意想不到的副作用。最近，就有不少朋友在搭建 Cloudflare Tunnel（以前叫 Argo Tunnel）时遇到了一个棘手的问题：明明为了方便没有 IPv6 的外网环境访问才部署的 Tunnel，结果出口 IP 竟然变成了代理服务器的 IP，而不是家里的真实宽带 IP。

这就导致了一个尴尬的局面：如果你想通过 Tunnel 访问家里只有白名单允许的服务（比如某些只信任自家 IP 的 API 接口），或者仅仅是因为某些服务检测到了代理 IP 而拒绝访问，就会直接 GG。

问题根源分析：为什么 Tunnel “被迫”走代理？

首先，我们要简单梳理一下 Cloudflare Tunnel 的工作原理。Cloudflare Tunnel 通常由两部分组成：

1. Cloudflared 客户端（daemon）：运行在你的内网服务器上，负责主动连接 Cloudflare 的边缘节点。
2. Cloudflare 边缘网络：接收外部用户的请求，并通过建立的加密隧道转发给你的内网服务器。

问题的关键就在于这个 Cloudflared 客户端。在你的网络架构中，内网服务器的网关指向了旁路由（SMBox），而旁路由默认配置了科学上网规则。通常情况下，我们为了防止代理节点被墙或者提高稳定性，会在旁路由上设置“常见域名或常见服务直连”。很多新手会理所当然地以为，只要把 Cloudflare 的相关解析域名（比如 .*.cloudflare.com）设置为直连，问题就解决了。

但这往往是不够的。

Cloudflared 客户端与 Cloudflare 边缘节点通信时，并不总是走我们熟知的 443/80 端口的域名解析流量。在某些握手、心跳包或者边缘节点 IP 变化的情况下，它可能会直接与 IP 地址进行通信。而这些云厂商的 IP 段通常会包含在 GFW 黑名单中，或者被你的旁路由规则识别为“需要代理”的流量。结果就是，Cloudflared 发起的出站连接被旁路由强行接管，送到了代理通道，导致出口 IP 变成了代理节点的 IP。

图示：在爱快+旁路由架构下，Cloudflared 流量流向示意图。

解决方案一：让 Cloudflared 客户端“绕过”代理（推荐）

既然问题的核心是 Cloudflared 被旁路由“误导”了，那么最稳妥的解决办法就是明确告诉旁路由：这台服务器负责 Tunnel 的流量，或者 Cloudflared 这个进程，必须走直连。

如果你的旁路由是基于 OpenWrt 或类似的 Linux 系统：

你可以利用 ip rule 策略路由或者 iptables 标记来实现。最简单的做法是检查 Cloudflared 进程的 UID/GID，然后为该用户的所有流量创建单独的路由表，直接指向主路由网关，绕过旁路由。

对于爱快用户，如果不想写复杂的脚本，可以尝试在爱快主路由上设置:

1. 在“行为管理”或“IP 组”中，将运行 Cloudflared 的服务器 IP 选中。
2. 设置针对这台服务器的特殊分流规则，将其下一跳直接设为 WAN 口（光猫/运营商），而不是旁路由网关。
3. 规则优先级设为最高，确保流量不流向旁路由。

这样，无论 Cloudflared 请求什么 IP，它都会物理上绕过代理通道，直接走家里的宽带出口，IP 自然就正确了。

解决方案二：精细化的域名+IP 白名单（治标）

如果你无法修改路由器的拓扑结构，或者不想针对单一机器做路由策略，那你需要非常精细地维护你旁路由里的“直连规则”。

仅仅添加 cloudflare.com 是不够的。你需要找到 Cloudflare 官方公布的 IP 段（通常是 IPv4 和 IPv6 的 CIDR 列表），并将这些 IP 段全部加入到你的“直连/白名单”列表中。

• 操作思路：定期更新 Cloudflare 的 IP 列表（可以通过脚本抓取官方 API），然后写入到你的 PassWall 或 SSrPython 的直连设置中。

这个方法的缺点是维护成本较高，如果 Cloudflare 新增了边缘节点 IP 而你没有及时更新，Tunnel 可能又会“断连”或走代理。

解决方案三：IPv6 DDNS 的降级备选

你在问题中提到了已经配置了 IPv6 DDNS。其实，在当前的网络环境下，IPv6 的普及率已经相当高了。如果你的运营商提供了公网 IPv6，且大部分你需要访问的设备（如手机、PC）都支持 IPv6，那么完全可以直接使用 IPv6 地址访问，彻底抛弃 Tunnel 的端口映射复杂性。

• 针对无 IPv6 环境：保留 Tunnel，但仅作为备用方案。
• 针对有 IPv6 环境：优先使用 IPv6 + DDNS，或者在 DNS 解析中设置“双栈解析”，优先返回 AAAA 记录。

注意：有些代理插件对 IPv6 的支持不如 IPv4 完善，有时候走 IPv6 反而能天然“绕过”代理设置（如果你的旁路由规则主要针对 IPv4）。你可以尝试关闭 Cloudflared 的 IPv4 支持，强制使用 IPv6 连接 Cloudflare 节点（如果网络允许），这也可能解决 IP 异常问题。

总结

遇到 Cloudflare Tunnel 出口 IP 变成代理 IP，不要慌，这大概率是策略路由的“误伤”。最根本的解决思路是物理隔离——即让建立隧道的那台机器，或者那个进程，不要经过代理软件。

如果你正在玩软路由，建议在爱快主路由上做针对性的 IP 组分流，这是最省心且稳定的方案。毕竟，Tunnel 是为了内网穿透服务的，如果它自己都“穿”不出去，那内网服务就成了孤岛了。