BattlEye and Easy Anti-Cheat on servers

On a dedicated server running BattlEye or Easy Anti-Cheat, you control surprisingly little: whether the anti-cheat is switched on, a handful of settings around it, and - for BattlEye only - a local ban list, an RCon interface and a set of script filters on some games. The detection itself, the signatures, and every global ban belong to the anti-cheat vendor and the game's developer. You cannot unban someone they banned, you cannot see why a player was kicked beyond a short message, and you cannot add your own detections. Knowing exactly where that line falls is the difference between configuring the thing properly and spending an evening looking for settings that do not exist.

This post covers what each system does on the server, the switches per game, the files you own, how bans work at each level, and the cheating neither system will ever stop - which is where your own moderation comes in.

What a kernel anti-cheat does, and where the server fits#

BattlEye and Easy Anti-Cheat (EAC, now part of Epic Online Services) are both client-side systems first. The heavy part runs on the player's PC, at kernel level on modern versions, and looks for known cheat software, memory tampering, injected modules and unsigned drivers. The server-side component is comparatively thin: it checks that every connecting client is running the anti-cheat, relays the client's reports to the vendor's backend, and kicks the client when the backend says so.

That design has three consequences worth stating plainly:

• Detection happens elsewhere. Your server is not scanning anything. It is enforcing a verdict reached on the player's machine and the vendor's servers.
• A server can only require it, not improve it. There is no "stricter mode" you can buy or configure. Every server running the same game build gets the same detections.
• Turning it off is total. A server with the anti-cheat disabled accepts clients that are not running it at all, which means anything goes.

Valve Anti-Cheat (VAC) is the third system you will meet, on Source games and CS2. VAC works differently - delayed bans issued by Valve, no kernel driver, no server-side interaction beyond the server being "secure" - but the ownership question has the same answer: Valve decides, you choose whether your server participates.

Which games use which system#

This changes over time, and developers occasionally switch vendors, so treat the table as a starting point and check the game's current server documentation before you rely on it.

A few of these deserve a sentence each. Arma 3 and DayZ have the deepest server-side BattlEye integration, with filters and RCon covered below. 7 Days to Die is the common case where people turn anti-cheat off on purpose, because mods that ship custom code (DLL mods) do not load with EAC enabled, while XML-only modlets do - 7 Days to Die server settings covers the rest of that file. Rust community servers run EAC as a matter of course; a Rust server with server.secure false is a curiosity that most players will not join.

On Source games, VAC is on unless the server is started with -insecure, or sv_lan 1 makes it a LAN server. An insecure server is not listed to VAC-secured players in the normal way, and VAC-banned accounts can join it, which is rarely what you want on a public server.

The switches you actually own#

Here is the complete list of anti-cheat decisions that are yours on most games:

1. On or off. The single biggest choice. Leave it on for any public server. Turn it off only for a private group that needs mods the anti-cheat blocks, and accept that you are now relying on trust.
2. Signature and file verification, on games that have it. This is not the anti-cheat itself but works next to it, and on some games it matters more.
3. Ping and timeout limits, which BattlEye exposes on some games.
4. Your local ban list and your RCon access, for BattlEye games.
5. Script filters, on Arma-family games.

On Arma 3, the relevant part of server.cfg looks like this:

BattlEye = 1;              // require BattlEyeverifySignatures = 2;      // reject clients with unsigned or mismatched addonskickDuplicate = 1;         // kick a second connection from the same IDallowedFilePatching = 0;   // clients may not load loose files over packed data

verifySignatures = 2 is the setting that does the most work against casual cheating on Arma 3. It requires every addon a client loads to be signed with a key the server has in its keys folder, which stops a player from loading a modified PBO that the server never approved. BattlEye catches the cheat software; signature checking catches the cheat content. Arma 3 server.cfg and missions goes through the rest of that file.

BattlEye on the server: files, RCon and filters#

BattlEye's server side lives in a BattlEye folder, normally inside the server's profile directory. The file you edit is BEServer_x64.cfg (or BEServer.cfg on older 32-bit builds). It is short:

RConPassword a-long-generated-passwordRConPort 2306MaxPing 250

