Rust Server Running at 1 FPS or Rubberbanding? The fps.limit Trap - Rust Wiki

Rust Server Running at 1 FPS or Rubberbanding? The fps.limit Trap and How to Fix server.fps

Last verified: June 2026 against the current RustDedicated server build.

There is a specific, nasty Rust server failure that does not look like a normal performance problem. Players rubberband constantly. They snap back several meters after running. Rockets and melee hits do not register. Reloads stall and ammo reappears in the magazine after a shot. Yet you check the box and the CPU is almost idle, RAM is fine, and the network graph is flat. Everything that usually causes lag looks healthy.

If that matches your server, the first number to look at is not CPU usage. It is server.fps. When a Rust server is rubberbanding while the hardware looks fine, server.fps is very often pinned at 1 or 2. This guide explains why that happens, why a misconfigured fps.limit is one of the most common causes, and how to get the server back to a high tick rate.

server.fps Is Not the Same as Your Players' FPS

This is the part that confuses most admins, so it is worth being precise. There are three separate numbers in play and they are easy to mix up:

• server.fps - the rate at which the server simulates the world, one full simulation pass per "frame". This is a server-side value and it has nothing to do with the frame rate on any player's screen. It is the heartbeat of the simulation.
• server.tickrate - how often the server sends networked state updates to clients per second (commonly 30 on a vanilla server). Tick rate is about network update frequency, not simulation speed.
• Client FPS - the frame rate inside a player's game, driven by their GPU and CPU. The server has no direct control over this.

The simulation runs on server.fps. Physics, movement, projectiles, animals, doors and entity logic are all advanced once per server frame. When server.fps drops below roughly 25, the simulation falls behind real time. Movement stutters, physics calculations lag, and hit registration breaks. When server.fps sits at 1, the server is effectively advancing the world once per second. Players keep moving on their own clients, the server corrects them a full second later, and the result is the classic teleport-backwards rubberband. Rockets fired in that window are resolved late or dropped entirely. The network and CPU look fine because the server is barely doing any work - it is choosing, incorrectly, to run almost no frames.

How to Measure server.fps

Before you change anything, confirm the actual value. Do not guess from CPU graphs.

Via RCON or the F1 Console

# Type this in the in-game F1 console (as admin) or over RCON
server.fps

The server prints a single number. On a healthy server you will see a value at or near your configured limit, for example server.fps: 256 or server.fps: 60. If you see server.fps: 1 or server.fps: 2 while players are rubberbanding, you have found the problem.

It is worth pairing that reading with a couple of related values so you can rule out other causes in the same pass:

server.fps          # current simulation frame rate (the key number)
fps.limit           # the configured cap - check what it is actually set to
server.tickrate     # network update rate, separate concern
perf 2              # on-screen performance overlay, shows server FPS live

Trust the live server.fps reading over what your config file says. Config and runtime can disagree, and that disagreement is itself a clue, as the next section explains.

The fps.limit Trap

The fps.limit convar sets the maximum frame rate the server is allowed to run at. Used correctly it is harmless and even useful: capping a low-population server at 60 keeps CPU usage down with no gameplay impact, and Facepunch has long noted that players cannot tell the difference between a 30 FPS cap and a higher one on a normal server.

The trap is in the values. A bad fps.limit does not produce a warning or an error. The server boots normally, reports itself online, and then quietly simulates at a crawl. There are two ways to fall into it.

1. Zero or Negative Values

Setting fps.limit to 0 tells the server to allow zero frames, which is meaningless and can leave the simulation effectively stalled. Negative values are worse and more confusing, because admins reach for them on purpose. Many guides suggest fps.limit -1 as a way to say "no cap, run unlimited." On some configurations that works as intended. But it is fragile, and where it goes wrong it goes very wrong: instead of being read as "unlimited," the value can end up clamped to an extremely low frame rate, which is exactly the 1 FPS state described above.

2. Command Line vs Config Precedence

This is what makes the fps.limit trap so hard to diagnose. Rust applies configuration in a specific order, and the command line wins:

• Command-line arguments (the launch flags such as +fps.limit ...) are applied as the server boots and take precedence over the config files.
• server.cfg / serverauto.cfg are applied afterwards (serverauto.cfg auto-loads at start; server.cfg may need to be read in).

The consequence: if a bad fps.limit is baked into your launch command line, no amount of editing serverauto.cfg will save you. You can set fps.limit 256 in the config, restart, run server.fps, and still see 1, because the command line set the value first and the boot-time launch flag won. This is precisely why the live server.fps reading can disagree with your config file. A config-only guard cannot beat a command-line convar. You have to fix the launch command itself, or override the value at runtime after boot.

