How Fake Player Anti Detection Works at the Network Level

Every fake player provider in this category says their players are "100 percent undetectable" and stops there. No explanation of what detection actually means, which systems do the checking, or what signals those systems look for. That vagueness is fine for marketing copy, but it is not useful if you are an operator who needs to understand the actual exposure before running fake players on a server with an active anticheat subscription.

This post explains the three primary detection vectors for FiveM fake players, how each one works at the connection level, which anticheat systems use which signals, and what we do to address each one. We also explain what the phrase "100 percent undetectable" does and does not mean in practice.

The three detection vectors

Fake player detection on FiveM operates across three distinct surfaces. Understanding each one separately is the only way to evaluate whether a provider's anti-detection claim covers your actual risk. Operators using fake players to build server population can read the complete FiveM fake players guide for the broader context.

Vector one: CFX API scraping

The CFX API is a public endpoint that exposes player information for every FiveM server listed in the server browser. External tools and monitoring services query this API to compare the player list your server broadcasts with other observable data. The most common form of this check looks at player identifiers: a legitimate player connecting from a real FiveM client generates a Steam identifier, a Discord identifier, and a license identifier that are consistent with a real account.

A fake player that connects without valid Steam or Discord identifiers, or with identifiers that follow a pattern (sequential, repeated prefix, obviously synthetic), will appear anomalous in any API scrape that compares identifier structure across players. The CFX API scrape vector is not used by anticheat systems in the traditional sense. It is used by third-party monitoring tools, competing operators, and community watchdog bots that flag servers suspected of running bots.

How we address this: each fake player connection carries a unique, structurally valid identifier set. These identifiers follow the same format as real client-generated identifiers. They do not share prefixes, are not sequential, and do not cluster in ways that pattern-matching tools can flag. We rotate identifier pools to avoid repetition across billing cycles.

Vector two: connection fingerprinting

The FiveM client performs a handshake with the server during connection that includes information about the client environment: the game version, the FiveM client version, the hardware token, and the network characteristics of the connection. A real player's handshake comes from a full FiveM installation running on consumer hardware over a residential or commercial internet connection. A fake player connection generated from a data center has a different network profile.

Connection fingerprinting is the most technically involved detection vector because it operates at the network layer before the player even appears in the server's player list. Anticheat systems that perform fingerprinting look at IP range classification (data center versus residential), connection latency patterns that do not match the claimed geographic location, and client handshake fields that deviate from the expected distribution for real clients.

How we address this: our connection nodes are distributed across regions using infrastructure that does not flag on standard IP range classification tools used by FiveM-adjacent systems. Latency profiles are calibrated to match realistic values for each region. Client handshake parameters conform to the expected distribution for genuine FiveM clients on the artifact version your server reports.

Vector three: txAdmin native scanning

txAdmin, the standard server management panel for FiveM, has native player monitoring capabilities. Operators and moderators checking the txAdmin player list can see connection metadata that goes beyond what the server browser shows: join time, connection state, the resource loading sequence on join, and behavioral patterns during the session.

A fake player that connects but does not progress through the standard resource loading sequence, or that appears in the player list without the expected server-side events firing, is visible to a trained txAdmin operator. Additionally, txAdmin integrations for some anticheat systems surface player-side data that would be absent for a connection generated without a running game client.

How we address this: our fake player connections are txAdmin native, meaning they appear in the txAdmin player list as expected, complete the connection sequence that txAdmin monitors, and trigger the server-side events that txAdmin and its integrations expect from a legitimate join. This is the reason our txAdmin integration requires the server to be on a compatible artifact version. The connection behavior is version-specific.

What anticheat systems actually check

The four anticheat systems most commonly deployed on FiveM servers are FiveGuard, Electron, Waveshield, and Reaper. Each has a different detection scope and a different relationship with fake player connections.

FiveGuard

FiveGuard operates primarily as a client-side anticheat that detects game modifications, cheat injections, and modified game files on the player's machine. Its enforcement mechanism is a ban on the player's license identifier and hardware token. Because fake players do not run a game client with a FiveGuard-monitored process, FiveGuard's client-side checks do not apply to them. However, FiveGuard also performs server-side connection validation that checks identifier structure and connection metadata.

We have tested our fake player connections against servers running FiveGuard. Connections pass the server-side validation when configured correctly. The key configuration requirement is ensuring your artifact version is within the compatible range and that the fake player identifiers pass FiveGuard's structure validation.

Electron

Electron anticheat combines client-side process monitoring with server-side behavioral analytics. On the server side, Electron monitors player behavior patterns: movement inputs, spawn events, and interaction events that would be generated by a real player over time. A fake player that connects and remains completely static from Electron's perspective generates a behavioral signature that differs from any real player.

Our fake players generate minimal behavioral noise to avoid static-connection signatures. This is not a complete simulation of player behavior, but it is sufficient to avoid triggering Electron's passive pattern detection. Electron's primary value is detecting cheaters in active gameplay, not auditing connection quality, so the false-positive surface for fake players in a correctly configured deployment is limited.

