Network specifications are where hosting is described most loosely. Three different numbers are all called "bandwidth", they limit different things, and a server can be well within one while being throttled by another.
The three numbers
Port speed is how fast data can move at any instant, 1 Gbps, 10 Gbps. It sets your maximum, and it is what determines whether a large file downloads quickly.
Transfer allowance is how much data you may move in a month, measured in terabytes. It sets your total.
Actual throughput is what you get in practice, which depends on the route between you and the visitor and on how busy the provider's upstream links are.
A server can have a fast port, an ample allowance, and disappointing throughput. They are independent.
Which one you will actually hit
For a normal website, neither of the first two.
A busy site serving mostly HTML, images and CSS uses far less than a terabyte a month. The port speed matters only during bursts.
Two workloads change that. Video (streaming or downloads) consumes transfer at a rate nothing else approaches. And backups leaving the server, which are counted and which people forget entirely when estimating.
If you are transcoding and serving video, transfer is your constraint and it should be the first number you look at. ffmpeg-hosting/what-is-ffmpeg-hosting-and-why-do-you-need-it.html">What FFmpeg hosting is walks through that workload.
"Unmetered" and "unlimited" are different words
Read them carefully, because they are used precisely by providers who mean them and loosely by providers who do not.
Unmetered usually means no monthly cap, with the port speed as the real limit. A 1 Gbps unmetered port cannot deliver more than about 320 TB a month regardless: that is the arithmetic, and it is the actual limit.
Unlimited is a marketing word. There is always a fair-use clause, and the honest question is what happens when you exceed it.
Ask specifically: is the connection throttled, is there an overage charge, or is the account suspended? A provider who answers plainly is telling you something useful about how they operate.
Overage is the expensive surprise
Exceeding a transfer allowance is usually billed per terabyte, and the rate is often much higher than the rate implied by the plan.
A viral post, a large file being widely shared, or a misconfigured backup running hourly can produce a bill several times the server's monthly cost.
Set an alert at 70% of your allowance rather than discovering it on the invoice. Most providers offer usage graphs; few send warnings unless you ask.
Traffic that is not your visitors
When usage looks disproportionate to your audience, it usually is.
Crawlers and scanners consume real transfer, and aggressive ones can exceed human traffic on a small site.
Hotlinked images on someone else's busy page bill you for their visitors. Hotlink protection deals with whether it is worth acting on.
Backups leaving the server every night, at the full size of the account if they are not incremental.
A compromised account serving files for someone else. Heavy outbound traffic with no matching visitors is a security incident in place of a capacity problem, and buying more transfer would simply fund it.
Reading the direction
Most providers count outbound traffic and many do not count inbound.
That matters for what you are doing. Serving a website is almost entirely outbound. Receiving uploads. A media site, a backup destination, is inbound, and may be effectively free.
Check which your provider counts before assuming an upload-heavy application is expensive.
Where your visitors are
Throughput depends on distance and on the route, neither of which appears in a specification.
A server in one continent serving visitors in another adds latency that no port speed fixes. Every request pays it, and on a page making many requests it compounds.
Two responses. Choose a location near your audience, which is free and decided once. Or put a CDN in front, which serves cached content from near the visitor and also reduces the transfer counted against your allowance: often paying for itself on a media-heavy site.
DDoS protection is a separate question
An attack fills your port with traffic you did not ask for. The connection is saturated, legitimate visitors cannot get through, and your transfer allowance is consumed by the attack.
Ask what is included. Basic protection at the network level absorbs common volumetric attacks and is often included. Application-level protection (against attacks that look like normal requests) usually is not.
Ask also what happens during an attack. Some providers null-route the target address, which stops the attack and also takes your server off the internet until it subsides. Knowing that in advance is better than learning it during one. Server hardening goes into what you control yourself.
Measuring what you actually have
Test throughput to a few destinations rather than one, because a single slow result may be that destination.
Watch usage over a full month before deciding you need more. Traffic is uneven, and a busy week is not a trend.
And check per-service usage rather than only the total. A single account or a single directory is usually responsible when a number jumps, and finding it is more useful than upgrading. Viewing website statistics goes into the per-account view.
Measure what you actually get, not what was sold
A port speed is a ceiling, and the throughput available to you depends on everything between the machine and the visitor.
curl -o /dev/null -w 'hiz %{speed_download} B/s sure %{time_total}\n' \
https://speed.hetzner.de/100MB.bin 2>/dev/null
iperf3 -c ping.online.net -p 5209 -t 10 2>/dev/null | tail -4
Test to more than one destination and at more than one time of day. A figure that is high to a nearby test point and low to a distant one is a routing or peering matter rather than a capacity one, and no upgrade to the port changes it.
Run the same test from a machine on a different network as well. Comparing the two separates a slow server from a slow path, which are diagnosed and escalated completely differently.
Watch the interface for the errors nobody reports
A network problem rarely announces itself as a network problem. It appears as an application that is intermittently slow.
ip -s link show ethtool -S eth0 2>/dev/null | grep -iE 'err|drop|discard' | grep -v ': 0$' ethtool eth0 2>/dev/null | grep -E 'Speed|Duplex'
Errors and drops that climb mean a cable, a port or a negotiation problem. A link reporting half duplex, or a speed below what the port supports, is a negotiation fault that produces exactly the symptom of a server that is fine under light load and terrible under real traffic.
These counters are cumulative, so record them and compare rather than reading them once. A number that has not moved in a month is history.
Where the traffic is going
Knowing the total is not enough to act. What matters is which destinations and which files account for it.
awk '{s[$1]+=$10} END {for (i in s) printf "%.1f MB %s\n", s[i]/1048576, i}' ~/logs/example.com | sort -rn | head
awk '{s[$7]+=$10} END {for (f in s) printf "%.1f MB %s\n", s[f]/1048576, f}' ~/logs/example.com | sort -rn | head
vnstat -m 2>/dev/null | tail -5
Two patterns dominate the surprises. A single crawler taking a large share, which is fixed by a rule rather than a plan upgrade. And one large file requested repeatedly, which is fixed by moving it somewhere designed for that.
Both are cheap to correct once visible and impossible to correct while the only number available is the monthly total. Stopping bots and scrapers deals with the first.