Avant de commencer
Il vous faut un VPS compatible, l’accès à la zone DNS du domaine concerné et une sauvegarde de la configuration réseau avant toute modification. Les exemples app.example.com et 192.0.2.10 sont illustratifs ; remplacez-les par vos valeurs réelles, sans appliquer une passerelle ou un masque d’un autre serveur.
Séparer domaine, adresse et service
Une adresse IP indique une destination réseau ; un nom de domaine permet notamment de retrouver cette destination. Les hôtes virtuels de Nginx ou d’autres serveurs web distinguent plusieurs sites sur une même IP. TLS SNI permet au client d’indiquer le nom attendu lors de la connexion. Des domaines différents n’imposent donc pas, à eux seuls, un achat d’IP pour chacun.
Identifier un besoin d’adresses distinctes
Plusieurs IPv4 peuvent être utiles pour des services séparés ou un logiciel qui doit écouter sur des adresses distinctes. Elles ne créent pas une séparation de sécurité complète : permissions, processus et isolation restent à configurer. Plusieurs ports ou hôtes virtuels peuvent parfois suffire. Évitez de payer un lot avant d’avoir confirmé la compatibilité et le fonctionnement attendu pour votre application.
Compter les adresses supplémentaires
Distinguez le total souhaité des adresses à ajouter. Avec une principale incluse, cinq IPv4 au total correspondent à quatre supplémentaires. Au tarif constaté le 27 octobre 2026 de 1,20 €/mois par supplémentaire, cela ajoute 4,80 €/mois. Dix supplémentaires coûtent 12 €/mois et donnent onze adresses au total. Le simulateur utilise le prix configuré et ne crée aucune remise quantité.
Commander puis vérifier l’affectation
L’espace client permet le parcours de souscription existant. Les adresses supplémentaires suivent les règles de compatibilité, d’affectation et de parking indiquées pour le compte. L’IPv4 principale reste attachée au service. L’absence de plafond commercial fixe par VPS ne signifie pas que n’importe quelle quantité soit disponible. La simulation ne réserve rien et ne garantit pas qu’une IP puisse être déplacée vers un autre service.
Préparer le nom avant le reverse DNS
Pour un PTR souhaité vers app.example.com, créez d’abord dans la zone DNS autoritative un enregistrement A de ce nom vers l’IPv4 concernée. Attendez que la résolution publique renvoie effectivement cette IP, puis demandez le reverse DNS depuis l’espace client. CubixServ vérifie ce pointage avant d’accepter le changement. Un ancien cache DNS peut expliquer un refus temporaire ; vérifiez le résultat, pas seulement la saisie chez votre fournisseur DNS.
Vérifier sans casser les accès
Conservez l’adresse principale et un accès console pendant toute modification du système invité. Ne copiez pas un fichier réseau complet trouvé sur Internet : interface, routage et paramètres doivent correspondre au service. Après changement du PTR, vérifiez séparément résolution directe et inverse. Le reverse DNS ne remplace pas un certificat, ne crée pas un service web et ne garantit pas une délivrabilité de courrier ou une réputation d’adresse.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Plusieurs domaines web | Commencer par les hôtes virtuels et TLS ; vérifier si une seule IPv4 suffit. |
| Objectif de dix adresses au total | Simuler neuf IPv4 supplémentaires, puis confirmer leur disponibilité. |
| Reverse DNS refusé | Contrôler que le nom résout publiquement en A vers l’IP concernée avant de réessayer. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.