# GPU server DDoS protection, included on every public IP

> GPU server DDoS protection is always on for every public IP, at no extra fee. Learn what it covers, what it does not, and how to harden inference APIs.

Source: https://overgpu.com/products/ddos-protection  
Updated: 2026-10-23  
Publisher: OverGPU (https://overgpu.com/)

## Key points

- **On every public IP:** DDoS mitigation covers the public IP addresses of every server, single-GPU or 8-GPU.
- **Always on:** Mitigation runs all the time. There is nothing to enable and no ticket to open when an attack starts.
- **No extra fee:** DDoS protection is part of the monthly price, like the public IPs and the included bandwidth.
- **Backed by the 99.9% SLA:** Power, network and hardware availability carries service credits. Attacks beyond the included protection are excluded.
- **SSH-key access:** Choose SSH-key login when you deploy, and password login stays switched off.
- **Engineers 24/7:** Report an attack or abuse in a support ticket from your dashboard, at any hour.

## Recommended configurations

- [NVIDIA H100 SXM](https://overgpu.com/gpus/nvidia-h100): $2,190 per month — 80 GB of HBM3 for a public LLM API behind your own proxy
- [NVIDIA RTX PRO 6000 Blackwell](https://overgpu.com/gpus/nvidia-rtx-pro-6000): $1,390 per month — 96 GB to serve models and media apps to the public
- [NVIDIA L40S](https://overgpu.com/gpus/nvidia-l40s): $890 per month — 48 GB entry point for public image and inference APIs

## Overview

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](https://overgpu.com/products/private-networking) 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](https://overgpu.com/legal/sla) 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](https://overgpu.com/blog/self-host-llm-inference-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](https://overgpu.com/docs/networking-firewall) 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;
    }
}
```

> Never expose a notebook server, a ComfyUI instance or a model server's own port directly to the internet. Bind them to 127.0.0.1 or to the private network, and reach them through the proxy or an SSH tunnel.

### 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](https://overgpu.com/docs/gpu-monitoring) 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.

## Frequently asked questions

### Does DDoS protection cost extra?

No. DDoS mitigation is included on the public IPs of every server, always on, at no extra fee.

### Do I need to turn it on during an attack?

No. Mitigation is always on, so there is nothing to enable. If you see a problem, open a support ticket from your dashboard, at any hour.

### Does it protect my inference API from abuse?

Only from network-level floods. Requests that look legitimate, such as many long prompts sent to an open endpoint, pass through, so put API keys, rate limits and a reverse proxy in front of your model server.

### Is downtime from a DDoS attack covered by the SLA?

The 99.9% commitment covers power, network and hardware availability. Attacks exceeding the protection included with the service are excluded from downtime under the SLA.

### Is my private network protected too?

The private network between your servers is not reachable from the internet, so DDoS mitigation applies to your public IPs.

## Related pages

- [GPU server firewall setup](https://overgpu.com/docs/networking-firewall): Allow SSH first, filter IPv6, avoid the Docker port trap and secure a vLLM endpoint with TLS and an API key.
- [GPU servers for LLM inference, running 24/7 at a flat price](https://overgpu.com/solutions/inference): KV cache sizing, FP8 and FP4, and 20–50 TB of bandwidth included. See the sizing math.
- [How to self-host LLM inference with vLLM](https://overgpu.com/blog/self-host-llm-inference-vllm): Size the GPU, run an OpenAI-compatible server, tune FP8, prefix caching and parallelism, and secure it for production.
- [Private network between GPU servers](https://overgpu.com/products/private-networking): Link your OverGPU servers on an isolated network for data pipelines and multi-node jobs. See how it works.
- [Service level agreement](https://overgpu.com/legal/sla): 99.9% monthly availability with service credits of up to 100% of the monthly fee.
- [nvidia-smi commands for monitoring GPU servers](https://overgpu.com/docs/gpu-monitoring): Live views, CSV logs, nvtop, DCGM exporter, ECC and Xid errors, plus rocm-smi equivalents.