Ah oui, et si vous utilisez un pare-feu comme UFW (ce que je vous recommande chaudement), n'oubliez pas d'ouvrir le port 81 : ufw allow 81. Sinon, vous allez pleurer devant une page blanche et vous demander pourquoi ça marche pas.
docker-compose up -d
Et voilà ! C'est tout. Votre serveur tourne. Si vous avez des erreurs, c'est probablement parce que vos ports sont déjà utilisés. Ou que les dossiers data, Let's Encrypt et MySQL n'existent pas encore. Moi j'ai ça sur mon NAS :
La configuration que même ma grand-mère pourrait le faire
Ouvrez votre navigateur et allez sur http://votre-ip:8181 et créez vous un compte.
Une fois dedans, pour exposer un service, c'est ridicule tellement c'est easyyyy
- Cliquez sur "Add Proxy Host".
- Entrez votre nom de domaine (ex:
nextcloud.mondomaine.fr).
- Indiquez l'IP de la machine et le port du service (ex:
8080).
- Allez dans l'onglet "SSL", cochez "Request a new SSL Certificate" et "Force SSL".
- Sauvegardez.
En fait, le seul truc qui peut coincer, c'est la propagation DNS. Si vous venez d'acheter votre nom de domaine il y a 5 minutes, pas de panique si Let's Encrypt refuse de générer le certificat. Attendez une petite heure et réessayez. C'est classique.
Et hop, fini. Votre service est accessible en HTTPS, avec le petit cadenas vert qui va bien. Nginx Proxy Manager s'occupe de discuter avec Let's Encrypt et de renouveler le certificat tout seul. C'est carrément magique.
Tour d'horizon des fonctionnalités qui sauvent des week-ends
Parce que oui, Nginx Proxy Manager ne fait pas "juste" proxy + "cadenas". Dans le menu Hosts, vous avez plusieurs types de trucs à créer, et chacun sert à un usage bien précis. Et côté Certificats et sécurité, il y a de quoi faire sans sortir le marteau-piqueur.
Certificats Let's Encrypt (HTTP et DNS) + certifs locaux
On va commencer par le sujet qui donne des boutons : les certificats. Dans l'onglet Certificates, vous pouvez gérer tout ça au même endroit :
- Let's Encrypt en HTTP-01 : le classique. NPM ouvre la voie, répond au challenge, et basta. Pratique pour un
service.mondomaine.fr exposé "normalement".
- Let's Encrypt en DNS-01 : là, c'est le mode "j'ai compris la vie". Vous pouvez valider le certificat via votre DNS (donc sans dépendre d'un port 80 accessible), et surtout ça permet les wildcards du style
*.mondomaine.fr. Donc un seul certif et roule ma poule, même si vous ajoutez 12 sous-domaines demain à 3h du mat.
- Certificats locaux : vous pouvez aussi importer un certificat existant (genre un certif de votre boîte, un truc interne, un CA maison, ou même un self-signed si vous aimez vivre dangereusement). Ça évite de dépendre de Let's Encrypt si vous êtes en mode "tout en local, rien sur Internet".
Et le meilleur c'est que NPM gère le renouvellement automatique. Donc plus de rappel calendrier "renouveler les certifs" tous les 2 mois, sinon c'est le drame et tout le monde vous écrit "ça marche plus ton truc".
Plusieurs comptes, parce que tout le monde n'est pas "admin"
Dans Users, vous pouvez créer plusieurs comptes pour accéder à l'interface. Typiquement :
- un compte admin pour vous, le chef, le patron, le seigneur des reverse proxies.
- un compte "moins dangereux" pour quelqu'un qui doit juste consulter ou bidouiller un truc sans toucher à toute l'infra.
Et ça, couplé aux Audit Logs (j'y reviens juste après), c'est très pratique quand plusieurs personnes mettent les mains dedans. Parce que "c'est pas moi, j'ai rien touché" est une phrase universelle, on la retrouve dans toutes les cultures.
Access Lists, le videur à l'entrée
Alors ça, c'est une des fonctions les plus sous-cotées. Les Access Lists permettent de mettre en place des règles d'accès et de les réutiliser partout :
- Basic Auth (login/mot de passe) : parfait pour protéger une appli pas prévue pour être publique, ou un petit outil d'admin que vous ne voulez pas exposer "en clair".
- Allow/Deny par IP : le top pour dire "seulement depuis mon IP / mon VPN / mon réseau". Et là, même si quelqu'un devine votre URL, il se prend un mur.
Vous créez une Access List une fois, et ensuite vous l'appliquez à vos Proxy Hosts. Du coup, pas besoin de refaire 50 fois la même conf. C'est propre, c'est net, c'est carré.
Les redirections propres (HTTP -> HTTPS, domaine A -> domaine B, etc.)
Besoin de rediriger un vieux domaine vers un nouveau ? Ou de faire un joli http:// qui part systématiquement en https:// ? Les Redirection Hosts servent exactement à ça. C'est bête mais ça évite d'aller trifouiller des règles Nginx à la main.
Exemples typiques :
mondomaine.fr -> www.mondomaine.fr
ancientruc.mondomaine.fr -> nouveautruc.mondomaine.fr
http -> https (pour les retardataires)
Streams - Quand ce n'est pas du HTTP mais que vous voulez quand même un reverse proxy
Le web, c'est bien, mais tout n'est pas en HTTP. Certaines applis parlent en TCP/UDP (bases de données, services réseau, protocoles chelous, etc.). C'est là que Streams entrent en jeu. Cette fonctionnalité vous permet de proxyfier des flux réseau, genre "ce port externe pointe vers ce port interne".
Alors oui, c'est plus "brut" que les Proxy Hosts, mais ça dépanne vraiment quand vous avez un service qui n'a rien à faire derrière un vhost HTTP. Et ça se configure aussi en 2 clics, sans incantations démoniaques.
404 Hosts - La sortie de secours
Les 404 Hosts, c'est la petite finition qui fait plaisir (non, rien à voir avec votre salon de massage préféré). Vous pouvez définir un "host poubelle" qui répond proprement quand quelqu'un tape un domaine qui n'existe pas chez vous, ou quand un bot scanne votre serveur en espérant trouver /phpmyadmin par magie.
Au lieu de laisser traîner une réponse moche ou ambiguë, vous renvoyez une 404 nette, propre, assumée. C'est pas de la sécurité absolue, mais c'est une bonne hygiène, et ça évite de donner trop d'infos aux curieux.
Audit Logs
Dans Audit Logs, vous avez l'historique des actions effectuées dans l'interface : création/modif de hosts, changements de certifs, etc. C'est le genre de truc dont on se fout… jusqu'au jour où on en a besoin. Et là, vous êtes content de pouvoir remonter le film de l'horreur.
Et enfin, mon bonus : Le mode "je sais ce que je fais" (les options avancées Nginx)
Et si un jour vous voulez aller un cran plus loin, NPM permet aussi d'ajouter des réglages plus "Nginx pur jus" par host (headers, règles, conf custom). Donc vous commencez en mode clic-clic, et si vous devenez un peu psycho sur l'optimisation, vous pouvez aussi affiner. Sans tout casser, normalement.
2/3 conseils de daron pour éviter les boulettes
- Ne laissez pas l'admin ouvert au monde : le port 8181 (ou votre port d'admin) c'est "pour vous". Si possible, limitez-le via pare-feu / VPN / IP autorisées. C'est le panneau de commande de votre château, pas un distributeur de bonbons.
- Utilisez les Access Lists pour tout ce qui est sensible : dashboards, outils d'admin, services pas prévus pour Internet, etc.
- Pensez au DNS-01 si vous voulez des wildcards ou si vous n'avez pas envie d'exposer le port 80.
Et par rapport aux autres ?
Je vous vois venir les puristes : "Oui mais Traefik c'est mieux car c'est dynamique". C'est vrai. J'ai testé Traefik, et c'est une tuerie pour les environnements qui bougent tout le temps. Mais sa config en YAML peut vite devenir une usine à gaz si vous débutez. Caddy est top aussi (un seul fichier de conf), mais il faut quand même mettre les mains dans le cambouis.
Perso, je pense que Nginx Proxy Manager est un excellent choix pour un homelab par exemple. C'est un peu le choix du confort, celui des grosses feignasses comme moi parce que c'est visuel, c'est du clic-bouton clic clic, et pour un petit serveur perso, c'est franchement imbattable.
Bref, si vous galérez encore avec vos vhosts Nginx, arrêtez de vous faire du mal. Installez ça, et profitez de la vie (et de vos week-ends).
Nginx Proxy Manager
c'est par ici !