Bandwidth and fair use: what unmetered hosting really means

Most people worry about bandwidth and then use a fraction of a per cent of what would ever be a problem. A twenty-player game server is a steady trickle measured in single-digit megabits. A small web application serves most of its bytes as cached assets that never touch your process. Neither is close to any limit worth discussing. What actually generates traffic is a different list entirely - file downloads, off-site backups, video, and attacks - and it is worth knowing which list you are on before you start comparing transfer allowances between hosts.

This post gives you the numbers: what a player costs, how to turn kilobytes per second into a monthly figure, which workloads genuinely move terabytes, how to measure your own, and what "unmetered" means when somebody has to pay for the uplink.

What a player actually costs in bandwidth#

The figure that matters is outbound from the server, because that is the direction that carries game state to everybody at once. Inbound is much smaller: a client sends key presses and mouse movement, a few kilobytes a second at most.

Three things distort these numbers and are worth knowing about:

• Joins are bursts, not trickles. A Minecraft client joining a fresh area pulls chunk data as fast as the connection allows - several megabytes in a few seconds, which is far above the steady-state rate. Twenty people joining at once after a restart looks like a spike and is completely normal.
• Source-engine games cap themselves. Traffic to each client is bounded by the client's rate convar and the server's sv_minrate and sv_maxrate. The per-client update convars that existed in CS:GO were changed or removed in CS2, so check which ones your title still honours rather than copying a config from 2018.
• Arma 3 is explicitly configurable. MaxBandwidth, MinBandwidth, MaxMsgSend and MaxSizeGuaranteed in basic.cfg are the knobs, and a badly set MaxBandwidth is a classic cause of desync on a server that has plenty of headroom.

Turning kilobytes per second into gigabytes a month#

One conversion is worth memorising, because every bandwidth argument reduces to it:

1 Mbit/s sustained for 30 days  =  324 GB1 MB/s   sustained for 30 days  =  2.59 TB

That is it. From there, multiply players by their per-player rate, convert, and apply a duty cycle, because almost no server is full twenty-four hours a day. A community server that is busy for six hours an evening is at roughly a quarter of its theoretical peak.

Two conclusions fall out of that table. The first is that a normal game server is a low-single-digit-megabit workload, and any transfer allowance quoted in terabytes is irrelevant to it. The second is that the peak matters more than the total: 8 Mbit/s sustained is nothing, but 8 Mbit/s arriving as a two-minute 200 Mbit/s burst is a different conversation, and it is the shape hosts actually care about.

The workloads that really move traffic#

Here is the list that produces real numbers. If you are not on it, stop thinking about bandwidth and go and look at CPU or RAM instead, which is almost certainly your real constraint.

Serving downloads to players. This is the big one for Source-engine communities. Garry's Mod, Counter-Strike and Team Fortress 2 servers distribute maps and content to every new joiner, either through the slow in-game transfer or over HTTP with sv_downloadurl. A 350 MB content pack served to 200 first-time joiners a day is 70 GB a day, or a little over 2 TB a month, from a game server that otherwise uses 8 Mbit/s. Workshop content and FastDL covers doing this without putting it all on the game box.

Resource packs and modpacks. Minecraft's resource-pack key in server.properties is a URL, and the file is served by whatever is at that URL. Point it at your own server and a 60 MB pack downloaded by 500 people is 30 GB you paid for. Point it at object storage or a CDN and it is somebody else's problem. The same applies to modpack distribution for a launcher. MOTD, icons and resource packs has the keys and the SHA-1 requirement.

Off-site backups. A 40 GB server copied off the machine in full every night is 1.2 TB a month of egress, which will be the largest single line in your traffic and produces nothing anybody can see. Deduplicating tools such as restic or borg send the first copy in full and then only the changed blocks, which typically drops a nightly run to a few gigabytes. Backups that actually restore is about the other half of that problem.

