HTTP 502 sol indicar que un proxy o servidor web no ha obtingut una resposta vàlida del servei posterior, sovint PHP-FPM. WordPress pot generar la càrrega que desencadena la fallada, però el 502 neix una capa abans.
Conserva les capçaleres de resposta i l’hora abans de reiniciar serveis. Un reinici pot recuperar el web i, alhora, eliminar les pistes d’un procés caigut o d’un pool de workers exhaurit.
Identifica qui ha generat el 502
Revisa les capçaleres i el disseny del cos per distingir Cloudflare, un proxy de l’allotjament, Nginx, Apache o un balancejador. Si hi ha una CDN, prova l’origen mitjançant un mètode autoritzat pel proveïdor.
Registra:
estat públic i de l'origen
URL i durada de la petició
identificador de petició o Ray ID
registres del servidor i PHP a la mateixa hora
si funcionen els fitxers estàticsNo exposis la IP d’origen ni afebleixis el tallafoc per fer la prova.
Compara peticions estàtiques i PHP
Demana una imatge o CSS coneguts i després wp-login.php i la pàgina afectada. Si els recursos estàtics funcionen i totes les peticions PHP retornen 502, l’origen apunta a PHP-FPM, el seu socket o el servei upstream.
Si només falla una ruta de WordPress, investiga la càrrega PHP i la durada d’aquella petició. Si fallen tots els webs del compte, és més probable un problema de capacitat compartida o de configuració del servei.
Comprova dominis veïns només quan hi estiguis autoritzat.
Revisa els registres del proxy i PHP-FPM
Busca missatges com «connection refused», «upstream prematurely closed connection», «no live upstreams», sortida d’un worker, error de segmentació o timeout.
Relaciona el PID i l’hora entre registres. Un error fatal de PHP acostuma a produir una resposta d’aplicació; un procés que cau pot deixar el proxy sense cap capçalera vàlida.
Protegeix els registres perquè les rutes i els paràmetres de petició poden contenir informació sensible.
Comprova si falten workers de PHP
Tots els processos poden estar ocupats amb peticions lentes, fent que les connexions noves esperin o fallin. Revisa processos actius i màxims, llargada de la cua, CPU i RAM.
Augmentar el nombre de workers consumeix més memòria. Calcula el pic per procés i la capacitat total del servidor abans de modificar el pool.
Localitza la ruta, consulta o API externa que manté els processos ocupats. Afegir capacitat no ha d’ocultar una feina sense límits.
Verifica el socket o el port
Nginx o Apache s’han de connectar al mateix socket Unix o port TCP on escolta PHP-FPM. Després de canviar la versió de PHP, l’antiga ruta del socket pot deixar d’existir.
Compara el propietari i els permisos del socket amb l’usuari del servidor web. No utilitzis permisos d’escriptura universal com a reparació.
En cPanel o Plesk, fes servir els controls compatibles del controlador PHP perquè el panell no sobreescrigui més tard la configuració.
Busca caigudes de processos
Consulta els registres del sistema i PHP per detectar processos finalitzats per falta de memòria, errors de segmentació o extensions defectuoses. El sistema operatiu pot matar PHP sense deixar cap entrada a WordPress.
Desactiva o actualitza l’extensió responsable mitjançant els controls de l’allotjament després de reproduir el problema en proves. No retiris de producció extensions necessàries sense revisar quins webs en depenen.
Comprova espai i inodes: els serveis també fallen quan no poden escriure sockets o registres.
Separa el 502 de la CDN del de l’origen
Cloudflare pot retornar 502 si no pot connectar amb l’origen o si aquest envia una resposta invàlida. Relaciona l’identificador de l’esdeveniment amb el registre d’accés del servidor.
Si no hi ha cap petició a l’origen, revisa DNS, ruta de xarxa, tallafoc o TLS entre l’edge i el servidor. Si l’origen registra el seu propi 502, el problema és a la pila local.
No obris una regla àmplia de tallafoc sense comprovar els requisits de xarxa vigents del proveïdor.
Repara i verifica amb càrrega
Corregeix el socket, el servei PHP, la capacitat del pool, l’extensió que cau o la ruta lenta demostrada per les proves. Reinicia només el servei necessari i documenta’n l’estat anterior.
Repeteix peticions PHP, accions administratives i la ruta original mentre observes els workers. El manteniment recurrent hauria d’alertar per cues de PHP, caigudes de processos i taxa de 502 per actuar abans que les fallades intermitents es converteixin en una caiguda completa.