Me han preguntado varios lectores sobre el mismo problema: se encuentran con un error 502, Bad Gateway o puerta de enlace, devuelto por un servidor Nginx. ¿Dónde se produce este error? Pues en el punto en que el servidor Nginx se comunica con otra aplicación o servicio ¿Y por qué se da? Por muchos motivos: que uno de los dos esté caído, que no se «aclaren» con el protocolo (mala configuración), etc. Puede darse cuando Nginx funciona como proxy de Apache, con problemas derivados de la configuración del buffering o del tiempo de espera de respuesta, cuando Nginx funciona como puerta de enlace con otra aplicación o cuando Nginx funciona con el daemon PHP-FPM.

Lo primero, tanto en el caso del daemon de PHP-FPM, como en el de usarlo como proxy de Apache o como puerta de enlace para otro servicio es reiniciar dichos servicios. En la mayoría de los casos el error surge porque el servicio se ha detenido por algún motivo, y con el reinicio se soluciona. En caso de que ocurra reiteradamente entonces investigad por qué ese servicio «casca» de forma tan habitual. Seguramente en los logs del servidor esté mucha de la información que necesitaréis para encontrar la solución.

Aunque la caída del servicio es lo más habitual no es la única opción. En otro artículo ya hablamos de configurar los valores del tiempo para timeout de FastCGI en IIS, en Nngix podemos hacer esto editando el archivo nginx.conf, dentro del bloque http (esto es un ejemplo copiado de la documentación oficial de Nginx, cada caso deberá adaptarse a sus necesidades):

http {
...
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
...
}

En caso de que estéis usando Nginx como proxy deberéis añadir unas líneas como estas en el archivo nginx.conf:

proxy_connect_timeout       600;
proxy_send_timeout          600;
proxy_read_timeout          600;
send_timeout                600;

Para el caso de PHP-FPM debes asegurarte, revisando el fichero http://www.conf de configración de Nginx, de que está bien configurado el puerto en que el servicio debe estar «a la escucha». Generalmente es una de estas dos opciones:

listen = /var/run/php5-fpm.sock
#o si no
listen = 127.0.0.1:9000

Si no está configurado así probad una de esas dos opciones y reiniciad el servicio.

Otra causa de este problema venía derivado del uso de APC Cache, y se solucionaba dejando de usarlo y pasándose a Xcache. De esto hará cosa de un año, puede que a día de hoy ya no genere problemas, pero a saber.

Y a más de uno le ha comenzado el problema tras actualizar algunos paquetes de PHP en su servidor. El problema viene porque en esa actualización los permisos de lectura-escritura-ejecución del socket han sido modificados, y el servidor no puede acceder a ellos porque no está en el mismo grupo. Para solucionar esto tienes que tocar varios archivos. El primero nginx.conf, donde comprobaremos que esto esté tal cual:

user nginx;

Luego nos vamos a /etc/php-fpm.d/www.conf y lo configuramos así

listen = /tmp/php5-fpm.sock
listen.owner = nginx
listen.group = nginx

Y tras esto reiniciamos tanto el servicio de nginx como el de php-fpm.

Estos son los principales problemas y soluciones que he ido encontrando por la red, espero que os sirvan de ayuda.