[Accueil](https://servghost.com/fr) /
[Guides Hébergement Privé](https://servghost.com/fr/guides) /
Protection DDoS VPS : où finit l'hébergeur, où commence la couche 7






Exploitation


# Survivre à une attaque DDoS sur votre VPS



Chaque offre d'hébergement annonce une « protection DDoS incluse », et cela signifie toujours la même chose, assez étroite : le réseau absorbe des inondations mesurées en gigabits. Les attaques qui mettent réellement à terre les petits sites se mesurent en requêtes par seconde, ne coûtent presque rien à l'attaquant, et arrivent en ayant l'air parfaitement légitimes. Ce guide trace la ligne entre les deux, montre comment déterminer en une minute de quel côté vous vous trouvez, et couvre ce qui tient vraiment du côté de la ligne qui vous revient.


[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





26 min de lecture
Mis à jour Sep 2026

Sur cette page

[01Deux attaques différentes qui partagent un seul nom](#deux-attaques-différentes-qui-partagent-un-seul-nom)
[02Ce qu'achète réellement la « protection DDoS incluse »](#ce-quachète-réellement-la-protection-ddos-incluse)
[03D'abord, déterminez s'il s'agit bien d'une attaque](#dabord-déterminez-sil-sagit-bien-dune-attaque)
[04Lire l'attaque depuis le serveur lui-même](#lire-lattaque-depuis-le-serveur-lui-même)
[05Les dix premières minutes](#les-dix-premières-minutes)
[06Des limites de débit qui tiennent, et l'erreur que tout le monde commet](#des-limites-de-débit-qui-tiennent-et-lerreur-que-tout-le-mon)
[07La mise en cache est la mitigation la moins chère que vous déploierez jamais](#la-mise-en-cache-est-la-mitigation-la-moins-chère-que-vous-d)
[08Les plafonds qui décident si le serveur s'effondre](#les-plafonds-qui-décident-si-le-serveur-seffondre)
[09Mettre quelque chose devant l'origine](#mettre-quelque-chose-devant-lorigine)
[10Une origine cachée vaut mieux que n'importe quel filtre](#une-origine-cachée-vaut-mieux-que-nimporte-quel-filtre)
[11Choisir le matériel et l'emplacement pour qu'une attaque reste un non-événement](#choisir-le-matériel-et-lemplacement-pour-quune-attaque-reste)
[12Cinq choses à ne pas faire](#cinq-choses-à-ne-pas-faire)
[13La version courte](#la-version-courte)
[FAQQuestions fréquentes](#guide-faq)
[→Pages recommandées](#guide-cta)







Il y a deux moments où l'on découvre comment fonctionne réellement la mitigation DDoS. Le premier est calme, au moment de l'achat, en lisant une liste de fonctionnalités qui annonce « protection DDoS incluse » et en supposant tranquillement que cette phrase couvre tout. Le second survient à trois heures du matin, quand le site est en panne, que les graphiques affichent quelque chose d'incompréhensible, et que cette protection incluse ne fait — à juste titre, et par conception — strictement rien.

Les deux moments concernent le même produit et la même vérité : un hébergeur filtre les attaques qui arrivent sous forme de volume brut, parce qu'il possède le tuyau par lequel transitent ces paquets, et vous non. Il ne peut pas filtrer les attaques qui arrivent sous forme de requêtes d'apparence ordinaire, parce que, du point de vue du réseau, ce sont des requêtes d'apparence ordinaire. Cette ligne — entre l'inondation que votre hébergeur absorbe et celle à laquelle vous devez survivre vous-même — est tout le sujet de ce guide. Tout ce qui suit consiste à déterminer de quel côté de cette ligne vous vous trouvez, et que faire dans chaque cas.

## Deux attaques différentes qui partagent un seul nom

« DDoS » est un seul mot qui recouvre deux problèmes n'ayant presque rien en commun, à part le résultat. Ils sont arrêtés à des endroits différents, par des personnes différentes, avec des outils différents, et les confondre est la raison pour laquelle tant d'efforts de mitigation atterrissent dans la mauvaise couche.

| | Volumétrique — couches 3 et 4 | Applicatif — couche 7 |
| --- | --- | --- |
| Ce qui arrive | Inondations SYN, amplification UDP via des réflecteurs DNS, NTP ou memcached ouverts, inondations ACK, de purs paquets indésirables | Requêtes HTTP ordinaires : inondations GET, inondations POST, Slowloris, chaînes de requête destinées à casser le cache |
| Se mesure en | Gigabits et millions de paquets par seconde | Requêtes par seconde — souvent seulement quelques milliers |
| Bande passante nécessaire pour vous nuire | Énorme. C'est un concours de capacité | Presque aucune. Un simple portable y suffit si le point de terminaison est assez coûteux |
| Où cela doit être arrêté | **En amont, par votre hébergeur.** Le temps que les paquets atteignent votre port, le mal est déjà fait | **Sur votre serveur, par vous**, ou sur un proxy que vous contrôlez devant lui |
| À quoi cela ressemble sur la machine | Interface saturée, compteurs de paquets absurdes, le CPU peut rester inactif | Bande passante modeste, mais tous les workers occupés, charge qui grimpe, file d'attente de la base de données qui grossit |
| Qui le corrige | Le filtrage de votre hébergeur, automatiquement, généralement en quelques secondes | Votre configuration — limites de débit, mise en cache, plafonds de connexions |

Relisez les deux dernières lignes, car c'est là que se trouve le point pratique. Si l'interface est saturée, rien de ce que vous taperez sur le serveur n'aidera : les paquets ont déjà consommé le port, et la seule partie capable de les rejeter est celle qui possède le routeur en amont. Si l'interface est calme mais que le site est toujours en panne, c'est l'inverse qui est vrai — votre hébergeur ne voit rien d'anormal parce que, à son niveau, rien *n'est* anormal, et la correction vous revient entièrement.

Les inondations volumétriques sont filtrées en amont, là où se trouve la capacité. Ce qui survit à ce filtre, c'est du trafic d'apparence ordinaire — et l'arrêter est votre travail, pas celui de votre hébergeur.

## Ce qu'achète réellement la « protection DDoS incluse »

La protection au niveau réseau est réelle, précieuse, et presque toujours mal comprise. Quand un hébergeur annonce un filtrage L3/L4, cela signifie que son réseau surveille le trafic destiné à votre adresse, et que lorsqu'une inondation est détectée, ce trafic est dérouté vers des équipements de filtrage qui éliminent la portion malveillante et transmettent ce qui ressemble à du trafic légitime. Cela se produit sans ticket de support et généralement sans que vous remarquiez plus qu'un bref accroc.

Cette seule phrase fait beaucoup de travail, et il vaut la peine de détailler ce qu'elle couvre et ce qu'elle ne couvre pas :

- **Elle couvre les attaques que vous ne pouvez pas affronter seul.** Une inondation par amplification de 200 Gbps contre un serveur avec un port à 1 Gbps n'est pas un problème de configuration. C'est de l'arithmétique. Le filtrage en amont est la seule réponse qui existe.

- **Elle est sans état vis-à-vis de votre application.** Le filtre ne sait pas lesquelles de vos URL sont coûteuses, quels visiteurs sont connectés, ou qu'une requête vers votre point de terminaison de recherche coûte quatre cents fois plus qu'une requête vers votre logo.

- **Elle réagit à un seuil, pas à votre souffrance.** La détection se déclenche sur le volume de trafic. Une attaque qui ne franchit jamais ce seuil ne le déclenche jamais, quelle que soit l'ampleur avec laquelle elle a mis votre site à terre.

- **Elle peut brièvement null-router l'adresse dans les cas extrêmes.** Chaque réseau a un plafond. Si une attaque menace une infrastructure partagée, l'adresse peut être null-routée pendant un moment — c'est une pratique standard et universelle, qu'il vaut mieux connaître avant que cela n'arrive plutôt que pendant.

**La version en une ligne :** votre hébergeur protège son réseau, et vous en profitez. Il ne protège pas votre application, et il n'a aucun moyen de le faire. La couche 7 n'est pas une option payante qui vous aurait été refusée — c'est une couche dans laquelle votre hébergeur ne peut pas voir sans terminer votre TLS, ce qui, pour quiconque héberge offshore, est un compromis avec ses propres coûts sérieux.

## D'abord, déterminez s'il s'agit bien d'une attaque

Une part impressionnante des incidents pris pour des DDoS sont en réalité autre chose déguisé, et les corrections ne sont pas interchangeables. Avant de limiter quoi que ce soit en débit, passez deux minutes à écarter les imposteurs — une erreur de diagnostic ici vous coûte une heure et, parfois, vos vrais utilisateurs.

- **Vous êtes devenu populaire.** Un lien sur un grand agrégateur produit une forme de trafic qui ressemble exactement à une inondation de couche 7, sauf que les référents sont réels et que les requêtes portent sur des pages qu'un humain voudrait consulter. C'est un problème de capacité avec une cause heureuse ; le limiter en débit revient à se faire du tort à soi-même.

- **Un robot d'indexation a perdu ses manières.** Des scrapers agressifs et des robots d'entraînement d'IA peuvent trivialement dépasser les capacités d'un petit serveur. Le user-agent le trahit généralement, et la correction passe par robots.txt plus une limite ciblée, pas une limite générale.

- **Vous avez cassé quelque chose.** Un déploiement qui a désactivé la mise en cache, une tâche cron devenue incontrôlable, une base de données qui a perdu un index — tout cela se présente comme « une charge soudaine, sans cause évidente ». Si le moment correspond à un changement que vous avez fait, croyez ce changement.

- **Votre propre supervision est l'inondation.** Rare, gênant, et bien plus fréquent que quiconque ne l'admet. Une boucle de health-check qui retente sans backoff peut générer un débit de requêtes véritablement impressionnant.

La question qui permet de distinguer les deux est simple : *ce trafic veut-il quelque chose ?* Une charge réelle — même une charge réelle d'apparence hostile — a une forme. Elle frappe des pages qui existent, suit des liens, charge des ressources, et provient d'une répartition plausible de réseaux. Une attaque, en général, ne s'embête pas avec tout cela.

## Lire l'attaque depuis le serveur lui-même

Vous n'avez pas besoin d'un tableau de bord pour classifier ce qui se passe. Quatre commandes, exécutées dans l'ordre, vous diront en moins d'une minute dans quelle couche vous vous battez — et le savoir détermine tout ce que vous ferez ensuite.

**Le tuyau est-il plein ?** Surveillez les compteurs d'interface. Si le débit est collé près du plafond du port, vous êtes dans une attaque volumétrique et votre travail consiste à ouvrir un ticket de support, pas à changer une configuration :

- vnstat -tr 10 — débit moyen sur dix secondes, la lecture honnête la plus rapide de la saturation.

- cat /proc/net/dev exécuté deux fois à une seconde d'intervalle — deltas de paquets et d'octets par interface, sans outillage particulier.

**S'agit-il d'une inondation SYN ?** Les connexions semi-ouvertes s'accumulent en SYN-RECV. Une poignée est normale ; des milliers ne le sont pas :

- ss -s — la ligne de résumé, le nombre de connexions par état en un coup d'œil.

- ss -tn state syn-recv | wc -l — le chiffre précis qui compte.

**S'agit-il de la couche 7 ?** Si la bande passante est banale mais que tout est lent, comptez les requêtes par client dans votre journal d'accès. Une seule adresse avec des dizaines de milliers de coups est un amateur ; cent mille adresses avec trois coups chacune, c'est du sérieux :

- tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30

- Remplacez $1 par $7 pour classer les chemins demandés à la place. Si un point de terminaison coûteux domine, vous avez trouvé la cible et la moitié de la solution.

**Qu'est-ce qui est réellement épuisé ?** Le load average ne vous dit pas grand-chose à lui seul. Cherchez le plafond précis que vous avez atteint : processus PHP-FPM tous occupés, connexions à la base de données à leur limite, descripteurs de fichiers épuisés, ou workers bloqués en état D en attente du disque. C'est ce plafond — pas le trafic — qui a mis le site à terre, et le relever est souvent plus rapide que de filtrer quoi que ce soit.

**Gardez ceci en tête pendant que vous cherchez :** si vous exploitez un service axé sur la confidentialité, une attaque est précisément le moment où vous serez le plus tenté d'augmenter la verbosité des journaux et de l'y laisser. Augmentez-la si vous le devez, puis redescendez-la et faites tourner les fichiers de façon agressive ensuite. Un incident qui laisse un mois de journaux de visiteurs en plein détail sur le disque a échangé un problème contre un autre, pire et plus durable. Notre [guide d'OpSec serveur](https://servghost.com/fr/guides/server-opsec-staying-anonymous) couvre la discipline à laquelle cela appartient.

## Les dix premières minutes

Sous pression, les gens saisissent le plus gros levier disponible, et c'est généralement le mauvais. Voici l'ordre qui limite les dégâts, à peu près du plus rapide et plus sûr au reste :

- **Classifiez avant d'agir.** Interface saturée signifie volumétrique ; interface calme avec des workers occupés signifie couche 7. Trente secondes passées ici vous évitent de corriger la mauvaise couche pendant une heure.

- **Si c'est volumétrique, ouvrez immédiatement un ticket** en incluant l'adresse de destination, l'heure de début, et vos compteurs d'interface. Puis arrêtez de taper quoi que ce soit sur le serveur — vous ne pouvez pas corriger cela depuis l'intérieur.

- **Si c'est la couche 7, mettez en cache d'abord.** Activer une mise en cache agressive de pages entières pour les visiteurs anonymes est le moyen le plus rapide de transformer une panne en simple haussement d'épaules, et c'est la seule mesure qui aide aussi contre du trafic réel.

- **Puis limitez le débit** — d'abord le point de terminaison ciblé, tout le reste ensuite. Commencez prudemment. Une limite qui met hors service vos propres utilisateurs est une continuation auto-infligée de l'attaque.

- **Ne bloquez que ce qui est sans ambiguïté.** Une douzaine d'adresses avec cent mille requêtes chacune, un user-agent manifestement faux, un pays où vous n'avez aucun utilisateur. Résistez à l'envie d'écrire des règles élaborées sous le feu ; vous ne vous en souviendrez plus le mois prochain.

- **Délestez la charge délibérément si nécessaire.** Servir une page statique « en maintenance » aux visiteurs non authentifiés maintient la machine en vie, maintient votre API disponible, et vous achète du temps de réflexion. Décider quoi sacrifier vaut mieux que de le laisser décider à votre place.

- **Notez ce que vous avez fait.** Chaque règle temporaire que vous ajoutez est un piège que vous laissez à votre futur vous. Les règles qui ont aidé deviennent permanentes ; le reste ressort demain.

## Des limites de débit qui tiennent, et l'erreur que tout le monde commet

La limitation de débit est l'instrument principal pour la couche 7, et nginx s'en tire bien avec deux directives qui résolvent deux problèmes véritablement différents. limit_req plafonne le *débit* des requêtes — la fréquence à laquelle un client peut demander. limit_conn plafonne la *concurrence* — le nombre de connexions qu'un client peut maintenir ouvertes à la fois. Les inondations demandent la première ; les attaques Slowloris, qui maintiennent des milliers de connexions quasi inactives pour épuiser votre pool de workers, demandent la seconde. N'en déployer qu'une seule vous couvre contre la moitié du problème.

Trois détails séparent une limite qui fonctionne d'une limite décorative :

- **Utilisez un burst, et utilisez nodelay.** Les vrais navigateurs fonctionnent par rafales — une seule vue de page déclenche une douzaine de requêtes de ressources quasi simultanées. Une limite sans marge étrangle les visiteurs authentiques pendant qu'un attaquant qui se cale juste sous le seuil passe sans encombre.

- **Limitez séparément les points de terminaison coûteux.** Votre page de recherche, votre formulaire de connexion, la réinitialisation de mot de passe, et tout point de terminaison qui écrit dans la base de données méritent un budget bien plus serré que vos ressources statiques. Les attaquants les trouvent sans effort, parce que ce sont ceux qui font mal.

- **Renvoyez 429, pas 503.** Le code de statut signale aux clients bien élevés et aux moteurs de recherche qu'il s'agit d'une limitation et non d'une panne — et cela évite qu'un mauvais après-midi ne se transforme en problème de classement.

**L'erreur qui annule silencieusement tout cela :** si quoi que ce soit se trouve devant votre serveur — un CDN, un load balancer, votre propre reverse proxy — alors chaque requête arrive depuis *son* adresse, pas celle du visiteur. Une limite de débit par client compte alors l'internet entier comme un seul client, et elle ne fera soit rien du tout, soit elle bannira toute votre audience d'un coup. Vous devez configurer votre source de véritable IP (en nginx, set_real_ip_from pour les plages du proxy plus real_ip_header pour l'en-tête qu'il envoie) *avant* que les limites n'aient le moindre sens. Restreignez-la aussi aux plages propres du proxy : faire confiance à un en-tête fourni par le client depuis l'internet ouvert permet à un attaquant de forger une nouvelle identité à chaque requête et de traverser directement chaque limite que vous possédez.

## La mise en cache est la mitigation la moins chère que vous déploierez jamais

Une limite de débit rejette du travail. Un cache fait que le travail n'existe pas. Pour tout ce qu'un visiteur anonyme voit, la mise en cache de pages entières change l'économie de toute l'attaque : une requête qui aurait coûté un aller-retour en base de données, un rendu de template et un worker PHP devient une lecture de fichier mesurée en microsecondes. Le même serveur qui s'effondrait à quatre cents requêtes dynamiques par seconde en servira des dizaines de milliers en cache sans même le remarquer.

Ce qui compte quand vous l'activez dans l'urgence :

- **Ne mettez en cache que pour les visiteurs anonymes.** Contournez le cache sur un cookie de session. Servir la page d'un utilisateur connecté à un autre est un incident bien pire que la panne que vous étiez en train de corriger.

- **Servez du contenu périmé, délibérément.** Le proxy_cache_use_stale de nginx associé à updating error timeout fait que, quand votre backend peine, les visiteurs reçoivent une page légèrement ancienne plutôt qu'une erreur. Pendant une attaque, c'est la différence entre un site qui a l'air d'aller bien et un site qui a l'air mort.

- **Fusionnez les miss de cache identiques.** proxy_cache_lock garantit que mille requêtes simultanées pour la même page non mise en cache produisent une seule requête vers le backend, pas mille. Sans cela, une attaque de contournement du cache traverse le cache directement et atterrit sur votre base de données à pleine puissance.

- **Neutralisez les chaînes de requête qui cassent le cache.** L'astuce classique consiste à ajouter ? suivi d'une valeur aléatoire pour que chaque requête soit une clé unique et rate le cache indéfiniment. Normalisez votre clé de cache pour ignorer les paramètres de requête que votre application n'utilise pas réellement.

Il y a ici une asymétrie agréable qu'il vaut la peine d'intérioriser : chaque heure passée sur la mise en cache rend aussi le site plus rapide les bons jours, moins coûteux à faire tourner, et meilleur pour survivre au succès. Presque aucune autre ligne de défense ne verse un dividende quand tout va bien.

## Les plafonds qui décident si le serveur s'effondre

La plupart des serveurs ne meurent pas parce qu'ils manquent de CPU. Ils meurent parce qu'ils heurtent un plafond invisible que personne n'a fixé délibérément — une valeur par défaut vieille de dix ans qui avait du sens sur du matériel que plus personne n'utilise. Sous attaque, voici ce qui casse réellement en premier :

- **Les workers applicatifs.** Le pm.max_children de PHP-FPM, votre nombre de workers Python, la taille de votre cluster Node. C'est la vraie limite de concurrence de votre site. Quand ils sont tous occupés, chaque visiteur supplémentaire fait la queue, et le site est en panne, peu importe à quel point le CPU semble inactif. Ne l'augmentez que dans la limite que la mémoire permet — le swap est pire que la file d'attente.

- **La file d'acceptation.** net.core.somaxconn et votre backlog d'écoute décident combien de connexions peuvent attendre d'être acceptées. Un petit backlog transforme une rafale survivable en connexions refusées.

- **Les cookies SYN.** net.ipv4.tcp_syncookies permet au noyau de répondre à une inondation SYN sans allouer d'état pour des connexions qui ne s'achèveront jamais. Les noyaux modernes l'activent par défaut ; vérifiez-le plutôt que de le supposer, car cela ne coûte rien et vous épargne l'inondation la plus courante qui soit.

- **Les descripteurs de fichiers.** Chaque connexion est un descripteur. La limite nofile par défaut est fréquemment inférieure au nombre de connexions que vous essayez de servir, et le mode de défaillance — des accepts qui échouent alors que tout semble sain — est authentiquement déroutant à trois heures du matin.

- **Les connexions à la base de données.** Augmenter votre nombre de workers sans augmenter le pool de connexions ne fait que déplacer la file d'attente vers un endroit plus difficile à observer. Ces deux chiffres doivent être ajustés ensemble.

Réglez tout cela un jour calme, pas pendant un incident. L'intérêt de les connaître, c'est que lorsque le site s'effondre, vous pouvez nommer le plafond qu'il a heurté au lieu de deviner — et un plafond nommé est un plafond que l'on corrige.

## Mettre quelque chose devant l'origine

Tout ce qui précède se passe sur le serveur. L'étape suivante consiste à décider si le serveur doit être la chose qui reçoit le trafic, tout simplement. Il existe trois options honnêtes, et la bonne réponse dépend bien plus de ce que vous hébergez que de ce que vous pouvez vous permettre.

| Approche | Ce que cela vous donne | Ce que cela vous coûte |
| --- | --- | --- |
| Origine directement exposée, durcie | Simplicité, aucun tiers, aucune terminaison TLS que vous ne contrôlez pas | Votre adresse est publique et permanente. La couche 7 est entièrement à votre charge |
| CDN commercial ou service de filtrage | Capacité d'absorption considérable, une page de vérification activable en un clic, mise en cache mondiale | Un service abus qui a un avis sur votre contenu, et une entreprise qui peut voir votre trafic. Pour des projets offshore ou sensibles au DMCA, cela peut être le maillon le plus faible d'un montage par ailleurs soigné |
| Votre propre nœud frontal — un petit VPS faisant tourner nginx, en proxy vers une origine protégée par pare-feu | Contrôle total, aucun tiers dans le chemin de la requête, une adresse que vous pouvez brûler et remplacer, et une adresse réelle qui reste cachée | Ses propres limites de capacité, et une machine de plus à faire tourner. Deux ou trois façades sur des réseaux différents rendent la mise hors service nettement plus difficile |

Le nœud frontal auto-hébergé mérite plus d'attention qu'il n'en reçoit habituellement, en particulier pour quiconque a choisi l'hébergement offshore pour des raisons qu'un grand CDN pourrait ne pas partager. Le schéma n'a rien de spectaculaire : des nœuds proxy bon marché devant, une origine protégée par pare-feu qui n'accepte les connexions que de ces nœuds, un DNS qui pointe vers les façades. Si une façade est attaquée, vous la remplacez par une nouvelle adresse en quelques minutes et l'origine ne s'en aperçoit jamais. La version complète de cette architecture — y compris les six façons dont une adresse d'origine fuit quand même — fait l'objet de notre guide sur [la dissimulation de l'IP de votre serveur d'origine](https://servghost.com/fr/guides/hiding-your-origin-server-ip).

## Une origine cachée vaut mieux que n'importe quel filtre

Cela vaut la peine de le dire sans détour, car cela inverse la priorité habituelle : la mitigation DDoS la moins chère à votre disposition est une adresse que l'attaquant ne possède pas. Le filtrage, c'est ce que vous faites quand cela a déjà échoué.

Cela compte plus qu'il n'y paraît, car les adresses d'origine fuient constamment et discrètement. Les enregistrements DNS historiques d'avant la mise en place d'un proxy survivent au changement pendant des années. Le courrier envoyé directement depuis l'application porte l'adresse dans ses en-têtes. Un certificat TLS émis sur l'adresse brute est publié en permanence dans les journaux Certificate Transparency. Une page d'erreur, une redirection, ou un sous-domaine obscur qui n'a jamais été proxifié, tout cela la trahit. Si vous avez mis un CDN devant un serveur qui était auparavant exposé, partez du principe que l'ancienne adresse est connue tant que vous ne l'avez pas changée.

**Le corollaire est une règle de pare-feu, et c'est la ligne la plus précieuse de tout ce guide :** une fois que quelque chose se trouve devant, l'origine devrait refuser les connexions sur les ports 80 et 443 en provenance de tout sauf des adresses de cette façade. Sans cela, le proxy n'est qu'une suggestion — quiconque apprend l'adresse réelle la contourne simplement et vous attaque directement, et tout ce que vous avez configuré en façade devient décoratif.

## Choisir le matériel et l'emplacement pour qu'une attaque reste un non-événement

Une partie de tout cela se décide avant même qu'une attaque n'ait lieu, au moment où vous choisissez une offre. Trois propriétés comptent bien plus que ne le suggère la fiche technique :

- **La bande passante illimitée.** Sur une offre avec quota, une attaque n'est pas seulement une panne — c'est une facture. Un trafic que vous n'avez jamais demandé et que vous ne pouviez pas refuser compte quand même dans votre forfait. Le transfert illimité convertit un risque financier en un risque purement technique, ce qui est une bien meilleure catégorie de problème.

- **Que le port vous appartienne ou non.** Sur un hôte virtualisé partagé, un voisin sous attaque peut vous dégrader, et votre propre plafond de protection est partagé. Le [matériel dédié](https://servghost.com/fr/dedicated) avec son propre port supprime les deux effets. Pour un projet qui s'attend à une attention hostile, c'est la raison la plus nette de monter en gamme depuis un [VPS](https://servghost.com/fr/vps) — plus que les cœurs ou la RAM.

- **L'emplacement du réseau.** Un réseau européen bien connecté avec une réelle capacité de transit absorbe une inondation qu'un réseau avec un peering médiocre n'absorbera pas, et la juridiction que vous avez choisie pour des raisons légales a aussi ses propres caractéristiques réseau. Cela vaut la peine de vérifier les deux en choisissant parmi les [localisations](https://servghost.com/fr/locations) disponibles.

Il existe aussi un argument d'échelle qui favorise discrètement la simplicité. Un site statique derrière un cache sur un serveur modeste est extraordinairement difficile à mettre hors service ; le même contenu sur un CMS lourd avec un point de terminaison de recherche non mis en cache peut être cassé par une seule personne déterminée avec un script. Réduire ce qui est dynamique est une mitigation, et elle est gratuite. Si votre projet vit véritablement sous charge soutenue, nos notes sur l'[hébergement à fort trafic](https://servghost.com/fr/use-cases/high-traffic-hosting) couvrent le dimensionnement de la même question.

## Cinq choses à ne pas faire

Les modes d'échec ici sont assez constants pour être listés, et chacun a coûté un week-end à quelqu'un :

- **Ne vous null-routez pas vous-même.** Faire du blackholing sur votre propre adresse termine l'attaque de la façon la plus littérale possible — plus personne ne peut vous atteindre, y compris vos utilisateurs. C'est un outil de dernier recours pour votre hébergeur, pas une action que vous prenez volontairement.

- **Ne considérez pas fail2ban comme une protection DDoS.** C'est un bon outil contre les tentatives de force brute depuis un petit nombre d'adresses. Contre une inondation distribuée, il réagit en quelques minutes à quelque chose qui arrive en quelques secondes, et une règle qui bannit des milliers d'adresses peut coûter plus cher en traitement par le pare-feu que ce que l'attaque vous a coûté.

- **Ne payez pas de rançon.** L'écrasante majorité des e-mails d'extorsion menaçant d'une attaque dévastatrice viennent de gens sans aucune capacité qui envoient des milliers de messages identiques. La petite minorité qui peut mettre sa menace à exécution reviendra, parce que vous avez prouvé que vous payez.

- **Ne ripostez pas.** Au-delà du fait que c'est illégal à peu près partout, les sources sont des tiers compromis. Vous attaqueriez des victimes, et vous le feriez depuis une adresse qui est sans ambiguïté la vôtre.

- **Ne migrez pas dans la panique.** Changer d'hébergeur en pleine attaque signifie que la nouvelle adresse est publique en quelques minutes et que vous n'avez aucune configuration fonctionnelle. Stabilisez d'abord, déménagez délibérément ensuite — et si vous déménagez, notre guide sur la [migration sans interruption de service](https://servghost.com/fr/guides/migrate-website-to-offshore-hosting) existe précisément pour que le déménagement ne soit pas un second incident.

## La version courte

Débarrassé du raisonnement, le modèle de fonctionnement tient en huit lignes :

- **Classifiez d'abord.** Interface saturée signifie volumétrique et relève de votre hébergeur. Interface calme avec des workers épuisés signifie couche 7 et relève de vous.

- **Pour le volumétrique, ouvrez un ticket** avec l'adresse, l'horodatage et vos compteurs — puis arrêtez de toucher au serveur.

- **Mettez en cache agressivement pour les visiteurs anonymes,** servez du contenu périmé sous stress, et fusionnez les miss identiques. C'est le changement au plus fort effet de levier que vous puissiez faire.

- **Limitez le débit à la fois par fréquence de requêtes et par concurrence,** le plus serré sur les points de terminaison qui coûtent le plus, et renvoyez 429.

- **Corrigez votre configuration de véritable IP avant tout le reste,** sinon chaque limite par client derrière un proxy est soit inutile, soit catastrophique.

- **Connaissez vos plafonds** — workers, backlog, descripteurs, connexions à la base de données — et relevez-les délibérément un jour calme.

- **Gardez l'adresse d'origine secrète et protégée par pare-feu,** réservée à vos nœuds frontaux. Cela vaut plus que tous les filtres combinés.

- **Achetez de la bande passante illimitée** pour qu'un trafic que vous n'avez pas demandé ne soit jamais aussi une facture.

Rien de tout cela ne vous rend immunisé, et quiconque vend l'immunité vend autre chose. Ce que cela fait, c'est vous faire sortir de la population qui se fait mettre hors ligne par un adolescent qui s'ennuie, pour entrer dans celle qui exige de véritables ressources et une véritable intention de nuire — ce qui, pour l'écrasante majorité des projets, est indiscernable de la sécurité. Le reste, c'est le même travail sans éclat qui rend un serveur bon en tout : [durci dès le premier jour](https://servghost.com/fr/guides/first-hour-vps-hardening-checklist), [restaurable le pire jour](https://servghost.com/fr/guides/vps-backup-strategy), et hébergé quelque part où votre trafic ne regarde que vous.





FAQ

## DDoS sur un petit serveur — questions fréquentes





### 01
La « protection DDoS incluse » signifie-t-elle que je suis protégé contre tout ?



Non, et l'écart est précis plutôt que flou. La protection incluse est un filtrage au niveau réseau : elle élimine les inondations volumétriques — inondations SYN, amplification UDP, tempêtes de paquets bruts — en amont, avant qu'elles n'atteignent votre port. C'est la catégorie que vous ne pouvez véritablement pas gérer seul, donc c'est la bonne chose à inclure. Elle n'inspecte pas votre application, donc une inondation HTTP de quelques milliers de requêtes par seconde contre un point de terminaison coûteux la traverse sans encombre et met votre site à terre pendant que tous les graphiques réseau ont l'air normaux. La couche 7 est une configuration qui vous appartient : mise en cache, limites de débit et plafonds de connexions.





### 02
Comment distinguer une attaque DDoS d'un pic de trafic ?



Demandez-vous si ce trafic veut quelque chose. De vrais visiteurs, même un afflux soudain provenant d'un lien populaire, demandent des pages qui existent, chargent les ressources de ces pages, arrivent avec des référents plausibles et se répartissent sur de nombreux réseaux selon un schéma naturel. Une attaque martèle généralement un seul chemin, ignore les ressources, envoie des user-agents invraisemblables ou absents, et montre une répartition qui a l'air synthétique. Vérifiez votre journal d'accès pour les requêtes par adresse cliente et par chemin : si un seul point de terminaison domine et que rien d'autre n'est chargé, c'est une attaque. Si ce sont les mêmes pages qu'un humain voudrait consulter qui sont servies et que vos référents sont réels, vous avez un problème de capacité avec une cause heureuse.





### 03
Quelle est la mesure la plus efficace que je puisse prendre pendant une attaque ?



Activez la mise en cache de pages entières pour les visiteurs anonymes, et configurez-la pour servir du contenu périmé quand le backend peine. Une limite de débit rejette du travail ; un cache fait que le travail n'existe pas. Une requête qui coûtait une requête en base de données, un rendu de template et un worker applicatif devient une lecture de fichier, et le même matériel qui s'effondrait à quelques centaines de requêtes dynamiques par seconde en servira des dizaines de milliers en cache. C'est aussi la seule mesure de cette liste qui aide de façon identique contre du trafic réel, donc contrairement à une limite de débit, elle ne peut pas se retourner contre vos propres utilisateurs.





### 04
Pourquoi ma limite de débit nginx a-t-elle cessé de fonctionner après avoir mis un CDN devant ?



Parce que chaque requête arrive désormais depuis l'adresse du CDN plutôt que celle du visiteur, donc une limite par client compte l'internet entier comme un seul client. Selon le seuil, elle ne se déclenchera jamais, ou bannira tout votre trafic d'un coup. Configurez votre source de véritable IP — en nginx, les plages du proxy de confiance plus l'en-tête que le proxy envoie — pour que la limite se base à nouveau sur le vrai visiteur. Restreignez cette confiance aux plages propres du proxy : si vous acceptez un en-tête fourni par le client depuis l'internet ouvert, un attaquant peut forger une nouvelle identité à chaque requête et traverser toutes les limites que vous avez mises en place.





### 05
fail2ban suffit-il à arrêter une attaque DDoS ?



Non. fail2ban lit les journaux à intervalles réguliers et bannit les adresses fautives après un seuil, ce qui convient aux tentatives de force brute provenant d'un petit nombre de sources. Une attaque distribuée arrive en quelques secondes depuis des milliers d'adresses qui n'envoient chacune qu'une poignée de requêtes, donc le seuil n'est jamais atteint et le temps de réaction est de toute façon bien trop lent. Pire, un jeu de règles qui grossit jusqu'à des dizaines de milliers d'entrées peut consommer plus de ressources que l'attaque elle-même. Réservez-le à SSH et aux points de terminaison de connexion, et traitez les inondations avec la mise en cache, la limitation de débit et un filtrage en amont.





### 06
Dois-je utiliser un CDN, ou faire tourner mon propre reverse proxy devant ?



Cela dépend de ce que vous hébergez plutôt que de votre budget. Un CDN commercial apporte une capacité d'absorption que vous ne pouvez pas égaler et une page de vérification à un clic, mais vous héritez de son service abus et il peut voir votre trafic — ce qui, pour des projets offshore ou sensibles au DMCA, est souvent le maillon le plus faible d'un montage par ailleurs soigné. Vos propres nœuds frontaux coûtent plus de travail et ont de vraies limites de capacité, mais il n'y a aucun tiers dans le chemin de la requête et une façade attaquée peut être remplacée par une nouvelle adresse en quelques minutes. Dans les deux cas, l'origine doit être protégée par pare-feu pour n'accepter le trafic web que depuis la façade, sinon tout le montage n'est que décoratif.





### 07
Une attaque va-t-elle me coûter de l'argent en plus de la disponibilité ?



Sur une offre avec quota, oui — un trafic que vous n'avez jamais demandé et que vous ne pouviez pas refuser compte quand même dans votre forfait de transfert, et une inondation soutenue peut produire une facture de dépassement plus élevée qu'une année d'hébergement. C'est la raison pratique pour laquelle la bande passante illimitée compte plus qu'elle n'en a l'air sur une fiche technique : elle convertit un risque financier en un risque purement technique. Il vaut aussi la peine de savoir à l'avance que si une attaque menace une infrastructure partagée, les hébergeurs peuvent null-router temporairement l'adresse ; c'est une pratique standard partout, pas une défaillance propre à votre hébergeur.





### 08
Passer à un hébergeur offshore ou sans KYC rend-il les attaques plus probables ?



Le choix de l'hébergeur en lui-même est neutre ; c'est ce que vous faites tourner qui attire l'attention. Serveurs de jeu, forums, streaming, places de marché, et tout ce qui a un concurrent ou une rancune à assouvir attirent les attaques quelle que soit la juridiction. Ce qui change réellement offshore, c'est votre recours : vous risquez moins d'être lâché parce que vous êtes gênant, ce qui joue dans les deux sens — la protection est technique plutôt que contractuelle. Choisissez une localisation avec une réelle capacité de transit, prenez de la bande passante illimitée, gardez l'adresse d'origine cachée, et traitez la couche 7 comme votre propre responsabilité dès le premier jour plutôt qu'au premier incident.




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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.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://servghost.com/fr/guides/full-disk-encryption-on-a-vps)
[### Masquer l'IP d'origine : CDN, reverse proxy et fuites

Confidentialité


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.


FAQ de 8 questions](https://servghost.com/fr/guides/hiding-your-origin-server-ip)
[### 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://servghost.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://servghost.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://servghost.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://servghost.com/fr/guides/self-host-a-crypto-payment-gateway)




## Hébergez-le là où les inondations sont filtrées



Serveurs KVM offshore dans sept juridictions avec filtrage DDoS L3/L4, bande passante illimitée, accès root complet et stockage NVMe. Sans KYC, paiement en crypto, déployés quelques minutes après confirmation de la transaction.


[Voir les offres VPS](https://servghost.com/fr/vps)
[Serveurs Dédiés](https://servghost.com/fr/dedicated)
[Hébergement offshore](https://servghost.com/fr/offshore-hosting)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servghost.com/#organization",
    "name": "ServGhost",
    "url": "https://servghost.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://servghost.com/ServGhost.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://servghost.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servghost.com/canary",
        "https://servghost.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servghost.com/#website",
    "url": "https://servghost.com",
    "name": "ServGhost",
    "publisher": {
        "@id": "https://servghost.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": "Protection DDoS VPS : où finit l'hébergeur, où commence la couche 7",
    "description": "Votre hébergeur filtre les inondations de paquets ; les inondations de requêtes sont à votre charge. Comment marche le filtrage L3/L4, pourquoi la couche 7 le traverse sans encombre, et ce qui garde un petit serveur offshore en ligne pendant qu'il encaisse.",
    "image": "https://servghost.com/assets/img/guides/surviving-a-ddos-attack-on-your-vps.webp?v=1788769011",
    "author": {
        "@type": "Organization",
        "@id": "https://servghost.com/#editorial",
        "name": "ServGhost Editorial",
        "url": "https://servghost.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://servghost.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servghost.com/#organization"
    },
    "datePublished": "2026-09-07T00:00:00+00:00",
    "dateModified": "2026-09-07T00:00:00+00:00",
    "mainEntityOfPage": "https://servghost.com/guides/surviving-a-ddos-attack-on-your-vps",
    "inLanguage": "fr",
    "keywords": "protection DDoS VPS, comment arrêter une attaque DDoS sur un serveur, mitigation DDoS couche 7, limitation de débit nginx anti-DDoS, hébergement offshore anti-DDoS, filtrage DDoS L3 L4, protection contre les inondations SYN, cacher l'IP d'origine contre le DDoS",
    "articleSection": "Exploitation",
    "wordCount": 5066
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "La « protection DDoS incluse » signifie-t-elle que je suis protégé contre tout ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Non, et l'écart est précis plutôt que flou. La protection incluse est un filtrage au niveau réseau : elle élimine les inondations volumétriques — inondations SYN, amplification UDP, tempêtes de paquets bruts — en amont, avant qu'elles n'atteignent votre port. C'est la catégorie que vous ne pouvez véritablement pas gérer seul, donc c'est la bonne chose à inclure. Elle n'inspecte pas votre application, donc une inondation HTTP de quelques milliers de requêtes par seconde contre un point de terminaison coûteux la traverse sans encombre et met votre site à terre pendant que tous les graphiques réseau ont l'air normaux. La couche 7 est une configuration qui vous appartient : mise en cache, limites de débit et plafonds de connexions."
            }
        },
        {
            "@type": "Question",
            "name": "Comment distinguer une attaque DDoS d'un pic de trafic ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Demandez-vous si ce trafic veut quelque chose. De vrais visiteurs, même un afflux soudain provenant d'un lien populaire, demandent des pages qui existent, chargent les ressources de ces pages, arrivent avec des référents plausibles et se répartissent sur de nombreux réseaux selon un schéma naturel. Une attaque martèle généralement un seul chemin, ignore les ressources, envoie des user-agents invraisemblables ou absents, et montre une répartition qui a l'air synthétique. Vérifiez votre journal d'accès pour les requêtes par adresse cliente et par chemin : si un seul point de terminaison domine et que rien d'autre n'est chargé, c'est une attaque. Si ce sont les mêmes pages qu'un humain voudrait consulter qui sont servies et que vos référents sont réels, vous avez un problème de capacité avec une cause heureuse."
            }
        },
        {
            "@type": "Question",
            "name": "Quelle est la mesure la plus efficace que je puisse prendre pendant une attaque ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Activez la mise en cache de pages entières pour les visiteurs anonymes, et configurez-la pour servir du contenu périmé quand le backend peine. Une limite de débit rejette du travail ; un cache fait que le travail n'existe pas. Une requête qui coûtait une requête en base de données, un rendu de template et un worker applicatif devient une lecture de fichier, et le même matériel qui s'effondrait à quelques centaines de requêtes dynamiques par seconde en servira des dizaines de milliers en cache. C'est aussi la seule mesure de cette liste qui aide de façon identique contre du trafic réel, donc contrairement à une limite de débit, elle ne peut pas se retourner contre vos propres utilisateurs."
            }
        },
        {
            "@type": "Question",
            "name": "Pourquoi ma limite de débit nginx a-t-elle cessé de fonctionner après avoir mis un CDN devant ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Parce que chaque requête arrive désormais depuis l'adresse du CDN plutôt que celle du visiteur, donc une limite par client compte l'internet entier comme un seul client. Selon le seuil, elle ne se déclenchera jamais, ou bannira tout votre trafic d'un coup. Configurez votre source de véritable IP — en nginx, les plages du proxy de confiance plus l'en-tête que le proxy envoie — pour que la limite se base à nouveau sur le vrai visiteur. Restreignez cette confiance aux plages propres du proxy : si vous acceptez un en-tête fourni par le client depuis l'internet ouvert, un attaquant peut forger une nouvelle identité à chaque requête et traverser toutes les limites que vous avez mises en place."
            }
        },
        {
            "@type": "Question",
            "name": "fail2ban suffit-il à arrêter une attaque DDoS ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Non. fail2ban lit les journaux à intervalles réguliers et bannit les adresses fautives après un seuil, ce qui convient aux tentatives de force brute provenant d'un petit nombre de sources. Une attaque distribuée arrive en quelques secondes depuis des milliers d'adresses qui n'envoient chacune qu'une poignée de requêtes, donc le seuil n'est jamais atteint et le temps de réaction est de toute façon bien trop lent. Pire, un jeu de règles qui grossit jusqu'à des dizaines de milliers d'entrées peut consommer plus de ressources que l'attaque elle-même. Réservez-le à SSH et aux points de terminaison de connexion, et traitez les inondations avec la mise en cache, la limitation de débit et un filtrage en amont."
            }
        },
        {
            "@type": "Question",
            "name": "Dois-je utiliser un CDN, ou faire tourner mon propre reverse proxy devant ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Cela dépend de ce que vous hébergez plutôt que de votre budget. Un CDN commercial apporte une capacité d'absorption que vous ne pouvez pas égaler et une page de vérification à un clic, mais vous héritez de son service abus et il peut voir votre trafic — ce qui, pour des projets offshore ou sensibles au DMCA, est souvent le maillon le plus faible d'un montage par ailleurs soigné. Vos propres nœuds frontaux coûtent plus de travail et ont de vraies limites de capacité, mais il n'y a aucun tiers dans le chemin de la requête et une façade attaquée peut être remplacée par une nouvelle adresse en quelques minutes. Dans les deux cas, l'origine doit être protégée par pare-feu pour n'accepter le trafic web que depuis la façade, sinon tout le montage n'est que décoratif."
            }
        },
        {
            "@type": "Question",
            "name": "Une attaque va-t-elle me coûter de l'argent en plus de la disponibilité ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Sur une offre avec quota, oui — un trafic que vous n'avez jamais demandé et que vous ne pouviez pas refuser compte quand même dans votre forfait de transfert, et une inondation soutenue peut produire une facture de dépassement plus élevée qu'une année d'hébergement. C'est la raison pratique pour laquelle la bande passante illimitée compte plus qu'elle n'en a l'air sur une fiche technique : elle convertit un risque financier en un risque purement technique. Il vaut aussi la peine de savoir à l'avance que si une attaque menace une infrastructure partagée, les hébergeurs peuvent null-router temporairement l'adresse ; c'est une pratique standard partout, pas une défaillance propre à votre hébergeur."
            }
        },
        {
            "@type": "Question",
            "name": "Passer à un hébergeur offshore ou sans KYC rend-il les attaques plus probables ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Le choix de l'hébergeur en lui-même est neutre ; c'est ce que vous faites tourner qui attire l'attention. Serveurs de jeu, forums, streaming, places de marché, et tout ce qui a un concurrent ou une rancune à assouvir attirent les attaques quelle que soit la juridiction. Ce qui change réellement offshore, c'est votre recours : vous risquez moins d'être lâché parce que vous êtes gênant, ce qui joue dans les deux sens — la protection est technique plutôt que contractuelle. Choisissez une localisation avec une réelle capacité de transit, prenez de la bande passante illimitée, gardez l'adresse d'origine cachée, et traitez la couche 7 comme votre propre responsabilité dès le premier jour plutôt qu'au premier incident."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Accueil",
            "item": "https://servghost.com/fr/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Guides Hébergement Privé",
            "item": "https://servghost.com/fr/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Protection DDoS VPS : où finit l'hébergeur, où commence la couche 7",
            "item": "https://servghost.com/fr/guides/surviving-a-ddos-attack-on-your-vps"
        }
    ]
}
```