OpenClash Fake-IP 与 Cloudflare Tunnel冲突问题完整解决记录
一、问题的开始：Tunnel 启动了，但就是连不上
事情起源于一次看似非常普通的部署。
在 iStoreOS 路由器上，我同时运行着：
OpenClash（Meta 内核，Fake-IP 模式）
Cloudflare Tunnel（cloudflared）
cloudflared 能正常启动，配置文件也没有报错：
Starting tunnel Generated Connector ID Initial protocol quic
一切看起来都很“健康”。
但几秒钟后，日志开始变得不对劲：
Failed to dial a quic connection timeout: no recent network activity Retrying connection
它在不断重试，却永远连不上 Cloudflare Edge。
二、第一反应：是不是 QUIC 的锅？
cloudflared 默认使用 QUIC，而 OpenClash 里我开了：
禁用 QUIC
UDP 443 拦截
绕过大陆
直觉告诉我：QUIC 被掐了。
于是我做了第一轮修改：
禁用 OpenClash 的 QUIC 拦截
放行 UDP 443
尝试强制 cloudflared 使用 HTTP2
结果？
毫无变化。
日志依然是：
failed to dial to edge with quic
这一步让我第一次意识到：
问题可能不在“连接”，而在“连向哪里”。
三、开始怀疑 DNS
于是我转向 DNS。
我在路由器上直接执行：
nslookup region1.argotunnel.com
返回结果却让我愣了一下：
Server: 127.0.0.1 *** Can't find region1.argotunnel.com: No answer
一个 Cloudflare 官方使用的域名，居然 没有任何应答。
这已经不是 QUIC 的问题了。
四、深入一点：Fake-IP 的影子开始出现
我继续测试其它 cloudflare 域名，发现情况开始变得诡异：
有的域名返回 198.18.x.x
有的域名直接 No answer
有的偶尔能解析，但连接仍失败
198.18.x.x 这个地址段非常眼熟。
Fake-IP 专用地址段
这一刻，线索终于连起来了。
五、真相浮现：cloudflared 根本不认识 Fake-IP
OpenClash 的 Fake-IP 机制是：
DNS 返回假 IP（198.18.0.0/15）
实际连接时由内核接管并重定向
这套逻辑对 浏览器、系统流量 非常友好。
但 cloudflared 是什么？
一个 独立进程
自己解析 DNS
自己发起 QUIC / TLS
完全不走透明代理
也就是说：
cloudflared 拿到 Fake-IP 后，会真的去连那个假 IP。
于是所有症状都解释通了：
QUIC 超时
没有网络活动
Edge 永远连不上
不是 Cloudflare 的问题，也不是 OpenClash 的 bug，而是两者的设计根本不兼容。
六、第一次“以为解决了”：Fake-IP-Filter
知道是 Fake-IP 的问题后，我第一时间想到的是：
Fake-IP-Filter
在 OpenClash 的 DNS 设置里，我找到了这个选项（它藏得真的不显眼）。
我加上了：
*.cloudflare.com *.argotunnel.com *.trycloudflare.com region*.argotunnel.com
并设置为 黑名单模式。
重启 OpenClash，重启 dnsmasq。
再测一次：
nslookup region1.argotunnel.com
结果仍然不稳定。
有时能解析，有时不行，有时还是走了 Fake-IP。
这时候我意识到一件事：
Fake-IP-Filter 只是“不返回 Fake-IP”，但 DNS 还是可能被 Clash 接管。
七、最终的关键：Nameserver-Policy
真正解决问题的，是我最后加上的 Nameserver-Policy。
在 OpenClash 的 DNS 设置中，我明确写下：
'+.cloudflare.com': '223.5.5.5' '+.argotunnel.com': '223.5.5.5' '+.trycloudflare.com': '223.5.5.5' 'region*.argotunnel.com': '223.5.5.5'
这一刻，本质发生了变化：
cloudflared 相关域名
完全绕过 Clash 的 DNS 逻辑
直接用真实、直连的 DNS 解析
重启 OpenClash → 重启 dnsmasq。
八、验证时刻
再次执行：
nslookup region1.argotunnel.com
返回：
Name: region1.argotunnel.com Address: 104.xxx.xxx.xxx
紧接着，cloudflared 日志变成了：
Connected to edge Tunnel established
问题彻底消失。
九、回头看：这是一个“配置过于正确”的坑
整个过程里，没有任何一处是“明显配置错误”：
OpenClash 配得很规范
Fake-IP 是推荐模式
cloudflared 也是官方用法
但正是因为 每一层都很“聪明”，才导致它们在一起时完全不通。
十、最终结论
Cloudflare Tunnel 与 Fake-IP 机制在设计上不兼容。
唯一稳定、可控、长期有效的解法是：
Fake-IP-Filter 排除 cloudflared 域名
Nameserver-Policy 强制真实 DNS
不指望 cloudflared 走透明代理
十一、写在最后
这类问题最难的地方不在配置，而在：
判断“哪里不该被代理”
接受“不是所有流量都适合 Fake-IP”
当你意识到这一点时，问题就已经解决了一半。
