WordPress: ошибка HTTP при загрузке изображений

#Где искать причину

«Ошибка HTTP» без подробностей — общее сообщение: обработка изображения на сервере завершилась сбоем. Чаще всего причина в ограничении памяти PHP при создании миниатюр, лимитах upload_max_filesize и post_max_size, прерывании по max_execution_time, неверных правах на wp-content/uploads, конфликте плагинов оптимизации, либо проблеме модуля Imagick. Эту статью следует читать с точки зрения лимитов и прав доступа; статья про Imagick/GD рассматривает обработку изображений отдельно.

#Причины

#Порядок

1. Загрузите небольшой файлВ «Медиафайлы → Добавить новый» WordPress попробуйте загрузить небольшой .jpg допустимого размера с обычным латинским именем. Затем попробуйте исходное изображение; запишите его формат, размер и точный ответ сайта. Если небольшой файл загружается, проблема вероятнее в лимите, обработке формата или ресурсах, а не в полной недоступности каталога.
2. Проверьте ограничения загрузки PHP через «Здоровье сайта»В «Инструменты → Здоровье сайта → Информация → Сервер» посмотрите действующие лимиты PHP и библиотеку обработки изображений (GD/Imagick), если эти сведения доступны. Не путайте параметры PHP CLI с веб-сайтом. Если параметр file_uploads выключен, проблему должен решать администратор хостинга.
3. Уточните действующие лимиты PHP и измените их при необходимостиПри подтверждённом превышении лимита администратор хостинга в конфигурации нужного пула PHP может поднять upload_max_filesize и post_max_size (второй — больше размера файла) с учётом доступной памяти и ограничений сервера. Не ставьте одинаковое значение 64M для обоих, поскольку POST содержит дополнительные данные; перезагрузите нужный PHP-FPM и проверьте параметры снова.
4. Проверьте права на каталог wp-content/uploadsВ файловом менеджере хостинга найдите wp-content/uploads, проверьте существование подпапки года/месяца и возможность записи пользователем PHP. При SSH используйте namei -l и ls -ld; не выполняйте рекурсивный chmod 755/644 на всём каталоге без проверки владельца и ACL, иначе нарушите доступ к загруженным файлам.
5. Отключите плагины и вернитесь к стандартной темеЕсли сбой начался после установки плагина сжатия/оптимизации изображений, отключите его одного на тестовом сайте и повторите загрузку; проверьте также проблему с Imagick/GD и доступность временной директории. Не меняйте рабочую тему на стандартную сразу, если это повлияет на посетителей.
6. Проверьте свободное место на хостингеВ панели хостинга откройте использование диска и квоты файлов, а по SSH проверьте df -h и df -i для раздела с uploads. Если достигнут предел, освободите место после проверки резервных копий и повторите операцию; не удаляйте библиотеку медиафайлов для освобождения места.
7. Проверьте журнал ошибокСразу после отказа откройте журнал PHP-FPM и журнал веб-сервера для нужного сайта. Ищите Allowed memory size exhausted, Permission denied, 413, ошибки Imagick или временных файлов. Исправьте подтверждённую причину, повторите загрузку и проверьте, что WordPress создал миниатюры.
8. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Увеличить лимит памяти WordPress (добавьте перед строкой 'That's all, stop editing!')

   PHPКомандаКопировать всёВыделить

   Увеличить лимит памяти WordPress (добавьте перед строкой 'That's all, stop editing!')

   define('WP_MEMORY_LIMIT', '256M');

   define('WP_MAX_MEMORY_LIMIT', '512M');

   Вариант 2Лимиты загрузки (для PHP-FPM/CGI хостинга; на Apache используйте php_value в .htaccess)

   INIКомандаКопировать всёВыделить

   Лимиты загрузки (для PHP-FPM/CGI хостинга; на Apache используйте php_value в .htaccess)

   upload_max_filesize = 64M

   post_max_size = 64M

   memory_limit = 256M

   max_execution_time = 300

   Вариант 3Права на каталог загрузок и свободное место

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Права на каталог загрузок и свободное место

   ls -ld wp-content/uploads

   find wp-content/uploads -type d ! -perm 755 | head

   df -h .

   Вариант 4Выставить стандартные права на каталоги и файлы WordPress (из корня сайта)

   Linux · Терминал (Bash)С осторожностьюКопировать всёВыделить

   Выставить стандартные права на каталоги и файлы WordPress (из корня сайта)

   namei -l wp-content/uploads

   ls -ld wp-content/uploads

   # Права и владельца исправляйте точечно после диагностики, не рекурсивно.

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

   Вариант 5Журнал ошибок

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Журнал ошибок

   tail -n 50 wp-content/debug.log

   tail -n 50 ~/logs/error.log

#Дополнительно

Если проблема только с большими фотографиями с камеры, уменьшите их перед загрузкой до 2500 пикселей по длинной стороне. Для массовой загрузки используйте FTP или WP-CLI: wp media import /путь/*.jpg. Ограничение может быть и на уровне веб-сервера: в nginx добавьте client_max_body_size 64M; и перезагрузите конфигурацию.

#Проверка по этапам загрузки

Запрос на загрузку проходит четыре стадии: браузер отправляет файл, веб-сервер принимает его, PHP сохраняет во временную папку, WordPress переносит файл в uploads и создаёт миниатюры. Ошибка может возникнуть на любой из них. Узнайте, на какой, по косвенным признакам: если ошибка появляется сразу, до полоски прогресса, сработал лимит размера на сервере; если в конце, виноваты миниатюры и память; если ошибка только на некоторых файлах, дело в их формате или метаданных.

Проверьте и временную папку PHP: в phpinfo() найдите upload_tmp_dir — каталог должен существовать и быть доступен на запись, а на нём должно быть свободное место. Нередко на хостинге временная папка переполнена, и любая загрузка заканчивается сбоем.