LearnDocsLog in
Deploy a serverDeploy

DDoS protection that runs on the machine it protects.

Floods large enough to fill the link are absorbed upstream, where 17 Tbps of mitigation capacity sits in front of every plan. What reaches your server meets Clouduxe Prism, our own XDP/eBPF filter at the network driver, which checks the address, the transport and the protocol your service speaks before it sees a single packet. Whatever you run, the same filter is in front of it.

See plans and pricesFollow a packet through
Upstream capacity
17 Tbps, the same on every plan
On the host
Clouduxe Prism, XDP/eBPF at the network driver
Checks, in order
Layer 3, then Layer 4, then Layer 7
Protocol validators
8 families
Regions
Mumbai, Singapore and Limburg
Price
Included with every server

One filter in front of everything you run. Blue reaches your server. Ember is dropped at the first check that recognises it.

Reaches your server Dropped at the first check that recognises it

Two layers, and only one of them needs you. The edge handles size. Prism handles whether a packet is real.

  • The upstream edge, then Prism on your server

    Neither job can be done well from where the other one sits. The edge removes traffic before it arrives, with nothing for you to set. Prism runs on the machine itself and judges packet by packet, and that is the layer you configure. What the edge removed is folded into the same drop counters on the Attacks tab, so you read one figure, not two partial ones.

  1. InternetReal users and the flood, mixed
  2. Upstream edge17 Tbps capacity. Absorbs volume. Nothing to configure.
  3. Prism, L3 to L7At the driver of the host's 25 Gbit/s card, before your port. Your rules.
  4. Your serviceLegitimate traffic only
A diagram of the mechanism, not a measurement. Band widths show order, not quantities.

On the host, three questions in order. Each layer only runs if the one before it did not already decide.

See the whole path

  1. Layer 3

    The address

    Is this source allowed to talk to this server at all, and is the packet structurally sane?

    Ends here: blocked sources and malformed packets, at the lowest possible cost.

  2. Layer 4

    The transport

    Is this a real TCP or UDP conversation, or a packet pretending to be one?

    Ends here: spoofed and stateless floods, and traffic above the ceilings on your port rules.

  3. Layer 7

    The protocol

    Is this actually the protocol the port claims to serve?

    Ends here: floods that look like real clients on the wire but never speak the service's protocol.

The cheapest question comes first, so the expensive one is only ever asked about traffic that survived the cheap ones.

What changes when the filter sits on your own machine. Scrubbing handles volume. It cannot read your protocol.

CapabilityClouduxeUpstream-only scrubbing
Ask why one user was droppedAddress lookup names the check that did it, with exact countsNo record of a single address
Judge the protocol your service speaksValidators for DNS, RDP, VPN, TeamSpeak and four game protocol families, plus HTTP request checksVolume and known signatures
Where filtering happensAt the network driver of your own machine, before the kernel allocates a bufferIn a scrubbing centre, then relayed on to you
Ceilings you controlPer port, per source and per connection, from the Firewall tabOne profile for the whole address
Why a packet was droppedA reason recorded per packet, grouped into incidentsA dropped total
Clients already connectedSources that proved themselves keep priority when pressure risesEvery packet is equally anonymous
A check that misfires on your trafficSwitch it off for that rule yourselfOpen a ticket

Most "DDoS protected hosting" means scrubbing upstream and nothing on the server. The right-hand column describes that category of service, not any named provider. Both share the same upstream idea: absorb what would fill the link. The difference is everything after that.

What you control. It all runs untouched. You choose ports, ceilings and trusted sources.

One switch for the server

Protection for each server address reads Active or Paused. Paused lets every packet through unfiltered, so it exists for troubleshooting. Pausing deletes nothing: your rules and lists are back in force the moment you switch it on.

growth-sg / FirewallTry itExample view

growth-sg

203.0.113.40

Inbound rules
5
Trusted sources
1
Blocked sources
1
Protection
Active

Default for unlisted ports

AllowDeny all

Pause protection or change the default to see what it means.

Port rules

One rule opens one port or port range on TCP or UDP and carries every setting for it: the service it serves, its ceilings, protocol validation and the engines that run. A port with no rule falls to your default for unlisted ports, Allow or Deny all.

