Nginx baixando arquivos PHP no aaPanel? Como

Se o navegador começa a baixar arquivos index.php em vez de renderizar o seu site, o problema quase sempre envolve falha na integração entre o servidor Nginx e o gerenciador de processos PHP-FPM. Esse comportamento ocorre porque o Nginx, ao não conseguir encaminhar o script para o interpretador FastCGI, trata a resposta como um arquivo estático genérico e envia cabeçalhos MIME padrão (como application/octet-stream), instruindo o navegador a fazer o download do código-fonte bruto.

Neste guia detalhado, você encontrará um roteiro técnico completo para diagnosticar e reestabelecer o funcionamento correto do servidor web no aaPanel, cobrindo backups preventivos, conflitos de bind ("Address already in use"), sockets órfãos, controle de permissões, SSL, SELinux, logs de auditoria e testes pós-fix.

Sintoma Clínico	Causa Raiz Provável	Impacto Imediato	Ação Recomendada
Navegador baixa código PHP	PHP-FPM inativo ou bloco `location ~ \.php` ausente	Exposição de credenciais e falha do site	Validar socket Unix e checar `nginx -t`
Erro `Address already in use`	Processos órfãos do Nginx segurando as portas 80/443	Nginx falha ao iniciar (Downtime)	Identificar PID com `ss` e matar suavemente
PHP-FPM status `active (exited)`	Perda de rastreamento do PID real pelo systemd	Falha crítica de upstream FastCGI	Recriar socket Unix e reiniciar pool PHP-FPM
Modal ou AJAX falha (Content)	Chamadas HTTP misturadas em página carregada via HTTPS	Requisições bloqueadas pelo navegador (Console)	Aplicar redirecionamento 301 e cabeçalho CSP

1. Backups preventivos antes de alterar configurações#

Antes de executar qualquer comando corretivo, matar processos ou editar arquivos de configuração em seu servidor de produção aaPanel, é mandatório realizar cópias de segurança dos diretórios críticos do Nginx e do PHP-FPM.

Execute os comandos abaixo para gerar backups estruturados com marcação de data:

# Criar cópia de segurança do diretório de configurações do Nginx
cp -r /www/server/nginx/conf/ /root/nginx-conf-backup-$(date +%Y%m%d)/

# Criar cópia de segurança do diretório de configurações do PHP-FPM 8.0
cp -r /www/server/php/80/etc/ /root/php80-etc-backup-$(date +%Y%m%d)/

Alternativamente, você pode consolidar e compactar ambas as pastas em um único arquivo de segurança comprimido:

# Gerar arquivo tarball das configurações do Nginx e PHP-FPM antes das alterações
tar czf /root/webserver-config-backup-$(date +%Y%m%d).tar.gz /www/server/nginx/conf/ /www/server/php/80/etc/

2. O erro de BIND "address already in use" e finalização segura de processos#

Quando você tenta reiniciar o Nginx e depara-se com o seguinte erro nos logs:

[emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

Isso indica que o sistema operacional não pôde associar o Nginx à porta 80 ou 443 porque outro processo (ou workers órfãos zumbis de uma instância antiga do próprio Nginx) está retendo o socket de rede da porta.

O perigo do `killall -9` sem auditoria#

Forçar a parada imediata com o sinal SIGKILL (-9) de forma cega é uma prática perigosa. Ela impede que o Nginx realize o fechamento seguro de conexões ativas de clientes, finalize transferências de arquivos em andamento, limpe arquivos de lock temporários e grave logs de auditoria pendentes na memória.

Siga o protocolo seguro de desligamento e limpeza de portas:

Audite os processos ativos de forma limpa:

   # Listar todos os processos associados ao Nginx
   ps aux | grep nginx | grep -v grep

Envie um sinal de desligamento suave (SIGTERM):

   # Solicitar o encerramento ordenado dos processos
   killall nginx
   # Aguardar a desalocação de buffers de rede e escrita de logs
   sleep 3

Verifique se as portas 80/443 continuam ocupadas:

   # Consultar portas ativas e identificar o PID associado
   ss -lntp | grep -E ':80|:443'

Aplique o SIGKILL apenas como último recurso em processos teimosos:

   # Encerrar de forma forçada se restarem instâncias órfãs travadas
   killall -9 nginx 2>/dev/null || true

3. Sockets unix órfãos e status "active (exited)" do PHP-FPM no aaPanel#

O aaPanel gerencia o ciclo de vida do PHP-FPM através de init scripts tradicionais localizados em /etc/init.d/php-fpm-XX (onde XX é a versão do PHP, ex.: 80). Em momentos de alta carga ou falha de disco, o utilitário systemd ou o script de inicialização pode perder o rastreio do PID master do PHP, exibindo o status confuso active (exited) no gerenciador de serviços.

Quando isso acontece, o arquivo do socket Unix (geralmente /tmp/php-cgi-80.sock) torna-se órfão (inconsistente) ou é deletado, impedindo que o Nginx repasse as chamadas de scripts PHP via protocolo FastCGI.

Diagnóstico de sockets e serviços#

Execute a triagem física do serviço e do canal de comunicação socket:

# Inspecionar o status de execução ativa do PHP-FPM
systemctl status php-fpm-80

# Verificar se o arquivo do socket existe fisicamente no diretório temporário
ls -la /tmp/php-cgi-80.sock

# Consultar informações avançadas sobre propriedade e permissões de escrita do socket
stat /tmp/php-cgi-80.sock

Validando a escuta do processo#

Para certificar-se de que o daemon do PHP-FPM está rodando e escutando requisições no socket Unix ou na porta TCP correta, utilize o utilitário ss:

# Listar portas e sockets Unix abertos pelo PHP-FPM no sistema
ss -lnxp | grep php-cgi

# Se o pool estiver configurado via porta TCP (ex.: 9000)
ss -lntp | grep php-fpm

4. Validação da configuração e sintaxe do Nginx#

Nunca reinicie o Nginx diretamente após editar os blocos de hosts virtuais. Erros de digitação, diretivas obsoletas ou delimitadores faltantes podem indisponibilizar todo o servidor web.

Testando a sintaxe localmente#

Execute o comando de teste integrado para validar a gramática dos arquivos de configuração:

# Validar a integridade estrutural e de sintaxe do Nginx
nginx -t

Dump e busca por alertas#

Para inspecionar todas as diretivas ativas aplicadas nos arquivos incluídos (include) em busca de conflitos ou avisos, execute:

# Exportar as configurações compiladas e filtrar alertas e erros
nginx -T 2>&1 | grep -iE "error|warn"

Bloco de configuração PHP recomendado (aaPanel)#

Certifique-se de que o bloco location ~ \.php no arquivo de virtualhost da aplicação (/www/server/panel/vhost/nginx/meusite.com.conf) está direcionado corretamente para o socket Unix correspondente à versão ativa do PHP:

# Diretiva de processamento FastCGI para arquivos PHP
location ~ \.php$ {
    fastcgi_pass unix:/tmp/php-cgi-80.sock; # Socket físico ativo
    fastcgi_index index.php;
    include fastcgi.conf;
    
    # Parâmetros de mapeamento e buffers
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    
    # Configurações de timeout para evitar HTTP 504 Gateway Timeout
    fastcgi_connect_timeout 60s;
    fastcgi_send_timeout 60s;
    fastcgi_read_timeout 60s;
}

5. Auditoria detalhada de permissões de arquivos web#

Permissões incorretas no diretório raiz do site (/www/wwwroot/meusite.com/ ou /home/usuario/public_html/) impedem o interpretador do PHP-FPM de ler e executar os arquivos solicitados pelo Nginx, resultando em erros HTTP 403 Forbidden ou falhas de processamento que podem induzir o download do script.

Verificação do proprietário e permissões#

Inspecione as configurações de propriedade recursiva nos arquivos da aplicação:

# Listar permissões e proprietários dos arquivos no diretório web
ls -la /www/wwwroot/meusite.com/

Aplicando correções estruturadas#

O aaPanel utiliza o usuário e grupo de sistema www para executar os serviços web. Aplique as permissões seguras recomendadas no ambiente:

# Definir recursivamente o proprietário e grupo correto para o diretório
chown -R www:www /www/wwwroot/meusite.com/

# Padronizar permissão de leitura, escrita e navegação em pastas para 755
find /www/wwwroot/meusite.com/ -type d -exec chmod 755 {} \;

# Padronizar permissão de leitura e escrita em arquivos para 644
find /www/wwwroot/meusite.com/ -type f -exec chmod 644 {} \;

Remoção de atributo imutável do `.user.ini`#

O aaPanel cria o arquivo .user.ini de segurança para blindar o diretório contra ataques de travessia (Directory Traversal). Esse arquivo frequentemente é marcado como imutável no kernel Linux, bloqueando a aplicação de comandos chown ou chmod recursivos no diretório.

Se você receber o erro Operation not permitted durante a correção de permissões, remova o atributo imutável temporariamente:

# Remover a proteção de arquivo imutável do .user.ini
chattr -i /www/wwwroot/meusite.com/.user.ini

# Re-aplicar os comandos de permissões anteriores e restabelecer o atributo se desejado:
# chattr +i /www/wwwroot/meusite.com/.user.ini

6. Configuração de certificados SSL e redirecionamentos HTTPS#

Conflitos de certificados expirados, diretivas SSL mal formadas ou portas HTTPS não associadas ao bloco do servidor web impedem a validação de handshakes de segurança.

Auditoria de configurações SSL#

Consulte em quais arquivos de virtualhost a porta 443 e diretivas SSL estão ativas:

# Buscar a presença de diretivas SSL ativas nos virtualhosts do aaPanel
grep -i "ssl" /www/server/panel/vhost/nginx/*.conf

Validação do certificado físico via openssl#

Antes de reiniciar o servidor, certifique-se de que os arquivos de certificado (fullchain.pem ou cert.pem) não estão corrompidos ou expirados:

# Verificar a validade temporal do certificado SSL configurado
openssl x509 -in /www/server/panel/vhost/cert/meusite.com/fullchain.pem -noout -dates

Testando a comunicação HTTPS localmente#

Valide a resposta do protocolo de segurança ignorando resoluções externas de DNS (disparando o comando diretamente contra o IP de loopback):

# Inspecionar cabeçalhos de resposta HTTPS forçando bypass de segurança local
curl -kI https://localhost/

7. Bloqueios silenciosos pelo SELinux#

Em sistemas baseados em Red Hat (como Rocky Linux, AlmaLinux e CentOS), o SELinux opera como um mecanismo de segurança de Controle de Acesso Mandatório (MAC). Mesmo que as permissões de arquivos (chmod) e proprietários (chown) estejam corretas no Linux tradicional, o SELinux pode bloquear a comunicação do Nginx com arquivos do sistema e sockets do diretório /tmp.

Verificando o estado do SELinux#

Consulte o status ativo de policiamento do kernel:

# Verificar se o SELinux está Enforcing, Permissive ou Disabled
getenforce

Rastreando violações de políticas (denials)#

Se o SELinux estiver em modo Enforcing, audite o log do sistema em busca de violações de acesso associadas aos serviços web:

# Buscar registros recentes de negação AVC associados ao Nginx ou PHP
sudo ausearch -m avc -ts recent | grep -iE "nginx|php"

Validando contextos de segurança#

Inspecione os rótulos de contexto associados ao socket e ao diretório web da aplicação:

# Verificar o rótulo de segurança do socket Unix do PHP
ls -laZ /tmp/php-cgi-80.sock

# Verificar rótulos de contexto dos arquivos do site
ls -laZ /www/wwwroot/meusite.com/

8. Verificação de espaço em disco e exaustão de inodes#

Se o disco do servidor atingir 100% de ocupação ou exaurir a tabela de inodes (número máximo de arquivos alocáveis no filesystem), o PHP-FPM não conseguirá escrever sessões de usuários ou armazenar dados temporários. O Nginx também falhará ao gerar buffers locais de requisições, quebrando a comunicação e forçando downloads ou erros 502/504.

Diagnóstico de recursos de armazenamento#

Execute o inventário de uso de espaço e inodes nas partições do sistema:

# Verificar espaço livre em disco nas partições críticas
df -h /var/log /tmp /www

# Verificar inodes livres na partição de dados do aaPanel
df -i /www

Localizando logs inflados no aaPanel#

Arquivos de logs de acesso e erros mal configurados ou sem rotatividade ativa podem consumir centenas de gigabytes rapidamente. Localize arquivos gigantescos na pasta de logs do aaPanel:

# Identificar arquivos maiores que 100MB na árvore de logs do webserver
find /www/wwwlogs -type f -size +100M -exec ls -lh {} \;

9. Leitura de logs do Nginx e do PHP-FPM#

A triagem final de um incidente sistêmico exige o monitoramento ativo dos arquivos de log de erros de ambos os componentes de software.

Localização dos logs no aaPanel#

Logs do Nginx (Virtualhost): /www/wwwlogs/meusite.com.error.log (ou log global em /var/log/nginx/error.log).
Logs do PHP-FPM 8.0: /www/server/php/80/var/log/php-fpm.log (ou log global em /var/log/php-fpm.log).

Monitoramento de logs em tempo real#

Inicie a leitura contínua dos registros de eventos em busca de alertas de queda de serviço:

# Monitorar logs de erros do Nginx
tail -n 100 /www/wwwlogs/meusite.com.error.log

# Monitorar logs de execução e workers do PHP-FPM
tail -n 100 /www/server/php/80/var/log/php-fpm.log

Rastreando erros de BIND e conexão recusada#

Utilize o grep para mapear erros recorrentes nos arquivos consolidados:

# Buscar falhas de porta ou endereço já em uso no Nginx
grep -i "bind" /www/wwwlogs/*.log /var/log/nginx/*.log | tail -20

# Buscar falhas de Upstream e conexões de sockets recusadas
grep -iE "upstream|connect|permission" /www/wwwlogs/*.log | tail -20

10. Validação pós-fix e testes de funcionamento#

Após aplicar as correções e restabelecer os daemons do sistema, certifique-se de que os serviços retornaram à estabilidade operacional e que o código PHP está sendo interpretado e não exposto de forma insegura.

Passos de validação operacional#

Confirmar status de execução ativa dos daemons:

   # Status ativo do Nginx
   systemctl status nginx
   # Status ativo do PHP-FPM 8.0
   systemctl status php-fpm-80

Inspecionar a resposta de cabeçalhos HTTP do servidor local:

   # Requisitar headers do host local validando se retorna HTTP 200 OK
   curl -I http://localhost/

Garantir a interpretação adequada do código PHP:

Insira um arquivo de teste básico (ex: index.php contendo <?php echo "Webserver OK"; ?>) e execute a chamada via curl. A resposta deve conter o texto impresso, e nunca a sintaxe de código aberta de programação:

   # Validar que a saída é HTML/texto estruturado e não contém tags PHP brutas
   curl -s http://localhost/index.php | head -5

Checklist: Nginx baixando PHP (não executando)#

1. Diagnóstico inicial#

[ ] Verificar se o Nginx está rodando: systemctl status nginx
[ ] Verificar se o PHP-FPM está rodando: systemctl status php-fpm-80
[ ] Verificar a existência do socket físico: ls -la /tmp/php-cgi-80.sock
[ ] Monitorar logs de erro do Nginx em tempo real: tail -50 /www/wwwlogs/meusite.com.error.log
[ ] Monitorar logs de erro do PHP-FPM: tail -50 /www/server/php/80/var/log/php-fpm.log

2. Tratamento de address already in use#

[ ] Mapear processos ativos do Nginx na memória: ps aux | grep nginx
[ ] Enviar sinal de encerramento suave: killall nginx (aguardar 3 segundos)
[ ] Certificar se as portas 80/443 foram desalocadas: ss -lntp | grep -E ":80|:443"
[ ] Forçar encerramento de órfãos apenas em caso de falha: killall -9 nginx
[ ] Iniciar o serviço de forma limpa: systemctl start nginx

3. Recuperação e sockets do PHP-FPM#

[ ] Verificar integridade e presença do socket Unix: ls -la /tmp/php-cgi-80.sock
[ ] Confirmar ownership do socket para o usuário correto: stat /tmp/php-cgi-80.sock (esperado: www:www)
[ ] Reiniciar pool de processos do PHP-FPM: systemctl restart php-fpm-80
[ ] Auditar sockets de escuta ativos no sistema: ss -lnxp | grep php-cgi

4. Validação de sintaxe e arquivos de configuração#

[ ] Executar teste de sintaxe das configurações do Nginx: nginx -t
[ ] Fazer dump completo das regras de upstream e includes: nginx -T 2>&1 | grep -iE "error|warn"
[ ] Validar a presença do bloco FastCGI PHP correto nas diretivas do virtualhost.

5. Configurações de SSL e segurança#

[ ] Auditar diretivas de SSL no bloco de host virtual do site.
[ ] Verificar a validade temporal do certificado: openssl x509 -in fullchain.pem -noout -dates
[ ] Adicionar CSP para upgrade automático de requisições de mídia: add_header Content-Security-Policy "upgrade-insecure-requests";
[ ] Substituir URLs fixadas HTTP por relativas no código JavaScript.

6. Controles de permissões, SELinux e recursos#

[ ] Remover atributo imutável de arquivos de segurança se necessário: chattr -i .user.ini
[ ] Corrigir ownership recursivo da pasta raiz: chown -R www:www /www/wwwroot/meusite.com/
[ ] Ajustar permissões recursivas de pastas (755) e arquivos (644).
[ ] Verificar status ativo do SELinux: getenforce
[ ] Buscar bloqueios recentes AVC do SELinux no audit: ausearch -m avc -ts recent
[ ] Validar inodes (df -i) e espaço em disco disponível (df -h) no sistema.
[ ] Monitorar arquivos de log inflados consumindo storage: find /www/wwwlogs -type f -size +100M

7. Homologação pós-fix#

[ ] Efetuar requisições HTTP locais e certificar que retorna HTTP 200 OK: curl -I http://localhost/
[ ] Testar requisições contra arquivos PHP e validar a renderização do código em HTML estruturado.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Este post está licenciado sob CC BY-NC.