Check Network Performance Problems on Linux

Updated 5 November 2026 · Standard formula, shown below

To check network performance problems on a Linux system, measure throughput, latency, packet loss, and interface errors, then compare results across the local network and the wider internet. Start with basic command-line tools such as ip, ping, and ss; use iperf3 when you need to isolate link speed from internet service performance.

Start with the Interface and Route

First confirm which network interface is active and where traffic is routed. This prevents testing the wrong connection, especially on systems with Ethernet, Wi-Fi, VPNs, containers, or virtual interfaces.

Run ip -br link to see interface names and whether they are up. Then run ip -br address to check for assigned addresses.
Run ip route to inspect routes. The default route usually identifies the gateway used for internet-bound traffic.
Use ip route get 1.1.1.1 to see the route and interface Linux would use to reach that destination. The address is an example public destination, not a guarantee that it will respond to every diagnostic.
For Wi-Fi, run iw dev to identify wireless devices. If available, iw dev wlan0 link shows connection details; replace wlan0 with the actual interface name.

Link state alone does not prove that a connection is healthy. An interface can be up while the cable, access point, gateway, DNS service, or upstream network is failing.

Check Latency and Packet Loss

ping sends diagnostic packets and reports round-trip time and packet loss. Test the local gateway first, then a known external destination:

ping -c 10 192.168.1.1 sends ten packets to an example gateway. Use the gateway address shown by ip route.
ping -c 10 1.1.1.1 checks a public IP address, if that destination permits ping and your network allows it.
ping -c 10 example.com also tests name resolution, because Linux must translate the hostname into an IP address.

Look for loss and variation, not just the lowest time. A stable local ping with poor external results points beyond the computer or local Wi-Fi, while loss to the gateway suggests a local link, wireless, or gateway problem. ICMP packets may be deprioritized or blocked, so a failed ping alone does not prove that a host or service is unavailable. Compare with an application-specific test.

Measure Throughput Separately

A speed test to the internet combines several factors: the computer’s link, router, service provider, remote test server, and current traffic. To isolate the local network, use iperf3 between two computers on the same network. Install it through your distribution’s package manager if it is not already present.

On one computer, run iperf3 -s. On the other, run iperf3 -c 192.168.1.20, replacing the address with the server’s LAN address. The result reports measured throughput for the test interval. Run tests in both directions with iperf3 -c 192.168.1.20 -R, because upload and download performance can differ. Use a trusted local network and stop the server when finished; avoid exposing its listening port to the public internet.

Compare the result with the negotiated link rate, but do not expect application throughput to equal that rate. Protocol overhead, Wi-Fi conditions, hardware limits, and competing traffic reduce usable throughput. If local throughput is healthy but internet throughput is not, investigate the router’s internet connection or upstream path rather than assuming the Linux interface is at fault.

Inspect Errors, Drops, and Active Traffic

Interface counters can reveal physical or congestion problems. Run ip -s link and inspect the RX (received) and TX (transmitted) counters, especially errors and dropped packets. Take two readings several minutes apart while reproducing the issue: counters are cumulative, so a nonzero total may be old rather than evidence of a current fault.

For a more detailed view, ethtool -S eth0 may show driver-specific counters on Ethernet; substitute the real interface. Not every driver supports every statistic, and counter names differ. Increasing CRC or other physical-layer errors can point to a cable, port, or link problem. Drops can have multiple causes, including congestion, buffering, or driver behavior, so interpret them alongside workload and timing.

Use ss -s for a summary of sockets and ss -tpn to inspect TCP connections and processes where permissions allow. These commands help identify many active connections, but they do not measure bandwidth by themselves. For live per-process usage, tools such as nethogs may help if installed; use package sources you trust.

Trace the Path and Check DNS

If the local gateway responds normally but a remote service is slow, trace the route with tracepath example.com, or use traceroute if installed. Each hop represents a router along the path. Missing replies at a hop are common because routers may filter or rate-limit diagnostic traffic; they do not necessarily indicate a fault there. Look for a change that persists across later hops, and compare more than one destination.

To separate DNS delays from connection delays, compare a hostname test with a direct IP test, while remembering that services can use multiple addresses and may require hostnames for correct routing. Check the configured resolver with resolvectl status on systems using systemd-resolved; other Linux distributions may use different DNS management. A slow lookup with otherwise responsive IP connectivity suggests investigating resolver configuration or DNS service availability.

Common Causes and a Useful Test Order

Network symptoms can overlap. Wi-Fi interference may cause variable latency and retransmissions; a damaged cable may produce errors; a saturated link may slow many applications; and a single remote server may be slow even when the network is sound. Change one factor at a time so results remain useful.

Record the time, affected application, connection type, and whether other devices are affected.
Check interface state, address, and route; then test the gateway with ping.
Test an external IP and a hostname, comparing latency, loss, and name-resolution behavior.
Check interface counters before and after reproducing the problem.
Measure local throughput with iperf3 if another computer is available, then compare with a reputable internet speed test.
Repeat at a different time or over Ethernet when possible. A single result is a snapshot, not a diagnosis.

Do not assume that a high Wi-Fi link rate guarantees fast internet, or that a speed-test result identifies the faulty component. The link rate is a connection parameter; actual application performance also depends on congestion, latency, packet loss, server capacity, and protocol behavior.

Frequently Asked Questions

How do I check network speed from the Linux terminal?
Use iperf3 between two computers to measure local throughput. For internet performance, use a trusted speed-test service or command-line tool from a trusted source, and treat the result as a measurement of the full path to that test server.

How can I tell whether packet loss is on my Wi-Fi or internet connection?
Ping the local gateway and then an external destination. Loss to the gateway suggests a local wireless, cable, or router issue; loss only beyond it suggests an upstream path or destination issue. Confirm with repeated tests because diagnostic packets may be filtered.

Which command shows network interfaces in Linux?
ip -br link gives a concise interface and link-state view. Use ip -br address to see assigned addresses and ip route to inspect routing.

Does a failed ping mean the internet is down?
No. A firewall, router, or remote host may block or deprioritize ping while web traffic continues to work. Test the affected application and compare with other destinations.

Why is Linux internet speed slower than the Wi-Fi link rate?
The displayed Wi-Fi rate is not the same as application throughput. Shared airtime, signal quality, interference, protocol overhead, router capacity, and internet service limits can all reduce the measured speed.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.