Resolvendo o limite de upload no CloudLinux + DirectAdmin: por que o php.ini não atualiza e como forçar via CLI

Você precisa subir um banco de dados pesado, restaurar um backup volumoso do WordPress ou permitir o envio de arquivos de mais de 1GB em uma aplicação. Você abre as configurações, altera o php.ini, salva, reinicia o serviço e, ao testar, a aplicação continua acusando que o limite máximo não foi atingido ou o phpinfo() segue exibindo os valores antigos.

Em servidores com a dobradinha DirectAdmin e CloudLinux (usando o PHP Selector e CageFS), essa frustração é clássica. A arquitetura em camadas do CloudLinux não lê diretamente o /etc/php.ini tradicional para contas de usuário. Além disso, pequenas pegadinhas de sintaxe na notação de bytes do PHP e buffers intermediários do Nginx costumam sabotar a alteração silenciosamente.

Abaixo está o roteiro prático para entender onde essa configuração fica guardada, como contornar os erros de sintaxe e como forçar a atualização completa pelo terminal.

1. Onde o CloudLinux armazena as opções do PHP?#

Em um ambiente padrão sem isolamento, as opções do PHP costumam ficar centralizadas em arquivos globais do sistema. Quando o CloudLinux PHP Selector está ativo, no entanto, cada usuário ganha a liberdade de escolher a versão do interpretador e ajustar suas próprias diretivas dentro de uma jaula virtualizada (o CageFS).

Ao inspecionar a pasta home de um usuário (chamado aqui de formula), você encontra uma organização peculiar:

[root@servidor formula]# ls -la
total 92
drwx--x---    12 formula access   4096 Sep 16  2025 .
drwx--x--x. 1433 root    root    40960 May  8 16:55 ..
drwxr-xr-x     2 formula formula   59 May 11 10:42 .cl.selector
drwxrwx---     2 formula apache   138 May 11 00:26 .php
lrwxrwxrwx     1 formula formula   48 May 29  2025 public_html -> ./domains/meusite.com.br/public_html

Olhando esses diretórios ocultos:

• .php/: Armazena principalmente registros de e-mails enviados por script (php-mail.log) e dados temporários de sessão. Não é aqui que o runtime busca configurações.
• .cl.selector/: É aqui que mora o segredo. Esta pasta guarda os arquivos de personalização gerados quando o usuário ajusta opções pelo painel web.

Dentro de .cl.selector/, você verá arquivos correspondentes à versão do PHP em uso:

[root@servidor formula]# ls .cl.selector/
alt_php74.cfg  defaults.cfg

O arquivo alt_php74.cfg (onde 74 representa o PHP 7.4) guarda as opções customizadas da conta:

;>=== Start of PHP Selector Custom Options ===
upload_max_filesize=1G
;<=== End of PHP Selector Custom Options =====

2. A pegadinha dos decimais na notação do PHP#

Imagine que a sua aplicação precise aceitar arquivos de até 1.6 GB. A primeira ideia que vem à mente é escrever:

upload_max_filesize = 1.6G

Essa linha parece totalmente lógica, mas o interpretador do PHP não entende frações decimais seguidas de multiplicadores abreviados (K, M, G). Quando o parser do PHP encontra o caractere de ponto (.) em 1.6G, ele trunca o valor de forma imprevisível ou simplesmente assume 1G (ou até 1 byte em versões mais antigas).

Convertendo para megabytes#

Para definir exatamente 1.6 GB sem quebrar o parser, converta tudo para Megabytes inteiros:

$$1.6 \times 1024 = 1638.4 \text{ MB} \approx 1638\text{M}$$

A hierarquia de diretivas de memória#

No PHP, aumentar apenas o upload_max_filesize não resolve. Uma requisição de envio de arquivo carrega dados via método POST e consome memória do script. Se as diretivas ao redor forem mais baixas, o upload será cortado antes mesmo de terminar.

A regra mandatória que precisa ser mantida é:

$$\text{memory\_limit} \ge \text{post\_max\_size} \ge \text{upload\_max\_filesize}$$

Para um teto de 1.6 GB, a combinação equilibrada fica assim:

upload_max_filesize = 1638M
post_max_size = 1640M
memory_limit = 1700M

3. Por que editar o .cfg manualmente não reflete no site?#

Se você abrir o arquivo /home/formula/.cl.selector/alt_php74.cfg com o seu editor de texto, colar os valores acima e salvar, quase certamente ao recarregar a página o phpinfo() continuará mostrando o limite antigo.

