大容量の写真や動画のリバースプロキシアップロードトラブルシューティングガイド

エヴァ・ウォン

IceWhale author

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

Reverse Proxy Upload Troubleshooting Guide for Large Photos and Videos - Zima Store Online

安全なアプローチとは、制限値、バッファリング、ネットワーク設定を変更する前に、どの層が失敗しているかを特定するサイズと時間の管理されたテストを、単一のコマンドではなく、観測可能なゲートの連続として扱うことです。

1つ以上のプロキシの背後にあるセルフホスト型の写真またはメディアアプリケーションでは、小さなアップロードは成功するものの、大きな写真や動画がリバースプロキシ経由で失敗、リセット、またはタイムアウトすることが実際的なリスクです。現在の識別情報と復旧ポイントを記録し、最も影響の小さい切り分けから始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合、または復旧可能なコピーが保護されていない状態で公開される場合は停止してください。以下のワークフローは、元のワークロードが成功するか、証拠がエスカレーションの境界に達するまで続きます。

サイズの段階を設けて1回のアップロードを再現する

同じクライアント、アカウント、ネットワーク、ホスト名、ファイル形式を使用します。小さな制御用ファイルをアップロードし、その後、段階的に大きなテストファイルをアップロードしながら、正確なバイト数、所要時間、ブラウザーのエラー、HTTPステータス、プロキシのアクセスログとエラーログのタイムスタンプ、アプリケーションログ、部分的なオブジェクトが残るかどうかを記録します。

利用可能であれば、同じ最大サイズのファイルを、信頼できるアプリケーションの直接エンドポイント経由でもテストします。直接接続では成功してプロキシ経由では失敗する場合は、プロキシ経路が原因として疑われます。両方が同じサイズまたは段階で失敗する場合は、プロキシ設定を変更する前に、アプリケーション、ストレージ、またはクライアントの動作を調べます。

すべてのサイズ制限とタイムアウト制限を一度に引き上げないでください。現在の設定と空き容量の測定値を保持し、テストによってアプリケーションのデータボリュームが満杯になったり、保護されていないバックエンドエンドポイントが公開されたりする場合は停止します。

サイズによる拒否と経過時間による失敗を区別する

再現可能なバイト数のしきい値で即座に413または拒否が返る場合は、最初の層にあるボディサイズポリシーがそのステータスを返していることを示します。再現可能な時間が経過した後に408、499、502、504、または接続リセットが発生する場合は、クライアント、プロキシ、アップストリーム、トンネル、またはアプリケーションのタイムアウトが原因である可能性が高くなります。

大容量アップロードのタイムアウト事例に関するTraefikコミュニティの事例は、所要時間とプロキシからアプリケーションまでの完全な経路が重要である理由を示しています。通常の写真のアップロードやブラウジングが機能していても、トンネル経由では大容量アップロードが失敗することがあります。この事例は診断上の特徴として扱い、普遍的なタイムアウト値とはみなさないでください。

制限を適用できるすべてのホップを洗い出します。CDNまたはトンネル、エッジプロキシ、認証プロキシ、アプリケーションプロキシ、アプリケーションサーバー、ランタイム、アップロードエンドポイントです。最初に失敗をログに記録する、または返す層を、次のテストの対象にします。

バッファリング、一時ストレージ、トランスポートを確認する

管理されたファイルをアップロードしている間、プロキシの一時ディレクトリ、コンテナの書き込み可能レイヤー、アプリケーションのアップロード先、ファイルシステムの容量、使用可能なinode、メモリを観測します。アプリケーションが本文を受け取る前に、バッファリングによってディスクやメモリが消費されることがあります。そのため、最終的なライブラリボリュームに十分な容量があっても、プロキシに作業領域があることの証明にはなりません。

複数層にまたがる大容量アップロードの失敗に関するNextcloudとTraefikの報告は、同じ大容量ファイルの症状がWeb、アプリケーション、プロキシの各層にまたがる可能性を示しています。多層にわたる点を教訓として活用しつつ、変更は実際に失敗したステータス、ログのタイムスタンプ、リソースに結び付けてください。

失敗が一定のサイズまたは時間の境界に収まらず変動する場合は、Ethernet、Wi-Fi、VPN、直接LANの経路を比較します。アプリケーションの制限を引き上げてトランスポートのリセットを隠すのではなく、安定した経路を1つ残し、MTU、パケット損失、トンネルの動作を個別にテストします。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

適合する修正を1つ適用し、元のアップロードを再実行する

確認された境界だけを変更します。範囲を限定したボディサイズ制限、特定のリクエストまたはレスポンスのタイムアウト、バッファリングモード、一時ストレージの割り当てのいずれかです。認証、TLS、関係のない仮想ホストは変更せず、プロキシをリロードして有効な設定を確認します。

直接経路とプロキシ経路のテストに関するZimaSpaceのワークフローは、再起動後に直接経路とプロキシ経路を比較することで、プロキシ経路を切り分ける方法を示しています。ここでも同じ境界に対して適用し、まったく同じ大容量ファイルを2回再実行して、最終サイズ、可能な場合はチェックサム、メタデータ処理、一時ファイルの削除を確認します。

プロキシを1回再起動し、元のリモート経路からアップロードを再実行します。小さいファイルと大きいファイルが、新たな公開やストレージ圧迫なしに成功した場合のみインシデントを終了します。制限の変更が他のホストに影響する場合はロールバックし、再現可能な境界がない場合は、ステータス、時間、層、リソースの証拠を添えてエスカレーションします。