RConPassword and RConPort enable BattlEye's own remote console, a UDP protocol separate from the game's. MaxPing kicks players above that ping, which is cruder than it sounds - a player with a spike gets kicked mid-fight - so set it generously or leave it out. Some builds rewrite this file at start with an _active_ suffix in the name; edit the base file, not the generated one.

BattlEye RCon is how almost every third-party admin tool talks to Arma and DayZ servers. The commands are few and worth knowing directly:

The same rules apply to BattlEye RCon as to any remote console: a long random password, the port exposed only if a tool really needs it, and access granted to as few people as possible. RCON safely covers the reasoning; DayZ admin tools and BattlEye RCon covers the DayZ-specific tooling.

The BattlEye GUID in the players output is not a secret identifier. It is derived from the player's SteamID64 - an MD5 hash of the bytes BE followed by the 64-bit ID - so a ban tool can compute it from a SteamID, and a ban by GUID is effectively a ban by Steam account.

Script filters on Arma

On Arma 3, BattlEye can also filter scripting traffic: files such as remoteexec.txt, createvehicle.txt, publicvariable.txt and setvariable.txt in the BattlEye folder hold rules that log or kick when a client sends something matching a pattern. Well-made filters stop a large class of script-injection attacks that the kernel component would never see, because the "cheat" is just a legitimate game command sent by a client that should not be sending it.

Filters are also the easiest way to break a mission. A filter strict enough to stop injected code will kick legitimate players the moment the mission or a mod does something the filter author did not anticipate. The workable approach is to start from filters published for your mission or mod set, run them in log-only mode while you play a few sessions, read what they would have kicked, and only then switch the kicks on. loadScripts and loadEvents reload them without a restart.

How bans work at each level#

There are three kinds of ban on an anti-cheat game, and mixing them up causes most of the confused tickets server owners send to the wrong place.

Only the bottom box is yours.

• Global anti-cheat bans are issued by BattlEye or by the developer through EAC, apply to every server running that game, and cannot be lifted by you. The player sees a message saying they are globally banned. If they believe it is a mistake, the appeal goes to the vendor or developer, not to you, and you should say so without engaging further.
• Game bans on Valve games (VAC and game bans) are issued by Valve. Same rule: not yours to lift, and a VAC-secured server will refuse the account.
• Your local bans are yours entirely. On BattlEye games they live in bans.txt in the BattlEye folder, one line per ban with the GUID or IP, the expiry (or -1 for permanent) and the reason. On EAC and VAC games they live in the game's own ban list, which differs per title.

A local ban is only as good as the identifier behind it. GUID and Steam bans follow the account, which a determined cheater replaces with a new one. IP bans follow an address that may be shared by a whole household or university, and change at the next router restart. Handling cheaters and ban lists covers which identifier to ban and how to deal with the second account.

What anti-cheat will never catch#

This is the part that matters most for your expectations. A kernel anti-cheat is good at catching known cheat software on a client. It is structurally unable to catch:

• Closet cheating with good cheats. Private, well-funded cheats evade detection for months. A player with a subtle aimbot and a natural-looking play style can stay undetected for a long time.
• Hardware and external cheats. Devices that read the screen with a second computer, or modified input hardware, never touch the game process.
• Information from outside the game. Somebody watching your server's stream, a teammate on voice in the other team, or a friend calling out positions.
• Exploits of the game itself. Glitching under the map, duplication bugs, abusing a mod's broken logic. These are allowed by the game, so the anti-cheat sees a normal client doing normal things.
• Server-side abuse. An admin with RCon spawning items for friends. Anti-cheat has no opinion about your staff.
• Griefing and toxicity. Not cheating in the anti-cheat sense at all.

That list is why anti-cheat is a baseline rather than a solution. On top of it you still need logs that let you review what happened, admins who spectate, a clear rule set and a ban process that holds up - server rules, moderation and staff is the policy side of that, and game server exploits and crash bugs is the side about bugs rather than cheaters.

Mods, anti-cheat and the private-server compromise#

The most common reason a server owner touches the anti-cheat switch is mods. The rules are game-specific but the pattern repeats:

