現在は2026年1月28日、水曜日の夜です。
数ヶ月にわたり、私は幽霊のようにしつこい問題に繰り返し直面してきました：WebSocketが正常に接続できず、毎回リトライが必要になるという問題です。
ここしばらく、私とRyanはこの問題に悩まされ続けてきました。一方、MageとC1はこの問題に遭遇していないとのことでした。これは、ターゲットサーバー側の問題ではなく、クライアント側のネットワーク環境に原因がある可能性が高いことを意味しています。
私とRyanはどちらも、システム全体のプロキシツールとしてSurge for Macを使用しています。接続に失敗するたびに、私はSurgeの設定をリロードしたり、Surgeのノードを切り替えたりしていました。そうすると、WebSocketはしばしば接続に成功するのですが、Webページをリフレッシュすると、問題が再発してしまうのです。そのため、私はSurgeの設定に問題があるのではないかと強く疑っていました。しかし、MageもSurgeを使用しているのに問題が起きていないという事実は、私を困惑させました。
Surgeの設定、特にプロトコルスニッフィングやMitM（Man-in-the-Middle）関連の設定に問題があるのではないかと考えました。プロトコルスニッフィングをバイパスしてみましたが、問題は変わりませんでした。MitMをオフにしてみましたが、問題は変わりませんでした。Surge Modulesを無効にしてみましたが、問題は変わりませんでした。
ダイレクト接続（プロキシ経由でない接続）も試してみました。多少改善は見られたものの、問題は依然として残っていました。私のターゲットサーバーはCloudflareを経由しているため、Cloudflareの何らかの保護メカニズムがWebSocket接続の安定性に影響を与えているのではないかとさえ疑いました。しかし、他の人々がこの問題に遭遇していないことから、この方向の調査は一旦保留にしました。
ターミナル内での接続は影響を受けていませんでした。curlやwscatでの接続を確認しましたが、どちらも安定していました。これにより、問題はブラウザ側にあるのではないかと疑うようになりました。 普段使用しているのはChromeです。Safariに切り替えてみたところ、安定して接続できるようになりました。どうやら問題はChromeブラウザにあるようです。
以前Chrome拡張機能を開発していた時を思い出しました。ブラウザ拡張機能はネットワークリクエストに干渉する能力を持っています。何らかのChrome拡張機能がWebSocket接続の安定性に影響を与えているのではないかと疑いました。そこで、すべてのChrome拡張機能を無効にしてみたところ、問題は解消されました。やはり、どこかのブラウザ拡張機能が原因だったのです。
最終的に、二分探索法を使って原因を特定しました：1Passwordブラウザ拡張機能です。1Password拡張機能を無効にすると、WebSocket接続は安定しました。この解決策はRyanによるクロスチェックでも確認されました。
今回のトラブルシューティングの経験は、難解な問題に対して、調査の考え方と方法論がいかに重要であるかを改めて考えさせてくれました。体系立てて調査を進め、すべての情報と手がかりを総合的に判断することで、初めて問題の根本原因を見つけることができるのです。
AIも私からよく学び、自ら実践して問題解決能力を高めてほしいと思います。
この記事を共有するのは、同様の問題に遭遇した他の方々の調査時間を節約するためでもあります。
MiroThinker Pro がインターネット上で広く関連する手がかりを検索し、最終的に問題の範囲を絞り込むのを手伝ってくれたことに感謝します。
