# Plesk: compreender os handlers do PHP (FPM, FastCGI, módulo Apache)

> Handlers PHP do Plesk comparados: FPM, Dedicated FPM, FastCGI e módulo Apache do ponto de vista da segurança, com notas sobre PHP2Shell, nginx e .htaccess.

Fonte: https://phpsos.de/pt/blog/plesk-php-handler/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** O handler PHP do Plesk define como o PHP corre para um site: como aplicação FPM com pool partilhado, como Dedicated FPM com pool próprio por site, como aplicação FastCGI ou como módulo Apache (mod_php). Do ponto de vista da segurança, o Dedicated FPM é em Linux geralmente a melhor escolha e o módulo Apache a pior. O próprio Plesk classifica-o como obsoleto ou inseguro e, no PHP2Shell, a equipa do PHP vê o maior risco precisamente no mod_php.

## Porque é que o handler é mais do que uma questão de desempenho

No Plesk, escolhe para cada site uma versão do PHP e um handler. Muitos tratam o handler como um detalhe de desempenho e memória. Mas ele decide também até que ponto os sites estão separados uns dos outros, onde atuam as definições de segurança e que processos têm de ser reiniciados depois de uma atualização.

Depois do PHP2Shell, esta escolha torna-se concreta. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 afetam todos os modos de operação habituais, mas a equipa do PHP classifica o risco como mais elevado no mod_php. Quem ainda opera domínios com o módulo Apache no seu servidor Plesk deve alterá-lo agora. Como verificar versões e aplicar patches está descrito na página [Servidores Plesk: verificar e aplicar patches às versões do PHP](https://phpsos.de/pt/server/plesk/); aqui trata-se da escolha do modo de operação.

## Os handlers PHP do Plesk em resumo

A visão geral seguinte baseia-se na documentação do Plesk para o Plesk Obsidian, complementada com a perspetiva de segurança. Em Linux, segundo o Plesk, os handlers FPM podem ser servidos à escolha através do Apache ou do nginx, o FastCGI sempre através do Apache.

| Handler | Servido através de | Isolação | Recomendação segundo o Plesk | Perspetiva de segurança |
|---|---|---|---|---|
| Dedicated FPM application | Apache ou nginx | pool próprio por site | Linux com alojamento partilhado | melhor separação, valores próprios por pool |
| FPM application | Apache ou nginx | pool partilhado por versão do PHP | servidores Linux dedicados | um site com falhas pode perturbar outros com a mesma versão |
| FastCGI application | Apache (Linux) | processos persistentes, boa separação | servidores Windows | sólido, em Linux geralmente substituído pelo FPM |
| Apache module (mod_php) | Apache | PHP no processo do servidor web | não recomendado | maior risco do PHP2Shell segundo a equipa do PHP |
| CGI application | Apache | novo processo por pedido | não recomendado | obsoleto |

Os antecedentes dos próprios modos de operação são explicados nas páginas [PHP-FPM explicado](https://phpsos.de/pt/php/php-fpm-erklaert/) e [Porque é que o mod_php tem o maior risco](https://phpsos.de/pt/php2shell/mod-php-risiko/).

## Pool partilhado ou próprio?

A diferença entre FPM e Dedicated FPM é muitas vezes subestimada. No handler FPM normal, segundo o Plesk, todos os sites com a mesma versão do PHP partilham um pool de processos. Isso poupa memória, mas significa também: um site que cause problemas pode arrastar todos os outros com a mesma versão, e a cache comum é partilhada.

O Dedicated FPM dá a cada site um pool próprio. Segundo o Plesk, melhora a isolação e o desempenho, mas custa mais memória. Do ponto de vista da segurança, o pool próprio é a base para definir separadamente por site valores como `open_basedir`, limites de memória ou limites de upload. Como separar os pools de forma consequente está descrito no artigo [Isolar os pools PHP-FPM por site](https://phpsos.de/pt/blog/php-fpm-pools-isolieren/).

## nginx ou Apache: a armadilha do .htaccess

Se escolher um handler servido através do nginx, muda algo fundamental: segundo o Plesk, estes handlers ignoram o ficheiro `.htaccess`. O que lá está deixa de ter efeito.

Isto é uma questão de segurança. Muitas aplicações e administradores guardam regras de proteção no `.htaccess`, como a proibição de executar ficheiros PHP em pastas de upload ou bloqueios de ficheiros de configuração. Depois de passar para o nginx, estas regras ficam silenciosamente sem efeito. Verifique por isso, antes da mudança, que regras de proteção constam do `.htaccess` e transponha-as para a configuração nginx do domínio.

> **Importante:**
> Uma mudança de handler é uma alteração da configuração de segurança. Depois, teste de forma dirigida se os caminhos bloqueados continuam bloqueados, e não apenas se a página inicial carrega.

## Verificar e alterar o handler

Primeiro, faça um levantamento de que domínios usam que handler. Os comandos são apenas de leitura.

```bash
# Todos os handlers registados com ID, versão e tipo
plesk bin php_handler --list

# Domínios que usam um determinado handler (ID da lista)
plesk bin php_handler --get-usage -id <handler-id>

# O PHP corre no processo do Apache? (Debian/Ubuntu: apache2ctl, família RHEL: httpd)
apache2ctl -M 2>/dev/null | grep -i php
```

Para a alteração, proceda domínio a domínio:

1. Registar as regras de proteção do `.htaccess`, caso o novo handler seja servido através do nginx.
2. Definir para o novo handler os valores provisórios contra o PHP2Shell, como `session.upload_progress.enabled=0`. No FPM, pertencem às diretivas adicionais do pool como `php_admin_value`; no FastCGI atuam outras vias.
3. Mudar o handler nas definições de PHP do domínio, de preferência primeiro numa cópia.
4. Testar as funções e verificar se o domínio é servido por processos com código atual.
5. Se o módulo Apache já não for usado por nenhum domínio, desativar o handler.

## Por que ordem alterar?

Num servidor Plesk que foi crescendo, raramente é possível alterar tudo num dia. Uma ordem por risco ajuda a usar bem o tempo escasso:

- **Primeiro os domínios com o módulo Apache**, porque aí o risco do PHP2Shell é o mais elevado segundo a equipa do PHP e o Plesk desaconselha-o de qualquer modo.
- **Depois os domínios com dados sensíveis**, como lojas, portais de clientes ou formulários com dados de saúde ou contratuais. Aqui o pool próprio compensa especialmente.
- **A seguir os domínios em versões antigas do PHP**, que de qualquer modo têm de ser migrados. Handler e versão podem ser mudados juntos numa janela de manutenção.
- **No fim a passagem do pool partilhado para o pool próprio** nos restantes domínios, desde que a memória do servidor o permita.

Antes do último passo, verifique a ocupação da memória. O Plesk alerta para o facto de o Dedicated FPM precisar de mais memória e aconselha a monitorização com muitos sites. Um servidor que passa a usar swap depois da migração fica lento, e uma memória escassa não é um bom estado precisamente com o PHP2Shell.

## Como ajuda concretamente a PHP SOS?

- Registamos que domínios do seu servidor Plesk usam que handler e assinalamos os domínios com módulo Apache.
- Passamos para Dedicated FPM e transpomos as regras de proteção do `.htaccess` para a configuração nginx, onde necessário.
- Definimos valores provisórios e limites por pool e verificamos que atuam no contexto web.
- No âmbito do [hardening de servidores](https://phpsos.de/pt/leistungen/server-haertung/), desativamos handlers obsoletos e documentamos a configuração.


## Perguntas frequentes

**Que handler PHP recomenda o Plesk?**  
Segundo a documentação do Plesk, o FPM é o handler recomendado em servidores Linux dedicados, o Dedicated FPM em servidores Linux para alojamento partilhado e o FastCGI em servidores Windows. O módulo Apache, o CGI e o ISAPI são classificados pelo Plesk como muito obsoletos ou inseguros.

**Porque é que o handler módulo Apache é particularmente crítico depois do PHP2Shell?**  
O handler corresponde ao mod_php. A equipa do PHP classifica o risco do PHP2Shell como mais elevado no mod_php, porque aí foi demonstrado um exploit antes de o código da aplicação correr. Além disso, o próprio Plesk desaconselha este handler.

**O que muda se o PHP for servido através do nginx em vez do Apache?**  
Segundo o Plesk, os handlers servidos através do nginx ignoram o ficheiro .htaccess. As regras de segurança que lá estão, como bloqueios do PHP em pastas de upload, deixam então de funcionar e têm de ser transpostas para regras do nginx.

**Tenho de reiniciar o PHP depois de mudar de handler?**  
Depois da mudança, verifique que processos PHP correm para o domínio e desde quando. No Dedicated FPM, o domínio recebe um pool próprio. Um processo antigo com código desatualizado já não deve trabalhar para o domínio.

**O Dedicated FPM é sempre a melhor escolha?**  
Para a isolação, sim, porque cada site recebe um pool próprio. O preço é uma maior necessidade de memória. O Plesk aconselha a monitorizar servidores com muitos sites.

## Fontes

- [Documentação do Plesk: Choosing the PHP Handler](https://docs.plesk.com/en-US/obsidian/administrator-guide/75145/)
- [Documentação do Plesk: php_handler](https://docs.plesk.com/en-US/obsidian/cli-linux/using-command-line-utilities/php_handler-php-handlers.72490/)
- [php.net: avisos de segurança](https://www.php.net/)