L’error 503 Backend fetch failed apparaît quand un reverse proxy – Varnish dans la grande majorité des cas – envoie une requête au serveur d’origine et n’obtient aucune réponse valide en retour. Le visiteur voit une page blanche, le monitoring s’emballe, et la cause réelle reste souvent invisible dans les logs applicatifs. Sur un site à fort trafic, ce type de panne a une dynamique particulière : elle s’emballe vite et se résout rarement en supprimant un plugin.
Varnish, le backend et la rupture de communication
Varnish agit comme un intermédiaire entre le visiteur et le serveur web (Apache ou Nginx). Quand le cache ne peut pas servir une réponse stockée – parce que la ressource a expiré ou n’a jamais été mise en cache – il interroge le backend. Si ce dernier ne répond pas dans le délai configuré, Varnish génère lui-même le 503 avec le message « Backend fetch failed ».
Ce message est donc produit par Varnish, pas par Apache ou Nginx. C’est un point que les logs serveur standard ne révèlent pas directement : le backend peut apparaître silencieux dans ses propres journaux alors que Varnish accumule les erreurs. Les logs à consulter en premier sont ceux de Varnish, via varnishlog ou varnishstat, pas les access logs Apache.
Le timeout configuré dans Varnish (paramètre first_byte_timeout) définit combien de temps le proxy attend avant d’abandonner. Sur des serveurs correctement dimensionnés, cette valeur n’est jamais atteinte en temps normal. Quand elle l’est, c’est que le backend est saturé ou bloqué.
Pourquoi les sites à fort trafic saturent le backend différemment
Un site sous charge modérée tombe rarement en 503 même mal configuré. La panne devient systématique à partir du moment où les requêtes simultanées dépassent la capacité de traitement réelle du backend. Plusieurs mécanismes aggravent alors la situation.
Le premier est l’effet d’empilement : quand le backend ralentit, les requêtes en attente s’accumulent, ce qui augmente encore la charge et ralentit davantage le traitement. Sans limite de file d’attente, le serveur finit par consommer toute sa mémoire en gérant des connexions qui attendaient depuis trop longtemps – y compris des connexions abandonnées côté client, mais dont le traitement côté serveur continue.
Le deuxième mécanisme est celui des tentatives automatiques. Quand un client ou une couche applicative reçoit un 503, il relance souvent la requête immédiatement. Plusieurs couches qui relancent simultanément multiplient la charge au pire moment, c’est-à-dire quand le backend est déjà à saturation. Ce comportement transforme une surcharge temporaire en panne prolongée.
Le mode grace de Varnish : servir du cache périmé plutôt que rien
Varnish propose un mécanisme conçu précisément pour ce scénario : le mode « grace ». Quand le backend est indisponible, Varnish peut continuer à servir une version expirée du cache plutôt que de retourner un 503 aux visiteurs.
La configuration se fait dans le fichier VCL (Varnish Configuration Language). On définit un délai de grace pendant lequel le contenu périmé reste servi, et un délai de « keep » plus long pendant lequel Varnish conserve l’objet en mémoire pour pouvoir relancer une tentative en arrière-plan. Ce mécanisme protège l’expérience utilisateur pendant les pannes courtes et réduit la pression sur un backend déjà fragilisé.
- Grace active : Varnish sert le contenu expiré dès que le backend dépasse le first_byte_timeout, sans attendre une décision explicite.
- Bereq.is_bgfetch : Varnish lance une requête en arrière-plan pour rafraîchir le cache pendant que le visiteur reçoit la version ancienne, sans bloquer la réponse.
- Saint mode : si plusieurs tentatives vers le même backend échouent, Varnish peut basculer vers un backend alternatif ou marquer le serveur comme temporairement indisponible.
Dimensionnement et configuration durables pour éviter le 503
Le mode grace achète du temps, mais ne résout pas la cause. Sur un site à fort trafic, la solution durable repose sur deux leviers : le dimensionnement réel du backend et la configuration des limites.
Côté PHP-FPM (le cas le plus courant avec WordPress ou Drupal), le nombre de workers simultanés définit la capacité de traitement réelle. Quand toutes les connexions sont occupées, les nouvelles requêtes attendent – jusqu’à ce que le timeout Varnish les abandonne. Augmenter pm.max_children sans augmenter la RAM disponible provoque des swaps et ralentit davantage l’ensemble.
Côté Varnish, les paramètres à ajuster selon la charge réelle du site sont les suivants :
- first_byte_timeout : délai avant que Varnish abandonne une requête en attente. Une valeur trop courte génère des 503 sur des requêtes légitimement lentes ; une valeur trop longue accumule des connexions mortes.
- connect_timeout : temps maximum pour établir la connexion TCP avec le backend. Révèle les problèmes réseau entre le proxy et le serveur.
- max_connections par backend : limite le nombre de connexions simultanées que Varnish ouvre vers un backend donné, ce qui protège le serveur d’origine d’un afflux incontrôlé.
Ces valeurs dépendent du type de pages générées (temps de génération d’une page dynamique complexe vs statique), de la RAM disponible et du profil de trafic. Il n’existe pas de valeur universelle : un site e-commerce avec des pages de panier non cachables ne se configure pas comme un blog à fort trafic dont 95 % des pages sont servies depuis Varnish.
Rejeter tôt plutôt que tomber en cascade
Un principe moins évoqué mais documenté dans les pratiques SRE : un 503 renvoyé rapidement vaut mieux qu’un 503 renvoyé après avoir épuisé toutes les ressources. Quand le backend signale qu’il est saturé, continuer à lui envoyer des requêtes aggrave la situation.
Plusieurs approches permettent de limiter les dégâts en cascade. La première est de borner les files d’attente : une requête qui a attendu plus longtemps que le délai maximum cumulé de toutes les couches de l’application ne devrait plus être traitée, parce que le client a déjà abandonné. Consommer des ressources pour une réponse que personne ne recevra contribue à maintenir la saturation.
La deuxième est de définir à l’avance quelles fonctions peuvent être dégradées. Sur un site e-commerce, le catalogue peut être servi depuis le cache Varnish même si la partie compte client est indisponible. Cette granularité suppose d’avoir conçu l’architecture en conséquence, mais elle change radicalement la résilience perçue par les visiteurs lors d’un pic de trafic.
Diagnostiquer une error 503 Backend fetch failed sur un site à fort trafic revient donc à identifier précisément à quelle couche le délai se produit : réseau entre Varnish et le backend, saturation des workers PHP, lenteur de base de données, ou configuration de timeouts inadaptée à la charge réelle. Les logs Varnish donnent la réponse en quelques minutes – à condition de les lire avant de toucher quoi que ce soit d’autre.
