DDoS Defence by Bottleneck: A Practical Guide for Websites and Game Servers

Reviewed: 31 August 2026 · Next review: 28 February 2027
Author: Ozlin Info Editorial Team · Human review: Lin

A DDoS plan is only useful when it names the resource that is expected to fail first. “We have a firewall” does not answer whether an incident will fill the upstream link, exhaust packet forwarding, consume connection state, overload a query parser or make the application perform too much work.

This guide offers a defensive planning model for public websites, Java multiplayer services and Valve-family dedicated-server queries. It avoids universal thresholds and packet recipes. The goal is to help owners ask better questions, place controls in the right part of the path and define a degraded mode before an incident.

No single control guarantees availability. Capacity, provider routing, protocol support, application design and incident response all matter. Validate any design against your provider, software versions, traffic patterns and risk appetite.

Start with the bottleneck, not the attack name

Use more than one traffic measure. Each describes a different kind of pressure:

Measure	What it represents	Typical failure point
bps / Gbps	Bits carried per second	Internet circuit, transit or scrubbing capacity
pps / Mpps	Packets processed per second; Mpps means millions of packets per second	Router, NIC, virtual switch, ACL or kernel packet path
CPS	New connections per second	SYN handling, state tables, TLS handshakes or accept queues
Concurrent connections	Connections held open at once	Memory, descriptors, proxy workers or load-balancer state
RPS	HTTP requests per second	Reverse proxy, application, cache or database
QPS	Protocol queries per second	DNS or game-query parsing and response work

“Bpps” can mean billions of packets per second in some network discussions, but the notation is easy to confuse with bits per second. Write out the unit in procurement and incident records.

Average packet size can be estimated for context as bits per second ÷ (8 × packets per second). For example, 100 Gbps divided by 100 million packets per second is about 125 bytes per packet. That is illustrative arithmetic, not an attack fingerprint or a sizing promise.

Five useful pressure classes

1. Volumetric pressure consumes link capacity. If the link is full before traffic reaches your server, a host firewall behind that link cannot restore the lost bandwidth. Mitigation must happen upstream, such as at the provider edge, an anycast network or a scrubbing service.
2. Packet-rate pressure uses many small packets to exhaust packet handling before bandwidth looks full. Ask providers about packet rate as well as Gbps.
3. Connection or state pressure targets new-connection handling or retained state. SYN defences, connection proxies and careful timeout policies help, but must be placed where they can still receive traffic.
4. Protocol-query pressure repeatedly invokes a public protocol function, such as a status or server-browser query. It needs protocol-aware validation and budgets, not only generic port filtering.
5. Application-resource pressure makes apparently valid requests consume CPU, database, cache, search, authentication or external-service capacity. This is commonly called application-layer or Layer 7 DDoS. “CC attack” is an informal term often used for HTTP request floods; it is not a standards-defined category.

RFC 4732 explains why Internet denial-of-service defence is a system problem rather than a single appliance feature. BCP 38 / RFC 2827 and its update, RFC 3704, describe source-address filtering that can reduce spoofed traffic near its source. They do not stop attacks sent from valid source addresses.

Websites: defend the whole request path

A useful website pattern is:

upstream or anycast edge → HTTP DDoS controls → validation and WAF → cache → reverse proxy → bounded application and queue → origin data stores

• Upstream or edge capacity absorbs traffic before the origin link becomes the bottleneck.
• Request validation and WAF rules reject traffic that violates known application behaviour.
• Caching prevents repeated public reads from becoming repeated origin work.
• Path-specific budgets recognise that a cached article, a login, a search and a large export have very different costs.
• Queues and back-pressure keep a burst from turning into uncontrolled work.
• Graceful degradation preserves essential pages while temporarily disabling expensive search, exports, previews or third-party calls.

Conceal and constrain the origin

An HTTP reverse proxy is bypassable if the origin address remains reachable. Cloudflare’s own guidance recommends proxying appropriate DNS records, auditing DNS-only records for origin exposure, restricting origin access and rotating an address that has previously been exposed. Those are Cloudflare-specific operational recommendations; equivalent controls differ by provider.

Do not assume that an ordinary HTTP CDN or proxied DNS record protects arbitrary raw game protocols. Cloudflare documents that proxied DNS covers specific HTTP/HTTPS ports, while other TCP/UDP services need a protocol-specific product or upstream service. Confirm the clean traffic path before changing DNS.

Rate limits need context

Per-address limits are simple, but mobile carriers, offices, universities and households may share public addresses through NAT or CGNAT. A rigid source-IP threshold can punish legitimate users. Combine signals where the platform permits it: path, method, session, authenticated identity, token, device evidence, request cost and behaviour over time. Maintain a documented false-positive appeal or bypass process.

Cloudflare recommends combining managed DDoS controls, custom WAF rules, rate limits, origin protection and caching. Treat that as vendor guidance, then test it against your actual application and plan level. Rate limits are especially useful when they describe the expensive route they protect rather than applying one blanket number to every request.

Java multiplayer services: separate status, login and play

• Status discovery supports server-list visibility and should be lightweight and observable.
• Login and authentication create new connection, cryptographic and identity work.
• Join and initialisation load player data, plugins, worlds or resource checks.
• Ongoing play produces long-lived, stateful traffic with game-specific packet handling.

A protocol-aware edge can distinguish these stages and protect a proxy tier. A common architecture is a protected public edge, a Velocity proxy and isolated backend servers that accept connections only from the trusted proxy path.

