cURL error 28: Connection timed out after 30001 milliseconds : ce message, remonté par le plugin de synchronisation Algolia sur un site WordPress hébergé en mutualisé, bloquait entièrement la réindexation du catalogue produit après chaque modification. Le tableau de bord Algolia côté cloud restait vide de tout contenu synchronisé depuis plusieurs jours, sans que rien dans les logs applicatifs WordPress ne pointe vers une cause précise autre que ce timeout générique.
Un timeout de connexion sortante peut avoir plusieurs origines : un problème de résolution DNS, une latence réseau excessive, ou un blocage explicite du trafic sortant vers certains ports ou certaines destinations. Sur un hébergement mutualisé, cette dernière hypothèse est souvent la plus probable et la moins visible depuis WordPress lui-même, puisque le blocage se situe en dehors de tout ce que l’application peut observer directement.
Symptôme : un échec systématique, jamais intermittent
Premier élément de diagnostic important : l’échec était systématique, à cent pour cent des tentatives, jamais intermittent. Un problème de latence réseau ou de surcharge temporaire du service Algolia se serait manifesté par des échecs occasionnels entrecoupés de succès. Un échec constant, avec le même délai de trente secondes à chaque tentative, oriente fortement vers un blocage réseau statique plutôt que vers un problème de performance ponctuel côté service tiers.
Diagnostic : isoler la connexion réseau du code applicatif
Pour écarter toute cause liée au plugin WordPress lui-même, le test suivant a été exécuté directement en ligne de commande sur le serveur, en dehors de tout contexte PHP ou WordPress :
curl -v --max-time 10 https://YOUR_APP_ID.algolia.net/1/indexes/*/objects \
-H "X-Algolia-API-Key: XXXX" \
-H "X-Algolia-Application-Id: YOUR_APP_ID"
La commande a échoué avec exactement le même symptôme que côté WordPress : blocage à l’établissement de la connexion TCP, aucune réponse HTTP, timeout après le délai configuré. Ce test, indépendant de tout code PHP, confirmait que le problème se situait au niveau réseau du serveur, pas dans la logique du plugin de synchronisation.
Confirmer le blocage côté hébergeur
Un test complémentaire vers un autre service HTTPS externe connu (l’API publique de WordPress.org, par exemple) a réussi sans délai, ce qui écartait un problème DNS ou de résolution réseau général. Le blocage était donc spécifique à la destination Algolia, ou plus précisément au port ou à la plage d’adresses IP utilisée par ce service. Un test de port isolé a confirmé le diagnostic :
nc -vz -w 5 YOUR_APP_ID.algolia.net 443
Ce test s’est terminé par un timeout, contre une réponse immédiate obtenue sur d’autres domaines HTTPS, confirmant que le pare-feu sortant de l’hébergement mutualisé bloquait spécifiquement le trafic vers les plages d’adresses IP d’Algolia, probablement via une liste de blocage générique appliquée à l’échelle de l’infrastructure de l’hébergeur plutôt qu’un blocage ciblant ce compte en particulier.
Correctif : demander une exception réseau explicite
Sur un mutualisé, aucune configuration côté client ne permet de contourner un pare-feu sortant géré par l’hébergeur. La correction a nécessité un ticket auprès du support technique de l’hébergeur, avec les plages d’adresses IP publiques d’Algolia à autoriser explicitement en sortie. L’hébergeur a confirmé, après vérification, qu’un blocage générique de sécurité s’appliquait sur un ensemble de plages d’adresses jugées à risque par leur système de filtrage automatique, incluant sans distinction certaines infrastructures cloud légitimes.
Prévention pour les projets futurs
- Tester systématiquement, dès la phase de cadrage d’un projet mutualisé, la connectivité sortante vers chaque service tiers prévu (recherche, paiement, envoi d’email), avant de s’engager sur cet hébergement.
- Documenter dans la fiche technique du projet les services externes nécessitant une exception réseau explicite chez cet hébergeur particulier.
- Préférer, pour les projets à forte dépendance envers des services tiers cloud, un hébergement VPS où le contrôle du pare-feu sortant reste entre les mains de l’agence plutôt que de l’hébergeur.
Un timeout de connexion sortante systématique, jamais intermittent, mérite d’être testé en dehors de tout code applicatif avant de chercher un bug dans le plugin : la cause la plus probable se situe souvent une couche plus bas, au niveau du réseau lui-même.
Ce qu’il faut retenir
Un serveur mutualisé applique parfois des règles de pare-feu sortant invisibles depuis WordPress, capables de bloquer un service tiers légitime sans message d’erreur explicite. Un test curl et nc isolés, en dehors du contexte applicatif, permettent de confirmer ce diagnostic en quelques minutes, bien avant d’envisager une régression dans le code du plugin de synchronisation.
