DDoS attack on a VPS: what happens
and how to stop it

Back to Blog

What Happens Second by Second When a DDoS Hits Your VPS

If you run anything on a VPS, from a game server to a SaaS product, you are a target. VPS instances sit on shared infrastructure with limited bandwidth allocations, which makes them especially vulnerable to volumetric DDoS attacks. Understanding exactly what happens during an attack is the first step toward surviving one.

Here is what a typical DDoS attack looks like from inside a VPS, broken down second by second:

Seconds 0 to 5: Attack traffic begins arriving at your VPS. Depending on the attack type (UDP flood, SYN flood, DNS amplification), your network interface starts receiving thousands to millions of packets per second. Your server's NIC buffer fills up. Legitimate packets start getting dropped because the kernel cannot process them fast enough. If you are watching iftop at this exact moment, you will see bandwidth usage spike from your normal baseline to the maximum your VPS allocation allows.

Seconds 5 to 30: Your services start degrading. Web requests time out. Database connections hang. API responses that normally take 50ms now take 10 seconds or fail entirely. If you are connected via SSH, your session becomes laggy. Keystrokes take 2 to 5 seconds to echo. You might still be able to run commands, but the output is delayed and unreliable. Your monitoring tools (if you have any) start firing alerts for high packet loss and latency.

Seconds 30 to 120: The attack ramps to full volume. Your 1 Gbps VPS link is now saturated with 2, 5, or even 10 Gbps of attack traffic. The excess traffic is being dropped at the hypervisor level, but even the traffic that reaches your instance is more than it can handle. SSH becomes completely unresponsive. You cannot connect to your server at all. Your website returns connection timeouts. Your users start contacting you through other channels asking if you are down.

Seconds 120 to 300: Your VPS provider's automated detection systems pick up the attack. The provider sees that one IP on their network is receiving an abnormal volume of traffic that is affecting the shared infrastructure. Their automated system triggers the next step: null-routing your IP address.

How VPS Providers Detect and Respond

Most major VPS providers have automated DDoS detection systems that monitor traffic patterns across their network. When traffic to a single IP exceeds a threshold, the provider takes action. The specifics vary by provider, but the general approach is the same: protect the shared infrastructure by sacrificing the targeted IP.

OVH operates one of the more sophisticated DDoS mitigation systems among VPS providers. Their VAC (Vacuum) system can scrub traffic up to 1.3 Tbps. For VPS plans, traffic is routed through the VAC automatically when an attack is detected. However, the scrubbing is generic and may not catch application-layer attacks. If the scrubbing fails to reduce traffic to acceptable levels, a null-route may still be applied.

Hetzner uses automated null-routing when inbound traffic exceeds approximately 500 Mbps for standard VPS instances. The null-route typically lasts 1 to 3 hours. There is no scrubbing option on standard VPS plans. You can request the null-route be lifted early through support, but they will only do so if the attack has stopped.

DigitalOcean applies null-routing when traffic to a droplet threatens their network infrastructure. Their threshold varies but generally kicks in between 1 to 2 Gbps of sustained attack traffic. The null-route can last anywhere from 1 to 24 hours. DigitalOcean does not offer integrated DDoS scrubbing for standard droplets.

Vultr has automated DDoS detection and will null-route IPs receiving sustained attack traffic. Their documentation states they may suspend instances that are repeatedly targeted. They offer no built-in scrubbing for standard plans.

Linode (Akamai) benefits from Akamai's network but standard Linode instances still get null-routed during significant attacks. Their threshold is generally higher than smaller providers (around 1 to 2 Gbps), and they offer some basic traffic filtering, but heavy attacks result in null-routing lasting 1 to 24 hours.

What Null-Routing Actually Means for You

When your VPS provider null-routes your IP address, they announce a route for your IP that points to /dev/null at their network edge. Every packet destined for your IP, whether it is attack traffic or a legitimate customer trying to load your website, is silently dropped before it ever reaches your server.

Your server is technically still running. The operating system is up, your processes are active, and if you had a second IP or an out-of-band management console, you could still access it. But from the internet's perspective, your server does not exist. DNS queries for your domain still resolve to your null-routed IP, so every connection attempt fails with a timeout.

This is an important distinction: null-routing protects the provider's network, not yours. The provider is not mitigating the attack for your benefit. They are preventing the attack traffic from congesting their switches, routers, and the other customers sharing your physical host. Your downtime is an acceptable tradeoff for them.

The null-route typically lasts between 1 and 24 hours, depending on the provider and the severity of the attack. Some providers lift the null-route automatically after a set period. Others require the attack to stop completely before they remove it. If the attacker sends another burst of traffic after the null-route expires, the cycle starts over.

The Timeline of a Typical VPS DDoS

Understanding the full timeline helps you plan your response. Here is what a typical VPS DDoS incident looks like from start to finish:

