Anti-Cheat for Community Servers: What Actually Works

Published 9 September 2026 · JoinGG · Guides

Nothing you can install prevents cheating on a community server. VAC bans on Valve's schedule and ignores your plugins. What works is a stack: file integrity, cvar checks, server-side behavior heuristics, and a human reviewing demos. Each layer raises the cost of cheating; none of them ends it.

Every operator asks the same question after a bad night: what anti-cheat should I install? There is no single product you can drop onto a Counter-Strike, Garry's Mod or Team Fortress server that stops cheating. What you can build is a set of independent checks that each catch a different class of cheater, plus a review process for the cases code cannot decide.

This matters more for community servers than for matchmaking. Valve Anti-Cheat runs on Valve's terms and Valve's timetable, and it knows nothing about your surf timer, your zombie mod or your custom weapon plugin. If you run one of the 859 CS2 servers or the 1,588 Counter-Strike 1.6 servers currently listed on JoinGG, the detection that protects your regulars is detection you configured yourself.

What follows is the layer-by-layer version: what each method looks at, what it cannot see, what it costs to keep running, and how often it accuses someone innocent. Read the false positive section even if you skip the rest.

What VAC actually does on a community server

VAC is signature and memory scanning performed by Valve's client, on the player's machine, against a detection set Valve maintains and never publishes. Three properties of that design decide what it is worth to you.

It is deliberately delayed. Valve accumulates detections and issues bans in waves, often weeks or months after the cheat was used. That is sound ecosystem policy, because it stops cheat developers from testing a build against VAC and shipping the moment it comes back clean. It is also useless when a spinbot is wrecking round four tonight. Nothing about VAC is an incident response tool.

It is not yours. You cannot query it, tune it, whitelist against it, or ask why a decision went the way it did. A VAC ban does block that account from every VAC-secured server for that game, which is genuine deterrence, but you get no signal until it fires. Your admins learn about it the same way the player does.

It only knows Valve's definition of cheating. A macro that abuses your shop cooldown, an alt account farming your ranking table, a Lua exploit against your gamemode, someone spoofing a name to impersonate staff: VAC has no opinion on any of it. Roughly everything that makes a community server a community, rather than a matchmaking lobby, sits outside its remit.

None of that argues for turning it off. Stay VAC-secured: it is free, it costs no CPU, and it forces the bottom tier of public cheat user to buy a fresh copy of the game to come back. Do not run plugins that require sv_cheats 1 on a public server, and be suspicious of anything that asks you to leave secure mode. The advice holds on the older Source titles too, where the plugin ecosystem is stable enough to make it easy, which is part of why the Counter-Strike: Source server list still shows around 4,060 players across 598 servers. The hard cases start where VAC stops, which is almost immediately.

The detection layers you can actually run

Think of anti-cheat as six layers, ordered by what they cost you to operate. Each catches a different failure mode. Running one and calling the problem solved is the standard mistake, because the cheap layers catch only the cheap cheats.

Read the table bottom-up when you plan your week. The cheap top rows are configuration you do once. The expensive bottom rows decide whether your server has a reputation for fair play, and they are the ones operators quietly stop doing. A realistic floor is one hour of review per week for every 100 concurrent players you carry.

Two notes before the detail. Every layer should log a timestamp, the account identifier, the check that fired and the tick range, whether or not it acts; detection you cannot reconstruct is detection you cannot defend in an appeal. And ban management is separate from detection: SourceBans++ on a MySQL backend gives you searchable history, an appeal form and a shared list, and is worth installing before any heuristic at all.

Server-side detection: sv_pure, consistency and cvar checks

These are the cheapest wins on any Source engine server, and the ones most often configured wrong.

File integrity with sv_pure

sv_pure 0 lets clients load whatever they like. sv_pure 1 enforces a whitelist, normally pure_server_whitelist.txt, which decides per directory whether files must come from the original game archives, may be modified, or are ignored. sv_pure 2 forces everything from the archives and breaks custom content outright. For a server running custom maps, models or a HUD, sv_pure 1 with a carefully written whitelist is the only workable setting.

Lock materials/, models/ and particles/ to the archives and leave your own content directories permissive. That kills the entire class of texture wallhacks, no-smoke edits and glowing-model packs, still the most common cheat a casual player installs because it does not feel like cheating to them. It touches nothing external: a cheat reading entity positions out of process modifies no file, so sv_pure reports a clean client.

Forcing consistency on models and sounds

