Linux online course

Linux netstat Command: Connections, Listening Ports, Routes, and Interface Statistics

Learn how to use Linux netstat to inspect sockets, listening ports, processes, TCP states, protocol statistics, interfaces, and routes, plus modern ss alternatives.

netstat reports information from the Linux networking stack. It can show active network sockets, services waiting for connections, routing information, network-interface counters, and protocol statistics.

A socket is a network communication endpoint used by a process. A socket is commonly identified by a protocol, an IP address, and a port. A port is a transport-layer number that identifies an application or service endpoint.

For command-line background, see Linux and Bourne Again Shell Bash.

Basic netstat usage

Running netstat without options displays its default connection report:

netstat

The default view generally focuses on active network connections rather than every socket on the system. Output commonly includes columns such as protocol, receive and send queues, local endpoint, remote endpoint, and a TCP state.

Viewing all sockets and listening services

The -a option includes both active connections and listening sockets:

netstat -a

A listening socket belongs to a server process waiting for incoming connection requests. An established socket represents an active client-server session. Checking listening sockets is useful after starting a daemon because it verifies that the daemon opened the expected port.

Filtering TCP and UDP sockets

Use -t for TCP and -u for UDP. They can be combined:

netstat -t
netstat -u
netstat -tu
netstat -atu

The common combination -atu shows all TCP and UDP sockets, including listening sockets. UDP is connectionless and does not use TCP's handshake and lifecycle states, so UDP output normally lacks a meaningful State column.

Numeric addresses and ports

Use -n to prevent hostname and service-name resolution:

netstat -atun

Without -n, netstat may translate IP addresses through DNS and port numbers through the local service database. Numeric output is usually faster, avoids DNS delays, and makes troubleshooting less ambiguous. For example, 192.0.2.10:443 identifies a local HTTPS endpoint, while 198.51.100.20:53124 identifies a remote address and ephemeral client port.

Finding the process that owns a port

The -p option requests the PID and program name associated with each socket. Seeing every process often requires administrative privileges:

sudo netstat -tulpn

This command lists listening TCP and UDP sockets, uses numeric addresses and ports, and shows process ownership. It is useful when a service cannot start because a port is already in use, or when an unexpected service is listening.

For a web-service problem, first check whether the expected port is listening, whether it is bound to all interfaces or only loopback, and whether the expected process owns it. A binding such as 127.0.0.1:8080 accepts local connections only; a wildcard binding such as 0.0.0.0:8080 can accept connections through local IPv4 addresses, subject to firewall and service policy.

Reading a numeric socket listing

netstat -atun

Read each row as a pair of endpoints: the local address and port, and the foreign address and port. A listening server might show a wildcard local address and a wildcard foreign address. An established TCP session shows a specific local endpoint connected to a specific peer.

Continuous monitoring

Use -c to repeat the selected report:

netstat -atunc

Repeated output helps you observe connections appearing and disappearing, and lets you watch TCP states change. Stop continuous output with Ctrl+C.

Protocol statistics

The -s option prints counters maintained by network protocols:

netstat -s
netstat -st

Depending on the system, reports can include IP, TCP, UDP, and ICMP statistics. Counters may include packets or segments sent and received, receive and send errors, discarded packets, retransmissions, failed connection attempts, and ICMP messages.

Use netstat -st to focus on TCP statistics. Increasing retransmission counters can point to loss, congestion, or an unreliable path. Receive or send errors and discards can indicate malformed traffic, resource pressure, or filtering. Interpret counters over time rather than treating one absolute value as proof of a problem.

Network interface statistics

Use -i to display interface-level counters:

netstat -i

The report identifies interfaces and commonly includes receive and transmit packet totals, errors, drops, overruns, and collisions where the platform supplies those counters. Rising receive or transmit errors and drops can suggest a cable, NIC, driver, switch-port, MTU, or congestion problem. Capture the counters twice over an interval so that you can determine whether they are increasing.

Routing table display

Use -r to display the kernel routing table:

netstat -r

A route selects a destination network, an optional gateway, and an interface. Typical columns include:

• Destination: the network or host the route matches.
• Gateway: the next-hop router; a direct route may show no gateway.
• Genmask: the netmask used to determine how specific the destination match is.
• Flags: properties such as whether the route is up, a gateway route, or a host route.
• Metric: a preference value used when routes compete.
• Iface: the network interface used for traffic.

The default route is used when no more-specific route matches the destination. An absent or incorrect default gateway can make remote networks unreachable. An incorrect interface or destination route can also send traffic along the wrong path.

TCP connection states

TCP is a connection-oriented transport protocol with ordered delivery and a lifecycle. Netstat can expose that lifecycle through the State column.

Common troubleshooting workflow

1. Check the required service with sudo netstat -tulpn. Verify the intended port and local bind address.
2. Confirm the PID and program name. If another process owns the port, decide whether to stop it or configure the new service to use a different port.
3. Inspect active TCP sessions with netstat -tan and examine states such as ESTABLISHED, SYN_SENT, and CLOSE_WAIT.
4. Review Recv-Q and Send-Q when an application is slow or connections appear stalled.
5. Use netstat -st to review retransmissions, errors, discards, and send/receive counters.
6. Use netstat -i to inspect interface counters and netstat -r to verify route selection.
7. Use numeric output such as netstat -atun during troubleshooting to remove name-resolution ambiguity.

Example: a service cannot be reached

Run sudo netstat -tulpn. If no listener exists, inspect the service status and configuration. If the service listens only on loopback, review its bind address. If it listens on the intended interface, continue by checking firewall policy, routing, and whether the client is using the correct address and port.

Example: a port is already in use

Locate the requested port in sudo netstat -tulpn, record the PID and program name, and determine whether the existing owner should be stopped or whether the new service should use another configured port.

Example: connections remain in CLOSE_WAIT

netstat -tan
sudo netstat -tanp

The remote side has closed these connections, but the local application has not released its sockets. Investigate application behavior, connection cleanup, and possible resource leaks.

Example: connections are stuck during establishment

netstat -tan
netstat -r

Look for persistent SYN_SENT or SYN_RECEIVED entries. Check the destination route, firewall policy, remote service availability, address correctness, and return-path routing.

Example: packet loss or interface errors

netstat -i

Compare receive and transmit errors, drops, overruns, and other counters over time. Correlate increasing values with physical cabling, the NIC, driver messages, switch-port configuration, MTU, and congestion.

Option reference

Modern alternatives: ss and ip

ss provides comparable socket-inspection capabilities and is commonly supplied through the iproute2 package. It is generally preferred on current Linux systems.

For new scripts and operational habits, learn ss for sockets, ip route for routing, and ip -s link for interface counters. Keep netstat knowledge because it remains present on older systems and in many troubleshooting guides.

Exam-relevant notes

• -a includes listening sockets; without it, a server may not appear in the default active-connection view.
• -n avoids DNS and service-name lookups, which improves speed and removes resolver ambiguity.
• -p identifies the owning PID and program, but administrative privileges may be needed for complete results.
• TIME_WAIT is often normal after many short-lived TCP sessions.
• Persistent CLOSE_WAIT usually points to a local application that failed to close a peer-terminated connection.
• TCP has lifecycle states; UDP normally does not have a TCP-style state field.
• The default route handles destinations for which no more-specific route exists.