¿NGINX Unit como alternativa a PHP-FPM? Arquitectura, riesgos y casos de uso

Estado «archivado» y veredicto breve y claro

A fecha de 30 de septiembre de 2026, el veredicto es claro: NGINX Unit Podía ejecutar aplicaciones PHP directamente y, al mismo tiempo, aceptar conexiones HTTP, terminar conexiones TLS, servir archivos estáticos y enrutar solicitudes. De este modo, su gama de funciones superaba con creces la de PHP-FPM. No obstante, Unit no es una recomendación general para nuevas plataformas de alojamiento PHP en producción, ya que el proyecto oficial está archivado desde octubre de 2025 y ya no recibe mantenimiento.

Esto no significa que una instalación de Unit ya existente deje de funcionar de inmediato. Puede seguir dando servicio a una aplicación, siempre y cuando se hayan documentado sus dependencias, las medidas de seguridad y una ruta de migración. Sin embargo, una nueva inversión debe evaluarse de otra manera: sin un mantenimiento continuo del proyecto, aumentan los riesgos relacionados con las vulnerabilidades de seguridad, la disponibilidad de los paquetes, las nuevas versiones del sistema operativo y la compatibilidad futura con PHP.

Es importante establecer una distinción clara en lo que respecta a las versiones. La documentación de instalación, que sigue estando disponible, menciona en numerosas ocasiones la versión 1.34.2, mientras que la versión estable publicada es la 1.35.0. Esta versión es compatible, entre otras cosas, con PHP 8.5; sin embargo, esto no implica que se vaya a seguir manteniendo. La rama de desarrollo master Debido a su estado de archivo, no es una versión del producto relevante para la toma de decisiones operativas.

Diferencias entre NGINX, PHP-FPM y Unit

Para tomar una decisión sólida, hay que analizar cada uno de los componentes por separado. NGINX es un servidor web y un proxy inverso: recibe solicitudes HTTP, puede servir contenidos estáticos y reenvía las solicitudes dinámicas. PHP-FPM, por su parte, es un gestor de procesos FastCGI. Proporciona trabajadores PHP, pero no se encarga por sí mismo de la tarea típica de un servidor web de aceptar y enrutar solicitudes HTTP.

En la estructura clásica, una solicitud llega primero a NGINX. Si se trata de un archivo estático, NGINX puede servirlo inmediatamente. En el caso de un script PHP, NGINX pasa los parámetros FastCGI necesarios a un grupo de PHP-FPM; un trabajador disponible ejecuta el código y devuelve la respuesta a través de NGINX. El tamaño del grupo y el modo de proceso de PHP-FPM se controlan mediante archivos de configuración en formato php.ini.

Unit, por el contrario, era un Servidor de aplicaciones con listeners, rutas, entrega estática y tiempos de ejecución de los idiomas en un modelo de configuración JSON. Allí se integra una aplicación PHP como tipo de aplicación; de este modo, Unit puede representar la ruta de la solicitud dentro de la misma plataforma, desde su recepción hasta la ejecución de PHP. Esto no reduce automáticamente el riesgo operativo, pero sí modifica los límites de responsabilidad.

Por lo tanto, Unit no es „NGINX con PHP-FPM integrado“. Al compilar el módulo de PHP, se crea un módulo SAPI propio que está vinculado a la biblioteca PHP-Embed. Por lo tanto, durante el análisis y la migración, los equipos no solo deben transferir la configuración de FastCGI, sino también reasignar el enrutamiento, las definiciones de aplicaciones, la vinculación de módulos y las rutas de diagnóstico. Los errores no pueden atribuirse de forma generalizada a un servidor web anterior o a un grupo de FPM independiente.

Módulos de PHP, versiones y límites de configuración

Para PHP, una instalación de Unit necesita, además del núcleo, un módulo de lenguaje adecuado. Este módulo está vinculado a la versión de PHP utilizada y a la instalación de Unit. Si no había paquetes adecuados disponibles para el sistema operativo y la versión de PHP, la documentación describía cómo compilarlo uno mismo utilizando una instalación de PHP que proporcionara la SAPI «Embed». Esto aumenta considerablemente el esfuerzo necesario para las actualizaciones, las compilaciones reproducibles y el análisis de errores.