sv_consistency 1 plus explicit ForceConsistency entries makes the server demand that specific model, sound and decal files match by size or checksum. Use it for assets that matter to fairness, not for everything you ship. Consistency failures kick with a message most players cannot act on, and someone kicked twice over a stale cached file does not stay to investigate. If you push content over FastDL, version your asset paths so a changed file arrives at a new URL instead of colliding with a cache.

Querying client convars, and why it stops working

SourceMod's convar query and the AMX Mod X equivalent let the server ask a client for a variable's value and act on the answer. The classic set is r_drawothermodels forced to 1, mat_fullbright and mat_wireframe forced to 0, r_drawtranslucentworld checked, and cl_interp constrained to a sane band for your tick rate, which the guide to tick rate and what the server actually sees covers in more depth.

Set that interpolation band deliberately rather than copying someone else's config. Too tight and you punish every player on a 90 ms connection; too loose and lag switching hides inside your tolerance. Then accept the limit: the query is answered by the client, so any cheat that hooks the response returns whatever you asked to hear. Cvar checks catch the player who edited an autoexec after watching a video. They catch almost nobody who paid for a subscription. Run them anyway, because they are free, but never treat a clean response as evidence of a clean client.

Is a kernel-level anti-cheat worth it for a community server?

Usually the question is moot, because the option does not exist. EasyAntiCheat and BattlEye are licensed to game developers and compiled into the game client. You cannot bolt either onto a Source mod, a GoldSrc server or a Garry's Mod gamemode as an operator. Where a game ships with one the decision was made for you: Rust runs EAC because Facepunch chose it, and your work happens above it in Oxide or Carbon plugins. The platform anti-cheats competitive leagues run are tied to those platforms' own clients and are not licensable for a 24-slot pub.

What you can do is ship a custom client or launcher and require it. This is not theoretical: sXe Injected did exactly that for Counter-Strike 1.6 and is still required across part of the Latin American 1.6 scene twenty years later. It works in the narrow sense that it blocks injected DLLs and known signatures. The costs are real, and mostly not technical.

• Install friction. Most joins from a public list are casual. Someone browsing servers and hitting connect will not stop to install a driver from a community they have never heard of. Expect to lose the majority of drive-by traffic, which is most of your growth.

• Support burden. Antivirus flags, driver conflicts, Secure Boot, and one Windows update that breaks everything on a Tuesday. That is now your support queue, staffed by volunteers.

• Trust. You are asking strangers to run a kernel driver from an unknown publisher. Some are right to refuse.

• It still loses to hardware. A DMA setup reads game memory across the PCIe bus from a second machine, so the gaming PC runs no cheat process at all. Add a hardware mouse emulator and the input is indistinguishable from a real mouse at the OS level. There is nothing on that machine to detect.

That last point is the honest frame for the whole article. You are not building prevention, you are raising cost. A DMA rig plus a subscription runs into the hundreds of dollars and a weekend of setup, and practically nobody spends that to ruin a 24-slot public server; they spend it where there is a ladder to climb. Push the cost of cheating above the value of cheating on your server specifically, and that bar is far lower than the one Valve has to clear. Since your budget is finite and what a server actually costs to run each month already competes with everything else, spending it on a driver nobody installs is the wrong trade.

Writing your own heuristics on SourceMod and AMX Mod X

This is the layer that earns its keep, because it measures what happened in the game rather than what is on the client. A private cheat is invisible to signature scanning and completely visible to a check that asks whether a human hand could have produced that movement.

SMAC, the SourceMod Anti-Cheat suite, packaged most of these as modules: aim angle snapping, eye-angle validation, autotrigger timing, spinhack detection and command flooding. The original project has been unmaintained for years, so run a current fork and read the module list as a menu of ideas rather than a finished product. If you are still choosing a scripting platform, the comparison of SourceMod, AMX Mod X and Oxide covers which engines each one reaches.

The checks worth writing, with starting values you must calibrate against your own population:

1. Angle snap. A human turn spreads across five to fifteen ticks; an aimbot lands in one or two. Flag a yaw or pitch delta above about 40 degrees in a single tick when a shot fires within three ticks.

1. Flick reversal. Yaw moving A to B and back to within a couple of degrees of A inside four ticks is a bot snapping on and releasing. Humans overshoot and correct; bots return exactly.

1. Reaction floor. Human reactions cluster between 150 and 250 ms. Repeated sub-100 ms shots at targets that were occluded a tick earlier is a wallhack or triggerbot signal.

1. Recoil correlation. Compare a player's compensation against the exact inverse of the weapon's recoil pattern. A no-recoil script correlates almost perfectly. Human compensation is good, never that good.

1. Speedhack timing. Sum the movement time in incoming user commands over a rolling ten-second window and compare it against wall-clock time. A ratio sustained above 1.0 is client clock manipulation. This classic GoldSrc check still works on 1.6 today.

