Erreur Cloudflare 522 : délai de connexion dépassé - causes et corrections

Ce que signifie l'erreur 522

Chaque requête passée en proxy commence par Cloudflare qui ouvre une connexion TCP vers votre origine avant de pouvoir envoyer la requête HTTP elle-même. L'erreur 522 se déclenche quand ce handshake, le SYN TCP et le SYN-ACK attendu en retour, ne s'achève pas dans la fenêtre de délai de Cloudflare. L'origine est peut-être trop surchargée pour accepter de nouvelles connexions, un pare-feu abandonne peut-être silencieusement les paquets au lieu de les rejeter, ou le chemin réseau entre Cloudflare et l'origine est peut-être congestionné.

Cela diffère de l'erreur 521, où l'origine refuse activement la connexion, et de l'erreur 524, où la connexion TCP réussit mais la réponse HTTP elle-même n'arrive jamais à temps. L'erreur 522 est spécifiquement un échec au stade du handshake, avant même qu'une requête HTTP ne soit envoyée.

Comment l'erreur 522 apparaît

Les visiteurs voient la page de Cloudflare, « Error 522: connection timed out », avec un Ray ID. Une requête curl contre le domaine montre le même statut après à peu près la fenêtre de délai de Cloudflare :

curl -I https://example.com
HTTP/2 522

Puisque le handshake TCP n'a jamais abouti, aucune requête n'a atteint votre application, donc les journaux applicatifs sont généralement vides pour la période d'échec. Regardez plutôt les métriques au niveau de la connexion : la charge et le CPU du serveur au moment des erreurs, le nombre de connexions établies et en attente (ss -s ou netstat -an | grep SYN_RECV), et les journaux du pare-feu ou de l'équilibreur de charge pour des paquets abandonnés ou filtrés sur le port concerné.

Ce qui provoque l'erreur 522

• Le serveur d'origine est surchargé et ne peut pas accepter de nouvelles connexions assez vite. Un CPU élevé, une file d'attente de connexions pleine, ou un pool de workers épuisé produisent tous cela.
• Un pare-feu ou un groupe de sécurité abandonne silencieusement les paquets SYN de Cloudflare au lieu d'envoyer une réinitialisation TCP. Un abandon ressemble en tout point à un serveur lent ou mort vu du côté de Cloudflare, alors qu'une réinitialisation produirait plutôt l'erreur 521.
• Le keepalive TCP est désactivé sur l'origine, ce qui augmente le renouvellement des connexions et la probabilité qu'un nouveau handshake arrive à un moment où le serveur est trop occupé pour l'accepter.
• L'adresse IP de l'origine n'est pas correctement mise sur liste d'autorisation là où le réseau exige une liste d'autorisation explicite plutôt qu'une simple règle de pare-feu, donc les requêtes de Cloudflare sont filtrées avant d'atteindre le socket en écoute.
• Une congestion réseau ou une perte de paquets entre Cloudflare et l'origine, plus fréquente sur des origines derrière un hébergement grand public ou fortement surengagé.

522 face à 524

Les deux codes sont des délais dépassés, mais ils se produisent à des points différents de la requête. L'erreur 522 se produit avant qu'aucune requête HTTP ne soit envoyée : le handshake TCP lui-même ne s'achève jamais. L'erreur 524 se produit après : la connexion TCP réussit et Cloudflare envoie la requête HTTP, mais l'origine ne renvoie pas de réponse complète dans les 100 secondes. Un 524 pointe généralement vers une application lente, par exemple un point de terminaison de génération de rapport, une requête de base de données longue, ou une requête déclenchée par cron qui prend légitimement plusieurs minutes. La correction pour un 524 est presque toujours d'accélérer le point de terminaison ou de sortir le travail lent du cycle requête-réponse vers une tâche en arrière-plan que le client interroge pour obtenir un résultat ; les forfaits Cloudflare Enterprise peuvent aussi relever la limite de 100 secondes pour des routes spécifiques, mais cela traite le symptôme plutôt que le point de terminaison lent lui-même.

Comment savoir de qui vient la faute

Un 522 provient presque toujours de l'origine ou de son voisinage, puisque le propre réseau de Cloudflare est hautement disponible et rarement la source d'un délai de handshake dépassé. La question utile est de savoir si l'origine est complètement en panne ou simplement en difficulté sous la charge de certaines régions. Le moyen le plus rapide de vérifier est de lancer une vérification HTTP depuis plusieurs emplacements à la fois : la vérification HTTP de HostTracker interroge le domaine depuis des points de contrôle dans plusieurs pays et rapporte chacun séparément, donc un schéma où certains emplacements dépassent le délai et d'autres réussissent pointe vers un serveur surchargé traitant certaines requêtes mais pas toutes, alors qu'un délai dépassé uniforme partout pointe vers une origine totalement en panne ou un pare-feu abandonnant chaque connexion.

Comment corriger l'erreur 522

Si vous êtes visiteur