La configuración también sigue modelos diferentes. Unit agrupa los listeners, las rutas y las aplicaciones como datos JSON a través de su interfaz de configuración. PHP-FPM, por su parte, gestiona los grupos en archivos con formato php.ini. Esta diferencia va más allá de la sintaxis: en una pila FPM, las reglas del servidor web y las definiciones de los grupos PHP están separadas, mientras que Unit integra ambos elementos de forma más estrecha en una misma plataforma. Los planes de migración deben tener en cuenta esta estructura.

En cuanto a las directivas de PHP, Unit distingue entre las siguientes áreas: admin y usuario. Las opciones de administrador se corresponden con PHP_INI_SYSTEM y la aplicación no puede modificarlas en tiempo de ejecución; las opciones de usuario se corresponden con PHP_INI_USER. Sin embargo, Unit no amplía el ámbito permitido de una directiva de PHP. El modo de configuración de PHP sigue determinando si una configuración puede establecerse de esta manera o modificarse mediante el código de la aplicación.

Advertencia: La compatibilidad con PHP 8.5 indicada en Unit 1.35.0 solo confirma que esta versión se admite en la última versión estable. No supone ninguna garantía de futuras correcciones de seguridad ni adaptaciones del módulo Unit-PHP. Por lo tanto, para el funcionamiento de los sistemas existentes, se deben documentar como dependencia conjunta la etiqueta exacta de Unit, la versión de PHP, el origen del módulo y una ruta de sustitución probada.

Configurar el enrutamiento de PHP y el Front Controller

Una configuración de unidad conecta un listener con rutas y una aplicación. Para una demostración local, el listener puede estar configurado exclusivamente en 127.0.0.1:8080 escuchar. Una ruta intenta primero encontrar el archivo solicitado en /srv/example-app/public servir de forma estática. Los archivos PHP quedan excluidos de este servicio mediante la exclusión por tipo MIME y se transfieren a la aplicación PHP; lo mismo ocurre con los archivos que no existen. De este modo, los archivos públicos y la ejecución de la aplicación se mantienen como pasos separados y trazables.

En la aplicación se establece root establece el directorio de documentos, mientras que type: php que selecciona el entorno de ejecución de PHP. Con script: index.php cada solicitud que se transmite a la aplicación se redirige a este script. Esto equivale a lo siguiente: Controlador frontal de muchos frameworks de PHP: la aplicación analiza por sí misma la ruta original y decide, por ejemplo, a qué controlador o página de error dirigirse.

Sin esa actitud script Procesa rutas de scripts basadas en URI. Esto puede resultar adecuado para aplicaciones más antiguas en las que se deba acceder directamente a los archivos PHP, pero requiere una delimitación cuidadosa de las rutas a las que se puede acceder. targets Además, permiten definir subáreas con un comportamiento diferente en cuanto a «root», «script» o «index». Por lo tanto, no sustituyen al enrutamiento, sino que constituyen una forma de definir varias reglas de aplicación de manera específica.

El siguiente ejemplo es un archivo de configuración JSON para una demostración local, no para un servicio público. No contiene nombres de dominio, ni datos de TLS ni de acceso. Antes de implementarlo, es necesario comprobar los permisos del archivo, la compatibilidad con PHP realmente instalada y el método previsto por Unit para importar la configuración.

{
  "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"
    }
  }
}

El orden es fundamental: el entrega estática El paso «share», que sirve para ello, se intenta antes del «fallback», pero excluye expresamente los archivos PHP. Estas solicitudes y los archivos que no existen terminan en index.php; gracias a ello, también funcionan las URL descriptivas como /artikel/beispiel sin un archivo con el mismo nombre. La necesidad de reglas adicionales para los directorios de subida, las áreas de administración o los archivos PHP a los que se puede acceder directamente depende de cada aplicación y no debe deducirse de forma generalizada a partir de esta demostración.

