WordPress curl error 28 signifie que la requête cURL a dépassé son délai d’attente avant de recevoir une réponse. Pour corriger le problème, testez d’abord la résolution DNS et la connexion HTTPS du serveur, puis vérifiez le loopback WordPress, le pare feu, le certificat TLS et les limites de l’hébergeur. Une valeur cURL error 28: Operation timed out pointe vers un délai réseau ou serveur, tandis que cURL error 7: Failed to connect indique généralement un port fermé, un service indisponible ou un nom d’hôte injoignable. Voici la procédure complète, sans désactiver la sécurité du site.

Que signifie wordpress curl error 28 dans WordPress ?

cURL est la bibliothèque utilisée par PHP pour appeler une ressource distante en HTTP ou HTTPS. WordPress s’en sert pour les mises à jour, les appels de la REST API, les contrôles de santé du site, les flux, les services antispam et certains connecteurs. L’erreur 28 apparaît lorsque la connexion ou la lecture prend plus de temps que le délai autorisé. Le serveur distant peut répondre, mais WordPress abandonne avant la fin.

Le message exact aide à distinguer plusieurs situations. Resolving timed out concerne le DNS. Connection timed out concerne l’ouverture de la connexion. Operation timed out arrive souvent pendant la lecture de la réponse. Avec l’erreur 7, aucun canal TCP n’a pu être établi. Dans tous les cas, le navigateur du visiteur peut fonctionner parfaitement, car c’est le serveur WordPress qui doit joindre la destination.

Cette différence est importante avec l’erreur « The response is not a valid JSON response » dans l’éditeur. Si l’éditeur Gutenberg est concerné, consultez aussi notre guide WordPress publishing failed et réponse JSON invalide. Le symptôme peut être proche, mais la cause réseau doit être confirmée avant de modifier le contenu ou les permaliens.

Identifier l’appel qui échoue avant de modifier le serveur

Commencez dans Outils, Santé du site, Informations, Serveur. La section REST API affiche souvent une erreur plus précise. Regardez ensuite les journaux PHP et le journal du serveur web à l’heure exacte du problème. Notez l’URL appelée, le code HTTP éventuel, la durée et le message cURL. Une erreur répétée sur une seule destination ne se traite pas comme une erreur sur toutes les destinations.

# Test depuis le serveur qui héberge WordPress
curl -I -L --connect-timeout 10 --max-time 30 https://wpadminlab.com/wp-json/

# Afficher les détails DNS, TLS et HTTP
curl -v -L --connect-timeout 10 --max-time 30 https://wpadminlab.com/wp-json/ -o /dev/null

# Vérifier uniquement la résolution DNS
getent hosts wpadminlab.com
# ou
nslookup wpadminlab.com

Un code 200 ou 401 prouve que le réseau répond. Un code 403 prouve que le serveur répond aussi, mais qu’une règle de sécurité refuse la requête. En revanche, un délai sans code HTTP confirme un problème de transport, de filtrage ou de traitement trop long. Exécutez ces commandes depuis le serveur, pas seulement depuis votre ordinateur local.

Si vous n’avez pas SSH, demandez à l’hébergeur d’exécuter le test depuis la machine concernée. Un test externe avec un outil de disponibilité ne mesure pas le même chemin réseau que le loopback PHP.

Corriger un loopback WordPress en échec

Le loopback est la capacité du site à s’appeler lui même. WordPress le teste pour les tâches planifiées, la santé du site et certaines opérations d’administration. Un pare feu peut bloquer l’adresse IP publique, le nom de domaine ou le port 443 lorsque PHP lance une requête vers le même hébergement.

Vérifiez les URL principales avec WP CLI. Elles doivent utiliser le bon protocole et le bon domaine. Après une migration, une ancienne URL HTTP, une redirection en boucle ou un certificat associé à un autre domaine suffit à provoquer un timeout.

wp option get home
wp option get siteurl
wp cron test
wp cron event list --fields=hook,next_run_gmt, schedule | head -20

# Tester la REST API depuis le shell
curl -sS -o /dev/null -w 'HTTP %{http_code}, durée %{time_total}sn' 
  --connect-timeout 10 --max-time 30 
  https://exemple.fr/wp-json/

Si le domaine résout vers une adresse IPv6 non fonctionnelle, cURL peut attendre avant de retenter en IPv4. Testez les deux familles d’adresses avec curl -4 et curl -6. La correction durable se fait chez l’hébergeur ou dans le DNS, pas en augmentant indéfiniment le délai WordPress.

