FiveM Anti Crasher: How to Stop Crashers on Your Server
Stop FiveM crashers with layered defence: documented server convars that shrink the crash surface, server-side validation, and detection that names who did it.
Roby Einstein
FairShieldAC Security Team
Someone in your session is dropping your players. A working FiveM anti crasher setup is three layers in this order: platform hardening with the documented convars that shrink the crash surface, server-side validation of what you agree to route, and detection that attributes the attempt to a player. An anti-cheat bolted onto an unvalidated server is the weakest version of that, and nothing here makes a client uncrashable.
Rule out two things first. If your own game crashes when you join servers, that is client troubleshooting. If nobody can reach your server while the process is healthy, you have a network flood - read what to do during a FiveM DDoS attack instead.
Background, then the defence. A FiveM crasher is an in-session action, commonly delivered through a modified client, that makes other players' clients or the server process fail or freeze. If you need the threat side - the vector classes, why they get used and how to recognise one in progress - what a FiveM crasher is covers it, and this page starts where that one ends. A Lua executor is one delivery route.
This page publishes no payloads, hashes, argument shapes or reproduction steps. Pages that do are arming the people crashing you.
Crasher or DDoS? Diagnose before you change one convar
A DDoS saturates your link from outside and makes the server unreachable to everyone, you included. A crasher is an in-session action by an authenticated, connected player, and the server usually stays reachable while people fall out of it. Three outcomes look identical in a panicked Discord message.
| What you see | What it usually points at | First evidence to collect |
|---|---|---|
| Players drop together, the server process stays up and reachable | A client-side crash class inside the session | Client crash dumps from affected players, plus the connection log for who was in session |
| The FXServer process dies or hangs, console closes | A server-side failure - abuse, or a faulty resource | A full server dump, plus console output from the seconds before |
| Nobody can connect but the process is healthy | A network or HTTP flood, not an in-session crasher | Upstream traffic graphs and concurrent connection counts |
| Crashes track one player's presence in the session | The attribution question | Per-player join and leave timestamps correlated against each crash |
One caveat: crash dumps do not always produce a consistent signature across affected clients. The warning signs of a cheater still apply.
Platform hardening: the documented convars that shrink the crash surface
Start here: this layer is enforced by the server binary and costs only compatibility testing. Read the server commands documentation closely and most of this family ships permissive, because Cfx cannot break existing servers by changing a default. A stock server.cfg leaves the widest surface open.
- sv_entityLockdown - default inactive, the most permissive mode. Valid modes: full, strict, relaxed, inactive.
- sv_filterRequestControl - default 0, which the docs label Off. Modes run -1 through 4.
- sv_enableNetworkedSounds - true by default, and true means allow routing.
- sv_enableNetworkedScriptEntityStates - also true by default, from server version 8540.
- sv_enableNetworkedPhoneExplosions - disabled by default, already safe, from version 6831.
- setr sv_stateBagStrictMode - default false, from version 12739. Note the replicated setr prefix.
Correct the most copy-pasted line first: sv_entityLockdown true is not valid, yet owners paste it and believe they are protected. Docs define strict as "No entities can be created by clients" and relaxed as "Only script-owned entities created by clients are blocked". Strict also breaks any resource spawning entities client-side, so relaxed is the migration step and strict is usually a refactor rather than a config flip.
sv_filterRequestControl blocks REQUEST_CONTROL_EVENT routing on a policy, and defaults to off. Mode 1 blocks control requests to player-controlled entities (currently occupied vehicles only) older than sv_filterRequestControlSettleTimer, default 30000 milliseconds; 2 covers all player-controlled entities; 3 adds settled non-player entities; 4 never routes the event. The timer applies only to modes 1 and 3, so setting it while leaving the mode at its default changes nothing.
Two convars switch off routing for net game events that Cfx's docs call "commonly used by malicious actors": sv_enableNetworkedSounds covers NETWORK_PLAY_SOUND_EVENT, sv_enableNetworkedScriptEntityStates covers SCRIPT_ENTITY_STATE_CHANGE_EVENT. Both default to true, so you harden by setting them false. Guides filing these under performance tuning teach the wrong mental model: an owner who thinks it is an optimisation reverts it the moment a script misbehaves.
sv_enableNetworkedPhoneExplosions is the reverse case, already disabled, so the job is auditing that nobody enabled REQUEST_PHONE_EXPLOSION_EVENT routing and left it on. Meanwhile setr sv_stateBagStrictMode true moves state writes on replicated entities to the server only. It carries the family's highest compatibility cost: plenty of framework and inventory code writes state bags client-side and will error until refactored.
If strict lockdown is too expensive server-wide, apply lockdown modes per routing bucket: SetRoutingBucketEntityLockdownMode takes strict, relaxed or inactive, so a suspect player gets strict lockdown without imposing it on everyone. Three of these carry minimum server builds, so a stale artifact makes the block a no-op - check which build to run and take the rest from the hardening checklist.
Server-side validation: your code decides what the server agrees to route
A server that validates what it is asked to route cannot be made to route an abusive volume of it. That is our inference from Cfx guidance, not a claim they make about crashes - their Secure Your Events page never mentions crashers. It still warns that "Cheats can allow the client to trigger events in any context".
The platform also hands you a cancellable interception point. Per the server events reference, the server-side entityCreating event "can be canceled to instantly delete the entity". The hook is free; the policy inside it is your code. Cfx's caveat stands - server-event checks help, "although it doesn't prevent everything". How to stop a Lua executor owns this argument at code depth.
Detection and response: attribution is the part that decides your week
Detection sits on top of the other two layers. Its output is a name attached to a timestamp. A crash wave with no per-player attribution leaves you unable to ban, report, or tell whether the same person returned on a fresh identity. Cfx's own debugging documentation starts with dumps and logs, so collect them before you ask for help. With a name, the cheater report workflow covers evidence and the ban decision.
- Per-player join and leave timestamps with identifiers. Without them a timestamped crash correlates to nobody.
- Rate and pattern anomaly logging - bursts of entity creation, event triggers or explosion activity traced to one source. txAdmin already logs connections, disconnections, kills, chat and explosions.
- Dump capture, if you run Windows. Cfx document a ProcDump full-dump procedure, Windows-only and not currently supported on Linux. It catches hangs as well as crashes.
- Automatic recovery. txAdmin documents auto-restarting FXServer on crash or hang. Shortens the outage from an evening to a restart cycle. It prevents nothing and shortens the outage.
- Identity quality at connect, because attribution is worthless if identities are cheap to rotate.
What each anti crasher layer stops - and what it costs you
Read the last column first: copy-paste config lists never print it.
| Layer | What it stops | What it costs you | Where it stops helping |
|---|---|---|---|
| Entity lockdown (sv_entityLockdown, global or per routing bucket) | Client-created entity spam | Strict breaks resources that spawn entities client-side; usually a refactor to server-side creation | Anything that does not depend on client-side entity creation |
| Control-request filtering (sv_filterRequestControl plus settle timer) | Hostile ownership takeover of player-controlled entities | Escalates fast; mode 4 affects towing, pushing, garage and admin tooling | Vectors that never request control of anything |
| Event-routing convars (networked sounds, script entity states, phone explosions) | Server routing of the specific net game events those convars name | A resource audit; some siren, radio, notification and state-dependent resources break | Any vector using an event with no convar switch behind it |
| State bag strict mode (setr sv_stateBagStrictMode true) | Client-written state on replicated entities | Highest compatibility cost of the family; many frameworks write state client-side and error until refactored | Server-written state, and client-side non-replicated entities, which the docs exclude |
| Server-side validation (entityCreating, event checks per Cfx guidance) | The volume and shape of what you agree to route | Engineering time; Cfx's own caveat is that it doesn't prevent everything | Vectors that never touch your resource code |
| Running a current server build | Vector classes already patched upstream | A maintenance window and a rollback plan | Anything not yet patched, which is by definition what hits you |
| Detection and enforcement | Nothing structurally - it attributes the attempt and acts on it | Operational overhead, tuning, and the possibility of a false positive | A novel vector it has never seen |
| Recovery (dumps, auto-restart on crash or hang) | Nothing - it shortens the outage | Dump capture is Windows-only per Cfx docs | Prevention; this is the last layer to reach for |
Where FairShieldAC fits
Being precise about our own product: FairShieldAC's public changelog records "Added Anti Crasher modules" in the release dated 10 July 2026. The same changelog names related modules - Anti Trigger detection, Anti Vehicle Spawn, Anti Explosion Spam, Anti Weapon Spawner, Anti Chat Exploit, Anti InputBox and anti threads stop. Names and dates are what is published, so that is all we claim: no internals, no effectiveness figure.
The framing, plainly. Platform convars are structural limits the server enforces. Validation is your code. Detection sits on top and adds attribution and enforcement; it cannot retroactively validate your event handlers. The ordering argument is the same one we make about Gravity DDoS protection, which is a separate problem entirely.
Honest limits of any FiveM crash protection
No configuration makes a client uncrashable. A determined attacker holding a vector nobody has seen will land it, and the platform patches upstream on its own schedule - specific issues are often already fixed upstream before owners notice. Running a current build is a real mitigation, and free. Cfx say the quiet part themselves: "The anti-cheat team is always trying to improve the anti-cheat, but sometimes things slip through."
So set the goal honestly. You are reducing surface, attributing the attempt, and recovering fast. A server doing all three loses ten minutes and comes out with a name.
FiveM anti crasher: common questions
Does sv_entityLockdown stop crashers?
It removes one structural class, entities created by clients, and leaves the others untouched. Documented values are full, strict, relaxed and inactive; the default is inactive. sv_entityLockdown true is not one of the four documented modes, so it does not give you the protection owners assume. Note that full is documented as usable only on FiveM for GTAV Enhanced. Expect strict to break resources spawning entities client-side, so use relaxed as the migration step.
Is an anti fivem crasher script enough on its own?
No. A detection layer adds attribution and enforcement on top of your server; it cannot retroactively validate your event handlers or change what the platform will route. Harden the documented convars, validate your own events, then add detection. In the opposite order it covers less ground.
Which convar should I set first?
sv_enableNetworkedSounds false and sv_enableNetworkedScriptEntityStates false are the cheapest first move: both ship true, both switch off routing for net game events Cfx's own docs call commonly used by malicious actors, and the blast radius is a resource audit rather than a refactor. Leave setr sv_stateBagStrictMode last - it carries the highest compatibility cost of the family, and it needs a current server build to do anything at all.
How do I find out who crashed my server?
Correlate a timestamped crash against per-player join and leave records, and keep dumps. On Windows, Cfx document a ProcDump full-dump procedure; on Linux that method is not currently supported. Without per-player attribution you are left with an outage and no defensible ban.
Next step, tonight: open server.cfg and read what those six convars are actually set to, because on a stock config the answer is almost certainly the permissive default. Then pick the lowest-cost one for your resource list and test it on staging. When you want the attribution layer on top, our plans are on the homepage. Otherwise start with the hardening checklist, the console commands reference, and how to vet a script.