NSTAT Command Explained: Network Statistics and Troubleshooting Guide

When a network feels “slow,” the cause is often hidden in counters: retransmitted packets, failed connections, dropped datagrams, or routing errors. The nstat command helps uncover those clues on Linux systems by displaying kernel network statistics in a compact, script-friendly way. It is especially useful for administrators, DevOps engineers, and anyone troubleshooting TCP/IP behavior beyond simple ping tests.

TLDR: nstat shows low-level Linux network statistics, including TCP retransmits, UDP errors, IP forwarding counters, and ICMP activity. For example, running nstat -az TcpRetransSegs can reveal whether a server is losing packets or experiencing congestion. In a real support case, a web server with only 2% CPU usage but a 17% increase in TCP retransmissions over 10 minutes pointed to a network path issue rather than an application bug. Use nstat before and after a test to compare what changed.

What Is the nstat Command?

nstat is part of the iproute2 package and is commonly available on modern Linux distributions. While older tools like netstat focus on sockets, routes, and interface summaries, nstat reads detailed protocol counters maintained by the Linux kernel. These counters come from sources such as /proc/net/snmp, /proc/net/netstat, and /proc/net/snmp6.

In simple terms, nstat answers questions like: Are packets being retransmitted? Are UDP packets failing because no application is listening? Is the system receiving ICMP errors? Are TCP connections being reset? These answers can dramatically shorten troubleshooting time.

Basic Syntax

The basic command is straightforward:

nstat

By default, nstat displays counters that have changed since the last time it was run. This is one of its most useful features, but it can surprise beginners. If you run it and see little or no output, it may simply mean the counters have not changed since the previous snapshot.

To show all counters, including values that have not changed, use:

nstat -a

To avoid updating the history file and preserve the current baseline, use:

nstat -n

To display zero values as well, combine options:

nstat -az

Understanding Common Options

• -a: Shows all counters, not only changed ones.
• -z: Shows counters with zero values.
• -n: Does not update the history file after displaying results.
• -r: Resets the history file, giving you a clean baseline.
• -s: Displays counters in a more compact, SNMP-like format.

A practical workflow is to reset the baseline, run a network test, and then inspect what changed:

nstat -r
curl https://example.com/largefile.iso
nstat

This approach gives you a focused view of what happened during the test window instead of burying you in lifetime system totals.

Important nstat Counters to Know

The output of nstat can look intimidating because Linux tracks many protocol details. However, a handful of counters are especially valuable during everyday troubleshooting.

• TcpRetransSegs: Number of TCP segments retransmitted. A rising value often indicates packet loss, congestion, or unstable links.
• TcpOutSegs: TCP segments sent by the host. Useful for comparing activity against retransmissions.
• TcpInSegs: TCP segments received by the host.
• TcpAttemptFails: Failed outbound TCP connection attempts.
• TcpEstabResets: Established TCP connections that were reset.
• UdpNoPorts: UDP packets received for ports with no listening application.
• IpInReceives: Total IP packets received.
• IpOutRequests: Total IP packets the system attempted to send.
• IcmpInMsgs: ICMP messages received, including errors and echo requests.

For example, if TcpRetransSegs climbs rapidly while TcpOutSegs is stable, you may be dealing with packet loss. If UdpNoPorts increases during application testing, clients may be sending UDP traffic to the wrong port or the service may not be running.

Example: Checking TCP Retransmissions

TCP retransmissions are one of the most useful signals for diagnosing network quality. Occasional retransmissions are normal, especially on busy networks, but frequent retransmissions can indicate serious trouble.

nstat -az TcpRetransSegs TcpOutSegs

You might see output like this:

#kernel
TcpRetransSegs       124
TcpOutSegs           84020

To estimate the ratio, divide retransmitted segments by outgoing segments. In this case, 124 / 84020 is about 0.15%, which is usually acceptable. If the number jumps to 5%, 10%, or higher during a file transfer, video stream, or database replication task, the network path deserves closer inspection.

Example: Troubleshooting Failed Connections

Suppose users report that an internal API sometimes fails to connect. The application logs show timeouts, but CPU and memory look normal. You can check whether the host is experiencing failed TCP attempts:

nstat -az TcpAttemptFails TcpEstabResets

If TcpAttemptFails is increasing, outbound connection attempts are failing before they become established. This may point to firewall rules, routing issues, unavailable services, or connection limits. If TcpEstabResets is rising, connections are being reset after they are already established, which may suggest application crashes, load balancer behavior, or aggressive timeout settings.

Using nstat with watch

For live monitoring, combine nstat with watch:

watch -n 2 'nstat -az TcpRetransSegs TcpAttemptFails TcpEstabResets UdpNoPorts'

This refreshes the selected counters every two seconds. It is a quick way to observe changes while you reproduce a problem. For cleaner analysis, reset the nstat history first:

nstat -r

Then run your test and monitor the counters. This is particularly effective during load testing, VPN troubleshooting, container networking checks, and cloud instance diagnostics.

nstat vs netstat vs ss

Many Linux users know netstat, but it is considered legacy on many systems. The modern replacements are typically ss and tools from the iproute2 suite. Each command has a different job:

• nstat: Shows protocol counters and kernel network statistics.
• ss: Shows socket details, listening ports, connection states, and queues.
• ip: Shows and manages addresses, routes, interfaces, and neighbors.
• netstat: Older all-in-one tool, still useful on some systems but often replaced.

A good troubleshooting session often uses several tools together. For instance, use ss -t state established to inspect active TCP sockets, ip route to verify routing, and nstat to see whether protocol-level errors are increasing.

Practical Troubleshooting Workflow

1. Start with a clean baseline: Run nstat -r before testing.
2. Reproduce the issue: Trigger the download, API call, database query, or user workflow that fails.
3. Check changed counters: Run nstat to see what moved.
4. Focus on relevant counters: Look at retransmissions, resets, failed attempts, and UDP errors.
5. Compare with other tools: Confirm findings with ss, logs, packet captures, or interface statistics.

Tips for Reading nstat Output

Do not panic over a single counter value without context. A server running for 180 days may naturally have large totals. What matters most is the rate of change. If TcpRetransSegs increases by 10 over an hour, that may be harmless. If it increases by 10,000 during a five-minute backup job, that is worth investigating.

Also remember that nstat reports what the local kernel sees. It cannot directly tell you whether a switch is overloaded, a remote server is misconfigured, or an ISP link is dropping packets. However, it provides evidence that helps narrow the search.

Final Thoughts

The nstat command is a small tool with significant diagnostic value. It turns hidden kernel counters into readable evidence, helping you identify retransmissions, resets, failed attempts, UDP problems, and ICMP activity. Used with a clear baseline and paired with tools like ss, ip, and logs, it can quickly separate application problems from network problems. For Linux network troubleshooting, nstat deserves a place in your regular toolkit.