Erreur HTTP 509 : comprendre, diagnostiquer et résoudre

Procédure

Qu'est-ce que l'erreur 509 ?

Le code d'erreur HTTP 509 signifie que le site dépasse les limites de ressources prévues par sa formule d'hébergement. Le serveur refuse alors temporairement de traiter une partie ou l'ensemble des requêtes lié à la formule d'hébergement.

Deux limites peuvent déclencher cette erreur :

• Connexions simultanées : nombre de connexions HTTP ouvertes au même instant
• Volume de requêtes : nombre de requêtes sur une période

Une limite, pas un blocage

L'erreur 509 n'est pas un blocage et ne peut donc pas être levée manuellement, ni par le client ni par le support. Elle disparaît automatiquement dès que la consommation du site repasse sous les limites de sa formule.

Si l'erreur revient régulièrement, la cause de la surconsommation est toujours présente : il faut l'identifier et la traiter (voir les sections suivantes).

Situations fréquentes

Dans la pratique, l'erreur 509 apparaît le plus souvent dans l'un des cas suivants :

• Trafic légitime trop important pour la formule : le site reçoit plus de visiteurs que ce que sa formule peut absorber.
• Robots SEO et IA trop actifs : des crawlers explorent le site de façon intensive, parfois des milliers de pages par heure.
• Attaque DDoS : un grand nombre de requêtes malveillantes cherche à saturer le site.
• Ressource HTTP mal optimisé : un URL est fortement sollicité (campagne publicitaire, viralité organique ...) mais celui-ci requiert un volume important de ressources pour être traitée (pas de cache de page, requête SQL mal optimisé ...)
• Bug générant une boucle de requêtes : par exemple un script AJAX qui appelle la même URL en boucle.
• Site infecté ou piraté : des pirates utilisent le site pour héberger des landing pages de phishing ou de campagnes frauduleuses, qui attirent un trafic important.

Diagnostiquer l'origine du problème

Le log d'accès du site web est la source principale pour comprendre quelles requêtes provoquent l'erreur.

1. Depuis votre interface cPanel, récupérez le log d'accès lié au site web concerné.
2. Repérez les URL les plus sollicitées : une même ressource appelée en boucle indique souvent un bug ou une page ciblée.
3. Repérez les adresses IP et les user-agents les plus fréquents : des noms comme Googlebot, Bingbot, GPTBot, ClaudeBot ou AhrefsBot signalent des robots.
4. Comparez avec un outil de statistiques côté navigateur (Google Analytics ou équivalent).

La comparaison de l'étape 4 est décisive. Un outil comme Google Analytics fonctionne en JavaScript : il ne compte que les vrais visiteurs dont le navigateur exécute le script. Si le log d'accès montre beaucoup plus de requêtes que les visites mesurées par Analytics, l'écart provient très probablement de robots, d'une attaque ou d'appels automatisés.

Des URL inconnues ou suspectes dans le log (pages que vous n'avez pas créées, chemins vers des fichiers PHP inhabituels) doivent faire penser à un piratage.

Les deux solutions possibles

Pour mettre fin durablement à l'erreur 509, deux options existent :

• Migrer vers un VPS : adapté lorsque le trafic est légitime et que le site a simplement dépassé les capacités d'un hébergement mutualisé. Un VPS offre des ressources dédiées, sans ces limites de connexions et de requêtes.
• Réduire la consommation : adapté lorsque la surconsommation vient de robots, d'attaques, d'un bug ou d'un cache mal exploité. Les outils décrits ci-dessous permettent de diminuer le nombre de requêtes et de connexions HTTP.

Avant d'envisager une migration, il est recommandé de vérifier dans les logs que le trafic est bien légitime : migrer un site piraté ou bombardé de robots ne règle pas la cause.

Outils pour réduire la consommation

Limiter l'exploration avec robots.txt

Le fichier robots.txt, placé à la racine du site, indique aux robots SEO et IA quelles pages ils peuvent explorer. Vous pouvez y interdire des répertoires entiers ou certains robots IA dont vous n'avez pas besoin. Vous pouvez également définir un temps d'attente minimum entre l'exploration de deux pages.

Exemple :

User-agent: GPTBot
Disallow: /

User-agent: Claudebot
Crawl-Delay: 60

User-agent: *
Disallow: /panier/
Disallow: /*?filtre=

Ceci est particulièrement utile lorsque votre site web est submergé par des robots d'explorations. En effet, depuis l'essor des robots d'entraînements IA, certains robots effectuent le maximum d'exploration, parfois inutiles. Par exemple, les robots IA sont particulièrement connus pour essayer toutes les combinaisons de filtres et de tri possibles sur les pages de liste de produits.

Au delà de votre bande passante gaspillé pour ce type de crawling, les robots SEO et IA peuvent considérer que votre site web a beaucoup trop de pages. Ils peuvent ainsi arrêter l'exploration sans avoir fini d'explorer l'ensemble de votre site web, ce qui vous pénalise dans votre référencement. Il est dans votre intérêt de limiter les pages explorés afin que les robots puissent se concentrer sur les pages qui apportent le plus de valeur en terme de référencement SEO et GEO.

Les robots respectueux suivent ces règles ; les robots malveillants les ignorent, d'où l'intérêt des outils suivants.

LWS Protect

LWS Protect regroupe trois protections utiles contre l'erreur 509 :

• Rate limiting des robots : limite la fréquence des requêtes des robots SEO et IA sans les bloquer totalement.
• Anti-DDoS agressif : soumet les navigateurs à un challenge JavaScript. Les vrais visiteurs passent, les scripts automatisés sont arrêtés.
• Blocage des IP à mauvaise réputation : filtre les adresses connues pour du spam, des attaques ou du scraping.

Consultez la documentation de LWS Protect pour en savoir plus.

Fastest Cache

Le système de cache Fastest Cache permet de servir une version déjà générée des pages. Le serveur n'exécute plus PHP / Node.js / Python ni les requêtes à la base de données pour chaque visite, ce qui réduit les ressources consommées et le temps de chargement. C'est particulièrement important pour une page ciblée par une campagne publicitaire.

Si la page concernée est dynamique (contient des parties variables selon le visiteur connecté, le pays connercté ...), vous pouvez mettre en place du cache partiel : vous chargez d'abord le squelette de la page et le contenu statique qui est identique pour tous les visiteurs, puis vous chargez le contenu dynamique par requête asynchrone Javascript. Vous pouvez ainsi mettre en cache le contenu statique.

Pour en savoir plus sur l'utilisation de Fastest Cache, consultez la documentation du produit.

Mode Under Attack de Cloudflare

Si le site passe par Cloudflare, le mode « Under Attack » impose une vérification aux visiteurs avant l'accès au site. Il est utile pendant une attaque DDoS, mais à désactiver une fois l'attaque terminée car il ralentit le premier accès des visiteurs.