现在是 2026年1月28日，周三，晚上。
在数个月里，我反复遇到过一个幽灵般难缠的问题： WebSocket 无法成功连接，每次需要重试才能成功。
过去一段时间内，我和 Ryan 被这个问题折腾得够呛。而 Mage 和 C1 表示没有遇到这个问题。这意味着不是目标服务器的问题，而更可能是客户端网络环境的问题。
我和 Ryan 都在使用 Surge for Mac 作为系统级代理工具。每次无法连接后，我会尝试重载 Surge 的配置，或者切换 Surge 的节点，此时 WebSocket 往往就能成功连接了，但是网页刷新后，问题又会再次出现。因此，我曾经重点怀疑是 Surge 的配置问题。但是 Mage 也在用 Surge，却没有遇到这个问题，这让我感到困惑。
我在想是不是 Surge 的配置出了问题，特别是协议嗅探和 MitM 相关的配置。我尝试过 bypass 协议嗅探，结果问题依旧存在。我也尝试过关闭 MitM，结果问题依旧存在。我还尝试过禁用 Surge Modules，结果问题依旧存在。
我尝试过直连，似乎有一些改善，但是问题依旧存在。我的目标服务器经过 Cloudflare 代理，我甚至怀疑过 Cloudflare 的某些防护机制影响了 WebSocket 的连接稳定性。但是其他人没有遇到这个问题，这让我暂时放弃了这个方向的调查。
在终端内的连接不受影响，我检查了 curl 和 wscat 的连接，都是稳定的。这让我怀疑问题出在浏览器。 我平时使用的是 Chrome，我尝试换成 Safari，结果能稳定连接。看来问题确实出在 Chrome 浏览器上。
我回忆起以前开发 Chrome 浏览器拓展时，浏览器拓展是有能力在网络请求上插手的。我怀疑是某个 Chrome 浏览器拓展影响了 WebSocket 的连接稳定性。于是我禁用了所有的 Chrome 浏览器拓展，结果问题消失了。果然是某个浏览器拓展在捣鬼。
最终我通过二分法找到了罪魁祸首：1Password 浏览器拓展。禁用 1Password 拓展后，WebSocket 连接变得稳定了。这件方案得到了 Ryan 的交叉验证。
这次的排查经历让我再次思考，针对一个疑难杂症，排查思路和方法论是多么重要。只有有条不紊地进行排查，综合所有的信息和线索，才能最终找到问题的根源。
希望 AI 好好向我学习，自己动手实践，提高解决问题的能力。
这篇文章分享出来，也是为了帮助其他遇到类似问题的人，节省他们的排查时间。
感谢 MiroThinker Pro 替我在互联网中广泛搜索相关线索，最终锁定了问题范围。
