NGINX Unit como alternativa ao PHP-FPM? Arquitetura, riscos e casos de utilização

Estado «arquivado» e veredicto sucinto e claro

A 30 de setembro de 2026, o veredicto é claro: Unidade NGINX conseguia executar aplicações PHP diretamente, aceitando ligações HTTP, terminando ligações TLS, servindo ficheiros estáticos e encaminhando pedidos. Assim, o leque de funcionalidades ultrapassava claramente o do PHP-FPM. No entanto, o Unit não é uma recomendação geral para novas plataformas de alojamento PHP em produção, uma vez que o projeto oficial está arquivado desde outubro de 2025 e já não é mantido.

Isso não significa que uma instalação do Unit já existente deixe imediatamente de funcionar. Esta pode continuar a dar serviço a uma aplicação, desde que as suas dependências, medidas de segurança e um plano de migração estejam documentados. No entanto, um novo investimento deve ser avaliado de forma diferente: sem uma manutenção contínua do projeto, aumentam os riscos relacionados com falhas de segurança, disponibilidade de pacotes, novas versões do sistema operativo e compatibilidade futura com o PHP.

No que diz respeito às indicações de versão, é importante haver uma separação clara. A documentação de instalação, que continua disponível, refere frequentemente a versão Unit 1.34.2, enquanto a versão estável 1.35.0 já foi lançada. Esta versão comprova, entre outras coisas, a compatibilidade com o PHP 8.5; no entanto, isso não implica uma manutenção contínua. O ramo de desenvolvimento master Devido ao seu estado de arquivo, não constitui uma versão do produto relevante para decisões operacionais.

Distinguir entre o NGINX, o PHP-FPM e o Unit

Para se chegar a uma decisão fundamentada, é necessário analisar os componentes separadamente. NGINX é um servidor Web e um proxy reverso: recebe pedidos HTTP, pode fornecer conteúdos estáticos e reencaminha pedidos dinâmicos. O PHP-FPM, por outro lado, é um gestor de processos FastCGI. Este fornece trabalhadores PHP, mas não processa ele próprio a tarefa típica de um servidor web de aceitar e encaminhar pedidos HTTP.

Numa configuração clássica, uma solicitação chega primeiro ao NGINX. Se se tratar de um ficheiro estático, o NGINX pode fornecê-lo imediatamente. No caso de um script PHP, o NGINX transmite os parâmetros FastCGI necessários a um pool do PHP-FPM; um worker disponível executa o código e devolve a resposta através do NGINX. A dimensão do pool e o modo de processo do PHP-FPM são controlados em ficheiros de configuração no formato php.ini.

O Unit, por outro lado, era um Servidor de Aplicações com listeners, rotas, entrega estática e tempos de execução de linguagem num modelo de configuração JSON. Uma aplicação PHP é integrada como tipo de aplicação; assim, o Unit pode mapear o percurso do pedido dentro da mesma plataforma, desde a receção até à execução do PHP. Isto não reduz automaticamente o risco operacional, mas altera os limites de responsabilidade.

Por isso, o Unit não é „o NGINX com o PHP-FPM incorporado“. Ao compilar o módulo PHP, é criado um módulo SAPI próprio, que está associado à biblioteca PHP-Embed. Consequentemente, durante a análise e a migração, as equipas não só têm de transferir as configurações do FastCGI, como também têm de reatribuir o encaminhamento, as definições das aplicações, a ligação dos módulos e os percursos de diagnóstico. Os erros não podem ser atribuídos de forma generalizada a um servidor web a montante ou a um conjunto FPM separado.

Módulos PHP, versões e limites de configuração

Para o PHP, uma instalação do Unit requer, para além do núcleo, um módulo de linguagem adequado. Este módulo está vinculado à versão do PHP utilizada e à instalação do Unit. Caso não estivessem disponíveis pacotes adequados para o sistema operativo e a versão do PHP, a documentação descrevia a compilação própria com uma instalação do PHP que fornecesse a Embed-SAPI. Isto aumenta consideravelmente o esforço necessário para atualizações, compilações reproduzíveis e a análise de erros.

