CS2 net settings
net_graph reading + the cvars that matter.
CS2’s sub-tick engine made most CS:GO-era network tweaks irrelevant — the engine auto-tunes interp and rate on modern connections. What still matters: reading net_graph, capping FPS to your refresh + headroom, and diagnosing packet loss when it actually appears.
One console command turns it on.
net_graph 1
net_graphpos 1
net_graphproportionalfont 0net_graph 1 shows the standard 5-line readout. net_graphpos controls position (1 = bottom-right, 2 = top-right, 3 = center). The proportionalfont value at 0 keeps the readout small and out of the way.
What net_graph tells you
Five fields that matter, with healthy ranges and what out-of-range values usually mean.
| Field | What it shows | Healthy | Bad sign |
|---|---|---|---|
| fps | Current frames-per-second | Above your monitor refresh × 1.5 | Dipping below refresh during fights → GPU bottleneck |
| ping | Round-trip latency to server | Under 50ms for most regions | Over 80ms → consider a different region or check ISP |
| loss | Packet loss percent | 0% — every percent matters | Above 0.5% → network issue (Wi-Fi, ISP, server) |
| choke | Packets the server dropped before sending | 0 | Above 0 → server-side issue, not yours |
| in/out | Inbound / outbound bandwidth (KB/s) | ~2-8 KB/s in normal play | Sustained ~50+ KB/s → unusual, possibly a different game |
Network + perf cvars worth knowing
Six cvars. CS2 defaults are usually correct — the recommended column is for confirming or troubleshooting.
| Cvar | Default | Recommended | What |
|---|---|---|---|
| rate | 786432 | 786432 | Maximum bytes/sec the server can send you. Default is correct for any modern connection. Lower causes choke; higher does nothing. |
| cl_interp_ratio | 2 | 2 | How many ticks of buffer for interpolation. CS2 sub-tick auto-tunes — leave at 2 unless you see warping enemies on poor connections. |
| cl_interp | 0.015625 | 0 | Manual interp override. CS2 uses sub-tick so this is mostly cosmetic. Setting 0 lets the engine pick the lowest valid value. |
| fps_max | 400 | 400 | Frame cap. 400 is the modern default. Lower (~refresh × 1.5) reduces input latency on G-Sync setups; uncapped is fine if you have headroom. |
| fps_max_menu | 120 | 120 | Menu FPS cap. Keeps the lobby/UI from hammering the GPU. Don't bump above 240 — wastes power. |
| mat_queue_mode | -1 | -1 | Threading mode for material queue. -1 = auto (correct on multi-core CPUs). Setting 2 was a CS:GO trick that no longer applies. |
Loss > 0% in net_graph — where to look.
- 1. Check Wi-Fi. If you’re wireless, switch to ethernet for a round. ~70% of "CS2 packet loss" is the home router.
- 2. Run a ping test.
ping -t 8.8.8.8for 60 seconds. If you see drops, ISP/modem. - 3. Try another server region. If only one region shows loss, it’s a Valve-side relay, not your line.
- 4. Check Steam download region. Mismatched region routing on Comcast/AT&T can cause CS2 traffic to take a long route.
- 5. Restart router. Last resort. If loss persists across all the above, call the ISP — that’s on them.
Cap to refresh × 1.5, leave headroom.
CS2 input latency is dominated by frame time + tick time. With a 240Hz monitor, your render time is ~4.2ms. Capping FPS at 360 (refresh × 1.5) gives the engine consistent frame pacing — uncapped sometimes oscillates and feels worse. With G-Sync / FreeSync, set fps_max to refresh − 5 (e.g. 235 for 240Hz) to stay inside the variable-refresh window and avoid v-sync-style hiccups.
144Hz monitor
fps_max 240 (or 139 with G-Sync)
240Hz monitor
fps_max 360 (or 235 with G-Sync)
360Hz monitor
fps_max 540 (or 355 with G-Sync)
Related