growth-sg / FirewallTry itExample view
PortServiceCheckWhole port
tcp/443Web (HTTPS)None
tcp/22SSH2,000 pps
udp/53DNS20,000 pps
tcp/3389RDP5,000 pps
udp/30120FiveM50,000 pps
any otherClosed

Flip a check to see what changes. Web and SSH have no protocol validator.

Rate limits

Two packet-rate ceilings per rule. Whole port bounds a distributed flood across every source; per connection bounds a single established flow inside it. Both are counted in packets, because a flood of small packets can exhaust a server long before it fills the link.

growth-sg / Firewall / Edit ruleExample view
RuleTCP 25565 Minecraft (Java)
Whole port, packets/sec (0 = unlimited)10,000
Per connection, packets/sec (0 = service default)250

Needs a whole-port ceiling above. The datapath only consults this inside that limit, so on its own it is not applied.

Presets

Ready-made rule bundles for a web server, TeamSpeak and common game servers. Applying one writes ordinary rules you can edit afterwards, most with protocol validation already on where the service has a validator.

growth-sg / Firewall / Inbound rulesTry itExample view

Quick setup: apply a preset for a common workload

  • Web serverTCP 80, TCP 443
    2 rulesApply
  • TeamSpeak 3UDP 9987, TCP 10011, TCP 30033
    3 rulesApply
  • FiveM (GTA RP)TCP 30120, UDP 30120
    2 rulesApply
  • Minecraft (Java)TCP 25565
    1 ruleApply
  • Source / CS2UDP 27015
    1 ruleApply

Blocking and allowing addresses

Deny one address outright, for an hour, a day, a week or for good, or trust one so it skips rate limits and behavioural filters. A source rule applies whichever port the sender aims at, and it never opens or closes a port for anyone else.

growth-sg / Firewall / Source IPsTry itExample view
  • 198.51.100.10ALLOWuptime monitor
  • 203.0.113.42DENYExpires in 24 hours

Block an IP

IPv4 address203.0.113.42
ExpiresNever1 hour24 hours7 days

Three engines you can switch off

TCP fingerprint, Signature (zero-day) and UDP first-packet challenge can be switched off on one rule when a legitimate client trips them; the rest cannot be switched off. Changes reach your server at its next configuration poll.

Read: Protocol validation
growth-sg / Firewall / Edit ruleTry itExample view
RuleUDP 30120 FiveM

  • TCP fingerprint

    Applies to TCP rules. No effect on this one.

  • Signature (zero-day)

    Learns the payload pattern of an in-progress attack and blocks it, without a rule being written first.

  • UDP first-packet challenge

    Under load, drops an unknown source's first packet. Real clients retransmit and get through; single-shot spoofed floods never do.

Backdoor sinkhole, for FiveM

With a FiveM rule on the server, the Backdoors tab gives you a hosts file of known backdoor callback domains to apply on your own machine. It matches names, not addresses, and Clouduxe does not inspect your outbound traffic.

Read: Backdoor sinkhole
growth-sg / Firewall / BackdoorsExample view
Download for Linux
# append to the system hosts file
sudo tee -a /etc/hosts < clouduxe-backdoor-hosts-linux.txt
# check it took effect
getent hosts 5mscripts.net

Recreated panel views. Addresses are from documentation ranges; ceilings are the documented preset values.

Afterwards, you can see what happened and why. Every drop has a reason, grouped into incidents you can read.

Attack analytics

The Attacks tab groups dropped packets into incidents: one attack, bounded in time, with every vector the attacker threw while it ran. A quiet gap ends one incident and starts the next. Open an ended incident for its sources, targeted ports and the checks that fired.

Read: Reading the Attacks tab
dash.clouduxe.com / growth-sg / AttacksExample view
growth-sg

Amplification on udp/53

Ended. Lasted 6 min 40 s. 11,420 sources.

AmplificationProtocol impostorPer-source flood
Peak received
2.4M pps
Peak dropped
2.3M pps
Peak traffic
38 Gbps
Removed upstream
94%
DroppedPassed, own scale

Why packets were dropped

  • Protocol validation61%
  • Whole-port ceiling24%
  • Per-source ceiling9%
  • Blocked source6%

Address lookup

