La sol·licitud loopback falla a WordPress: per què Salut del lloc no pot cridar la web

Què importa primer: WordPress usa loopback sol· licituds per a tasques programades, l’editor i operacions de fons. Ha fallat vol dir que el propi client HTTP del servidor no pot completar una sol· licitud al públic del lloc URL.

Què indica realment aquest símptoma

L’extrem frontal pot funcionar per als visitants mentre que els loopbacks fallen internament perquè el servidor DNS, IPv6, TLS, autenticació bàsica o WAF segueix una ruta diferent.

Recull proves abans de canviar res

• Copieu el loopback exacte de URL i l’error de Site Health.
• Sol·licita que URL des del servidor WordPress e Inspecciona DNS, redirecionaments i TLS.
• Comprova si la protecció d’estadificació, autenticació bàsica o regles de manteniment bloquegen les trucades internes.
• Compara la resolució IPv4 i IPv6 si el domini publica ambdós.

Causes més habituals

• Problema d’auto- DNS: El servidor resol el domini a una adreça inabastable o obsoleta.
• Límit d’autenticació: Autenticació bàsica, SSO o una porta de manteniment bloquegen la sol·licitud interna.
• Ha fallat la validació de l’TLS: El servidor no pot validar la vostra pròpia cadena de certificats.
• Firewall o regla CDN: La IP sortint del servidor és desafiada o bloquejada en tornar a través de la vora pública.

Seqüència segura de diagnòstic i reparació

1. Fes que el canònic URL del lloc sigui accessible des de l’amfitrió sense debilitar la seguretat pública.
2. Corregir la divisió DNS o la configuració de servidors només quan reflecteix la ruta de producció real.
3. Permet la ruta de bucle autenticada del servidor a través de la capa de protecció específica.
4. Torna a provar Site Health i una veritable operació cron o editor que depèn de loopbacks.

Com distingir entre les causes probables

No tractis Problema d’auto-DNS i Límit d’autenticació com a causes equivalents. El servidor resol el domini a una adreça inabastable o obsoleta. En canvi, autenticació bàsica, SSO o una porta de manteniment bloquejaran la sol· licitud interna. Per a distingir- les, useu aquestes dues comprovacions: Copieu el loopback exacte de URL i l’error de Site Health; i demana que URL des del servidor WordPress e Inspecciona DNS, redirecionaments i TLS. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada —Fer que el canònic URL del lloc sigui accessible des de l’amfitrió sense debilitar la seguretat pública— o si has de conservar l’estat actual i ampliar la recerca.

En un lloc de WordPress en producció, repeteix la petició que falla mentre comprova una pàgina que funciona correctament i l’àrea d’administració. Un error aïllat en una ruta requereix un rollback més acotat que un problema que afecta PHP, la base de dades o totes les peticions. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.

Què no has de fer

No desactivis les proves de loopback o cron com una solució. L’error ocult apareixerà més tard com tasques perdudes, actualitzacions estancades o errors de l’editor.

Com verificar la reparació

• Site Health informa d’una sol·licitud amb èxit.
• Un sol esdeveniment programat s’ executa sense un disparador cron extern.
• L’editor de blocs i les comprovacions d’actualització de fons normalment es completen.

Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.