A configuração também segue modelos diferentes. O Unit agrupa listeners, rotas e aplicações como dados JSON através da sua interface de configuração. O PHP-FPM, por outro lado, gere os pools em ficheiros no formato php.ini. Esta diferença vai além da sintaxe: numa pilha FPM, as regras do servidor web e as definições dos pools PHP estão separadas, enquanto o Unit integra ambas de forma mais estreita numa única plataforma. Os conceitos de migração têm de ter em conta esta estrutura.

No que diz respeito às diretivas PHP, o Unit distingue as seguintes áreas admin e usuário. As opções de administrador correspondem a PHP_INI_SYSTEM e não podem ser alteradas pela aplicação em tempo de execução; as opções de utilizador correspondem a PHP_INI_USER. No entanto, o Unit não alarga o âmbito permitido de uma diretiva PHP. O modo de configuração do PHP continua a determinar se uma configuração pode ser definida desta forma ou alterada através do código da aplicação.

Aviso: A compatibilidade com o PHP 8.5 indicada na versão 1.35.0 do Unit apenas comprova o suporte a esta versão na última versão estável. Não constitui uma garantia de futuras correções de segurança ou adaptações do módulo Unit-PHP. Para a operação em produção, devem, por isso, ser documentados a data exata do Unit, a versão do PHP, a origem do módulo e um caminho de migração testado como dependências interligadas.

Configurar o encaminhamento (routing) do PHP e o Front Controller

Uma configuração de unidade associa um ouvinte a rotas e a uma aplicação. Para uma demonstração local, o ouvinte pode estar ligado exclusivamente a 127.0.0.1:8080 ouvir. Uma rota tenta, em primeiro lugar, encontrar o ficheiro solicitado em /srv/example-app/public ser entregues de forma estática. Os ficheiros PHP são excluídos desta entrega através da exclusão do tipo MIME e encaminhados para a aplicação PHP; o mesmo se aplica aos ficheiros inexistentes. Desta forma, os ficheiros públicos e a execução da aplicação permanecem compreensíveis como etapas separadas.

Na aplicação, define-se root define o diretório de documentos, enquanto type: php que seleciona o ambiente de execução do PHP. Com script: index.php cada pedido encaminhado para a aplicação é redirecionado para este script. Isto corresponde ao Controlador frontal de muitas estruturas PHP: a aplicação analisa ela própria o caminho original e decide, por exemplo, qual o controlador ou a página de erro a apresentar.

Sem essa atitude script A Unit processa caminhos de script baseados em URI. Isto pode ser adequado para aplicações mais antigas, cujos ficheiros PHP devem ser chamados diretamente, mas exige uma delimitação cuidadosa dos caminhos acessíveis. targets Permitem, além disso, subáreas com comportamentos diferentes em relação a root, script ou index. Por isso, não substituem o encaminhamento, mas constituem uma forma de definir várias regras de aplicação de forma específica.

O exemplo seguinte é um ficheiro de configuração JSON para uma demonstração local, não para um serviço público. Não contém nomes de domínio, nem dados TLS ou de acesso. Antes de o implementar, é necessário verificar os direitos de acesso ao ficheiro, o suporte PHP efetivamente instalado e o método previsto pelo Unit para importar a configuração.

{
  "listeners": {
    "127.0.0.1:8080": {
      "pass": "routes/example"
    }
  },
  "routes": {
    "example": [
      {
        "action": {
          "share": "/srv/example-app/public$uri",
          "types": ["!application/x-httpd-php"],
          "fallback": {
            "pass": "applications/example-php"
          }
        }
      }
    ]
  },
  "applications": {
    "example-php": {
      "type": "php",
      "root": "/srv/example-app/public",
      "script": "index.php"
    }
  }
}

