Stop your Reforger server from bleeding bandwidth.
A practical, no-fluff field guide to cutting your Arma Reforger dedicated server's traffic in half without your players noticing a thing. Written for GTX Gaming customers — translates to any host.
Briefing · 01Why your server is eating bandwidth
If you've ever opened your GTX panel mid–session and watched the bandwidth graph climb into the red, you already know: Arma Reforger is hungry. A modest 32–slot Conflict server can easily push 5–15 Mbps upstream, and modded servers running heavy AI and long view distances routinely cross 30 Mbps. For owners on capped lines, on home connections, or on plans with bandwidth–based pricing, that adds up fast — and worse, it shows up to your players as rubber–banding, desync, and floating vehicles.
The good news: Reforger gives you a lot of dials, and most of the bandwidth comes from a small number of them. Cut those, and you can usually halve your traffic without players noticing a thing.
This guide walks through every meaningful setting, in order of impact, using the GTX Gaming Configuration Editor. No JSON. No SSH. No SteamCMD.
Briefing · 02A 30-second primer on Reforger netcode
Before you start changing settings, it helps to understand what you're actually cutting.
Reforger runs on Bohemia's Enfusion engine, which uses a replication model: the server is the source of truth for every entity in the world — players, AI, vehicles, dropped items, projectiles, particle effects — and it streams updates about those entities to every player who can "see" them. The world is divided into network cells, and only the cells around each player get streamed.
Bandwidth–per–player is roughly:
Every setting in this guide attacks one of those three multipliers. The biggest wins come from reducing the number of nearby entities each player gets told about — which is what Network View Distance, Max Players, and AI Limit control.
Briefing · 03Before you start
A few things to do before touching anything:
- Stop the server. Edits made to a running server can get clobbered when it shuts down. Hit Stop in the GTX panel first.
- Back up your config. In Configuration Files, download the current
server.json(sometimesconfig.jsondepending on your template version) to your PC. If you break something, you can re–upload it in ten seconds. - Know your baseline. Watch your bandwidth graph during a typical full session before changing anything. Without a "before" number, you won't know if your changes actually helped.
Reforger config is case–sensitive under the hood, but the GTX Configuration Editor handles that for you. Just fill in the labelled fields and save.
Lower Network View Distance
If you only do one thing on this list, do this.
Network View Distance controls how far around each player the server replicates networked objects. Default is 1500 metres. Range is 500–5000. Every player on your server has a bubble of this radius around them, and the server has to constantly tell them about every replicated thing inside it.
Doubling the radius roughly quadruples the area, which roughly quadruples the entities in the bubble, which roughly quadruples the bandwidth. The relationship is brutally non–linear, which is why this setting is so powerful.
In the GTX Configuration Editor, set:
| Field | Value | Notes |
|---|---|---|
| Server Max View Distance | 1600 | What clients can render |
| Network View Distance | 1000 | What the server streams |
| Server Min Grass Distance | 50 | Anti–cheat against "no grass" players |
Tuning guide for Network View Distance:
- PvP / infantry–focused: 800–1000
- Combined arms / vehicles: 1200–1500
- Long–range / sniper / artillery: 1500–2000 (bandwidth–hungry; only if you have headroom)
Network View Distance must never exceed Server Max View Distance. Clients can't render objects past the max view distance, so streaming them is pure waste. Set Network View Distance equal to or below Server Max View Distance — always.
Lower Max Players
Bandwidth doesn't scale with player count. It scales with player count squared.
Here's a fact that surprises a lot of new server owners: bandwidth scales roughly with the square of player count. Every player has to be informed about every other player's position, animation state, weapon state, and so on. Doubling players doesn't double the work — it roughly quadruples it.
Going from 64 to 48 players doesn't cut 25% of your traffic. It cuts closer to 45%.
Max Players: Start at 32. If your bandwidth graph stays comfortably below your cap during full sessions, bump up to 40, then 48. Don't just set it to what your CPU can handle — set it to what your network can handle.
Cap the AI
Every AI is, to your network, basically another player.
AI units are replicated to clients exactly like players. A Conflict scenario with 150 active AI is, from a network perspective, similar to having 150 extra players walking around.
In the Configuration Editor:
| Field | Value | Notes |
|---|---|---|
| AI Limit | 60 | Default -1 = unlimited |
| Disable AI | false | Set true on pure PvP — kills AI bandwidth entirely |
For a 32–slot Conflict server, AI Limit between 40 and 80 is the sensible range. The mission still spawns objectives and combat, just with fewer simultaneous bots. Players rarely notice the difference once the bullets start flying.
If you're running a pure PvP scenario — King of the Hill, Capture & Hold, custom PvP modes — tick Disable AI and reclaim that bandwidth completely.
Cull your mod list
Some mods are bandwidth–neutral. Some are quietly catastrophic.
Every networked mod adds entities, behaviours, or replicated effects on top of vanilla. The worst offenders:
- Vehicle expansion packs. Each new vehicle is a replicated entity with its own physics, suspension, and turret state.
- AI overhaul mods. Especially ones that "fix" AI by making it more aware — they often spawn more units or run more replicated checks.
- Dynamic event mods. Random patrols, dynamic weather, ambient gunfire — all replicated to every nearby player.
- Heavy particle mods. Smoke, fire, debris effects that spawn per–tick replicated objects.
In Configuration Editor → Mods, ruthlessly remove anything you don't actively need. If a mod's value is "nice to have," it's almost certainly not worth the bandwidth on a server that's already over budget. Test removing mods one at a time and watch your graph.
Cap server FPS
Server FPS isn't client FPS. More is not better.
A Reforger server running at 200+ FPS sends more frequent network updates than one capped at 60. It also burns more CPU, which on a shared host means worse performance overall. There is no meaningful gameplay benefit above ~60 server FPS.
In the GTX panel, open Startup Parameters (left sidebar, near Configuration Files). Most GTX Reforger templates expose a Max FPS field — set it to 60.
If your template uses a raw command line, make sure it includes:
-maxFPS 60Don't go below 30 FPS. Server FPS controls how often the world ticks, including hit registration. Below 30, players will start noticing delayed hits, ghost shots, and physics weirdness.
Stretch Player Save Time
A small win, but free.
This setting controls how often the server writes player state to persistence storage. Each save triggers some network and disk activity. Default is 120 (seconds).
| Field | Value |
|---|---|
| Player Save Time | 300 |
Stretching from 120 to 300 seconds is a small win on its own, but combined with everything else it adds up. The trade–off: if your server crashes, players lose up to 5 minutes of progress instead of 2. For most communities that's acceptable. If your server is rock–solid stable, push it to 600.
Network Dynamic Simulation
Powerful, but easy to misconfigure. Only touch if Steps 1-6 weren't enough.
Skip this step if Steps 1–6 got you where you need to be. These settings are powerful but easy to misconfigure, and the symptoms of bad values (vehicle warping, AI teleporting, objects popping in and out) are unpleasant.
If the GTX Configuration Editor doesn't expose these directly, you can add them as startup parameters:
-nds 8 -nwkResolution 400What they do:
- nds (Network Dynamic Simulation): Number of cells around each player whose physics are fully simulated and replicated. Default is around 12. Lower = less work, more pop–in at the edges.
- nwkResolution: Size of each network cell in metres. Default roughly 500. Larger cells = fewer cell transitions but more entities per cell. Range 100–1000.
- streamingBudget / streamsDelta: Limits on how much data the server will stream per tick. Lowering is a hard cap on bandwidth, but causes visible streaming lag if set too low.
If you change any of these and start seeing vehicles warp or objects flicker, revert immediately.
Section · 04How to test if it worked
After saving your config and restarting:
- Get a representative load on the server. A 6–player test won't tell you anything — you need close to full capacity for bandwidth numbers to mean anything. Schedule a test event, or wait for peak hours.
- Watch the bandwidth graph in the GTX panel's Statistics or Live Console view. Compare against your pre–change baseline.
- Ask your players how it feels. If anyone reports vehicles warping, AI teleporting, or things popping in at the edges of view, you've cut too deep — back off on Network View Distance or
nds. - Check server FPS in console output. It should hold steady at your cap. If it's dropping below, your "bandwidth savings" might actually be CPU savings in disguise.
A 30 to 50 percent drop in average upstream is realistic. 70 percent usually means you've gone too far.
Section · 05Common mistakes
A few traps people fall into:
- Setting Network View Distance higher than Server Max View Distance. Pure waste — the server streams data clients can't render. Always keep
networkViewDistance ≤ serverMaxViewDistance. - Cranking Max FPS to 144+ to "feel smoother." Server FPS doesn't work like client FPS. Anything above 60 just burns resources.
- Forgetting to restart the server. Configuration Editor saves your changes, but the running server doesn't reload them. Stop and start after every edit.
- Cutting AI to zero on a Conflict scenario. The mission needs AI to function. Set a reasonable limit; don't disable entirely unless you're on a PvP scenario.
- Editing while the server is running. GTX usually warns you, but if you save changes mid–session, they may be overwritten on shutdown. Always stop first.
Section · 06The lean preset
If you just want a tested baseline for a 32–slot infantry–focused server on GTX, set:
| Setting | Value |
|---|---|
| Max Players | 32 |
| Server Max View Distance | 1600 |
| Network View Distance | 1000 |
| Server Min Grass Distance | 50 |
| AI Limit | 60 |
| Player Save Time | 300 |
| Max FPS (startup param) | 60 |
This config runs comfortably on GTX's standard Reforger plans, gives players a solid experience, and keeps bandwidth in a sensible range for almost any scenario.
Section · 07When to upgrade your plan instead
If you've done everything above and you're still bumping into bandwidth limits during full sessions, the issue isn't your config — it's your plan. Reforger's per–player bandwidth has a hard floor; you can't get under it without breaking the game.
At that point your options are:
- Move to a higher–tier GTX plan with more bandwidth headroom
- Reduce Max Players to match what your current plan can sustain
- Switch scenarios to one with naturally lower entity counts — Game Master sessions, for example, can be much lighter than Conflict
Bandwidth optimisation gets you a long way. But past a certain point, more players cost more bytes, and there's no clever trick that gets around that.