ある日突然「Error 522「Connection timed out」」とブラウザに表示されたことはないですか？

Cloudflare 522「Connection timed out」は、WebサイトやAPIを Cloudflare で運用している技術者にとって避けて通れないエラーです。しかし、原因がネットワーク／サーバー／SSL／Docker／DNS と多岐にわたるため、現場では“どこから調べていいかわからない” という大きな壁があります。

本記事は、実際に私のサーバーで発生した Cloudflare 522 エラー → n8n のダウン → Dockerコンテナ再構築 → 復旧 に至るまでの全記録を、AI（ChatGPT）と共に解決した“リアルな実例”としてまとめたものです。

発端：突然の Cloudflare 522「Connection timed out」

ある日、運用しているサービスにアクセスすると次のエラーが表示されました。

Connection timed out
Error code 522

522 は「Cloudflare がオリジンサーバーと TCP ハンドシェイクできなかった」という意味ですが、原因は多岐にわたります。

サーバーダウン
Firewall の遮断
SSLミス設定
reverse proxy（Caddy/Nginx）の障害
Docker コンテナ停止
ポートの開放漏れ

当初は 原因が特定できず混乱 しました。

そこで、生成AIである ChatGPT に相談しながら、原因を1つずつ切り分けていくことにしました。

ChatGPT を使った障害切り分け：Docker から調査開始

まず ChatGPT は、次のような“初手として的確な指示”を出してくれました。

Docker コンテナが落ちていないか確認
reverse proxy（Caddy）が正常か確認
SSL証明書の期限とパス設定の確認
ポート 443 / 8443 の LISTEN 状態確認
Cloudflare 側のDNS設定確認

実際にサーバーで次を実行して調査しました。

docker ps

すると、

containrrr/watchtower   Restarting (1)

Watchtower がエラーで再起動を繰り返している → リソースを圧迫する可能性
ということが判明！

ChatGPT からも「原因切り分けのため一旦 watchtower の停止を推奨」との回答があり、次のコマンドで停止。

docker rm -f watchtower

原因の第二候補：n8nコンテナが存在しない

522 エラーとは別に、n8n が完全に落ちている ことがわかりました。

docker compose ps

→ 表示に n8n がいない！

設定ファイル（docker-compose.yml）を確認すると、

証明書パス
ポートマッピング
環境変数
ホスト名
SSL設定

など、多くの要素が絡んでいることが判明。

ChatGPT は 1 つずつ丁寧に次のポイントを指摘してくれました。

SSL キーと証明書のパスは正しいか？
N8N_HOST と public URL が一致しているか？
HTTPS を使用する際の N8N_PROTOCOL
コンテナ内で 8443 が LISTEN しているか？
Caddy と競合していないか？

この段階で n8n が起動できていなかったことが 522 発生の副次的原因 と特定できました。

docker-compose.yml を修正し再起動

あなたと ChatGPT のディスカッションを経て、最終的に以下の修正で n8n を復旧させました。

docker compose up -d

起動後の状況：

STATUS: Up 55 seconds
PORT: 8443

ブラウザアクセスも正常化し、

https://n8n.j-makoto.online:8443/

が復活！

Cloudflare 522 → n8n ダウン → Dockerコンテナ再構築 → 完全復活
という流れで完全解決に至りました。

実際にAIを使ってわかった「AIが本当に役立つ瞬間」

今回の復旧は、AIが次の点で確実に役立った実例でした。

① 障害切り分けの優先順位を瞬時に提示してくれる

エンジニアはどうしても「自分の得意なレイヤー」から調べる癖があります。

AIは ネットワーク → Docker → SSL → reverse proxy → Cloudflare の順で“正しい切り分け順”を示してくれるため、時間が短縮されました。

② こちらの状況（ログ・コマンド結果）から次のアクションを即判断する

会話型で原因を深掘りできるのは、従来の検索エンジンにはない強みです。

③ Docker / Caddy / SSL / Cloudflare が複雑に絡む障害でも即座に全体像を把握

多くの技術が混在する障害は、専門知識がないと非常に難しいですが、AIは横断的に依存関係を理解してくれます。

④ 作業後の確認方法まで提示（ps / logs / curl など）

改善案だけではなく、「確認すべき項目」まで的確に提案してくれるので、復旧の精度が上がります。

まとめ：Cloudflare 522 の“本当の原因”と、AI活用の価値

今回の障害でわかったことをまとめます。

Cloudflare 522 の主な原因

サーバー側が応答していない
reverse proxy (Caddy) とオリジンの通信が失敗
8443 ポートにアプリが待ち受けていない
n8n が落ちていた
Watchtower が暴走

➡ 結果として Cloudflare が TCP ハンドシェイクに失敗し、522エラーを返していた。

AIを使った復旧で得られた最大の価値

障害対応の時間を大幅に短縮
切り分けミスがゼロに近くなる
すべてのログを元に“次の行動を指示”してくれる
Docker・Caddy・SSL・Cloudflare の横断的な知識を補完できる
経験が浅い分野も安心して触れる

おわりに

今回の障害復旧は、AIが 単なる検索ツールではなく、実務パートナーとして機能する ことを明確に示した実例になりました。