A ordem é determinante: O entrega estática A etapa «share», que serve para este fim, é tentada antes do «fallback», mas exclui expressamente os ficheiros PHP. Estas solicitações e os ficheiros inexistentes são encaminhados para index.php; assim, também funcionam URLs descritivas como /artikel/beispiel sem um ficheiro com o mesmo nome. A necessidade de regras adicionais para diretórios de upload, áreas de administração ou ficheiros PHP diretamente acessíveis depende da aplicação em questão e não deve ser deduzida de forma generalizada a partir desta demonstração.

Comparar modelos de processos e orçamento RAM

O PHP-FPM controla os trabalhadores de cada pool através dos modos static, dynamic e ondemand. No Unit, por outro lado, o número de processos é modelado no âmbito da aplicação. Uma configuração dinâmica do Unit limita com processes.max o número total e mantém-se com processes.spare Processos em espera; idle_timeout elimina os processos inativos em excesso.

Por isso, os termos não são intercambiáveis de forma direta. Em particular, uma predefinição documentada não é um valor adequado para um site. Tanto pm.max_children tão bem como processes.max limitam o trabalho paralelo do PHP e, se os valores forem demasiado baixos, podem criar filas de espera. Por outro lado, valores demasiado elevados competem pela memória com o sistema operativo, a base de dados, a cache e outros serviços.

A Orçamento de RAM É, numa primeira fase, apenas um modelo de planeamento: da memória total são deduzidas as reservas para o sistema operativo, a base de dados, a cache e outros processos. O valor restante é dividido por uma estimativa conservadora das necessidades de memória por cada worker PHP. A título de exemplo, 1 200 MiB para o PHP, divididos por 120 MiB por worker, resultam matematicamente em dez workers; ambos os valores são valores de referência escolhidos deliberadamente, não constituindo uma medição nem uma recomendação de configuração.

O resultado é um Limite superior e um ponto de partida para a observação, não a configuração correta. O que é determinante são os picos reais, as filas de espera, os erros de resposta e as necessidades de memória sob carga normal e elevada. Para a dedução metódica e o reajuste de pm.max_children a contribuição interna ajuda Calcular o número adequado de processos filhos do PHP-FPM. No Unit, aplica-se o mesmo princípio, mesmo que os parâmetros tenham nomes diferentes.

Aviso: definir limites do processo limitando-se a adotar valores fornecidos por terceiros muitas vezes apenas adia os problemas. Só um orçamento de memória bem definido e uma monitorização contínua permitem verificar se um limite máximo de workers é adequado para a aplicação, as suas extensões e os serviços executados em simultâneo.

Avaliar modelos operacionais para alojamento PHP

A tabela classifica as arquiteturas, não a velocidade nem o consumo de memória. O principal argumento a favor da nova hospedagem PHP na configuração NGINX-PHP-FPM é a separação clara: o servidor web trata do HTTP, do proxy e dos conteúdos estáticos, enquanto o PHP-FPM gere os trabalhadores PHP por pool. Estas responsabilidades facilitam a avaliação separada das configurações, dos erros e das atualizações.

O Unit conseguiu reunir listeners, roteamento, ficheiros estáticos e aplicações numa única plataforma e suportar outros motores de execução para além do PHP. Esta abordagem multilíngue pode explicar por que razão um ambiente já existente optou pelo Unit. No entanto, para ofertas exclusivamente baseadas em PHP, não constitui automaticamente uma vantagem: não substitui nem a avaliação das funcionalidades necessárias, nem a verificação de se a equipa será capaz de dominar a longo prazo a lógica de configuração e funcionamento diferente.

No caso da Unidade 1.35.0, o âmbito funcional técnico deve ser definido pelo Estado de manutenção serem separadas. A data de lançamento indica a versão publicada e as respetivas alterações; daí decorre que não haverá mais manutenção do projeto, que entretanto foi arquivado. No caso de uma nova decisão, este limite tem mais peso do que um número reduzido de componentes visíveis. Por outro lado, no caso de uma instalação já existente, constitui um motivo para documentar as dependências e um plano de migração.

