IP OVHCloud bloquée par Clouflare ?

Domains and Hosting
1

Bonjour,

Depuis un peu plus d'un mois, notre site wordpress hébergé sur OVH ne peut plus se connecter à notre plateforme Sumup de paiement par carte bancaire.

Après de nombreux allers-retours avec leur support, voici la réponse qu'ils nous apportent :

"Dear Marielle, Thank you for reaching out regarding the connection issue you're experiencing with the WooCommerce plugin.

After investigating the issue, we’ve determined that the connection failure is related to the hosting environment provided by OVH.

Specifically, OVH's free-tier hosting uses shared IP addresses, which are publicly available and often subject to misuse. Because these IPs are widely accessible at no cost, they are more frequently targeted for malicious activity and are consequently added to abuse or block lists. In your case, it appears the IP address assigned to your site has been listed by Cloudflare, which is currently managing the block list affecting your WooCommerce API connections.

To resolve this, we recommend contacting Cloudflare directly to request a delisting of the IP address you are currently using. For testing purposes, you might consider running a local PHP or web server on your workstation and using your home IP address to make API calls.

This can help bypass the restrictions while you verify the functionality of your integration. For a production environment, especially when using IPv4, we strongly recommend using a dedicated IP address—or at the very least, one that is not part of a free or shared-tier hosting plan. This approach can significantly reduce the likelihood of being affected by IP reputation or access issues."

Pouvez-vous nous assister à comprendre si cela peut bien être un problème que nous rencontrons avec l'IP 51.91.236.193 qui semble être l'IP qui nous est attribuée ?

Est-ce possible de la changer pour vérifier leur hypothèse ?

Avez-vous déjà interagi avec cloudflare pour ce genre de problèmes ?

J'ai essayé de comprendre https://www.abuseipdb.com/check/51.91.236.193 sans trop savoir en tirer de conclusions

Merci d'avance pour votre support

2

Bonjour Marielle,

Auriez-vous un ticket support à me transmettre avec tous les détails possibles svp.

Cela me permettra de vous identifier, ainsi que le cluster concerné et de creuser le sujet avec l'équipe.

Merci

--

Bruno B.
Teal Lead Hébergement mutualisés

3

Bonjour Bruno,

Nous avons créé un ticket CS11237083 auprès du support mais en attendant j'essayais également de consulter la communauté car je suis un peu perdu sur les solutions à notre disposition.

Merci,

Patrick

4

Bonjour,

C'est l'adresse IP qui est présentée par tous les sites de cluster028 qui font des connexions sortantes.

Il n'y a pas de solutions à vous proposer

- si OVH ne fait rien pour évacuer les clients maladroits ou malhonnêtes, et c'est d'autant plus difficile lorsque les communications sont cryptées.

- si la mise en liste noire ne tient pas compte du nombre de connexions légitimes par rapport aux connexions abusives.

Ou bien aller chez un petit hébergeur qui connaît tous ses clients triés sur le volet.

5

Bonjour Patrick,

Je vous remercie, je prends le cas dans l'équipe pour le traiter au plus vite avec cloudflare et on revient vers vous au plus vite.

--

Bruno B.
Team Lead Hébergements mutualisés

6

Bonjour,

L'IP donnée dans le premier message est l'IP d'entrée renseignée dans les DNS des domaines, mais elle nous a permis d'identifier le cluster concerné sur lequel des investigations sont en cours complémentées par le ticket fourni par la suite.

Nous agissons bien au quotidien sur les hébergement malicieux, tant sur des comportement inadéquats en entrée ou en sortie que sur les hébergements de clients qui ont été vérolés par manque de mise à jour de leurs applicatifs par exemple afin de limiter au maximum l'impact qu'il soit au niveau des performances que de la sécurité des plateformes.

--
Bruno B.
Team Leader Hébergements Mutualisés

7

