Este artículo puede ayudarlo a solucionar problemas relacionados con errores 504/502/gateway. Al solucionar problemas, puede ser útil comprender cómo funciona el procesamiento entre nginx y PHP, que a menudo se usa para el alojamiento de aplicaciones web de alto rendimiento, como WordPress.
Errores comunes que ocurren relacionados con esta configuración:
- 504 Tiempo de espera de puerta de enlace
- Tiempo de espera de la puerta de enlace (504)
- Error HTTP 504:tiempo de espera de puerta de enlace
- Error de tiempo de espera de la puerta de enlace
- 502 mala puerta de enlace
- Puerta de enlace incorrecta
¿Por qué hay una puerta de enlace?
Cuando llega una solicitud a través de un navegador web, primero llega a nginx, nuestro servidor web front-end liviano, y luego nginx decide a dónde debe ir la solicitud desde allí, como un conductor de tren. Nginx generalmente manejará solicitudes más simples de recursos (como imágenes y páginas en caché) por sí mismo, mientras envía solicitudes de páginas dinámicas (como una página de administración de WordPress o un carrito de compras) a apache (para procesamiento de modsecurity y .htaccess) y luego a PHP. Se ve así:
nginx -> apache -> php -fpm
nginx actúa como una puerta de enlace que envía los tipos correctos de solicitudes a apache y PHP. Si hay un problema 'aguas abajo', como con apache o php, obtendrá una puerta de enlace error, como 502 Bad Gateway o 504 Tiempo de espera de puerta de enlace .
Este problema podría ser un código de ejecución extremadamente lento o un problema real con el servicio apache o PHP, aunque con nuestro alojamiento, el problema suele ser un problema de código.
Use los registros del servidor para obtener más información
Para ayudar a identificar la causa del error de la puerta de enlace, verifique los registros para ver qué se informa. a veces, los registros simplemente informan un error 502 o 504, tal como está viendo en el navegador, lo que no será útil. Pero a veces es posible que vea un error o una advertencia registrados justo antes del error de Gateway que indicará qué complemento o tema está causando el error.
Puede aprender a usar Plesk para ver registros aquí. Si puede usar esos errores para llegar al fondo del problema, ¡entonces definitivamente hágalo! De lo contrario, siga leyendo para conocer formas adicionales de reducir las cosas.
¡Ayuda! ¡Ni siquiera puedo acceder al área de administración de mi sitio web! (Como wp-admin para WordPress)
A veces, cuando recibe errores constantes de Gateway, no puede acceder al área de administración de su sitio web (como wp-admin de WordPress), pero necesita hacerlo para ayudar a solucionar este problema. La única forma de recuperar el acceso es bloquear el acceso hasta que pueda resolver el problema.
Para bloquear el acceso, puede proceder de dos maneras:1) bloquear el acceso a la parte particular del sitio que está consumiendo recursos, o 2) puede bloquear el acceso a todas las direcciones IP, excepto la suya, temporalmente para recuperar el acceso.
Para bloquear el acceso a todas las direcciones IP excepto a la suya (más fácil)
Inicie sesión en Plesk y visite la configuración de Apache y nginx página. En "Denegar acceso al sitio ” ingrese un valor personalizado y conviértalo en "* “ (sin las comillas). Luego, en "Excluyendo ” ingrese su propia dirección IP y guarde los cambios. Es posible que deba esperar hasta 3 minutos después de guardar los cambios para que el servidor se reinicie (~1 min) y para que cualquier proceso de PHP que se estaba ejecutando alcance su tiempo de espera (~2 min).
Asegúrate de eliminar este bloqueo cuando termines de solucionar el problema.
Para bloquear el acceso a la solicitud de uso intensivo de recursos (más complejo)
Si solo hay una página o recurso en el sitio que está creando este problema (como una sola página que se carga lentamente), use los registros para identificar ese URI de solicitud en particular. Luego agregue el siguiente fragmento de código en la parte superior de su archivo .htaccess para bloquear el recurso problemático (aunque sea temporalmente) para que pueda acceder al panel de administración. Reemplazar filename\.php con el URI de solicitud real que se muestra en los registros (esta es la parte que viene después del dominio). Si hay puntos en la ruta del archivo, asegúrese de anteponerlos con una barra invertida como se ve en el ejemplo.
<FilesMatch filename\.php> Order Allow,Deny Deny from all </FilesMatch>
Motivos comunes de errores de puerta de enlace
La posible solución rápida:
Si el problema fue solo una vez (como si ejecutara un script y no dejara de ejecutarse), la solución es reiniciar directamente los servicios subyacentes , lo que obliga a que el script finalice.
Si no tiene acceso de raíz al servidor o acceso de administrador a Plesk, a menudo puede activar dicho reinicio al realizar cambios en la configuración de su sitio web en Plesk. Por ejemplo, intente ir al botón "Configuración de PHP" para su dominio, luego haga cualquier pequeño cambio allí (como aumentar la memoria de 32 MB a 48 MB) y luego guarde sus cambios. ¡Esta actualización desencadena un reinicio del procesamiento de apache y PHP y podría resolver su error!
Los cambios pueden demorar hasta 3 minutos (o más, según su proveedor) para que surtan efecto.
Si eso no funciona o el problema vuelve, deberá revisar las siguientes causas/síntomas posibles para determinar cuál se adapta mejor a su caso.
Estoy tratando de ejecutar un informe grande, de exportación o de importación que lleva un rato
Si su sitio se ejecuta con normalidad, pero cada vez que intenta ejecutar una exportación, importación o informe grande para los datos de su sitio, obtiene errores de puerta de enlace, esto se debe a que está alcanzando los tiempos de espera antes de que se pueda procesar el informe. Aunque no hay una manera súper simple de arreglar esto a largo plazo, hay una manera de arreglarlo a corto plazo:aumentar temporalmente los tiempos de espera.
Puede hacer esto en el panel de control de Plesk siguiendo los pasos de nuestra guía sobre cómo cambiar una configuración de PHP. Deberá cambiar los valores (están en segundos) para max_execution_time y max_input_time a algo así como 300 para permitir que los procesos se ejecuten durante 5 minutos. No olvide volver a cambiar esos valores una vez que haya completado su acción de ejecución prolongada.
¿Por qué no puedes aumentar los tiempos de espera de forma permanente?
Técnicamente es posible, sin embargo, aumentar los tiempos de espera de forma permanente muy probablemente afectará negativamente el rendimiento de su sitio. . Los tiempos de espera predeterminados son valores como 30 o 60 segundos con intención:si un proceso tarda tanto en completarse y activa demasiados procesos de ejecución prolongada, pueden consumir todos los espacios de procesamiento disponibles y hacer que todo su sitio no funcione para todos los visitantes. Por lo tanto, mantener los valores de tiempo de espera entre 30 y 60 segundos garantiza que esto solo suceda durante ese tiempo como máximo.
Casi todas las solicitudes a mi sitio o página de inicio tardan mucho tiempo en procesarse
Sabrá si este es el problema si una o más páginas del sitio tardan más de ~10 segundos en comenzar a cargarse, y su navegador no muestra nada hasta que haya pasado ese período de más de 10 segundos.
Hay dos razones comunes por las que esto puede ocurrir:
2) Solicitudes de recursos externos lentas o que no responden: Algún código PHP intenta comunicarse con un recurso externo (alojado en otro lugar) que tarda demasiado en responder o no responde en absoluto. Para resolver problemas con los recursos externos, deberá investigar qué partes del código PHP de su sitio web (código personalizado o complementos/código de tema) intentan recuperar recursos externos. Este es más comúnmente un código que se conecta a un servicio de terceros, como un procesador de pagos o la recuperación de datos meteorológicos a través de una API o raspado. He aquí algunos ejemplos:
- Algunas pasarelas de pago o servicios de API XML usan puertos no estándar (aunque es muy poco común en estos días, ya que los puertos estándar se usan con mucha más frecuencia ahora). Si no está utilizando el puerto 80 o 443, es probable que intente comunicarse en un puerto bloqueado y falle.
- Se sabe que los widgets de Twitter más antiguos recuperan tweets usando un código de back-end y luego las fallas para conectarse a los servidores de Twitter causan bloqueos como este. Esto no se aplica a las incrustaciones de feeds de Twitter que funcionan a través de Javascript de forma asíncrona.
Si está utilizando WordPress o cualquier otro CMS con complementos, asegúrese de desactivar cualquier complemento que pueda comunicarse externamente para ver si resuelve el problema.
Si no puede determinar intuitivamente qué complemento podría tener la falla, entonces su opción restante es la solución exhaustiva de problemas. Tenemos una guía para la solución exhaustiva de problemas con WordPress aquí.
Causa:Se necesitan demasiados procesos PHP para atender las solicitudes
Si su sitio requiere una gran cantidad de procesos de PHP debido a una gran cantidad de tráfico que crea solicitudes de procesamiento dinámico, entonces su objetivo principal debe ser reducir la cantidad de procesamiento dinámico que debe ocurrir en cada carga de página. Así es como:
- Si usa WordPress, consulte aquí para obtener información sobre cómo instalar y optimizar su caché.
- Si ya tiene habilitado el almacenamiento en caché, el siguiente paso es detectar y reducir los casos en los que se produce el procesamiento dinámico.
Causa:Búferes limitados
Los procesos de Apache o PHP pueden estar generando tamaños de datos más grandes de los que nginx puede procesar. Dado que tanto apache como PHP necesitan pasar estos datos a través de nginx para llegar al visitante del sitio web, se genera un error 502 que indica "Encabezado demasiado grande enviado en sentido ascendente". Hemos visto este error con clientes que usan el complemento de WordPress OptInMonster, sin embargo, cualquier software podría hacerlo.
Nuestro alojamiento compartido ya debería estar optimizado con búferes más grandes para nginx, sin embargo, si tiene su propio VPS o no está alojado con nosotros, deberá aplicar estos valores usted mismo a la configuración de nginx:
fastcgi_buffers 128 4096k; fastcgi_buffer_size 4096k;
Esto le dice a nginx que está bien que acepte encabezados grandes (4 MB). Puede insertarlos en un archivo como:/etc/nginx/conf.d/increase_buffers.conf luego reinicie nginx para aplicar los cambios. Ejemplo:
echo 'fastcgi_buffers 128 4096k; fastcgi_buffer_size 4096k;' > /etc/nginx/conf.d/increase_buffers.conf
Causa:PHP-FPM mal configurado o necesita ajuste (VPS/servidor dedicado solamente)
A veces, si recibe errores constantes de tiempo de espera de la puerta de enlace, y lo único que los soluciona es reiniciar PHP (como se describe anteriormente), o si está en un VPS y ve que sus procesos de PHP se ejecutan con una CPU alta y duran mucho más tiempo del que deberían (o los técnicos del servidor le han dicho que eso es lo que está sucediendo), deberá tomar algunas medidas para controlarlos.
Nota:si está en nuestro alojamiento compartido, nuestra configuración de PHP-FPM ya está optimizada para un entorno de alojamiento compartido y, por lo tanto, si experimenta errores de puerta de enlace, esta solución no se aplicará.
Las siguientes son algunas opciones que nos han funcionado, sin embargo, es muy importante tener en cuenta que estas son soluciones alternativas al problema real. Identificar el código que no responde lo suficientemente rápido y optimizar su rendimiento es la verdadera solución.
- PHP-FPM le permite ajustar PHP Process Manager (FastCGI Process Manager =FPM) realizando algunos cambios en Plesk. Si está utilizando el proceso PHP-FPM de estilo "bajo demanda", es posible que desee reducir la cantidad de solicitudes que maneja cada proceso antes de salir/reiniciar correctamente un nuevo proceso. Esto está etiquetado como pm.max_requests. Prueba 100 o 150 si tienes problemas de rendimiento
- Si sus procesos de PHP no están desapareciendo, es posible que deba *hacer* que dejen de funcionar. Hay un par de buenas maneras de hacer esto. Lo primero es establecer definitivamente un tiempo de espera inactivo para los procesos de PHP-FPM configurando pm.process_idle_timeout – intente establecerlo en 10 s (puede hacerlo en el campo debajo de la configuración de FPM.
- Si su PHP procesa todavía no se están muriendo, es posible que deba volverse aún más agresivo con ellos. Intente configurar request_terminate_timeout a unos segundos más que su configuración max_execution_time. Si max_execution_time no elimina el proceso, request_terminate_timeout ciertamente lo hará.
Si esta guía le resultó útil, consulte las otras guías y publicaciones disponibles. Si necesita un alojamiento web canadiense de alto rendimiento o un socio de alojamiento VPS, consulte nuestros servicios.