5 Common Network Bottlenecks and How to Detect Them

What is a network bottleneck?

A network bottleneck is the slowest component in a data path. It sets the ceiling for every transfer that crosses it. Upgrading anything else changes nothing. Finding it means measuring each segment on its own until one measures far below the rest.

Every transfer crosses several components in sequence. A file leaving a NAS passes through a disk, a network card, and a cable. Then come one or more switches, sometimes a router, and the receiving device. The slowest of those sets the speed.

This is why upgrades so often disappoint. A 2.5 GbE card in a NAS does nothing if the laptop reading from it sits on Wi-Fi. A gigabit internet plan does nothing if the router cannot forward at that rate.

The practical problem is that a network bottleneck rarely announces itself. Links stay up. Speed tests pass. The only reliable approach is measurement, one hop at a time.

How to find a network bottleneck: test one segment at a time

Start with the shortest possible path and add one segment at a time. Test two wired devices on the same switch first. Then add the router, then Wi-Fi, then the internet. The first step where throughput drops sharply contains the bottleneck.

The tool for this is iperf3, which measures throughput between two machines without touching storage. That last detail matters, because it separates network problems from disk problems.

Run the server on one machine and the client on the other. The default port is 5201.

# On the receiving machine
iperf3 -s

# On the sending machine
iperf3 -c 192.168.1.50 -t 30

Then walk up the ladder. Each rung adds exactly one component to the path.

1. Two wired devices, same switch. This is your best case. Anything slower later is caused by what you added.
2. Two wired devices, across an uplink. Now the switch-to-switch link is in play.
3. Wired device to router, or across the router. This brings the router CPU into the path.
4. Wireless device to a wired device. The drop here is your Wi-Fi cost.
5. Internet. Only now does your ISP plan matter.

Compare each rung to the one before it. A small drop is normal, so ignore it. A drop of more than half points at the network bottleneck you just added.

If a step fails outright rather than running slowly, the problem is connectivity rather than capacity. Our step-by-step network connectivity guide covers that path instead.

Bottleneck 1: Wi-Fi is slower than its label suggests

Wi-Fi throughput lands near 70% of the negotiated link rate, and often lower. A 1200 Mbps connection delivers roughly 840 Mbps of real data. Distance, interference, and shared airtime push it lower still. Wi-Fi is the most common bottleneck in a home network.

The number your device reports is the PHY rate, not throughput. It describes how fast bits go out over the air during a transmission. It excludes acknowledgements, contention, retries, and management traffic.

Field testing across generations puts real throughput between 60% and 80% of the PHY rate. Treat 70% as the working estimate. A ratio near 50% means something is wrong, usually interference or a busy channel.

Airtime is shared, not divided

Every device on a channel takes turns. A slow client at a low data rate holds the channel longer than a fast one. Both move the same amount of data. That single device drags down everyone else.

Neighbouring networks on overlapping channels have the same effect. On 2.4 GHz, only channels 1, 6, and 11 avoid overlap entirely.

How to confirm Wi-Fi is the limit

Run the same iperf3 test twice from the same laptop. First over Ethernet, then over Wi-Fi, to the same wired target. If the wired result is healthy and the wireless result collapses, you have your answer.

Then check the reported link rate at that spot. If throughput sits near 70% of it, Wi-Fi is working correctly and simply cannot go faster there. If throughput sits near 40%, the radio environment needs attention.

Bottleneck 2: one slow link in an otherwise fast chain

A single 100 Mbps port, a damaged cable, or a duplex mismatch caps every transfer crossing it. The link still shows as up, so nothing looks broken. Check negotiated speed and duplex at both ends of every hop before blaming bandwidth.

This failure wastes the most time. The symptom looks like general slowness rather than a specific fault. Two of its forms are worth knowing.

Damaged cabling that still links up

Ethernet negotiates down rather than failing. A cable with a crushed or broken pair often drops from 1000 Mbps to 100 Mbps and keeps working. Nothing warns you. Throughput simply sits near 94 Mbps forever.

Check the negotiated speed directly rather than trusting the link light.

