Rust Packet Flooding (Player Tick) Kicks: Cause and Server Fix
Rust packet flooding (player tick) kicks explained: the server limit behind them, how to raise it on GSK so it sticks, and the fake convars to skip.
If players on your Rust server are being disconnected with "Kicked: Packet Flooding: Player Tick", the server itself is doing the kicking. It is not a DDoS and not a ban. Rust counts how many movement-and-input packets (called ticks) each player sends per second, and when one player's count reaches a server limit, it drops them. That limit is a server setting, server.maxpacketspersecond_tick, so the fix for Rust packet flooding (player tick) kicks is on the server side, not the player's.
This guide explains what the check does, why normal players trip it, how to raise the limit on a GSK server so it survives restarts, and which "fixes" copied around the internet are convars that don't exist.
What the Kick Actually Checks
We read this straight from the Rust server code rather than from forum guesses. Every packet a player sends has a type, and for each type the server keeps a per-player packets-per-second counter. For tick packets, the check is:
- If this player's tick packets per second are at or above
server.maxpacketspersecond_tick, kick them withPacket Flooding: Player Tick. - The default limit is 300 ticks per second.
A tick carries a player's inputs to the server. The client sends them at the rate set by player.tickrate_cl, which defaults to 32 per second. So an ordinary player sits at roughly a tenth of the limit. Reaching 300 means the server saw nearly ten times the normal number of ticks from one player inside one second.
Why Normal Players Hit the Limit
The counter works on real clock time. Ticks that pile up somewhere and then arrive or get processed together all land in the same second. At the default tick rate, 300 ticks is about nine seconds' worth of input arriving at once. Based on the code, that happens in two situations:
| Pattern you see | Most likely cause |
|---|---|
| Several players kicked at the same moment | The server stalled for several seconds (a long save, a heavy plugin, a hitch), and the queued ticks from everyone were counted together when it resumed |
| The same one player, again and again | That player's connection is delivering ticks in bursts, or their client is modified |
Started after you changed player.tickrate_cl |
You raised the client tick rate. At the maximum of 128 per second, 300 leaves barely two seconds of headroom |
The kick message itself doesn't say which it is, so check the console log. If the kicks cluster around the same timestamp, look at what the server was doing just before.
Fix 1: Raise the Tick Limit
Raising server.maxpacketspersecond_tick gives legitimate bursts room without removing the protection. A value between 600 and 1000 covers stalls two to three times longer than the default allows.
Test it live first. In the panel's Console tab (or over RCON):
server.maxpacketspersecond_tick 600 Then make it permanent. This convar is not one that server.writecfg saves, so running server.writecfg afterwards won't keep it. Use one of these instead:
Option A: server.cfg. Open the Files tab, go to server/myserver/cfg/, and create or edit server.cfg. Add the line without a leading +:
server.maxpacketspersecond_tick 600 Rust reads server.cfg on every start, after its own serverauto.cfg, so your value wins.
Option B: startup argument. On the Startup tab, add this to Additional Arguments (with the +):
+server.maxpacketspersecond_tick 600 Restart, then run server.maxpacketspersecond_tick with no value in the console. It prints the current setting, so you can confirm it took.
Don't set it absurdly high
The limit exists so one client can't flood the server with input packets. Doubling or tripling it fixes the false positives. Setting it to 100000 simply switches the protection off.
Fix 2: Find What Is Stalling the Server
If whole groups of players get kicked together, the limit is only half the problem. Something froze the server for several seconds, and players felt that as rubber-banding before they were kicked.
- Run
server.fpsin the console during normal play and again when kicks happen. A server dropping to single digits is stalling. - Check whether kicks line up with saves. Each save is logged in the console. The panel's default Save Interval is
60seconds, while Rust's own default is600. On a large, busy map, frequent saves are worth ruling out: raise Save Interval on the Startup tab and see whether the kicks stop. - Unload recently added plugins one at a time on modded servers.
- Work through entity counts and hardware limits in Rust Server Lag & Performance.
Convars That Don't Exist
Several guides tell you to set server.maxflood and server.maxtickspersecond. Neither exists in the Rust server code, so adding them to server.cfg or the startup line changes nothing.
The real per-player packet limits, with their defaults in the 2026 server builds we checked, are:
| Kick message | Convar | Default |
|---|---|---|
| Packet Flooding: Player Tick | server.maxpacketspersecond_tick |
300 |
| Packet Flooding: RPC Message | server.maxpacketspersecond_rpc |
200 |
| Packet Flooding: Client Command | server.maxpacketspersecond_command |
100 |
| Packet Flooding: World | server.maxpacketspersecond_world |
1 |
Only change the one that matches the kick your players are actually getting. You can check any of them yourself with find maxpacketspersecond in the server console.
Is It a DDoS or a Cheat?
Usually neither. The check counts packets from a player who has already connected and authenticated, so a network attack on your server isn't what this message reports.
A modified client that deliberately spams inputs would trip this check, and stopping that is why it exists. That is the case for leaving a limit in place rather than disabling it. If one account keeps getting kicked while everyone else is fine, and raising the limit to 600–1000 doesn't stop it, treat that player with suspicion. The combatlog and moderation commands in Rust Admin Commands are the next step.
FAQ
What does "Packet Flooding: Player Tick" mean in Rust?
The server received too many tick (input) packets from one player within a second, at or above server.maxpacketspersecond_tick (default 300), and kicked them to protect itself.
Can a player fix packet flooding on their end?
Not directly. The limit and the kick are server-side. A player with an unstable connection trips it more often, but the fix that works for everyone is the server owner raising the limit and removing server stalls.
What should I set server.maxpacketspersecond_tick to?
Start at 600. If kicks continue during known stalls, try up to 1000. Much higher than that effectively disables the protection.
Why doesn't my setting survive a restart?
server.maxpacketspersecond_tick isn't saved by server.writecfg. Put it in server/myserver/cfg/server.cfg or in the Additional Arguments startup variable.
Does server.maxflood fix packet flooding?
No. server.maxflood is not a Rust convar. Use server.maxpacketspersecond_tick for the Player Tick kick.
Related Rust Guides
- Rust Server Lag & Performance: finding and fixing the stalls behind group kicks.
- Rust Admin Commands: kicks, bans and combat logs for players you suspect.
- Popular Rust Plugins: what to check first if a plugin is the source of the hitching.
- Getting started with your Rust server: the panel's Console, Files and Startup tabs.
Made with 💜 by GameServerKings

Need a Rust server?
Deploy an instantly-provisioned Rust server on high-clock hardware — DDoS protected, no contracts, cancel anytime.
From $13.00 /month