A FiveM server is a live session with an audience. Attacking it produces something an attacker can watch happen, which is exactly why roleplay communities see more of this than a static site of the same size ever would. The traffic arrives, players start timing out, and your Discord does the rest.
The framework’s shape is also part of the problem. FiveM runs its session traffic over UDP, and UDP has no handshake at the transport layer that a network device can lean on to tell a real client from a crafted packet. Something has to understand Cfx.re specifically to make that call.
Every packet aimed at our range crosses the scrubbing layer before it reaches a customer machine, and on Shield that happens continuously rather than after a trigger. For FiveM the relevant piece is the Cfx.re profile: it validates the framework’s own handshake, so a session that cannot complete one correctly is dropped at the edge instead of being carried to your server and dealt with there.
That covers the two things people report most often, spoofed sessions and connection floods aimed at filling your slots. It runs as an XDP program at the edge, which is why the cost of dropping a packet stays roughly flat as the attack grows.
Three modes exist for this profile: standard, experimental, and strict deep-packet inspection. Standard is the default and the right starting point. Strict earns its place when something is still getting through, at the cost of less headroom for unusual traffic.
Being specific about the limits is more useful than a capacity number.
Your server browser listing is Steam query traffic, and reflection abuse aimed at it is a separate profile rather than part of the Cfx.re one. Both are included on Shield, they are just different filters doing different jobs.
Nothing at the network layer helps with an application problem. A resource that leaks memory, a script that blocks the main thread, or a server that falls over at 200 players will fall over the same way with perfect filtering in front of it. Attack traffic and a bad tick are different failures that feel identical to a player, and it is worth knowing which one you have before buying anything.
Our filtering and our machines are both in the Frankfurt metro, so for players across Germany, Austria, the Netherlands and Poland the packets are not making a detour to be cleaned. If your community is mostly North American, a European host is the wrong answer no matter how good the mitigation is.
Slot count is the number people size on and it is the wrong one. What fills memory on a FiveM server is the resource stack: custom MLOs, streamed vehicles and the assets a roleplay build accumulates. Two servers with the same thirty-two slots can differ by several gigabytes on the strength of what they stream, so count your resources before you count your players.
Cores matter less than the clock they run at. The main thread is where your scripts execute, and a resource that blocks it stalls the server regardless of how many cores are sitting idle next to it. Extra cores are for the database and the asset HTTP server, not for the tick.
shield plans
Pricing in EUR · 20% Austrian VAT for AT consumers · Reverse charge for EU B2B
Cfx.re publishes no server hardware requirement. Its setup documentation lists software prerequisites and stops there, so the two tiers below are our recommendation rather than a vendor specification, and we would rather label them that way than dress them up as official.
A development server, or a private group on a light resource stack.
A live ESX or QBCore server with custom MLOs and vehicles.
A large community on a heavy streamed asset library.
Every tier carries the same always-on filtering and the same 25 Gbps uplink, so the choice above is about compute, not about protection.
No. The profile validates the shape of the Cfx.re handshake, it does not inspect or rewrite what your resources send afterwards. Asset downloads on your HTTP port and anything your scripts talk to are separate services and are covered by the baseline anti-spoofing rather than the game profile.
Standard validates the handshake and drops what fails. Strict deep-packet inspection applies tighter checks on the session traffic that follows, which catches more but leaves less headroom for anything unusual your server does. We start customers on standard and move to strict only when an attack is getting through, because the stricter profile is the one more likely to catch a legitimate player.
It is possible. Automated classification works on thresholds and traffic patterns, and our terms say plainly that legitimate traffic with unusual shape can be misclassified. In practice the profile is tuned around the framework handshake rather than gameplay traffic, so client mods are rarely the thing that trips it. If you see false drops, tell support and the sensitivity can be adjusted within limits.
For a roleplay server with players connected, Shield. On the Standard line filtering is reactive, and the roughly five second window before it engages is long enough to disconnect everyone on the box at once. An attacker only has to repeat that. Reactive protection is fine for a website and wrong for a session-based game server.
The filtering runs as an XDP program at our own edge in the Frankfurt metro, not in a scrubbing centre in another country, so packets are not detoured before they reach you. The cost of the classification itself is small enough to sit inside normal jitter. Distance is what players actually feel, which is why where the filtering happens matters more than that it happens.
Yes, and that is the common case for a new Shield order. Because the filtering is always on rather than triggered, there is nothing to activate once you are running on a Shield IP. The part that takes time is moving your server and telling your players the new address.
