React Hooks avancés : useEffect, useContext, et custom hooks
Introduction Les hooks React sont la fondation des applications modernes. Après avoir maîtrisé useState, il…
Estimated reading time: 5 minutes
Chaque fois que je montais un nouveau reverse proxy ou un bloc PHP-FPM pour un des sites du homelab, je repartais du même point : rouvrir un de mes propres articles, copier-coller le bloc nginx qui correspondait à peu près, vérifier à la main que je n’avais pas oublié un header de sécurité. Ça a fini par m’agacer assez pour que je construise un outil qui fait ça correctement, une bonne fois : tools.arewel.com.
Le problème que je voulais régler
J’ai écrit pas mal d’articles ici sur des configs nginx et Caddy : Traefik vs Nginx Proxy Manager, le firewall OPNsense, la checklist de sécurisation d’un VPS Debian. À chaque fois, je repars d’une base à moitié mémorisée et je re-vérifie les mêmes détails : est-ce que proxy_set_header X-Forwarded-Proto est bien là, est-ce que le socket PHP-FPM est au bon endroit, est-ce que j’ai mis les en-têtes de sécurité ou juste oublié comme la dernière fois.
Plutôt que de garder ça dans un bloc-notes personnel, j’ai construit un site qui génère la config à ma place et qui te dit, avec une note, ce qui manque.
Ce que j’ai fait
tools.arewel.com tourne entièrement dans le navigateur. Aucune donnée n’est envoyée nulle part, ce qui compte pour moi : je génère parfois des configs avec des noms de domaine ou des chemins internes que je préfère ne pas balancer à un service tiers, même gratuit.
Le site propose neuf générateurs, chacun disponible en version nginx et Caddy en parallèle :
- Reverse proxy — le cas le plus courant, avec headers X-Forwarded-* et gestion du websocket upgrade
- Site statique — servir un dossier, avec cache-control et compression
- PHP-FPM — socket Unix ou TCP, timeouts, séparation des chemins sensibles
- Load balancer — round-robin ou least-conn selon les upstreams
- nginx.conf complet — le fichier de base, pas juste un bloc
server - CI/CD — snippets pour valider une config avant déploiement
- CSP — Content-Security-Policy, le genre de header que tout le monde configure trop large par flemme
- Fail2Ban — jails prêtes pour les patterns nginx les plus courants
- Bot block — filtrage User-Agent pour les scrapers évidents
Chaque config générée reçoit une note de sécurité, en lettre (A à F), avec le détail de ce qui a fait perdre des points : header manquant, TLS mal configuré, absence de rate limiting sur un endpoint sensible. L’idée n’est pas de remplacer une vraie revue de sécu, mais d’éviter les oublis bêtes qu’on refait tous les six mois parce qu’on a la mémoire courte.
J’ai ajouté une section apprendre à côté des générateurs : quinze articles courts qui expliquent, pour chaque scénario, l’équivalent nginx et Caddy côte à côte. Pas pour remplacer la doc officielle, mais pour avoir la comparaison directe sans rouvrir deux onglets.
Ce qui coince
Le fait que tout tourne côté navigateur, c’est une qualité et une limite en même temps. Il n’y a aucune validation contre un vrai serveur : pas de nginx -t, pas de vérification que ton certificat existe vraiment au chemin indiqué. La config générée est un bon point de départ, pas une garantie que ça va démarrer du premier coup chez toi.
Le scope est aussi volontairement limité à neuf scénarios. Pas d’Apache, pas de Traefik alors que j’en ai parlé ici, pas de HAProxy. Rate limiting a un article dans la section apprendre mais pas encore de générateur dédié, ce qui est l’incohérence la plus visible du site en ce moment. Et la notation de sécurité reste générique : elle ne connaît pas ton threat model, juste un ensemble de règles courantes. Un A ne veut pas dire que ta config est inattaquable, juste qu’elle évite les erreurs classiques.
Résultat
Depuis que je l’utilise pour mon propre homelab, je n’ai plus rouvert un vieil article à moi pour copier un bloc nginx. Je génère, je compare la note nginx et Caddy pour le même scénario, je colle le résultat et j’ajuste les deux ou trois lignes spécifiques à mon cas (nom de domaine, chemin du socket). Ça remplace un bloc-notes personnel qui trainait depuis un moment et qui n’était de toute façon jamais à jour.
Si tu gères tes propres services exposés à la maison, ça peut t’éviter les mêmes oublis que moi. Le site est gratuit et sans compte à créer.
Prochaines étapes
Le générateur de rate limiting est la prochaine évidence à combler. Après ça, je regarde soit HAProxy, soit une intégration directe avec CrowdSec plutôt que Fail2Ban seul, vu que j’en ai parlé ici récemment. Rien n’est figé, ça dépendra de ce qui me manque réellement la prochaine fois que je monte un service.