Lorsqu’un site renvoie soudainement « error 503 backend fetch failed », il n’est pas toujours évident de savoir si la panne vient du cache ou du serveur applicatif. Avec Varnish, ce message signifie que le proxy n’a pas réussi à récupérer la réponse du backend, mais les logs et un test direct restent nécessaires pour identifier la cause.
Pour rétablir le service sans aggraver la situation, commencez par isoler la couche défaillante : vérifiez le backend directement, puis purgez ou contournez temporairement le cache si les observations le justifient. Un redémarrage ne doit intervenir qu’après ce premier diagnostic, avec une sauvegarde de la configuration et un contrôle des logs avant et après l’action.
Résumé
- Commencez par identifier si la panne vient du cache ou du backend, puis testez le backend en direct pour confirmer où la chaîne casse.
- L’erreur indique que le proxy n’a pas pu récupérer la réponse du serveur applicatif ; les logs peuvent notamment révéler un délai dépassé, une connexion refusée ou une réponse mal formée.
- Inspectez les logs et l’état du service avec les outils adaptés pour retrouver la cause exacte et isoler le composant en défaut.
- Appliquez ensuite les correctifs les plus sûrs en priorité, comme la purge ou le contournement du cache, avant d’ajuster durablement la configuration.
Que faire en urgence face à une erreur 503 ?
Selon la cause identifiée et après sauvegarde de la configuration, envisagez trois vérifications : purgez ou contournez temporairement le cache, testez le backend en direct et redémarrez proprement les services impactés. Si vous disposez des accès et compétences nécessaires, effectuez ces vérifications depuis un terminal SSH et contrôlez chaque résultat dans les logs.
Ordre de diagnostic
- Si le cache est en cause, effectuez une purge ciblée de Varnish ou activez temporairement return(pass) pour l’URL affectée.
- Testez directement le backend avec curl -v –max-time 10 http://127.0.0.1:8080/.
- Si les logs confirment un service bloqué, prévoyez un retour arrière puis redémarrez proprement le backend.
- Si le site revient après le contournement du cache, examinez la logique de cache et la configuration du proxy sans exclure une défaillance intermittente du backend.
Que signifie « Backend fetch failed » ?
L’intitulé error 503 backend fetch failed indique que la couche de cache/proxy (par ex. Varnish) n’a pas pu récupérer la réponse auprès du serveur applicatif. Cette réponse synthétique vient du proxy et non forcément du code applicatif.
Quelle est la cause technique derrière « backend fetch failed » ?
Les logs Varnish peuvent notamment révéler une connexion refusée ou une réponse HTTP mal formée ; selon la configuration, un délai de connexion ou de premier octet dépassé peut aussi interrompre le fetch. La cause exacte doit être établie à partir du tag FetchError et des logs du backend. Varnish appelle vcl_backend_error et renvoie le 503 quand la tentative de fetch échoue, comme décrit dans la documentation officielle guide de dépannage de Varnish.
Comment distinguer cette erreur des autres codes 5xx ?
Les codes 502, 503 et 504 peuvent tous apparaître dans une chaîne comportant un intermédiaire, mais leur interprétation dépend du serveur qui émet la réponse et de sa configuration. Dans le cas documenté par Varnish, le 503 « Backend fetch failed » appelle vcl_backend_error après l’échec du fetch ; consultez les transactions Varnish et les logs du backend pour identifier l’erreur originelle.
Comment diagnostiquer la source du problème ?
Commencez par collecter preuves et métriques : XID Varnish, statut backend, traces applicatives et état système. Suivez une séquence reproduisible pour isoler la couche fautive.
Quels logs et commandes vérifier en priorité ?
Filtrez les lignes liées au fetch dans Varnish : varnishlog -i FetchError et varnishncsa. Vérifiez les logs nginx/apache (error et access) et les logs d’application via journalctl -u nom-du-service –since “10 minutes ago”. Listez les backends connus avec varnishadm backend.list pour repérer ceux en état sick.
Comment tester le backend sans passer par le cache ?
En adaptant le port et le chemin à votre configuration, interrogez le service applicatif directement : curl -v –max-time 5 http://127.0.0.1:8080/health. Testez la connexion TCP avec telnet 127.0.0.1 8080 et vérifiez séparément l’écoute locale du port avec ss -tulnp | grep :8080. Si le backend répond correctement hors proxy, examinez en priorité la configuration du cache, sans exclure un défaut intermittent du backend.
Quels indicateurs surveiller pour repérer une saturation ?
Surveillez CPU et RAM via top ou htop, la mémoire libre avec free -m, et l’état des connexions ainsi que la limite de descripteurs avec ss -s et ulimit -n. En métriques, suivez latence médiane, p95, QPS et taux de 5xx. Une hausse simultanée de la latence et du taux de 5xx peut orienter vers une saturation, mais elle ne suffit pas à l’établir sans corrélation avec les ressources système et les logs applicatifs.
Comment corriger l’erreur et éviter qu’elle se reproduise ?
Appliquez d’abord des correctifs rapides : purgez le cache ou basculez temporairement en pass-through si le cache est impliqué. N’augmentez les timeouts et ne redémarrez les services, avec drainage du trafic, qu’après avoir identifié un symptôme compatible et prévu un retour arrière. Après confirmation par les logs, n’ajustez les limites liées aux en-têtes que si le tag FetchError signale des en-têtes trop nombreux ou trop longs, en suivant la documentation de votre version de Varnish. Traitez les fuites mémoire ou requêtes lentes seulement après les avoir mesurées ; des sondes de santé peuvent ensuite être configurées selon l’architecture. Documentez chaque intervention et, si une réponse de maintenance est nécessaire, configurez-la selon les pratiques de synthetic responses documentation Varnish sur les réponses synthétiques. Conservez les XID et les extraits de logs associés à chaque intervention afin de comparer précisément l’état du service avant et après correction.
