O que é PHP-FPM | Instalar e configurar o PHP-FPM

Ambiente de teste Família RHELAlmaLinux 9.8Apache 2.4 + PHP-FPM 8.3conta rootVerificado em 2026-10-26

O PHP-FPM é um gerenciador de processos FastCGI em que processos worker iniciados com antecedência recebem as requisições PHP repassadas por um servidor web e as processam. Em um servidor AlmaLinux 9 com Apache, este guia verifica se ele está instalado e como estão configurados os pools e os sockets de cada site, e vai até o teste da configuração e a verificação do status com a saída real.

O Apache também pode executar o PHP diretamente com o mod_php, mas, se você o repassa ao PHP-FPM, o servidor web e o PHP ficam separados. O Nginx não consegue executar o PHP diretamente, então repassa as requisições a um processo FastCGI como o PHP-FPM. Por isso um único PHP-FPM pode ser ligado tanto ao Apache quanto ao Nginx. A configuração de pools e a estrutura de sockets abaixo valem do mesmo jeito quando você liga o PHP-FPM ao Nginx.

1️⃣ O que é o PHP-FPM: a diferença entre CGI e FastCGI

CGI (Common Gateway Interface) é a forma padrão de um servidor web executar um programa externo para gerar conteúdo dinâmico, e ele inicia o programa de novo a cada requisição recebida. O custo de criar e remover um processo a cada requisição se acumula, e o servidor responde mais devagar conforme os acessos aumentam.

O FastCGI elimina esse custo iniciando o programa com antecedência e tratando as requisições em sequência. É a diferença entre ligar e desligar o computador a cada uso e usar direto um computador que já está ligado. O PHP-FPM (FastCGI Process Manager) é o gerenciador que executa o PHP via FastCGI e vem incluído no PHP desde a versão 5.3.3.

Para cada pool, que é um grupo de workers, o PHP-FPM inicia com antecedência o número de workers definido; um worker livre recebe a requisição que o servidor web repassa pelo socket, a processa e espera a próxima. Arquivos estáticos, como imagens e CSS, são respondidos diretamente pelo servidor web, e só os arquivos PHP passam para o PHP-FPM. Só muda a forma como o servidor web repassa as requisições ao socket: o Apache usa o módulo mod_proxy_fcgi e o Nginx usa a diretiva fastcgi_pass.

🧩 Como o CGI e o PHP-FPM tratam as requisições
Diagrama explicativo
⚙️ Execução do PHP
🌐 Servidor web
🌐 ApacheNginx
📨 Requisição 1 · index.php📨 Requisição 2 · wp-login.php📨 Requisição 3 · index.php
Arquivos estáticos (imagens, CSS) são respondidos diretamente pelo servidor web
Executa a cada requisiçãoFastCGI · socket→
🧱 Processos CGI
Requisição 1Novo processo → tratamento → encerramento
Requisição 2Novo processo → tratamento → encerramento
Requisição 3Novo processo → tratamento → encerramento
Quando o tratamento termina, o processo também desaparece · a próxima requisição começa de novo
🧰 Pool do PHP-FPM [siteuser]
Worker 1Requisição 1
Worker 2Requisição 2
Worker 3Requisição 3
Worker 4espera
Worker 5espera
Os workers iniciados com antecedência recebem as requisições e, ao terminar, esperam a próxima
Quando o Apache executa o PHP como CGI, ele inicia um novo processo PHP a cada requisição e o encerra ao terminar o tratamento, então o custo de criar processos se acumula conforme as requisições aumentam.
O Nginx não tem nenhum módulo que execute programas CGI diretamente, por isso essa combinação não é usada; o PHP é repassado ao PHP-FPM via FastCGI.
O Apache repassa as requisições PHP ao socket com o mod_proxy_fcgi, e um worker do PHP-FPM iniciado com antecedência a recebe, a processa e espera a próxima.
O Nginx as repassa ao mesmo socket com fastcgi_pass, então, mesmo com outro servidor web, o pool do PHP-FPM continua sendo o mesmo.