# Linux
ethtool eth0

# Windows PowerShell
Get-NetAdapter | Format-Table Name, LinkSpeed, Status

# macOS
networksetup -getmedia Ethernet

Duplex mismatch

A mismatch happens when one side is forced to a setting and the other auto-negotiates. The auto side falls back to half duplex, and the two ends disagree about whether they can transmit at once.

Per Cisco’s auto-negotiation reference, the giveaway is late collisions counted on the half-duplex side, often with FCS errors. Ping still succeeds. Anything sustained collapses.

Gigabit Ethernet requires auto-negotiation by specification. Hard-coding speed and duplex on a gigabit link causes more problems than it solves. Leave both ends on auto.

Bottleneck 3: your router’s CPU, not your bandwidth

Routers forward packets with a processor, and that processor has a ceiling. NAT, VPN tunnels, packet inspection, and queue management all consume cycles. Once the CPU saturates, throughput flattens well below the line rate on your bill.

This is the network bottleneck people least expect, because the hardware looks capable on paper. Consumer routers hit their advertised numbers by offloading forwarding into dedicated hardware. Turn on a feature that hardware cannot handle, and everything falls back to the main processor.

Three features commonly trigger that fallback:

• VPN termination. Encryption is expensive. A router advertising gigabit routing may manage 100 Mbps through a WireGuard tunnel.
• Smart queue management. Shaping traffic to fix bufferbloat disables hardware acceleration on many platforms.
• Deep packet inspection. Security suites that classify every flow add per-packet cost.

The OpenWrt SQM documentation notes that fq_codel costs roughly 15% less CPU than CAKE. That gap matters once the router is the ceiling. Multi-core CAKE, shipped as cake-mq from OpenWrt 25.12, aims to spread that cost across cores.

How to confirm the router is the limit

Watch processor load during a transfer. Open the router’s status page or an SSH session, then start a sustained iperf3 run through it. A core pinned near 100% while throughput sits flat is conclusive.

The second test is simpler. Disable the suspect feature, retest, and re-enable it. If throughput doubles with queue management off, you have found the trade-off rather than a fault.

Bottleneck 4: latency and bufferbloat, not throughput

Some bottlenecks never appear in a bandwidth number. Bufferbloat adds hundreds of milliseconds of delay under load while the speed test still passes. Measure latency while the link is saturated, not while it sits idle, or you will miss it entirely.

Oversized buffers queue packets instead of dropping them. Throughput stays high, but everything waits in line. Calls stutter, games lag, and pages hesitate before loading.

The test takes a minute. Start a continuous ping, then saturate the connection and watch what happens to the numbers.

# Leave running
ping -t 1.1.1.1        # Windows
ping 1.1.1.1           # macOS and Linux

# Then start a large download or speed test

Judge the increase, not the raw value. A rise under 20 ms is healthy. A rise past 100 ms explains real, visible lag. Our guide to slow internet when the speed test looks fine walks through the full diagnosis.

The fix is active queue management, standardised as FQ-CoDel in RFC 8290. Most modern router firmware exposes it as SQM or adaptive QoS.

Our guide to reading ping results explains each field of that output. The Ping and Packet-Loss Interpreter summarises a pasted result for you.

Where the delay sits in the path

Latency that appears only beyond a certain hop points outside your network. A traceroute shows which hop introduces the jump. That tells you whether to call your ISP or keep looking at home.

Bottleneck 5: the disk at the end of the transfer

On gigabit, almost any modern drive keeps up. Above gigabit, storage often becomes the limit instead. A single hard drive reads roughly 100 to 200 MB per second sequentially. Small files drop it far lower.

Gigabit Ethernet tops out near 118 MB per second, so one hard drive usually saturates it. Move to 2.5 GbE and the arithmetic flips. The network can now accept about 295 MB per second, which no single spinning disk delivers.

Small files make it worse. A folder of thousands of tiny files forces per-file overhead on both the filesystem and the sharing protocol. Sequential speed becomes irrelevant.

The test that settles it