Comparar modelos de procesos y el presupuesto RAM

PHP-FPM controla los trabajadores de cada grupo mediante los modos static, dynamic y ondemand. En Unit, en cambio, el número de procesos se modela dentro de la aplicación. Una configuración dinámica de Unit limita con processes.max el número total y se mantiene al día con processes.spare Procesos en segundo plano; idle_timeout elimina los procesos inactivos que sobran.

Por lo tanto, estos términos no son intercambiables de forma directa. En concreto, una configuración predeterminada documentada no es un valor adecuado para un sitio web. Tanto pm.max_children así como processes.max limitan el trabajo paralelo de PHP y, si los valores son demasiado bajos, pueden generar colas. Por el contrario, unos valores demasiado altos compiten por la memoria con el sistema operativo, la base de datos, la caché y otros servicios.

A Presupuesto de RAM En un primer momento, se trata únicamente de un modelo de planificación: del espacio de almacenamiento total se deducen las reservas para el sistema operativo, la base de datos, la caché y otros procesos. El valor restante se divide entre una estimación conservadora de los requisitos de memoria por cada trabajador PHP. A modo de ejemplo, 1.200 MiB para PHP dividido entre 120 MiB por trabajador da como resultado, matemáticamente, diez trabajadores; ambos valores son meros ejemplos elegidos a propósito, no constituyen una medición ni una recomendación de configuración.

El resultado es una Límite superior y un punto de partida para la observación, no la configuración adecuada. Lo decisivo son los picos reales, las colas de espera, los errores de respuesta y los requisitos de memoria tanto en condiciones de carga típica como de carga elevada. Para la deducción metódica y el reajuste de pm.max_children La contribución interna ayuda Calcular correctamente el número de procesos hijos de PHP-FPM. En Unit se aplica el mismo principio, aunque los parámetros tengan otros nombres.

Advertencia: Establecer límites del proceso basándose únicamente en cifras ajenas a menudo solo sirve para posponer los problemas. Solo un presupuesto de memoria bien definido y un seguimiento constante permiten determinar si un límite máximo de trabajadores se adapta a la aplicación, a sus extensiones y a los servicios que se ejecutan simultáneamente.

Evaluar modelos operativos para el alojamiento de PHP

La tabla clasifica las arquitecturas, no la velocidad ni el consumo de memoria. Lo que más habla a favor del nuevo alojamiento PHP en la configuración NGINX-PHP-FPM es, sobre todo, la clara separación: el servidor web se encarga del HTTP, el proxy y los contenidos estáticos, mientras que PHP-FPM gestiona los trabajadores de PHP por cada grupo. Estas responsabilidades facilitan la evaluación por separado de las configuraciones, los mensajes de error y las actualizaciones.

Unit ha logrado integrar listeners, enrutamiento, archivos estáticos y aplicaciones en una única plataforma, además de ser compatible con otros entornos de ejecución además de PHP. Este enfoque multilingüístico puede explicar por qué un entorno ya existente ha optado por Unit. Sin embargo, para ofertas basadas exclusivamente en PHP, esto no supone una ventaja automática: no sustituye ni a la evaluación de las funciones necesarias ni a la comprobación de si el equipo podrá dominar de forma permanente la lógica de configuración y funcionamiento.

En la unidad 1.35.0, las funciones técnicas deben ser las siguientes: Estado de mantenimiento se separan. La fecha de lanzamiento indica la versión publicada y sus modificaciones; de ello se deduce que no se seguirá realizando ningún mantenimiento del proyecto, que ya se ha archivado. A la hora de tomar una nueva decisión, este límite tiene más peso que un número menor de componentes visibles. Sin embargo, en el caso de una instalación ya existente, es motivo para documentar las dependencias y una ruta de migración.

Apache con PHP-FPM no es, en términos generales, una alternativa mejor o peor, sino una opción cuando existen requisitos específicos para Apache. La elección debe basarse en la facilidad de mantenimiento, las versiones de PHP disponibles, los procesos de aplicación de parches, los conocimientos del equipo y el plan de contingencia. Sin perfiles de carga comparables ni una metodología de medición documentada, no es posible establecer una clasificación fiable del rendimiento a partir de esta descripción general de la arquitectura.