2️⃣ Instalar o PHP-FPM: verificar o pacote e instalar com o dnf

Se você instalou o PHP com o dnf em um servidor da família RHEL, o pacote php-fpm foi instalado junto. Primeiro verifique com o rpm se ele está instalado. O processo de instalação do PHP é o mesmo de Instalar o APM no Rocky Linux.

rpm -qa | grep php-fpm
php-fpm-8.3.36-1.module_php.8.3.el9.remi.x86_64

Se a saída estiver vazia, ele não está instalado; instale com o dnf.

dnf -y install php-fpm

Quando a instalação terminar, execute de novo o mesmo comando rpm para verificar se o nome do pacote é exibido.

3️⃣ Configurar o PHP-FPM: o pool www.conf, o socket e os modos estático e dinâmico

Há dois arquivos de configuração: a configuração geral [/etc/php-fpm.conf] e a configuração de pools [/etc/php-fpm.d/www.conf]. As linhas para olhar primeiro no pool padrão www.conf são listen e pm, e os valores logo após a instalação são estes.

grep -E '^(listen|pm) ' /etc/php-fpm.d/www.conf
listen = /run/php-fpm/www.sock
pm = dynamic

O listen é o lugar para onde o servidor web repassa as requisições, e o valor padrão na versão 8.3 é o socket Unix [/run/php-fpm/www.sock]. O valor padrão das versões antigas, [127.0.0.1:9000], recebe as requisições por uma porta TCP. Dentro do mesmo servidor, o socket é mais leve porque dispensa o processo de conexão por porta, e com listen.owner e listen.group você pode restringir o acesso como se fossem permissões de arquivo.

🔲 Configurar o modo estático e o modo dinâmico

O pm é a forma de iniciar os workers, e você define um destes três valores: static, dynamic ou ondemand. O modo estático mantém sempre iniciado o número escrito em pm.max_children, e a configuração abaixo mantém 100 workers.

pm = static
pm.max_children = 100

O modo dinâmico é o padrão e aumenta ou diminui o número de workers conforme o volume de requisições. A configuração abaixo inicia 12 na partida, mantém entre 6 e 18 workers livres e cresce até no máximo 120.

pm = dynamic
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18

O modo ondemand só inicia workers quando chega uma requisição e os encerra depois que pm.process_idle_timeout passa; por isso serve para sites com poucos acessos e não serve para sites com muitos acessos.

Os três modos diferem em quando iniciam os workers e em como o número deles sobe e desce.

ModoComo os workers são iniciadosSites adequados
static (estático)Mantém sempre iniciado o número escrito em pm.max_childrenSites com muitos acessos
dynamic (dinâmico)Padrão · sobe e desce dentro de pm.start_servers, pm.min_spare_servers e pm.max_spare_servers conforme o volume de requisiçõesSites cujo volume de acessos sobe e desce
ondemandSó inicia quando chega uma requisição e encerra depois que pm.process_idle_timeout passaSites com poucos acessos

O max_children é definido dividindo a memória do servidor pela memória que um worker usa. Mesmo quando os avisos sobre [max_children] se acumulam, não aumente o valor logo de cara; primeiro descubra nos logs quais requisições encheram os workers.

A memória e o limite de upload são definidos no php.ini, a configuração geral do PHP, e são ajustados junto com o número de workers conforme o site que você administra.

memory_limit = 1024M
post_max_size = 128M
upload_max_filesize = 128M

Os três valores são o limite de memória que um script PHP pode usar e o tamanho dos arquivos que podem ser enviados de uma vez, e só passam a valer depois de reiniciar o PHP-FPM.

🔲 Configurar um pool por conta de site

Quando há vários sites, não se compartilha um único www.conf: cria-se um arquivo de pool por conta e separam-se a conta de execução e o socket. O PHP de um site não consegue ler os arquivos de outra conta, e o número de workers é definido por site.

vi /etc/php-fpm.d/siteuser.conf

No arquivo vão o nome do pool, a conta de execução, o caminho do socket e o número de workers.

