HTTP 522 Connection Timed Out (Cloudflare)

Scrapeless Web Unlocker は、オリジン接続の失敗と利用可能な結果を区別する必要があるワークフロー向けに、公開ページコンテンツを取得します。

HTTP 522 Connection Timed Out は、オリジン Web サーバーへの接続中にタイムアウトが発生したことを報告する Cloudflare エラーです。ブラウザは Cloudflare には正常に到達していても、Cloudflare がその背後のサーバーとの必須の接続確立処理を完了できていない場合があります。そのため、修復作業は通常、ウェブサイト運営者またはホスティングプロバイダ側の担当範囲となります。

522 がリクエスト経路のどこで発生するか

522 は、リクエスト経路のうち Cloudflare からオリジンへの区間で発生します。訪問者はまず Cloudflare と通信し、その後 Cloudflare がサイトを提供するオリジンと通信する必要があります。後半の区間で障害が起きると、訪問者には通常どおりエラーページが届くことがあります。そのページを受け取ったことは、訪問者が HTTP レスポンスを受信したことは証明しますが、オリジンが要求された処理を実行したことまでは証明しません。

The Cloudflare 522 の定義 では、関連する 2 つのケースを挙げています。1 つは TCP 接続確立前のタイムアウト、もう 1 つは接続確立後の確認応答の欠如です。これらはトランスポート層での観測結果です。2 つ目のケースを、「アプリケーションが完全なレスポンスを生成するのに時間をかけすぎただけだ」という主張に置き換えないでください。確認応答とアプリケーション処理完了は別のイベントです。

アプリケーションのアクセスログには、リクエストがアプリケーション層に到達していない場合、対応するエントリが一切残らないことがあります。その欠如は、他の証拠と組み合わせて初めて意味を持ちます。接続障害、ログの欠落、あるいは別のオリジンにリクエストが届けられたことを示している可能性があります。どの説明が当てはまるか判断する前に、宛先とログ取得範囲を確認してください。

522 が近縁のエラーと異なる点

HTTP ステータスとローカル例外は、異なる境界を表現します。 HTTP セマンティクス標準 は一般的なゲートウェイおよびサーバーのステータスを定義している一方で、522 は Cloudflare 固有の診断コードです。この区別をインシデント記録に保持しておくことで、問題を適切な担当者に振り分けやすくなります。

単一のインシデントから、複数の症状が生じることがあります。締め切りの短い収集クライアントは、Cloudflare が 522 を返す前に待機をやめてしまうかもしれません。一方で、より長い締め切りを持つ別のクライアントは、そのエラードキュメントを受け取る可能性があります。これらの観測結果は、同じ基盤となる障害を指し示しつつも、同じエラーカテゴリとは限りません。

キャパシティ変更の前にオリジンアドレスを確認する

設定されているオリジンアドレスは、その時点でウェブサイトを処理するようプロビジョニングされているサーバーと一致していなければなりません。Cloudflare の DNS 設定を、ホスティングプロバイダの現在のアドレスおよび想定される環境と照合してください。最近の移行、インスタンスの入れ替え、DNS の編集により、トラフィックが古い宛先に向けられたままになっている場合があります。

オリジンが想定しているホスト名とポートを検証してください。サーバーがオンラインであるだけでは不十分で、必要なリスナーが存在しない場合や、期待するバーチャルホストが提供されていない場合があります。認可された直接オリジンチェックを行う際には、正しいホスト名と TLS の前提条件を維持してください。IP のみを使ったテストでは、別のバーチャルホストが動作し、誤解を招く証拠となる場合があります。

調査範囲は絞り込んでください。あるホスト名だけが失敗し別のホスト名は正常な場合、ホスティングプラットフォーム全体がダウンしていると決めつけるのではなく、それぞれのオリジンマッピングとルーティング設定を比較してください。同一オリジン上の関連しない複数サイトが同時に障害を起こしている場合には、共有ネットワークや共通リソースに関する証拠の方が重要になります。

ファイアウォールとホスティングネットワーク制御を点検する

ファイアウォールの調査では、Cloudflare からの接続がオリジンに到達し、期待どおりの応答を受け取れているかどうかを確認する必要があります。ホストファイアウォール、セキュリティグループ、ホスティングフィルタ、および経路上の自動ブロッキングシステムを確認してください。外側のネットワーク層にある制御は、オペレーティングシステムがアプリケーションリクエストを記録する前にトラフィックを破棄する可能性があります。

アーキテクチャが Cloudflare からオリジンへのアクセスを必要とする場合、現在の Cloudflare アドレスレンジが想定されたポリシーで処理されていることを確認してください。診断の近道として、特定のポリシーを制限のないパブリックアクセスに置き換えないでください。ホスティングプロバイダーに、関連するドロップの送信元、送信先、アクション、およびタイムスタンプを特定するよう依頼してください。

最初に障害が発生した期間と構成履歴を比較します。停止と同時に行われたルール更新は「証拠」ではなく「手がかり」です。ログやパケット証拠の中から一致するトラフィックを探し、そのうえで正当化できる最小限の修正をテストします。後のクリーンアップで同じ制限を再導入してしまわないよう、ルールの理由を文書化してください。

