Lorsqu’on développe un site web ou une application en local, tout fonctionne généralement très bien… jusqu’au moment où une URL publique HTTPS devient indispensable.
C’est souvent le cas pour tester des webhooks (Stripe, PayPal, services tiers), des callbacks OAuth ou simplement montrer un projet à un client sans le déployer en production.
Mettre en place un port forwarding, gérer un DNS et installer un certificat SSL local peut rapidement devenir lourd, surtout pour un besoin temporaire.
C’est précisément dans ce contexte que NGrok se révèle être une solution particulièrement efficace.
Pourquoi utiliser NGrok avec Virtualmin ?
NGrok permet d’exposer un serveur local sur Internet via une URL publique sécurisée en HTTPS, sans aucune modification de votre réseau.
Aucune redirection de port, aucun réglage sur votre box ou firewall, et surtout aucun certificat SSL à gérer côté serveur local.
Dans un environnement Virtualmin, cela permet de :
-
conserver une architecture Apache classique
-
continuer à utiliser des VirtualHosts locaux
-
tester des services externes comme s’ils accédaient à un serveur de production
NGrok agit comme un point d’entrée HTTPS, puis relaie les requêtes vers votre serveur local en HTTP.
Architecture de fonctionnement
Avant d’entrer dans la configuration, il est important de comprendre comment les différents éléments interagissent.
│
▼
URL publique HTTPS NGrok
│
▼
Tunnel sécurisé NGrok
│
▼
Serveur Virtualmin local (Apache HTTP)
│
▼
VirtualHost Apache (ex: monsite.loc)
NGrok assure la terminaison TLS (HTTPS), puis transmet les requêtes à Apache en HTTP en ajoutant un en-tête essentiel :
Cet en-tête jouera un rôle clé dans la configuration Apache.
Prérequis techniques
Avant de commencer, assurez-vous de disposer des éléments suivants :
-
Un serveur Virtualmin fonctionnel (machine locale ou VM)
-
Apache accessible en HTTP sur le port 80
-
Un compte NGrok (la version gratuite suffit)
-
NGrok installé sur le serveur et authentifié avec votre token
L’installation officielle de NGrok est documentée ici :
https://dashboard.ngrok.com/get-started/setup/linux
Lancer un tunnel NGrok vers Virtualmin
Une fois NGrok installé et configuré, le tunnel peut être lancé très simplement depuis un terminal SSH.
--url=delightingly-quizzable-aide.ngrok-free.dev \
--host-header=monsite.loc
Cette commande mérite quelques explications, car chaque paramètre est important.
Choix du port HTTP
Il est essentiel d’utiliser le port 80 du serveur Virtualmin.
Même si Apache est configuré en HTTPS localement, il est fortement déconseillé d’utiliser le port 443 avec NGrok lorsque les certificats sont autosignés. Cela entraîne des erreurs SSL et des comportements imprévisibles.
NGrok gère déjà le HTTPS côté public, il n’y a donc aucun avantage à chiffrer de nouveau la connexion côté local.
URL NGrok permanente
Le paramètre --url correspond à un domaine réservé depuis le dashboard NGrok
(https://dashboard.ngrok.com/domains).
Cela permet de conserver une URL stable, pratique pour les webhooks ou les tests récurrents.
Host-header et Virtualmin
Le paramètre --host-header doit correspondre exactement au nom du VirtualHost Apache (par exemple monsite.loc).
Sans cela, Apache ne saura pas quel site servir et retournera le VirtualHost par défaut.
Vérifier le bon fonctionnement du tunnel
Une fois la commande lancée, NGrok affiche un résumé de la session active :
Forwarding https://delightingly-quizzable-aide.ngrok-free.dev -> http://192.168.0.19:80
Web Interface http://127.0.0.1:4040
L’interface web locale accessible sur le port 4040 est particulièrement utile.
Elle permet de :
-
visualiser les requêtes entrantes
-
inspecter les headers HTTP
-
déboguer facilement des webhooks en échec
Le point le plus important : la configuration Apache
C’est ici que se produisent la majorité des erreurs.
Apache reçoit les requêtes en HTTP, même si l’utilisateur final accède au site en HTTPS via NGrok.
Si une redirection HTTPS est configurée de manière classique, une boucle de redirection infinie se produit.
La solution consiste à tenir compte de l’en-tête X-Forwarded-Proto.
Règle Apache recommandée
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
Cette règle impose une redirection HTTPS uniquement si :
-
Apache ne voit pas de HTTPS direct
-
et qu’aucun proxy en amont n’a déjà géré le HTTPS
Ainsi, lorsque NGrok est utilisé, Apache ne redirige pas inutilement.
Exemple complet de fichier .htaccess
RewriteEngine On
RewriteBase /
# Redirection HTTP vers HTTPS compatible NGrok et production
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
# Autres règles de réécriture
</IfModule>
Cette configuration est robuste et fonctionne aussi bien :
-
en local avec NGrok
-
derrière un reverse proxy
-
en environnement de production avec un vrai certificat SSL
Récupérer l’adresse IP réelle du visiteur en PHP
Par défaut, l’adresse IP vue par Apache correspond à celle de NGrok.
L’IP réelle du visiteur est transmise via l’en-tête X-Forwarded-For.
$ip = explode(',', $ip)[0];
$ip = trim($ip);
Cette récupération est indispensable pour les logs, les contrôles de sécurité ou les limitations par IP.
Conclusion
L’utilisation de NGrok avec Virtualmin permet de disposer rapidement d’une URL publique HTTPS, sans aucune modification réseau et sans complexité inutile.
Avec une configuration Apache adaptée, il est possible de travailler dans des conditions très proches de la production, tout en restant sur un environnement local maîtrisé.
C’est une solution idéale pour le développement, les tests de webhooks et les démonstrations, tout en conservant une architecture propre et réutilisable.
