[Accueil](https://servhidden.com/fr) / [Guides Hébergement Privé](https://servhidden.com/fr/guides) / Masquer l'IP d'origine : CDN, reverse proxy et fuites Confidentialité # Masquer l'IP de votre serveur d'origine Absorber une attaque et rester introuvable sont deux problèmes différents, et le montage qui règle l'un peut discrètement défaire l'autre. Ce que couvre le filtrage réseau, ce qu'ajoute et coûte un CDN, comment les origines sont réellement trouvées — et comment vérifier la vôtre. [Lire le guide](#guide-body) [FAQ](#guide-faq) ## Sur cette page - [Guide](#guide-body) - [FAQ](#guide-faq) - [Guides connexes](#guide-related) - [Pages recommandées](#guide-cta) Sans KYC Crypto uniquement Aucun journal DMCA ignoré Accès root complet SSD NVMe 18 min de lecture Mis à jour Aug 2026 Sur cette page [01Deux problèmes qui n'en ont l'air que d'un](#deux-problèmes-qui-nen-ont-lair-que-dun) [02Ce que votre hébergeur fait déjà, et où cela s'arrête](#ce-que-votre-hébergeur-fait-déjà-et-où-cela-sarrête) [03Ce qu'un CDN masque, et le service abus que vous héritez](#ce-quun-cdn-masque-et-le-service-abus-que-vous-héritez) [04Les six façons dont une adresse d'origine fuit quand même](#les-six-façons-dont-une-adresse-dorigine-fuit-quand-même) [05Verrouiller l'origine pour que seule la façade puisse l'atteindre](#verrouiller-lorigine-pour-que-seule-la-façade-puisse-lattein) [06Votre propre nœud frontal plutôt qu'un CDN](#votre-propre-nœud-frontal-plutôt-quun-cdn) [07Choisir, en un tableau](#choisir-en-un-tableau) [08Le compte est généralement le maillon le plus faible](#le-compte-est-généralement-le-maillon-le-plus-faible) [09Auditer votre propre exposition en dix minutes](#auditer-votre-propre-exposition-en-dix-minutes) [10Quand l'adresse est déjà grillée](#quand-ladresse-est-déjà-grillée) [11La version courte](#la-version-courte) [FAQQuestions fréquentes](#guide-faq) [→Pages recommandées](#guide-cta) « Dois-je mettre un CDN devant ? » est la première question que se posent la plupart des gens après avoir acheté un serveur offshore, et elle n'a pas de réponse unique, car ce sont en réalité deux questions sous un même manteau. Absorber une attaque et rester introuvable sont des problèmes différents, avec des solutions différentes, et le montage qui règle l'un peut discrètement défaire l'autre. La confusion coûte cher dans les deux sens. Certains mettent un grand CDN américain devant un contenu pour lequel ils avaient précisément choisi un [hébergement DMCA-ignored](https://servhidden.com/fr/dmca-ignored-hosting), et remettent un service de plaintes entre les mains du type même d'intermédiaire qu'ils cherchaient à éviter. D'autres ne mettent rien en place, se font toucher par une inondation de couche applicative que le filtrage réseau n'a jamais été conçu pour voir, et en concluent que la protection DDoS était un mensonge. Ce guide sépare les deux problèmes, dit ce que chaque couche fait réellement, et consacre l'essentiel de son propos à la partie qui décide du résultat dans les deux cas : les six façons dont une adresse d'origine fuit quand tout le reste est pourtant bien configuré. ## Deux problèmes qui n'en ont l'air que d'un Tout ce que vous mettez devant un serveur remplit l'un de ces deux rôles : tenir une attaque à distance, ou tenir son adresse inconnue. Ils se recoupent assez pour être confondus, et diffèrent assez pour que résoudre le mauvais soit de l'argent perdu. | Ce qui vous inquiète | Ce qui le résout réellement | Ce qui ne le résout pas | | --- | --- | --- | | Une inondation volumétrique qui sature votre tuyau (couches 3 et 4) | Le filtrage en périphérie de réseau chez l'hébergeur, inclus sur chaque offre ici | Rien de ce que vous installez sur le serveur — à ce stade, le tuyau est déjà plein | | Une inondation applicative de requêtes qui semblent réelles (couche 7) | Un CDN ou un WAF, la mise en cache, des limites de débit, des points de terminaison moins coûteux | Le filtrage de paquets, qui voit du HTTP valide et le laisse passer | | Personne ne doit pouvoir atteindre directement la machine | Une façade (CDN ou votre propre nœud) *plus* un pare-feu qui n'accepte qu'elle | Un CDN seul, si l'origine répond encore à tout l'internet | | Personne ne doit savoir qui l'exploite | Inscription sans KYC, confidentialité du paiement, discipline du compte | N'importe quelle quantité d'infrastructure — c'est une question d'identité | | Le contenu doit survivre aux plaintes | La juridiction, et un hébergeur qui n'y donne pas suite | Un CDN, qui **ajoute** un canal de plaintes au lieu d'en retirer un | Lisez deux fois la dernière ligne, car c'est celle qui piège les gens. Tout le reste sur cette page relève de l'ingénierie. Pas cette ligne. Ce qui se trouve devant votre serveur se trouve aussi entre vous et ceux qui s'en plaignent — une protection dans un sens, une nouvelle adresse pour les plaintes dans l'autre. ## Ce que votre hébergeur fait déjà, et où cela s'arrête Le filtrage de couche 3 et 4 est inclus sur chaque offre que nous vendons, sans coût supplémentaire, et il s'exécute en périphérie du réseau plutôt que sur votre serveur — le seul endroit où il peut réellement fonctionner, puisqu'une liaison montante saturée n'est réparée par rien de ce qui tourne derrière elle. La bande passante est illimitée, donc une attaque ne se transforme pas en facture. Pour la grande majorité de ce que les gens appellent « une attaque DDoS », c'est toute l'histoire. Ce qu'il ne peut pas voir, c'est l'autre genre. Cinq cents requêtes par seconde vers un point de recherche, provenant de quarante mille adresses résidentielles, n'est pas du trafic malformé ; c'est du trafic. Des connexions Slowloris qui égrènent un en-tête toutes les quelques secondes sont, prises individuellement, polies. Un formulaire de connexion martelé de vrais corps POST est indiscernable, au niveau paquet, d'un lundi chargé. Aucun filtre de paquets n'aide, parce qu'il n'y a rien d'anormal dans les paquets. **Le test pour savoir si vous avez besoin de plus qu'un filtrage réseau :** une seule requête bien formée peut-elle coûter à votre serveur un balayage de base de données, un redimensionnement d'image ou un hachage de mot de passe ? Si oui, vous avez une surface de couche 7, et la solution est la mise en cache, la limitation de débit et des points de terminaison moins coûteux — avec ou sans CDN devant. Il existe un sens de trafic sur lequel nous agissons, et il vaut la peine de le dire clairement : les attaques et le spam massif *provenant* de notre réseau peuvent être null-routés pour préserver la santé du reste de l'infrastructure. C'est une mesure opérationnelle, pas une mesure de contenu — la distinction que détaille notre [guide de l'hébergement DMCA-ignored](https://servhidden.com/fr/guides/dmca-ignored-hosting-explained). ## Ce qu'un CDN masque, et le service abus que vous héritez Le mécanisme est simple et réellement efficace. Votre domaine se résout vers les adresses du fournisseur, les clients s'y connectent, et le fournisseur va chercher le contenu sur votre origine. L'adresse réelle n'apparaît jamais dans la connexion d'un client, donc elle ne peut pas être attaquée par quiconque ne connaît que le domaine. C'est le même tour de passe-passe qui fait fonctionner le CDN fronting pour les [proxies résistants à la censure](https://servhidden.com/fr/censorship-resistant-hosting/v2ray) : un censeur voit du trafic vers une adresse qu'il ne peut pas se permettre de bloquer. Trois choses arrivent avec lui, et aucune n'est cachée dans les petites lignes : - **La périphérie termine votre TLS.** Le trafic est en clair à l'intérieur du réseau du fournisseur, par conception — c'est ainsi que fonctionnent la mise en cache et le filtrage. Tout ce que tapent vos utilisateurs atteint un tiers avant de vous atteindre. - **Un canal d'abus qui n'existait pas avant.** Des plaintes peuvent être déposées directement contre le CDN, et un CDN y répond : en vous les transmettant, en nommant votre hébergeur, ou en résiliant votre compte. Si votre raison d'être offshore est que les plaintes ne mènent nulle part, placer un intermédiaire américain devant reconnecte la chaîne que vous aviez payé pour rompre. - **Un compte.** Adresse e-mail, moyen de paiement, souvent un numéro de téléphone, liés à votre domaine et conservés indéfiniment. Plus de détails plus bas, car c'est généralement le maillon le plus faible de tout le montage. Rien de tout cela ne rend un CDN mauvais en soi. Cela en fait une décision à deux faces : excellente pour une boutique ou une application avec de vrais utilisateurs et une vraie pression de couche 7, activement contre-productive pour une publication qui attire les retraits. Notre propre réponse à cette question sur la [page de l'hébergement DMCA-ignored](https://servhidden.com/fr/dmca-ignored-hosting) a toujours été la version courte de ceci : pour résister aux retraits, utilisez le filtrage réseau que vous avez déjà et passez du CDN. ## Les six façons dont une adresse d'origine fuit quand même C'est la section qui compte, car la dissimulation n'est pas un produit qu'on achète — c'est une propriété qu'on entretient ou qu'on perd, généralement en quelques jours, à cause de l'une de ces six choses. Des origines sont retrouvées chaque jour derrière des configurations CDN par ailleurs impeccables. - **Les journaux Certificate Transparency.** Chaque certificat publiquement reconnu émis pour votre domaine est publié en quelques minutes dans des journaux publics, permanents et consultables. Ils ne publient pas votre adresse ; ils publient vos *noms d'hôtes* — staging, mail, vpn, le sous-domaine que vous avez créé une fois en 2024. Chacun est un candidat à résoudre, et un seul enregistrement qui ne pointe pas vers la façade met fin à l'exercice. - **L'historique DNS.** Les services de DNS passif archivent chaque adresse vers laquelle votre domaine a jamais résolu. Passer derrière un CDN par la suite ne dépublie pas ce qui a déjà été enregistré — la dissimulation doit commencer avant la première résolution du domaine, ou il vous faut une nouvelle adresse, pas une nouvelle façade. - **Les enregistrements qui ne peuvent pas être proxifiés, et ceux que vous avez oubliés.** Les serveurs d'échange de courrier doivent pointer vers quelque chose de joignable. Tout comme un enregistrement AAAA laissé en place quand vous n'avez proxifié que l'IPv4, un vieux nom d'hôte FTP ou de panneau, un wildcard, ou l'hôte de développement « temporaire » qui a maintenant trois ans. - **Tout ce que le serveur envoie.** Le courrier émis depuis l'origine porte son adresse dans les en-têtes Received — un message de réinitialisation de mot de passe est une divulgation en libre-service. Webhooks, récupérations d'images sortantes, aperçus de liens, pingbacks, vérifications de mises à jour et rapporteurs de plantage contactent tous l'extérieur depuis l'adresse réelle, et quiconque peut faire parler votre application à un hôte qu'il contrôle l'apprend. - **Le scan de l'internet entier.** Chaque adresse IPv4 est scannée et indexée en continu par des services publics, et les résultats sont interrogeables en quelques secondes. Si votre origine répond sur le port 443 avec votre certificat, ou sert votre page d'accueil à n'importe quel en-tête Host, la faire correspondre tient en une requête contre un hachage de corps de page, une empreinte de certificat ou un hachage de favicon. C'est ainsi que la plupart des origines sont trouvées, et cela ne coûte rien à celui qui cherche. - **L'application qui parle d'elle-même.** URL absolues et redirections contenant l'adresse brute, points de terminaison de statut ou de métriques laissés ouverts, traces de pile verbeuses nommant des hôtes internes, en-têtes qui révèlent le backend, et le virtual host par défaut qui sert joyeusement votre site à quiconque le demande par adresse. **Cinq de ces six failles relèvent de la configuration, pas de la cryptographie.** Rien dans cette liste n'est vaincu par une offre CDN plus chère, et rien n'y est exotique — ce sont les six premières choses que n'importe qui vérifie, dans cet ordre. ## Verrouiller l'origine pour que seule la façade puisse l'atteindre Une dissimulation qui dépend du fait que personne ne devine l'adresse n'est pas une dissimulation. Le montage ne tient que si l'origine refuse de parler à quiconque hormis la façade, de sorte qu'une adresse qui fuit soit une nuisance et non un événement. - **Refus par défaut, puis autorisation de la façade.** N'acceptez les ports 80 et 443 que depuis les plages d'adresses publiées du fournisseur, et rafraîchissez cette liste automatiquement — les plages changent, et une liste périmée échoue ouverte ou échoue fermée au pire moment. Tout le reste, y compris SSH, doit passer par un tunnel ou une adresse de gestion, comme dans notre [checklist de durcissement de la première heure](https://servhidden.com/fr/guides/first-hour-vps-hardening-checklist). - **Authentifiez la façade.** Des certificats client entre le CDN et votre origine — généralement appelés authenticated origin pulls — font qu'une adresse correcte plus un en-tête Host correct n'obtiennent rien sans le certificat. - **Mieux : aucun port entrant du tout.** Un tunnel strictement sortant de l'origine vers la périphérie, qu'il s'agisse du connecteur propre du CDN ou de WireGuard vers un nœud que vous exploitez, fait que l'origine n'écoute jamais sur une interface publique. Le scan ne peut pas trouver ce qui ne répond pas, et c'est la version la plus solide du montage. - **Un seul virtual host, un seul en-tête Host.** Le serveur par défaut ne doit rien renvoyer d'utile. Si votre site se charge par adresse, un scanner le repérera en moins d'une semaine. - **Sortez le courrier de l'origine web.** Le courrier doit être joignable et doit s'identifier ; gardez-le sur sa propre machine, comme le suppose le [guide du serveur mail](https://servhidden.com/fr/guides/offshore-mail-server-setup). - **Vérifiez depuis l'extérieur.** Chaque contrôle de cette liste est dénué de sens s'il est exécuté depuis le serveur lui-même. Testez depuis un réseau qui n'est pas le vôtre. ## Votre propre nœud frontal plutôt qu'un CDN La troisième option est souvent ignorée parce qu'elle n'a pas de budget marketing : un petit VPS en façade publique, un tunnel chiffré vers la machine qui détient les données, et nginx ou HAProxy qui fait transiter le trafic entre les deux. Vu de l'extérieur, cela ressemble à n'importe quel serveur web. Le vrai serveur est ailleurs, sans aucun port entrant. Ce que vous obtenez, c'est une dissimulation sans personne d'autre dans le montage — pas de compte tiers, pas de service abus externe, pas d'inconnu qui termine votre TLS. Vous obtenez aussi une séparation des juridictions autrement difficile à obtenir : la façade là où sont les utilisateurs, les données là où la loi vous convient, à choisir parmi nos [sept localisations](https://servhidden.com/fr/locations). Et comme aucune identité n'a été rattachée à l'inscription, la façade est jetable — une adresse grillée se remplace en quelques minutes plutôt que de se négocier. Ce que vous n'obtenez pas, c'est une capacité anycast. Un nœud n'a que la capacité d'un nœud, et si notre filtrage réseau le protège exactement comme il protège n'importe quel autre serveur, une attaque volumétrique réellement massive est un concours de bande passante que gagne un réseau mondial. La position honnête : un nœud frontal est la bonne réponse pour cacher un backend lourd ou coûteux — une baie de stockage, une machine GPU, un serveur mail, une base de données — et pour séparer les juridictions. Ce n'est pas un substitut à un CDN sous pression soutenue de couche 7. ## Choisir, en un tableau | Votre situation | Montage | Raisonnement | | --- | --- | --- | | Publication qui attire les notifications de retrait | Direct, sans CDN, dans une juridiction choisie à dessein | Un CDN ajoute un service de plaintes que votre hébergeur n'a délibérément pas | | Boutique ou SaaS avec de vrais utilisateurs et une pression de couche 7 | CDN devant, origine verrouillée sur ses plages | La couche 7 est le problème pour lequel un CDN est réellement conçu | | Point d'accès de contournement dans un pays censuré | CDN fronting | Le censeur voit une adresse qu'il ne peut pas se permettre de bloquer | | Trafic statique ou média important | CDN pour délester le cache | La bande passante et la latence sont l'enjeu ; la dissimulation est un effet secondaire | | L'anonymat est l'exigence première | Votre propre nœud frontal, ou rien devant | Un compte tiers est un registre d'identité que vous n'aviez pas avant | | Backend lourd qui mérite d'être caché | Nœud frontal plus tunnel strictement sortant | La machine coûteuse n'apparaît jamais sur l'internet public | ## Le compte est généralement le maillon le plus faible Considérez ce qui se passe quand l'infrastructure est parfaite et que la paperasse ne l'est pas. Le serveur a été payé en Monero, sans documents d'identité ni adresse e-mail — le montage décrit dans nos pages [hébergement no-KYC](https://servhidden.com/fr/no-kyc-hosting). Puis un compte CDN est ouvert avec une carte, une adresse personnelle et un numéro de téléphone, mentionnant le domaine qu'il protège. Ce compte est un registre d'identité plus solide et plus durable que tout ce qui se trouve sur le serveur, détenu par une entreprise qui répond aux citations à comparaître, et il annule entièrement la confidentialité du paiement. La correction n'est pas compliquée, seulement facile à oublier : si l'anonymat est l'objectif, soit la façade vous appartient, soit le compte qui se trouve devant elle est aussi jetable et aussi inattribuable que le serveur derrière elle. [L'OpSec serveur](https://servhidden.com/fr/guides/server-opsec-staying-anonymous) traite correctement cette discipline, et [notre réponse honnête sur l'anonymat offshore](https://servhidden.com/fr/guides/is-offshore-hosting-truly-anonymous) est sans détour sur les maillons de la chaîne qui cèdent généralement en premier. Ce ne sont presque jamais les maillons techniques. ## Auditer votre propre exposition en dix minutes Chaque point ci-dessous est quelque chose qu'une partie intéressée vérifierait dans les toutes premières minutes. Faites-le vous-même, depuis une machine qui n'est pas le serveur, avant d'avoir besoin des réponses. - **Listez chaque nom d'hôte que vous avez jamais certifié.** Cherchez votre domaine racine dans un moteur de recherche Certificate Transparency et résolvez chaque résultat. Tout ce qui ne pointe pas vers la façade est une fuite, y compris les hôtes que vous n'utilisez plus. - **Lisez votre propre historique DNS.** Une recherche de DNS passif montre les adresses vers lesquelles votre domaine résolvait avant le CDN. Si l'origine d'hier est encore celle d'aujourd'hui, la dissimulation n'a jamais été réelle. - **Interrogez l'origine directement.** curl -sI --resolve example.com:443:198.51.100.10 https://example.com/ — si le site répond, votre pare-feu ne restreint pas l'accès à la façade, et quiconque dispose d'une adresse candidate peut le confirmer en une seule requête. - **Interrogez-la sans ménagement.** curl -skI https://198.51.100.10/ ne devrait rien renvoyer de reconnaissable. Un virtual host par défaut qui sert votre page d'accueil est l'erreur isolée la plus courante de cette page. - **Vérifiez chaque type d'enregistrement, pas seulement A.** dig +short AAAA example.com, dig +short MX example.com, et de même pour chaque sous-domaine révélé par les journaux de transparence. Un IPv6 laissé non proxifié est un classique. - **Envoyez-vous un e-mail depuis l'application.** Déclenchez une réinitialisation de mot de passe et lisez la chaîne Received complète. Si l'adresse d'origine s'y trouve, elle se trouve aussi dans chaque message que vous avez jamais envoyé. - **Confirmez que les ports sont fermés.** Depuis un réseau qui n'est pas le vôtre, nmap -Pn -p80,443 198.51.100.10 devrait afficher filtered, pas open. - **Cherchez dans les scanners.** Recherchez l'empreinte de votre certificat et le hachage du favicon de votre page d'accueil dans un index public de scan d'internet. Si votre origine est indexée, c'est ainsi qu'elle sera trouvée. ## Quand l'adresse est déjà grillée Partez du principe qu'elle le restera. Une adresse apparue dans le DNS passif et dans des index de scan est un registre public permanent, et aucun changement de configuration ne le rétracte. La réponse est mécanique plutôt qu'ingénieuse. - **Réglez d'abord la fuite.** Faire tourner vers une nouvelle adresse sans refermer la brèche reproduit la situation en quelques jours, et vous aurez dépensé une migration pour n'avoir rien appris. - **Puis faites tourner.** Déployez un remplacement — dans une juridiction différente si la raison était légale plutôt que technique — restaurez, et basculez. Comme aucune identité n'était rattachée au premier serveur, c'est un nouveau départ plutôt qu'une négociation, ce qui est le bénéfice pratique et peu glorieux d'acheter des serveurs sans historique de compte. - **Préparez le basculement avant l'urgence.** Un TTL DNS court, une configuration que vous pouvez redéployer depuis un dépôt et une restauration testée transforment un mauvais après-midi en vingt minutes. Personne n'organise cela pendant une attaque. - **Retirez proprement l'ancienne adresse.** Ne laissez pas l'ancien serveur stationné sur l'ancienne adresse à servir le même contenu ; c'est une confirmation en direct pour quiconque observe, et cela maintient le registre à jour. ## La version courte Le filtrage au niveau réseau gère les attaques volumétriques, vient avec le serveur et ne coûte rien de plus. Un CDN gère la couche applicative et masque l'origine, au prix d'un intermédiaire qui termine votre TLS, répond aux plaintes et sait qui vous êtes. Votre propre nœud frontal achète la dissimulation sans l'intermédiaire, mais pas la capacité mondiale. La juridiction tranche la question légale et aucun des trois ne la touche. Et tous les trois sont défaits par un seul enregistrement non proxifié, un seul e-mail venu de l'origine, ou un seul virtual host par défaut. Décidez selon l'objectif plutôt que par habitude, puis consacrez les dix minutes à l'audit — il révèle plus d'exposition réelle que n'importe quelle mise à niveau. Si vous voulez l'architecture sans le tiers, un petit [VPS](https://servhidden.com/fr/vps) en façade et le vrai travail sur du [matériel dédié](https://servhidden.com/fr/dedicated) derrière est le montage que nous observons le plus souvent chez ceux qui se sont déjà fait trouver une fois. FAQ ## IP d'origine et DDoS — questions fréquentes ### 01 Un CDN masque-t-il la véritable adresse IP de mon serveur ? Il la masque aux clients, ce qui constitue l'essentiel du bénéfice : les visiteurs se connectent au CDN et ne voient jamais votre adresse. Il ne la masque pas aux registres publics déjà existants, à tout ce que votre serveur envoie vers l'extérieur, ni aux scanners qui parcourent tout l'internet et peuvent faire correspondre votre origine à son certificat ou à sa page d'accueil. Et cela ne fonctionne que si votre pare-feu empêche l'origine de répondre à quiconque d'autre que le CDN — sinon, l'adresse n'est qu'à une requête confirmée de redevenir utilisable. ### 02 Mettre Cloudflare ou un autre CDN devant annule-t-il l'hébergement DMCA-ignored ? En pratique, oui. Un CDN est partie prenante de votre service et a son propre processus de traitement des abus : des notifications peuvent être déposées directement contre lui, et il les transmettra typiquement, identifiera votre hébergeur, ou mettra fin à votre compte. Cela reconnecte la chaîne de retrait que l'hébergement offshore est choisi pour rompre. Pour un contenu qui attire les plaintes, le meilleur montage est un hébergement direct dans une juridiction choisie à dessein, avec le filtrage DDoS au niveau réseau déjà inclus avec le serveur. ### 03 La protection DDoS de couche 3/4 suffit-elle à elle seule ? Pour les attaques volumétriques — celles qui saturent votre liaison montante — oui, et c'est la seule couche qui peut aider ici, car elle agit avant que le trafic ne vous atteigne. Elle est incluse sur chaque offre avec une bande passante illimitée, donc une attaque ne génère pas non plus de facture. Ce à quoi elle ne peut pas répondre, c'est à une inondation de couche 7 faite de requêtes bien formées. Si une seule requête vers votre application peut déclencher un balayage de base de données ou un redimensionnement d'image, c'est là que se trouve votre risque, et la mise en cache, la limitation de débit et un WAF sont la réponse, pas le filtrage de paquets. ### 04 Comment retrouve-t-on l'IP d'origine derrière un CDN ? Six voies expliquent presque tout : les journaux Certificate Transparency qui révèlent des sous-domaines non proxifiés, les archives de DNS passif qui conservent l'adresse utilisée par le domaine avant le changement, les enregistrements qui ne peuvent pas être proxifiés comme les serveurs d'échange de courrier, les connexions sortantes du serveur lui-même y compris ses propres en-têtes d'e-mail, le scan de tout l'internet qui fait correspondre l'origine par certificat ou par contenu de page, et l'application qui divulgue sa propre adresse via des redirections, des points de terminaison de statut ou un virtual host par défaut. Aucune ne demande la moindre compétence. ### 05 Puis-je utiliser un CDN et rester anonyme ? Seulement si le compte est aussi anonyme que le serveur, ce qui est rarement le cas. Un compte CDN porte une adresse e-mail, un moyen de paiement et souvent un numéro de téléphone, liés à votre domaine et conservés indéfiniment par une entreprise qui répond aux procédures judiciaires. Si vous avez payé le serveur en Monero sans documents d'identité, puis ouvert un compte CDN avec une carte personnelle, ce compte est désormais le registre d'identité le plus solide de tout le montage. Soit vous gardez la façade sous votre propre contrôle, soit vous rendez le compte aussi jetable que tout le reste. ### 06 Ai-je besoin de tout cela pour un petit site ? Généralement non. Un petit site sur un serveur avec filtrage réseau, un pare-feu à refus par défaut et aucun service superflu est un montage parfaitement ordinaire et raisonnablement robuste. La question de l'origine devient réelle quand il existe une raison précise de cacher la machine — une audience qui inclut des gens susceptibles de l'attaquer, un backend qui vaut plus que la façade, ou un contenu dont vous préférez ne pas afficher le montage d'hébergement. ### 07 Le serveur mail doit-il tourner sur la même IP que le site web ? Non, et c'est l'une des façons les plus courantes dont une origine est exposée. Le courrier doit être joignable à une adresse qui ne peut pas être proxifiée, et chaque message qu'il envoie porte cette adresse dans ses en-têtes. Faire tourner le courrier sur une machine séparée garde l'origine web hors de chaque e-mail que vous envoyez et hors des enregistrements DNS que n'importe qui peut interroger. Cela évite aussi qu'un problème de réputation du courrier ne devienne un problème du site web. ### 08 Mon IP d'origine a déjà fuité — que faire maintenant ? Considérez l'adresse comme définitivement publique, car les archives de DNS passif et de scan la conservent. Refermez d'abord la fuite, qu'il s'agisse d'un enregistrement non proxifié, d'un canal e-mail ou d'un virtual host par défaut, puis passez à une nouvelle adresse et basculez avec un TTL DNS court préparé à l'avance. Ne laissez pas l'ancien serveur répondre sur l'ancienne adresse avec le même contenu. Comme rien dans le serveur d'origine n'était rattaché à une identité, le remplacer est un déploiement ordinaire plutôt qu'une négociation avec qui que ce soit. Guides connexes ## Continuer la lecture [### Comment choisir une juridiction d'hébergement offshore en 2026 Achat Un cadre de décision pratique pour choisir une juridiction offshore : loi sur la rétention de données, exposition aux MLAT, position face au DMCA, rapidité des tribunaux et application réelle — pays par pays. FAQ de 6 questions](https://servhidden.com/fr/guides/choosing-an-offshore-jurisdiction) [### VPS vs Serveur Dédié pour les Charges de Travail Sensibles à la Confidentialité Achat Quand un VPS suffit, quand la colocation est une responsabilité, et quand le bare metal est la seule réponse honnête. Isolation matérielle, risque hyperviseur, et coût vs modèle de menace. FAQ de 6 questions](https://servhidden.com/fr/guides/vps-vs-dedicated-for-privacy) [### VPN Auto-Hébergé sur un VPS Sans-KYC : WireGuard vs OpenVPN Exploitation Pourquoi un VPN auto-hébergé surpasse les fournisseurs commerciaux, et comment WireGuard et OpenVPN se comparent vraiment sur la confidentialité, les performances et le risque opérationnel en 2026. FAQ de 6 questions](https://servhidden.com/fr/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 pour l'inférence IA (et où se situe le RTX 5090) Achat Guide d'achat : quel GPU NVIDIA pour des charges LLM auto-hébergées, image, vidéo, voix et finetuning en 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, débit, $/token, quand chacun gagne. FAQ de 6 questions](https://servhidden.com/fr/guides/rtx-4090-vs-h100-for-ai-inference) [### RDP Windows offshore pour le trading Forex MT4 / MT5 / cTrader Exploitation Guide complet : pourquoi un RDP Windows pour le trading Forex, comment choisir une juridiction offshore à faible latence, configuration MT4 / MT5 / cTrader / Expert Advisor, latence vers les serveurs de courtiers, et la voie de paiement sans KYC. FAQ de 6 questions](https://servhidden.com/fr/guides/offshore-windows-rdp-for-forex-trading) [### L’hébergement DMCA-ignoré expliqué : ce que cela signifie vraiment en 2026 Achat Ce que l’hébergement « DMCA ignoré » vous apporte réellement, quelles juridictions le soutiennent vraiment, les charges de travail qui en ont besoin, et les pièges en matière de droits d’auteur que le terme ne couvre pas. FAQ de 6 questions](https://servhidden.com/fr/guides/dmca-ignored-hosting-explained) [### Enregistrement de domaine anonyme avec crypto : confidentialité WHOIS en 2026 Confidentialité Un guide pratique 2026 pour enregistrer des domaines sans révéler votre identité : régimes WHOIS par extension, choix du bureau d’enregistrement, options de paiement en crypto, et les erreurs opérationnelles qui vous trahissent quand même. FAQ de 6 questions](https://servhidden.com/fr/guides/anonymous-domain-registration-with-crypto) [### Paiements Crypto pour l'Hébergement : Monero vs Bitcoin vs USDT Confidentialité Comment le choix de la monnaie affecte ce que votre hébergeur apprend sur vous. Confidentialité, frais, finalité et exposition à l'analyse de chaîne pour XMR, BTC et USDT — avec une recommandation claire. FAQ de 6 questions](https://servhidden.com/fr/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### L’hébergement offshore est-il vraiment anonyme ? Une réponse honnête Confidentialité L’hébergement offshore sans KYC supprime l’identité qu’un hébergeur classique collecte — mais « anonyme » dépend du paiement, de la journalisation du fournisseur et de votre propre opsec. Voici ce qui est réellement traçable. FAQ de 6 questions](https://servhidden.com/fr/guides/is-offshore-hosting-truly-anonymous) [### La première heure de durcissement d’un VPS : une checklist Exploitation Une checklist concrète et ordonnée pour sécuriser un nouveau VPS en moins d’une heure : clés SSH, pare-feu, fail2ban, mises à jour automatiques, et la réduction de surface d’attaque qui stoppe la plupart des attaques opportunistes. FAQ de 6 questions](https://servhidden.com/fr/guides/first-hour-vps-hardening-checklist) [### Qu'est-ce que l'hébergement sans KYC ? Définition, légalité et fonctionnement Confidentialité L'hébergement sans KYC vous permet de louer un serveur sans aucune vérification d'identité — ni nom, ni e-mail, ni pièce d'identité. Voici exactement ce que cela signifie, comment ça fonctionne techniquement, si c'est légal, et comment choisir un vrai prestataire. FAQ de 6 questions](https://servhidden.com/fr/guides/what-is-no-kyc-hosting) [### L'hébergement offshore est-il légal ? La réponse honnête en 2026 Achat L'hébergement offshore est légal — pour vous comme pour le prestataire. Voici ce que le terme signifie vraiment, où se situe réellement la limite légale, les idées reçues à abandonner et comment l'utiliser de façon responsable. FAQ de 6 questions](https://servhidden.com/fr/guides/is-offshore-hosting-legal) [### Comment payer son hébergement avec Monero (XMR) — Guide étape par étape Confidentialité Un guide étape par étape pour payer un VPS ou un serveur dédié avec Monero (XMR) : pourquoi XMR est l'option la plus privée, comment l'obtenir, et comment fonctionne le paiement — de la facture à un serveur opérationnel en quelques minutes. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-pay-for-hosting-with-monero) [### Comment héberger un site web anonymement — Guide pratique 2026 Confidentialité Un guide pratique et structuré par couches pour héberger un site web sans identité attachée : le compte, le paiement, le domaine, la juridiction, votre connexion et le contenu — chaque couche expliquée. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-host-a-website-anonymously) [### Comment configurer un VPN WireGuard sur un VPS — Guide étape par étape Exploitation Créez votre propre VPN privé sur un VPS avec WireGuard : pourquoi un VPN auto-hébergé surpasse un service commercial, la configuration complète de l'installation à la connexion d'un client, et comment le renforcer. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### Comment héberger soi-même un LLM sur un serveur GPU — Guide 2026 Exploitation Faites tourner votre propre grand modèle de langage sur un serveur GPU loué : pourquoi l'auto-hébergement surpasse une API tierce, quel GPU et quel modèle choisir, la mise en place avec Ollama ou vLLM, et ce que ça coûte. FAQ de 6 questions](https://servhidden.com/fr/guides/self-host-an-llm-on-a-gpu-server) [### Hébergement bulletproof vs hébergement offshore — Quelle est la différence ? Achat Hébergement bulletproof et hébergement offshore sont constamment confondus — et pourtant ce n'est pas la même chose. Voici la vraie différence, pourquoi elle compte, et lequel des deux vous recherchez réellement. FAQ de 6 questions](https://servhidden.com/fr/guides/bulletproof-vs-offshore-hosting) [### Comment acheter un VPS avec Bitcoin — Guide étape par étape (2026) Achat Un guide accessible pour acheter un VPS avec Bitcoin : obtenir des BTC, choisir un plan, régler la facture et ce que vous obtenez — un serveur opérationnel sans carte bancaire et sans nom associé. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-buy-a-vps-with-bitcoin) [### Meilleurs pays pour un hébergement ignorant le DMCA en 2026 Achat Où héberger vos serveurs hors de portée des suppressions à l'américaine : les juridictions qui fonctionnent vraiment, ce que « ignorer le DMCA » signifie concrètement, et comment choisir. FAQ de 6 questions](https://servhidden.com/fr/guides/best-countries-for-dmca-ignored-hosting) [### Comment héberger un service caché Tor (site .onion) — Guide 2026 Exploitation Configurez un service onion Tor sur un VPS : ce qu'est un service caché, pourquoi c'est la forme d'hébergement anonyme la plus robuste, la mise en place complète et comment préserver réellement son anonymat. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-host-a-tor-hidden-service) [### Configuration d'un serveur mail offshore — Hébergez votre messagerie privée en 2026 Exploitation Gérez votre propre serveur de messagerie privé sur un VPS offshore : pourquoi auto-héberger vos emails, ce dont vous avez besoin, la mise en place concrète avec une solution tout-en-un, et comment assurer la délivrabilité. FAQ de 6 questions](https://servhidden.com/fr/guides/offshore-mail-server-setup) [### Guide d'hébergement de nœud crypto — Faire tourner un nœud blockchain sur un VPS Exploitation Comment héberger un nœud blockchain sur un serveur : pourquoi faire tourner son propre nœud, dimensionner le serveur pour Bitcoin, Ethereum, Monero et d'autres chaînes, la mise en place, et comment conserver sa confidentialité. FAQ de 6 questions](https://servhidden.com/fr/guides/crypto-node-hosting-guide) [### Hébergement GPU pour Stable Diffusion — Faites tourner votre propre serveur d'images Exploitation Faites tourner Stable Diffusion sur votre propre serveur GPU : pourquoi héberger soi-même la génération d'images, quel GPU choisir, la mise en place avec une interface web, et ce que cela coûte par rapport à un service hébergé. FAQ de 6 questions](https://servhidden.com/fr/guides/gpu-hosting-for-stable-diffusion) [### OpSec serveur — Rester anonyme quand on gère un serveur Confidentialité Sécurité opérationnelle pour toute personne gérant un serveur anonyme : les erreurs qui permettent de désanonymiser, les habitudes qui les préviennent, et comment maintenir une identité vraiment séparée. FAQ de 6 questions](https://servhidden.com/fr/guides/server-opsec-staying-anonymous) [### Guide de configuration d'une seedbox — Créez votre propre seedbox privée en 2026 Exploitation Comment créer sa propre seedbox sur un serveur : ce qu'est une seedbox, comment la dimensionner, installer un client torrent avec interface web, et la maintenir privée et sécurisée. FAQ de 6 questions](https://servhidden.com/fr/guides/seedbox-setup-guide) [### Comment contourner la censure DPI avec votre propre VPS (guide 2026) Confidentialité Votre VPN a cessé de fonctionner ? Comment contourner la censure DPI avec votre propre VPS : ce que l'inspection approfondie des paquets détecte réellement, lequel des cinq protocoles de 2026 bat quel type de blocage, et un guide complet de déploiement VLESS+REALITY. FAQ de 6 questions](https://servhidden.com/fr/guides/bypass-dpi-censorship-with-your-own-vps) [### Chiffrement intégral du disque sur un VPS : configuration LUKS Exploitation Comment chiffrer un VPS avec LUKS : volumes de données chiffrés, chiffrement intégral de la racine avec déverrouillage SSH, les réglages qui comptent sur un petit serveur, et ce que le chiffrement empêche vraiment. FAQ de 8 questions](https://servhidden.com/fr/guides/full-disk-encryption-on-a-vps) [### Sauvegarde VPS chiffrée et hors site : la stratégie qui restaure vraiment Exploitation Votre hébergeur ne conserve aucune sauvegarde. Ce qui détruit un serveur, restic contre Borg, les clés qu’on oublie, et comment tester une restauration. FAQ de 8 questions](https://servhidden.com/fr/guides/vps-backup-strategy) [### Auto-héberger Matrix : fédération, métadonnées et limites du chiffrement E2EE Exploitation Ce qu'un serveur Matrix auto-hébergé change : Synapse ou Conduit, le server_name qu'on ne change jamais, les médias qui saturent le disque, ce que révèle la fédération. FAQ de 8 questions](https://servhidden.com/fr/guides/self-host-a-matrix-server) [### Migrer un site vers un hébergeur offshore sans interruption Exploitation L’ordre qui rend une migration d’hébergeur ennuyeuse : baisser le TTL DNS plusieurs jours à l’avance, faire tourner les deux serveurs en parallèle, geler les écritures pendant des minutes plutôt que des heures — et nettoyer la trace laissée par le DNS passif, les journaux Certificate Transparency et le WHOIS. FAQ de 8 questions](https://servhidden.com/fr/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Exploitation Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. FAQ de 8 questions](https://servhidden.com/fr/guides/self-host-a-crypto-payment-gateway) ## Mettez la bonne couche devant le bon serveur Filtrage DDoS au niveau réseau et bande passante illimitée sur chaque offre, dans sept juridictions offshore. Faites tourner un nœud frontal pour quelques dollars par mois, gardez le vrai travail derrière — sans KYC, crypto uniquement. [Voir les offres VPS](https://servhidden.com/fr/vps) [DMCA ignoré](https://servhidden.com/fr/dmca-ignored-hosting) [Hébergement offshore](https://servhidden.com/fr/anonymous-hosting) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "VPS et serveurs dédiés offshore dans 7 juridictions privacy-friendly. Sans KYC, sans logs, crypto uniquement. La vie privée par architecture.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Masquer l'IP d'origine : CDN, reverse proxy et fuites", "description": "Faut-il un CDN devant un serveur offshore : ce qu'il masque, le service abus hérité, les six fuites d'IP d'origine possibles, et comment auditer la vôtre.", "image": "https://servhidden.com/assets/img/guides/hiding-your-origin-server-ip.webp?v=1787175673", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-19T00:00:00+00:00", "dateModified": "2026-08-19T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/hiding-your-origin-server-ip", "inLanguage": "fr", "keywords": "hide origin server IP, origin IP leak, Cloudflare offshore hosting, DDoS protection offshore VPS, reverse proxy hide origin, L7 DDoS mitigation, certificate transparency origin leak, lock origin to CDN IP ranges", "articleSection": "Confidentialité", "wordCount": 3562 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Un CDN masque-t-il la véritable adresse IP de mon serveur ?", "acceptedAnswer": { "@type": "Answer", "text": "Il la masque aux clients, ce qui constitue l'essentiel du bénéfice : les visiteurs se connectent au CDN et ne voient jamais votre adresse. Il ne la masque pas aux registres publics déjà existants, à tout ce que votre serveur envoie vers l'extérieur, ni aux scanners qui parcourent tout l'internet et peuvent faire correspondre votre origine à son certificat ou à sa page d'accueil. Et cela ne fonctionne que si votre pare-feu empêche l'origine de répondre à quiconque d'autre que le CDN — sinon, l'adresse n'est qu'à une requête confirmée de redevenir utilisable." } }, { "@type": "Question", "name": "Mettre Cloudflare ou un autre CDN devant annule-t-il l'hébergement DMCA-ignored ?", "acceptedAnswer": { "@type": "Answer", "text": "En pratique, oui. Un CDN est partie prenante de votre service et a son propre processus de traitement des abus : des notifications peuvent être déposées directement contre lui, et il les transmettra typiquement, identifiera votre hébergeur, ou mettra fin à votre compte. Cela reconnecte la chaîne de retrait que l'hébergement offshore est choisi pour rompre. Pour un contenu qui attire les plaintes, le meilleur montage est un hébergement direct dans une juridiction choisie à dessein, avec le filtrage DDoS au niveau réseau déjà inclus avec le serveur." } }, { "@type": "Question", "name": "La protection DDoS de couche 3/4 suffit-elle à elle seule ?", "acceptedAnswer": { "@type": "Answer", "text": "Pour les attaques volumétriques — celles qui saturent votre liaison montante — oui, et c'est la seule couche qui peut aider ici, car elle agit avant que le trafic ne vous atteigne. Elle est incluse sur chaque offre avec une bande passante illimitée, donc une attaque ne génère pas non plus de facture. Ce à quoi elle ne peut pas répondre, c'est à une inondation de couche 7 faite de requêtes bien formées. Si une seule requête vers votre application peut déclencher un balayage de base de données ou un redimensionnement d'image, c'est là que se trouve votre risque, et la mise en cache, la limitation de débit et un WAF sont la réponse, pas le filtrage de paquets." } }, { "@type": "Question", "name": "Comment retrouve-t-on l'IP d'origine derrière un CDN ?", "acceptedAnswer": { "@type": "Answer", "text": "Six voies expliquent presque tout : les journaux Certificate Transparency qui révèlent des sous-domaines non proxifiés, les archives de DNS passif qui conservent l'adresse utilisée par le domaine avant le changement, les enregistrements qui ne peuvent pas être proxifiés comme les serveurs d'échange de courrier, les connexions sortantes du serveur lui-même y compris ses propres en-têtes d'e-mail, le scan de tout l'internet qui fait correspondre l'origine par certificat ou par contenu de page, et l'application qui divulgue sa propre adresse via des redirections, des points de terminaison de statut ou un virtual host par défaut. Aucune ne demande la moindre compétence." } }, { "@type": "Question", "name": "Puis-je utiliser un CDN et rester anonyme ?", "acceptedAnswer": { "@type": "Answer", "text": "Seulement si le compte est aussi anonyme que le serveur, ce qui est rarement le cas. Un compte CDN porte une adresse e-mail, un moyen de paiement et souvent un numéro de téléphone, liés à votre domaine et conservés indéfiniment par une entreprise qui répond aux procédures judiciaires. Si vous avez payé le serveur en Monero sans documents d'identité, puis ouvert un compte CDN avec une carte personnelle, ce compte est désormais le registre d'identité le plus solide de tout le montage. Soit vous gardez la façade sous votre propre contrôle, soit vous rendez le compte aussi jetable que tout le reste." } }, { "@type": "Question", "name": "Ai-je besoin de tout cela pour un petit site ?", "acceptedAnswer": { "@type": "Answer", "text": "Généralement non. Un petit site sur un serveur avec filtrage réseau, un pare-feu à refus par défaut et aucun service superflu est un montage parfaitement ordinaire et raisonnablement robuste. La question de l'origine devient réelle quand il existe une raison précise de cacher la machine — une audience qui inclut des gens susceptibles de l'attaquer, un backend qui vaut plus que la façade, ou un contenu dont vous préférez ne pas afficher le montage d'hébergement." } }, { "@type": "Question", "name": "Le serveur mail doit-il tourner sur la même IP que le site web ?", "acceptedAnswer": { "@type": "Answer", "text": "Non, et c'est l'une des façons les plus courantes dont une origine est exposée. Le courrier doit être joignable à une adresse qui ne peut pas être proxifiée, et chaque message qu'il envoie porte cette adresse dans ses en-têtes. Faire tourner le courrier sur une machine séparée garde l'origine web hors de chaque e-mail que vous envoyez et hors des enregistrements DNS que n'importe qui peut interroger. Cela évite aussi qu'un problème de réputation du courrier ne devienne un problème du site web." } }, { "@type": "Question", "name": "Mon IP d'origine a déjà fuité — que faire maintenant ?", "acceptedAnswer": { "@type": "Answer", "text": "Considérez l'adresse comme définitivement publique, car les archives de DNS passif et de scan la conservent. Refermez d'abord la fuite, qu'il s'agisse d'un enregistrement non proxifié, d'un canal e-mail ou d'un virtual host par défaut, puis passez à une nouvelle adresse et basculez avec un TTL DNS court préparé à l'avance. Ne laissez pas l'ancien serveur répondre sur l'ancienne adresse avec le même contenu. Comme rien dans le serveur d'origine n'était rattaché à une identité, le remplacer est un déploiement ordinaire plutôt qu'une négociation avec qui que ce soit." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Accueil", "item": "https://servhidden.com/fr/" }, { "@type": "ListItem", "position": 2, "name": "Guides Hébergement Privé", "item": "https://servhidden.com/fr/guides" }, { "@type": "ListItem", "position": 3, "name": "Masquer l'IP d'origine : CDN, reverse proxy et fuites", "item": "https://servhidden.com/fr/guides/hiding-your-origin-server-ip" } ] } ```