introducción
Cuando aparezca en su navegador el icono "502 Puerta de enlace defectuosa", esto suele significar que se ha producido un fallo en las comunicaciones internas del servidor web. ParaWordPressEn cuanto a los usuarios, el sitio web funciona sobre todo conNginxtal vezApacheentorno. Aunque ambos pueden tener errores 502, la causa raíz y los métodos de solución de problemas varían. Este artículo servirá como una guía de diagnóstico preciso para la solución de problemas basados en el software de servidor utilizado para restaurar rápidamente el acceso a su sitio web.

Capítulo 1: Comprender la naturaleza común de los errores 502
Antes de profundizar en las diferencias, debemos establecer una percepción uniforme: ¿qué es un error 502 Bad Gateway?
Por su propia naturaleza, un error 502 es unHTTPUn código de estado que indica que el servidor que actúa como puerta de enlace o proxy (es decir, el servidor web que se enfrenta directamente al usuario) recibió una respuesta no válida del servidor ascendente (es decir, el servicio back-end que realmente maneja la lógica de la aplicación). En pocas palabras, cuando un usuario visita su sitio WordPress, la solicitud llega primero a Nginx o Apache.
Posteriormente, este servidor web necesita pasar la petición al proceso que maneja PHP (más comúnmente PHP-FPM) para ejecutar el código del núcleo de WordPress, temas y plugins. Si este proceso de paso falla, o si PHP-FPM no devuelve ningún contenido válido, el servidor web lanza un error 502 al usuario.

Por lo tanto, ya sea Nginx o Apache, ambos juegan el mismo papel:intermediario de comunicacionesEl problema es que este "intermediario" no es el mismo que el "trabajador" back-end (el "trabajador"). El problema es que este "intermediario" y el "trabajador" back-end (el "trabajador") son el mismo.PHP-FPM) tiene un enfoque diferente del diálogo.
Capítulo 2: Resolución de errores 502 en un entorno Nginx
Nginx es conocido por su alto rendimiento y su arquitectura basada en eventos. Cuando se comunica con PHP-FPM, normalmente lo hace a través de un protocolo específico (FastCGI). Comprender esto es la clave para solucionar con éxito los problemas.
2.1 Examinar el registro de errores de Nginx para localizar pistas iniciales
El registro de errores de Nginx es el punto de partida para la investigación. La ubicación de los registros varía de un sistema a otro, con rutas comunes son /var/log/nginx/error.log. Examinar ese archivo, especialmente los registros cercanos al momento en que se produjo el error, es un primer paso crucial.

Las entradas más comunes en los registros de Nginx relacionadas con errores 502 incluyen:
conectar()failed: Esto significa que Nginx no pudo conectarse al grupo de procesos PHP-FPM especificado en la configuración.Guión principal desconocido: Esto significa que Nginx no pudo encontrar o ejecutar el script PHP especificado (por ejemplo.index.php).
2.2 Una investigación en profundidad de "connect() failed".
Cuando los registros muestran errores de fallo de conexión, el núcleo del problema es que la conexión física entre Nginx y PHP-FPM no pudo establecerse.
2.2.1 Verificando el Estado del Pool de Procesos PHP-FPM
Es posible que el servicio PHP-FPM no se esté ejecutando o se haya bloqueado. Su estado se puede comprobar mediante el siguiente comando:
sudo systemctl status php-fpm # Para sistemas que utilizan systemctl
# o
sudo service php-fpm status
Si el servicio no se está ejecutando, intente iniciarlo:sudo systemctl start php-fpm. Si el arranque falla, o si el servicio se bloquea repetidamente, debe comprobar la configuración y los registros del propio PHP-FPM.
2.2.2 Confirmación de los métodos de comunicación y autoridad
Nginx y PHP-FPM pueden comunicarse de dos maneras principales:Enchufe Unix tal vez Enchufe TCP/IP.