J'utilise https://www.abuseipdb.com et le "score" de 51.91.236.193 du cluster 28 est "propre".
Personne ne va ban cette IP pour les quelques rapports enregistrés (et ça m'étonnerai que Cloudflare utilise abuseIpDb).

De toute façon, comme le dit @fritz2cat 🇧🇪 🇪🇺 il est quasiment impossible pour OVH de contrôler tous le trafic.
Vous pouvez aussi prendre un dédié (barematel ou vps) avec votre propre IP (avec un infogérant c'est mieux) si le budget le permet.

8

OK donc il semble de plus en plus que Sumup me réponde ça mais que leur analyse soit à côté ? Je connais très peu ces sujets donc je peux prendre n'importe quelle réponse pour argent comptant.

De plus, de ce que je constate avec Cloudflare, il semblerait qu'ils n'aient pas vraiment la main sur ce qu'ils ban, ils doivent utiliser des solutions qui leur donne un catalogue et eux n'ont pas du tout la main dessus, c'est plutôt aux client ensuite de whitelist certaines choses si besoin ?

Pour la solution que tu proposes @TTY , cela signifierait passer par une solution payante côté OVH pour avoir une IP dédiée ?

Merci d'avance pour votre temps

9

Leur diag est clair :
Specifically, OVH's free-tier hosting uses shared IP addresses, which are publicly available and often subject to misuse. Because these IPs are widely accessible at no cost, they are more frequently targeted for malicious activity and are consequently added to abuse or block lists. In your case, it appears the IP address assigned to your site has been listed by Cloudflare, which is currently managing the block list affecting your WooCommerce API connections.

C'est l'IP qui certainement vous cause problème (je trouve ça étonnant mais bon).
La solution d'avoir une IP dédiée en passant par un VPS ou un serveur dédié, encore une fois le budget n'as rien à voir surtout si vous devez vous faire aider par un infogérant.

@fritz2cat 🇧🇪 🇪🇺 donne aussi la piste d'un petit hébergeur qui connaît ses clients. Cela limite effectivement ce genre de problème.
Etes-vous suivi par un webmaster pro ? (agence web ou indépendant)

10

Réponse Copilot. J'avais pourtant un vague souvenir que OVH avait eu l'intention de proposer cela.

Community-Pasted-Attachment-1750424171026.jpg899×603 128 KB

11

Je continue à discuter avec l'IA.

>Il suffit qu'il y ait 2 ou 3 personnes qui lancent des bruteforce depuis une IP partagée, est-ce que Cloudflare va réagir différemment s'il y a 100 utilisateurs qui se comportent comme il faut (98%) ou 100.000 (99,998%) ?

C’est une excellente question — et une qui touche au fonctionnement souvent opaque de services comme Cloudflare.

En résumé : **Cloudflare ne fait pas une moyenne pondérée du “bon comportement”** pour juger une IP. Il suffit de quelques activités malveillantes suffisamment marquées pour qu’une IP partagée se retrouve sur une liste de blocage.

Cloudflare s’appuie sur plusieurs signaux combinés :
- **Le type d’activité détectée** : un bruteforce, c’est un signal fort et catégorique.
- **Le volume** et la fréquence : deux attaques ponctuelles ne valent pas des centaines en rafale.
- **Le contexte global** : réputation historique de l’IP, ASN du fournisseur, géolocalisation, etc.
- **Les règles personnalisées mises en place par le site cible** : certaines sont strictes au point de bloquer des IP dès le moindre soupçon.

Et dans l’univers Cloudflare, une IP peut être pénalisée même si 99,999 % des utilisateurs sont irréprochables, car **ce qui compte, c’est la sévérité du signal et la sensibilité du site ciblé**. Un peu comme un immeuble où une seule personne malveillante dans un appartement peut déclencher une alarme générale 😅.

En mutualisé, c’est justement ce genre de phénomène qui fait que l’on préfère parfois migrer des services sensibles vers une IP dédiée, pour avoir une réputation que l’on maîtrise.

...

12

Dernier message, je n'ai pas pu m'empêcher de vous le partager:

> merci, mais je ne vois pas de solution en mutualisé. Chacun a raison dans son île.

C’est joliment dit, et tellement vrai : en mutualisé, chacun rame sur sa barque, mais si un passager jette l’ancre n’importe comment, tout le ponton est fichu 😅.

Tu as parfaitement résumé la situation : avec une IP partagée, on hérite aussi des erreurs ou des abus des voisins. Les contraintes de sécurité, comme celles de Cloudflare, ne font pas de sentiment — elles protègent un site, pas les bons élèves du même immeuble.

Moralité : vouloir une connexion “propre” en mutualisé, c’est un peu comme vouloir un jacuzzi privé dans une auberge de jeunesse.

Mais bon, si jamais ton contact n’a vraiment pas les moyens de sortir du mutualisé, il reste des bricoles à tenter :
- Tenter de faire valider l’IP actuelle côté service cible (si possible).
- Passer par des services tiers qui proxyfient les appels (serverless, APIs publiques…).
- Ou même... mettre un tout petit VPS en bastion, administré par un ami serviable ? 😉 (je dis ça, je dis rien)

Si tu veux pousser l’exercice plus loin pour voir s’il reste un angle mort quelque part, je suis partant.

13

héhéhéhé. J'utilise Claude et il n'a pas la blague aussi facile :D

14

@TTY J'alimente AbuseipDB depuis février 2017: https://www.abuseipdb.com/contributor/12905.svg

(je n'ai pas trouvé le moyen d'afficher cette image remote.)

15

Bonjour,

Autre solution, la plus simple, nous alimenter en feedbacks :-)
Nous agissons au quotidien sur les hébergement malicieux, tant sur des comportement inadéquats en entrée ou en sortie que sur les hébergements de clients qui ont été vérolés par manque de mise à jour de leurs applicatifs par exemple afin de limiter au maximum l'impact qu'il soit au niveau des performances que de la sécurité des plateformes.

Nous sommes également en contact avec certaines des entités suceptibles de bloquer afin d'avoir leurs feedbacks avant que cela n'arrive ou afin d'agir en cas de problèmes.

--
Bruno B.
Team Leader Hébergements Mutualisés

16

Merci @Bruno B. c'est encourageant d'avoir du répondant de la part d'OVH. Ca permet d'avoir des réponses validées par le staff et on voit que ça bouge :)

