503 ou 403 instantané : vérifiez d'abord au-dessus de l'application

L'absence de latence est la première mesure

Le temps jusqu'au premier octet vous dit si l'application a fait un quelconque travail. Une erreur qui arrive à peu près au temps d'aller-retour réseau a été décidée sans elle. Une erreur générée par l'application porte le temps qu'elle a passé avant d'abandonner.

curl -s -o /dev/null -w 'code=%{http_code} ttfb=%{time_starttransfer} total=%{time_total}\n' https://site.example/
curl -sI https://site.example/

Les en-têtes nomment la couche la plupart du temps. Un en-tête Server ou Via qui appartient au edge ou au balancer plutôt qu'au serveur web, un X-Cache ou un identifiant de requête du edge, un corps en texte brut là où l'application rendrait un template : chacun dit qui a répondu. Avec cela en main, la checklist est courte.

La checklist, de haut en bas

Le CDN ou le edge. Une règle WAF, un rate limit, une règle géographique, un défi anti-bot, ou un problème de certificat entre le edge et l'origine, que le edge rapporte comme son propre 5xx. Contournez-le : résolvez le nom directement vers l'origine et répétez la requête.

curl -s -o /dev/null -w 'code=%{http_code} ttfb=%{time_starttransfer}\n' \
     --resolve site.example:443:ORIGIN_IP https://site.example/

L'origine répond 200, le edge répond 5xx : l'erreur appartient au edge, et la règle qui l'a produite aussi.

Le load balancer. HAProxy répond 503 de lui-même quand aucun backend n'est up, avec son propre en-tête Server et un corps d'une ligne. C'est une question de health check, pas d'application : un chemin de vérification changé au dernier déploiement, un port de vérification déplacé, ou un backend marqué down pour une raison visible sur la page de stats. Demandez un backend directement depuis l'hôte du balancer pour confirmer qu'il sert.

La couche plateforme. Un état de suspension ou de maintenance dans le panneau de contrôle, l'interrupteur de maintenance d'un outil de déploiement, un service mis à l'échelle zéro. Chacun sert une page fixe sans invoquer l'application, et chacun est un drapeau que vous pouvez lire, pas une théorie.

Les règles du serveur web. Une seule directive return, rewrite ou deny répond instantanément et paraît catastrophique. Exportez la configuration effective plutôt que le fichier que vous croyez chargé.

# nginx: the configuration actually in effect, with the rules that short-circuit a request
nginx -T 2>/dev/null | grep -nE '^\s*(return|rewrite|deny|allow)\b'

# IIS: the URL Rewrite rules for the site
appcmd list config /section:system.webServer/rewrite/rules

Sur Apache, lisez la chaîne .htaccess effective pour le chemin, pas seulement le vhost.

Le DNS. Confirmez que le nom se résout vers l'hôte que vous déboguez. Un enregistrement périmé, une différence de split-horizon ou un changement encore en propagation signifient que la machine que vous regardez n'est pas celle qui répond.

Les permissions et SELinux. Le serveur web ne peut pas lire le document root ou se connecter au socket upstream. Un 403 ou un 502 sans aucune ligne dans le log de l'application. Sur un système en mode enforcing, le journal d'audit nomme le refus et la correction est un module de politique, pas un changement de mode.

ausearch -m avc -ts recent | audit2why

Seulement maintenant, l'application. Les pools de workers, le runtime, les dépendances, le code. Chacun de ces points coûte cher à investiguer et ne peut pas être la cause d'une réponse que l'application n'a pas produite.

Deux détails qui prolongent la chasse

Un 429 a deux auteurs possibles. Un limiteur au edge y répond avec les en-têtes du edge lui-même et généralement un Retry-After. Un limiteur de l'application y répond depuis l'intérieur de l'application, avec les en-têtes de l'application et après que celle-ci a fait un certain travail. Le temps jusqu'au premier octet et les en-têtes les distinguent, et la correction se trouve à un endroit différent pour chacun.

Une page d'erreur peut survivre à sa cause. Les edges et les reverse proxies peuvent mettre un 5xx en cache un court moment, si bien que l'origine se rétablit et que le edge continue de servir l'erreur stockée jusqu'à son expiration. Un en-tête Age sur la réponse d'erreur dit qu'il s'agit d'une copie en cache. Purgez le chemin au edge, ou attendez la fin du TTL, avant de conclure que la correction n'a pas fonctionné.

Faites prouver chaque couche

Chaque étape ci-dessus associe une couche à une façon de la contourner : résoudre directement vers l'origine contourne le edge, demander un backend depuis l'hôte du balancer contourne le balancer, demander le port de l'application sur localhost contourne le serveur web. Le premier saut où la réponse passe de l'erreur au contenu est la couche à laquelle appartient l'erreur. La méthode est mécanique à dessein, et c'est ce qui la rend rapide à toute heure.