Utilizar la unidad de forma segura en el parque de máquinas

Una instalación existente de Unit debería registrarse en primer lugar como sistema actual, y no como plantilla para una nueva plataforma. Lo decisivo es la versión que se utiliza realmente, las aplicaciones conectadas y sus dependencias. El hecho de que Unit siga siendo técnicamente ejecutable no cambia el hecho de que el proyecto se haya archivado; por lo tanto, el funcionamiento y la sustitución deben planificarse conjuntamente.

En WordPress, Joomla o Drupal, el Controlador frontal El punto clave: las rutas que no corresponden a archivos existentes deben dirigirse al archivo de inicio central de PHP, mientras que los archivos existentes pueden servirse directamente. La guía de WordPress para Unit ilustra este principio de enrutamiento, incluido el tratamiento de los archivos PHP y /wp-admin/. En el caso de un CMS ya existente, esta puede ser una configuración razonable; sin embargo, para una nueva instalación, esto no supone ninguna recomendación para Unit.

Varias aplicaciones pequeñas escritas en PHP, Python, Ruby o Node.js pudieron agruparse en una plataforma común mediante Unit Listener, rutas y entornos de ejecución. Esto puede explicar por qué una arquitectura ya existente se decantó en su momento por Unit. Sin embargo, en el caso del alojamiento exclusivamente en PHP, esta capacidad multilingüe no es un fin en sí misma: los componentes independientes y bien mantenidos pueden resultar más fáciles de mantener a largo plazo, a pesar de las interfaces adicionales.

Una implementación de contenedor congelada requiere un inventario especialmente preciso. Para ello, documenta la etiqueta exacta de la unidad, la versión de PHP, el módulo de idioma instalado, la imagen base y la configuración completa. Añade, además, las fuentes de las imágenes y los paquetes, el proceso de aplicación de parches, así como una ruta de migración y una ruta de contingencia que hayan sido probadas. La compatibilidad con PHP de una versión concreta de Unit no garantiza que el módulo correspondiente vaya a recibir correcciones de seguridad en el futuro.

NGINX puede situarse antes de Unit, por ejemplo, cuando se desea mantener una capa de NGINX ya existente o cuando se quiere redirigir de forma específica el tráfico. La documentación de Unit también menciona esta integración en relación con la protección del control socket. Sin embargo, no resuelve el problema del estado «archivado» y crea un servicio adicional con su propia configuración, registro y responsabilidad de actualización. Por lo tanto, hay que sopesar concretamente los beneficios frente a este esfuerzo operativo.

Tiempos de espera, registros y procesos bloqueados

Los límites del proceso no constituyen un diagnóstico de errores. Con limits.requests Unit puede sustituir un proceso de aplicación tras un número determinado de solicitudes procesadas. Esto puede limitar temporalmente el uso acumulado de memoria, pero no elimina ni las fugas de memoria, ni las estructuras de datos de tamaño excesivo, ni las llamadas externas que provocan bloqueos. Por lo tanto, un reinicio periódico no debe considerarse prueba de que el código de la aplicación sea estable.

Con limits.timeout Unit finaliza una solicitud con un código HTTP 503 una vez transcurrido el tiempo configurado. Se trata de un límite de protección visible para solicitudes individuales, pero no constituye una protección completa contra los trabajadores bloqueados: según la documentación, Unit no detecta los procesos bloqueados, que pueden permanecer en el grupo de procesos. Un tiempo de espera más largo solo pospone este problema, mientras que uno más corto puede interrumpir operaciones que, por lo general, son lentas.

