RockCloud vs a DDoS-protected server: distributed scrubbing or one hardened rack
A protected server funnels every attack packet into one facility, down one pipe, at one publicly exposed IP. Outgrow that pipe and the carrier blackholes the address — the whole site vanishes, and there is nothing you can do from inside the box. RockCloud spreads scrubbing across 3,000+ edge nodes, hides your origin completely, and adds what a single rack was never going to give you: WAF, CC behavioural detection, cache acceleration and CN2 return paths. Your existing servers stay exactly where they are.
Start a free 24-hour testKey differences at a glance
| Dimension | RockCloud (cloud anti-DDoS CDN) | DDoS-protected server |
|---|---|---|
| Defence model | Distributed scrubbing across 3,000+ nodes, absorbed near the source | Scrubbing concentrated in one facility; all attack traffic converges there |
| Capacity ceiling | 7T+ of scrubbing network-wide, up to 3 Tbps on a single IP | Capped by the pipe that one facility sells you — what you bought is what you get |
| What happens on overage | Scrubbing level is raised to keep you online; availability comes first | Carrier blackholes the IP — unreachable at the network layer for hours |
| Origin IP | Fully hidden; only replaceable edge addresses are ever visible | The real IP is public, giving attackers one fixed target to hammer |
| Application-layer defence | WAF rules, CC behavioural detection and challenges, enforced at the edge | Network-layer scrubbing only — no WAF, no CC logic, valid requests pass through |
| Scaling up protection | Change a tier in the console; effective in minutes with zero user impact | A higher tier means a new machine: rebuild, migrate data, repoint DNS, take downtime |
| Performance | 3,000+ nodes serving locally, 98% cache hit ratio, bidirectional CN2 into China | One or two facilities worldwide — protected, but distant users still take the long way |
Four places where the gap actually opens up
None of this shows on a quiet day. The moment attack volume climbs or your audience spreads out, it turns into measurable downtime and lost conversions.
One facility’s ceiling is your entire defence ceiling
A protected server scrubs inside the single facility it lives in, so every attack packet has to reach that one ingress before anything filters it. The egress allocated to one customer is a hard cap, and once an attack exceeds it the carrier blackholes your IP to protect everyone else in the building. That is not a scrubbing failure — it is total unreachability at the network layer, typically for hours, and logging into the box changes nothing. We scrub across 3,000+ nodes so traffic is absorbed near its source, backed by 7T+ network-wide and up to 3 Tbps on one IP. Exceed your tier and we raise the scrubbing level to keep you serving, rather than null-routing you and leaving you to wait it out.
A fixed public IP is a bullseye
Protection on a dedicated box is bound to that machine’s public address, and the address has to be reachable, so one DNS lookup hands an attacker the target. An exposed IP is also hard to un-expose: historical DNS records, certificate transparency logs and mail headers all leave traces, so every rotation means another DNS change, another propagation wait, and being found again days later. Behind us, DNS resolves only to edge nodes and the origin sits behind the fetch path — allow our fetch ranges at the origin firewall, drop everything else, and every address an attacker can enumerate is a node we can replace at will.
Network-layer scrubbing does not stop the attacks that actually hurt
A protected server is built for volumetric floods — SYN, UDP reflection, anything decided by packet rate and bandwidth anomalies. What actually takes a business offline is CC: complete, well-formed HTTP requests with valid parameters from widely distributed sources. At the network layer they are indistinguishable from real users, so the scrubber forwards all of them and your database gives out before your pipe does. Traditional setups have no WAF, no request fingerprinting, no behavioural scoring and no challenges, leaving the origin to absorb it alone. We resolve that at the edge: CC detection on request rate, path distribution and client fingerprint, WAF rules against injection and scanning, and a 98% cache hit ratio that keeps the bulk of it off your origin.
Surviving an attack is not the same as being fast — and scaling should not mean a rebuild
Protected facilities exist in one or two locations, so every user routes to them regardless of where they are; buying protection does nothing for your cross-border or overseas experience. Defence and delivery are separate problems and the traditional answer solves only the first. Then, when volume grows, your only move is a bigger machine: rebuild the environment, migrate the database, repoint DNS, take real downtime — and attacks do not wait for a maintenance window. Here, mitigation and acceleration share one path and one bill: 3,000+ nodes serving locally, bidirectional CN2 GIA for mainland China visitors, and a protection tier you raise in the console in minutes. Your own servers never move — we sit in front of them.
Why teams move off protected servers
The reasons customers coming from a dedicated protected box give most often.
- One blackhole was enough — the attack barely exceeded the allocated pipe, the IP was cut off entirely, and the site, API and payment callbacks all went dark while support queues filled and nobody could do anything but wait.
- The real IP was already public and rotating it never held — DNS history, certificate logs and mail headers kept the trail alive, and the attacker was back on the new address within days.
- The protected server did nothing during a CC flood — every request looked legitimate at the network layer, all of it was forwarded, the application and database fell over first, and the mitigation dashboard reported a quiet night.
- Raising protection meant replacing hardware — rebuild, data migration and a DNS change, an overnight job at best, scheduled for a quiet window while attacks arrive at peak.
- Protected but still slow — with one or two facilities in the path, overseas and cross-border users waited on every page, conversions stayed flat, and nobody wanted to rebuild a working server just to get delivery.
Switching over takes four steps
No rebuild, no data migration, no application changes. The origin stays put, and a DNS record puts everything back.
Leave the origin alone
Your current server keeps serving as the origin — same environment, same data, same deployment. We do not sell servers; we sit in front of yours.
Onboard and validate
Add the domain and origin address in the console, then run a test hostname or a slice of traffic through it and compare latency, hit ratio and success rate.
Cut over and hide the origin
Repoint the main CNAME — live within five minutes. Then rotate the origin IP and allow only our fetch ranges so the old address stops working entirely.
Tune policy, retire the old box
Enable WAF and CC policies for your workload and set cache rules. After a stable week or two, downgrade or cancel the protected server.
Anti-DDoS CDN vs protected server FAQ
If your service is reached through a hostname — website, app API, game, live stream, payment callbacks — take the cloud anti-DDoS CDN. The difference is structural: a protected server concentrates scrubbing in one facility whose pipe is your ceiling, and exceeding it means a blackhole. A CDN scrubs across 3,000+ nodes near the traffic source and adds origin shielding, CC defence and acceleration in the same move. A protected server only wins for raw-IP protocols that cannot be fronted by a hostname.
Yes, and this is one of our most common onboarding scenarios. A blackhole is the carrier dropping your IP at the network layer, so nothing you do inside the server helps and the timer has to expire. The move is to repoint DNS at our edge immediately and give the origin a fresh, un-blackholed address for fetches. Let the attacker keep hitting the old IP — it is already null-routed. The whole switch takes minutes, and our 24/7 engineering team stays on the line through it.
Yes. Exposure means an attacker knows a fixed address of yours, so stop serving from it. Behind us, DNS resolves only to edge nodes; you rotate the origin to a new IP and allow only our fetch ranges at the firewall, dropping everything else. The address the attacker holds now points at a machine that no longer answers. However hard they scan afterwards, all they get are node addresses we can replace — the origin never appears in a DNS answer again.
On a protected server, a higher tier effectively means a new machine: rebuild the environment, migrate the database, repoint DNS and accept downtime — usually forced on you after an attack has already hurt. With us there is nothing to migrate. We do not sell servers, your origin stays on the hardware you already run, and raising the protection tier is a console change that takes effect in minutes with no user-visible impact.
Largely no. Its scrubbing targets volumetric traffic and decides on packet rate and bandwidth anomalies, while CC sends complete, valid HTTP requests with normal parameters from distributed IPs, often at a modest rate. At the network layer that is a real user, so it gets forwarded. Stopping CC needs application-layer logic: request-rate and path-distribution analysis, client fingerprinting and behavioural scoring, challenges where warranted, and caching to absorb repeats at the edge — none of which a traditional protected box provides.
Yes, and the two are not in conflict. The server you already paid for keeps working as the origin, so nothing is wasted. We add in front of it what it cannot do: origin shielding, WAF and CC behavioural detection, local delivery and caching, CN2 return paths into China, and distributed scrubbing once volume exceeds what one facility can take. After a stable period most customers downgrade the protected server to an ordinary one and drop that line item entirely.
Still haven't found what you're looking for? Talk to our team.
Third-party trademarks belong to their respective owners. Products and pricing may change — refer to the latest official information.
Bring us the attack you are dealing with and test us for 24 hours
Tell us your workload, the volume you are seeing and the specs of your current protected server, and we will come back with an onboarding plan and a side-by-side test. The origin never moves — decide after you see the numbers.