Bonjour à tous.
J'ai une boutique en ligne WordPress, WooCommerce avec plugin multilinge WPML.
J'ai un hébergement PRO (normalement spécialiement conçu pour WP) car je craignais un serveur trop juste.
le site n'est même pas officiellement en ligne.
Je crée des produits et je les traduits en utilisant l'éditeur WPML.
Au bout de quelques dizaines de minutes le site plante (partie admin) et j'ai même eu une erreur 429 (ou "Your IP has been banned") ...
J'ouvre un ticket sur OVH et au bout de "3 semaines" (!!!) j'ai une réponse dans laquelle, en gros, on me dit de me débrouiller !
Mais tout ça est il bien normal ?
Bonne journée.
Le message 429 - Your IP has been banned que vous voyez n’est pas une erreur de votre site ni un problème de configuration. C’est une mesure de protection automatique du système anti‑DDoS d’OVH qui s’active lorsqu’il détecte ce qu’il considère comme un trafic anormal ou suspect.
Dans votre cas, le déclencheur est très probablement le plugin WPML. Cet outil, destiné à gérer les traductions et à synchroniser le contenu, effectue de multiples requêtes intensives au serveur, surtout lors de la création ou de la modification de produits. Le système d’OVH interprète cette activité légitime comme une attaque et bloque l’IP pour protéger le serveur.
Essayez de désactiver ce plugin et faites‑nous un retour.
Cordialement,
Sergio Turpín
Bonjour @Pat
Que disent les logs de votre hébergement ? Comme l'indique @sturpin : Les erreurs 429 apparaissent lorsque vous effectuez plein de requêtes d'un coup : 10 requêtes dans la même seconde par exemple.
Si celles-ci ne sont pas de votre fait, peut-être que vous faites quelque chose qui lance plusieurs requêtes, ce qui finit par provoquer le blocage de de votre adresse.
Pour accéder aux logs de votre hébergement :
• Cliquez sur votre hébergement, sous la section "Hébergements".
• Rendez-vous dans l'onglet"Statistiques et logs" puis cliquez sur "voir les logs"
Pour plus d'informations : https://docs.ovhcloud.com/fr/guides/web-cloud/web-hosting/logs-and-statistics
N'hésitez pas à rechercher l'adresse IP bloquée via un CTRL + F dans les logs pour voir ce qu'il apparait 
Astérix
merci pour votre aide !
Le problème c'est que dans les logs d'erreur, il y a des tonnes d'infos mais t aucune trace de "wpml"...
Il affiche même des erreurs sur les images...
client denied by server configuration: /homez......../wp-content/uploads/woocommerce_uploads/2026/03/M-041oq9-pdf-hlvyer-232x300.jpg
Et plein d'autres erreurs...
FastCGI: An error happened during Fastcgi processing, fallback to CGI
Dans le log Web il y a aussi des tonnes d'erreurs, la seule référence à wpml est ceci.
"GET /wp-json/wc-analytics/admin/notes?page=1&per_page=25&type=error%2Cupdate&status=unactioned&_locale=user HTTP/1.1" 200 2 "https://monsite.com/wp-admin/post.php?post=201&action=edit&lang=fr&classic-editor&referer=ate&wpml_version=4.9.4&complete_no_changes=0&ate_job_id=199820910&ate_status=6&ate_original_id=199820910&complete=true" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0"
Mais ça ne choque personne qu'il faille 3 semaines pour avoir une réponse sur un ticket relativement urgent ? 
Client denied by server configuration et erreurs d'images… Cette erreur indique que le serveur refuse l’accès à certains fichiers, probablement à cause de permissions incorrectes. Les erreurs avec les images dans uploads/woocommerce_uploads suggèrent que le problème pourrait venir de la configuration de sécurité du serveur ou des permissions des fichiers et dossiers.
En ce qui concerne FastCGI… C’est un signal que le processus FastCGI, qui gère les requêtes PHP, échoue ou est surchargé. Cela arrive généralement lorsque le serveur ne peut pas gérer la charge de requêtes et recourt à une méthode plus lente (comme le CGI), ce qui ralentit tout et peut entraîner des blocages.
Essayez de faire ce qui suit :
- Modifiez le fichier .htaccess et ajoutez ces valeurs :
php_value memory_limit 512M
php_value max_execution_time 300
- Vérifiez les permissions des fichiers. Connectez‑vous via FTP et assurez‑vous que les dossiers (comme uploads/woocommerce_uploads) ont des permissions 755 et les fichiers 644.
- Je vous recommande également de purger les caches et les objets transitoires : WooCommerce et WordPress stockent de nombreuses données temporaires. Un plugin comme WP‑Optimize ou l’option Transient Cleanup de WPML peut aider à nettoyer ces données et réduire la charge.
Important ! – Ces erreurs, en particulier celle de FastCGI, sont typiques des hébergements partagés lorsqu’un site commence à exiger plus de ressources que le forfait ne peut offrir. Si le problème persiste, la solution la plus définitive sera de migrer votre site vers un VPS ou un serveur dédié, où vous disposerez de ressources garanties et pourrez ajuster la configuration du serveur sans restrictions.
J’espère vous avoir aidé 
Cordialement,
Sergio Turpín
Cela dépend du plan que vous avez souscrit... mais parfois ils ont une forte surcharge d’incidents et cela peut prendre un peu de temps 
Merci pour l'aide.
Mais quand j'ajoute les 2 lignes au htaccess j'ai une erreur 500...
Pour ce qui est de migrer vers un VPS, sérieusement ça n'est pas possible ?!
J'installe une boutique WooCommerce toute simple avec 2 langues, je crée une dizaine de produits et le serveur plante !
Je ne suis pas spécialiste réseau, mais un VPS pour un site WordPress sans aucun trafic pour l'instant et avec un dizaine de produits il me faut un serveur dédié ?
Cordialement.
Salut @Pat
Je ne vais pas te dire que la seule solution est un VPS, car ce n’est pas vrai. Le problème, presque certainement, n’est pas que ton site soit très lourd, mais une combinaison de la façon dont les extensions que tu utilises (WooCommerce + WPML) consomment des ressources dans un environnement partagé, et de la manière dont le système de sécurité d’OVH réagit à cette consommation.
Cette erreur 500 lors de l’ajout des lignes est généralement due à une erreur de syntaxe dans le fichier. Si tu as ajouté quelque chose de mauvais, tout le site se bloque. Vérifie le contenu du .htaccess avec soin . Pour dépanner, renomme‑le en .htaccess.old et le site reviendra à fonctionner (mais sans les modifications). Ensuite, ajoute les lignes une à une et teste.
Tiens moi au courant.
Cordialement,
Sergio Turpín
j'ai mis le bout de code dans le user.ini, car tout plante dés que je touche au htaccess.
Mais j'arrive toujours pas à comprendre qu'avec 4 plugins, une dizaines de produits et 0 trafic le serveur Pro ne suffise pas !
Salut @Pat
Oui, comme je te l’ai dit, j’ai le sentiment que ton problème n’est pas le trafic (car tu n’en as pas) ni la taille du site, c’est davantage la façon dont les plugins utilisent les ressources dans un environnement partagé et la façon dont OVH gère ce trafic.
Utiliser .user.ini pour augmenter la mémoire et le temps d’exécution de PHP est correct 
As‑tu remarqué la différence ? Tiens‑moi au courant.
Salut,
Sergio Turpín
0 différence, ça plante encore quand je saisis des nouveaux produits.
Je suis vraiment dégouté du serveur dit "Pro" de OVH, les performences sont déplorables !
Attention, la modification de variable de PHP sera vaine, car ce type de configuration est impossible sur les hébergements mutualisés.
Si vous rencontrez des problèmes de stabilité, n'hésitez pas à ouvrir un ticket d'assistance à ce sujet et à partager le numéro sur ce topic
Astérix
Merci pour la réponse.
J'ai clairement des problèmes de réponses de php
AH10143: FastCGI: comm with server "/homez.2247/monsite/www/index.php" aborted: read failed
AH10149: FastCGI: incomplete headers (0 bytes) received
AH10157: FastCGI: An error happened during Fastcgi processing, fallback to CGI
Et pour les tickets... le premier j'ai attendu 3 semaines une réponse, sans intéret d'ailleurs.
Et le dernier ticket...
votre demande XXXXDEMANDE CLIENTXXXX dépassant le cadre des services que nous fournissons à nos clients, je vous informe que notre support ne peut vous accompagner sur ce sujet.
Pourrais-je avoir le numéro de ticket, s'il vous plait ? Il faudrait creuser plus en détails pour mieux interpréter ces logs.
Ici index.php plante sans renvoyer de réponse à Apache (0 octet reçu). Cela vient généralement d'un dépassement de mémoire, d'un timeout, d'une erreur, etc Apache a donc tenté un fallback en CGI classique, mais toujours sans succès.
Que s'est-il passé sur les logs web au moment où cette erreur est apparue ?
Votre base de données est-elle spammée (visible dans les "stats et logs" de votre hébergement).
Y a-t-il eu une modification au sein du site qui aurait pu provoquer l'anomalie que vous rencontrez ?
Avez-vous tenté une restauration à une date ou le site était fonctionnel et accessible correctement ?
Astérix
MErci pour la réponse.
Voici le numéro de ticket CS16225140.
Cordialement.
Merci pour le numéro du ticket de ticket, celui-ci a été mis à jour, n'hésitez pas à y répondre en cas de besoin
Astérix
J'ai eu aussi le même problème avec la même réponse lénifiante et sans intérêt à un ticket du même type : Le correspondant ne prenait absolument pas en compte ce que je lui disais.
Le système donnait aussi une erreur avec mon IP d'administrateur bannie. L'assistance au ticket m'a répondu (réponse automatique ???) plusieurs fois que la cause était que j'avais trop de requêtes par seconde (ce qui était faux d'après mes vérifications). Alors que le déblocage a été immédiat en supprimant une expression d'un simple texte plein ! 
. Donc rien à voir avec le nombre de requêtes.
Le système OVH (WAF) contrôlant mon blog m'interdit de parler dans un texte non informatique de éetcépassword (comme je me méfie des WAF OVH, ici j'ai remplacé les / par des é) comme si c'était du code exécutable. J'ai vérifié sur d'autres blogs sur le même système avec les mêmes effets. Cette protection vraiment beaucoup trop stricte est absurde... et l'assistance n'y comprend rien.
Oui, un VPS serait préférable mais ce n'est pas toujours adapté.
Salut @AlainR120
C’est frustrant, je te comprends
Est‑ce que cela t’arrive seulement dans la partie "admin" ou aussi quand tu visualises des produits dans le "frontend" ?
Tiens‑moi au courant.
Vous pouvez essayer de placer le texte offensif entre guillemets ou d’ajouter un espace, par exemple, / etc/passwd pour que le WAF ne le détecte pas comme un chemin.
Autre chose, si on vous dit que c’est à cause du nombre de requêtes, demandez qu’on examine les journaux du WAF afin qu’ils voient exactement quelle chaîne de texte est bloquée. C’est la seule façon d’être pris au sérieux.
Salut à tous.
Pour info après mes derniers echanges avec OVH c'est WooCommerce qui fait planter...
c'est l'utilisation de WooCommerce qui sollicite l'API en générant cette consommation inhabituelle.
Ca me parait totalement dingue...
Donc l'hébergement dit "Pro" ne permet pas d'utiliser WooCommerce ?!
Ca serait bien de le précisier avant que l'on souscrive non.
Bon courage à tous.