Contrôlez aussi les redirections. Une chaîne de trois ou quatre redirections ne crée pas toujours une erreur 28, mais elle consomme le délai disponible. Utilisez curl -I -L et supprimez les redirections contradictoires entre HTTP, HTTPS, www et domaine nu.

Résoudre curl error 7, connexion refusée ou port inaccessible

curl error 7 apparaît quand cURL ne réussit pas à se connecter à l’hôte ou au port demandé. Le service peut être arrêté, le port 443 peut être filtré, ou le DNS peut renvoyer une mauvaise adresse. Dans un environnement Docker, l’erreur arrive souvent parce que le conteneur WordPress utilise localhost au lieu du nom du service distant.

services:
  wordpress:
    image: wordpress:latest
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: wp
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: secret
  db:
    image: mariadb:11

Dans Docker, localhost désigne le conteneur courant. Il ne désigne pas le conteneur MariaDB. Pour une API externe, vérifiez la route sortante du réseau Docker et les règles du pare feu. Pour un appel vers le propre domaine, vérifiez que le proxy inverse accepte les requêtes provenant de l’adresse du serveur.

Sur un VPS, utilisez ss -ltnp pour voir les ports en écoute et inspectez les règles UFW ou nftables. Sur un hébergement mutualisé, ne tentez pas d’ouvrir un port vous même. Transmettez le message exact au support, avec l’heure, l’IP de destination et le résultat de getent hosts.

Vérifier DNS, TLS et les certificats

Un DNS lent ou incohérent peut expliquer un curl error 28 intermittent. Comparez les enregistrements A et AAAA depuis plusieurs résolveurs. Si le domaine utilise un CDN, vérifiez que l’origine est joignable depuis le réseau de l’hébergeur. Une adresse IPv6 publiée sans service IPv6 fonctionnel est une cause fréquente de délais longs.

# Résolveurs publics et types d'enregistrements
for resolver in 1.1.1.1 8.8.8.8; do
  dig +time=2 +tries=1 @$resolver exemple.fr A
  dig +time=2 +tries=1 @$resolver exemple.fr AAAA
done

# Diagnostic du certificat et de la chaîne TLS
openssl s_client -connect exemple.fr:443 -servername exemple.fr 
  </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer -subject

Un certificat expiré déclenche normalement une erreur TLS explicite, mais un proxy mal configuré peut simplement interrompre la connexion. Vérifiez les dates de validité, le nom de domaine, la chaîne intermédiaire et le protocole TLS accepté. Ne désactivez pas la vérification avec CURLOPT_SSL_VERIFYPEER false : cela masque le défaut et expose les identifiants transmis par WordPress.

Si vous utilisez Cloudflare ou un autre CDN, contrôlez le mode SSL. Le mode flexible peut créer une boucle entre le CDN et l’origine. Préférez un chiffrement complet avec un certificat valide sur l’origine, puis testez depuis le serveur WordPress.

Traiter un timeout de la REST API trop lente

Quand la connexion s’établit mais que la réponse n’arrive pas, le problème peut venir d’une requête PHP ou SQL trop longue. Un plugin, une API tierce ou un endpoint personnalisé peut bloquer le processus. Mesurez les temps séparément avec les options cURL.

curl -sS -o /dev/null 
  -w 'DNS %{time_namelookup}s | TCP %{time_connect}s | TLS %{time_appconnect}s | premier octet %{time_starttransfer}s | total %{time_total}sn' 
  --connect-timeout 10 --max-time 60 
  https://exemple.fr/wp-json/wp/v2/posts?per_page=1

Un temps DNS élevé appelle une correction DNS. Un temps TCP ou TLS élevé appelle une correction réseau. Un temps jusqu’au premier octet élevé indique plutôt PHP, WordPress, la base ou l’API appelée par l’endpoint. Activez temporairement le journal des requêtes lentes, désactivez les plugins non essentiels sur un environnement de préproduction et répétez le test.

Réduire per_page, limiter les champs demandés et mettre en cache une réponse publique sont de meilleures solutions que d’augmenter le délai à plusieurs minutes. Si une tâche cron n’a pas besoin d’une réponse immédiate, planifiez la synchronisation côté serveur au lieu de la déclencher pendant une requête d’administration.

Contrôler le pare feu, les extensions PHP et l’hébergeur

Vérifiez que l’extension PHP cURL est installée et qu’elle utilise une version récente de libcurl et d’OpenSSL. Un certificat CA obsolète peut bloquer les connexions HTTPS. La commande php -i | grep donne une première indication, mais seul le journal PHP permet de confirmer la configuration réellement utilisée par le site.