1. Spinbot. Sustained yaw change beyond 180 degrees per tick. Trivial to detect, and almost always paired with something worth finding.

Statistical flags such as headshot ratio belong in a review queue, never on a ban trigger. Over 500 kills, a ratio above roughly 70 percent on 1.6 is rare enough to look at, and it is also what a very good player produces on a map they know. Use it to decide who gets watched, not who gets banned.

Then follow the calibration protocol people skip. Ship every new check in log-only mode and run it for two to four weeks against regulars you already know are clean. If it fires on three known-good players in a fortnight, the threshold is wrong, not the players. Only when the log is quiet do you let it act, and even then start with a temporary kick. Garry's Mod deserves a note of its own: across the 351 servers on the Garry's Mod server list, the larger threat is a malicious addon running server-side Lua rather than an aimbot, so your effort belongs on addon auditing instead.

Demo review and player reports catch what code cannot

A pure wallhack with a competent human aiming is invisible to every heuristic above. Nothing about the movement is inhuman. What gives it away is context only a person can read: pre-aiming a doorway nobody has walked through, tracking a target through smoke, always choosing the correct rotation, never once clearing an empty angle. This is why demo review is not optional, and why it is the layer that sets your reputation.

Do not record everything. GOTV and HLTV demos of a busy server run into the tens of megabytes per half hour, and recording every round on every map fills a disk faster than anyone plans for. Wire recording to your heuristics instead: when a check fires in log-only mode, start a demo and mark the tick. You end up with a small library already pre-filtered by a signal, which turns an hour of review into eight or ten real decisions instead of two.

Player reports are the other input, and their quality depends entirely on weighting. A raw !report command produces noise, because losing players report winning players. Three design choices fix most of it:

• Snapshot on submit. Capture the accused account, the reporter, the server, the map and a tick range covering the last 30 seconds, so a reviewer jumps straight to the moment instead of scrubbing a 40-minute demo.

• Weight by reporter history. A regular with 100 hours whose last five reports were upheld should outrank a two-minute-old account. Track upheld rate per reporter and sort the queue by it.

• Close the loop. Tell reporters what happened, even when the answer is no action. Reporting into a void stops, and then you have lost the only sensor that scales with your player count.

The output is trust, which is a growth channel rather than a chore. Players pick servers on reputation, and a listing showing consistent population plus a visible enforcement record converts far better than one that does not, which is the argument made in the piece on what makes a server listing trustworthy. A monthly line about reports received, actions taken and bans overturned does more for recruitment than any anti-cheat claim in your MOTD.

False positives cost you more than cheaters do

Run the arithmetic before you enable automatic banning. A cheater on a 24-slot server ruins one map for 23 people, and most of them come back tomorrow. A wrongly banned regular tells their friends, and the friends were why you had a Tuesday evening population at all. The asymmetry worsens the smaller you are: once average concurrency drops you fall down every sort order, which is the failure loop described in the piece on why nobody joins your server.

The players your heuristics will accuse are predictable:

• High-ping players. Interpolation and prediction mean the server's view of their aim is reconstructed, and reconstruction produces angle deltas that look artificial. Anyone consistently above 120 ms trips snap detection more often than a local player.

• Low frame rate players. At 30 fps input arrives in coarse chunks, and a turn a 240 fps player spreads over twelve ticks arrives in three.

• Macro and hardware users. A mouse with a configured DPI shift, or a keyboard macro for crouch-jumping, produces mechanically consistent input that a correlation check reads as a script.

• Very good players. The top one percent of any long-lived community genuinely does hit the numbers your accuracy flags watch for. On 1.6 especially, someone with fifteen years on the same map set is not statistically normal, and the Counter-Strike 1.6 player-count history is a reminder that these communities have had two decades to produce them.

Four policies keep the damage contained. Require two independent signals before any automatic action, so one noisy check cannot ban alone. Make the first ban time-limited, typically seven days, because you can escalate a temporary ban with more evidence but you cannot un-ruin a reputation. Publish the evidence standard in plain language. And run a real appeal route with a named reviewer and a deadline.

Then watch your overturn rate. Never overturning anything is not proof your detection is perfect; it is a sign the appeal form is decorative and people stopped using it. Somewhere between 5 and 15 percent of appeals succeeding is healthy for a server that acts on automated signals, and a rate far above that band means your thresholds are too aggressive rather than your appeals too generous.

Counter-Strike 1.6 and CS2 are two different problems

Operators often ask which is harder to protect. They are not the same problem, and the difficulty sits in opposite places.

Counter-Strike 1.6: mature cheats, mature detection, broken identity

