A Source dedicated server has several hundred console variables. About fifteen of them decide whether your server feels good, appears in lists and survives contact with the internet. The rest are either defaults you should not touch or settings that matter only for a specific mod.
The ones that decide how it feels
sv_maxrate and sv_minrate set the bandwidth ceiling and floor per client. Set the ceiling too low and players get a visibly compressed, stuttering picture of the world under load; leave it at zero and it is uncapped, which is usually correct on modern connections.
sv_maxupdaterate and sv_maxcmdrate cap how many world updates a client can request per second and how many command packets it can send. These want to match your tick rate, and setting them above it achieves nothing except confusion.
sv_mincmdrate and sv_minupdaterate are the more useful half of that pair. Raising the floor stops a player with badly configured rates from being a lag source for everyone who has to see them, which is a real effect and one of the few settings that improves other people's experience rather than the setter's.
fps_max on the server controls the server's own frame budget, which is the tick loop. On a dedicated box this should be set deliberately rather than left to whatever the mod's default is; the common wisdom of tying it to tick rate is right.
None of these compensate for hardware. The tick loop runs on one core and single-thread performance is what decides whether it holds — no rate setting rescues a server whose CPU cannot finish a tick in time.
The ones that decide whether you are listed
hostname is the only text most players will read. Twenty useful characters before truncation; the reasoning is in choosing a server hostname.
sv_lan 0 — obvious, and forgotten often enough to be worth stating. Set to 1 and your server is invisible to the internet and works perfectly for you, which is the most confusing possible combination of symptoms.
sv_region tells the master server roughly where you are so region filters work. Getting it wrong means players filtering by their own region never see you, and it is a single digit that nobody checks after installation.
sv_max_queries_sec and sv_max_queries_sec_global are the rate limiters that exist so your server cannot be used to amplify an attack on somebody else. The defaults are sensible. Tightened aggressively — which some hosting templates do — they drop legitimate directory traffic along with the abuse, and the result is a listing that flickers between online and offline for no visible reason. This is the first thing to check when a server keeps vanishing from lists.
sv_password set to anything makes the server private and, on most lists, unlistable. Obvious in isolation; less obvious when it has been left in a config from a test weekend.
The ones that decide whether you get exploited
sv_allowupload and sv_allowdownload control whether clients can push files to the server and pull them from it. Uploads have been an attack surface historically and there is almost never a reason to allow them. Downloads you generally want, but through a separate host rather than the game server — that is what sv_downloadurl is for, and it moves a real amount of traffic off the machine.
sv_pure decides whether clients may use modified game files. Set it to 1 or 2 unless you have a specific reason, or you are running a server where anybody can replace textures with flat colours and see through walls.
rcon_password deserves more care than it usually gets. RCON is remote administration over the network, historically over an unencrypted channel, and a weak password on a public server is an invitation. If you do not use RCON, leave it unset entirely rather than setting something short.
sv_cheats 0 is the default and should stay there. It is worth knowing that a mod can toggle it, and that a server where it got left on after testing behaves in ways that look like an exploit and are not.
The ones people change and should not
sv_gravity, mp_friendlyfire, timescale and their relatives are gameplay decisions, not tuning. They are listed here only because they get changed during debugging and left behind, and a server with odd gravity that nobody chose is a mystery that takes an hour to trace.
net_maxfilesize and the compression settings are worth leaving alone unless you have measured a problem they cause. The defaults were chosen against a large fleet.
How to organise the files
server.cfg runs at startup, autoexec.cfg earlier, and per-map configs run on map change. The failure mode is spreading settings across all three and losing track of which one is winning.
The arrangement that stays maintainable:
autoexec.cfg— things that must be set before anything else: rates, network, securityserver.cfg— everything else, in one file, commented- Per-map configs — only where a map genuinely needs different rules
And keep it in version control, or at minimum keep a copy off the machine. A config that has been edited live for two years by three admins is the most common piece of institutional knowledge to be lost when an owner walks away.
Testing a change
Two rules that save time.
Change one thing. A server that behaves differently after five simultaneous edits tells you nothing about which one did it.
Test at load. Almost every setting in the first section above has no observable effect on an empty server. A rate change judged with two players is a change judged by nobody, and the difference only appears when the tick budget is under pressure.
The corollary is that a config tuned on a quiet Tuesday can be wrong on a busy Saturday, which is the same trap as testing hosting before committing to it.
The short version
Fifteen settings out of several hundred. Rates and fps_max decide feel, sv_lan, sv_region and the query limiters decide whether anybody finds you, and sv_pure, upload permissions and the RCON password decide whether the server stays yours.
Put the network settings in autoexec.cfg, everything else in one commented server.cfg, keep a copy somewhere other than the server, and change one thing at a time under actual load.
Published · 5 min read