Je ne passe pas par un script PHP, mais je fais directement des tests en ligne de commande via SSH sur mon hébergement mutualisé (cluster 023). Voici les résultats de mes tests avec curl :
curl ifconfig.me
# Échec de la connexion au port 80 ifconfig.me : Connexion refusée
Il semble que seules certaines connexions sortantes soient autorisées. Cela pose problème pour installer des dépendances via Composer ou accéder à des API externes.
Est-ce qu’il y a une restriction particulière sur les connexions sortantes sur ce cluster ? Comment puis-je permettre à mon hébergement d’effectuer des requêtes externes librement ?
Nous avons fait d'autres essais avec le développeur du module. Cela pourrait-il être lié à des problème DNS ?
Voici ce qu'il en ressort :
******************************** Salut Samuel,
Merci pour la réponse. Je suis presque sûr qu'il s'agit d'un problème sur l'hébergeur OVH, car nous avons maintenant testé cela encore plus en profondeur :
J'ai également vérifié les journaux d'accès et d'erreurs sur le serveur Veello et je n'ai rien trouvé de pertinent.
Je suppose donc que ce n'est pas lié au serveur de Veello lui-même, mais plutôt à la configuration d'OVH. Je ne peux pas vous aider davantage, ils doivent vérifier cela de leur côté. Peut-être que c'est lié à des problèmes de DNS ?
Merci pour la réponse. Je suis presque sûr qu'il s'agit d'un problème sur l'hébergeur OVH, car nous avons maintenant testé cela encore plus en profondeur :
Il est intéressant de noter que certains serveurs sont accessibles pour OVH, et d'autres non : https://dosotec.prod-igweb.fr/test-curl.php
Je suppose donc que c'est lié à la configuration OVH...
J'ai contacté le support mais je n'ai pas de solutions proposées pour le moment... Peut-être que c'est lié à des problèmes de DNS ?
$ch_rech = curl_init(); // Initialiser cURL. curl_setopt($ch_rech, CURLOPT_URL, $url); // Indiquer quel URL récupérer curl_setopt($ch_rech, CURLOPT_HEADER, 0); // Ne pas inclure l'header dans la réponse.
ob_start(); // Commencer à 'cache' l'output.
curl_exec($ch_rech); // Exécuter la requète. curl_close($ch_rech); // Fermer cURL.
$content = ob_get_contents(); // Sauvegarder le 'cache' dans la variable $Page_Infos_GEOIP. ob_end_clean(); // Vider le buffer.
<?php
$url = "https://veello.com"; // Remplace par l'URL à tester
$ch_rech = curl_init(); // Initialiser cURL.
curl_setopt($ch_rech, CURLOPT_URL, $url); // Indiquer quelle URL récupérer.
curl_setopt($ch_rech, CURLOPT_HEADER, 0); // Ne pas inclure l'header dans la réponse.
ob_start(); // Commencer à 'cacher' l'output.
curl_exec($ch_rech); // Exécuter la requête.
curl_close($ch_rech); // Fermer cURL.
$content = ob_get_contents(); // Sauvegarder le 'cache' dans la variable.
ob_end_clean(); // Vider le buffer.
echo $content;
?>
Accessible à cette adresse : https://dosotec.prod-igweb.fr/test-curl-2.php
ça mouline jusqu'à un : Gateway Timeout The gateway did not receive a timely response from the upstream server or application.
J'ai également testé plusieurs hébergement mutualisés que je gère et j'ai le même problème... certaines adresses sont accessibles et d'autre non... c'est étonnant. N'y a t'il pas des maintenances en cours qui seraient la cause du problème ? j'imagine que je ne suis pas le seul dans ce cas ^^
J'ai le même problème curl error 28 et plus de WP-CRON fonctionnel.
J'ai l'impression que plusieurs personnes ont ce problème en ce moment car ce sujet fait partie des sujets les plus consultés ces 7 derniers jours.
Cela voudrait dire que c'est bien de la faute d'OVH et qu'ils doivent trouver un solution plutôt que de se dédouaner en disant que tout va bien de leur côté.
Car personnellement de mon côté je n'ai rien changé sur la config de mon site ces derniers jours.
Votre site dosotec.prod-igweb.fr tourne sur cluster023. Quand cluster023 fait un curl, l'adresse IP de sortie est: 91.134.248.235
Assurez-vous en premier lieu que le serveur que vous sollicitez avec curl ne bloque pas les connexions en provenance de 91.134.248.235. Alors le fautif doit être OVH.
Dans un ticket incident à OVH, plaignez-vous qu'une fonctionnalité attendue ne fonctionne pas, soyez clair, dites que votre site n'arrive pas à contacter tel site sur tel n° de port. Vous confirmez avoir vérifié avec ce site que les connexions en provenance de 91.134.248.235 ne sont pas bloquées par un firewall auprès de ce site.
Bonsoir, nous avons vérifié les adresses IP.
Aucun blocage apparent sur les serveurs cibles.
Pour moi le problème vient de OVH, je pense que c'est du à une lenteur des serveurs…
Il y a une maintenance en cours sur pas mal de cluster… J'attends de voir si ça corrigera le problème.
J'ai déposé un ticket à OVH, mais pour eux tout va bien… Il ne constate pas de problème …
Bref j'ai fini par installer mon projet chez infomaniak et tout fonctionne correctement
Voici un résumé de la situation (que j'ai transmis à OVH également) :
Bonjour,
Après plusieurs tests, je pense que le problème vient d’une lenteur des serveurs chez OVH. En effet, même lorsque le script est exécuté via le front office (appelé depuis un navigateur), certaines requêtes échouent avec l'erreur *"Connection timed out after 15000 milliseconds"*. Pourtant, en exécutant exactement le même script sur un autre hébergeur, les requêtes aboutissent sans problème.
Nous avons également vérifié le serveur cible http://veello.com, et il n'y a aucun blocage d'adresse IP qui pourrait expliquer ces échecs.
Pour que vous puissiez constater le problème par vous-même, voici un lien vers un test PHP que nous avons mis en place pour tester tout ça et vérifier sur d'autre serveurs : https://dosotec.prod-igweb.fr/test-curl.php Il y a actuellement une "curl error 28" sur deux pointages : - https://www.5150media.de - et https://veello.com
Ce qui me fait dire que le problème vient de OVH c'est que la semaine dernière j'avais plus d'erreurs sur les même adresses... Voir une de mes message précédent dans cette même discussion.
De plus, j’ai déjà installé ce même module des dizaines de fois sur des hébergements mutualisés OVH sans jamais rencontrer ce problème. Celui-ci est apparu il y a une vingtaine de jours.
Étant donné l’urgence du projet, j’ai finalement dû l’héberger chez Infomaniak, où tout fonctionne normalement.
Enfin, j’ai constaté qu’il y a actuellement des maintenances en cours sur plusieurs clusters chez OVH. Est-ce que cela pourrait être la cause de ces lenteurs et de ces erreurs de connexion ?
Informations demandées : - API utilisée : Composer et Packagist pour l'installation des dépendances PHP - URL utilisée par l’API sur mon hébergement : L’URL concernée est celle du gestionnaire de paquets PHP, principalement https://packagist.org et les URL des dépendances mentionnées dans le fichier composer.json - Erreur rencontrée à votre niveau : curl error 28 while downloading - Connection timed out after 10005 milliseconds
Les délais de 10000 ou 15000 millisecondes sont clairement des timeouts et n'ont rien à voir avec la charge des serveurs.
Toujours depuis mon cluster013, veello fonctionne et 5150media ne fonctionne pas.
Vous avez bien fait d'aller voir ailleurs car j'ai l'impression que chez OVH plus personne n'a le pouvoir, la capacité et la compétence pour aller voir ce qui se passe et rapporter honnêtement au client avec un diagnostic.
Depuis toujours il y a eu trop de situations non gérées au niveau des connexions sortantes bloquées depuis les clusters OVH - sans doute en réaction à des abus - et où des situations différentes selon les clusters et non documentées restent ainsi gravées dans le marbre.
A la décharge d'OVH il y a bon nombre de sites partenaires qui ferment les connexions en provenance de ces IP d'OVH - sans doute en réaction à des abus - et le résultat est le même, absence de connexion et timeout 10 secondes, 15 seconds, dépendant de votre logiciel qui instaure un timeout pour ne pas être bloqué "pour toujours".
As part of our continuous improvement plan, maintenance is scheduled on our Web Hosting Offer.
Start time : 25/02/2025 22:00 UTC End time : 26/02/2025 05:00 UTC Service impact : Filerz following will be unavailable one by one during 20 minutes. Cluster030- Filerz1518 Cluster029 - Filerz1625 Cluster028 - Filerz1580 Cluster028 - Filerz786 Cluster020 - Filerz802 Cluster023 - Filerz941 Service improvement : We are going to reboot the Filerz one by one (Web Hosting server) to improve the performance and stability of the service.
Thank you for your understanding. Posted on Feb 21, 2025 - 21:21 UTC
(exactement le même serveur que ci-dessus !)
…