BattlEye and EAC on a Self-Hosted Game Node: What the Client Trust Chain Actually Requires

Running your own game node changes the anticheat problem completely. On a rented game slot, the host has already negotiated with BattlEye or Easy Anti-Cheat, opened the ports, and published the IP ranges that the anticheat backend trusts. On a self-hosted box, you own all of that plumbing and none of the visibility — you cannot see the anticheat vendor’s dashboard, you cannot read their logs, and you cannot approve your own node. What follows is the operational model of that trust chain, the outbound requirements it implies, and the parts you can and cannot enforce from your side of the line.

The Trust Chain: Client, Server, and the Vendor Backend

The anticheat service is not a component that runs on your server. It is a client-side kernel driver plus a cloud backend, with your game server in the middle acting mostly as a session authority. Three flows happen when a player joins:

• Client to backend. The player’s installed anticheat service opens an authenticated session with the vendor’s infrastructure and receives a session token or GUID. This happens whether or not your server exists.
• Client to server. The player’s game client presents that token in the join handshake, and your server (or the game’s own server binary) validates it against the backend over HTTPS.
• Server to backend. Your node sends a heartbeat reporting the session, server identity, and config fingerprint. If this heartbeat fails, the server refuses connections or the game enters an unranked state.

The important consequence: your node must be able to reach the vendor’s API on the public internet, and the vendor must recognise your server’s identity. A node with no outbound access — or one behind a NAT that rewrites your source address — breaks the second half of that chain.

Outbound Endpoints and Ports You Actually Need

Requirements vary by title and by anticheat version, so treat the following as the shape of the traffic rather than a fixed list. Verify the exact hostnames with the anticheat vendor or the game’s dedicated-server documentation for your build.

Do not open inbound ports for anticheat. The vendor never connects into your server; every flow is either outbound from the node or relayed through the game’s own protocol. If a guide tells you to expose a management port for anticheat, it is wrong for the current generation of both services.

Why Self-Hosted Nodes Get Flagged

Most “my server is flagged” incidents on self-hosted boxes come down to four causes, in rough order of frequency:

• Unknown IP range. The anticheat vendor maintains a list of known hosting ASNs and game-server providers. A residential ISP, a cloud VPS ASN, or an unlisted colocation /24 looks like a compromised machine rather than a game server.
• Shared IP with prior abuse. If your IP was previously used for cheat distribution or bot hosting, its reputation is already bad and the vendor has no reason to re-evaluate.
• Heartbeat blocked. Egress firewalls that allow only DNS and the game ports will silently break validation. The server appears up but unverified.
• Clock drift. Session tokens are time-bound. A node running 3 minutes behind has tokens rejected as expired, which is often misread as a ban.

# Verify egress and clock before blaming the anticheat
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://<vendor-api-host>/
chronyc tracking | egrep 'Leap|System time|Last offset'
dig +short TXT whois.asn.cymru.com +short $(curl -s ifconfig.me)

That last command tells you the ASN the vendor sees, which is the single most useful piece of information when opening a whitelist request. If it resolves to a consumer ISP or a general-purpose cloud, expect pushback.

Whitelisting Your IP Range with the Vendor

Whitelisting is a business process, not a config file. Neither BattlEye nor EAC exposes a public self-service endpoint for adding arbitrary IP ranges. In practice the path runs through one of three routes:

• The game developer’s dedicated server programme, if the title has one. This is the cleanest route and usually comes with documentation plus a support contact.
• Your hosting provider’s existing relationship, if you are on a bare metal box at a provider already known to the vendor. Ask them to file the range under their account; it is quicker than a cold request.
• Direct vendor support with evidence: static ASN, reverse DNS on the range, abuse contact, and a description of the deployment.

Set up reverse DNS before you ask. A range with PTR records like game1.ark.example.net is treated very differently from an anonymous block, and rDNS is the cheapest credibility signal you have. Confirm the range is static and documented in your ticket, because a dynamic address will invalidate the whitelist the first time it changes.

Kernel Drivers: Server Side vs Client Side

This is the most misunderstood part of the trust chain. Both BattlEye and EAC install a kernel-mode driver on the player’s machine to inspect memory and process integrity. Nothing equivalent runs on your server. The server side is a userspace component that loads as part of the game binary or as a companion module, and it does not need kernel privileges.

If you are running the server inside a container or a VM with a custom kernel, you do not need to expose /dev or load unsigned modules. If a guide tells you otherwise, it is describing the client. The server component is sensitive to CPU feature masking under some hypervisors, though — hiding AVX or restricting CPUID leaves can cause the module to misidentify the platform and refuse to start.

What You Cannot Enforce Without the Private API

Be realistic about the boundary. Without vendor API access you cannot read individual verdicts, cannot query a player’s ban history across other servers, cannot whitelist by SteamID at the anticheat layer, and cannot receive webhook notifications when a session is refused. What you can do is indirect:

• Log every kick reason at the server level and aggregate by reason code — patterns reveal whether you have a mass authentication failure or individual suspicious clients.
• Correlate join timestamps with connection source IPs to catch ban evasion that anticheat does not flag.
• Maintain your own ban list keyed on SteamID64 and IP, and enforce it in your server’s connect handler.
• Alert on heartbeat failure, because a node that silently drops out of verification keeps accepting players with no protection at all.

Hardening the Ops Side

Pin egress so the node always leaves via the same static address — asymmetric routing through a second uplink will intermittently present a different source IP and appear as a spoofing attempt. Monitor the validation path with a five-minute synthetic check that joins a loopback test client; that catches egress and clock failures before players do.

Keep a runbook entry with your ASN, rDNS records, vendor ticket number, and the date the range was confirmed. When an anticheat update changes an endpoint — and it does, roughly twice a year — you will need all four to re-open the case quickly. If you are choosing a node for a title with strict anticheat, the dedicated game server options include providers with static IP blocks and clean ASN reputation, and the game server hosting comparisons note which platforms have existing vendor relationships.