O motivo é simples: o CloudLinux Selector não lê diretamente o .cfg a cada requisição web. Esse arquivo funciona apenas como um espelho de metadados. Os arquivos de configuração de fato consumidos pelos processos do PHP-FPM e Apache residem compilados dentro do CageFS do usuário.

Se o utilitário do seletor não for acionado para recompilar essa estrutura, a alteração fica órfã no disco.

O comando correto via CLI: selectorctl#

Tentar comandos genéricos ou flags inexistentes (como --replace-config-file) costuma resultar em erros de uso no terminal:

[root@servidor .cl.selector]# selectorctl --user formula --replace-config-file --version=7.4
Usage: /usr/bin/selectorctl [OPTIONS]

O comando nativo suportado pelo CloudLinux é o --replace-options (ou -m), que espera uma lista de opções separadas por vírgula no formato chave:valor:

selectorctl --user formula --version 7.4 --replace-options "upload_max_filesize:1638M,post_max_size:1640M,memory_limit:1700M"

Reiniciando os processos do PHP-FPM do usuário#

Mesmo após a regravação, pools persistentes do PHP-FPM podem reter configurações na memória RAM. Finalize os processos do usuário para forçar o reinício limpo dos workers:

killall -u formula php-fpm

Sincronizando a gaiola do CageFS#

Por fim, garanta que os links simbólicos e mapeamentos da jaula do usuário estejam sincronizados com as novas definições:

cagefsctl --update formula

4. Validando o valor real sem depender de cache de navegador#

Testar pelo navegador pode induzir a erros por conta de cache de página, proxies intermediários ou arquivos estáticos. A forma mais precisa de conferir o resultado é rodar o PHP exatamente sob o contexto e as permissões do usuário afetado via terminal:

su - formula -s /bin/bash -c "php -i | grep upload_max_filesize"

O terminal deve retornar imediatamente o valor atualizado em ambas as colunas (Local Value e Master Value):

upload_max_filesize => 1638M => 1638M

5. O gargalo invisível no proxy reverso (Nginx)#

Se o PHP já acusa 1638M no phpinfo(), mas ao enviar o arquivo de 1.6 GB o navegador devolve quase instantaneamente um erro 413 Request Entity Too Large, o problema não está mais no PHP.

Em configurações onde o Nginx roda na frente do Apache como proxy reverso acelerador, é o Nginx quem recebe a requisição primeiro. O limite padrão de corpo de requisição do Nginx (client_max_body_size) costuma ser de modestos 1MB ou 10MB. Se o arquivo for maior do que isso, o Nginx barra o tráfego antes mesmo de encaminhar os pacotes para o Apache ou PHP.

Como ajustar o buffer do Nginx no DirectAdmin#

1. Acesse o painel do DirectAdmin com perfil administrativo (Admin).
2. Navegue até Configurações personalizadas do HTTPD (Custom HTTPD Configurations).
3. Selecione o domínio da aplicação que receberá os arquivos grandes.
4. Na seção de customização do bloco do nginx.conf, adicione a diretiva ampliando o tamanho máximo permitido:

client_max_body_size 1700M;

1. Salve as alterações e reinicie o serviço do Nginx pelo terminal para recarregar as tabelas de roteamento:

systemctl restart nginx

O checklist operacional para uploads gigantescos sem travamento#

Quando precisar ajustar limites de upload em ambientes gerenciados com CloudLinux e DirectAdmin, siga esta sequência direta para não perder tempo com alterações que não surtem efeito:

1. Evite decimais: Calcule o tamanho pretendido em Megabytes inteiros ($1.6\text{ GB} = 1638\text{M}$).
2. Respeite a pirâmide de memória: Garanta sempre que memory_limit (ex: 1700M) $\ge$ post_max_size (ex: 1640M) $\ge$ upload_max_filesize (ex: 1638M).
3. Use o selectorctl em vez de editar arquivos na mão: Aplique as regras com selectorctl --user USER --version X.Y --replace-options "...".
4. Limpe processos órfãos e sincronize o CageFS: Rode killall -u USER php-fpm seguido de cagefsctl --update USER.
5. Verifique o proxy de borda: Se receber HTTP 413, ajuste o client_max_body_size no Nginx para cobrir o volume esperado.

Com essa cadeia alinhada da camada de rede ao interpretador de scripts, os envios de arquivos grandes fluem de forma estável e previsível.

Veja também

E-mail Como resolver assinaturas de imagem quebradas no Roundcube com cPanel e CloudLinux

Servidores Troubleshooting avançado de erro 500 no cPanel: do rastreio de logs à compatibilidade do runtime

Infraestrutura Desincronização de handshake do MySQL em ambientes multi-tenant: cPanel, CloudLinux e CageFS

Este post está licenciado sob CC BY-NC.