Type in a user's address and get a straight answer: was it filtered, and by which protection. The counts are exact, not sampled, so "was not filtered" is a real answer too.

growth-sg / Attacks / Address lookupExample view

4 packets filtered across 1 attack window

ProtectionTargetPackets
protocolProtocol validationtcp/33893
per_source_ratePer-source ceilingtcp/33891

This address had completed a valid session, so some of these drops affected legitimate traffic. Worth reporting to support.

Discord alerts

Connect a webhook once and attack alerts post to your own channel: one when filtering starts, one when traffic is back to normal. One alert per attack, not one per minute.

Read: Notifications
Discord / #server-alertsExample view

  1. Clouduxe alerts app

    Attack being filtered

    203.0.113.40, udp/53. Filtering is automatic and already running.

  2. Clouduxe alerts app

    Traffic back to normal

    Lasted 6 min 40 s. The breakdown is on the Attacks tab.

These panels are recreated to show the layout. Every figure in them is an illustration, and every address is from a documentation range.

Checks for the protocols people actually run. Only a real client speaks the protocol, so a validator can tell.

Web and HTTP

Request floods, missing client identity and off-path requests

  • TCP 80
  • TCP 443
Request checks

DNS

Query and response validation

  • UDP 53
  • TCP 53
Validator

RDP

Remote Desktop

  • TCP 3389
  • UDP 3389
Validator

VPN

Common tunnel protocols

  • Per protocol
Validator

TeamSpeak

Voice, server query and file transfer

  • UDP 9987
  • TCP 10011
  • TCP 30033
Validator

Game servers

4 protocol families: FiveM, Minecraft, Source and rAthena. Other games by port presets.

See every game
  • FiveM
  • Minecraft
  • Source
  • rAthena

Protocol validation is switched on per port rule, for a service that has a validator. A port whose service has none still gets your rate limits, the full layer 3 and layer 4 filter and the behavioural engines, and we do not claim more than that for it. The HTTP card is exactly the three request checks listed on Attack types. The others are protocol validators,8 families in all.

Questions about the protection

Still unsure? Email contact@clouduxe.com. Support runs 24/7/365.

Is DDoS protection included with every server?

Yes. Every VPS, VDS and bare metal server in Mumbai, Singapore and Limburg sits behind the same upstream network and runs Clouduxe Prism on the host. There is nothing extra to buy.

How large an attack can you absorb?

The upstream network carries up to 17 Tbps of mitigation capacity. That figure is the same on every plan, because it is the same network in front of every server, and it is not metered or divided per customer.

Does DDoS protection add latency?

There is no scrubbing hop. Prism runs on the machine serving your traffic, so nothing is re-encapsulated or relayed through another city. Traffic that passes reaches your service the same way it would with no protection at all.

Will the filter block my real users?

Prism separates legitimate clients from attackers by protocol and behaviour, not by volume alone. If a real user is ever dropped, Address lookup on the Attacks tab names the exact check that dropped them, and that rule can be tuned.

Which protocols does the filter understand?

Protocol validators ship for DNS, RDP, common VPN protocols and TeamSpeak, and four more families cover game protocols, listed on the game servers page. For HTTP services, the filter catches request floods, requests with no client identity and requests to paths the service does not serve. A port whose service has no validator still gets the layer 3 and layer 4 filter, your rate limits and the behavioural engines.

Can I see the attacks against my server?

Yes. The Attacks tab groups what was dropped into incidents, with their sources, the ports they targeted and what the attack was made of. Attack alerts can also go to a Discord channel of your own.

Do I have to configure anything?

Upstream filtering needs nothing from you. On the host you choose which ports are open and how fast traffic may arrive on each, usually by applying the preset for your service and then fitting the limits to your own busy-hour traffic.

Does another customer being attacked affect my server?

No. Every server has its own filtering state and its own rules, so another customer's attack does not tighten anything on yours, and a rule you set never leaks outwards.

The long version is in the help center. Every setting, with the real field names the filter reads.

Attack types

The protection is already in the price.

Every plan in Mumbai, Singapore and Limburg includes the same 17 Tbps upstream and the same filter on the host, with 25 named detections across 6 attack classes.

See plans and pricesTalk to us