Before you start
List public addresses, ports and protocols used by gameplay, websites, files, voice and administration. Identify the origin, proxies and databases. Specify services that must remain public and access that should be restricted. Keep a known networking configuration and a rollback method before changing routes or restrictions.
Understand the layers without oversimplifying
L3 concerns the network layer, including IP forwarding. L4 concerns transport protocols such as TCP and UDP and their exchanges. L7 processing uses the behaviour of an application or application protocol. These layers can work together within a protection architecture.
An attack may try to fill a link, exhaust connection state or consume application work. Several effects can happen together. Identify the threatened resource and affected traffic before choosing upstream filtering, connection controls or application rules.
Read advertised capacities and limits
The aggregate capacity of an operator or mitigation locations is not bandwidth reserved for one server. Ask what the figure measures: aggregate volume, one site, port speed or a contractual limit. Bandwidth, packets and requests describe different constraints.
Also check permitted clean traffic, covered protocols, protected addresses and intervention terms. Protection can have coverage limits or containment measures. An unlimited claim does not replace technical conditions and a contract.
Establish what L7 means for your game
HTTP protection addresses HTTP exchanges. It does not automatically replace protection for Minecraft’s protocol, UDP gameplay or voice services. For each application, ask which component is inspected, which connections terminate at a proxy and which traffic travels directly.
FiveM demonstrates the distinction: the HTTP entry point, downloads and gameplay need a coherent architecture. A protected website can remain available while the game fails. An L7 capability should describe its actual scope rather than claim to cover every application.
Avoid routes that bypass protection
Remote protection helps only when covered traffic passes through it. Inventory old addresses, DNS records, secondary services and advertised endpoints. A directly reachable origin can let traffic bypass the protected entry point.
Restricting an origin requires understanding legitimate sources and services. Validate routes, return traffic, voice, files and administration before filtering. An excessively broad allowlist exposes the origin; an overly narrow one can cause an outage. Do not copy a generic rule without understanding the architecture.
Assess stability during and after an incident
Compare measurements before, during and after an incident: service latency, observed loss, successful connections and application response time. ICMP measurements or a TCP test of the website alone do not validate a game protocol. Prefer normal connections from your users’ networks.
Request timestamped events and a filtering explanation when legitimate connections fail. Distinguish false positives, routing detours and application load. An uncoordinated load test can degrade the service itself; arrange active validation with the provider and precise limits.
Choose using a documented scope
Prepare a short specification covering services, protocols, addresses, origin location, normal traffic and maintenance constraints. Establish setup, responsibilities, available statistics and escalation steps. For remote protection, include tunnel, proxy or routing requirements.
Then compare available plans and pricing for the requested scope. A useful choice combines network capacity, protocol-aware handling and the ability to diagnose incidents. No protection system removes the need to maintain software, accounts and backups.
For your situation
| Situation | Next check |
|---|---|
| Link or packet saturation | Assess upstream filtering and traffic limits. Confirm coverage for the affected address and protocol. |
| Application exhaustion | Identify requests and expensive operations. Request protocol-appropriate protection and correct application weaknesses. |
| Remote protection | Verify the traffic path, return route and exposed origin. Document secondary services before restricting access. |
Official sources
These documents describe the relevant protocols and software. Your service terms and configuration still need to be checked.