Erreur Cloudflare 1020 / 1015 : accès refusé et limitation de débit

Ce que signifie cette erreur et comment la reconnaître

• Une page d’erreur aux couleurs de Cloudflare s’affiche à la place du site ou de la ressource demandée.
• La page affiche explicitement Error 1020: Access denied ou Error 1015: You are being rate limited.
• La réponse inclut généralement un Cloudflare Ray ID, une heure approximative et le nom d’hôte concerné.
• L’erreur 1020 peut concerner une adresse IP, un chemin, un modèle de requête ou une condition de règle de sécurité précis, tandis que d’autres visiteurs continuent de se connecter.
• L’erreur 1015 peut disparaître lorsque l’activité des requêtes diminue, réapparaître lors de pics d’activité ou toucher les utilisateurs partageant une même IP publique via du NAT, un proxy ou une passerelle d’entreprise.
• La requête peut avoir été arrêtée au niveau de l’edge de Cloudflare avant d’être traitée par l’application d’origine. Comparez l’erreur aux journaux de l’origine au lieu de supposer que toutes les défaillances similaires ont la même cause.

Causes principales, classées par probabilité

Causes les plus probables

1. Un pare-feu, un WAF ou une règle de sécurité Cloudflare correspond à la requête (1020). La règle peut évaluer l’adresse IP source, le pays, le chemin URI, la méthode HTTP, les en-têtes, le user-agent ou un autre attribut de la requête.
2. Un seuil de limitation de débit configuré a été dépassé (1015). Des chargements de page répétés, l’interrogation périodique d’une API, des crawlers, des téléchargements parallèles, des tentatives de connexion ou de nombreux utilisateurs derrière une même adresse partagée peuvent déclencher la politique.
3. Une politique de sécurité est plus large que prévu. Une règle conçue pour un chemin d’administration ou du trafic abusif peut également correspondre à un visiteur légitime, un service de monitoring, un réseau d’entreprise ou un client d’API.
4. Un modèle d’adresse IP source partagé ou inhabituel a déclenché une correspondance. Les VPN, les proxies, le NAT opérateur et les passerelles d’entreprise peuvent donner l’impression que des utilisateurs sans lien entre eux proviennent d’une même adresse.
5. Une modification récente de la configuration Cloudflare a introduit le blocage. Cette hypothèse est particulièrement plausible lorsque l’erreur a commencé immédiatement après une modification du pare-feu, du WAF, de la protection contre les bots ou de la limitation de débit.

Ces erreurs ne constituent pas, à elles seules, la preuve que le serveur d’origine est hors service. Une requête bloquée peut ne jamais atteindre l’origine, tandis qu’un problème distinct au niveau de l’origine peut produire une réponse différente.

Comment corriger le problème

Si vous êtes visiteur

1. Enregistrez la page d’erreur complète. Notez si elle indique 1020 ou 1015, le Ray ID, l’horodatage, le fuseau horaire, le nom d’hôte ainsi que l’URL ou l’action qui a échoué. Ne partagez pas de mots de passe, de tokens ni d’autres données sensibles de la requête.
2. Arrêtez les tentatives rapides. Si l’erreur est 1015, attendez avant de réessayer. Les actualisations répétées, les onglets parallèles et les tentatives automatisées peuvent prolonger la limitation de débit ou la déclencher à nouveau.
3. Mettez en pause les sources de requêtes évitables. Arrêtez les gestionnaires de téléchargement, extensions de navigateur agressives, scripts, interrogations périodiques d’API, crawlers ou autres outils qui interrogent le même site de manière répétée. Si nécessaire, essayez une seule requête normale depuis un navigateur, sans VPN ni proxy, mais ne contournez pas un contrôle d’accès que vous n’êtes pas autorisé à contourner.
4. Vérifiez si le problème est limité ou généralisé. Un seul chemin, une action liée au compte ou un réseau peut être bloqué alors que d’autres pages fonctionnent. Une requête réussie depuis un autre réseau ne prouve pas que le site fonctionne correctement pour tout le monde.
5. Contactez l’opérateur du site. Fournissez le numéro de l’erreur, le Ray ID, l’horodatage, l’URL concernée, une description de ce que vous faisiez et votre adresse IP publique uniquement si l’opérateur la demande et si son partage est approprié.