1. Rechargez après une courte attente. Un pic momentané de charge ou un bref accroc réseau se résorbe souvent tout seul.
2. Vérifiez la page de statut du site, s'il en a une, pour un incident connu.
3. Il n'y a rien à corriger de votre côté. Le délai dépassé se produit entre Cloudflare et le propre serveur du site, pas dans votre navigateur ou votre connexion à Cloudflare.

Si vous gérez le site

1. Vérifiez la charge du serveur et la capacité de connexion disponible au moment des échecs : CPU, mémoire, et les limites de connexion ou de worker configurées du serveur web (par exemple worker_connections de nginx).
2. Confirmez que votre pare-feu ou groupe de sécurité autorise les plages IP publiées de Cloudflare sur le port concerné, et qu'il rejette avec une réinitialisation plutôt que d'abandonner silencieusement les paquets, ce qui transforme au moins un 522 en 521 plus facile à diagnostiquer.
3. Activez le keepalive TCP sur le serveur web de l'origine et tout équilibreur de charge devant lui, et vérifiez que les réglages de keepalive au niveau système ne sont pas laissés à des valeurs par défaut bien plus longues que ce dont la connexion a réellement besoin.
4. Si votre hébergement ou votre réseau cloud exige une liste d'autorisation IP explicite séparée du pare-feu, confirmez que l'IP de l'origine y figure.
5. Chronométrez le handshake brut directement contre l'origine, en contournant Cloudflare, pour voir si le délai vient du fait même d'atteindre votre serveur :

   curl -v -H "Host: example.com" --connect-timeout 5 https://ORIGIN_IP/

   Une connexion qui reste bloquée ici confirme que l'origine elle-même est lente à accepter les connexions, pas quelque chose de spécifique à Cloudflare.
6. Pour des points de terminaison individuels lents plutôt qu'un serveur globalement surchargé, sortez le travail long (rapports, exports, tâches par lots) du chemin de la requête vers une tâche en arrière-plan que le client interroge ou dont il est notifié, et n'envisagez une augmentation du délai Cloudflare Enterprise que comme un pis-aller pour des routes que vous ne pouvez pas accélérer rapidement.

Comment le prévenir

Un serveur qui échoue son handshake seulement sous une charge de pointe passera avec succès chaque vérification manuelle que vous lancez vous-même, puisqu'il est peu probable que vous le testiez exactement au moment où il est en difficulté. Une vérification HTTP qui s'exécute selon un calendrier depuis l'extérieur de votre réseau détecte cette fenêtre d'échec même quand personne ne surveille, et l'exécuter depuis plusieurs pays montre si le ralentissement est une capacité globale ou un chemin réseau régional.

Erreurs associées

• Erreur Cloudflare 520 : erreur inconnue - l'origine a répondu, mais la réponse était inutilisable.
• Erreur Cloudflare 521 : le serveur web est en panne - l'origine a refusé la connexion au lieu de ne pas répondre.
• Erreurs serveur 5xx - la famille générale de codes de statut.
• 502 Bad Gateway - la version non spécifique à Cloudflare d'un échec upstream.

Questions fréquentes

Combien de temps Cloudflare attend-il avant d'afficher l'erreur 522 ?

Environ 15 secondes pour le handshake TCP. Si l'origine n'a pas accepté la connexion d'ici là, Cloudflare abandonne et renvoie 522 au visiteur.

Le 522 est-il la même chose que mon serveur en panne ?

Pas toujours. Cela peut aussi signifier que le serveur fonctionne mais est trop occupé pour accepter une nouvelle connexion à temps, ou qu'un pare-feu abandonne la tentative de connexion sans envoyer de réinitialisation.

Pourquoi un pare-feu abandonne-t-il une connexion au lieu de la rejeter ?

Certaines configurations de pare-feu ou de groupe de sécurité par défaut jettent silencieusement les paquets qui ne correspondent à aucune règle d'autorisation au lieu d'envoyer une réinitialisation TCP. Cet abandon silencieux est ce qui transforme ce qui pourrait être un 521 rapide et clair en un 522 plus lent et plus ambigu.

Le 522 signifie-t-il que je dois faire évoluer mon serveur ?

Pas nécessairement. Avant de monter en puissance, vérifiez si le keepalive est désactivé, si le pare-feu abandonne silencieusement les plages de Cloudflare, et si les limites de connexion dans la configuration du serveur web sont fixées plus bas que ce que le trafic exige réellement.

Quelle est la différence entre 522 et 524 ?

522 est un échec à même achever le handshake TCP. 524 est une connexion achevée où la réponse HTTP elle-même prend trop de temps, généralement à cause d'une logique applicative lente plutôt que d'un problème réseau ou de capacité.

Une seule requête de base de données lente peut-elle causer un 522 ?

Pas directement, puisque le 522 se produit avant qu'aucune requête ne soit envoyée. Une requête lente est plus susceptible de produire un 524, où la connexion a réussi mais la réponse a mis trop de temps à arriver.