Plateforme · Reverse proxy
Une seule porte d’entrée,
bien gardée.
Chaque visite passe par le Hub. Il l’envoie au bon programme, sert du cache ce qui peut l’être, vérifie la connexion quand il le faut et refoule les robots qui cherchent une faille.
Ce que ça vous évite
Un serveur web à configurer par programme
Il n’y a qu’une porte d’entrée. Ajouter un programme, c’est ajouter une route.
Les pages lentes sous la charge
Les réponses qui peuvent l’être sont servies depuis le cache, sans solliciter l’application.
Les journaux pleins de tentatives d’intrusion
Les robots qui testent des failles connues sont bloqués avant d’atteindre vos programmes.
Ce que fait le Hub
Routage par nom
Le Hub lit le nom demandé et envoie la requête au conteneur qui le sert, sur le Hub ou sur un minihub distant, par son tunnel.
Temps réel et gros volumes
WebSocket et flux SSE traversent le proxy sans être mis en mémoire tampon : un tableau de bord en direct ou une réponse d’IA en continu arrivent au fil de l’eau.
Cache à deux niveaux
Un premier niveau en mémoire, un second dans Redis, avec une durée de vie par nom et par chemin. On purge une application, un chemin, ou tout.
Connexion par route
Chaque route choisit son niveau : publique, connexion facultative, connexion obligatoire. Un site peut être public et son administration protégée.
ScanGuard
Un filtre reconnaît les motifs d’attaque (injection SQL, XSS, lecture de fichiers système…) et les chemins que seuls les robots demandent. On voit les plus fréquents, on ajoute des motifs, on pose des exceptions par nom.
État
Opérationnel sur le Hub thesocle.net (3.51.1, relevé du 2026-09-23).
Limite actuelle : le Hub ne sonde pas les applications en HTTP. Il juge de leur santé par l’état de leur conteneur : un programme démarré mais qui ne répond plus n’est pas signalé par le proxy. La surveillance applicative se fait par le tableau de bord de chaque application.