Compare iperf3 against a real file copy between the same two machines. iperf3 generates data in memory and never touches storage.

• iperf3 fast, file copy slow. The network is fine. Look at storage or the sharing protocol.
• Both slow. The network is the problem. Return to the segment ladder.

That single comparison saves more time than any other test in this article. Our guide on how long a file transfer should take covers the underlying arithmetic.

One more hidden limit: packet size

A path that fragments packets, or silently drops oversized ones, produces slow transfers with healthy ping times. VPN tunnels and PPPoE both shrink the usable packet size. Our guide to MTU and why packet size breaks large transfers covers the symptoms. The MTU Path Calculator gives you the value to set.

Baseline numbers that reveal a network bottleneck

Baselines turn a vague complaint into a measurement. Record what each link achieves while the network is healthy. Later, a number sitting far below its baseline points straight at the segment that changed, without any guesswork.

The figures below are realistic sustained throughput, not marketing numbers. Anything far under its baseline is a network bottleneck worth chasing. Use them to judge whether a result is normal or genuinely poor.

Wi-Fi figures assume a healthy channel and a two-stream client, which covers most laptops and phones. Wired figures come from standard 1500-byte frames with normal TCP overhead, matching the arithmetic in NetApp’s gigabit throughput breakdown.

Related tools and guides

These tools and guides cover the individual measurements this article strings together. Use the interpreters when you have output but are unsure what it means. Use the calculators when you need a target value before changing a setting.

• Ping and Packet-Loss Interpreter — paste raw ping output and get a plain-language summary of loss and latency.
• MTU Path Calculator — stack VPN, PPPoE, and VLAN overhead to find the right interface MTU.
• How to Troubleshoot Network Connectivity — the seven-step sequence for a link that fails rather than crawls.
• Can You Split Your PC’s Network Traffic? — why two routers rarely help, and what queue management does instead.
• Traceroute Explained — read each hop and find where latency enters the path.

Frequently asked questions

These are the questions that come up most when a network feels slow but the cause is unclear. Each answer points to the measurement that settles it. Test before buying hardware, because most suspected bandwidth problems turn out to be something else.

How do I know if the bottleneck is my network or my computer?

Run iperf3 between the two machines and watch processor use on both. If iperf3 reaches the expected rate, the network is fine. A slow file copy after a fast iperf3 result points at storage, the sharing protocol, or the application.

Will a faster internet plan fix a network bottleneck?

Only if the internet link is the slowest part of the path. If your router, Wi-Fi, or cabling caps throughput below your current plan, a larger plan changes nothing. Measure the local segments first, then decide.

What is the best tool for finding a network bottleneck?

iperf3 is the standard, because it measures the network alone and never touches disk. Pair it with a continuous ping for latency under load. Between them they separate bandwidth problems, latency problems, and storage problems.

Why is my file transfer slow when the speed test is fast?

Speed tests measure the internet path, not your local network. A transfer between two devices in your home never touches that path. Test locally with iperf3 to see what your own switches, cables, and Wi-Fi actually deliver.

Can a bad Ethernet cable cause a bottleneck?

Yes, and it is common. A damaged pair makes the link negotiate down to 100 Mbps instead of failing. Everything keeps working at one tenth the speed. Check the negotiated link speed on both ends before replacing anything else.

Does link aggregation remove a network bottleneck?

Not for a single transfer. Bonded links assign each session to one physical port, so one copy still runs at the speed of one link. Aggregation raises total capacity across many simultaneous sessions instead.

References

These are the primary sources behind this article’s technical claims. They cover Ethernet auto-negotiation and duplex errors, gigabit throughput arithmetic, active queue management standards, and the measurement tools referenced throughout. Each entry links to the original publisher.

• Cisco — Configure and Verify Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation
• Cisco — Troubleshooting Ethernet Collisions
• NetApp — What is the theoretical maximum throughput of a Gigabit Ethernet interface?
• IETF — RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm
• IETF — RFC 8289: Controlled Delay Active Queue Management
• ESnet — iperf3 Documentation
• OpenWrt — SQM (Smart Queue Management)