• Registrar el estado HTTP, las rutas afectadas, los intervalos de tiempo y la frecuencia antes de modificar los valores límite.
• Combinar los registros de acceso, de errores y de la aplicación basándose en las marcas de tiempo; en el caso de PHP-FPM, un «slowlog» puede proporcionar información adicional sobre la pila.
• Comprobar la CPU, la memoria RAM, las entradas y salidas, las conexiones de red, así como el estado y el número de procesos.
• A continuación, analiza el código, las consultas a la base de datos, los accesos al sistema de archivos y los servicios externos como posibles causas.
• Solo cuando se conozcan la causa y el perfil de carga, se deben ajustar de forma específica los tiempos de espera, los límites de los procesos o las reglas de reinicio.

Por lo tanto, un código HTTP 503 puede indicar que se ha agotado el tiempo de espera, pero también puede deberse a componentes previos u otros errores. No debes gestionar las solicitudes PHP largas y recurrentes basándote únicamente en el número de trabajadores. La guía sobre el El «slowlog» de PHP-FPM y el análisis de las causas de las solicitudes lentas muestra cómo se pueden relacionar las trazas de la pila con los datos de la solicitud; esta misma lógica de causa y efecto también resulta útil en un análisis de inventario de unidades.

Los síntomas sin una conclusión clara son especialmente críticos: tiempos de espera cada vez mayores, procesos ocupados de forma permanente o ausencia de avances en los registros. En esos casos, el estado del proceso y las dependencias son más importantes que un aumento general del tiempo de espera. Comprueba, por ejemplo, si un worker de PHP está a la espera de una E/S de la base de datos, del DNS, del sistema de archivos o de la red. Solo el bloqueo concreto determina si lo adecuado es una corrección del código, un ajuste de los recursos o un reinicio controlado.

Decisión sobre los sistemas nuevos y antiguos

Para los nuevos entornos de alojamiento PHP, un servidor web bien mantenido con PHP-FPM es la opción estándar más lógica. PHP-FPM forma parte de la distribución habitual de PHP y ofrece opciones documentadas de gestión de pools y procesos. En el caso de Unit, sin embargo, la cuestión pasa de la mera funcionalidad a la facilidad de mantenimiento: la instalación puede seguir funcionando, pero el estado archivado del proyecto aumenta el riesgo de una dependencia a largo plazo.

En el caso de los sistemas Unit ya existentes, una decisión fundamentada comienza con un inventario. Comprueba el estado de mantenimiento y la capacidad de aplicación de parches del sistema operativo, PHP y la imagen base, la compatibilidad del módulo de idioma instalado, los conocimientos operativos disponibles y los servicios asociados. Igualmente importantes son las configuraciones exportables, un proceso de reversión reproducible y un sistema de destino al que se puedan transferir paso a paso el enrutamiento, los ajustes de PHP y las implementaciones.

Una migración no requiere un plazo general preestablecido, sino un orden de prioridades. Las aplicaciones expuestas a Internet, las imágenes que no se pueden actualizar, los módulos de origen desconocido y las aplicaciones críticas para el negocio que carecen de un plan de contingencia deben ser las primeras en recibir atención. A continuación, las aplicaciones se pueden agrupar según su complejidad y sus dependencias. El funcionamiento en paralelo durante una transición controlada puede reducir los riesgos, siempre que se hayan definido previamente el almacenamiento de datos, las sesiones y la ruta de retorno.

El API de control Se trata de un acceso administrativo y no de un punto de acceso habitual de un sitio web. Unit documenta para usted un socket de dominio Unix y justifica su uso por motivos de seguridad. Establezca permisos de archivo restrictivos y accesos administrativos claramente delimitados; si fuera de acceso público, en caso de que un atacante lograra acceder, se le abrirían amplias posibilidades para modificar la configuración.

El proceso práctico de migración no termina con una nueva configuración de procesos. Transfiere, aplicación por aplicación, la versión de PHP, las extensiones, las variables de entorno, los permisos de los archivos, las reglas de enrutamiento y la observabilidad al sistema de destino. Para ello, compara las respuestas esperadas y los casos de error, en lugar de extraer conclusiones generales sobre la velocidad. De este modo, lo que era una carga heredada no planificada se convierte en un proceso documentado Estrategia de sustitución con decisiones técnicas justificadas.