17

Bonjour,

D'autres clients français hébergés par OVH qui semblaient voir le même problème que moi ont le problème de résolu depuis samedi matin, mais pas moi, même en retentant tout le process de connexion depuis le début.

OVH me dit que mon IP de sortie serait potentiellement suspecte en me donnant cette IP 91.134.248.249, que je ne vois nulle part sur mon interface d'administration, je pensais être en 51.91.236.193, est-ce que

https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a91.134.248.249

@Bruno B. est-ce que le fait que je fasse un ticket fait partie des feedbacks dont vous parlez ou je peux faire quelque chose d'autre ?

@TTY Non nous ne sommes pas suivi par un webmaster pro et c'est bien le problème je pense, on est sur la boutique en ligne d'un petit éditeur de livres, j'essaie de donner un coup de main avec mes connaissances mais ça limite beaucoup les moyens financiers et humains

@fritz2cat 🇧🇪 🇪🇺 Je suis complètement pour essayer des choses qui me permettraient de valider le diagnostic de Sum'up mais là je manque de connaissances, valider l'IP me semble illusoire en termes de sécurité chez eux, et proxyfier mes appels ou disposer d'un VPS en bastion sont des concepts que je ne touche même pas du doigt...

Je prends toutes les bonnes volontés :')

18

Bonjour,

> OVH me dit que mon IP de sortie serait potentiellement suspecte en me donnant cette IP 91.134.248.249, que je ne vois nulle part sur mon interface d'administration, je pensais être en 51.91.236.193,

et ils ont raison

Quand on visite un site sur cluster028 on s'adresse à 51.91.236.193 (ce n'est pas la seule adresse)

Quand un site hébergé sur cluster028 ouvre une connexion vers un site extérieur, cette connexion émane de l' IP 91.134.248.249

Voyez dans https://help.ovhcloud.com/csm/fr-web-hosting-clusters-ip-addresses?id=kb_article_view&sysparm_article=KB0052378 et pour chaque cluster vous avez l'adresse de la passerelle de sortie (gateway en anglais)

Vous n'êtes pas en mesure de monitorer l'usage et les abus à partir de cette adresse. C'est le boulot d'OVH.

Si un de vos voisins de palier fait du tapage, vous en subissez les conséquences aussi.
Et un cluster d'OVH ça a plutôt la taille d'une tour que celle d'un petit immeuble à Neuilly...

19

Bonjour,

@Patrick Milin oui effectivement ça nous aide. Vous me confirmez que c'est api.sumup.com que vous utilisez ?
Si oui, je vous confirme que nous n'avons plus de problèmes à joindre cette API depuis cette nuit sur ce cluster.

Bien à vous,

--
Bruno B.
OVHcloud Team Leader Hébergements Mutualisés

20

Bonjour @Bruno B.

En effet la connexion avec Sumup est "tombée en marche" Mercredi.

Est-ce que vous savez me dire d'où vient la résolution du problème, si c'est une action côté OVH ou si c'est juste la réputation de l'IP qui aurait été nettoyée par différents process, les votres ou d'autres ?

Merci en tout cas pour le support, à vous ainsi qu'à @TTY et @fritz2cat 🇧🇪 🇪🇺 , en espérant que la situation reste pérenne