[siteuser]
user = siteuser
group = nobody
listen = /run/php-fpm/siteuser.sock
listen.owner = siteuser
listen.group = nobody
listen.mode = 0660
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
chdir = /home/siteuser/www

listen.owner e listen.group são o dono e o grupo do arquivo do socket, e o PHP-FPM cria o socket com esses valores ao iniciar. Se o servidor web é executado com a conta nobody, escreva nobody em listen.group; se for a conta apache, escreva apache, para que o servidor web consiga abrir o socket.

listen.owner = siteuser
listen.group = nobody
listen.mode = 0660

Essas três linhas vão em cada arquivo de pool, e depois de alterar os valores é preciso reiniciar para que o socket seja recriado com as novas permissões.

🔲 Configurar o slowlog

O slowlog é um arquivo que registra onde estava sendo executada uma requisição que demorou mais que request_slowlog_timeout, e com o valor 0 nada é registrado. Quando for procurar a causa de requisições lentas, ative-o indicando um tempo em segundos, como 3s.

slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 0

O arquivo registrado guarda o caminho do script da requisição lenta e a função que estava em execução naquele momento, então dá para ver qual plugin ou código demorou.

4️⃣ Integração com o Apache: configuração do VirtualHost e permissões do socket

O Apache repassa as requisições de arquivos PHP ao socket do pool com o módulo mod_proxy_fcgi. Você coloca uma linha SetHandler no FilesMatch dentro do VirtualHost e, em cada site, escreve o socket da conta dele.

# Um VirtualHost por conta de site · em SetHandler vai o socket dessa conta (em vez de SetHandler, também é possível ligar com ProxyPassMatch)
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /home/siteuser/www

    <Directory /home/siteuser/www>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php-fpm/siteuser.sock|fcgi://localhost"
    </FilesMatch>
</VirtualHost>

DocumentRoot e Directory são a raiz web dessa conta, e o -Indexes em Options impede que a lista de pastas apareça no navegador.

🔲 Configurar as permissões do socket

Quando o pool inicia, o socket é criado com os valores de listen.owner, listen.group e listen.mode, e você confere com o ls se as permissões estão corretas.

ls -l /run/php-fpm/
total 4
srw-rw----  1 siteuser_a nobody 0 out 22 23:34 siteuser_a.sock
-rw-r--r--  1 root       root   7 out 26 03:00 php-fpm.pid
srw-rw----  1 siteuser_b nobody 0 out 22 23:34 siteuser_b.sock
srw-rw----+ 1 root       root   0 out 22 23:34 www.sock

Se as permissões não batem e o servidor web não consegue abrir o socket, os visitantes recebem um erro 503; para corrigir na hora sem reiniciar, defina o dono e as permissões com chown e chmod.

Esta é a sintaxe atual, que separa o usuário e o grupo com dois-pontos.

chown siteuser:nobody /run/php-fpm/siteuser.sock

Depois de mudar o dono, ajuste as permissões para 660.

chmod 660 /run/php-fpm/siteuser.sock

Esta é a sintaxe antiga, que separa o usuário e o grupo com um ponto, e o chown a executa normalmente também no AlmaLinux 9.

chown siteuser.nobody /run/php-fpm/siteuser.sock

Depois de mudar o dono, ajuste as permissões para 660.

chmod 660 /run/php-fpm/siteuser.sock

O resultado das duas sintaxes é o mesmo: usando qualquer uma, o dono do socket passa a ser siteuser e o grupo passa a ser nobody.

🔲 Integração com o Nginx: a diretiva fastcgi_pass

No Nginx, o location dos arquivos PHP dentro do bloco server repassa as requisições ao socket do mesmo pool com fastcgi_pass.

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php-fpm/siteuser.sock;
}

Se o Nginx é executado com a conta nginx, é preciso escrever nginx em listen.group no arquivo de pool para que ele consiga abrir o socket.

5️⃣ Teste da configuração e reinício: php-fpm -t e systemctl

Depois de alterar a configuração, não reinicie logo em seguida; faça antes uma verificação de sintaxe com php-fpm -t. Se houver um erro de digitação em um arquivo de pool, todo o PHP-FPM cai no reinício e todos os sites recebem um 503.

