GPU server DDoS protection, included on every public IP

GPU server DDoS protection is included with every OverGPU server. Mitigation is always on for your server's public IPs, at no extra fee, whether you rent one GPU or eight. It is there to filter network floods before they reach your machine. It does not make an open inference endpoint safe on its own, and this page explains the difference.

How GPU server DDoS protection works

A distributed denial-of-service attack tries to exhaust a server's network link or connection handling with traffic from many sources. Mitigation sits in front of your public IPs at the network level: attack traffic is filtered before it reaches the server, while legitimate traffic keeps flowing. Because it is always on, there is no switch to flip and no ticket to open before it starts working.

It applies to every server we rent, single-GPU or 8-GPU. If you use a private network between your servers, that side is not reachable from the internet at all.

What it covers, and what it does not

Covered

• Floods of attack traffic aimed at your public IPs at the network level, the kind that would otherwise saturate the link.
• Every server, at all times, at no extra fee.

Not covered

• Attacks exceeding the included protection. Our service level agreement excludes them from downtime, so they do not count toward service credits.
• Application-layer abuse. Requests that look legitimate at the network level, such as many long prompts sent to an open API, pass through. Your application has to handle them.
• Your software and configuration. An exposed notebook server, a database without a password or a leaked API key are outside what network mitigation can fix. The SLA also excludes issues caused by your software, configuration or use.
• Credentials. Keeping SSH keys and API keys secure is your responsibility, as is activity on your servers.

Why inference endpoints need more than DDoS mitigation

A GPU endpoint is expensive per request. A static web page costs almost nothing to serve, while a language model can spend seconds of GPU time on one long prompt and a long answer. Nobody needs a flood to exhaust it. A modest number of concurrent requests with long contexts can fill the KV cache and queue every real user behind them, and to the network that traffic looks normal.

So protection for inference lives in your stack: a firewall, a reverse proxy, authentication and limits in front of the model server. Our guide to self-hosting LLM inference with vLLM covers the serving side.

Hardening checklist for exposed endpoints

1. Firewall the host

Allow SSH and HTTPS, and deny everything else:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Docker publishes ports through its own iptables rules, which can bypass ufw. Publish model servers on localhost only, for example -p 127.0.0.1:8000:8000. The networking and firewall guide goes further.

2. Put a reverse proxy in front

Keep the model server on 127.0.0.1 and expose only a reverse proxy such as nginx or Caddy. It terminates TLS, caps the request size and limits the request rate per client:

limit_req_zone $binary_remote_addr zone=api:10m rate=5r/s;
server {
    listen 443 ssl;
    server_name api.example.com;
    # ssl_certificate and ssl_certificate_key go here
    client_max_body_size 1m;
    location /v1/ {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://127.0.0.1:8000;
        proxy_read_timeout 300s;
    }
}

3. Require API keys

Do not leave an endpoint open by accident. vLLM's OpenAI-compatible server takes an --api-key option and then rejects requests without the matching bearer token:

vllm serve <model> --host 127.0.0.1 --port 8000 --api-key "$VLLM_API_KEY"

If several clients use the endpoint, give each one its own key at the proxy or gateway, so a leaked key can be revoked without affecting the others.

4. Cap what one request can cost

Rate limits count requests, but GPU cost depends on tokens. Cap context length and concurrency on the server, for example with vLLM's --max-model-len and --max-num-seqs, and enforce a ceiling on max_tokens in your API layer. Watch GPU utilization, queue depth and error rates so abuse shows up early; the GPU monitoring guide lists what to track.

If you are under attack

Open a ticket from the support section of your dashboard with the affected IP address, the time the problem started and what you see: traffic graphs, error rates, logs. Support is available 24/7. If it is application-layer abuse, tighten limits and rotate keys at the same time. If downtime caused by power, network or hardware on our side brings your monthly availability below 99.9%, request service credits through support within 30 days after the end of the month; credits are added to your account balance.