- Unix Socket Check: Si su configuración de Nginx utiliza algo como el método
fastcgi_pass unix:/var/run/php/php-fpm.sock;de instrucciones que deben comprobarse:- Si este archivo de socket existe:
ls -l /var/run/php/php-fpm.sock - El usuario en el que se ejecuta el proceso Nginx (normalmente el usuario
www-datostal veznginx) si tiene permiso para leer y escribir en el archivo del socket. Los errores de permiso son una causa común de fallo de conexión.
- Si este archivo de socket existe:
- Comprobación del socket TCP/IP: Si se configura como
fastcgi_pass 127.0.0.1:9000;Hay que comprobarlo:- Si PHP-FPM está escuchando en el puerto:
netstat -tulpn | grep 9000 - Si el cortafuegos del sistema está bloqueando la comunicación en este puerto en la dirección loopback local (127.0.0.1).
- Si PHP-FPM está escuchando en el puerto:
2.3 Agotamiento de recursos y bloqueo de procesos
Otra razón común para que Nginx devuelva 502 es que el proceso hijo PHP-FPM se agote mientras procesa la petición o termine por falta de recursos.

- Compruebe la configuración de los recursos PHP-FPM: Edite el archivo de configuración del grupo de procesos PHP-FPM (normalmente ubicado en el directorio
/etc/php/7.x/fpm/pool.d/www.conf(el número de versión puede ser diferente), preste atención a los siguientes parámetros:pm.max_hijos: Si el número de peticiones concurrentes excede este valor, las nuevas peticiones serán rechazadas, resultando en un 502.request_terminate_timeout: Si el tiempo de procesamiento de una sola petición PHP excede este valor de tiempo de espera, el proceso se verá forzado a terminar, muy probablemente resultando en un error 502. Es posible aumentar este valor adecuadamente, pero es más importante optimizar los scripts o consultas que tardan demasiado en ejecutarse.
Capítulo 3: Solución de errores del entorno Apache 502
Apache suele utilizarmod_phpo a través del módulomod_proxy_fcgicombinado con PHP-FPM para manejar las peticiones PHP. Este último (Apache + PHP-FPM) es cada vez más común en las implementaciones modernas, y nuestra solución de problemas se centrará en eso también.
3.1 Análisis de los registros de errores de Apache
De forma similar a Nginx, el registro de errores de Apache es la principal fuente de información. Sus rutas comunes son /var/log/apache2/error.log tal vez /var/log/httpd/error_log.
En los registros de Apache, es posible que vea entradas sobre errores de proxy, ya que normalmente se informan a través del comandomod_proxyse comunica con PHP-FPM.

3.2 Configuración del módulo proxy y problemas de permisos
Cuando se utiliza Apache como proxy para comunicarse con PHP-FPM, la configuración es significativamente diferente a la de Nginx.
3.2.1 Verificación de los módulos mod_proxy y mod_proxy_fcgi
Asegúrese de que los módulos de Apache necesarios están activados. Esto se puede comprobar mediante el siguiente comando:
sudo a2enmod proxy_fcgi # en sistemas Debian/Ubuntu
# o mire la salida httpd -M
3.2.2 Revisión de la configuración del host virtual
Apache normalmente define cómo enviar las peticiones PHP a PHP-FPM en su archivo de configuración de alojamiento web. un típico fragmento de configuración podría ser como este:
SetHandler "proxy:fcgi://127.0.0.1:9000"
# o use Unix Socket: SetHandler "proxy:unix:/var/run/php/php-fpm.sock|fcgi://localhost"
</FilesMatch
Se requiere confirmación:
SetHandlerLa ruta de la directiva (ya sea la ruta IP:Port o Unix Socket) es exactamente la misma que la dirección de escucha real de PHP-FPM.- Si se utiliza un socket Unix, el usuario de ejecución de Apache (normalmente el usuario
www-datostal vezapache) debe tener permisos de lectura y escritura en ese archivo de socket.
3.3 Conflictos entre módulos y limitación de recursos
Los conflictos entre módulos son un problema que requiere especial atención en el entorno Apache.

- Evitar conflictos entre módulos: Si ambos cargados
mod_php(tratamiento a la antigua) ymod_proxy_fcgi(procesamiento moderno), y mal configurados, pueden competir por los derechos de procesamiento sobre los archivos PHP, llevando a un comportamiento impredecible, incluyendo errores 502. Después de configurar PHP-FPM, normalmente debería deshabilitar la opciónmod_phpo asegurarse de que no interfiere con la nueva configuración del agente. - Ajuste los límites de recursos de Apache y PHP: Apache
Tiempo de esperay la directivatiempo_de_ejecución_máximopueden afectar a los scripts de larga ejecución. Del mismo modo, la configuración de recursos de PHP-FPM (como la directivapm.max_hijos) también se aplica a este entorno y debe ajustarse razonablemente a la carga del servidor.
Capítulo 4: Resolución de problemas y medidas preventivas comunes a todas las plataformas
Aunque Nginx y Apache están configurados de manera diferente, hay algunos pasos de solución de problemas que son de aplicación universal, ya que se dirigen a una corriente ascendente común - PHP-FPM y el propio WordPress.
4.1 Diagnosticando la salud de PHP-FPM
Independientemente del tipo de servidor web en el front-end, el estado de PHP-FPM es decisivo.

- Reinicie el servicio PHP-FPM: Como una forma rápida de recuperación, reiniciar PHP-FPM puede limpiar cualquier proceso muerto o fuga de memoria que pueda existir. Comandos como:
sudo systemctl restart php-fpm. - Analizar los registros de PHP-FPM: PHP-FPM tiene su propio archivo de registro separado (en el archivo de configuración del pool)
catch_workers_outputresponder cantandophp_admin_flag[log_errors]). Ver estos registros puede proporcionar información valiosa sobre la razón exacta por la que un script PHP falló, como el agotamiento de la memoria, el tiempo de ejecución o un error fatal.
4.2 Resolución de conflictos entre plugins y temas de WordPress
Los plugins o temas de WordPress defectuosos son un culpable común de la caída del proceso PHP.

