413 Request Entity Too Large no WordPress: ajuste nginx e PHP-FPM juntos

O zip do tema tem 28 MB, você clica em enviar e a tela devolve uma página de erro crua do nginx: 413 Request Entity Too Large. Mexer no php.ini agora não muda nada, porque a requisição nem chegou no PHP. O nginx recusa corpo acima de 1 MB por padrão e encerra a conversa ali.

Primeiro o server block

# /etc/nginx/sites-available/seusite.conf
server {
    server_name seusite.com.br;
    root /var/www/seusite/html;

    client_max_body_size 64M;
    client_body_timeout 300s;
}

sudo nginx -t

Confirme no /var/log/nginx/error.log: quando o limite estoura, a linha diz que o cliente pretendia enviar um corpo grande demais, com o tamanho e o limite lado a lado. Um detalhe que custa tempo: se você põe a diretiva só dentro do location do PHP, o upload pela biblioteca de mídia até passa, mas a REST API e o editor de blocos continuam caindo. No server block ela vale pro host inteiro.

Depois o PHP-FPM

# /etc/php/8.3/fpm/php.ini
upload_max_filesize = 60M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 300

sudo systemctl reload php8.3-fpm
sudo systemctl reload nginx

Os três valores formam uma escada: o client_max_body_size igual ou maior que o post_max_size, e o post_max_size maior que o upload_max_filesize. Quem mede o corpo inteiro, arquivo mais os campos do formulário, é o post_max_size; deixá-lo abaixo do upload_max_filesize faz o PHP descartar a requisição e o WordPress receber um POST vazio, sem arquivo e sem mensagem de erro decente na tela. E se o nginx ficar abaixo dele, você continua no 413.

Repare na ordem do reload: PHP-FPM antes do nginx, pra não abrir a porteira em cima de um pool que ainda recusa o arquivo. E não confira o resultado com php -i no terminal, porque o CLI lê o /etc/php/8.3/cli/php.ini, outro arquivo. O valor que vale aparece em Ferramentas, Saúde do site, aba Informações, seção Servidor.