「HTTPエラー」の謎
WordPressのメディアライブラリで、単にHTTPエラーとだけ表示される謎の赤いボックスを目にしたことがあるでしょう。これは通常、大容量のファイルアップロードが100%に達した瞬間に発生します。エラーコードも説明もありません。ただアップロードが停止し、ファイルが大きすぎるのか、それともサーバーがダウンしたのか、途方に暮れることになります。
LEMPスタックを管理してきた私の経験では、これは通常、画像自体に問題があるわけではありません。むしろ、アップロード後の処理フェーズで発生するトラブルです。WordPressが画像の複数のサイズ（サムネイル、中サイズ、大サイズ）を生成しようとした際、サーバーのリソース限界に達してしまうのです。
初期分析：推測をやめ、ログを確認する
WordPressのUIには手がかりが表示されないため、内部を確認する必要があります。ログを見ずに対応するのは、暗闇で矢を射るようなものです。すぐに以下の3つの場所を確認することをお勧めします。
- PHPエラーログ (例: /var/log/php8.2-fpm.log):
memory_limitの枯渇エラーやmax_execution_timeのタイムアウトを探します。 - Nginx/Apacheエラーログ:
client_max_body_sizeや "413 Request Entity Too Large" が表示されている場合、PHPに届く前にウェブサーバーがファイルをブロックしています。 - ブラウザコンソール (F12): Networkタブを確認します。500 Internal Server Errorは、画像処理中にサーバーがクラッシュしたことを裏付けることが多いです。
修正1：リソースを大量消費するImagickを制御する
最近の多くのWordPress環境では、画像処理にImagickが使用されています。Imagickは強力ですが、リソースを大量に消費することで知られています。マルチコアのVPSでは、5MBのJPEGファイルを1つ処理するために、利用可能なすべてのCPUスレッドを使用しようとすることがあります。これがPHPプロセスの強制終了を招くメモリ急増を引き起こします。
Imagickをシングルスレッドに制限することで、多くの場合、これらのクラッシュは即座に解消されます。テーマの functions.php ファイルに以下のスニペットを追加してください。
add_filter('wp_image_editors', function($editors) {
$first_editor = array_shift($editors);
if ($first_editor === 'WP_Image_Editor_Imagick') {
if (class_exists('Imagick')) {
// Imagickのスレッド数を1に制限
Imagick::setResourceLimit(Imagick::RESOURCETYPE_THREAD, 1);
}
}
array_unshift($editors, $first_editor);
return $editors;
});
Ubuntuでシステム全体の設定を変更するには、policy.xml（/etc/ImageMagick-6/ または /etc/ImageMagick-7/ にあります）を編集し、以下の行を追加します。
<policy domain="resource" name="thread" value="1"/>
修正2：より軽量なGDライブラリへの切り替え
Imagickを使っても問題が解決しない場合（1GBのRAMを搭載した月額5ドルのエントリーレベルのVPSなどで一般的）、GDライブラリに切り替える時期かもしれません。GDは機能面ではImagickに劣りますが、メモリ効率が大幅に優れています。以下のフィルターを使用して、GDを優先的な画像処理ハンドラーにします。
add_filter('wp_image_editors', function($editors) {
return array('WP_Image_Editor_GD', 'WP_Image_Editor_Imagick');
});
修正3：サーバーの「ゲートキーパー」制限値を調整する
アップロードに時間がかかりすぎたり、ファイルサイズが大きすぎたりすると、サーバーが接続を遮断することがあります。10MB以上の高解像度写真をアップロードする場合、php.ini に十分な余裕を持たせる必要があります。本番環境では、以下の基準値を推奨します。
upload_max_filesize = 128M
post_max_size = 128M
memory_limit = 512M
max_execution_time = 300
Nginxユーザーは、サーバーブロック内の client_max_body_size がPHPの制限値と一致していることを確認してください。PHPが128MBを許可していても、Nginxがデフォルトの1MBに設定されていると、アップロードは毎回失敗します。設定を更新してリロードしてください。
server {
client_max_body_size 128M;
}
# その後実行:
sudo nginx -t && sudo systemctl reload nginx
修正4：Apache向けの.htaccessによる対応
Apacheサーバーでは、特定の最適化モジュールがバックグラウンドでのImagickの画像処理と競合することがあります。.htaccess ファイルの先頭に以下の1行を追加することで、これらの競合を回避できることがよくあります。
SetEnv MAGICK_THREAD_LIMIT 1
検証：解決策のテスト
負荷テストを行うまでは、解決したと決めつけないでください。シークレットウィンドウを開き、以前失敗したのと全く同じファイルをアップロードしてみてください。正常に完了したら、メディアライブラリに移動して画像をクリックします。サムネイルが正しく読み込まれれば、後処理エンジンは正常です。それでも失敗する場合は、wp-content/debug.log を確認してください。プラグインの競合や、ディレクトリの権限の問題（uploads ディレクトリは755が標準です）がある可能性があります。