- Accede al modo de solución de problemas: Acceda a los archivos de su sitio web a través de FTP o SSH.
- Cambie el nombre del directorio de plugins: comandante en jefe (militar)
wp-content/pluginsCambie el nombre del directorio aplugins.desactivados. Todos los plugins se desactivarán en este punto. - Consulte el sitio web: Actualice el frontend de su sitio. Si el error 502 desaparece, significa que el problema está causado por uno de los plugins. Puede reactivar los plugins uno a uno hasta encontrar el que causa el problema.
- Cambiar de tema: Si el problema no es del plugin, pruebe a cambiar el tema activo por el tema predeterminado de WordPress (por ejemplo, Twenty Twenty-Four) para descartar problemas de compatibilidad de temas.
resúmenes
El error 502 Bad Gateway, aunque molesto, no es imposible de rastrear. Para los usuarios de Nginx, la solución de problemas debe centrarse en las conexiones FastCGI a PHP-FPM, los permisos de los archivos de socket y los límites de recursos del proceso. Para los usuarios de Apache, es necesario revisar cuidadosamente el archivomod_proxy_fcgiconfiguración del agente, problemas de conflicto de módulos y permisos de archivos asociados.
Dominar este proceso de diagnóstico específico le permitirá mantener la calma la próxima vez que se enfrente a un error 502, localizar las lesiones y aplicar las correcciones como un médico de sistemas experimentado, restaurando en última instancia la salud y vitalidad de su sitio de WordPress.
| Contacte con nosotros | |
|---|---|
| ¿No puede leer el tutorial? Póngase en contacto con nosotros para obtener una respuesta gratuita. Ayuda gratuita para sitios personales y de pequeñas empresas |
Servicio de atención al cliente WeChat
|
| ① Tel: 020-2206-9892 | |
| ② QQ咨询:1025174874 | |
| (iii) Correo electrónico: info@361sale.com | |
| ④ Horario de trabajo: de lunes a viernes, de 9:30 a 18:30, días festivos libres | |
Enlace a este artículo:https://www.361sale.com/es/79935El artículo está protegido por derechos de autor y debe ser reproducido con atribución.





















![Emoji[wozuimei]-Photonflux.com | Servicio profesional de reparación de WordPress, en todo el mundo, respuesta rápida](https://www.361sale.com/wp-content/themes/zibll/img/smilies/wozuimei.gif)
![Emoticono [baoquan] - Photon Wave Network | Servicios profesionales de reparación de WordPress, cobertura mundial, respuesta rápida](https://www.361sale.com/wp-content/themes/zibll/img/smilies/baoquan.gif)

Sin comentarios