Nginx y PHP-FPM: 502 por permisos en el socket, ¿cómo arreglarlo?

Te apareció un 502 de Nginx con un error connect to php-fpm.sock failed (13: Permission denied)? A mí me pasó y es más común de lo que crees después de actualizar PHP. Este mensaje suele aparecer después de una actualización de PHP, especialmente cuando pasas de una versión antigua a una más reciente (como de PHP 5.x a 7.x, o incluso dentro de la misma 5.x si trajo un parche de seguridad).

Lo que pasó es que PHP, por temas de seguridad, empezó a ser más estricto con los permisos del socket donde se comunica con Nginx. Antes, quizás el socket tenía permisos más laxos, pero con la actualización, PHP-FPM se pone más celoso y no deja que Nginx acceda si no cumple ciertas condiciones.

Yo me di un par de cabezazos con esto en un proyecto personal hace un tiempo. Recuerdo que estuve un par de horas una tarde de sábado, pensando que era algo de Nginx, hasta que caché que PHP-FPM era el culpable. De hecho, me costó un PR en un cliente porque mi configuración local no lo tenía en cuenta y no pude levantar el entorno.

La solución más directa, que verás en muchos lados y es la que la mayoría aplica para salir del paso, es revisar el archivo de configuración de tu pool de PHP-FPM. Generalmente está en /etc/php/X.Y/fpm/pool.d/www.conf (cambia X.Y por tu versión de PHP, por ejemplo, 7.4 o 8.2).

Ahí, tienes que asegurarte de que Nginx (o el usuario con el que corre tu servidor web) tenga los permisos para leer y escribir en ese socket. Esto se hace configurando listen.owner, listen.group y, a veces, listen.mode. Muchas guías te dirán que descomentes o añadas estas líneas:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Después de eso, reinicia PHP-FPM: sudo service phpX.Y-fpm restart.

Ahora, ojo que esta solución, si bien funciona, en estricto rigor puede abrir una pequeña brecha de seguridad si no manejas bien tus usuarios. El listen.mode = 0660 es lo que le da permisos de lectura/escritura al grupo, y si ese grupo no es exclusivo para el usuario de Nginx, podrías tener problemas. No es que vayas a tener un hacker al minuto, pero la idea es que cada proceso tenga los mínimos permisos necesarios.

Mi preferencia es ser un poco más restrictivo. Si sabes que Nginx corre bajo el usuario www-data (que es lo más común en Debian/Ubuntu), puedes simplemente asegurarte de que el socket sea propiedad de ese usuario y grupo, sin necesidad de tocar listen.mode. Así evitas darle permisos excesivos al archivo del socket. Solo necesitas estas dos líneas:

listen.owner = www-data
listen.group = www-data

Con esto, Nginx como www-data tendrá acceso al socket sin que otros usuarios del mismo grupo (si los hubiera) tengan permisos de escritura. Siempre verifica que Nginx efectivamente corre como www-data con un ps aux | grep nginx.

¿Cuál usar? Depende del contexto. Si estás en un entorno de desarrollo o un servidor con poca exposición y quieres salir del paso rápido, la primera opción con listen.mode funciona. Pero si buscas una configuración más robusta y segura, o si tienes varios servicios corriendo bajo diferentes usuarios, lo ideal es solo definir listen.owner y listen.group. La sobreingeniería me frustra, pero a veces, un pequeño ajuste de permisos te ahorra un dolor de cabeza futuro.