Un 502 es Nginx diciéndote que le pidió la página a otra cosa y recibió una respuesta que no pudo usar. Nginx sí está funcionando —si no, no verías nada en absoluto—, así que el fallo está detrás de él, casi siempre en PHP.

Averigua cuál de las cuatro es

Lee primero el registro de errores. Nombra la causa en una línea, y cada minuto que pasas adivinando es un minuto que no pasas leyéndolo.

tail -50 /var/log/nginx/error.log
  • connect() failed (111: Connection refused): PHP-FPM no está funcionando.
  • upstream timed out: PHP funciona pero tardó más que el tiempo límite.
  • recv() failed (104: Connection reset by peer): el proceso de PHP murió a mitad de la petición, normalmente por falta de memoria.
  • no live upstreams: al pool no le quedan procesos para responder.

PHP-FPM no está funcionando

  1. Compruébalo — systemctl status php8.3-fpm: un servicio detenido lo dice en la primera línea.
  2. Arráncalo — systemctl start php8.3-fpm
  3. Averigua por qué se paró — journalctl -u php8.3-fpm --since "1 hour ago": una línea mala en la configuración de un pool lo detiene al arrancar, y volverá a pararse.
Si arranca y se para de inmediato, ejecuta php-fpm8.3 -t. Valida los archivos de pool y nombra la línea que no le gusta.

PHP es demasiado lento para el tiempo límite

Por defecto PHP dispone de 60 segundos. Una importación lenta o una API externa que dejó de responder los supera, y Nginx devuelve un 502 en lugar de esperar eternamente.

location ~ \.php$ {
    fastcgi_read_timeout 300;
}
Subir el tiempo límite tapa el síntoma. Una página que necesita cinco minutos necesita una cola, no una espera más larga, y el visitante se ha ido mucho antes.

El proceso murió

Una petición que supera memory_limit mata su proceso, y Nginx ve la conexión reiniciada. El registro de errores de PHP nombra el archivo y la línea.

grep -i "allowed memory size" /var/log/php8.3-fpm.log | tail

El pool no tiene procesos

Todos los procesos están ocupados, así que una petición nueva no tiene adónde ir. Eso es un problema de capacidad, y el arreglo honesto es o menos peticiones lentas o más procesos, pero más procesos con la misma memoria solo mueven el fallo de sitio.

pm.max_children = 20
pm.max_requests = 500
En el alojamiento de EGPHP el pool se gestiona por ti y este caso se atiende antes de que lo veas. En un VPS el dimensionado es cosa tuya, y el número que importa es tu memoria dividida entre el tamaño medio de un proceso.