# Limitar com critério post_max_size e upload_max_filesize

> Limitar post_max_size e upload_max_filesize: interação com os limites do servidor web, valores transitórios do php.net para o PHP2Shell e erros típicos.

Fonte: https://phpsos.de/pt/blog/post-max-size-upload-limits/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** O `post_max_size` limita o tamanho total de um pedido POST, o `upload_max_filesize` o ficheiro individual; segundo o manual do PHP, os valores por defeito são 8M e 2M. Os valores têm de ser compatíveis com os limites do servidor web e da aplicação; caso contrário, os uploads falham sem uma mensagem clara. Até à atualização do PHP2Shell, o php.net aconselha `post_max_size = 8M` sem uploads ou `32M` com uploads, com `upload_max_filesize` abaixo, definido de modo que as aplicações não o sobrescrevam.

## Quando o formulário de candidatura de repente fica em silêncio

Depois das medidas transitórias para o PHP2Shell, muitos administradores baixaram o `post_max_size`. Poucos dias depois, o departamento de recursos humanos comunica que as candidaturas já não chegam. O formulário limita-se a voltar a carregar, sem qualquer mensagem de erro. A razão: o pedido com três anexos em PDF era maior do que o novo limite, e o PHP descartou os dados do formulário.

O exemplo mostra o problema de fundo. Os limites de upload atuam em vários pontos em simultâneo, e cada ponto reage de forma diferente quando é excedido. Quem conhece a cadeia consegue definir os valores de modo que protejam sem perturbar a operação. Como o PHP processa uploads internamente é explicado em [Como o PHP processa uploads de ficheiros](https://phpsos.de/pt/php/datei-uploads-intern/); a programação segura de funções de upload é descrita em [Implementar uploads de ficheiros em PHP com segurança](https://phpsos.de/pt/ratgeber/datei-upload-sicher/).

## A cadeia de limites de upload

Um pedido atravessa vários limites antes de a aplicação o ver. As indicações seguintes provêm das documentações do Nginx, do Apache e do PHP:

| Local | Definição | Valor por defeito segundo a documentação | Se for excedido |
|---|---|---|---|
| Nginx | `client_max_body_size` | 1m | erro 413 para o navegador |
| Apache a partir de 2.4.54 | `LimitRequestBody` | 1 GiB (até 2.4.53: ilimitado) | resposta de erro em vez de processamento |
| PHP | `post_max_size` | 8M | `$_POST` e `$_FILES` vazios |
| PHP | `upload_max_filesize` | 2M | ficheiro rejeitado com código de erro |
| PHP | `max_file_uploads` | 20 | os restantes ficheiros são ignorados |
| PHP | `max_input_vars` | 1000 | faltam os restantes campos de formulário |

Daqui resulta uma regra simples: `upload_max_filesize` menor do que `post_max_size`, e `post_max_size` menor do que o limite no servidor web. O manual do PHP recomenda ainda que o `memory_limit` seja, em geral, maior do que o `post_max_size`. Durante a medida transitória do PHP2Shell com `memory_limit=-1`, esse papel é assumido pelo limite através de contentor ou cgroup; mais informação em [Definir corretamente o memory_limit](https://phpsos.de/pt/blog/memory-limit-richtig-setzen/).

## post_max_size após o PHP2Shell: o que recomenda o php.net

No comunicado de segurança de 21/10/2026, o php.net indica, para servidores sem atualização, limites baixos de pedidos como uma das medidas transitórias. Reduzem o risco de alguns caminhos de ataque, mas expressamente não são uma proteção completa:

1. **Sem uploads de ficheiros:** `post_max_size = 8M`.
2. **Com uploads de ficheiros:** `post_max_size = 32M`.
3. **Em ambos os casos:** manter `upload_max_filesize` abaixo de `post_max_size`.
4. **Considerar adicionalmente:** limites no servidor web ou no proxy para o tamanho descodificado do pedido, o número de campos de entrada, o número de partes multipart, o número de linhas de cabeçalho e a profundidade de aninhamento. Segundo o php.net, estes limites têm de abranger também pedidos sem indicação `Content-Length` utilizável.

Os valores pertencem a um sítio onde as aplicações não os possam sobrescrever. Como o `post_max_size` e o `upload_max_filesize` podem, segundo o manual, ser alterados ao nível do diretório, um `.user.ini` ou, com mod_php, um `.htaccess` poderiam voltar a aumentá-los:

```ini
; Pool FPM do site, com uploads (fase transitória até à atualização)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
```

No servidor web, fixe o limite ligeiramente acima, para que os pedidos demasiado grandes nem sequer cheguem ao PHP:

```nginx
# Nginx, no bloco server ou location
client_max_body_size 32m;
```

```apache
# Apache, no VirtualHost: 32 MiB em bytes
LimitRequestBody 33554432
```

Depois, recarregue todos os workers PHP e o servidor web. A visão geral de todas as medidas transitórias está em [Medidas imediatas, quando ainda não pode aplicar o patch](https://phpsos.de/pt/php2shell/sofortmassnahmen-ohne-patch/). Se e como os pedidos de upload podem ser filtrados adicionalmente no proxy é analisado em [Filtrar pedidos de upload na periferia](https://phpsos.de/pt/blog/upload-anfragen-am-rand-filtern/).

> **Importante:**
> Depois de cada alteração, teste os formulários com os maiores pedidos legítimos: candidaturas com vários anexos, importações de produtos, galerias de imagens. Um valor demasiado curto paralisa processos de negócio sem que ninguém veja uma mensagem de erro.

## Determinar o valor certo para o seu site

Em vez de valores generalizados, vale a pena fazer um breve levantamento. Liste todos os formulários com uploads e anote o maior ficheiro legítimo e o maior número de ficheiros em simultâneo. Daí resulta a necessidade: o `upload_max_filesize` cobre o maior ficheiro individual, o `post_max_size` a soma de todos os ficheiros de um pedido mais alguma reserva para os campos de formulário.

Se a necessidade for superior a 32M, não é compatível com a recomendação transitória do php.net. Isso é mais uma razão para antecipar a atualização. Os uploads grandes podem também ser tratados através de um subdomínio próprio com pool próprio, para que o resto do site mantenha limites estreitos.

Depois da atualização para 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou um backport confirmado, pode voltar a ajustar os valores à necessidade real. Ainda assim, não devem ser mais generosos do que o necessário: cada limite que excede a necessidade aumenta a superfície de ataque sem benefício. Se um site não precisar de uploads, `file_uploads = Off` é a solução mais limpa.

## Interpretar corretamente os padrões de erro

Quando os uploads falham, o comportamento revela que limite está a atuar. Uma página com erro 413 vem do servidor web. Um formulário que volta a carregar sem mensagem ou que comunica «pedido inválido» aponta para dados `$_POST` vazios, ou seja, o `post_max_size`. Uma mensagem da aplicação sobre um único ficheiro corresponde ao `upload_max_filesize`. E campos em falta em formulários muito grandes, por exemplo com variantes de produtos, apontam para o `max_input_vars`. O registo de erros do PHP contém, em regra, quando o `post_max_size` é excedido, um aviso com o tamanho do pedido.

Para que os utilizadores não fiquem sem saber o que fazer, a aplicação deve reconhecer o caso. O manual do PHP propõe para isso um caminho simples: o formulário passa um marcador no endereço, por exemplo `?processed=1`. Se esse marcador chegar, mas `$_POST` e `$_FILES` estiverem vazios, o pedido era demasiado grande e a aplicação pode mostrar uma mensagem compreensível com o tamanho permitido.

## Como ajuda concretamente a PHP SOS?

- Registamos todos os caminhos de upload dos seus sites e determinamos os tamanhos realmente necessários.
- Definimos de forma coerente os limites do servidor web, do PHP e dos pools, bloqueados contra sobrescrita, incluindo os valores transitórios do php.net.
- Testamos formulários, importações e uploads após a alteração e ajustamos os valores de forma dirigida.
- No âmbito do [reforço de segurança de servidores](https://phpsos.de/pt/leistungen/server-haertung/), repomos os valores, após a atualização, na necessidade permanente.


## Perguntas frequentes

**Qual é a diferença entre post_max_size e upload_max_filesize?**  
O upload_max_filesize limita o tamanho de um único ficheiro carregado. O post_max_size limita o total dos dados de um pedido POST, isto é, todos os ficheiros e campos de formulário em conjunto. Segundo o manual do PHP, o post_max_size tem por isso de ser maior do que o upload_max_filesize.

**O que acontece se um pedido for maior do que o post_max_size?**  
Segundo o manual do PHP, $_POST e $_FILES ficam vazios. A aplicação não recebe, portanto, quaisquer dados de formulário e muitas vezes mostra apenas uma mensagem de erro pouco clara ou volta a carregar o formulário. Isto torna este erro difícil de reconhecer.

**Que valores recomenda o php.net por causa do PHP2Shell?**  
Como medida transitória até à atualização: post_max_size = 8M para aplicações sem uploads de ficheiros, 32M para aplicações com uploads, e upload_max_filesize abaixo disso. Segundo o php.net, não é uma proteção completa; só a atualização para uma versão corrigida do PHP fecha as vulnerabilidades.

**Posso alterar o post_max_size com ini_set() no código?**  
Não. Segundo o manual do PHP, o post_max_size só pode ser alterado ao nível do diretório, por exemplo no php.ini, no pool FPM, no .user.ini ou, com mod_php, no .htaccess. Quem quiser impor o valor define-o com php_admin_value; então nem um .user.ini o pode sobrescrever.

## Fontes

- [php.net: comunicado de segurança de 21/10/2026](https://www.php.net/)
- [Manual do PHP: definições do núcleo (post_max_size)](https://www.php.net/manual/en/ini.core.php)
- [Documentação do Nginx: client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html)
- [Documentação do Apache: LimitRequestBody](https://httpd.apache.org/docs/2.4/mod/core.html)