Video and audio. The only workload where bandwidth is the primary resource. One 1080p stream at 5 Mbit/s times twenty concurrent viewers is 100 Mbit/s, which is more than every game server in this post combined. If you plan to do this, say so before you buy, not afterwards.

Being crawled. A site with a large product catalogue and no rate limiting can serve more bytes to scrapers and AI crawlers than to humans. Check your access log by user agent before assuming the traffic is real. Rate limits and abuse covers the sensible defences.

Unmetered, unlimited and fair use, said plainly#

Unmetered means we do not bill you per gigabyte. It does not mean one server may saturate a shared uplink indefinitely, because the uplink is shared and somebody else's Valheim world is on the other end of it. That is the whole policy, and it is worth stating in full because the industry usually does not.

What that means in practice:

• A game server, an application, a bot or a website doing normal work will never come near a conversation about traffic. Do not size a plan around bandwidth.
• If you intend to distribute large files at volume, run a media service, or push full backups off-site every hour, tell somebody first. There is usually somewhere it does not affect anybody, and arranging that before you start is a five-minute conversation rather than a support ticket about your server being slow.
• Sustained saturation is the thing that gets noticed, not the monthly total. Ten terabytes spread over a month is invisible. Two terabytes in one afternoon at line rate is not.

Compare that with the alternative wording you will see elsewhere. "Unlimited bandwidth" with a clause about "acceptable use" usually means the same thing and says less about it. What you want from a host is a number or a sentence, not an adjective. When you are comparing, ask two questions: is there a per-gigabyte charge, and what happens if I sustain a high rate for a day. How to choose game server hosting has the rest of the checklist.

Attack traffic is bandwidth you did not ask for#

The largest bandwidth event most servers ever see is not caused by the owner. A volumetric flood is traffic addressed to you, generated by somebody else, arriving whether you want it or not. You cannot switch it off from inside the machine, and any counting you do of "your" usage does not include it.

What is real about filtering: upstream filtering drops obvious volumetric floods, reflection and malformed traffic before it reaches the hardware. What is not real is the implication in most hosting marketing that this makes attacks a solved problem. Attacks that look like real players are not filtered, because there is no way to tell them apart at the network layer without also dropping real players. A host that promises no downtime under any attack is selling you a sentence, not a service. What we actually do about attacks and DDoS attacks on game servers explained go into the mechanics.

One thing you can control is whether your own server becomes a source of somebody else's flood. Query ports that answer a small request with a much larger response are usable as reflectors, which is why the Source engine's server query protocol grew a challenge step. If a query port is generating outbound traffic wildly out of proportion to the players online, that is what is happening. Keep server software current, and do not expose a query or RCON port more widely than you need - RCON safely is short and worth it.

Measuring what you are actually using#

Guessing is unnecessary. On a machine you control, vnstat is the least effort for the most useful answer, because it keeps history:

$ apt install vnstat$ vnstat -i eth0 -d        # by day$ vnstat -i eth0 -m        # by month$ vnstat -i eth0 -l        # live

For a live look at who is consuming it right now:

$ iftop -i eth0 -B         # per-connection, in bytes$ nload eth0               # a simple in/out graph$ ip -s link show eth0     # cumulative counters since boot

For a web application, the honest number is in the access log rather than the interface counter, because it excludes everything the reverse proxy served from cache. Add the byte count to your log format and sum it:

log_format bytes '$remote_addr $status $body_bytes_sent "$request"';access_log /var/log/nginx/access.log bytes;

$ awk '{ sum += $3 } END { print sum/1024/1024/1024, "GB" }' \    /var/log/nginx/access.log

On a panel-based host you will not find a bandwidth graph, because the console graphs memory, CPU and disk against the limits rather than traffic. That is a real gap and worth saying: if you need per-month traffic figures, measure them inside the server with vnstat or from your application logs. Reading a server load graph explains what the graphs you do get are telling you.

Cutting traffic without cutting features#

If you are genuinely moving a lot of bytes, the fixes are cheap and none of them involve a bigger plan.

