iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To check a port on your own Linux machine, inspect its sockets with ss. To find out whether a remote host is reachable from your network, test from the client’s location using nc, nmap, or a Bash TCP check. These answer different questions: a local listener can still be unreachable remotely, and a UDP probe that gets no response is inconclusive.
Choose a method for the question you need to answer
| Method | Best for | What it tells you | Important limitation |
|---|---|---|---|
ss |
Checking sockets on the Linux machine where you run it | Local listening sockets and, with privileges, owning process details | Does not test whether a remote client can reach the service |
nc TCP |
A quick connection attempt to a remote TCP port | Whether a TCP connection attempt succeeds or fails | Does not verify the application protocol, TLS, or authentication |
nc UDP |
A preliminary probe to a remote UDP port | May provide a response or error from the target | No response does not show whether a UDP service is listening |
nmap |
Scanning selected ports or a broader range | Scanner-observed port states; optional service version detection | UDP results can be ambiguous, and scans can take time |
Bash /dev/tcp |
A simple TCP readiness check in a script | Whether Bash can open a TCP connection | Does not report scan states or identify services |
1. Inspect local listeners with ss
Run this on the Linux machine whose sockets you want to inspect:
sudo ss -tunlpThe options request TCP (-t), UDP (-u), numeric addresses and ports (-n), listening sockets (-l), and process details (-p). Root privileges may be needed to see process details for sockets owned by other users.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteTCP listeners show the state LISTEN. UDP has no listening handshake and commonly appears as UNCONN, so searching only for LISTEN can miss UDP sockets. Check the local address as well: 127.0.0.1 is loopback and accepts local connections only, while 0.0.0.0 means all IPv4 interfaces.
#1 Best Overall
Check one TCP port
sudo ss -tlnp sport = :22Replace 22 with the port you want to inspect. This is local socket inspection, not a remote reachability test.
2. Test a remote TCP port with nc
From the machine and network location that need access, try a zero-I/O connection check:
nc -z -v -w 3 HOST PORTReplace HOST with a hostname or IP address and PORT with the TCP port. In the commonly used OpenBSD netcat form, -z checks without sending application data, -v prints a result, and -w 3 bounds the wait to three seconds.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallNetcat implementations differ. OpenBSD netcat, traditional netcat, and Ncat do not necessarily support identical flags. Check the installed command’s nc -h output or local manual if an option is rejected. A range form such as nc -z -v HOST 20-80 is supported by the cited Ubuntu Noble netcat-openbsd manual, but should not be assumed to work identically in every implementation.
A successful TCP connection means the connection-level attempt succeeded; it does not establish that the application is usable. The service may require TLS, authentication, or a particular application request.
3. Make a preliminary UDP probe with nc
nc -z -v -u HOST PORTThe -u option selects UDP. Treat this only as a preliminary probe: UDP has no TCP-style handshake, so an apparent success, lack of an error, or lack of a response does not by itself prove that an application is listening. For a more meaningful check, send a request appropriate to the service’s protocol, or use Nmap’s UDP scan where suitable.
4. Scan ports and interpret states with nmap
Scan one TCP port or a full TCP range
nmap -p PORT HOSTReplace PORT and HOST with the target port and host. Nmap’s default TCP scan ordinarily checks the 1,000 most common TCP ports, not every port.
nmap -sT -p- HOSTThe -sT option requests a TCP connect scan, and -p- selects ports 1 through 65,535. Scan only systems you own or are authorized to test.
Scan a UDP port
sudo nmap -sU -p PORT HOSTUDP scans may take a while: open or filtered ports often do not respond, and ICMP errors from closed ports may be rate-limited. Nmap’s labels describe what its probes could determine, not a definitive diagnosis of the network equipment:
Rank #4
open: Nmap observed an application accepting packets.closed: The target responded that no application is listening on that port.filtered: Filtering or another obstacle prevented Nmap from determining whether the port is open. This does not identify which device or rule caused the obstruction.open|filtered: Nmap received no response to its UDP probe, so it cannot tell whether the port is open or filtered.
Identify a service, not just a port state
When the question is which service appears to be running, consider Nmap version detection with -sV, for example nmap -sV -p PORT HOST. A port-state result alone does not establish the application’s full behavior or whether a client can authenticate successfully.
5. Check TCP readiness in a Bash script
Bash can attempt a TCP connection through its /dev/tcp feature. This example applies a five-second timeout and uses the command’s exit status in an if statement:
if timeout 5 bash -c '</dev/tcp/HOST/PORT' &>/dev/null; then
echo "TCP connection succeeded"
else
echo "TCP connection failed or timed out"
fiReplace HOST and PORT with the destination. This is useful for a small TCP readiness check, but it does not provide Nmap’s port states or service detection. Bash also recognizes /dev/udp; opening that socket alone does not prove a UDP service is listening.
Best Value
What a failed check can—and cannot—tell you
Connection refused
A refused TCP connection usually means the attempt was rejected. It does not, by itself, explain why the target rejected it.
Timeout or an Nmap filtered result
A timeout can result from filtering, routing problems, an unavailable host, packet loss, or an upstream network rule. Likewise, filtered reports that Nmap could not determine the port state; it does not prove that a particular firewall is responsible.
Check the relevant network path, host reachability, and any host firewall, cloud firewall, router, or upstream filter. Also confirm that the service is bound to an address reachable from the test client. A firewall rule that permits traffic does not prove that an application is listening; use ss on the server to check its local socket separately.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →The local socket exists, but remote access fails
Compare the service’s bound address with the intended client path. A listener on 127.0.0.1 is local-only. Even a listener bound to a network interface can be unreachable if routing or filtering blocks the connection. Run the remote test from the client position that matters rather than treating local socket output as proof of external access.
Quick Recap
Sources and command references
- Nmap Reference Guide / nmap(1)
- Ubuntu Noble manual page for nc
- Linuxize: Check Open Ports in Linux
- Linuxize: How to Check Listening Ports in Linux
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
