What's the Difference Between a DDoS-Protected IP and an Ordinary Server? How to Choose?

Essential difference: a DDoS-protected IP takes the hit and scrubs attack traffic for you; an ordinary server can only absorb attacks with its own bandwidth. FAQ covering how a DDoS-protected IP works, how it differs from a DDoS-protected server, which sites need one, selection criteria, plus origin-firewall commands that allow only origin-return IPs.

Introduction

Site operators hit by DDoS once almost always start researching anti-DDoS. The real gap between a DDoS-protected IP and an ordinary server, whether it is the same as a DDoS-protected server, and when it is worth buying — a lot of claims are inaccurate. This FAQ covers how a DDoS-protected IP works, the essential difference from an ordinary server, selection criteria, and post-onboarding notes.

Q: What is a DDoS-protected IP? Essential difference vs. an ordinary server IP?

A DDoS-protected IP is a proxy scrubbing layer in front of origin: DNS points at the protection node, all traffic hits the protection PoP first, attack traffic is identified and filtered in the scrubbing center, only clean traffic is returned to your real server. An ordinary server IP is exposed directly on the public internet; attack traffic hits the server itself. Essential difference: the ordinary server is the target; the DDoS-protected IP is the shield that takes the hit and filters the attack. Ordinary servers absorb with their own bandwidth; DDoS-protected IPs absorb with datacenter-scale scrubbing and elastic bandwidth.

Q: How does a DDoS-protected IP stop DDoS?

Protection nodes typically have four capabilities a single server does not:

• Large bandwidth reserve: scrubbing centers are measured in Tbps. Even large floods rarely saturate the node itself;
• Traffic diversion and scrubbing: BGP steers attack traffic into the scrubbing cluster; signature filtering, protocol validation, and fingerprinting strip malicious traffic;
• Elastic protection: peaks above the baseline can burst. No need to buy the absolute peak as a fixed commit;
• Application-layer CC protection: rate limits, human challenges, and session checks against HTTP-layer CC attacks.

An ordinary server loses connectivity the moment attack traffic exceeds its bandwidth cap — the pipe is full. Server specs do not matter.

Q: Can an ordinary server absorb DDoS on its own?

Small floods, yes. Linux kernel knobs and the firewall can blunt low-intensity SYN Flood and similar:

`# Enable SYN Cookie to mitigate SYN Flood
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

# iptables: limit new connection rate per IP
iptables -A INPUT -p tcp --dport 443 --syn -m connlimit --connlimit-above 50 -j DROP`

These only delay. They do not fix the root problem. Once attack traffic exceeds your bandwidth cap (e.g. a typical 100M dedicated link), the ingress is clogged and every host-side tweak is irrelevant. Decision rule is simple: if attack volume stays below leftover bandwidth, self-absorb; if it exceeds the cap, you need a DDoS-protected IP.

Q: Is a DDoS-protected IP the same as a DDoS-protected server?

No. This is the most common selection mix-up:

• DDoS-protected server: the whole box lives in an anti-D datacenter with scrubbing. The IP itself has defense. Fits workloads that must own the machine, or that are extremely latency-sensitive;
• DDoS-protected IP: proxy-forward mode. Origin can be a server in any datacenter. No business migration. Onboarding is a DNS change, and the real origin IP can be hidden.

For existing workloads you do not want to migrate, a DDoS-protected IP is the smallest change. For a greenfield heavy workload, consider a DDoS-protected server directly. Do not confuse a DDoS-protected IP with ordinary CDN: CDN is cache/acceleration; scrubbing capacity against large DDoS is limited. Protection-node scrubbing clusters are built for attacks.

Q: Which sites need a DDoS-protected IP?

• Already hit once: attackers rarely stop at one shot. Recurrence after a first hit is high;
• Business that must stay online: ecommerce checkout, games, payment callbacks, API services. One minute of downtime is real money;
• High-target verticals: finance, private game servers, businesses with competitive disputes are frequent DDoS targets;
• Origin IP already leaked: historical DNS, mail headers, subdomains can expose the real IP. Attackers bypass CDN and hit origin directly.

Q: What parameters matter when choosing a DDoS-protected IP?

• Mitigation peak: look at the scrubbing cluster's total capacity and elastic ceiling. 100G is a sane floor for typical business. Inflated peak numbers are common in the industry; demand a stress test or historical mitigation report;
• Scrubbing-node transit: prefer BGP multi-homed nodes. Single-transit paths detour users in some regions;
• CC protection: DDoS mitigation and CC protection are separate stacks. Check HTTP-layer QPS ceiling and challenge mechanics;
• Origin-return method: confirm IP hiding and whether origin-return IPs are static. That drives origin firewall config;
• Billing elasticity: commit + burst costs less than buying peak mitigation as a fixed SKU.

Q: After onboarding a DDoS-protected IP, what else?

Critical: prevent origin IP leak. After onboarding, the origin firewall should allow only the protection node's origin-return IPs and deny everything else:

`# Allow only the DDoS-protected origin-return CIDR on 443 (use the origin IP list provided by the vendor)
iptables -A INPUT -p tcp --dport 443 -s 203.0.113.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP`

Also hunt every channel that can leak origin IP: historical DNS records, mail-server sending headers, subdomain direct connects, SSL certificate transparency logs. Once origin IP leaks, attackers bypass protection and hit origin directly. Protection becomes theater. Before cutting DNS, lower TTL (e.g. 300 seconds) so the cutover lands faster.

Q: Additional notes?

• Do not wait to be hit: selecting, onboarding, and tuning rules during an attack costs more downtime than protecting in advance;
• Configure monitoring/alerts: know first when bandwidth and connection counts spike, not after user complaints;
• Periodically verify mitigation is live: after onboarding, use `ping` and `dig` to confirm resolution points at the protection node and that origin direct-connect is blocked;
• Keep attack evidence: traffic-monitor screenshots, provider attack reports. Useful for police reports and attribution;
• Protection and backups in parallel: anti-DDoS handles knock-down; backups handle knock-through. Need both.