[Home](https://servghost.com/it) /
[Guide di Hosting Privato](https://servghost.com/it/guides) /
Protezione DDoS per VPS: dove finisce l'host e comincia il livello 7






Operaciones


# Sopravvivere a un attacco DDoS sul tuo VPS



Ogni piano di hosting dichiara «protezione DDoS inclusa», e ognuno di essi intende la stessa cosa ristretta: la rete assorbe flood misurati in gigabit. Gli attacchi che davvero mettono giù i piccoli siti si misurano in richieste al secondo, non costano quasi nulla all'attaccante, e arrivano con l'aspetto di traffico del tutto legittimo. Questa guida traccia il confine tra i due, mostra come capire in meno di un minuto in quale dei due ti trovi, e copre ciò che regge davvero dalla parte del confine che spetta a te.


[Leer la guida](#guide-body)
[FAQ](#guide-faq)






## En questa pagina




- [Guida](#guide-body)

- [FAQ](#guide-faq)

- [Guide relacionullas](#guide-related)

- [Paginas consigliate](#guide-cta)






Senza KYC
Solo crypto
Nessun log
DMCA ignorato
Root completo
NVMe SSD





24 min di lettura
Aggiornato Sep 2026

En questa pagina

[01Due attacchi diversi che condividono un nome](#due-attacchi-diversi-che-condividono-un-nome)
[02Cosa compra davvero la «protezione DDoS inclusa»](#cosa-compra-davvero-la-protezione-ddos-inclusa)
[03Prima di tutto: capire se è davvero un attacco](#prima-di-tutto-capire-se-è-davvero-un-attacco)
[04Leggere l'attacco direttamente dal server](#leggere-lattacco-direttamente-dal-server)
[05I primi dieci minuti](#i-primi-dieci-minuti)
[06Rate limit che tengono, e l'errore che fanno tutti](#rate-limit-che-tengono-e-lerrore-che-fanno-tutti)
[07Il caching è la mitigazione più economica che distribuirai mai](#il-caching-è-la-mitigazione-più-economica-che-distribuirai-m)
[08I tetti che decidono se il sito va giù](#i-tetti-che-decidono-se-il-sito-va-giù)
[09Mettere qualcosa davanti all'origine](#mettere-qualcosa-davanti-allorigine)
[10Un'origine nascosta vale più di qualunque filtro](#unorigine-nascosta-vale-più-di-qualunque-filtro)
[11Scegliere hardware e location perché gli attacchi restino noiosi](#scegliere-hardware-e-location-perché-gli-attacchi-restino-no)
[12Cinque cose da non fare](#cinque-cose-da-non-fare)
[13La versione breve](#la-versione-breve)
[FAQDomande frequenti](#guide-faq)
[→Paginas consigliate](#guide-cta)







Ci sono due momenti in cui si scopre come funziona davvero la mitigazione DDoS. Il primo è tranquillo, al momento dell'acquisto, leggendo un elenco di funzionalità che dice «protezione DDoS inclusa» e dando per scontato, senza pensarci troppo, che quella frase copra tutto. Il secondo è alle tre di notte, quando il sito è giù, i grafici sembrano sbagliati in un modo che non ha senso, e quella protezione inclusa non sta facendo — correttamente, e per progettazione — assolutamente nulla.

Entrambi i momenti riguardano lo stesso prodotto e la stessa verità: un provider di hosting filtra gli attacchi che arrivano come puro volume, perché possiede la pipe lungo cui viaggiano quei pacchetti e tu no. Non può filtrare gli attacchi che arrivano come richieste dall'aspetto ordinario, perché dal punto di vista della rete sono, appunto, richieste dall'aspetto ordinario. Quella linea di confine — tra il flood che il tuo host assorbe e il flood a cui devi sopravvivere da solo — è l'intero argomento di questa guida. Tutto ciò che segue serve a capire da che parte di quella linea ti trovi, e cosa fare in ciascun caso.

## Due attacchi diversi che condividono un nome

«DDoS» è una sola parola che copre due problemi che non hanno quasi nulla in comune, a parte l'esito. Vengono fermati in luoghi diversi, da persone diverse, con strumenti diversi, e confonderli è il motivo per cui tanto sforzo di mitigazione finisce nel livello sbagliato.

| | Volumetrico — livelli 3 e 4 | Applicativo — livello 7 |
| --- | --- | --- |
| Cosa arriva | SYN flood, amplificazione UDP tramite reflector DNS, NTP o memcached aperti, ACK flood, semplici pacchetti spazzatura | Richieste HTTP ordinarie: flood GET, flood POST, Slowloris, query string pensate per invalidare la cache |
| Misurato in | Gigabit e milioni di pacchetti al secondo | Richieste al secondo — spesso solo qualche migliaio |
| Banda necessaria per farti danno | Enorme. È una gara di capacità | Quasi nessuna. Un singolo laptop può farcela, se l'endpoint è abbastanza costoso |
| Dove va fermato | **A monte, dal tuo provider.** Quando i pacchetti raggiungono la tua porta, il danno è già fatto | **Sul tuo server, da te**, oppure su un proxy che controlli, posto davanti ad esso |
| Che aspetto ha sulla macchina | Interfaccia satura, contatori di pacchetti assurdi, la CPU può essere inattiva | Banda modesta, ma ogni worker occupato, load in salita, coda del database in crescita |
| Chi lo risolve | Il filtraggio del tuo host, automaticamente, di solito in pochi secondi | La tua configurazione — rate limit, caching, tetti di connessione |

Rileggi le ultime due righe, perché contengono il punto pratico. Se l'interfaccia è satura, niente di ciò che digiti nel server aiuterà: i pacchetti hanno già consumato la porta, e l'unico soggetto in grado di scartarli è chi possiede il router a monte. Se l'interfaccia è tranquilla ma il sito è comunque giù, vale l'opposto — il tuo host non vede nulla di sbagliato perché, al suo livello, nulla *è* sbagliato, e la correzione è interamente tua.

I flood volumetrici vengono filtrati a monte, dove sta la capacità. Ciò che sopravvive a quel filtro è traffico dall'aspetto ordinario — e fermarlo è compito tuo, non del tuo host.

## Cosa compra davvero la «protezione DDoS inclusa»

La protezione a livello di rete è reale, preziosa, e quasi sempre fraintesa. Quando un provider pubblicizza il filtraggio L3/L4, intende dire che la sua rete monitora il traffico diretto al tuo indirizzo, e quando viene rilevato un flood il traffico viene deviato attraverso hardware di filtraggio che scarta la parte malevola e inoltra ciò che sembra legittimo. Succede senza un ticket di assistenza e di solito senza che tu noti altro che un breve sussulto.

Quell'unica frase fa un gran lavoro, quindi vale la pena scomporre cosa include e cosa no:

- **Copre gli attacchi a cui non potresti sopravvivere da solo.** Un flood di amplificazione da 200 Gbps contro un server con una porta da 1 Gbps non è un problema di configurazione. È aritmetica. Il filtraggio a monte è l'unica risposta che esiste.

- **È stateless rispetto alla tua applicazione.** Il filtro non sa quali dei tuoi URL sono costosi, quali visitatori sono autenticati, o che una richiesta al tuo endpoint di ricerca costa quattrocento volte una richiesta al tuo logo.

- **Reagisce a una soglia, non alla tua sofferenza.** Il rilevamento scatta sul volume di traffico. Un attacco che non supera mai quella soglia non lo attiva mai, non importa quanto a fondo abbia messo giù il tuo sito.

- **Nei casi estremi, può null-routare brevemente il tuo indirizzo.** Ogni rete ha un tetto. Se un attacco minaccia l'infrastruttura condivisa, l'indirizzo può restare irraggiungibile per un periodo — è prassi standard e universale, ed è meglio saperlo prima che accada, non mentre accade.

**La versione in una riga:** il tuo host protegge la sua rete, e tu ne trai beneficio. Non protegge la tua applicazione, e non ha modo di farlo. Il livello 7 non è un upsell che ti è stato negato — è un livello in cui il tuo provider non può vedere senza terminare il tuo TLS, il che per chiunque faccia hosting offshore è uno scambio con costi seri tutti suoi.

## Prima di tutto: capire se è davvero un attacco

Una quota impressionante degli incidenti sospettati di essere DDoS è in realtà qualcos'altro travestito da tale, e i rimedi non sono intercambiabili. Prima di applicare un rate limit a qualsiasi cosa, dedica due minuti a escludere gli impostori — una diagnosi sbagliata qui ti costa un'ora e, a volte, i tuoi utenti veri.

- **Sei diventato popolare.** Un link su un grande aggregatore produce una forma di traffico che sembra esattamente un flood di livello 7, se non fosse che i referrer sono reali e le richieste riguardano pagine che una persona vorrebbe vedere. È un problema di capacità con una causa felice; applicargli un rate limit è autolesionismo.

- **Un crawler ha perso le buone maniere.** Scraper aggressivi e bot di addestramento per l'IA possono superare banalmente un piccolo server. Lo user-agent di solito si autodenuncia, e il rimedio è robots.txt più un limite mirato, non uno generale.

- **Hai rotto qualcosa tu stesso.** Un deployment che ha disabilitato la cache, un cron job impazzito, un database che ha perso un indice — tutti si presentano come «carico improvviso, senza causa evidente». Se la tempistica coincide con una modifica che hai fatto, credi alla modifica.

- **Il flood sei tu stesso, con il tuo monitoraggio.** Raro, imbarazzante, e molto più comune di quanto chiunque ammetta. Un loop di health-check che ritenta senza backoff può generare un tasso di richieste genuinamente impressionante.

La domanda che fa la differenza è semplice: *il traffico vuole qualcosa?* Il carico reale — anche quando ha un aspetto ostile — ha una forma. Colpisce pagine che esistono, segue i link, carica gli asset, e proviene da una distribuzione plausibile di reti diverse. Un attacco di solito non si prende questo disturbo.

## Leggere l'attacco direttamente dal server

Non serve una dashboard per classificare cosa sta succedendo. Quattro comandi, eseguiti in ordine, ti dicono in meno di un minuto contro quale livello stai combattendo — e saperlo determina tutto ciò che fai dopo.

**La pipe è piena?** Osserva i contatori dell'interfaccia. Se il throughput è inchiodato vicino al tetto della porta, sei dentro un attacco volumetrico e il tuo compito è aprire un ticket, non modificare una configurazione:

- vnstat -tr 10 — throughput medio negli ultimi dieci secondi, la lettura onesta più rapida sulla saturazione.

- cat /proc/net/dev due volte, a un secondo di distanza — delta di pacchetti e byte per interfaccia, senza bisogno di alcun tool.

**È un SYN flood?** Le connessioni semi-aperte si accumulano in SYN-RECV. Una manciata è normale; migliaia no:

- ss -s — la riga di riepilogo, il conteggio delle connessioni per stato a colpo d'occhio.

- ss -tn state syn-recv | wc -l — il numero specifico che conta davvero.

**È livello 7?** Se la banda è nella norma ma tutto è lento, conta le richieste per client nel tuo access log. Un singolo indirizzo con decine di migliaia di richieste è un dilettante; centomila indirizzi con tre richieste ciascuno sono la cosa vera:

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

- Sostituisci $1 con $7 per classificare invece i percorsi richiesti. Se un singolo endpoint costoso domina, hai trovato il bersaglio e metà del rimedio.

**Cosa si è davvero esaurito?** Il load average da solo ti dice poco. Cerca il tetto specifico che hai raggiunto: i processi di PHP-FPM tutti occupati, le connessioni al database al loro limite, i descrittori di file esauriti, o i worker bloccati nello stato D in attesa del disco. È quel tetto — non il traffico — ad aver messo giù il sito, e alzarlo è spesso più veloce che filtrare qualsiasi cosa.

**Tienilo a mente mentre osservi:** se gestisci un servizio orientato alla privacy, un attacco è esattamente il momento in cui sei più tentato di alzare il livello di logging e lasciarlo alto. Alzalo se devi, poi riabbassalo e ruota i file in modo aggressivo subito dopo. Un incidente che lascia sul disco un mese di log dei visitatori a piena risoluzione ha scambiato un problema con uno peggiore e più duraturo. La nostra [guida al server OpSec](https://servghost.com/it/guides/server-opsec-staying-anonymous) tratta la disciplina a cui questo appartiene.

## I primi dieci minuti

Sotto pressione, si tende ad afferrare la leva più grande disponibile, e la leva più grande di solito è quella sbagliata. Questo è l'ordine che limita il danno, all'incirca dal più rapido e sicuro in poi:

- **Classifica prima di agire.** Interfaccia satura significa volumetrico; interfaccia tranquilla con worker occupati significa livello 7. Trenta secondi spesi qui ti risparmiano un'ora passata a correggere il livello sbagliato.

- **Se è volumetrico, apri subito un ticket** e includi l'indirizzo di destinazione, l'orario di inizio e i tuoi contatori di interfaccia. Poi smetti di digitare nel server — non puoi risolverlo dall'interno.

- **Se è livello 7, occupati prima della cache.** Attivare un caching aggressivo a pagina intera per i visitatori anonimi è il modo singolarmente più rapido per trasformare un'interruzione in una scrollata di spalle, ed è anche l'unica misura che aiuta allo stesso modo contro il traffico reale.

- **Poi applica un rate limit** — prima l'endpoint preso di mira, tutto il resto dopo. Parti prudente. Un limite che mette fuori gioco i tuoi stessi utenti è una continuazione autoinflitta dell'attacco.

- **Blocca solo ciò che è inequivocabile.** Una dozzina di indirizzi con centomila richieste ciascuno, uno user-agent palesemente falso, un paese in cui non hai utenti. Resisti alla tentazione di scrivere regole elaborate mentre sei sotto attacco; il mese prossimo non te le ricorderai.

- **Se necessario, scarica il carico deliberatamente.** Servire una pagina statica «in manutenzione» ai visitatori non autenticati mantiene viva la macchina, mantiene attiva la tua API, e ti compra tempo per pensare. Decidere tu cosa sacrificare è meglio che farselo decidere da altri.

- **Annota cosa hai fatto.** Ogni regola temporanea che aggiungi è una mina vagante per il te del futuro. Le regole che hanno aiutato diventano permanenti; il resto salta fuori domani.

## Rate limit che tengono, e l'errore che fanno tutti

Il rate limiting è lo strumento principale per il livello 7, e nginx lo fa bene con due direttive che risolvono due problemi genuinamente diversi. limit_req limita il *tasso* di richieste — quanto spesso un client può fare una richiesta. limit_conn limita la *concorrenza* — quante connessioni un client può tenere aperte contemporaneamente. I flood hanno bisogno del primo; gli attacchi Slowloris, che tengono aperte migliaia di connessioni quasi inattive per esaurire il tuo pool di worker, hanno bisogno del secondo. Distribuiscine solo uno e sei coperto solo per metà del problema.

Tre dettagli separano un limite che funziona da uno puramente decorativo:

- **Usa un burst, e usa nodelay.** I browser reali sono a scoppi — una singola visualizzazione di pagina scatena una dozzina di richieste di asset quasi simultanee. Un limite senza margine strozza i visitatori genuini, mentre un attaccante che si tiene appena sotto la soglia passa liscio.

- **Limita separatamente gli endpoint costosi.** La tua pagina di ricerca, il form di login, il reset della password e qualunque endpoint che scrive sul database meritano un budget molto più stretto rispetto ai tuoi asset statici. Gli attaccanti li trovano senza nemmeno provarci, perché sono quelli che fanno male.

- **Restituisci 429, non 503.** Il codice di stato è un segnale, per i client ben educati e per i motori di ricerca, che si tratta di throttling e non di un guasto — e questo evita che un brutto pomeriggio si trasformi anche in un problema di posizionamento.

**L'errore che vanifica tutto in silenzio:** se qualcosa sta davanti al tuo server — una CDN, un load balancer, un tuo reverse proxy — allora ogni richiesta arriva dall'indirizzo *suo*, non da quello del visitatore. Un rate limit per client finisce così per contare l'intero internet come un unico client, e o non scatterà mai, oppure bannerà tutto il tuo pubblico in un colpo solo. Devi configurare la tua sorgente IP reale (in nginx, set_real_ip_from per i range del proxy più real_ip_header per l'header che invia) *prima* che i limiti abbiano un senso qualsiasi. Restringila anche ai soli range del proxy: fidarsi di un header fornito dal client, proveniente dall'internet aperto, permette a un attaccante di forgiare una nuova identità a ogni richiesta e attraversare dritto ogni limite che possiedi.

## Il caching è la mitigazione più economica che distribuirai mai

Un rate limit rifiuta il lavoro. Una cache fa sì che il lavoro non esista. Per tutto ciò che un visitatore anonimo vede, il caching a pagina intera cambia l'economia dell'intero attacco: una richiesta che sarebbe costata un round-trip al database, il rendering di un template e un worker PHP diventa una lettura da file misurata in microsecondi. Lo stesso server che crollava a quattrocento richieste dinamiche al secondo servirà decine di migliaia di richieste dalla cache senza nemmeno accorgersene.

Le cose che contano quando lo attivi con l'acqua alla gola:

- **Metti in cache solo per i visitatori anonimi.** Bypassa in presenza di un cookie di sessione. Servire la pagina di un utente autenticato a un altro è un incidente molto peggiore dell'interruzione che stavi cercando di risolvere.

- **Servi contenuto scaduto di proposito.** La direttiva proxy_cache_use_stale di nginx, insieme a updating error timeout, fa sì che quando il tuo backend è in difficoltà i visitatori ricevano una pagina leggermente vecchia invece di un errore. Durante un attacco questa è la differenza tra un sito che sembra a posto e uno che sembra morto.

- **Accorpa i miss duplicati.** proxy_cache_lock garantisce che mille richieste simultanee per la stessa pagina non in cache producano una sola richiesta al backend, non mille. Senza di esso, un attacco che invalida la cache la attraversa dritto e si abbatte sul tuo database a piena forza.

- **Neutralizza le query string che invalidano la cache.** Il trucco standard è aggiungere ? e un valore casuale, così ogni richiesta diventa una chiave unica e va sempre in miss. Normalizza la tua chiave di cache per ignorare i parametri di query che la tua applicazione non usa realmente.

C'è qui un'asimmetria piacevole che vale la pena interiorizzare: ogni ora che dedichi al caching rende il sito anche più veloce nel suo giorno migliore, più economico da gestire, e più capace di sopravvivere al successo. Quasi nessun'altra linea di difesa paga un dividendo quando non c'è nulla che non va.

## I tetti che decidono se il sito va giù

La maggior parte dei server non muore perché ha esaurito la CPU. Muore perché urta contro un tetto invisibile che nessuno ha impostato deliberatamente — un default di dieci anni fa che aveva senso su hardware che ormai non usa più nessuno. Sotto attacco, sono queste le cose che in realtà si rompono per prime:

- **I worker dell'applicazione.** Il pm.max_children di PHP-FPM, il numero di worker Python, la dimensione del tuo cluster Node. È questo il vero limite di concorrenza del tuo sito. Quando sono tutti occupati, ogni visitatore in più va in coda, e il sito è giù indipendentemente da quanto la CPU sembri inattiva. Alzalo solo per quanto lo consente la memoria — andare in swap è peggio che mettere in coda.

- **La coda di accettazione.** net.core.somaxconn e il tuo backlog di ascolto decidono quante connessioni possono aspettare di essere accettate. Un backlog piccolo trasforma un picco sopravvivibile in connessioni rifiutate.

- **I SYN cookie.** net.ipv4.tcp_syncookies permette al kernel di rispondere a un SYN flood senza allocare stato per connessioni che non si completeranno mai. I kernel moderni lo attivano di default; verificalo invece di darlo per scontato, perché non costa nulla e ti salva dal flood più comune che esista.

- **I descrittori di file.** Ogni connessione è un descrittore. Il limite predefinito di nofile è spesso più basso del numero di connessioni che stai cercando di servire, e la modalità di guasto — gli accept che falliscono mentre tutto sembra sano — è genuinamente sconcertante alle tre di notte.

- **Le connessioni al database.** Alzare il numero di worker senza alzare il pool di connessioni sposta semplicemente la coda in un punto più difficile da vedere. Questi due numeri vanno regolati insieme.

Regola questi valori in un giorno tranquillo, non durante un incidente. Il punto di conoscerli è che quando il sito va giù, puoi dare un nome al tetto che ha urtato invece di indovinare — e un tetto con un nome è un tetto che puoi sistemare.

## Mettere qualcosa davanti all'origine

Tutto quanto sopra avviene sul server. Il passo successivo è decidere se il server debba essere davvero la cosa che riceve il traffico. Ci sono tre opzioni oneste, e la risposta giusta dipende molto più da cosa ospiti che da quanto puoi permetterti.

| Approccio | Cosa ti dà | Cosa ti costa |
| --- | --- | --- |
| Origine esposta direttamente, blindata | Semplicità, nessuna terza parte, nessuna terminazione TLS che non controlli | Il tuo indirizzo è pubblico e permanente. Il livello 7 è interamente affar tuo |
| CDN commerciale o servizio di filtraggio | Capacità di assorbimento enorme, una pagina di verifica a un clic, caching globale | Uno sportello reclami con una propria opinione sui tuoi contenuti, e un'azienda che può vedere il tuo traffico. Per progetti offshore o sensibili a reclami DMCA, questo può essere l'anello più debole di un assetto altrimenti curato |
| Un tuo front node — un piccolo VPS che fa girare nginx, in proxy verso un'origine blindata | Controllo completo, nessuna terza parte nel percorso della richiesta, un indirizzo che puoi bruciare e sostituire, e un indirizzo reale che resta nascosto | I suoi propri limiti di capacità, e una macchina in più da gestire. Due o tre front in reti diverse rendono il tutto sensibilmente più difficile da abbattere |

Il front node self-hosted merita più attenzione di quanta ne riceva di solito, in particolare per chi ha scelto l'hosting offshore per ragioni verso cui una grande CDN potrebbe non essere comprensiva. Lo schema non ha nulla di affascinante: nodi proxy economici davanti, origine blindata per accettare connessioni solo da quei nodi, DNS che punta ai front. Se un front viene attaccato, lo sostituisci con un nuovo indirizzo in pochi minuti e l'origine non se ne accorge nemmeno. La versione completa di questa architettura — inclusi i sei modi in cui un indirizzo di origine trapela comunque — è l'argomento della nostra guida su [come nascondere l'IP del server di origine](https://servghost.com/it/guides/hiding-your-origin-server-ip).

## Un'origine nascosta vale più di qualunque filtro

Vale la pena dirlo senza mezzi termini, perché ribalta la solita priorità: la mitigazione DDoS più economica a tua disposizione è un indirizzo che l'attaccante non possiede. Il filtraggio è quello che fai quando questo è già fallito.

La cosa conta più di quanto sembri, perché gli indirizzi di origine trapelano di continuo e in silenzio. I record DNS storici da prima che tu mettessi un proxy davanti sopravvivono al cambiamento per anni. La posta inviata direttamente dall'applicazione porta l'indirizzo nelle sue intestazioni. Un certificato TLS emesso sull'indirizzo grezzo viene pubblicato in modo permanente nei log di certificate transparency. Una pagina di errore, un redirect, o un sottodominio poco noto che non è mai stato messo dietro proxy: tutti quanti lo rivelano. Se hai messo una CDN davanti a un server che prima era esposto, dai per scontato che il vecchio indirizzo sia noto finché non lo cambi.

**Il corollario è una regola di firewall, ed è la singola riga più preziosa di questa guida:** una volta che qualcosa sta davanti, l'origine dovrebbe rifiutare le connessioni sulle porte 80 e 443 da tutto tranne che dagli indirizzi di quel front. Senza di essa, il proxy è solo un suggerimento — chiunque scopra l'indirizzo reale gli gira semplicemente attorno e ti attacca direttamente, e tutto ciò che hai configurato sul front diventa decorativo.

## Scegliere hardware e location perché gli attacchi restino noiosi

Una parte di tutto questo si decide prima ancora che avvenga un attacco, nel momento in cui scegli un piano. Tre proprietà contano molto più di quanto suggerisca la scheda tecnica:

- **Banda illimitata.** Su un piano a consumo, un attacco non è solo un'interruzione — è anche una fattura. Il traffico che non hai mai richiesto e non hai potuto rifiutare conta comunque contro una soglia. Il trasferimento illimitato converte un rischio finanziario in uno puramente tecnico, che è una classe di problema molto migliore.

- **Se la porta è tutta tua.** Su un host virtualizzato condiviso, un vicino sotto attacco può degradare anche te, e il tuo stesso tetto di protezione è condiviso. L'[hardware dedicato](https://servghost.com/it/dedicated) con una porta propria elimina entrambi gli effetti. Per un progetto che si aspetta attenzioni ostili, questa è la ragione più chiara per passare da un [VPS](https://servghost.com/it/vps) a qualcosa di superiore — più dei core o della RAM.

- **Dove si trova la rete.** Una rete europea ben connessa, con vera capacità di transito, assorbe un flood che una rete con scarso peering non reggerebbe, e la giurisdizione che hai scelto per ragioni legali ha anch'essa delle caratteristiche di rete. Vale la pena controllare entrambe le cose quando scegli tra le [location](https://servghost.com/it/locations) disponibili.

C'è anche un argomento di scala che favorisce silenziosamente la semplicità. Un sito statico dietro una cache su un server modesto è straordinariamente difficile da abbattere; lo stesso contenuto su un CMS pesante con un endpoint di ricerca non in cache può essere spezzato da una sola persona determinata con uno script. Ridurre ciò che è dinamico è una mitigazione, ed è gratuita. Se il tuo progetto vive genuinamente sotto un carico sostenuto, le nostre note sull'[hosting per traffico elevato](https://servghost.com/it/use-cases/high-traffic-hosting) coprono il lato dimensionamento della stessa questione.

## Cinque cose da non fare

Le modalità di fallimento qui sono abbastanza ricorrenti da poterle elencare, e ognuna è costata a qualcuno un intero weekend:

- **Non null-routare te stesso.** Il blackholing del tuo stesso indirizzo pone fine all'attacco nel modo più letterale possibile — nessuno può raggiungerti, utenti compresi. È uno strumento a cui il tuo provider ricorre come ultima risorsa, non un'azione che compi volontariamente.

- **Non trattare fail2ban come protezione DDoS.** È un ottimo strumento contro tentativi di forza bruta da poche fonti. Contro un flood distribuito reagisce in minuti a qualcosa che arriva in secondi, e una regola che banna migliaia di indirizzi può costare in elaborazione del firewall più di quanto ti sia costato l'attacco stesso.

- **Non pagare un riscatto.** La stragrande maggioranza delle email di estorsione che minacciano un attacco devastante arriva da persone senza alcuna reale capacità, che inviano migliaia di messaggi identici. La piccola minoranza che è davvero in grado di agire tornerà, perché hai dimostrato di pagare.

- **Non reagire con una ritorsione.** Oltre a essere illegale praticamente ovunque, le fonti sono terze parti compromesse. Staresti attaccando delle vittime, per giunta da un indirizzo che è inequivocabilmente tuo.

- **Non migrare nel panico.** Cambiare host a metà attacco significa che il nuovo indirizzo diventa pubblico nel giro di minuti e che non hai una configurazione funzionante. Prima stabilizza, poi trasferisciti con calma — e se decidi di migrare, la nostra guida su come [migrare senza downtime](https://servghost.com/it/guides/migrate-website-to-offshore-hosting) esiste proprio perché il trasloco non diventi un secondo incidente.

## La versione breve

Spogliato del ragionamento, il modello operativo sta in otto righe:

- **Classifica per prima cosa.** Interfaccia satura significa volumetrico, ed è compito del tuo host. Interfaccia tranquilla con worker esauriti significa livello 7, ed è compito tuo.

- **Per il volumetrico, apri un ticket** con l'indirizzo, l'orario e i tuoi contatori — poi smetti di toccare il server.

- **Metti in cache in modo aggressivo per i visitatori anonimi,** servi contenuto scaduto sotto stress, e accorpa i miss duplicati. È la modifica con la leva più alta che puoi fare.

- **Applica un rate limit sia per tasso di richieste sia per concorrenza,** il più stretto possibile sugli endpoint che costano di più, e restituisci 429.

- **Sistema la tua configurazione del real IP prima di ogni altra cosa,** altrimenti ogni limite per client dietro un proxy è o inutile o catastrofico.

- **Conosci i tuoi tetti** — worker, backlog, descrittori, connessioni al database — e alzali deliberatamente in un giorno tranquillo.

- **Tieni l'indirizzo di origine segreto e blindato** verso i tuoi front node. Questo vale più di tutti i filtri messi insieme.

- **Compra banda illimitata,** così il traffico che non hai chiesto non diventa mai anche una fattura.

Niente di tutto questo ti rende immune, e chiunque venda l'immunità sta vendendo qualcos'altro. Quello che fa è spostarti fuori dalla popolazione che finisce offline per colpa di un adolescente annoiato, e dentro quella che richiede risorse genuine e intenzioni genuine per essere disturbata — il che, per la stragrande maggioranza dei progetti, è indistinguibile dall'essere al sicuro. Il resto è lo stesso lavoro poco appariscente che rende un server valido in tutto il resto: [messo in sicurezza fin dal primo giorno](https://servghost.com/it/guides/first-hour-vps-hardening-checklist), [ripristinabile in quello peggiore](https://servghost.com/it/guides/vps-backup-strategy), e ospitato in un posto che tratta il tuo traffico come affari tuoi.





FAQ

## DDoS su un piccolo server — domande frequenti





### 01
La «protezione DDoS inclusa» significa che sono al sicuro da tutto?



No, e il divario è preciso, non vago. La protezione inclusa è filtraggio a livello di rete: scarta i flood volumetrici — SYN flood, amplificazione UDP, tempeste di pacchetti grezzi — a monte, prima che raggiungano la tua porta. È esattamente la categoria che non potresti gestire da solo, quindi è giusto che sia inclusa. Non ispeziona la tua applicazione, quindi un flood HTTP di qualche migliaio di richieste al secondo contro un endpoint costoso lo attraversa indenne e mette giù il tuo sito mentre ogni grafico di rete sembra normale. Il livello 7 è configurazione che possiedi tu: caching, rate limit e tetti di connessione.





### 02
Come distinguo un attacco DDoS da un normale picco di traffico?



Chiediti se quel traffico vuole qualcosa. I visitatori reali, anche un flusso improvviso di essi generato da un link popolare, richiedono pagine che esistono, caricano gli asset di quelle pagine, arrivano con referrer plausibili e si distribuiscono su molte reti diverse in modo naturale. Un attacco di solito martella un solo percorso, ignora gli asset, invia user-agent implausibili o assenti, e mostra una distribuzione che sembra artificiale. Controlla il tuo access log per le richieste per indirizzo client e per percorso: se un solo endpoint domina e nient'altro viene caricato, è un attacco. Se vengono servite le stesse pagine che vorrebbe una persona e i tuoi referrer sono reali, hai un problema di capacità con una causa felice.





### 03
Qual è la singola cosa più efficace che posso fare mentre sono sotto attacco?



Attiva il caching a pagina intera per i visitatori anonimi, e configuralo per servire contenuto scaduto quando il backend è in difficoltà. Un rate limit rifiuta il lavoro; una cache fa sì che il lavoro non esista. Una richiesta che costava una query al database, il rendering di un template e un worker applicativo diventa una lettura da file, e lo stesso hardware che crollava a poche centinaia di richieste dinamiche al secondo servirà decine di migliaia di richieste dalla cache. È anche l'unica misura dell'elenco che aiuta allo stesso identico modo contro il traffico reale, quindi a differenza di un rate limit non può ritorcersi contro i tuoi stessi utenti.





### 04
Perché il mio rate limit su nginx ha smesso di funzionare dopo aver messo una CDN davanti?



Perché ora ogni richiesta arriva dall'indirizzo della CDN e non da quello del visitatore, quindi un limite per client sta contando l'intero internet come un unico client. A seconda della soglia, o non scatterà mai, oppure bannerà tutto il tuo traffico in un colpo solo. Configura la tua sorgente IP reale — in nginx, i range di proxy fidati più l'header che il proxy invia — così il limite torna a basarsi sul visitatore reale. Restringi quella fiducia ai soli range del proxy: se accetti un header fornito dal client proveniente dall'internet aperto, un attaccante può forgiare una nuova identità a ogni richiesta e attraversare ogni limite che hai messo.





### 05
fail2ban basta da solo a fermare un attacco DDoS?



No. fail2ban legge i log a intervalli e banna gli indirizzi colpevoli dopo una soglia, il che va bene per tentativi di forza bruta da un numero ridotto di fonti. Un attacco distribuito arriva in pochi secondi da migliaia di indirizzi che inviano ciascuno solo una manciata di richieste, quindi la soglia non viene mai raggiunta e comunque il tempo di reazione è di gran lunga troppo lento. Peggio ancora, un insieme di regole che cresce fino a decine di migliaia di voci può consumare più risorse dell'attacco stesso. Tienilo per SSH e per gli endpoint di login, e gestisci i flood con caching, rate limiting e un filtro a monte.





### 06
Dovrei usare una CDN, oppure far girare un mio reverse proxy davanti?



Dipende da cosa ospiti, più che dal tuo budget. Una CDN commerciale porta una capacità di assorbimento che non puoi eguagliare e una pagina di verifica a un clic di distanza, ma erediti il suo sportello reclami e può vedere il tuo traffico — il che per progetti offshore o sensibili a reclami DMCA è spesso l'anello più debole di un assetto altrimenti curato. I tuoi front node costano più lavoro e hanno limiti di capacità reali, ma non c'è nessuna terza parte nel percorso della richiesta, e un front che viene attaccato può essere sostituito con un nuovo indirizzo in pochi minuti. In entrambi i casi, l'origine deve essere blindata per accettare traffico web solo dal front, altrimenti l'intero assetto è decorativo.





### 07
Un attacco mi costerà anche denaro, oltre all'uptime?



Su un piano a consumo, sì — il traffico che non hai mai richiesto e non hai potuto rifiutare conta comunque contro la tua soglia di trasferimento, e un flood prolungato può produrre una fattura per l'eccedenza più alta di un anno di hosting. Questa è la ragione pratica per cui la banda illimitata conta più di quanto sembri su una scheda tecnica: converte un rischio finanziario in uno puramente tecnico. Vale anche la pena sapere in anticipo che se un attacco minaccia l'infrastruttura condivisa, i provider possono null-routare temporaneamente l'indirizzo; è prassi standard ovunque, non un difetto del tuo host in particolare.





### 08
Passare a un host offshore o no-KYC rende gli attacchi più probabili?



La scelta dell'hosting in sé è neutra; è ciò che fai girare ad attirare l'attenzione. Server di gioco, forum, streaming, marketplace e qualunque cosa abbia un concorrente o un nemico attira attacchi a prescindere dalla giurisdizione. Ciò che cambia davvero offshore è il tuo margine di manovra: è meno probabile che tu venga scaricato perché sei scomodo, il che vale in entrambi i sensi — la protezione è tecnica, non contrattuale. Scegli una location con vera capacità di transito, prendi banda illimitata, tieni nascosto l'indirizzo di origine, e tratta il livello 7 come una tua responsabilità fin dal primo giorno, non dal primo incidente.




Guide relacionullas

## Seguir leyendo


[### Come Scegliere una Giurisdizione di Hosting Offshore in 2026

Compra


Un quadro decisionale pratico per scegliere una giurisdizione offshore: leggi sulla conservazione dei dati, esposizione ai trattati MLAT, posizione sul DMCA, velocità dei tribunali e applicazione reale della legge — paese per paese.


FAQ di 6 domande](https://servghost.com/it/guides/choosing-an-offshore-jurisdiction)
[### VPS vs Server Dedicato per Workload Critici per la Privacy

Compra


Quando un VPS va bene, quando la tenancy condivisa è un rischio e quando il bare metal è l'unica risposta onesta. Isolamento hardware, rischio hypervisor e costo rispetto al modello di minaccia.


FAQ di 6 domande](https://servghost.com/it/guides/vps-vs-dedicated-for-privacy)
[### VPN Autogestionulla in un VPS Senza KYC: WireGuard vs OpenVPN

Operaciones


Perché una VPN self-hosted batte i provider commerciali, e come si confrontano davvero WireGuard e OpenVPN su privacy, prestazioni e rischio operativo nel 2026.


FAQ di 6 domande](https://servghost.com/it/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 per inferenza IA (e dove rientra la RTX 5090)

Compra


Guida all'acquisto: quale GPU NVIDIA scegliere per carichi di lavoro LLM, immagine, video, voce e fine-tuning self-hosted nel 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs doppio H100 — VRAM, throughput, $/token, quando vince ciascuna.


FAQ di 6 domande](https://servghost.com/it/guides/rtx-4090-vs-h100-for-ai-inference)
[### RDP Windows Offshore per Trading Forex con MT4 / MT5 / cTrader

Operaciones


Guida completa: perché scegliere un RDP Windows per il trading forex, come scegliere una giurisdizione offshore a bassa latenza, la configurazione di MT4 / MT5 / cTrader / Expert Advisor, la latenza verso i server dei broker e il percorso di checkout senza KYC.


FAQ di 6 domande](https://servghost.com/it/guides/offshore-windows-rdp-for-forex-trading)
[### Hosting con DMCA Ignorato: Cosa Significa Davvero nel 2026

Compra


Cosa acquista davvero un hosting "DMCA ignored", quali giurisdizioni lo supportano concretamente, i carichi di lavoro che ne hanno bisogno e le insidie sul copyright che il termine non copre.


FAQ di 6 domande](https://servghost.com/it/guides/dmca-ignored-hosting-explained)
[### Registrazione Anonima di Domini con Crypto: Privacy WHOIS nel 2026

Privacy


Una guida pratica 2026 per registrare domini senza rivelare la propria identità: regimi WHOIS per TLD, scelta del registrar, opzioni di pagamento crypto e gli errori operativi che vi espongono comunque.


FAQ di 6 domande](https://servghost.com/it/guides/anonymous-domain-registration-with-crypto)
[### Pagamenti Crypto per Hosting: Monero vs Bitcoin vs USDT

Privacy


Come la scelta della moneta di pagamento influisce su ciò che il tuo host scopre di te. Privacy, commissioni, finalità ed esposizione all'analisi della catena per XMR, BTC e USDT — con una raccomandazione chiara.


FAQ di 6 domande](https://servghost.com/it/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### L'hosting offshore è davvero anonimo? Una risposta onesta

Privacy


L'hosting offshore no-KYC elimina l'identità che un host normale raccoglie — ma "anonimo" dipende dal pagamento, dai log del provider e dalla tua opsec. Ecco cosa è davvero tracciabile.


FAQ di 6 domande](https://servghost.com/it/guides/is-offshore-hosting-truly-anonymous)
[### La prima ora di hardening di un VPS: una checklist

Operaciones


Una checklist concreta e ordinata per mettere in sicurezza un nuovo VPS in meno di un'ora: chiavi SSH, un firewall, fail2ban, aggiornamenti automatici e la riduzione della superficie d'attacco che blocca la maggior parte degli attacchi opportunistici.


FAQ di 6 domande](https://servghost.com/it/guides/first-hour-vps-hardening-checklist)
[### Cos'è l'Hosting No-KYC? Definizione, Legalità e Come Funziona

Privacy


L'hosting No-KYC ti permette di noleggiare un server senza alcuna verifica d'identità — nessun nome, nessuna email, nessun documento. Ecco cosa significa esattamente, come funziona tecnicamente, se è legale e come scegliere un provider affidabile.


FAQ di 6 domande](https://servghost.com/it/guides/what-is-no-kyc-hosting)
[### L'Hosting Offshore è Legale? La Risposta Onesta per il 2026

Compra


L'hosting offshore è legale — per te e per il provider. Ecco cosa significa davvero il termine, dove si trova il confine giuridico, i miti da sfatare e come usarlo in modo responsabile.


FAQ di 6 domande](https://servghost.com/it/guides/is-offshore-hosting-legal)
[### Come pagare l'hosting con Monero (XMR) — Guida passo dopo passo

Privacy


Una guida passo dopo passo per pagare un VPS o un server dedicato con Monero (XMR): perché XMR è l'opzione più privata, come ottenerlo e come funziona il checkout — dalla fattura al server operativo in pochi minuti.


FAQ di 6 domande](https://servghost.com/it/guides/how-to-pay-for-hosting-with-monero)
[### Come ospitare un sito web in modo anonimo — Guida pratica 2026

Privacy


Una guida pratica e stratificata per ospitare un sito web senza alcuna identità associata: l'account, il pagamento, il dominio, la giurisdizione, la connessione e il contenuto — ogni livello spiegato nel dettaglio.


FAQ di 6 domande](https://servghost.com/it/guides/how-to-host-a-website-anonymously)
[### Come Configurare una VPN WireGuard su un VPS — Guida Passo dopo Passo

Operaciones


Costruisci la tua VPN privata su un VPS con WireGuard: perché una VPN self-hosted supera quella commerciale, la configurazione completa dall'installazione a un client connesso, e come rafforzarne la sicurezza.


FAQ di 6 domande](https://servghost.com/it/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### Come fare self-hosting di un LLM su un server GPU — Guida 2026

Operaciones


Esegui il tuo modello linguistico su un server GPU in affitto: perché il self-hosting supera un'API, quale GPU e modello scegliere, la configurazione con Ollama o vLLM, e i costi reali.


FAQ di 6 domande](https://servghost.com/it/guides/self-host-an-llm-on-a-gpu-server)
[### Hosting Bulletproof vs Hosting Offshore — Qual è la Differenza?

Compra


Hosting bulletproof e hosting offshore vengono continuamente confusi — ma non sono la stessa cosa. Ecco la vera differenza, perché conta e quale dei due fa davvero al caso tuo.


FAQ di 6 domande](https://servghost.com/it/guides/bulletproof-vs-offshore-hosting)
[### Come acquistare un VPS con Bitcoin — Guida passo dopo passo (2026)

Compra


Una guida accessibile anche ai principianti per acquistare un VPS con Bitcoin: come ottenere BTC, scegliere un piano, pagare la fattura e cosa si ottiene — un server attivo senza carta e senza nome associato.


FAQ di 6 domande](https://servghost.com/it/guides/how-to-buy-a-vps-with-bitcoin)
[### I migliori paesi per l'hosting ignorato dal DMCA nel 2026

Compra


Dove ospitare i tuoi server quando vuoi essere al riparo dai takedown in stile statunitense: le giurisdizioni che funzionano davvero, cosa significa concretamente "ignorato dal DMCA" e come scegliere.


FAQ di 6 domande](https://servghost.com/it/guides/best-countries-for-dmca-ignored-hosting)
[### Come ospitare un servizio nascosto Tor (sito .onion) — Guida 2026

Operaciones


Configura un servizio onion Tor su un VPS: cos'è un servizio nascosto, perché rappresenta la forma più solida di hosting anonimo, la procedura completa e come mantenerlo davvero anonimo.


FAQ di 6 domande](https://servghost.com/it/guides/how-to-host-a-tor-hidden-service)
[### Configurazione di un Server Mail Offshore — Self-Hosting di Email Private nel 2026

Operaciones


Gestisci il tuo server email privato su un VPS offshore: perché ospitare la posta in autonomia, cosa ti serve, come configurare uno stack mail all-in-one e come garantire la consegna dei messaggi.


FAQ di 6 domande](https://servghost.com/it/guides/offshore-mail-server-setup)
[### Guida all'Hosting di Nodi Crypto — Esegui un Nodo Blockchain su un VPS

Operaciones


Come ospitare un nodo blockchain su un server: perché gestire il proprio nodo, come dimensionare il server per Bitcoin, Ethereum, Monero e non solo, la configurazione e come mantenerlo privato.


FAQ di 6 domande](https://servghost.com/it/guides/crypto-node-hosting-guide)
[### GPU Hosting per Stable Diffusion — Esegui il Tuo Server di Immagini

Operaciones


Esegui Stable Diffusion sul tuo server GPU dedicato: perché fare self-hosting della generazione di immagini, quale GPU scegliere, la configurazione con una web UI e il confronto dei costi rispetto a un servizio in hosting.


FAQ di 6 domande](https://servghost.com/it/guides/gpu-hosting-for-stable-diffusion)
[### Server OpSec — Restare Anonimi Quando Gestisci un Server

Privacy


Sicurezza operativa per chi gestisce un server anonimo: gli errori che espongono l'identità, le abitudini che li prevengono e come tenere davvero separate le identità.


FAQ di 6 domande](https://servghost.com/it/guides/server-opsec-staying-anonymous)
[### Guida alla configurazione di una seedbox — Costruisci la tua seedbox privata nel 2026

Operaciones


Come costruire la propria seedbox su un server: cos'è una seedbox, come dimensionarla, come installare un client torrent con interfaccia web e come mantenerla privata e sicura.


FAQ di 6 domande](https://servghost.com/it/guides/seedbox-setup-guide)
[### Come aggirare la censura DPI con il tuo VPS (guida 2026)

Privacy


La tua VPN ha smesso di funzionare? Come aggirare la censura DPI con il tuo VPS: cosa rileva davvero la deep packet inspection, quale dei cinque protocolli del 2026 batte quale tipo di blocco, e una guida completa a VLESS+REALITY.


FAQ di 6 domande](https://servghost.com/it/guides/bypass-dpi-censorship-with-your-own-vps)
[### Crittografia full-disk su un VPS: setup LUKS e cosa protegge davvero

Operaciones


Come cifrare un VPS con LUKS: volumi dati cifrati, cifratura full-root con sblocco remoto via SSH, le impostazioni che contano su un server piccolo, e cosa blocca davvero la crittografia del disco.


FAQ di 8 domande](https://servghost.com/it/guides/full-disk-encryption-on-a-vps)
[### Nascondere l'IP del server di origine: CDN, reverse proxy e cosa trapela

Privacy


Se mettere una CDN davanti a un server offshore: cosa nasconde, lo sportello reclami che erediti, i sei modi in cui un IP di origine trapela comunque, e come verificare il tuo.


FAQ di 8 domande](https://servghost.com/it/guides/hiding-your-origin-server-ip)
[### Backup VPS: Strategia Cifrata, Offsite e Che Funziona Davvero

Operaciones


Il tuo host non conserva backup. Cosa distrugge davvero i server, perché il backup push muore con loro, restic contro BorgBackup, e come testare un vero ripristino.


FAQ di 8 domande](https://servghost.com/it/guides/vps-backup-strategy)
[### Self-Hosting Matrix: federazione, metadati e cosa non copre la E2EE

Operaciones


Cosa ti dà davvero un homeserver Matrix: Synapse contro Conduit, il server_name che non puoi mai cambiare, i media che riempiono il disco e cosa rivela la federazione.


FAQ di 8 domande](https://servghost.com/it/guides/self-host-a-matrix-server)
[### Migrare un Sito su Hosting Offshore Senza Downtime

Operaciones


L'ordine che rende noiosa una migrazione di host: abbassa il TTL del DNS con giorni di anticipo, fai girare entrambi i server in parallelo, blocca le scritture per minuti anziché ore — e ripulisci la traccia di DNS passivo, Certificate Transparency e WHOIS che il trasloco lascia dietro di sé.


FAQ di 8 domande](https://servghost.com/it/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Operaciones


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 di 8 domande](https://servghost.com/it/guides/self-host-a-crypto-payment-gateway)




## Mettilo in un posto che filtra i flood



Server KVM offshore in sette giurisdizioni, con filtraggio DDoS L3/L4, banda illimitata, root completo e storage NVMe. Niente KYC, pagamento in crypto, operativo pochi minuti dopo la conferma della transazione.


[Vedi i Piani VPS](https://servghost.com/it/vps)
[Server dedicati](https://servghost.com/it/dedicated)
[Hosting offshore](https://servghost.com/it/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 e server dedicati offshore in 7 giurisdizioni. Nessun KYC, nessun log, solo crypto. Privacy per architettura.",
    "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": "Protezione DDoS per VPS: dove finisce l'host e comincia il livello 7",
    "description": "Il tuo host filtra i flood di pacchetti; i flood di richieste sono affar tuo. Come funziona il filtraggio L3/L4, perché il livello 7 lo attraversa indenne, e cosa tiene online un server offshore sotto attacco: caching, rate limit, tetti di connessione.",
    "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": "it",
    "keywords": "protezione DDoS VPS, come fermare un attacco DDoS su un server, mitigazione DDoS livello 7, rate limiting nginx anti-DDoS, hosting offshore con protezione DDoS, filtraggio DDoS L3 L4, come mitigare un SYN flood, nascondere l'IP del server di origine",
    "articleSection": "Operaciones",
    "wordCount": 4731
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "La «protezione DDoS inclusa» significa che sono al sicuro da tutto?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "No, e il divario è preciso, non vago. La protezione inclusa è filtraggio a livello di rete: scarta i flood volumetrici — SYN flood, amplificazione UDP, tempeste di pacchetti grezzi — a monte, prima che raggiungano la tua porta. È esattamente la categoria che non potresti gestire da solo, quindi è giusto che sia inclusa. Non ispeziona la tua applicazione, quindi un flood HTTP di qualche migliaio di richieste al secondo contro un endpoint costoso lo attraversa indenne e mette giù il tuo sito mentre ogni grafico di rete sembra normale. Il livello 7 è configurazione che possiedi tu: caching, rate limit e tetti di connessione."
            }
        },
        {
            "@type": "Question",
            "name": "Come distinguo un attacco DDoS da un normale picco di traffico?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Chiediti se quel traffico vuole qualcosa. I visitatori reali, anche un flusso improvviso di essi generato da un link popolare, richiedono pagine che esistono, caricano gli asset di quelle pagine, arrivano con referrer plausibili e si distribuiscono su molte reti diverse in modo naturale. Un attacco di solito martella un solo percorso, ignora gli asset, invia user-agent implausibili o assenti, e mostra una distribuzione che sembra artificiale. Controlla il tuo access log per le richieste per indirizzo client e per percorso: se un solo endpoint domina e nient'altro viene caricato, è un attacco. Se vengono servite le stesse pagine che vorrebbe una persona e i tuoi referrer sono reali, hai un problema di capacità con una causa felice."
            }
        },
        {
            "@type": "Question",
            "name": "Qual è la singola cosa più efficace che posso fare mentre sono sotto attacco?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Attiva il caching a pagina intera per i visitatori anonimi, e configuralo per servire contenuto scaduto quando il backend è in difficoltà. Un rate limit rifiuta il lavoro; una cache fa sì che il lavoro non esista. Una richiesta che costava una query al database, il rendering di un template e un worker applicativo diventa una lettura da file, e lo stesso hardware che crollava a poche centinaia di richieste dinamiche al secondo servirà decine di migliaia di richieste dalla cache. È anche l'unica misura dell'elenco che aiuta allo stesso identico modo contro il traffico reale, quindi a differenza di un rate limit non può ritorcersi contro i tuoi stessi utenti."
            }
        },
        {
            "@type": "Question",
            "name": "Perché il mio rate limit su nginx ha smesso di funzionare dopo aver messo una CDN davanti?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Perché ora ogni richiesta arriva dall'indirizzo della CDN e non da quello del visitatore, quindi un limite per client sta contando l'intero internet come un unico client. A seconda della soglia, o non scatterà mai, oppure bannerà tutto il tuo traffico in un colpo solo. Configura la tua sorgente IP reale — in nginx, i range di proxy fidati più l'header che il proxy invia — così il limite torna a basarsi sul visitatore reale. Restringi quella fiducia ai soli range del proxy: se accetti un header fornito dal client proveniente dall'internet aperto, un attaccante può forgiare una nuova identità a ogni richiesta e attraversare ogni limite che hai messo."
            }
        },
        {
            "@type": "Question",
            "name": "fail2ban basta da solo a fermare un attacco DDoS?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "No. fail2ban legge i log a intervalli e banna gli indirizzi colpevoli dopo una soglia, il che va bene per tentativi di forza bruta da un numero ridotto di fonti. Un attacco distribuito arriva in pochi secondi da migliaia di indirizzi che inviano ciascuno solo una manciata di richieste, quindi la soglia non viene mai raggiunta e comunque il tempo di reazione è di gran lunga troppo lento. Peggio ancora, un insieme di regole che cresce fino a decine di migliaia di voci può consumare più risorse dell'attacco stesso. Tienilo per SSH e per gli endpoint di login, e gestisci i flood con caching, rate limiting e un filtro a monte."
            }
        },
        {
            "@type": "Question",
            "name": "Dovrei usare una CDN, oppure far girare un mio reverse proxy davanti?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Dipende da cosa ospiti, più che dal tuo budget. Una CDN commerciale porta una capacità di assorbimento che non puoi eguagliare e una pagina di verifica a un clic di distanza, ma erediti il suo sportello reclami e può vedere il tuo traffico — il che per progetti offshore o sensibili a reclami DMCA è spesso l'anello più debole di un assetto altrimenti curato. I tuoi front node costano più lavoro e hanno limiti di capacità reali, ma non c'è nessuna terza parte nel percorso della richiesta, e un front che viene attaccato può essere sostituito con un nuovo indirizzo in pochi minuti. In entrambi i casi, l'origine deve essere blindata per accettare traffico web solo dal front, altrimenti l'intero assetto è decorativo."
            }
        },
        {
            "@type": "Question",
            "name": "Un attacco mi costerà anche denaro, oltre all'uptime?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Su un piano a consumo, sì — il traffico che non hai mai richiesto e non hai potuto rifiutare conta comunque contro la tua soglia di trasferimento, e un flood prolungato può produrre una fattura per l'eccedenza più alta di un anno di hosting. Questa è la ragione pratica per cui la banda illimitata conta più di quanto sembri su una scheda tecnica: converte un rischio finanziario in uno puramente tecnico. Vale anche la pena sapere in anticipo che se un attacco minaccia l'infrastruttura condivisa, i provider possono null-routare temporaneamente l'indirizzo; è prassi standard ovunque, non un difetto del tuo host in particolare."
            }
        },
        {
            "@type": "Question",
            "name": "Passare a un host offshore o no-KYC rende gli attacchi più probabili?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "La scelta dell'hosting in sé è neutra; è ciò che fai girare ad attirare l'attenzione. Server di gioco, forum, streaming, marketplace e qualunque cosa abbia un concorrente o un nemico attira attacchi a prescindere dalla giurisdizione. Ciò che cambia davvero offshore è il tuo margine di manovra: è meno probabile che tu venga scaricato perché sei scomodo, il che vale in entrambi i sensi — la protezione è tecnica, non contrattuale. Scegli una location con vera capacità di transito, prendi banda illimitata, tieni nascosto l'indirizzo di origine, e tratta il livello 7 come una tua responsabilità fin dal primo giorno, non dal primo incidente."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Home",
            "item": "https://servghost.com/it/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Guide di Hosting Privato",
            "item": "https://servghost.com/it/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Protezione DDoS per VPS: dove finisce l'host e comincia il livello 7",
            "item": "https://servghost.com/it/guides/surviving-a-ddos-attack-on-your-vps"
        }
    ]
}
```