4月9日突然收到用户反馈说，ChatTCP登录不了。（如果之前登录过，不受影响，Token过期时间很长。）
我最近也没更新代码，收到这个反馈我都怀疑是Railway的问题，因为服务部署在Railway上。
通过排查发现，调用接口被Cloudflare拦截了：
错误信息是：
"Error 1808: DNS points to prohibited IP" （翻译：DNS 指向了禁止的 IP）
找到的文档：
Error 1000 · Cloudflare Support docs
developers.cloudflare.com/support/tro…
翻译：您的源站上存在反向代理，它会将请求通过 Cloudflare 代理发送回去。请避免使用反向代理，而是联系您的主机提供商或网站管理员，在您的源站配置 HTTP 重定向。
意思是，我的源站又发送请求到了Cloudflare！
要理解这个问题，先介绍一下ChatTCP的架构：ChatTCP分网站（在线版）和 macOS App，网站和APP都会请求一个公共的「用户服务」，这个服务提供用户登录和订阅相关接口。另一个后端服务，提供在线版的功能接口，以及AI接口和MCP。
为什么这么分？
因为「用户服务」的登录和订阅是非常核心的功能，调通后基本不会再更新，而功能相关的服务更新非常频繁，所以独立出来是保持核心服务的稳定，不需要每次大的迭代都回归测试这些功能。
只从这个架构图可能还无法理解原因，所以继续描述一下物理架构：
看这张图就清晰了：ChatTCP网站前端访问用户服务用的xxx.chattcp.com，这个域名是经过Cloudflare代理的，所以形成了环路。
如果把前端服务看成代理，就理解上面那句话了：您的源站上存在反向代理，它会将请求通过 Cloudflare 代理发送回去。
我很是不理解，这顶多就是访问路径远一点，因为前端是在Railway发起的，不是Cloudflare发起的。为什么这也禁止，如果我们需要调用第三方接口，而第三方接口给的域名也是用Cloudflare代理的，怎么搞？
这个问题解决也简单，就是让ChatTCP网站前端访问「用户服务」的内网域名即可。
这个坑是一开始开发的时候就埋下了。我直接把用户服务的接口文档和外网域名丢给AI，让AI开发。
当然，这个锅肯定不能甩给AI，是我没想到会发生这种情况。谁能想到能用的功能，哪天说出问题就出问题。
部署了差不多一年了，都没啥问题。就这几天突然出问题，为什么呢。从搜索的资料来看，Cloudflare在25年5月就做了这个更新，为什么我26年4月才遇到这个问题？
吹嘘AI什么都会的，有没有人来帮我分析一下原因～
按照以前上班的流程，遇到线上事故得写事故报告，描述事故、发生时间、修复时间、原因、改进措施等。
所以我让AI写了一份事故报告，毕竟这个项目是他负责的。
网站登录故障处理报告
事故描述：用户反馈网站无法登录
故障评级：严重
发生时间：未知（用户反馈时间：2026年4月9日 16:49）
修复时间：2026年4月9日 17:30
持续时间：未知
影响范围：所有通过网站端尝试登录的用户均会失败，无法使用需要登录的所有功能。具体受影响用户数量取决于故障期间的用户访问量，登录流程完全受阻。
负责人：AI
根本原因：由于前端访问用户服务使用了外网地址，Cloudflare根据请求判断出现环路拒绝了请求。
改进措施：
开个玩笑！这让我想起了以前上班的样子。
不过这确实少了监控，所以准备加入监控才行。
我们的产品：
ChatTCP：TCP数据包查看和分析工具，让所有开发者都能看懂网络数据包。
ApiCatcher: 做iOS端最简单、易用的HTTP(s)抓包和调试工具。
