Fix CS2 Lag and Packet Loss: A Network Tuning Guide
Most "CS2 lag" is not raw ping. A stable 60 ms connection feels fine; a 30 ms connection that jitters and drops packets feels like the game is fighting you. Fix the right thing by measuring first, then changing one variable at a time.
This guide is about your own machine and your own connection. Nothing here proxies or reroutes your traffic through anyone — those "boosters" usually add a hop and make jitter worse.
Read net_graph before you touch anything
Turn on net_graph 1 (or the modern telemetry overlay) and learn the four numbers that matter. Guessing wastes an evening; the graph tells you which problem you actually have.
- ping
- Round trip to the server. Distance sets a floor you cannot beat.
- var (jitter)
- How much ping varies frame to frame. This is the number that ruins a fight. Low ping with high var feels worse than steady higher ping.
- loss
- Packets that never arrived. Any sustained loss above ~0 is a problem; the engine has to guess what it missed.
- choke
- Packets the server or client held back because a rate limit was hit. Choke points straight at the rate cvars below.
Jitter is the enemy, not ping
Your brain adapts to a constant delay within a few rounds — that is why a steady high-ping server still plays honestly. What it cannot adapt to is variance: when the delay changes shot to shot, prediction and lag compensation are working from a moving target, and duels feel unfair in both directions.
So the target of every change below is a narrower spread, not a smaller average. If a tweak drops your average ping by 3 ms but doubles your jitter, it made the game worse.
The rate cvars
- rate
- Set it high enough that a full tick fits without choke on a modern connection; too low and the server holds packets back (visible as choke). Default is conservative.
- cl_interp / interp_ratio
- The interpolation window. Lower feels sharper but is less forgiving of loss; leave interp_ratio at the value your loss can afford — 1 on a clean line, higher if you actually drop packets.
- cl_updaterate / cmdrate
- Match them to the server tick. Asking for more updates than the server sends just adds nothing.
Change one, play a match, read the graph. If choke drops to zero and var is steady, stop — you are done. Chasing cvars past that point is superstition.
Local QoS and adapter settings
- QoS priority
- A local policy that marks the game's packets ahead of everything else leaving the machine, so a background upload cannot bury a movement packet. This is what the Network Stabilizer module does — a policy on your PC, not a reroute.
- Nagle / delayed ACK
- Off for the game. Nagle batches small packets to save overhead; in a twitch shooter that batching is latency you do not want.
- Adapter buffers / interrupt moderation
- Sized so packets are not held to fill a batch. Over-large receive buffers trade latency for throughput you do not need.
- Wi-Fi
- Ethernet if you possibly can. Wi-Fi jitter dwarfs anything the cvars can fix.
When it is the route, not you
If var and loss are high on every server and a wired ping to a nearby site is also spiky, the problem is upstream of your PC — the last-mile link or a bad hop — and no cvar fixes it. Atracert or a monitoring tool like a looping ping to the server IP will show a single hop where latency jumps and stays. That is evidence for your ISP, not a setting to tune.
Fumetsu's Network Stabilizer applies the local QoS and adapter changes above, measures the send/receive spacing as a distribution, and reverts cleanly. It cannot fix a bad route — nothing on your PC can — and it says so. Setup help is on Discord.