1. T+0:00 - Attack traffic begins hitting your IP. Services start degrading within seconds.
2. T+0:30 to T+2:00 - Full degradation. SSH unresponsive. Web services down. You are aware something is wrong but cannot diagnose from inside the server.
3. T+2:00 to T+5:00 - Provider's automated system detects the anomaly and applies a null-route to your IP.
4. T+5:00 onward - Your server is completely unreachable from the internet. Attack traffic is being dropped at the provider's edge. Your server's load actually returns to normal because no traffic is reaching it.
5. T+1h to T+24h - Null-route expires. Your IP becomes reachable again.
6. T+24h+ - Attacker may launch another round. The cycle repeats.

The critical window is between T+0:00 and T+2:00. That is the only time you have any chance of taking action on the server itself. Once the null-route kicks in, you are locked out with everyone else. If you do not have monitoring that alerts you within the first 30 seconds, you will likely miss this window entirely.

Why VPS Users Are Easy Targets

VPS instances are disproportionately targeted for several reasons that make them attractive to attackers and difficult to defend:

• Shared infrastructure. Your VPS sits on a physical host alongside dozens of other instances. The provider must protect the entire host, which means your tolerance for attack traffic is lower than a dedicated server.
• Limited bandwidth. Most VPS plans allocate 1 Gbps of shared bandwidth. A 2 Gbps attack, trivial by modern standards, is enough to overwhelm your allocation and trigger a null-route.
• Predictable IP ranges. VPS providers allocate IPs in sequential blocks. Attackers can scan entire ranges to find active hosts. If you run a game server, API endpoint, or any service with publicly known IPs, you are trivially discoverable.
• No upstream filtering. Unlike dedicated hosting or colocation where you can purchase upstream DDoS scrubbing, VPS plans typically offer no option to add third-party mitigation at the network level.
• Low cost of attack. Booter services can generate 5 to 10 Gbps of attack traffic for under $20. Taking down a VPS requires minimal effort and budget from the attacker.

Detecting Attacks Before Your Provider Null-Routes You

The key to surviving a VPS DDoS is detecting the attack in the first few seconds, before your provider's automated system kicks in and locks you out. Here are the tools and techniques for early detection:

Monitoring /proc/net/dev

The /proc/net/dev file provides real-time network interface statistics updated by the kernel. You can poll it to detect sudden spikes in received packets or bytes:

# Watch packet counters update every second
watch -n 1 'cat /proc/net/dev | grep eth0'

# Sample output during normal operation:
# eth0: 1284923847  892341  0  0  0  0  0  0  284719234  341923  0  0  0  0  0  0

# Sample output during attack:
# eth0: 9284923847  89234100  482910  0  0  0  0  0  284719234  341923  0  0  0  0  0  0

The third column (errors) and fourth column (drops) jumping from 0 to thousands is a clear indicator that attack traffic is overwhelming your NIC. The received bytes and packets columns will also show a dramatic increase.

Using vnstat for Bandwidth Monitoring

# Real-time bandwidth monitoring
vnstat -l -i eth0

# Output shows current rx/tx rates:
# rx:   847.21 Mbit/s  142893 p/s
# tx:    12.34 Mbit/s    8923 p/s

# A massive asymmetry between rx and tx is a strong DDoS indicator

Checking PPS (Packets Per Second) with iftop

# Monitor per-connection bandwidth usage
iftop -n -i eth0

# The -n flag skips DNS lookups (critical during an attack,
# you don't want to waste resources on reverse DNS)

During an attack, iftop will show a small number of source IPs generating massive traffic, or (more commonly with amplification attacks) thousands of source IPs each sending moderate traffic that adds up to a flood.

Terminal Commands to Run During an Attack

If you catch the attack early and still have SSH access, these commands help you understand what you are dealing with:

# Connection state summary
ss -s
# Look for a massive number of SYN-RECV or ESTAB connections

# Top source IPs by connection count
ss -tn state established | awk '{print $5}' | \
  cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Current connection states breakdown
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -rn
# Normal: mostly ESTABLISHED and TIME_WAIT
# Attack: thousands of SYN_RECV or massive ESTABLISHED count

# Real-time packet rate on eth0
cat /proc/net/dev | grep eth0; sleep 1; cat /proc/net/dev | grep eth0
# Compare the received packets column between the two reads

# Check which ports are receiving the most traffic
ss -tun | awk '{print $5}' | cut -d: -f2 | sort | uniq -c | sort -rn | head -10

Save these commands in a script on your server before you need them. During an attack, SSH is slow and unreliable. Having a single script that dumps all diagnostics at once saves critical time.

Immediate Response Steps

Once you have confirmed you are under attack, take these steps as quickly as possible:

Emergency iptables Rules

If the attack is a SYN flood or connection-based flood, you can buy time with aggressive rate limiting:

# Accept established connections first
iptables -I INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Rate-limit new connections
iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 50 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# If it's a UDP flood, drop all UDP except DNS (if you need it)
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p udp -m limit --limit 50/s -j ACCEPT
iptables -A INPUT -p udp -j DROP

# Drop ICMP floods
iptables -A INPUT -p icmp -m limit --limit 10/s -j ACCEPT
iptables -A INPUT -p icmp -j DROP

These rules will not stop a volumetric attack (the bandwidth is still saturated at the network level), but they can prevent your server's CPU and memory from being exhausted by connection-state attacks, keeping SSH accessible longer.