Si vous gérez la zone Cloudflare

1. Confirmez la couche qui a généré la réponse. Vérifiez la présence de la marque Cloudflare, le numéro de l’erreur, le Ray ID et l’horodatage. Comparez l’événement aux journaux d’accès de l’origine ; s’il n’existe aucune requête correspondante au niveau de l’origine, le blocage s’est probablement produit au niveau de l’edge Cloudflare.
2. Pour l’erreur 1020, examinez les événements de sécurité et les règles correspondantes. Utilisez le Ray ID, l’heure, l’IP source et le chemin de la requête pour identifier la règle de pare-feu, le WAF, la règle personnalisée, la politique d’accès ou tout autre contrôle ayant refusé la requête. Examinez l’expression de la règle au lieu de désactiver tous les contrôles de sécurité.
3. Pour l’erreur 1015, examinez les statistiques et la configuration de la limitation de débit. Identifiez le nom d’hôte, le chemin, la méthode, l’identité du client et le seuil correspondants. Vérifiez si de nombreux utilisateurs légitimes partagent une adresse via du NAT, un proxy ou une passerelle d’entreprise.
4. Comparez les requêtes bloquées et autorisées. Examinez le chemin, la query string, la méthode, les en-têtes, le réseau source et la fréquence des requêtes. Cela aide à distinguer un faux positif d’un trafic réellement excessif ou malveillant.
5. Effectuez la plus petite modification autorisée. Rendez l’expression de la règle plus restrictive, corrigez une condition involontaire, créez une exception ciblée ou ajustez la politique de limitation de débit pour le endpoint concerné. Maintenez des contrôles plus stricts sur les chemins d’authentification et d’administration, sauf approbation contraire du responsable de la sécurité.
6. Testez prudemment et surveillez. Utilisez une requête de test autorisée représentant le trafic concerné. Vérifiez que l’accès légitime fonctionne tout en confirmant que la protection prévue se déclenche toujours pour le trafic qu’elle doit contrôler. Examinez les événements Cloudflare et les journaux de l’origine après la modification.
7. Faites remonter le problème avec des éléments probants si la correspondance n’est pas claire. Conservez le Ray ID, l’horodatage et le fuseau horaire, l’identifiant de la règle ou le nom de la politique, le nom d’hôte, le chemin, le contexte du réseau source et les détails pertinents de l’événement. Évitez de modifier les règles à répétition sans consigner chaque résultat.

Prévention et vérification du correctif

• Gardez les expressions du pare-feu et du WAF aussi ciblées que possible, en particulier pour les pages publiques, les API et les réseaux partagés.
• Définissez les limitations de débit avec la combinaison appropriée du chemin, de la méthode, de l’identité du client et du modèle de trafic, plutôt qu’avec un seuil global trop large.
• Tenez compte des adresses de sortie partagées liées au NAT, aux VPN, aux proxies et aux réseaux d’entreprise lors de l’évaluation du trafic légitime.
• Examinez les événements de sécurité après le déploiement ou la modification de règles, notamment le trafic des utilisateurs habituels, des systèmes de monitoring et des clients d’API.
• Donnez aux équipes de support une procédure standard pour recueillir le Ray ID, l’horodatage, le nom d’hôte et le chemin concerné au lieu de multiplier les tentatives.
• Documentez la différence entre les blocages au niveau de l’edge Cloudflare et les erreurs de l’origine afin que les intervenants consultent d’abord les bons journaux.
• Consignez les exceptions ciblées approuvées et réexaminez-les régulièrement ; évitez les allowlists permanentes et trop larges qui affaiblissent la protection.