curl error 28 while

Bonjour @Samuel 

Pourriez-vous nous montrer le script que vous utilisez avec CURL ?

Bonjour,

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 :

• agroturystykanafolwarku.baudesig.udl.pl 
• baudesign.pl  (exactement le même serveur que ci-dessus !)
• codefog.pl 
• veello.com 
• cdn51.dev  (fonctionne comme un proxy pour veello.com )
• terravista-erlebnisreisen.de 
• smaract.com 
• www.schutz-vor-naturgefahren.ch 
• contao.org 
• www.5150media.de 
• webbrand.de 

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

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 ?

Merci d'avance pour votre aide

Samuel

Vous pourriez peut-être tester 

      $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.

      print $content;

Merci pour votre retour.

J'ai donc ajouté ceci :

<?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 ^^

Bonjour @Samuel 

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

Faire un ticket Incident :

Manager OVH > https://www.ovh.com/manager/#/dedicated/useraccount/dashboard  >  Mes demandes d'assistance  >  Créer une demande / ticket 

puis :

Appeler le SAV OVH au  +33 9 72 10 10 07.
Plutôt  entre 8h et 9h le matin, ou vers 15h il y a moins d'attente.

Où déjà maintenant sur Twitter  @ovh_support_fr  ou   #OVHcloudsupport

Bonjour,

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.

Réponse à Samuel:

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 👌 Bon courage

Depuis l'environnement d'exécution de votre site web (et non la console ssh qui est bridée)

Depuis un site hébergé sur cluster013, curl ifconfig.me renvoie mon adresse 51.68.11.223

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

Merci d’avance pour votre aide.

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".

Merci pour ton retour.

Pour info, je viens de faire un essai sur le cluster015 et tout fonctionne correctement...

Le cluster023 est très lent et me retourne des erreurs comme mentionnées précédemment.

Si je regarde les travaux OVH j'ai ceci en prévision pour le cluster023 :