Ce signal émerge d’un incident réel où la topologie réseau implicite a produit un symptôme de panne applicative, illustrant une tension fréquente entre orchestration de services et diagnostic précis.
Les architectures modernes reposent de plus en plus sur des reverse-proxy (Traefik, Nginx, Envoy) placés devant des services conteneurisés, souvent connectés à plusieurs réseaux Docker pour des raisons de segmentation, de sécurité ou d’organisation.
Dans ce type de configuration, le reverse-proxy agit comme point d’entrée unique, concentrant à la fois l’exposition publique, la gestion TLS et une partie du diagnostic visible en cas d’erreur.
Dans un environnement multi-network Docker, l’absence de spécification explicite du réseau Traefik pour un service peut conduire à ce que le proxy tente de joindre une IP inatteignable, causant un timeout de proxy visible malgré un backend sain.
Une erreur de type 504 Gateway Timeout peut apparaître alors que le backend applicatif est sain, fonctionnel et répond correctement lorsqu’il est interrogé directement sur la bonne interface réseau.
Dans un contexte multi-network, le reverse-proxy peut tenter de joindre le service via une adresse IP associée à un réseau auquel il n’est pas connecté.
Dans une configuration explicite, le proxy devrait cibler l’interface réseau réellement atteignable par le backend ; ici, l’absence de contrainte explicite laisse le reverse-proxy sélectionner une interface invalide.
La requête n’échoue pas immédiatement : elle attend jusqu’au timeout, puis remonte une erreur générique.
Le signal observé est donc le suivant :
une erreur de topologie réseau est traduite en panne applicative, sans indication explicite de la cause réelle.
Ce mécanisme crée une illusion de lenteur ou de défaillance backend :
- l’application ne logue rien d’anormal,
- les métriques système restent stables,
- le proxy devient le seul point visible de l’échec.
# Extrait anonymisé de labels (Docker/Traefik)
traefik.enable=true
traefik.http.routers.blog.rule=Host(`blog.example.tld`)
traefik.http.routers.blog.entrypoints=websecure
traefik.http.routers.blog.tls.certresolver=le
traefik.http.services.blog.loadbalancer.server.port=80
# (absence volontaire) traefik.docker.network=<network partagé avec Traefik>Ce comportement a été observé concrètement lors de la mise en place de l’infrastructure de claralicious.dev.
Ce type de situation déplace le diagnostic vers le mauvais niveau :
on cherche une cause applicative là où le problème est structurel.
# Depuis le container Traefik : le backend répond vite
$ curl -I --max-time 2 http://<service>:80/
HTTP/1.1 200 OK
# Depuis l’extérieur via HTTPS (proxy) : timeout puis 504
$ curl -sk -o /dev/null -w "HTTP %{http_code} | %{time_total}s\n" https://blog.example.tld/
HTTP 504 | 30.10s
# Le même service a 2 IP (multi-network) :
web: 172.18.x.y -> joignable depuis Traefik
internal: 172.19.x.y -> non joignable depuis Traefik
# Depuis Traefik :
$ curl -I http://172.18.x.y:80/ # OK
$ curl -I http://172.19.x.y:80/ # timeoutDes situations similaires sont régulièrement observées dans des environnements fortement orchestrés : des timeouts proxy apparaissent alors que les services sont fonctionnels, des erreurs semblent applicatives alors que les causes sont liées à des choix implicites d’acheminement, de réseau ou de middleware.
À mesure que les stacks deviennent plus segmentées et orchestrées, ces erreurs implicites risquent de se multiplier, surtout lorsque les outils masquent leurs choix internes (sélection d’IP, ordre des réseaux, comportements par défaut).
Ce type d’incident illustre une tension déjà observée entre abstraction technique et lisibilité des systèmes :
Ce signal rappelle que :
- l’infrastructure n’est pas neutre,
- les abstractions “simplifiantes” déplacent parfois la complexité au lieu de la réduire,
- et que certaines pannes sont en réalité des erreurs de lecture du système plutôt que des erreurs du système lui-même.
L’orchestration croissante des flux applicatifs renforce ce type de glissement de responsabilité (n8n devient un vrai cerveau d’orchestration).
Add new comment