Waveshield and Reaper

Waveshield and Reaper are network-level protection systems focused on DDoS mitigation and connection filtering rather than gameplay-level cheat detection. Waveshield operates as a connection proxy that classifies incoming connections and filters malformed or anomalous ones. Reaper focuses on rate limiting and connection pattern analysis.

Both systems can theoretically flag fake player connections if the connection rate or IP source pattern looks automated. We route fake player connections through dispersed nodes with rate profiles that match organic join patterns. Connections are not established in burst batches. They are staggered over realistic join intervals.

What "100 percent undetectable" actually means

No fake player service is undetectable under all conditions, and any provider that claims otherwise without qualification is misleading you. The accurate claim is: our fake players are not detected by the standard automated checks used by the anticheat systems we have tested against, on the artifact versions within our compatibility matrix, when the server configuration meets the requirements we document.

The risk framing changes when you understand this correctly. The realistic threat model for most operators is not a manual CFX audit. It is community monitoring tools, competing operators using third-party scanners, and anticheat systems doing automated connection validation. Against those threats, our anti-detection measures are effective.

Anti-detection and artifact version compatibility

Anti-detection is not a configuration you set once and forget. The FiveM handshake protocol and the connection validation logic used by anticheat systems change with game updates and artifact releases. A fake player connection that passes validation on artifact build 7290 may fail on artifact build 7500 if a game update changed the expected handshake parameters.

We maintain compatibility by tracking artifact releases and updating our connection software when handshake parameters change. Updates to our connection layer are deployed within 24 to 48 hours of a major artifact release that changes validation behavior. During the update window, connections on affected artifact versions may experience reduced reliability.

• When a major FiveM update is released, check the dashboard status page before concluding your players are broken.
• Pinning your server to a tested artifact version is the most reliable way to maintain stable anti-detection behavior.
• We announce compatibility updates in the Discord and on the dashboard before releasing them so you can coordinate your server update with our connection layer update.

How identifier pools work and why rotation matters

Every fake player connection carries a set of identifiers: a license identifier derived from the FiveM client registration system, a Steam identifier, and optionally a Discord identifier. These identifiers are what appear in your server logs and in the CFX API player list. An identifier pool is the set of available identifiers from which connections draw when they establish.

Identifier reuse is one of the clearest detection signals for monitoring tools. If a server shows 40 players with 10 of the same identifier hashes appearing across different sessions, the pattern is visible to any log analysis tool. We rotate identifier pools across billing cycles and across connection establishments so no identifier appears more than once in your server logs within a given time window.

The rotation schedule is tied to your billing cycle and to the duration of each connection session. For long-running connections (players that stay connected for hours as part of a scheduled window), the identifier is stable for the session but replaced in the next scheduled connection. For short-window configurations, rotation happens more aggressively.

The network-level profile of a legitimate connection

A real FiveM player connecting from home has a distinct network profile: a residential or mobile IP address, a connection latency that matches the geographic distance between the player and the server, and a data rate pattern during the connection handshake that reflects the actual FiveM client resource loading process. Our connection layer replicates these characteristics at the network level.

The IP classification problem is the most significant technical challenge in fake player anti-detection. Data center IP ranges are publicly documented in databases like MaxMind GeoIP and the ARIN WHOIS records. A connection from an IP that maps to a data center AS number is immediately suspect for any connection fingerprinting system that checks IP origin. Our connection nodes use IP ranges that classify as residential or commercial (not data center) in the standard classification databases used by FiveM-adjacent tools.

• Latency profiles are calibrated per region. A fake player configured as European has connection latency that matches European residential ranges for your server's region.
• Data rates during handshake match the distribution observed in genuine FiveM client connections.
• Packet timing patterns do not follow the uniform intervals that automated connection tools produce.
• IP origin classification is residential or commercial in standard GeoIP databases, not data center.

How we test anti-detection continuously

We run test servers with live anticheat configurations to validate our connection behavior before and after each artifact update. Test servers run FiveGuard, Electron, and Waveshield configurations that match common operator setups. Fake player connections are validated against each configuration as part of our release process. The test cycle runs on a weekly basis outside of major game update windows, and before every release of a connection layer update.

Our test methodology for each anticheat system is specific to what that system checks. For FiveGuard, we validate identifier structure and server-side connection metadata. For Electron, we observe the behavioral signal generated by fake player sessions and verify it falls within the range that does not trigger passive anomaly flags. For Waveshield and Reaper, we validate that connection rate patterns and IP origin profiles pass the network-level filtering rules those systems apply.

Next steps

The anti-detection question and the ban risk question are related but distinct. Understanding what the anti-detection measures cover gives you the technical picture. Understanding the FiveM platform policy context gives you the operational picture. The

covers what the CFX team has said publicly about fake player services and how to frame your use of them responsibly.