> ## Documentation Index > Fetch the complete documentation index at: https://docs.x.com/llms.txt > Use this file to discover all available pages before exploring further. # 切断の処理 > Filtered Stream、Volume Streams、Powerstream、Compliance Streams などの X ストリーミングエンドポイント利用時の切断の処理方法を学びます。 [Filtered Stream](/x-api/posts/filtered-stream/introduction)、[Volume Streams](/x-api/posts/volume-streams/introduction)、[Powerstream](/x-api/powerstream/introduction)、[Compliance Streams](/x-api/compliance/streams/introduction) など、X のストリーミングエンドポイントを利用する際の切断の処理方法を学びます。 ## 切断とは何か ストリーミング API への接続とは、非常に長時間の HTTPS リクエストを行い、レスポンスを逐次的にパースすることを意味します。ストリーミングエンドポイントに接続する際は、HTTPS リクエストを構築し、実用的な限り長い間、その結果のストリームを消費してください。 X サーバーは、以下の場合を除き、接続を無期限に保持します。 * サーバー側のエラー * 過度なクライアント側の遅延 * ネットワークの問題 * 定期的なサーバーメンテナンス * 重複ログイン ストリーミング接続では、切断は **発生する** ものとして想定してください。アプリケーションには再接続ロジックを組み込む必要があります。 *** ## 切断の理由 切断の考えられる理由: | Reason | Description | | :---------- | :----------------------------------------------------------------------- | | 認証エラー | 誤ったトークンまたは認証方式が違う | | サーバー再起動 | X 側のコードデプロイ — 想定して設計してください | | クライアントが遅すぎる | クライアントがボリュームに追いついていない。サーバー側のメッセージキューが大きくなりすぎて接続が閉じられる | | クォータ超過 | アカウントが日次/月次の Post クォータを超過した | | 接続数超過 | アクティブな冗長接続が多すぎる | | 突然の読み取り停止 | Post の読み取りレートが急激に低下した | | ネットワークの問題 | サーバーとクライアント間の接続の問題 | | サーバーメンテナンス | 一時的なサーバー側の問題や予定されたメンテナンス（[status page](https://api.twitterstat.us/) を確認） | *** ## よくある切断エラー ### Operational disconnect ```json theme={null} { "errors": [{ "title": "operational-disconnect", "disconnect_type": "UpstreamOperationalDisconnect", "detail": "This stream has been disconnected upstream for operational reasons.", "type": "https://api.x.com/2/problems/operational-disconnect" }] } ``` ### Too many connections ```json theme={null} { "title": "ConnectionException", "detail": "This stream is currently at the maximum allowed connection limit.", "connection_issue": "TooManyConnections", "type": "https://api.x.com/2/problems/streaming-connection" } ``` *** ## 切断の検出 ストリーミングエンドポイントは、20 秒ごとに keep-alive heartbeat（改行文字）を送信します。このシグナルを使用して切断を検出します。 1. コードは、新しいコンテンツと heartbeat の受信が停止したことを検出する必要があります 2. 20 秒間データを受信しない場合、再接続ロジックを開始します 3. 一部の HTTP クライアントでは読み取りタイムアウトを指定できます。これを 20 秒に設定してください *** ## 再接続戦略 確立された接続が切断されたら、すぐに再接続を試みてください。再接続に失敗した場合は、エラーの種類に応じたバックオフ戦略を使用します。 ### TCP/IP ネットワークエラー **線形** にバックオフしてください。これらの問題は一般に一時的です。 * 試行ごとに 250ms ずつ遅延を増やす * 最大遅延: 16 秒 ### HTTP エラー 再接続が適切な HTTP エラーには **指数関数的** にバックオフしてください。 * 5 秒待機から開始 * 試行ごとに倍増 * 最大遅延: 320 秒 ### レート制限エラー（HTTP 429） より長い初期待機時間で **指数関数的** にバックオフしてください。 * 1 分待機から開始 * 試行ごとに倍増 * 429 を受け取るたびに、レート制限が解除されるまでの待機時間が増加 *** ## Rate limit と使用状況 ストリーミング接続レスポンスは、制限を理解するのに役立つ 3 つのヘッダーを返します。 | Header | Description | | :----------------------- | :------------------------- | | `x-rate-limit-limit` | 15 分間ウィンドウで許可されるリクエスト数 | | `x-rate-limit-remaining` | 15 分間ウィンドウでこれまでに行われたリクエスト数 | | `x-rate-limit-reset` | ウィンドウがリセットされる UNIX タイムスタンプ | どれだけの Post が配信されたかを追跡するために、消費を測定でき、必要に応じて一時停止できるように、クライアント側でメータリングロジックを実装してください。 *** ## 再接続のベストプラクティス ### FIFO キューアーキテクチャを使用する ストリームクライアントは、着信 Post を FIFO キューまたは同様のメモリ構造に挿入する必要があります。別のプロセス/スレッドがそのキューから Post を消費して、パースと保存を行います。この設計は、Post ボリュームが劇的に変化するときに効率的にスケールします。 ### バックオフ戦略のテスト 無効な認証情報を使用してバックオフ実装をテストし、再接続の試行を検証してください。良い実装では 429 レスポンスを受け取らないはずです。 ### 複数回の再接続でアラートを発行する 再接続間の時間の上限に達した場合、接続の問題を分類できるように通知を送信してください。 ### DNS の変更に対応する クライアントプロセスが DNS Time To Live（TTL）を尊重するようにしてください。一部のスタックは、プロセスの継続時間だけ解決したアドレスをキャッシュし、TTL 内の DNS 変更を検知しません。攻撃的なキャッシュは、X が IP アドレス間で負荷を移動させる際にサービス中断を招きます。 ### User-Agent ヘッダーを設定する クライアントのバージョンを `User-Agent` HTTP ヘッダーに含めてください。これは X 側での問題診断に不可欠です。環境で `User-Agent` を設定できない場合は、代わりに `x-user-agent` ヘッダーを使用してください。 *** ## 次のステップ 切断後の欠落データを復旧 堅牢なストリーミングクライアントを構築 高スループットのストリームを処理