O Apache com PHP-FPM não é, de forma geral, uma alternativa melhor ou pior, mas sim uma opção quando existem requisitos específicos para o Apache. A escolha deve basear-se na facilidade de manutenção, nas versões de PHP disponíveis, nos processos de aplicação de patches, nos conhecimentos da equipa e no plano de contingência. Sem perfis de carga comparáveis e uma metodologia de medição documentada, não é possível estabelecer uma classificação de desempenho fiável a partir desta visão geral da arquitetura.

Utilizar a unidade em segurança no parque de equipamentos

Uma instalação existente do Unit deve, em primeiro lugar, ser registada como sistema existente, e não como modelo para uma nova plataforma. O que é determinante é a versão efetivamente utilizada, as aplicações ligadas e as suas dependências. O facto de o Unit continuar a ser tecnicamente executável não altera o facto de o projeto ter sido arquivado; a operação e a substituição devem, portanto, ser planeadas em conjunto.

No WordPress, no Joomla ou no Drupal, o Controlador frontal O ponto fundamental: os caminhos que não correspondem a ficheiros existentes têm de ser redirecionados para o ficheiro principal de inicialização do PHP, enquanto os ficheiros existentes podem ser servidos diretamente. O guia do WordPress para o Unit ilustra este princípio de encaminhamento, incluindo o tratamento de ficheiros PHP e /wp-admin/. No caso de um CMS já existente, esta pode ser uma configuração compreensível; no entanto, no caso de uma nova instalação, isso não constitui uma recomendação para o Unit.

Várias pequenas aplicações em PHP, Python, Ruby ou Node.js puderam ser agrupadas numa plataforma comum através do Unit, com o Listener, as rotas e os motores de execução. Isso pode explicar por que razão uma arquitetura existente optou, na altura, pelo Unit. No entanto, no caso de um alojamento exclusivamente em PHP, esta capacidade multilíngue não é um fim em si mesma: componentes separados e bem mantidos podem, a longo prazo, ser mais fáceis de manter, apesar das interfaces adicionais.

A implantação de um contentor congelado exige um inventário particularmente preciso. Para tal, documente a data exata da unidade, a versão do PHP, o módulo de idioma instalado, a imagem base e a configuração completa. Acrescente ainda as fontes das imagens e dos pacotes, o processo de aplicação de patches, bem como um plano de migração e um plano de contingência testados. A compatibilidade com o PHP de uma determinada versão da unidade não constitui, neste contexto, uma garantia de que o módulo associado venha a receber correções de segurança no futuro.

O NGINX pode ser colocado à frente do Unit, por exemplo, quando se pretende manter uma camada NGINX existente ou encaminhar acessos de forma específica para uma camada anterior. A documentação do Unit também menciona esta integração no contexto da proteção do Control Socket. No entanto, esta integração não resolve o problema do estado «arquivado» e cria mais um serviço com configuração, registo e responsabilidade de atualização próprias. Por isso, os benefícios devem ser ponderados concretamente em relação a este esforço operacional.

Timeouts, registos e processos bloqueados

Os limites do processo não constituem um diagnóstico de erros. Com limits.requests O Unit pode substituir um processo de aplicação após um número definido de pedidos processados. Isto pode limitar temporariamente a ocupação acumulada de memória, mas não elimina fugas de memória, nem estruturas de dados excessivamente grandes, nem chamadas externas que causam bloqueios. Por conseguinte, um reinício regular não deve ser considerado prova de que o código da aplicação é estável.

Com limits.timeout O Unit encerra um pedido após o término do tempo configurado com um código HTTP 503. Trata-se de um limite de proteção visível para pedidos individuais, mas não constitui uma proteção total contra workers bloqueados: de acordo com a documentação, o Unit não deteta processos bloqueados; estes podem permanecer no conjunto de processos. Um tempo de espera mais elevado apenas adia este problema; um tempo de espera mais baixo pode interromper operações que são normalmente lentas.

