How to Check if a Port Is Open

A new application will not connect, a colleague cannot reach the office VPN, or a security review asks what your server exposes. All of these come down to the same question: can traffic reach a specific port? This guide shows how to check if a port is open using tools you already have, and how to read the result correctly, which is where most troubleshooting goes wrong.

First, decide where you are testing from

A port can be open from one place and closed from another. Firewalls, routers, cloud security groups and the service itself each have a say. So before testing, be clear about which path you are checking:

From the internet to your server or office: what customers, remote staff and attackers can reach.
From inside your network: what other machines on the LAN or in the same cloud network can reach.
On the machine itself: whether the service is running and listening at all.

Testing from your own office to your own public IP can also mislead you, because many routers do not handle that "hairpin" path the same way as genuinely external traffic.

Method 1: An online port checker (outside view)

For the internet-facing question, the most reliable test comes from a machine outside your network. Our port checker attempts a connection to the address and port you enter and reports whether it succeeded. If you are checking your office connection, get your public address first with What Is My IP; testing a private address like 192.168.1.10 from the internet will always fail.

This is the right test after setting up port forwarding, opening a cloud firewall rule, or when you want to confirm that something sensitive, such as Remote Desktop on port 3389, is not reachable.

Method 2: PowerShell on Windows

Windows includes a built-in test:

Test-NetConnection -ComputerName example.com -Port 443

The key line in the output is TcpTestSucceeded : True. If it says False, the connection failed. The short alias works too:

tnc example.com -Port 3306

Note that Test-NetConnection tests TCP only.

Method 3: netcat or bash on Linux and macOS

Netcat (nc) is the classic tool:

nc -zv example.com 443

-z means just check the connection without sending data, and -v prints the result, such as Connection to example.com port 443 [tcp/https] succeeded!. Add -w 3 to give up after three seconds instead of waiting a long time.

If netcat is not installed, bash can test TCP ports on its own:

timeout 3 bash -c '</dev/tcp/example.com/443' && echo open || echo closed-or-filtered

For web services, curl -v https://example.com:8443/ goes one step further and shows whether the application actually responds.

Method 4: nmap for several ports at once

Nmap is a free, widely used network scanner. To check specific ports:

nmap -p 22,80,443,3306 example.com

Or the 1,000 most common ports:

nmap example.com

Only scan systems you own or have written permission to test. Scanning other people's networks may break their terms of service or local law, and it will often be flagged by their security monitoring.

Method 5: On the server itself

If remote tests fail, check whether anything is listening at all:

# Linux: listening TCP and UDP ports with process names
sudo ss -tulpn | grep ':443'

# Windows
netstat -ano | findstr :443

Look at the local address. A service bound to 127.0.0.1:3306 only accepts connections from the same machine; 0.0.0.0:3306 or [::]:3306 means all interfaces. A database that "will not accept remote connections" is often simply bound to localhost, which for a database is usually the safer setting.

Reading the results: open, closed, filtered

Result	What happened	What it usually means
Open	The connection was accepted	A service is listening and the path allows it
Closed (connection refused)	The host replied immediately with a reset	The host is reachable but nothing listens on that port, or the service is stopped
Filtered (timeout)	No reply at all	A firewall is silently dropping the traffic somewhere along the path

The distinction between "refused" and "timed out" is the most useful clue you have. Refused points at the server's service; timed out points at a firewall.

A troubleshooting sequence

Is the service running and listening? Check with ss or netstat on the server.
Is it bound to the right interface? Not just 127.0.0.1.
Does the host firewall allow it? On Linux, check ufw status, firewalld or nftables; on Windows, Windows Defender Firewall inbound rules.
Does the network firewall allow it? Cloud security groups and network ACLs, or your office firewall.
For office connections, is port forwarding set up to the right internal address, and does your provider give you a real public IP rather than carrier-grade NAT?
Does the provider block it? Some ISPs block inbound or outbound traffic on ports like 25 and 445.

A note on UDP

UDP ports are harder to test because UDP has no handshake. A silent result could mean open or filtered. The practical test for UDP services is to use the real client: run dig @server example.com for DNS on port 53, or try connecting with the actual VPN client for WireGuard or OpenVPN.

Key takeaways

Always test from the location that matters: outside for internet exposure, inside for internal services.
Use an online checker, Test-NetConnection, nc -zv or nmap depending on where you are.
"Refused" means nothing is listening; "timed out" means a firewall is dropping traffic.
Check that the service listens on the right interface before blaming the network.

Networking articles