Contact Your Provider

Open a support ticket immediately. Include the time the attack started, the type of traffic you are seeing (protocol, port, source IP patterns), and ask specifically:

• Can they apply traffic filtering instead of a full null-route?
• Can they assign you a new IP address?
• What is the expected duration of the null-route?
• Do they offer any DDoS mitigation add-ons for your plan?

Request an IP Change

If the attack is targeting your specific IP (which it almost always is), getting a new IP is the fastest way to restore service. Most VPS providers can assign a new IP within minutes. Update your DNS records immediately after the change. Use a low TTL (60 to 300 seconds) on your DNS records ahead of time so that future IP changes propagate quickly.

Long-Term Prevention

Surviving one attack is not enough. If you have been targeted once, you will be targeted again. Here are the long-term measures that actually work for VPS deployments:

Cloudflare Proxy for Web Services

If you run a website or web API, put it behind Cloudflare's proxy. This hides your origin VPS IP behind Cloudflare's anycast network. Attackers hitting your domain will hit Cloudflare's edge instead of your VPS. The free plan includes basic DDoS protection. The Pro plan ($20/month) adds WAF and more aggressive bot filtering. This is the single most effective step you can take for web-facing services.

Critical caveat: Cloudflare only protects traffic that goes through their proxy (HTTP/HTTPS on ports 80 and 443). If you run game servers, mail servers, or other non-web services, those ports are still exposed at your real IP.

GRE Tunnel to a Scrubbing Provider

For non-web services, you can set up a GRE tunnel to a DDoS scrubbing provider like Path.net or Voxility. Traffic is routed through the scrubbing provider, which filters attack traffic and forwards clean traffic through the GRE tunnel to your VPS. This protects all ports and protocols but adds 2 to 5ms of latency and costs $50 to $200/month depending on the provider and bandwidth.

Running Flowtriq for Early Detection

The biggest problem with VPS DDoS attacks is not the attack itself. It is finding out about it too late. By the time your uptime monitor sends an alert, your provider has already null-routed you and you are locked out for hours. Flowtriq solves this by detecting attacks within 1 second of onset. The moment your packets-per-second or bandwidth deviates from your baseline, Flowtriq fires an alert through Discord, Slack, PagerDuty, email, or webhook. You get notified while you still have SSH access, giving you the window you need to apply emergency rules or trigger your incident response plan.

Provider DDoS Protection Comparison

Not all VPS providers handle DDoS attacks the same way. Here is a quick comparison of what you can expect:

• OVH / OVHcloud: Built-in VAC scrubbing on all plans. Best default protection among major VPS providers. Can handle most volumetric attacks without null-routing. Game DDoS protection available on specific plans.
• Hetzner: Null-route only. No scrubbing on standard VPS. Fast null-route trigger (around 500 Mbps). Good value but poor DDoS resilience.
• DigitalOcean: Null-route only. No mitigation add-ons for droplets. Support is responsive but cannot do much during active attacks.
• Vultr: Null-route with possible instance suspension for repeated attacks. No built-in scrubbing. They may ask you to leave if attacks persist.
• Linode (Akamai): Higher null-route threshold due to Akamai backbone. Some basic filtering. Still null-routes under sustained heavy attacks.
• AWS Lightsail: Benefits from AWS Shield Standard (free). Handles small attacks well. Large attacks may still result in throttling or IP blackholing.

If DDoS resilience is critical for your use case, OVH's VPS plans with VAC protection or AWS Lightsail with Shield Standard offer the best out-of-the-box protection. For everything else, you need a third-party solution.

How Flowtriq Helps VPS Operators

Flowtriq was built for exactly this scenario. Here is what it does for VPS operators who cannot afford enterprise DDoS mitigation:

1-second detection. Flowtriq monitors your network traffic in real time and detects anomalies within 1 second. It watches packets-per-second, bandwidth, connection rates, and protocol distribution. The moment any metric deviates from your learned baseline, an incident is created.

Instant alerts before null-route. You get notified through your preferred channel (Discord, Slack, PagerDuty, OpsGenie, email, SMS, or webhook) the moment an attack begins. This gives you the 30 to 120 second window before your provider null-routes you, enough time to apply emergency rules, trigger failover, or start your incident response.

PCAP capture for evidence. Flowtriq can capture packet data during the attack, giving you forensic evidence of the attack vectors, source IP distribution, and traffic characteristics. This is invaluable when talking to your provider's abuse team or when filing reports with law enforcement.

Attack classification. Instead of staring at raw packet counters trying to figure out if it is a SYN flood, UDP amplification, or DNS reflection, Flowtriq classifies the attack type automatically and shows you exactly what is happening.

Automatic mitigation triggers. Flowtriq can trigger automated responses when an attack is detected, from applying pre-configured iptables rules to sending commands to your edge firewall or calling a webhook that activates your cloud scrubbing service.

Flowtriq plans start at $9.99/month per node. For VPS operators, that is a fraction of the cost of a single hour of downtime. Start your 7-day free trial and see your traffic patterns in real time.

Back to Blog

Related Articles