• Registar o estado HTTP, os percursos afetados, o intervalo de tempo e a frequência antes de alterar os valores-limite.
• Agrupar os registos de acesso, de erros e de aplicação com base em carimbos de data e hora; no caso do PHP-FPM, um «slowlog» pode fornecer informações adicionais sobre a pilha.
• Verificar a CPU, a memória, as entradas/saídas, as ligações de rede, bem como o estado e o número de processos.
• Em seguida, analise o código, as consultas à base de dados, os acessos ao sistema de ficheiros e os serviços externos como possíveis causas.
• Só depois de se conhecerem a causa e o perfil de carga é que se devem ajustar de forma específica os tempos limite, os limites dos processos ou as regras de reinício.

Um erro HTTP 503 pode, portanto, indicar que o tempo limite expirou, mas também pode ser causado por componentes a montante ou por outros erros. Não deves resolver o problema das solicitações PHP longas e recorrentes apenas através do número de workers. O guia sobre o Slowlog do PHP-FPM e análise das causas das solicitações lentas mostra como as trilhas da pilha podem ser associadas aos dados do pedido; a mesma lógica de causa e efeito também se aplica a uma análise do inventário de unidades.

Os sintomas sem uma conclusão clara são particularmente críticos: tempos de espera crescentes, processos permanentemente ocupados ou ausência de registos de progresso. Nesses casos, o estado do processo e as dependências são mais importantes do que um aumento genérico do tempo de espera. Verifica, por exemplo, se um worker PHP está à espera de E/S da base de dados, do DNS, do sistema de ficheiros ou da rede. Só o bloqueio concreto determina se é adequada uma correção do código, um ajuste de recursos ou um reinício controlado.

Escolha entre sistemas novos e antigos

Para novos ambientes de alojamento PHP, um servidor Web bem mantido com PHP-FPM é a escolha padrão mais lógica. O PHP-FPM faz parte da distribuição normal do PHP e disponibiliza opções documentadas de gestão de pools e de processos. No caso do Unit, por outro lado, a questão passa da mera funcionalidade para a facilidade de manutenção: a instalação pode continuar a funcionar, mas o estado arquivado do projeto aumenta o risco de uma dependência a longo prazo.

No caso de sistemas Unit já existentes, uma decisão fundamentada começa com um inventário. Verifique o estado de manutenção e a capacidade de aplicação de patches do sistema operativo, do PHP e da imagem base, a compatibilidade do módulo de idioma instalado, os conhecimentos operacionais disponíveis, bem como os serviços associados. Igualmente importantes são as configurações exportáveis, um rollback reproduzível e um sistema de destino para o qual o encaminhamento, as definições do PHP e as implementações possam ser transferidos passo a passo.

Uma migração não requer um prazo genérico inventado, mas sim uma ordem de prioridades. As aplicações expostas à Internet, as imagens que não podem ser atualizadas, a origem pouco clara dos módulos e as aplicações críticas para o negócio sem um plano de contingência merecem atenção prioritária. Posteriormente, as aplicações podem ser agrupadas de acordo com a complexidade e as dependências. A operação em paralelo durante uma transição controlada pode reduzir os riscos, desde que a gestão de dados, as sessões e o caminho de regressão sejam definidos previamente.

O API de controlo trata-se de um acesso administrativo e não de um ponto de acesso normal de um site. A Unit documenta para si um soquete de domínio Unix e justifica a sua utilização com base em aspetos de segurança. Defina direitos de ficheiro restritivos e acessos administrativos claramente delimitados; a acessibilidade pública proporcionaria aos atacantes, caso conseguissem aceder, amplas possibilidades de alterar a configuração.

O percurso prático de migração não termina com uma nova configuração do processo. Transfira, aplicação a aplicação, a versão do PHP, as extensões, os valores de ambiente, os direitos de ficheiro, as regras de encaminhamento e a observabilidade para o sistema de destino. Ao fazê-lo, compare as respostas esperadas e os casos de erro, em vez de tirar conclusões genéricas sobre a velocidade. Desta forma, o que era um fardo não planeado transforma-se numa migração documentada Estratégia de substituição com decisões técnicas fundamentadas.