php-fpm -t
[26-Oct-2026 17:33:45] NOTICE: configuration file /etc/php-fpm.conf test is successful

Se a verificação passar, a mensagem [test is successful] é exibida junto com o caminho do arquivo de configuração, e depois você aplica a mudança no PHP-FPM. Uma mudança que exige recriar o socket, como o caminho do socket ou o listen.owner, é aplicada com restart. Se você alterou só valores como o número de workers em um servidor em produção, aplique com reload.

systemctl restart php-fpm

Se você editou o VirtualHost, reinicie também o Apache.

systemctl restart httpd

Registre-o com enable para que seja executado automaticamente quando o servidor for ligado de novo.

systemctl enable php-fpm

Verifique se ele está registrado com is-enabled.

systemctl is-enabled php-fpm
enabled

Com o status, verifique se há workers em execução em cada pool.

systemctl status php-fpm
● php-fpm.service - The PHP FastCGI Process Manager
     Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; preset: disabled)
     Active: active (running) since x
    Process: 3934033 ExecReload=/bin/kill -USR2 $MAINPID (code=exited, status=0/SUCCESS)
   Main PID: 1333314 (php-fpm)
     Status: "Processes active: 4, idle: 21, Requests: x, slow: 0, Traffic: x"
      Tasks: x
     Memory: x
        CPU: x
     CGroup: /system.slice/php-fpm.service
             ├─  41920 "php-fpm: pool siteuser_a"
             ├─  94143 "php-fpm: pool siteuser_b"
             ├─1333314 "php-fpm: master process (/etc/php-fpm.conf)"
             ├─3934078 "php-fpm: pool www"
             └─4009016 "php-fpm: pool siteuser_a"

out 26 03:00:01 server.example.com systemd[1]: Reloading The PHP FastCGI Process Manager...
out 26 03:00:01 server.example.com systemd[1]: Reloaded The PHP FastCGI Process Manager.

Na linha Status, active e idle são os workers que estão processando requisições agora e os workers livres, e o CGroup lista os workers por nome de pool. O nome do host e os nomes dos pools na saída foram trocados por valores de exemplo.

🔢 FAQ & conteúdo recomendado

O mod_php executa o PHP dentro do processo do Apache, então a configuração é simples, mas o PHP é carregado em cada worker do Apache, o que gasta muita memória e dificulta separar a conta de execução por site. O PHP-FPM separa o PHP em processos próprios, de modo que cada site pode ter sua própria conta e seu próprio número de workers; por isso, em um servidor com vários sites ou que usa Nginx, usa-se o PHP-FPM.

O systemctl reload php-fpm envia um sinal USR2 ao processo mestre, que lê a configuração de novo e substitui os workers. Se você definir process_control_timeout, os workers que terminaram a requisição em andamento são substituídos primeiro (conforme a documentação oficial). O restart derruba todos os workers e os sobe de uma vez, então as requisições daquele momento podem ser cortadas; em um servidor em produção, use primeiro o reload.

Na família RHEL, o log padrão é [/var/log/php-fpm/error.log], e é ali que ficam os avisos de falta de workers (seems busy · max_children) e os registros de início e parada dos pools. No arquivo que você define por pool com php_admin_value[error_log], os erros do código PHP daquele site são registrados à parte. O pool padrão registra em [/var/log/php-fpm/www-error.log].

ℹ️ Aviso de afiliados
O conteúdo deste site contém links de afiliados. Quando um visitante compra um produto ou serviço por meio de um desses links, o site recebe uma comissão do vendedor. O valor que o comprador paga (em promoções, ele diminui ↓) não aumenta por causa disso. Preços, descontos e informações de estoque valem para o momento em que o texto foi escrito e podem ter mudado, por isso confirme com o vendedor antes de comprar. Os produtos são escolhidos e avaliados por critérios próprios, e o recebimento de comissão não influencia a ordem de apresentação nem o conteúdo das avaliações.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Demonstre sua humanidade: 6   +   5   =