• Data-only mods usually work with anti-cheat on. Configuration changes, XML modlets on 7 Days to Die, Workshop content on Arma and DayZ that is signed and verified.
• Mods that inject code into the client usually do not. 7 Days to Die DLL mods, client-side frameworks that hook the game process, anything that looks to the anti-cheat exactly like a cheat because, mechanically, it is the same technique.
• Server-side mods are invisible to the anti-cheat. Oxide or Carbon plugins on Rust, server-side DayZ scripts, admin tools - none of these touch clients, so the anti-cheat neither knows nor cares.

If your group needs a client-side code mod that the anti-cheat blocks, the honest options are: run that server with anti-cheat off and a password or allow list, so only people you know can join; or skip the mod. What you should not do is run a public, listed server with anti-cheat disabled because one mod needed it. The server becomes a destination for exactly the players who were banned everywhere else.

Server-side admin and logging mods, by contrast, are worth having on any anti-cheat game. They give you the evidence anti-cheat never will: who killed whom from where, who picked up what, who said what. On DayZ that is typically an admin tool reading the server's admin log; on Rust it is plugins built for logging and reporting.

Running it on a hosted server#

Nothing about BattlEye or EAC needs special hosting. The server-side components ship with the dedicated server files and update with them. What does matter:

• Ports. BattlEye RCon needs its own UDP port if you use external tools. On RE:NODE every plan states its port allocations, and you can add one on the Network tab and point RConPort at it. If you never use external RCon tools, leave it unset and use the panel console instead.
• Updates. Anti-cheat versions are tied to game versions. A server that updates late gets clients refused, or the reverse; on Arma and DayZ, update the server when the game updates and the problem goes away. Restart schedules that help covers doing that at a quiet hour.
• Credentials. Arma 3, DayZ and 7 Days to Die on RE:NODE need a Steam login to install, which is stored as typed, so use a spare Steam account rather than the one you play on. The server is created at once and the install waits on the Setup tab until you enter it.
• Logs. BattlEye writes its own logs in the BattlEye folder, which are the first place to look when players report being kicked with a BattlEye message.

Troubleshooting kicks and anti-cheat errors#

"BattlEye: Client not responding". The client's BattlEye service stopped talking to the server. Usually the player's side: a firewall, a crashed BE service, or a very poor connection. If every player gets it at once, the server's BattlEye files do not match the game version - update the server.

"BattlEye: Global Ban". The vendor banned the account. Nothing to do on your side.

Players kicked for a script restriction on Arma. A filter matched. The kick message includes the filter file and line number; read that line in the file, decide whether it was a cheat or your mission, and adjust or exclude.

Signature check failed on Arma. The client has an addon the server has no key for, or a different version of a mod. Make sure the server and the client load exactly the same mod versions, and that the matching .bikey is in keys.

EAC kicks every player on 7 Days to Die after installing a mod. The mod contains custom code. Either remove it or set EACEnabled to false - and if you do the latter, put a password on the server.

Nobody can join after a game update. The client anti-cheat updated with the game and the server did not. Update the server; on a modded server, update the mods as well.

FAQ#

Can I ban someone through BattlEye so they cannot join any server?

No. Your bans apply to your server only. Global bans come from BattlEye or the developer, based on their own detection. Reporting a cheater to the vendor with evidence is possible on some games, but you have no direct way to trigger a global ban.

Can I unban a player who was globally banned by mistake?

No, and you should not try to work around it by disabling anti-cheat. The player appeals to the vendor or to the game's developer. You can tell them where to go, and that is the end of your involvement.

Does running anti-cheat cost server performance?

Very little. The server-side components do almost no work compared to the game simulation. BattlEye script filters on Arma add some cost on a busy server with complex filters, but rarely enough to notice.

Is a server with anti-cheat off automatically full of cheaters?

Not if nobody can join it. A private server behind a password or allow list, for a group that knows each other, is a perfectly reasonable way to run mods the anti-cheat blocks. The problem is a public server with anti-cheat off.

Do server-side plugins conflict with BattlEye or EAC?

Generally not. Server-side code never touches the client, which is the only place the anti-cheat looks. Conflicts come from client-side mods that hook the game process.