php -m | grep -i curl
php -i | grep -E 'cURL support|cURL Information|SSL Version|CA Bundle'

# Vérifier la limite mémoire et le temps PHP
wp eval 'echo ini_get("max_execution_time"), PHP_EOL;'
wp eval 'echo ini_get("memory_limit"), PHP_EOL;'

Un pare feu applicatif peut bloquer les requêtes sortantes selon le domaine, le User Agent ou la fréquence. Demandez au support si une règle mod_security, Imunify360, un proxy sortant ou une limite de connexions est active. Ne mettez pas tout le pare feu en pause sur un site public. Faites ajouter une exception ciblée pour la destination et le chemin nécessaires.

Certains hébergements mutualisés imposent un délai maximum pour les processus PHP. Si le timeout arrive toujours après la même durée, par exemple 30 ou 60 secondes, comparez cette valeur avec max_execution_time et les limites du proxy. Cette régularité est un indice utile à transmettre au support.

Réparer sans affaiblir la sécurité du site

Les contournements rapides sont souvent dangereux. Ne désactivez pas la validation TLS, ne remplacez pas HTTPS par HTTP, ne rendez pas la REST API publique sans raison et ne faites pas confiance à une adresse IP trouvée dans un message d’erreur. Commencez par une sauvegarde, reproduisez sur une copie et changez une seule variable à la fois.

Pour les endpoints WordPress, appliquez une authentification adaptée, une liste blanche de destinations et un délai raisonnable. Pour un appel distant, journalisez le domaine, le code HTTP et la durée, mais jamais les clés API ni les mots de passe. Notre guide sécuriser l’API REST WordPress détaille l’authentification, le rate limiting et CORS.

Si votre objectif est seulement de protéger l’API, ne confondez pas timeout réseau et attaque. Un 403 ou un 429 est une réponse du serveur. Un curl error 28 ne prouve pas une compromission. Il justifie une analyse des journaux et du chemin réseau.

Checklist de diagnostic en dix minutes

Appliquez cette séquence dans l’ordre. Elle évite les modifications inutiles et fournit au support des éléments exploitables.

  1. Copiez le message cURL complet et l’URL concernée.
  2. Testez /wp-json/ depuis le serveur avec curl -v.
  3. Comparez curl -4 et curl -6.
  4. Vérifiez les enregistrements DNS A et AAAA.
  5. Inspectez les redirections HTTP et HTTPS.
  6. Mesurez le DNS, TCP, TLS, premier octet et temps total.
  7. Contrôlez les journaux PHP, WordPress et du proxy.
  8. Testez sans le plugin ou l’endpoint qui déclenche l’appel.
  9. Demandez au support de vérifier le pare feu sortant et les limites.
  10. Restaurez la configuration normale et documentez la correction.

Questions fréquentes sur curl error 28 et curl error 7

Comment corriger rapidement wordpress curl error 28 ?

Testez la REST API depuis le serveur, puis vérifiez DNS, IPv6, certificat TLS, pare feu et durée de traitement PHP. N’augmentez le timeout qu’après avoir identifié la cause, car cette mesure ne répare pas un réseau bloqué.

Quelle est la différence entre curl error 28 et curl error 7 ?

Le curl error 28 correspond à un délai dépassé avant la fin de la requête. Le curl error 7 signifie que cURL n’a pas réussi à établir la connexion vers l’hôte ou le port demandé. Le premier demande une mesure de durée, le second une vérification du service et du réseau.

Pourquoi la REST API WordPress fonctionne dans le navigateur mais pas avec cURL ?

Le navigateur et PHP peuvent utiliser des DNS, des adresses IP, des proxys et des règles pare feu différents. Un loopback serveur bloqué, une IPv6 défaillante ou une règle appliquée au User Agent explique souvent cette différence.

Faut il désactiver la vérification SSL pour supprimer curl error 28 ?

Non. Désactiver la vérification SSL masque un certificat ou une chaîne de confiance incorrecte et expose les échanges. Corrigez le certificat, le bundle CA ou la configuration TLS de l’hébergement.

Quand contacter l’hébergeur pour un timeout cURL WordPress ?

Contactez l’hébergeur si le timeout est reproductible depuis le serveur, s’il survient à durée fixe, ou si les journaux montrent un blocage du pare feu sortant, du proxy ou du service DNS. Fournissez l’URL, l’heure, le message complet et les résultats de curl.

Sources :

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.