The launch flag to watch for looks like this, and it is the thing to remove or correct:

# Problematic - a negative value passed at launch can collapse the tick
RustDedicated -batchmode ... +fps.limit -1

# Safe - a positive cap passed at launch
RustDedicated -batchmode ... +fps.limit 256

The Fix

There are two parts to a durable fix: correct the running server now, and make sure the bad value is not reintroduced at the next launch.

Step 1 - Fix the Running Server Immediately

Over RCON or the F1 console, set a positive limit and persist it:

fps.limit 256
server.writecfg

Setting fps.limit 256 takes effect live. The simulation frame rate should jump within a second or two. Re-check it:

server.fps

You want to see a value that climbed from 1 up toward your cap - for example server.fps: 250 on a server capped at 256. If it moved, the diagnosis was correct. server.writecfg persists the relevant runtime configuration so the corrected state is written to disk rather than living only in memory.

Step 2 - Fix the Launch Command

Because the command line overrides the config, the runtime fix alone is not enough if a negative or zero fps.limit is still in your start script. On the next restart the bad launch flag would win again and the server would drop back to 1 FPS. Open your start script or hosting panel's launch parameters and either:

• Remove any +fps.limit -1 or +fps.limit 0 from the command line entirely, and let the config set the value, or
• Replace it with an explicit positive value: +fps.limit 256.

Restart once, run server.fps one more time, and confirm the value holds at the cap after a clean boot. That confirms the fix survives a restart and is not just a temporary runtime override.

Other Causes of Low server.fps to Rule Out

The fps.limit trap is the cause that fools people, because the hardware looks innocent. But a genuinely overloaded server will also report a low server.fps - the difference is that on an overloaded server the CPU is actually pegged. If you have fixed the fps.limit value and server.fps is still low while a CPU core is sitting at 100 percent, the cause is real work, not a misparsed convar. Rule out the usual suspects:

• Entity and save bloat. A map that has run for weeks without a wipe accumulates enormous numbers of deployables, foundations and dropped items. Every one is simulated each frame. A bloated save file drags the whole tick down. A wipe, or targeted entity cleanup, is the cure.
• Blueprint and base sprawl. Megabases with thousands of building blocks and stacked electrical or industrial setups are expensive to simulate. The structural integrity and decay systems re-evaluate large bases frequently.
• Industrial automation. Conveyors, smelters and the fluid system run on the server tick. Large automated farms can cost real frame time - see our dedicated guide on industrial automation performance.
• Mod and plugin load. A single badly written Oxide or Carbon plugin that hooks a hot path such as OnPlayerMove or runs synchronous work every frame can flatten server.fps. Disable plugins one at a time to isolate the culprit.
• Genuine CPU limits. Rust is heavily single-thread bound. If you are running 200 players on a slow core, you may simply be out of headroom. See the performance optimization guide for sizing and tuning.

The diagnostic order matters. Check server.fps first, then check whether a CPU core is actually saturated. If server.fps is at 1 and the CPU is idle, you are almost certainly looking at the fps.limit trap, not a hardware problem. If server.fps is low and the CPU is pegged, you are looking at real load and should turn to entity counts, plugins and hardware.

Quick Reference

How Managed Hosting Avoids This

The reason this bug is so persistent is that it hides. The server reports online, the dashboard shows green, the CPU graph looks healthy, and only the players feel it. An admin who does not know to check server.fps by hand can burn hours blaming the network or the hardware. The fix is trivial once you know where to look, but knowing where to look is the whole battle.

This is exactly the class of misconfiguration a managed host should never let reach a customer. On Supercraft's Rust hosting the FPS configuration is shipped correct out of the box: servers launch with a sane positive frame-rate cap, never a negative value on the command line, so they run at a high tick rate from first boot. RCON is exposed live in the panel console, so checking server.fps is one line away if you ever need it, and the branch picker keeps staging-versus-stable launches clean so a bad flag does not creep into your start command.

Related Guides

• Rust Server Performance Optimization - hardware sizing, entity limits, and broad tuning.
• Rust Server Troubleshooting - the full list of common server problems and fixes.
• Multithreaded Networking - the networking-side performance lever, a different concern from server.fps.
• Industrial Automation Performance - how conveyors, smelters and fluids cost server frame time.

Stop the rubberbanding for good. Host your Rust server with Supercraft and get a correct FPS configuration, live RCON, and infrastructure tuned for a high server tick rate from the first boot.