Pourquoi l'IP nue pose problème
Une adresse comme 203.0.113.10 est fonctionnelle mais crée trois obstacles concrets dès que vous voulez aller plus loin.
D'abord, TLS est impossible sur une IP nue. Let's Encrypt et les autres autorités de certification refusent d'émettre un certificat pour une adresse IP publique. Sans certificat, votre navigateur affiche « Non sécurisé » et votre reverse proxy n'a rien à terminer côté HTTPS.
Ensuite, l'IP est instable par construction. Si vous réinstallez le VPS, migrez vers une offre supérieure ou changez de datacenter, l'IP change. Toutes vos configurations — DNS interne, fichiers de conf d'app, commandes SSH dans votre gestionnaire de mots de passe — deviennent fausses du jour au lendemain.
Enfin, un reverse proxy a besoin d'un nom d'hôte. Nginx et Caddy s'appuient sur la valeur du Host: pour router les requêtes vers le bon backend. Sur une IP nue, ce champ est l'IP elle-même, ce qui complique l'hébergement de plusieurs services sur un même serveur.
Situations où une adresse temporaire (sans domaine propre) est la bonne solution
- Vous testez un outil en auto-hébergement avant de décider si vous gardez le VPS.
- Vous attendez le transfert d'un domaine existant (délai 5 à 7 jours chez certains registrars).
- Vous montez un environnement de recette interne que personne d'extérieur ne verra jamais.
- Vous prototypez une API ou un webhook et vous avez besoin d'une URL HTTPS joignable depuis l'extérieur.
- Votre client ne vous a pas encore fourni son domaine, mais le sprint commence demain.
- Vous explorez un sous-domaine pour un projet annexe avant de décider s'il mérite son propre domaine.
- Vous configurez le reverse DNS (PTR) de votre serveur mail et vous avez besoin d'un FQDN cohérent dès maintenant.
- Vous accédez à votre VPS depuis un réseau qui bloque les connexions directes par IP (certains pare-feux filtrent les destinations sans SNI).
Prérequis communs aux trois options
Avant de choisir, vérifiez que vous avez :
Un VPS actif et accessible en SSH. La commande ssh root@<ip-du-vps> doit répondre. Si votre VPS vient d'être livré, attendez quelques minutes que l'image soit entièrement déployée.
Un accès à la console de gestion (espace client ServOrbit pour l'option 1, accès navigateur pour les options 2 et 3).
Des notions de base en DNS : savoir qu'un enregistrement A pointe un nom vers une IP, et qu'un TTL trop élevé ralentit la propagation. Pour les options 2 et 3, rien d'autre n'est requis côté serveur — les services s'occupent du reste.
Option 1 — le sous-domaine ServOrbit : l'adresse immédiate
Chaque VPS ServOrbit reçoit à la livraison un nom d'hôte de la forme vps-xxxxxxx.servorbit-dns.com. Il est attribué automatiquement, pointe vers l'IP de votre serveur, et reste valide même si cette IP change après une réinstallation. C'est la solution zéro-friction : pas de compte tiers, pas de client à installer, pas de cron à configurer.
Activer et utiliser le sous-domaine ServOrbit
Repérez votre adresse dans l'espace client
Connectez-vous, ouvrez VPS → Gérer. Le bloc d'accès affiche votre adresse vps-xxxxxxx.servorbit-dns.com à la place de l'IP. Un bouton copie la commande SSH complète — ssh [email protected].
Remplacez l'IP par ce nom partout
Dans votre configuration d'application, votre client SSH, vos scripts de déploiement : substituez l'IP par le sous-domaine. L'adresse restera valide après une réinstallation qui changerait l'IP.
Publiez une application avec HTTPS sans écrire une ligne de config
Dans VPS → Gérer → Applications, choisissez votre template et sélectionnez le sous-domaine gratuit au lieu de saisir un domaine. L'installateur configure le reverse proxy (Caddy ou Nginx Proxy Manager selon le template), demande un certificat Let's Encrypt et vous donne une URL en mon-app.vps-xxxxxxx.servorbit-dns.com prête à utiliser, en HTTPS, dans les minutes qui suivent.
Posez votre reverse DNS (PTR) en un clic
Si vous hébergez un serveur mail, allez dans Réseau et sécurité → Reverse DNS, entrez vps-xxxxxxx.servorbit-dns.com et validez. Comme ce nom résout déjà vers l'IP de votre VPS, le PTR est immédiatement « confirmé » — la condition nécessaire pour que les serveurs destinataires ne classent pas vos e-mails en spam.
Branchez votre domaine quand vous êtes prêt
Le jour où vous achetez ou transférez un domaine, rattachez-le au VPS dans l'espace client. Le sous-domaine servorbit-dns.com reste actif en parallèle le temps de la transition — aucun lien existant ne casse, aucune configuration à remettre à zéro.
Option 2 — DNS dynamique gratuit (Afraid.org, deSEC, nsupdate.info)
Si vous voulez un nom plus personnalisé, ou si vous gérez plusieurs VPS chez différents hébergeurs, les services de DNS dynamique gratuits sont une alternative sérieuse. Afraid.org propose un sous-domaine de votre choix sous une cinquantaine de domaines publics (mooo.com, myftp.org…). deSEC vous laisse amener votre propre domaine et gère le DNS pour vous, gratuitement, avec une API pour les mises à jour. nsupdate.info suit le même principe avec une interface plus simple.
Le mécanisme est le même pour les trois : un client DDNS tourne sur votre VPS, détecte les changements d'IP et met à jour l'enregistrement A via l'API du service. Résultat : votre sous-domaine suit l'IP, même si elle change.
Mettre en place un DNS dynamique (exemple avec deSEC)
Créez un compte et un sous-domaine sur desec.io
Sur desec.io, créez un compte, puis ajoutez un sous-domaine (exemple : monvps.dedyn.io). deSEC génère un token d'accès API — copiez-le.
Installez ddclient sur votre VPS
Sur Debian/Ubuntu : apt install ddclient. Lors de l'installation, sélectionnez un protocole compatible ou répondez librement — vous allez remplacer la configuration de toute façon.
Configurez /etc/ddclient.conf
Éditez le fichier avec votre token et votre sous-domaine. deSEC propose une documentation directe sur son site pour le bloc de configuration exact selon votre version de ddclient.
Démarrez le service et vérifiez la propagation
Lancez systemctl enable --now ddclient, puis attendez 1 à 2 minutes. Vérifiez la résolution avec dig monvps.dedyn.io A depuis un poste extérieur. Si l'IP retournée est celle de votre VPS, c'est en place.
Obtenez un certificat TLS avec Caddy ou Certbot
Avec Caddy (apt install caddy), un fichier Caddyfile minimaliste suffit : monvps.dedyn.io { reverse_proxy localhost:3000 }. Caddy négocie le certificat Let's Encrypt tout seul. Avec Certbot, lancez certbot certonly --standalone -d monvps.dedyn.io.
Option 3 — tunnel de développement (Cloudflare Tunnel ou ngrok)
Les tunnels inversés sont la solution la plus rapide pour exposer un service sur un VPS derrière un NAT, sans ouvrir de port ni configurer de DNS. Cloudflare Tunnel (cloudflared) crée un tunnel chiffré entre votre VPS et l'edge Cloudflare, qui expose votre service sur un sous-domaine trycloudflare.com (mode temporaire, sans compte) ou sur votre propre domaine si vous en avez un dans Cloudflare. ngrok fonctionne selon le même principe et attribue une URL aléatoire renouvelée à chaque démarrage (compte gratuit) ou une URL fixe (compte payant).
Ces outils sont parfaits pour démontrer un prototype, tester un webhook Stripe ou GitHub, ou dépanner un client à distance sans modifier le pare-feu. Ils ne remplacent pas une infrastructure permanente : la latence supplémentaire et les limites de bande passante des plans gratuits les cantonnent au développement et à la recette.
Exposer un service en 3 minutes avec Cloudflare Tunnel (mode temporaire)
Installez cloudflared sur votre VPS
Téléchargez le binaire depuis github.com/cloudflare/cloudflared/releases et rendez-le exécutable : chmod +x cloudflared && mv cloudflared /usr/local/bin/.
Lancez un tunnel temporaire vers votre service
Si votre application écoute sur le port 8080 : cloudflared tunnel --url http://localhost:8080. Cloudflare affiche une URL en *.trycloudflare.com — partagez-la. Elle expire quand vous fermez le processus.
Pour un tunnel permanent, créez un compte et un tunnel nommé
Connectez-vous avec cloudflared tunnel login, créez un tunnel (cloudflared tunnel create mon-tunnel), configurez le fichier YAML et enregistrez le service (cloudflared service install). Le tunnel redémarre avec le VPS.
Quand passer à un vrai domaine
Ces trois options sont des solutions de démarrage ou de développement. Passez à un domaine à votre nom dès que l'une de ces conditions est remplie.
TLS de production. Let's Encrypt émet des certificats sur des noms de domaine enregistrés ; sur un sous-domaine tiers, vous dépendez de leur infrastructure et de leur politique de conservation.
SEO. Un article de blog, une landing page ou une boutique en ligne n'accumulent aucune autorité de domaine sur un sous-domaine tiers. Votre contenu sera indexé, mais le signal de confiance ira au domaine parent, pas à vous.
Confiance client. Partager une URL en monapp.vps-xxxxxxx.servorbit-dns.com ou en monapplication.trycloudflare.com avec un client final crée une friction inutile. Un domaine propre est un signal de professionnalisme que vous ne pouvez pas racheter après coup.
Sur ServOrbit, enregistrer ou transférer un domaine puis le rattacher au VPS se fait en quelques clics depuis l'espace client — et le sous-domaine gratuit reste disponible en parallèle pendant toute la transition.
Dépannage — les 4 erreurs les plus fréquentes
DNS pas encore propagé. La propagation d'un enregistrement A peut prendre de quelques secondes (TTL bas) à 48 heures (TTL hérité d'un ancien registrar). Vérifiez avec dig +short nom-de-votre-sous-domaine A depuis une machine extérieure — votre OS met souvent en cache une réponse périmée. Le sous-domaine ServOrbit est propagé immédiatement à la livraison : si dig ne répond pas, vérifiez que vous n'avez pas fait une faute de frappe dans l'adresse.
TLS refusé sur IP nue. Si Certbot ou Caddy sort une erreur du type « Domain not found » ou « Invalid domain », c'est que vous avez tenté d'émettre un certificat pour une adresse IP. Remplacez l'IP par votre nom d'hôte dans la configuration du reverse proxy et relancez.
Sous-domaine ServOrbit non assigné. Si vps-xxxxxxx.servorbit-dns.com ne résout pas, ouvrez l'espace client et vérifiez que le VPS est bien en état Actif (pas en cours d'installation). Sur un VPS tout juste livré, attendez 2 à 3 minutes le temps que l'assignation DNS soit propagée.
Tunnel Cloudflare qui se ferme. En mode temporaire (--url), le tunnel vit le temps du processus. Si votre connexion SSH se coupe, le tunnel disparaît. Pour un tunnel persistant, configurez-le en service systemd (cloudflared service install) ou utilisez screen / tmux pour que le processus survive à la déconnexion.
En résumé : choisir la bonne option
Le sous-domaine ServOrbit est le choix par défaut si votre VPS est chez ServOrbit : aucune configuration, HTTPS automatique via l'installateur, reverse DNS inclus. Il couvre 90 % des situations de démarrage.
Le DNS dynamique (deSEC, Afraid.org) vaut la peine si vous gérez plusieurs VPS chez différents hébergeurs, si vous voulez un nom plus parlant, ou si vous avez déjà un domaine que vous souhaitez déléguer sans payer un hébergeur DNS supplémentaire.
Le tunnel (Cloudflare Tunnel, ngrok) est la réponse quand la rapidité prime : un prototype à montrer dans l'heure, un webhook à tester, une démo client imprévue. La durée de vie courte est une fonctionnalité, pas un défaut.
Quand votre projet prend de la consistance, enregistrez votre domaine et rattachez-le au VPS — c'est la prochaine étape naturelle.
