FiveM Anticheat and Fake Players: Compatibility Guide

Anticheat compatibility is the most technically loaded question operators ask about our FiveM fake players service. This post provides a detailed explanation of what compatibility means for each anticheat system, which detection surfaces each system uses, and how the fake player connections that fill out your server population look to each scanner.

We cover four anticheat systems you are likely running on your FiveM server: FiveGuard, Electron, Waveshield, and Reaper. For each system, we describe what it scans at the connection level based on publicly observable behavior, how fake player connections appear to each scanner, and what configuration adjustments prevent false positives. We will be explicit about what we have tested and where our knowledge ends.

This documentation matters because the stakes are real. A misconfigured fake player session that triggers false kicks from your anticheat causes visible player count drops in the server browser, creates noise in your anticheat logs, and wastes the budget you are spending on fake players. Getting the configuration right from the start avoids all of that.

How Fake Player Connections Differ From Real Player Connections

Before covering each anticheat system, it helps to understand what a fake player connection actually looks like at the network level compared to a real game client connection. Understanding this distinction is the foundation for understanding why some detection surfaces apply and others do not.

A real FiveM client establishes a connection through the FiveM game client software running on the player's machine. The client presents a valid CFX license, downloads and loads the server's resource manifest, initializes the game state, and generates traffic patterns associated with the game's networking protocol including movement updates, entity state packets, and other in-session communication. A real client also has process-level presence on the player's machine: a running executable, loaded DLLs, active memory allocations.

A fake player connection is a lightweight network connection that satisfies the server's connection handshake protocol without running the full game client. The connection maintains presence in the server's player list, contributes to the player count the CFX API reports, and appears in txAdmin's connection log as a connected player. There is no game client process running on a machine. There are no DLLs loaded. There is no game state being processed.

This distinction is directly relevant to anticheat compatibility. Anticheat systems that scan client-side processes, DLLs, and memory cannot see fake players in the sense of scanning them, because there is no client process to scan. Anticheat systems that operate at the connection handshake or traffic pattern level can observe fake player connections and may have detection logic that applies. The question is whether that logic is tuned to flag the patterns fake player connections produce.

FiveGuard: The Most Common System in the Market

FiveGuard is the most widely deployed anticheat system across the FiveM server ecosystem as of May 2026. It is the system cited most frequently in operator questions about fake player compatibility, partly because it is so common and partly because operators want to confirm that fake player connections appear correctly in the FiveGuard operator panel.

FiveGuard operates across both client-side and server-side detection surfaces. Understanding which of these surfaces applies to fake player connections is the core of the compatibility question.

On the client side, FiveGuard scans for modified DLLs, injected processes, and memory manipulation patterns that indicate a cheating client is running. Fake players have no client-side process. There is nothing for FiveGuard's client module to scan on the fake player side because no game client is running on any machine for that connection. Client-side scanning is simply not a relevant surface for fake player compatibility analysis.

On the server and connection side, FiveGuard can observe connection metadata, traffic patterns, and player behavior during a session. This is where compatibility work is relevant. Our fake player implementation produces traffic patterns that are consistent with a connected but idle player rather than the patterns associated with automated bots, connection flooding tools, or other adversarial connection patterns that FiveGuard is designed to detect.

• Client-side DLL scanning: not applicable, no client process exists for the fake player connection
• Process injection detection: not applicable, no client process on any machine
• Connection metadata checks: our implementation passes standard handshake validation
• Traffic pattern analysis: our connections produce idle-player-consistent patterns
• Operator panel visibility: fake players appear in the FiveGuard player list as expected
• Behavioral detection during session: no in-game movement or action events generated

Electron: Hardware Identity and Session Integrity

Electron is a FiveM anticheat system with a strong emphasis on hardware identity verification and client integrity. It is designed to associate player session identities with hardware fingerprints, making ban evasion significantly harder for real cheaters who attempt to circumvent bans by creating new accounts.

For fake player compatibility, the client-side and server-side distinction applies again. Electron's hardware fingerprinting system, HWID ban enforcement, and client process integrity checking all operate on the game client machine. Fake players do not have a client machine in the sense Electron's scanning assumes. The hardware fingerprinting surface does not apply.

Electron also includes server-side session monitoring that watches for connection behavior patterns that look anomalous relative to normal player sessions. This is where our implementation work matters. Our fake player connections are configured to produce session-level behavior consistent with a connected but inactive player, not the behavioral signatures associated with the attack patterns Electron's anomaly detection targets.

One specific configuration concern with Electron: some server configurations include idle-player timeout rules that kick players who have been connected without generating movement or gameplay events for a defined period. Fake players do not generate movement events by default. If your Electron configuration has a strict idle timeout, you may see fake players kicked after the timeout window expires rather than by detection logic.

Waveshield: Network Traffic and Connection Rate Analysis

Waveshield operates primarily at the network and traffic level. It is designed to protect game servers against DDoS attacks, connection floods, and traffic anomalies. Unlike FiveGuard and Electron, Waveshield's primary mission is network protection rather than in-session cheat detection. Its relevance to fake player compatibility comes from its connection pattern analysis.

