大容量の写真や動画のアップロードに合わせてリバースプロキシのタイムアウトを設定する方法

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

受け入れ可能な最も遅い正規のアップロード速度を基準に、余裕を加えてプロキシのタイムアウトを設定し、アプリケーションと上流プロキシは少なくともそれ以上に許容範囲を広く保ちます。失敗するアップロードをすべて、無制限のタイムアウトを選ぶことで解決しようとしないでください。

大きな写真や動画は、同じアプリが通常どおり動作していても失敗することがあります。これは、リクエスト本文、上流での処理、またはレスポンスが別の制限に達するためです。まず、ステータスコード、経過時間、ファイルサイズ、プロキシログを記録してください。これらの観測結果から、本文サイズによる拒否、アイドルタイムアウト、バックエンドのタイムアウト、クライアント切断を区別できます。

アップロードを終了させている段階を特定する

既知の1つのファイルで再試行し、転送中、進行状況バーが100パーセントに達した後、またはサーバーがメディアを処理している間のどの時点で失敗するかを記録します。各段階は、異なる接続およびタイムアウトに対応します。

毎回同じバイト数で失敗する場合は、本文サイズの制限が示唆されます。同じアイドル時間の後に失敗する場合は、タイムアウトが考えられます。アップロード完了後にゲートウェイエラーが発生する場合は、プロキシからアプリケーションへの待機時間、またはアプリケーション独自の処理制限が原因である可能性があります。

プロキシのアクセスログとエラーログを、アプリケーションログと併せて確認します。先にクライアントが接続を閉じていた場合、プロキシのタイムアウトだけを延長しても効果はありません。モバイル端末のバックグラウンド動作、VPNの安定性、ブラウザのリクエスト経路を確認してください。

妥当なタイムアウト予算を測定する

受け入れる最大ファイルサイズを、サポート対象とする最も遅い上流速度で割って転送時間を見積もり、TLS、バッファリング、速度変動のための余裕を加えます。これを正当な処理に対する上限として使用し、遅い接続をいつまでも維持できるという保証にはしないでください。

合計時間とアイドル時間を区別します。たとえば、NGINXには個別のプロキシタイムアウトディレクティブがあり、レスポンス全体の時間ではなく、連続する処理間の間隔を測定するものもあります。

サービス拒否攻撃のリスクを考慮してください。接続の存続時間を大幅に延長する前に、認証とレート制御でアップロードエンドポイントを制限し、プロキシの管理インターフェースを公開しないでください。

過剰に修正せず、すべての層を整合させる

リクエスト本文のサイズを、アプリケーションがサポートする最大値以上に設定します。次に、確認された失敗段階に応じて、クライアント本文、上流接続、上流読み取り、上流送信の各タイムアウトを調整します。

外側にあるCDN、トンネル、ロードバランサー、またはより短い固定制限を持つ2つ目のリバースプロキシがないか確認します。実効的な制限はチェーン内で最も小さい値になるため、内側のプロキシだけを変更しても、目に見える結果が得られないことがあります。

アプリケーションのURLとプロキシのルートを文書化しておきます。ZimaSpaceのネットワーク共有上のImmichに関するガイドは、アップロード経路のエラーとストレージマウントの遅延や障害を切り分けるのに役立ちます。

低速、大容量、中断されたアップロードを再テストする

元の失敗したファイルを、元と同じ場所およびネットワーク速度でアップロードします。成功と判断するには、完了、アプリケーションによるインデックス作成、再生または表示可能なアセットの生成まで確認する必要があります。HTTP成功コードだけでは不十分です。

テスト接続をサポート対象の最低速度まで制限して、再度実行します。次に、1つのアップロードを意図的に中断します。一時ファイルと不完全なデータベースレコードが、アプリケーションの動作仕様に従ってクリーンアップされることを確認してください。

ログにバックエンドのクラッシュ、ストレージエラー、または外部プロバイダーによる固定制限が示されたら、タイムアウトの延長を止めます。過剰な値を元に戻し、失敗している層を修正したうえで、測定した処理量を一貫してカバーできる最小限のタイムアウトを維持してください。

よくある質問

すべてのプロキシタイムアウトに同じ値を設定すべきですか? いいえ。接続の確立、クライアント本文の読み取り、上流レスポンスの待機、下流への送信は、それぞれ異なる段階を保護します。

小さな写真は処理できるのに、動画は失敗するのはなぜですか? 動画は本文サイズのしきい値を超える、アイドル制限より長くかかる、またはサーバー側でより長い処理を必要とする可能性があります。ログと失敗するタイミングから原因を特定できます。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.