PaperMC’s current Velocity security documentation strongly recommends a firewall for backend isolation. It also warns that Velocity modern forwarding is a second layer of protection, not a replacement for a firewall. Keep the proxy and backend software updated, restrict backend reachability and review plugins because application-level abuse can still consume server work after network traffic is accepted.

Do not copy a universal join-rate or packet threshold from a blog. Establish a legitimate baseline, test player experience, change one control at a time and keep an emergency rollback. A protection provider should be able to explain whether it understands the game protocol or merely forwards a protected generic TCP stream.

Valve-family server queries: challenge spoofing, then budget real sources

Valve-family dedicated servers expose discovery information through A2S query types commonly known as A2S_INFO, A2S_PLAYER and A2S_RULES. These queries are useful to players and server browsers, but unauthenticated UDP responses can contribute to reflection risk when source addresses are spoofed. High query rates from real sources can also consume packet and protocol-processing capacity.

Valve developer communication describes an A2S challenge exchange that lets a server ask a client to return a challenge before an information response, helping demonstrate that the requester can receive traffic at the claimed source. That can reduce spoofed reflection. It cannot prove that a real-source bot is benign, and it does not create infinite query capacity.

• current server software and protocol support;
• challenge validation where compatible;
• protocol-aware filtering before expensive parsing;
• separate budgets and observability for information, player and rules queries;
• aggregate and source-aware controls that do not rely on one address threshold alone;
• an incident mode that preserves the minimum discovery response needed for legitimate clients, if the game and provider support it.

The Steamworks game-server overview explains the role of game-server discovery and connection. The challenge details above are based on a Valve developer-authored Steam Community announcement, not an RFC; compatibility and defaults can change, so verify them against the current game build and hosting provider.

What to ask a DDoS provider

• What clean and attack capacity is stated in Gbps and packets per second?
• How are new connections, simultaneous state and protocol queries handled?
• Which of our actual protocols are parsed, proxied or merely forwarded?
• Is mitigation always on or triggered on demand, and what is the expected time to mitigate?
• Where does clean traffic re-enter our network, and what latency or MTU changes should we expect?
• What traffic and mitigation telemetry can we access during and after an event?
• What is the escalation path, including after-hours response?
• How are legitimate-traffic drops investigated and corrected?
• Which features, traffic volumes, logs, support levels or data transfers add cost?
• What happens if the origin address is exposed or attacked directly?

OVHcloud’s Network Security Dashboard documentation is a useful example of provider-side visibility: it describes per-address events, attack-vector labels, bps/pps charts, clean and dropped traffic, and escalation data. Those fields describe one provider’s service, not a universal capability. Record what your selected provider actually offers.

A compact incident and degradation runbook

1. Declare and timestamp. Nominate an incident lead, start a record and preserve provider alerts and dashboards.
2. Classify the bottleneck. Compare link utilisation, pps, new connections, concurrent state, request/query rates, latency, errors, queue depth and host saturation.
3. Protect the management path. Keep administrative access separate where practical; avoid making emergency changes through the affected public service.
4. Escalate upstream early. If the link or provider edge is the bottleneck, contact the network or mitigation provider with destination, protocol, time window, customer impact and evidence.
5. Apply the smallest prepared control. Use reviewed edge rules, path budgets or protocol policies. Record the owner, timestamp and rollback.
6. Degrade intentionally. Serve cached or static content, pause expensive routes, reduce optional query detail or limit new joins while preserving existing sessions where feasible.
7. Watch legitimate traffic. Sample successful user journeys, geographic reachability, authentication and game-session health. Roll back a control that causes disproportionate harm.
8. Recover and review. Remove temporary controls carefully, retain evidence according to policy, document false positives and update the capacity model.

Monitoring signals worth keeping together

• provider and interface bps/pps;
• packet drops and NIC, virtual-switch or kernel saturation;
• SYN rate, accepted connections, resets, timeouts and connection occupancy;
• edge, cache and origin request rates plus cache-hit ratio;
• application latency, error rate, worker saturation, queue depth and database pressure;
• status, login, join, play and query-path health for game services;
• clean-traffic delivery, mitigation start/stop times and false positives;
• customer-impact signals such as successful page journeys or completed joins.

Alerts should identify the suspected bottleneck and a human owner, not merely announce “high traffic”.

Limits of this guide

This is general educational information, not a guarantee, penetration-test instruction or substitute for provider engineering. It does not prescribe universal capacity, thresholds or packet filters. Service architecture, versions, jurisdiction, budget and acceptable user impact can change the correct design. Test controls in an authorised environment, maintain rollback and confirm contractual limits directly with suppliers.

Plan the failure path before buying capacity

DDoS resilience improves when owners can answer three questions: what resource fails first, who can act before that point, and what essential service remains during degradation? That model turns product names into testable requirements and makes incident decisions faster.

If you need a bounded review of public exposure, dependencies, monitoring and recovery priorities, see Ozlin Info’s Cybersecurity Risk Advisory or contact us. Related reading: Incident Response and Disaster Recovery Planning and Home Broadband Server Hosting Risks in Australia.

---

Sources and review note

Material technical claims were checked on 31 August 2026 against the RFC Editor, Cloudflare documentation, PaperMC Velocity documentation, Steamworks documentation, a labelled Valve developer communication and OVHcloud documentation. Product behaviour and documentation can change; next scheduled review is 28 February 2027.

AI disclosure: AI assisted with source discovery, drafting, copyediting and the original editorial illustrations; Ozlin Info reviewed the final article and remains responsible for publication.