Le Hub · Proxy et cache
Une porte d’entrée,
et une mémoire pour les pages publiques.
Chaque visite passe par le Hub, qui l’envoie au bon programme. Ce qui peut être gardé en mémoire, une page publique, une feuille de style, est servi sans solliciter le programme.
À quoi ça sert
Sans point d’entrée commun, chaque programme a son serveur web à configurer, son certificat à poser, sa connexion à vérifier. Et chaque visite d’une page publique fait travailler le programme, même quand la page n’a pas changé depuis une heure.
Le proxy du Hub est la porte unique. Il lit le nom demandé et envoie la requête au conteneur qui le sert, sur le Hub ou sur une de vos machines rattachées. Il applique la connexion unique route par route. Il laisse passer le temps réel (WebSocket, flux continus) sans le retenir. Et, pour les programmes qui le demandent, il garde les réponses dans un cache à deux niveaux.
Ce qu’on voit à l’écran
L’écran Cache HTTP Gateway — Cache L1 (mémoire) + L2 (Redis) pour le reverse proxy, au 2026-09-23.
Quatre tuiles.
- 0.9 % Hit Rate : la part des requêtes servies depuis le cache.
- 3 Total Hits : trois réponses servies depuis le cache.
- 344 Total Misses : 344 requêtes passées au programme.
- 0 / 1000 Entrées L1 : le premier niveau, en mémoire, est vide sur mille places.
Les compteurs de succès et d’échecs partent du dernier démarrage du Hub.
Le tableau Hostname / Entrées L2 / Actions. Il donne, par nom d’hôte, les entrées du second niveau, gardé dans Redis, avec un bouton de purge par ligne. Ici : « Aucune entrée en cache. »
En bas, la mention « Cache active » : le cache fonctionne. En haut à droite, le bouton rouge Purger tout le cache.
Pourquoi presque rien en cache ? Parce que le cache s’active programme par programme, et qu’il ne garde pas, par défaut, les réponses faites à un utilisateur connecté. Sur ce Hub, la plupart des programmes sont des applications de travail derrière la connexion : il n’y a rien à garder pour elles. Le cache sert surtout aux sites publics — un WordPress, une forge, un tableau de bord public.
Comment on s’en sert
On active le cache d’un programme
À l’installation des logiciels qui s’y prêtent (WordPress, Gitea, Grafana), un réglage est proposé : Performance, Équilibre, Frais, ou Désactivé. Pour un programme déjà installé, le réglage est dans sa fiche, onglet « Proxy & SSO ».
On règle les durées
Par défaut, cinq minutes pour une page, vingt-quatre heures pour une image ou une feuille de style. Les chemins d’administration et d’API ne sont jamais gardés.
On vérifie dans le navigateur
Chaque réponse porte un en-tête X-Cache : HIT-L1, HIT-L2, MISS ou BYPASS. On sait si la page vient du cache.
On purge après une publication
Une application entière, un seul chemin, ou tout le cache, depuis cet écran.
Ce que ça vous évite
Vous n’avez pas un serveur web à configurer par programme : ajouter un programme, c’est ajouter une route. Vos pages publiques restent rapides un jour de forte affluence, parce qu’elles sont servies sans solliciter le programme. Et après une publication, un bouton suffit pour que tout le monde voie la nouvelle version.
Les limites d’aujourd’hui
Le proxy ne sonde pas les programmes : un programme démarré mais qui ne répond plus n’est pas signalé par lui. Et derrière Cloudflare, un envoi de plus de 100 Mo est refusé : pour de gros fichiers, il faut prévoir un second nom qui arrive directement au Hub.