18.4 Netstat

Introduction

Netstat is a small command line tool that shows what is happening with network connections on a computer. It does not fix problems by itself, but it gives you a clear picture of which programs are talking on the network, which ports are open, and how the system’s routing and interfaces are configured at that moment. In troubleshooting, it sits between very simple tools like ping and very detailed tools like tcpdump or Wireshark.

This chapter focuses on how to read and use netstat output in a practical way. Exact commands and options vary slightly between operating systems, but the core ideas are the same.

What Netstat Can Show You

Netstat stands for “network statistics”. It reads information from the operating system kernel and presents it in a human readable form. Depending on options, it can show:

A key idea is that netstat gives you a snapshot. Each time you run it, you see the current state. For intermittent problems, running it multiple times or in a loop can help catch brief issues.

Typical Netstat Output Structure

Although output formats vary, they usually follow a similar structure. For TCP or UDP connections, you often see columns like:

On many Unix like systems, a line might look like:

tcp 0 0 192.168.1.10:443 203.0.113.5:50932 ESTABLISHED

On many Windows systems, it might look like:

TCP 192.168.1.10:443 203.0.113.5:50932 ESTABLISHED

When options to show processes are used, you may see something like:

tcp 0 0 192.168.1.10:80 0.0.0.0:* LISTEN 1234/apache2

Being able to quickly read local address, foreign address, and state is the core skill when using netstat for connection troubleshooting.

Connection States and Their Meaning

Netstat is especially useful with TCP because TCP has defined connection states. These states tell you where in the lifecycle a connection is. Common states you will see include:

You do not need to memorize every state, but some patterns are very useful for troubleshooting.

If you see many connections in ESTABLISHED to a certain port and that port corresponds to your service, the service is receiving traffic and communicating. If users complain but you see no ESTABLISHED connections, traffic may not be reaching the host or the service may not be bound to the expected address and port.

If you see many SYN_SENT connections to a particular remote address, your system is trying to connect but not completing the handshake. This can suggest a firewall, routing problem, or a remote host that is unavailable.

If you see many CLOSE_WAIT connections owned by the same process, the remote side is closing connections, but the local application is not closing its side correctly. This can be a sign of a bug or resource leak in that application.

Listing Listening Ports

When users cannot reach a service on your machine, the first question is whether anything is actually listening on the expected port. Netstat can answer this.

On many systems, you can ask netstat to show only listening sockets. The output will usually show:

If, for example, you expect a web server on TCP port 80, but netstat shows no listening socket on that port, the problem is local to the host and service, not the network. Either the service is not running, is listening on a different port, or is bound only to a different interface.

Sometimes you will see a service listening on 127.0.0.1:80 which means it only accepts connections from the local machine. If clients on the network cannot reach the service, but local tests work, netstat can reveal this binding mistake.

Mapping Connections to Processes

Modern netstat versions can often show which process owns each socket. This is extremely helpful when you need to know which application is using a certain port, or when you suspect malware or unexpected software.

You will see an extra column, often labelled PID or PID/Program. Once you know the PID, you can use other tools on the system to inspect or manage that process. This helps in several scenarios.

If a port that you expect to be free is already in use, netstat can tell you which program is using it. If a suspected malicious connection is talking to an unknown remote IP, netstat can show which process on your machine is responsible. If you see too many open connections, perhaps from a buggy client, you can check which process holds those connections.

In some cases, you may need root or administrator privileges to see process names for all sockets, especially those owned by other users. Without those privileges, you may see only your own processes.

Netstat and Interface Statistics

Beyond connections and ports, netstat can often display per interface statistics. The typical table for interface statistics includes:

When troubleshooting performance problems, these counters can indicate whether a specific interface is experiencing errors, such as CRC errors or excessive drops. If one interface shows significantly higher error counts than others, the issue might be physical (cable, port, or signal quality) rather than a configuration mistake.

Since these counters are cumulative since boot or since the interface was reset, you can run netstat twice with some time in between to see if errors are still increasing. If the error counters do not move, the current problem may be elsewhere.

Routing Table View

Many netstat implementations include a way to view the routing table. The routing table tells the system where to send packets destined for particular networks. Even though more specialized tools exist for routing, netstat’s routing view is often enough to see basic issues.

A typical routing table view has columns similar to:

For connection problems that affect certain networks but not others, checking the routing table with netstat helps ensure there is a correct route, and that the default route points to the expected next hop. If there is no route to a network, you may see errors at the application level, but netstat lets you confirm this is due to routing.

Using Netstat in Common Troubleshooting Scenarios

Netstat becomes powerful when you combine it with a clear troubleshooting question. It does not test connectivity by itself, but it shows what your system believes about connections, services, and routes.

When a client cannot connect to a service on your host, you can use netstat to confirm that the service is listening on the correct IP and port. If netstat shows the correct listening socket but no incoming ESTABLISHED connections, the issue might be a firewall or a network path problem.

When your host cannot reach an external service, you can use netstat while you attempt the connection to see if connections remain in SYN_SENT or similar states. This points to problems beyond the local machine, such as remote filtering or routing.

When the host seems overloaded by network activity, netstat can reveal many current connections to a single port or remote address. This can be a sign of heavy legitimate use, a misbehaving client, or even a denial of service attack, which will be discussed separately in security topics.

Interpreting Netstat Output Carefully

Netstat output can be long and noisy, especially on busy servers or desktops. It is important to focus on the parts that relate to your current problem and to understand that some long lasting states, like TIME_WAIT, are normal.

Many TIME_WAIT entries alone are not necessarily a problem. They are part of TCP’s design to avoid confusion from delayed packets. What matters more is whether the system runs out of resources, such as available ports, which is discussed under transport layer reliability and scalability.

Also, netstat does not show packet level detail. If you need to know exactly what is inside the packets, tools like tcpdump and Wireshark are a better fit. Netstat’s role is to show the structure and counts of connections and interfaces, not the contents of the traffic.

Key Practical Rule

The most important practical rule when using netstat in troubleshooting is to tie its output directly to specific questions about services, connections, and paths.

By keeping these questions in mind, netstat becomes an efficient part of a systematic troubleshooting approach instead of just a long list of numbers and addresses.