Error 503 backend fetch failed : diagnostiquer et corriger la panne

Temps de lecture estimé : 5 minutes

Que signifie « error 503 backend fetch failed » ?

L’erreur error 503 backend fetch failed apparaît quand un visiteur demande une page et que le serveur ne répond pas correctement à un intermédiaire. Cet intermédiaire, c’est souvent Varnish, un cache placé devant le site pour servir les pages plus vite.

Le trajet de la requête

Le trajet se déroule en trois temps. Le navigateur interroge Varnish. Si la page n’est pas en cache, Varnish la réclame au serveur d’origine, appelé backend. Si ce backend ne répond pas ou répond mal, Varnish renvoie l’erreur au visiteur.

Un 503 précis, pas un simple statut

Le code 503 signale, selon MDN Web Docs, une indisponibilité temporaire du service. Il existe pourtant des 503 de toute nature : maintenance, surcharge, quota dépassé. Ici, la mention « backend fetch failed » indique que la récupération auprès du serveur d’origine a échoué. Assimiler tous les 503 à la même panne mène à de mauvais correctifs.

« Guru Meditation » et XID

Sur la page d’erreur, Varnish affiche souvent « Guru Meditation » et un numéro appelé XID. Ce numéro identifie la requête fautive dans les journaux. Notez-le avec l’heure : c’est la clé du diagnostic côté administrateur.

Ouvrir l’infographie en grand

Que faire si vous êtes simple visiteur ?

Vous ne pouvez pas réparer cette panne, car elle se situe sur le serveur du site. Vos gestes se limitent à confirmer qu’elle dure et à prévenir.

• Attendez quelques minutes, puis rechargez la page.
• Testez une autre page du même site, pour voir si tout est touché.
• Consultez les réseaux sociaux ou la page d’état du site s’ils existent.
• Contactez l’assistance en lui indiquant l’heure et le XID affiché.

Vider le cache du navigateur, changer de navigateur ou redémarrer votre box ne corrige pas un backend en panne. Dans les faits, ces manipulations font perdre du temps.

Comment isoler la panne côté administrateur ?

Le bon réflexe est de partir de la ligne de log, pas de deviner. Voici l’ordre que j’applique avec mes clients.

1. Vérifiez l’état des backends et de leurs contrôles de santé dans Varnish.
2. Testez le serveur d’origine directement, sans passer par Varnish, par exemple avec un appel curl sur son adresse interne.
3. Relevez le XID et l’heure, puis cherchez les lignes FetchError dans varnishlog.
4. Croisez avec les journaux applicatifs et la charge du serveur (processeur, mémoire, processus saturés).

Si le serveur d’origine répond bien en direct, le problème se situe entre Varnish et lui : réseau, délai ou limite de configuration. S’il ne répond pas non plus, la panne est en amont.

Quelles causes correspondent aux messages des logs ?

Les valeurs ci-dessous sont les paramètres par défaut de la documentation Varnish Cache (version trunk). Vérifiez la version et la configuration en place avant de vous y fier.

no backend connection

Le backend est indisponible, ou la connexion n’aboutit pas dans le délai connect_timeout, fixé par défaut à 3,5 secondes. Le service est arrêté, l’adresse est fausse, ou le contrôle de santé l’a déclaré malade.

http first read error : EOF

Varnish a envoyé sa requête, mais la connexion s’est fermée avant le premier octet de réponse. Le délai first_byte_timeout vaut 60 secondes par défaut. Une page très lente à générer ou un processus qui plante en cours de route produisent ce message.

http read error : EOF

La réponse a commencé, puis s’est interrompue pendant le transfert. Le paramètre between_bytes_timeout, lui aussi à 60 secondes par défaut, encadre l’attente entre deux morceaux de données.

Réponse rejetée

Varnish refuse parfois une réponse dont les en-têtes dépassent ses limites. Par défaut, un en-tête de réponse est limité à 8 KiB (http_resp_hdr_len), l’ensemble des en-têtes à 32 KiB (http_resp_size) et leur nombre à 64 lignes (http_max_hdr). Ces limites concernent les en-têtes, pas le corps de la page.

Comment corriger la cause identifiée ?

Chaque message appelle une correction différente. Augmenter tous les délais d’un coup masque le problème sans le résoudre.

• Backend injoignable : relancez le service d’origine, réparez la route réseau ou corrigez le contrôle de santé.
• Lenteur ou coupure en lecture : réduisez d’abord la lenteur applicative (requête lourde, plugin gourmand, manque de mémoire), puis seulement ajustez les délais Varnish.
• En-têtes trop gros : relevez les limites uniquement si les logs pointent ce rejet, et cherchez aussi pourquoi l’application en envoie autant.

Redémarrer Varnish de façon systématique n’est pas une solution : cela vide le cache et peut aggraver la charge sur un backend déjà fragile. Après toute intervention, validez la configuration, rechargez-la, puis testez la page et surveillez varnishlog pour confirmer que les FetchError ont disparu.

Comment éviter une nouvelle interruption ?

Dans mon expérience, une panne de dix minutes fait peu de dégâts quand elle est détectée tout de suite. Elle en fait beaucoup quand c’est un client qui l’annonce.

• Mettez des alertes sur la santé du backend et sur le nombre d’erreurs de récupération.
• Prévoyez une page d’indisponibilité claire et, si possible, un en-tête Retry-After.
• Évaluez le service d’une copie en cache pendant la panne. Varnish prévoit une marge (default_grace, 10 secondes par défaut) et une durée de vie par défaut (default_ttl, 2 minutes quand ni le backend ni la VCL n’en fixent une). Votre configuration locale peut prévaloir.

Un 503 bref n’inquiète pas Google. Un 503 qui se prolonge peut en revanche ralentir l’exploration du site : vérifiez après coup que les erreurs ont disparu et que le robot est revenu.

Suivre les erreurs jusqu’à leur disparition complète reste le meilleur test pour savoir si l’error 503 backend fetch failed est derrière vous.