Because Waveshield analyzes connection patterns as a proxy for attack traffic, fake player connections need to be indistinguishable from normal player connections at the network protocol level. A set of fake players connecting simultaneously in a short window can look like a connection burst or a soft-flood attempt to Waveshield's rate limiting logic, especially if the connections share IP address patterns that Waveshield associates with automated traffic.

Our testing confirms that Waveshield-protected servers can run fake players without triggering flood detection when the connection rate is managed correctly. The key operational detail is gradual connection ramp-up rather than simultaneous connection of all fake players.

Our infrastructure distributes fake player connections across multiple egress addresses in multiple regions. This prevents the connection source from looking like a single-origin burst to Waveshield's pattern analysis. A 30-player session connecting gradually from distributed addresses over several minutes looks like 30 real players joining through normal browser discovery, which is exactly what it is meant to simulate.

1. Start fake player connections gradually, not all at once. Allow connections to spread over 5 to 10 minutes.
2. Allow each connection batch to stabilize before adding the next group.
3. Do not restart the fake player session repeatedly in short intervals during the same operating window.
4. If Waveshield kicks connections, reduce the connection rate per minute and retest.
5. Check whether your Waveshield configuration includes a per-IP or per-subnet connection rate limit that could group our connections despite their distributed nature.
6. Contact our support channel with your Waveshield version and configuration details if basic adjustments do not resolve kicks.

Reaper: Behavior-Based In-Session Detection

Reaper takes a behavior-based approach to anticheat that differs significantly from the network-level analysis of Waveshield and the hardware identity focus of Electron. Rather than relying on signature matching or connection rate analysis, Reaper monitors in-session player behavior for patterns associated with cheating: movement that exceeds physics limits, impossible position changes between ticks, scripted action sequences that no human could execute, and similar behavioral fingerprints.

Fake players are idle connections with no in-game behavior. They do not move. They do not fire weapons. They do not generate collision events or interact with game world entities. This places them entirely outside the behavioral profile that Reaper's detection logic monitors. A fake player that produces zero in-session behavioral events does not produce the signatures that trigger Reaper's detection.

Our testing is consistent with how behavior-based anticheat operates in this context: systems that target active cheating behavior in-session do not flag players who are connected but not generating gameplay events. The detection surface simply does not apply to the behavioral profile of a fake player connection.

txAdmin Native Scanning and Operator Panel Visibility

txAdmin itself includes server-side monitoring and player management tools. Fake players appear in txAdmin's connected player list as expected. They display with the names you have configured, they show connection duration, and they persist in the list for the duration of the session. The txAdmin native integration means fake players are indistinguishable from real players in the player management panel.

txAdmin does not have a dedicated detection mechanism for fake player connections as a category distinct from real players. When we say our service has native txAdmin integration, we mean that the connections are established in a way that the txAdmin player monitoring system recognizes as valid player sessions rather than malformed connections or unknown connection types.

One operational note: txAdmin's player kick and ban tools operate on player identifiers that the fake player connections present. If an admin accidentally kicks or bans a fake player connection through the txAdmin panel, the behavior depends on your fake player configuration. Most providers including us will reconnect kicked fake players automatically within the next connection cycle. If you see fake player counts fluctuating, check your txAdmin action log for accidental kicks.

Configuration Steps Before Deploying With Any Anticheat

Regardless of which anticheat you are running, the configuration principles that support compatibility are consistent across all of them. Running through these steps before your first fake player deployment with a new anticheat version reduces the probability of unexpected kicks and the debugging time that follows.

1. Document your current anticheat name and version number before testing. Version matters when you need to report a compatibility issue.
2. Start with the minimum player count, 15 players, rather than your full target count for the initial test session.
3. Ramp connections gradually over 5 to 10 minutes rather than connecting all players simultaneously.
4. Monitor your anticheat panel and your txAdmin player log for kick or ban events in the first 30 minutes.
5. Check txAdmin's player list to confirm fake players appear as named, connected players.
6. If kicks occur, note the timing and frequency. Consistent timing suggests an idle timeout. Random timing suggests a rate or pattern issue.
7. If you see unexpected behavior with a specific anticheat version, contact our support channel with the anticheat name, version, and the specific behavior you are observing.

What We Cannot Promise About Anticheat Compatibility

We will not claim our fake player implementation is permanently compatible with every version of every anticheat system indefinitely. Anticheat vendors update their detection logic, change their behavioral thresholds, and add new scanning surfaces without public release notes in most cases. A configuration that passes FiveGuard version X without incident may behave differently with version Y of the same system if version Y introduces a new idle-connection heuristic or changes its traffic pattern baseline.

The correct expectation is ongoing maintenance rather than a static guarantee. We monitor the anticheat ecosystem, we track version updates from the major providers, and we respond to operator reports when new compatibility issues emerge. When an anticheat update changes behavior that affects our implementation, we update our implementation and document the change.

If you update your anticheat to a new major version and subsequently notice fake player connections being dropped or flagged, do not assume the service is broken indefinitely. Major version updates are the most common trigger for compatibility changes. The standard diagnostic process is to check the anticheat changelog if one is available, reduce the connection rate to the minimum to isolate whether it is a rate issue or a detection issue, and contact our support channel with the version information.

Next steps

For a deeper look at how anti-detection works at the network connection level, including the specific detection vectors our implementation addresses and how connection fingerprinting works in the CFX ecosystem, the anti-detection explainer covers the technical foundations in more detail.