動作しているが応答しないオリジンを調査する

オリジンが稼働していても、リソースやネットワーク経路が制約されている場合、接続を適切に受け付けたり応答したりできないことがあります。接続数、リスナーの健全性、CPU プレッシャー、メモリプレッシャー、およびホスティングプロバイダーによるネットワーク上の観測結果を確認してください。障害が新規接続、既存接続、あるいは特定のパスの一部だけに影響しているかどうかを確認します。

アプリケーションメトリクスだけでは問題を見逃すことがあります。リクエストスループットが低いダッシュボードは、アプリケーションに余力があることを意味する場合もあれば、リクエストがアプリケーションに届いていないことを意味する場合もあります。アプリケーションのテレメトリをトランスポートおよびホストのメトリクスと組み合わせ、低スループットを健全なサービスと取り違えないようにしてください。

Keep-alive 設定も、デプロイメントの要件に照らして確認する価値のあるオリジン側の詳細です。複数のトランスポート設定を一度に変更することは避けてください。狭い範囲でテストされた変更は解釈可能な証拠を生みますが、DNS、ファイアウォールルール、サーバーキャパシティを同時に変更すると、どの変更が接続経路を修復したのか判断しづらくなります。

ブラウザとオリジンの証拠を結びつけるタイムラインを使用する

タイムラインには、訪問者がナビゲーションを開始した時刻、Cloudflare がエラーを返した時刻、その間にオリジンが観測した内容を示す必要があります。ブラウザ側のタイミングとサーバー側のタイミングは異なる視点を表します。 Navigation Timing model はナビゲーションの各フェーズを区別するのに役立ちますが、ブラウザ側のタイミングだけでは Cloudflare とオリジン間のすべてのやり取りを明らかにすることはできません。

インシデント管理システムでは、タイムスタンプとともにタイムゾーンを記録してください。利用可能な場合はエラーページのリクエスト識別子を、関連するホスト名およびオリジンログと相関させます。クロックが同期していない場合、異なるマシン上で発生したイベント間に正確な一致があると主張するのではなく、その旨を明示してください。

同じルーティング構成のもとで、障害が発生した期間と、正常に動作していたことが分かっている期間を比較します。宛先、接続の成功状況、ホストの健全性の変化に注目してください。単発のページ読み込み成功は、特に複数のオリジンや地理的経路が関わる場合、影響を受けた全期間にわたってオリジンが健全だったことを証明するものではありません。

訪問者とデータ収集者が保存すべきもの

訪問者は、サイト運営者がオリジン経路を調査できるだけの十分な証拠を保存するべきです。影響を受けたアドレス、エラー番号、おおよその時刻、およびページに表示されているリクエスト識別子を含めてください。問題がサイト全体に及んでいるのか、特定のアクションだけに影響しているのかを報告しますが、プライベートなクエリパラメータや認証情報は開示しないでください。

データ収集者は、522 の結果をターゲットデータセットの外に保持するべきです。タスクが商品の価格を収集することであった場合、Cloudflare のブランディングを含む有効そうに見える HTML ドキュメントであっても、そのタスクを満たしたことにはなりません。分類された失敗として保存し、過去の価格データは元の収集時刻とともに保持してください。これにより、最新データが欠落している状態と、本当に価格が変わっていない状態を区別できます。

この Cloudflare content-validation workflow は、この受け入れ境界に関連します。トランスポート完了後にページの同一性と必須フィールドを確認してください。収集時点でのエラー処理は、その後ろでデータを利用する側が、欠落した観測値と受け入れられたレコードを区別できる場合にのみ有用です。

Web Unlocker はオリジンサーバーを修復しない

Web Unlocker はパブリックページワークフロー向けにマネージドなコンテンツ取得を提供できますが、Web サイトの DNS マッピングを修正したり、ファイアウォールを再開したり、オリジンのキャパシティを復元したりすることはできません。これらのコントロールは運営者の責任範囲です。522 調査における Web Unlocker の役割は、取得経路とそのリクエストから得られる証拠に限定されます。

描画済みの取得が収集タスクに適しているか判断する前に Web Unlocker introduction を確認し、ワークロード計画には最新の Scrapeless pricing を使用してください。レスポンス契約でサービスレベルの結果とターゲットサイトの結果が区別されている場合、それらを明確に分離しておきます。API 交換が完了したという事実だけでは、ターゲットページの収集が成功したことを自動的に意味しません。

ソースが利用不能な場合の収集停止条件を定義してください。障害のあるオリジンに対して作業を受け入れ続けると、リソースを浪費し、最初に得られた有用な証拠を見えづらくする可能性があります。責任者がソースが意図したトラフィックを提供できると判断した後、自社の運用ポリシーに従って通常の収集を再開してください。

結論

HTTP 522 の調査は、まずオリジンへの接続経路から始まります。宛先を確認し、ネットワーク制御を点検し、トランスポートの証拠とホストの健全性を相関させてください。訪問者と収集者は簡潔なインシデント記録を提供し、利用不能な観測値を正確に保存する必要があります。サイト運営者とホスティングプロバイダーは、根本となるオリジン通信を修復しなければなりません。