How to Check If a Port Is Open

When something on your network won't connect, the first question is always: is the port actually open?

A port is a numbered doorway. When a service runs—a web server, a database, an SSH daemon—it opens a door and waits. Your job is to figure out whether that door exists, whether anyone's behind it, and whether you can reach it.

The Three States

Every port exists in one of three states:

Open: Someone's home. A service is listening, ready to talk. This is what you want when you're testing a server you expect to reach.

Closed: The door exists, but nobody's there. Your connection attempt arrived, but nothing answered. You'll see "connection refused"—a polite rejection.

Filtered: You can't even find the door. A firewall is silently dropping your packets. You knock and hear nothing—not even an echo. This is the frustrating one, because silence could mean the host doesn't exist, the port is blocked, or your packets are being swallowed somewhere in between.

The difference between closed and filtered matters. Closed means the network path works but the service is down. Filtered means something is actively preventing you from even asking the question.

Checking Your Own Machine

When you need to know what's listening locally, your operating system already knows.

Windows

Open PowerShell and run:

Get-NetTCPConnection -State Listen

This shows every TCP port your machine is listening on, along with the process that owns it.

The older approach still works:

netstat -ano | findstr LISTENING

The -o flag adds the Process ID, which you can look up in Task Manager.

macOS and Linux

The ss command is the modern choice:

ss -tuln

That's TCP (-t), UDP (-u), listening (-l), numeric addresses (-n). Clean and fast.

To see which process owns each port:

sudo lsof -i -P -n | grep LISTEN

The lsof command—"list open files"—treats network connections as files, because in Unix, everything is a file.

Checking Remote Ports

Testing a port across the network means sending a connection attempt and watching what comes back.

Telnet: The Quick Test

telnet example.com 80

If the port is open, you'll either see a connection message or a blank screen (meaning you're connected, waiting for input). If it's closed, you'll see "Connection refused." If it times out, the port is filtered or the host unreachable.

Telnet only speaks TCP. It can't test UDP.

Netcat: More Flexible

Netcat (nc) handles both protocols:

nc -zv example.com 80

The -z flag scans without sending data. The -v flag makes it verbose. For UDP:

nc -zuv example.com 53

You can also scan ranges:

nc -zv example.com 20-80

Nmap: The Professional Tool

Nmap does what the other tools do, but with more depth:

nmap -p 80,443 example.com

This tests specific ports and tells you not just whether they're open, but often what service is running behind them.

UDP scanning requires root privileges because it involves crafting raw packets:

sudo nmap -sU -p 53 example.com

Here's the honest truth about UDP scanning: it's fundamentally uncertain. TCP has a handshake—you know definitively whether a connection succeeded. UDP just sends packets into the void. If nothing comes back, is the port open and silent, or filtered and dropping everything? Nmap often returns open|filtered because it genuinely cannot tell. That ambiguity isn't a limitation of the tool. It's a property of the protocol.

PowerShell: Built Into Windows

Test-NetConnection example.com -Port 443

This gives you ping results, TCP test results, and timing information without installing anything.

Testing Your Own Ports from Outside

Here's the trap: testing your own server from inside your network might bypass your firewall entirely. Your packets never leave the building, so you never learn whether the outside world can reach you.

You need an external perspective.

Online port checkers connect to your public IP from servers on the Internet. Enter your IP and port number, and they'll tell you what the world sees. This reveals whether your router's port forwarding actually works, whether your ISP blocks certain ports, and whether your firewall rules do what you think they do.

Testing from a remote server gives you more control. SSH into a VPS or cloud instance and run nmap or netcat against your home IP. Same information, but you control the tools.

When Things Go Wrong

Port closed locally when it should be open: The service isn't running. Start it.

Port open locally but closed remotely: A firewall between you and the destination is blocking traffic. Check the host firewall, security groups, and any network firewalls in the path.

Connection times out: Either the host is unreachable, or a firewall is silently dropping packets. Verify the IP is correct. Try pinging the host.

Different results from different locations: Something is filtering by source—geographic restrictions, CDN routing, or network-specific rules.

ISP blocking: Some residential ISPs block common ports like 25 (SMTP), 80 (HTTP), or 445 (SMB). If your configuration is correct but external connections fail, your ISP might be the culprit.

The Short Version

Local checks tell you what's listening on your machine. Remote checks tell you whether you can reach it across the network. External checks tell you whether the rest of the Internet can reach you.

Open means someone's answering. Closed means nobody's home. Filtered means you can't even knock on the door.

And only scan systems you own or have permission to test. Port scanning someone else's infrastructure without authorization is a quick way to receive uncomfortable legal correspondence.