GoldSrc is an engine from 1998 and its public cheat set has barely moved in fifteen years. That is a gift for defenders. Detection written in 2012 for OpenGL wallhacks, speedhacks and aim assists still fires in 2026, because the cheats did not change either. AMX Mod X accumulated a deep set of those plugins, and timing checks such as the movement-time ratio remain reliable. Technically, 1.6 is the easiest Counter-Strike to police.

The problem is identity. A meaningful share of the 10,800 players across 1,588 listed 1.6 servers connect from non-Steam clients, where the account identifier can be forged. When a banned player returns with a new identifier in ninety seconds, your ban list is decoration. The fallbacks are bad: IP bans collide with carrier-grade NAT and take out a whole neighborhood, and hardware identifiers need a client component you probably do not ship. Reserve slots for Steam-authenticated clients, or accept that enforcement on 1.6 is a rolling process rather than a permanent removal. The wider operational picture is in the guide to running Counter-Strike 1.6 servers.

CS2: solid identity, moving tooling

CS2 inverts all of that. Accounts are Steam accounts, so a ban means something and stays meaningful. What is unstable is everything you would build detection on. Source 2 changed the networking model, Metamod and SourceMod support arrived late and chases the game, and a Valve update can break an extension's binary compatibility without warning. Each break lands on a volunteer maintainer's schedule, not yours, and while it is broken your detection is off. The effects on server queries and listings are covered in the write-up on the CS2 community server networking update.

That churn is a large part of why community CS2 is still small: roughly 4,020 players across 859 servers, which you can watch move week to week on the CS2 population statistics, against a list of community CS2 servers that turns over faster than any other Source title. Plan for it. Pin plugin versions, keep a staging server, test after every game update before your Friday peak, and write heuristics against game events rather than engine internals, because game events survive updates and memory offsets do not. The most stable ground in the family is still CS:S and Team Fortress 2, where the plugin ecosystem stopped moving years ago and the Team Fortress 2 community servers run detection that has not needed a rewrite since before CS2 shipped.

Related reading

• Running Counter-Strike 1.6 zombie servers, where custom plugins and cheat detection collide most often.

• Stopping DDoS on a small game server, the other attack your regulars notice immediately.

• The Garry's Mod server operator guide, including addon auditing and backdoors.

Frequently asked questions

Does VAC protect my community server?

Partly. Staying VAC-secured means an account Valve bans cannot rejoin your server, which removes the cheapest tier of public cheat user. It does nothing in real time, it bans in delayed waves, and it has no opinion about anything specific to your plugins, your economy or your ranking table.

Can I install EasyAntiCheat on my own server?

No. EasyAntiCheat and BattlEye are licensed to game developers and integrated into the game client, not bolted onto a server by its operator. If your game ships with one, you get it whether or not you want it. If it does not, no amount of configuration will add it.

What is the best free anti-cheat for a SourceMod server?

A maintained SMAC fork plus SourceBans++ for ban management is the standard starting point on CS:S, TF2 and Garry's Mod. Treat it as a detector that files reports, not a judge. Run every module in log-only mode for a month before you let any of them kick or ban.

How do I avoid banning innocent players?

Require two independent signals plus a human demo confirmation before any ban, and make the first ban time-limited rather than permanent. Calibrate every threshold against your own regulars in log-only mode first. Publish an appeal route and actually overturn cases. A zero percent overturn rate means nobody trusts the process.

Is Counter-Strike 1.6 easier to protect than CS2?

Technically yes, socially no. The 1.6 cheat set barely changes, so detection written in 2012 still fires in 2026. But a large share of 1.6 traffic comes from non-Steam clients where identity is forgeable, so bans are hard to make stick. CS2 has the opposite problem: identity is solid, tooling is not.

Should I share ban lists with other communities?

Share detections, import selectively. A shared list is also a shared false-positive list, and you inherit the loosest evidence standard in the group. Subscribe to other communities as a flag that raises a player to review on join, rather than as an automatic ban that you cannot explain to the player.

Anti-cheat on a community server is an operations practice, not a purchase. Configure the cheap layers once, write two or three heuristics and calibrate them honestly, record demos only when something fires, weight your reports, and keep an appeal route that occasionally rules against you. That stack costs a few hours a month and it will hold a public server together. When it is holding, put the server where people can find it: JoinGG polls 11,561 listed servers every hour across 147 games and keeps seven days of history, so a well-run server shows a population curve that speaks for itself. You can add your server to the list for free, compare your peaks against the cross-game population statistics, read how JoinGG measures player counts before you trust any of it, or browse the full server list to see who is doing this well.