• Move downloads off the game server. Put FastDL content, resource packs and modpacks on object storage or behind a CDN. The game server then serves a URL rather than a file, and the traffic stops being yours. This is the single biggest win available to a Source-engine community.
• Compress what you serve. Gzip or Brotli on text responses typically cuts HTML, CSS and JavaScript by 70-80 per cent. It is one directive and it applies to every visitor.
• Cache with long lifetimes on hashed assets. Cache-Control: public, max-age=31536000, immutable on a file whose name contains a content hash means a returning visitor downloads it once, ever. HTTP caching headers explained covers the whole set, including why a badly set ETag can undo all of it.
• Use deduplicating backups. The first run is full, every run afterwards is the delta. This routinely takes a nightly backup from tens of gigabytes to hundreds of megabytes.
• Tune the game's own network settings. Minecraft's network-compression-threshold in server.properties defaults to 256 bytes, which is a reasonable trade of CPU for bandwidth; raising it sends more bytes and uses less CPU, and -1 disables compression entirely and is only sensible on a LAN. view-distance and simulation-distance cut CPU and bandwidth together.
• Serve images at the size you display them. The most common cause of a heavy page is a 3000-pixel photograph in a 400-pixel slot.

Bandwidth is not latency, except when it is#

The most common confusion in this whole subject: adding bandwidth does not reduce ping. A gigabit link and a hundred-megabit link to the same destination have the same propagation delay, and a game that needs 15 KB/s per player is not helped by having ten times more headroom than it uses. If your players complain about lag, the answer is almost never bandwidth. It is distance, a bad route, jitter, packet loss, or a server that is CPU-bound. Latency, jitter and packet loss is the post for telling those apart.

The exception is real and worth knowing. When a link is actually saturated, packets queue, and queuing is latency. A server running a full backup over the same interface its players are using will show a ping increase for the duration, not because bandwidth is low but because the queue in front of the interface is full. That is why backups belong at four in the morning, and why a rate limit on an outbound copy job is sometimes kinder than letting it finish faster:

$ rsync -a --bwlimit=10000 /srv/worlds/ backup@198.51.100.5:/srv/worlds/

--bwlimit is in kilobytes per second, so 10000 caps that transfer at roughly 80 Mbit/s and leaves the rest of the pipe for the people playing.

FAQ#

How much bandwidth does a Minecraft server use per player?

Roughly 5-20 KB/s in steady state, which is about 2 Mbit/s for a busy twenty-player server. Joins and teleports burst much higher for a few seconds while chunks stream. A larger view-distance raises both the steady rate and the burst.

Is unmetered bandwidth really unlimited?

It means you are not billed per gigabyte. It does not mean a single server may saturate a shared uplink for days. In practice nothing that looks like a game server, a bot, an API or a website will ever reach that line, and the workloads that do - bulk file distribution, media streaming - are worth a conversation before you start.

Will a bigger plan give me more bandwidth?

Not usefully, and it is almost never what you needed. Plans are sold on memory, disk and CPU share. If a server feels slow, the constraint is nearly always one of those three, or the network path between the player and the machine, not the volume of data you are allowed to move.

How do I find out how much traffic I have used?

Measure it inside the server: vnstat -m for a monthly total on a machine you control, or sum $body_bytes_sent from your web server's access log for an application. Panel graphs show memory, CPU and disk rather than traffic, so they will not answer this one.

Does a DDoS attack count against my usage?

No, and it would be an odd way to run a service if it did. Attack traffic is generated by somebody else and addressed to you. Upstream filtering drops the obvious volumetric kind before it reaches the machine; floods that imitate real player traffic are a harder problem and honest hosts say so.

What is the cheapest way to distribute a 500 MB modpack?

Not from the game server. Put it on object storage or behind a CDN and give players the URL. That turns a recurring terabyte into somebody else's bandwidth bill, usually for a few dollars, and it downloads faster for the player as well.