Nginx baixando arquivos PHP no aaPanel? Como resolver "Address already in use" e sockets órfãos

Se o navegador começa a baixar index.php em vez de renderizar o site, o problema quase sempre envolve falha na integração entre Nginx e PHP-FPM.

Neste guia, você encontra o diagnóstico e a sequência de correção para casos com Address already in use, processos órfãos e erro de conteúdo misto.

1. Sintoma: download do PHP em vez de execução

Isso acontece quando o Nginx não consegue enviar o script para o PHP-FPM. Principais causas:

PHP-FPM parado;
socket inexistente ou com permissão incorreta;
bloco location ~ \.php não carregado corretamente.

2. Erro crítico: `Address already in use`

Mesmo após restart, pode aparecer:

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

Normalmente há workers órfãos segurando as portas 80/443.

Limpeza forçada

killall -9 nginx
netstat -tulpn | grep -E ':80|:443'
systemctl start nginx

3. PHP-FPM com `active (exited)` no aaPanel

Esse status costuma indicar perda de rastreio do PID real pelo systemd.

Se o socket (ex.: /tmp/php-cgi-80.sock) não existe ou está inacessível, o Nginx não executa PHP e entrega o arquivo para download.

Ajustes recomendados

chown -R www:www /home/usuario/public_html
/etc/init.d/php-fpm-80 reload

Se necessário (arquivo imutável):

chattr -i .user.ini

4. Modal/AJAX falhando: Mixed Content (HTTPS vs HTTP)

Se acesso direto funciona, mas chamadas via modal/AJAX quebram, pode ser Mixed Content.

Requisições http:// dentro de página HTTPS podem ser bloqueadas e causar comportamento inesperado, incluindo download de resposta.

Correções

Forçar HTTPS via redirecionamento 301 no Nginx.
Usar URLs relativas no JS (/script.php) em vez de URL fixa com http://.
Aplicar CSP para upgrade automático de requests.

add_header Content-Security-Policy "upgrade-insecure-requests";

5. Sequência mestre de recuperação

# Limpa workers órfãos do nginx e sobe serviço limpo
killall -9 nginx && systemctl start nginx

# Reinicia php-fpm do pool utilizado
pkill -9 php-fpm && systemctl restart php-fpm-80

# Valida socket e permissões
ls -la /tmp/php-cgi-80.sock

Na maioria dos incidentes desse tipo, a causa é combinação de:

processos órfãos em memória;
socket PHP-FPM inconsistente;
permissões incorretas;
chamadas HTTP em ambiente HTTPS.

Com limpeza de processos, ajuste de owner/permissões e padronização de HTTPS, o Nginx e o PHP-FPM voltam a operar corretamente.

Este post está licenciado sob CC BY-NC.