11 min de leitura · Guia técnico
Otimizar Nginx + PHP-FPM no mesmo servidor exige ajustar sockets, limites de processos e buffers para evitar gargalos de comunicação entre o servidor web e o interpretador PHP. Para eliminar conflitos e extrair o máximo de performance, siga estes passos:
- Migrar a comunicação de TCP para socket Unix
- Ajustar pm.max_children conforme a RAM disponível
- Alinhar usuários e permissões entre Nginx e PHP-FPM
- Configurar buffers fastcgi e timeouts adequados
- Habilitar pm.status_path para monitoramento
- Testar com ferramentas de carga e ajustar iterativamente
Pré-requisitos
- VPS com Debian 12 ou Ubuntu 24.04 LTS e acesso root via SSH
- Nginx 1.26 ou superior instalado e ativo
- PHP 8.3 com pacote php8.3-fpm instalado
- Mínimo de 2 GB de RAM recomendado para ambientes de produção
- Ferramentas de diagnóstico: htop, ss, curl e ab (Apache Bench)
- Backup de /etc/nginx e /etc/php/8.3/fpm antes de qualquer alteração
Conflitos comuns entre Nginx e PHP-FPM no mesmo servidor
Quando o servidor web e o interpretador dividem o mesmo host, surgem disputas por recursos de CPU, memória e file descriptors. O Nginx opera como um processo event-driven assíncrono, enquanto o PHP-FPM usa um modelo pré-fork com workers dedicados. Se os dois não forem dimensionados em harmonia, o resultado típico é erro 502 Bad Gateway, lentidão em horários de pico ou consumo excessivo de swap.
Os três conflitos mais frequentes em ambientes de hospedagem Linux são: (1) permissões incompatíveis no socket Unix, quando o Nginx roda como www-data mas o pool PHP-FPM escuta como outro usuário; (2) fila de requisições PHP-FPM menor que a taxa de chegada do Nginx, causando timeouts; (3) worker_connections do Nginx configurado acima do que pm.max_children consegue atender, gerando backlog.
Antes de qualquer tuning, observe o comportamento real com htop e ss -xl | grep php durante um pico de tráfego. Sem baseline, ajustes viram chute.
Integração via socket Unix: performance e segurança
A comunicação entre Nginx e PHP-FPM pode ocorrer por TCP (127.0.0.1:9000) ou por socket Unix (/run/php/php8.3-fpm.sock). Em um único servidor, o socket Unix é a escolha recomendada porque elimina o overhead da pilha TCP/IP e restringe o acesso ao sistema de arquivos local.
Edite o pool padrão em /etc/php/8.3/fpm/pool.d/www.conf:
listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660No bloco server do Nginx, referencie o mesmo caminho:
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_read_timeout 60s;
fastcgi_buffer_size 16k;
fastcgi_buffers 8 16k;
}Reinicie os serviços e valide:
sudo systemctl restart php8.3-fpm nginx
sudo ss -xl | grep php8.3-fpm.sockOutput esperado:
u_str LISTEN 0 128 /run/php/php8.3-fpm.sock 12345 * 0Se o Nginx retornar 502 após a mudança, verifique se o usuário www-data pertence ao grupo correto com id www-data. Em distribuições como Rocky Linux 9 e AlmaLinux 9, o usuário padrão é nginx em vez de www-data, ajuste listen.owner de acordo.
Dimensionamento de workers PHP-FPM conforme a memória
O parâmetro pm.max_children define quantas requisições PHP podem ser processadas simultaneamente. Valores baixos geram fila; valores altos consomem toda a RAM e disparam OOM killer. A fórmula prática é: RAM disponível para PHP ÷ consumo médio por processo.
Meça o consumo real antes de configurar:
ps -ylC php-fpm8.3 --sort:rss | awk '{sum+=$8; n++} END {print "Media RSS:", sum/n/1024, "MB"}'Para um VPS de 2 GB com cerca de 1,5 GB livres para PHP e consumo médio de 50 MB por worker, ajuste em www.conf:
pm = dynamic
pm.max_children = 30
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500
request_terminate_timeout = 60sA diretiva pm.max_requests recicla workers após N requisições, mitigando memory leaks em extensões PHP. Para cargas estáveis em servidor dedicado, avalie pm = static — elimina o custo de fork e oferece latência p95 mais consistente. Consulte o artigo Dicas de Otimização de Servidores Linux para recomendações adicionais de kernel tuning.
Ajuste de buffers e timeouts no Nginx para FastCGI
O servidor web precisa de buffers suficientes para armazenar respostas do PHP-FPM sem escrever em disco temporário. Buffers subdimensionados geram warnings em /var/log/nginx/error.log do tipo "an upstream response is buffered to a temporary file".
No /etc/nginx/nginx.conf, dentro do bloco http:
fastcgi_buffer_size 32k;
fastcgi_buffers 16 16k;
fastcgi_busy_buffers_size 64k;
fastcgi_temp_file_write_size 64k;
fastcgi_connect_timeout 5s;
fastcgi_send_timeout 60s;
fastcgi_read_timeout 60s;
worker_processes auto;
worker_rlimit_nofile 65535;
events {
worker_connections 4096;
multi_accept on;
use epoll;
}O valor worker_processes auto faz o Nginx detectar automaticamente o número de núcleos da CPU. Já worker_connections 4096 deve ser proporcional ao limite de file descriptors — ajuste também em /etc/security/limits.conf.
Atenção: antes de aplicar, teste a sintaxe com sudo nginx -t. Um bloco malformado derruba o serviço ao recarregar.
sudo nginx -t && sudo systemctl reload nginxMonitoramento com pm.status_path e logs slow
Para diagnosticar gargalos em tempo real, ative o endpoint de status do PHP-FPM. Adicione em www.conf:
pm.status_path = /fpm-status
ping.path = /fpm-ping
slowlog = /var/log/php8.3-fpm-slow.log
request_slowlog_timeout = 5sNo Nginx, exponha o status apenas para localhost:
location ~ ^/(fpm-status|fpm-ping)$ {
allow 127.0.0.1;
deny all;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
}Consulte o status:
curl http://127.0.0.1/fpm-status?fullOutput esperado:
pool: www
process manager: dynamic
active processes: 8
total processes: 12
max active processes: 18
max children reached: 0
slow requests: 2
listen queue: 0O campo listen queue maior que zero indica que requisições estão aguardando worker livre — sinal claro de que pm.max_children precisa aumentar ou a aplicação tem consultas lentas. Se max children reached cresce, é hora de escalar vertical ou horizontalmente.
Problemas comuns e como resolver
Sintoma: erro 502 Bad Gateway intermitente sob carga
Causa: fila do PHP-FPM saturada ou socket com permissões incorretas após reinicialização.
Solução: aumente pm.max_children gradualmente (em incrementos de 20%), confirme que listen.owner corresponde ao usuário do Nginx e monitore o listen queue em /fpm-status. Verifique também dmesg | grep -i oom para descartar falta de memória.
Sintoma: latência alta em endpoints específicos
Causa: consultas SQL lentas ou chamadas externas bloqueando workers PHP.
Solução: inspecione /var/log/php8.3-fpm-slow.log, identifique os scripts ofensores e otimize queries ou adicione cache. Reduza request_terminate_timeout para liberar workers travados. Considere o uso de Redis para cache de sessão e dados frequentes.
Sintoma: muitos arquivos temporários sendo criados em /var/lib/nginx
Causa: buffers fastcgi menores que as respostas típicas do PHP, forçando escrita em disco.
Solução: aumente fastcgi_buffers e fastcgi_buffer_size para valores compatíveis com o tamanho médio de resposta. Meça com curl -w "%{size_download}\n" -o /dev/null -s https://seusite.com.br/pagina algumas URLs reais.
Sintoma: permission denied ao conectar no socket
Causa: divergência entre o usuário que executa o Nginx (nginx em Rocky/AlmaLinux, www-data em Debian/Ubuntu) e o dono do socket.
Solução: alinhe listen.owner, listen.group e listen.mode no pool. Em ambientes multi-site, considere pools PHP-FPM separados por usuário, reforçando isolamento — técnica útil também ao combinar com redirecionamento HTTPS forçado.
Perguntas frequentes sobre Nginx + PHP-FPM
Qual a diferença entre usar socket Unix e TCP entre Nginx e PHP-FPM?
Socket Unix é mais rápido e seguro pois evita a pilha TCP/IP, sendo ideal quando Nginx e PHP-FPM estão no mesmo servidor. Já TCP (127.0.0.1:9000) é necessário quando os serviços rodam em servidores separados ou em containers distintos. Para ambientes em um único host, o socket Unix reduz latência em cerca de 5 a 15 por cento segundo testes de bancada.
Quantos workers do PHP-FPM devo configurar em um VPS com 2 GB de RAM?
Divida a RAM disponível pelo consumo médio de cada processo PHP-FPM, que gira entre 30 e 80 MB dependendo da aplicação. Em um VPS de 2 GB com 1,5 GB livre para PHP, configure pm.max_children entre 20 e 40. Sempre monitore com pm_status antes de ajustar para cima.
Por que recebo erro 502 Bad Gateway ao integrar Nginx com PHP-FPM?
O erro 502 normalmente indica que o Nginx não conseguiu se comunicar com o PHP-FPM, por socket inexistente, permissões incorretas ou todos os workers ocupados. Verifique se o caminho fastcgi_pass no Nginx corresponde exatamente ao listen do pool PHP-FPM e se o usuário do Nginx tem permissão de leitura no socket.
Devo usar pm = dynamic ou pm = static no PHP-FPM?
Use pm = static em servidores dedicados com carga previsível, pois elimina o overhead de criação de processos. Use pm = dynamic em VPS compartilhados ou aplicações com picos irregulares, pois libera memória durante períodos ociosos. Para WordPress em produção estável, static costuma oferecer melhor latência p95.
Como saber se o gargalo está no Nginx ou no PHP-FPM?
Habilite o ping.path e pm.status_path no pool PHP-FPM e consulte o endpoint para verificar fila de requisições e workers ativos. Se listen queue estiver crescendo, o gargalo é PHP-FPM. Se o Nginx reporta muitos worker_connections em uso mas PHP-FPM está ocioso, o gargalo é na camada Nginx ou rede.
Conclusão
- Prefira socket Unix em single-host e alinhe listen.owner com o usuário do Nginx para eliminar 502 por permissão
- Dimensione pm.max_children a partir da medição real de RSS dos processos PHP-FPM, nunca por chute
- Ative pm.status_path e slowlog desde o dia zero para ter métricas acionáveis antes que o problema vire incidente
Leia também
- Passo a passo para configurar Nginx com PHP-FPM no VPS Linux: Guia Completo
- Otimizar o Desempenho do Nginx com Cache Avançado em VPS Linux e Servidor Dedicado
- Otimizar Docker Compose e Nginx no mesmo servidor AlmaLinux 9
Precisa de ajuda com otimização de Nginx e PHP-FPM?
A infraestrutura VPS da AviraHost oferece recursos dedicados, SSD NVMe e liberdade total para ajustar stack LEMP conforme sua carga real. Nossa equipe técnica apoia na configuração inicial e no tuning contínuo.
