Què importa primer: WordPress o un plugin va esperar massa temps per a un servei extern. Els fets importants són el servidor de destí, operació, valor de temps d’espera i si DNS, connexió o temps de resposta es va consumir.
Què indica realment aquest símptoma
Aquest error sovint apareix en Site Health, actualitzacions, pagaments passarel· les, llicències, webhooks o APIs remotes. L’augment del temps d’espera pot ocultar una dependència lenta mentre manté als treballadors PHP ocupats per més temps.
Recull proves abans de canviar res
- Captura l’error complet, incloent URL i durada del temps d’espera.
- Prova la resolució DNS, la connexió TCP i la resposta HTTPS per separat del servidor.
- Identifica l’operació plugin, tema o nucli que va fer la sol·licitud.
- Compara una petició fallida amb una sol· licitud reeixida d’una altra xarxa o servidor.
Causes més habituals
- Latència del servei remot: La API o punt final del proveïdor és lent o no està disponible.
- Retard DNS: El servidor no pot resoldre el destí de forma ràpida o consistent.
- Firewall sortint: Hosting o regles de seguretat bloquegen el destí o el port.
- Saturació del treballador: El servidor local està massa ocupat per a començar o completar la crida de sortida a temps.
Seqüència segura de diagnòstic i reparació
- Executeu una sol·licitud cronometrada des del servidor WordPress i Registra DNS, conècteu i temps total.
- Verifica el certificat de destí i redirigeix perquè la sol· licitud no estigui en bucle.
- Estableixi un temps adequat a l’operació i maneja l’error explícitament.
- Mou trucades de fons no crítiques fora de les sol· licituds dels visitants quan sigui possible.
Com distingir entre les causes probables
No tractis Latència del servei remot i Retard DNS com a causes equivalents. La API o punt final del proveïdor és lent o no està disponible. En canvi, el servidor no pot resoldre el destí de forma ràpida o consistent. Per distingir- les, usa aquestes dues comprovacions: Captura l’error complet, incloent URL i durada del temps d’espera; i prova la resolució DNS, la connexió TCP i la resposta HTTPS per separat del servidor. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada —Executeu una sol·licitud cronometrada des del servidor WordPress i Registra DNS, conècteu i temps total — o si heu de conservar l’estat actual i ampliar la investigació.
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 teniu temps d’espera globals molt alts de HTTP. Una dependència fallida aleshores pot esgotar els treballadors de PHP i convertir un problema d’integració en una interrupció a tot el lloc.
Com verificar la reparació
- La sol·licitud externa es completa dins d’un termini limitat predictible.
- L’error es gestiona sense bloquejar càrregues de pàgina, checkout o cron.
- No apareixen noves entrades de cURL 28 durant una finestra de prova representativa.
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.
CRITERI D’INCIDENT WP REPAIR
Reconstrueix la incidència abans de corregir-la
Aquest error sovint apareix en Site Health, actualitzacions, pagaments passarel· les, llicències, webhooks o APIs remotes. L’augment del temps d’espera pot ocultar una dependència lenta mentre manté als treballadors PHP ocupats per més temps.
- 1
Captura l’error complet, incloent URL i durada del temps d’espera.
- 2
Prova la resolució DNS, la connexió TCP i la resposta HTTPS per separat del servidor.
- 3
Identifica l’operació plugin, tema o nucli que va fer la sol·licitud.
- 4
Compara una petició fallida amb una sol· licitud reeixida d’una altra xarxa o servidor.
Què ha de quedar verificat
- La sol·licitud externa es completa dins d’un termini limitat predictible.
- l’error es gestiona sense bloquejar càrregues de pàgina, checkout o cron.
- No apareixen noves entrades de cURL 28 durant una finestra de prova representativa.
Fonts tècniques oficials
Continua el diagnòstic
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
Per tant elevar el valor de temps d'espera del CURL ho solucionarà permanentment?+
L’augment del temps d’espera pot ocultar una dependència genuïnament lenta mentre manté als treballadors PHP ocupats més temps, el que corre el risc de convertir una integració lenta en una saturació més àmplia del treballador. És millor identificar per què la trucada remota és lenta i establir un temps d’espera que coincideixi amb l’operació.
Com puc saber si el problema és DNS, la connexió o el temps de resposta del servei remot?+
Executeu una sol·licitud cronometrada des del servidor WordPress i mesuri la resolució DNS, la connexió TCP i el temps total de resposta per separat. Comparar això amb una sol·licitud d’una xarxa o host diferent mostra si la lentitud és específica a la ruta del vostre servidor o compartida per tots.
Podria un tallafocs sortint causar això fins i tot si el servei de destí és saludable?+
Sí. Hosting o regles de seguretat que bloquegen un host o port de destí específic produeixen el mateix símptoma de timeout que la latència remota genuina. Provar DNS, connexió i resposta HTTPS per separat del servidor ajuda a distingir una ruta de sortida bloquejada d’un servei lent però accessible.
És probable que aquest error afecti a tot el lloc o a una sola característica?+
Normalment, només afecta a l’operació específica que fa la trucada de sortida —Sit Health, un xec d'actualització, un pagament gateway, un xec de llicència, o un webhook — no el lloc en general.