Большие файлы в медиатеке WordPress: PHP, Nginx и Cloudflare

В медиатеку WordPress не лезет большой файл, а в интерфейсе что-то вроде: «От сервера получен неожиданный ответ. Файл, возможно, не был загружен корректно». Типично для видео, тяжёлых архивов и исходников. Чаще всего упираются не в сам WordPress, а в лимиты PHP, веб-сервера и CDN.

Откуда берётся сбой

1. PHP-FPM / php.ini – upload_max_filesize, post_max_size, таймауты.
2. Nginx – client_max_body_size режет тело запроса раньше PHP.
3. Cloudflare – на Free upload через прокси ограничен (порядка 100 МБ); для крупных файлов нужен обход или другой тариф/путь.
4. Сеть и клиент – обрыв соединения, таймаут прокси, нестабильный канал.

Ниже – практический порядок проверки: PHP, Nginx, Cloudflare, логи.

1. Лимиты PHP-FPM

Найдите php.ini для FPM, путь вроде /etc/php/8.x/fpm/php.ini (версия может быть 7.x / 8.x). Проверьте и поднимите:

upload_max_filesize = 256M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300

• upload_max_filesize – потолок одного файла;
• post_max_size – весь POST; обычно не меньше upload_max_filesize;
• max_execution_time / max_input_time – чтобы долгая загрузка не убивалась по таймауту.

Перезапуск FPM (подставьте свою версию):

sudo systemctl restart php8.2-fpm

Убедитесь, что правите тот pool, который реально обслуживает сайт (иногда рядом стоят несколько версий PHP).

2. Nginx: client_max_body_size

В конфиге сайта (/etc/nginx/sites-available/... или include в server/http) добавьте или увеличьте:

client_max_body_size 256M;

Проверка и reload:

sudo nginx -t
sudo systemctl reload nginx

Если лимит стоит только в server, а upload идёт через другой vhost/proxy – смотрите и туда. При reverse proxy лимит может быть на нескольких уровнях.

3. Cloudflare и крупные файлы

При оранжевом облаке (прокси) на бесплатном плане upload через Cloudflare упирается в лимит размера запроса. Для разовой загрузки 200 МБ в медиатеку часто делают так:

• в DNS Cloudflare временно выключить proxy (серое облако) для нужной записи;
• в Overview включить Development Mode, чтобы кэш не мешал проверке;
• загрузить файл напрямую на origin;
• вернуть proxy, если он нужен для защиты/CDN.

Альтернативы: SFTP/rsync в wp-content/uploads + импорт в медиатеку, отдельный upload-поддомен без proxy, или платный план с большим лимитом. Долгосрочно лучше не держать «серое облако» открытым без нужды.

4. Повторная загрузка

После правок PHP и Nginx (и при необходимости обхода Cloudflare) снова загрузите файл из админки. Имеет смысл свежий браузер и актуальный WordPress/PHP: старые стеки иногда добавляют свои сюрпризы.

5. Если ошибка осталась

• логи Nginx: /var/log/nginx/error.log (413 Request Entity Too Large – почти всегда body size);
• логи PHP-FPM: путь вида /var/log/php8.x-fpm.log;
• реальный размер файла vs выставленные лимиты (и что post_max_size >= upload);
• стабильность канала; при обрывах – chunked upload плагинами или загрузка по SFTP.

Краткий итог

«Неожиданный ответ» при upload в WordPress почти всегда означает: цепочка PHP → веб-сервер → CDN не пропускает тело запроса. Поднимите upload_max_filesize/post_max_size, client_max_body_size, учтите лимит Cloudflare, проверьте логи. После согласованных лимитов на всех уровнях медиатека принимает и 200+ МБ без сюрпризов.

Источники и ссылки