How to Check If a Port Is Open on Your Server or Network

Checking open ports is essential for both security and troubleshooting:

Security: Every open port is a potential entry point for attackers. If you're running a web server, you want ports 80 and 443 open — but port 3306 (MySQL) or port 22 (SSH) should not be accessible from the public internet unless absolutely necessary.

Troubleshooting: When a service isn't working — website not loading, email not arriving, SSH connection refused — the first step is checking whether the correct port is actually open and reachable.

Compliance: Security audits and compliance standards (PCI DSS, SOC 2) require regular port scanning to ensure only authorized services are exposed.

Verification after changes: After configuring firewall rules, port forwarding, or deploying a new service, you need to verify the ports are correctly open or closed.

The easiest way to check if a port is open from the outside is to use LookMyIP's Port Checker at lookmyip.com/port-checker.

Simply enter the IP address or hostname and the port number you want to check. The tool attempts a TCP connection from an external server and reports whether the port is open (accepting connections), closed (actively refusing), or filtered (no response — typically blocked by a firewall).

This is particularly useful because it shows how your ports appear to the outside world, which may differ from what you see locally. A port can be open on your server but blocked by an ISP, cloud provider security group, or intermediate firewall.

Using telnet: telnet example.com 443 If the connection succeeds, the port is open. If it says "Connection refused," the port is closed. If it hangs, the port is filtered.

Using nc (netcat): nc -zv example.com 443 The -z flag scans without sending data, and -v provides verbose output. Faster than telnet for quick checks.

Using nmap (most powerful): nmap -p 80,443,22 example.com Scan specific ports. Nmap reports whether each port is open, closed, or filtered.

nmap -p 1-1000 example.com Scan a range of ports.

Using PowerShell (Windows): Test-NetConnection -ComputerName example.com -Port 443 Built into Windows — no additional software needed.

Using curl: curl -v telnet://example.com:443 Another quick way to test TCP connectivity on systems that don't have telnet or nc.

Open: A service is listening on this port and accepting connections. For a web server, ports 80 and 443 should be open.

Closed: The port is reachable (the server responds), but no service is listening. The server sends back a TCP RST (reset) packet. This means the port isn't blocked by a firewall, but nothing is running on it.

Filtered: No response at all — packets are dropped silently. This usually means a firewall (iptables, AWS Security Group, cloud provider firewall) is blocking the port. This is the most secure state for ports you don't need.

Open|Filtered: Nmap can't determine if the port is open or filtered (common with UDP scans). UDP services don't always respond to probes.

For security, unexposed ports should be "filtered" (silently dropped), not "closed" (actively refused). Closed ports still reveal that a host exists at that IP address, while filtered ports give no information to potential attackers.

• Scan your own servers regularly. Run monthly port scans of your public-facing servers and compare results to your expected configuration.
• Follow the principle of least privilege. Only open ports that are needed. If you're running a web server, you need 80 and 443 — not 22 from everywhere.
• Restrict SSH access. If you need SSH (port 22), restrict it to specific IP addresses using firewall rules rather than leaving it open to the world.
• Close database ports. MySQL (3306), PostgreSQL (5432), MongoDB (27017), and Redis (6379) should never be open to the public internet. Access them through SSH tunnels or private network connections.
• Use cloud security groups. If you're on AWS, Azure, or GCP, configure security groups/firewall rules at the cloud level in addition to OS-level firewalls.
• Disable unused services. If you're not using FTP (21), Telnet (23), or other legacy services, stop the service and close the port.

"Is the port open?" is really two questions, and confusing them is the reason most port troubleshooting goes in circles.

From inside the machine, you are asking whether a process is listening:

sudo ss -tlnp

Read the Local Address column carefully, because it is where the answer usually lies:

LISTEN  0  128  127.0.0.1:5432   users:(("postgres",pid=812,fd=6))
LISTEN  0  511    0.0.0.0:80     users:(("nginx",pid=940,fd=6))
LISTEN  0  511       [::]:443    users:(("nginx",pid=940,fd=7))

PostgreSQL is bound to 127.0.0.1 and will never accept a remote connection no matter what you do to the firewall — the process itself is refusing to listen on any other interface. nginx on 0.0.0.0 and [::] is listening on every interface, IPv4 and IPv6.

This distinction alone resolves a large share of "the port is open but I cannot connect" problems. Changing firewall rules to fix a localhost binding is time spent on the wrong layer.

From outside, you are asking whether traffic actually reaches the process. Nothing you run on the machine can answer this, because it cannot see what the network in front of it does. Use the open port checker, which connects from the public internet, or test from an unrelated host:

nc -zv example.com 443
timeout 5 bash -c '</dev/tcp/example.com/443' && echo open || echo closed

That second form uses nothing but bash and works on any Linux host with no tools installed.

The diagnostic order that resolves things fastest is: confirm the process is listening on the right interface, then test from localhost, then from another machine on the same network, then from the internet. The first step that fails identifies the layer at fault — and it is very often step one.

nmap is the standard tool for auditing what a host exposes. These invocations cover most legitimate uses on infrastructure you own or are authorised to test.

Full TCP audit — what is actually reachable:

nmap -p- -T4 --open example.com

-p- scans all 65,535 ports rather than nmap's default top 1,000, and --open suppresses the noise of closed ports. This takes several minutes and is the scan that finds the forgotten service.

Identify what is running, not just that something is:

nmap -sV -sC -p 22,80,443 example.com

-sV fingerprints service versions; -sC runs the default script set, which reports TLS certificate details, supported ciphers, HTTP titles and common misconfigurations.

Check UDP, which almost everyone skips:

sudo nmap -sU --top-ports 100 example.com

UDP scanning is slow and unreliable by nature — there is no handshake, so a lack of response is ambiguous. It is still worth running, because exposed UDP services like memcached, NTP and SNMP are the amplification vectors used in reflection DDoS attacks.

Audit TLS configuration:

nmap --script ssl-enum-ciphers -p 443 example.com

This grades the cipher suites and flags anything weak, which is a faster first pass than a full external scanner.

Two important caveats. Scan only what you own or have written authorisation to test — the legal position on unauthorised scanning varies by jurisdiction and is at minimum a provider terms-of-service violation. And scan from outside your network to get a meaningful result; scanning your server from inside the same VPC bypasses exactly the controls you are trying to verify.

Finding an unexpected open port is the start, not the end. Work through it in order.

Identify the process, not just the port. A port number is a guess about what is running; the process is a fact.

sudo ss -tlnp | grep :8080
sudo lsof -i :8080

Decide whether it needs to be public at all. Most services that turn up unexpectedly do not. Databases, caches, admin panels, metrics endpoints and container APIs should be bound to localhost or a private interface and reached through a VPN or SSH tunnel. Binding correctly is more robust than a firewall rule because it does not depend on a filter staying in place.

ssh -L 5432:localhost:5432 user@server

That forwards the remote PostgreSQL port to your local machine over SSH, giving you access with nothing exposed to the internet.

If it must be public, restrict and harden it. Limit source addresses where you can, require authentication, put TLS in front of it, and rate-limit.

Check Docker specifically. Publishing a port with -p 8080:80 writes iptables rules that bypass ufw entirely, so a server that appears firewalled can be exposing every container port. Bind explicitly when a container should stay private:

docker run -p 127.0.0.1:8080:80 myimage

Then verify from outside again. A change you believe took effect and one that did are different claims — re-run the port checker after every change.

Finally, make it a routine. Ports open themselves over time: a colleague deploys something, a container is published carelessly, a package's default configuration listens broadly. A scheduled monthly scan with a diff against last month's result catches these while they are still recent.

Why does a port show closed when my service is definitely running?

In order of likelihood: the service is bound to 127.0.0.1 rather than a public interface; a host firewall is dropping the traffic; a cloud security group or network ACL has not been updated; or your ISP blocks the port. Residential ISPs commonly block 25, 445 and sometimes 80 and 443 outright.

Is having open ports dangerous?

Only if what is behind them is. A hardened, patched web server on 443 is fine — that is what it is for. An unauthenticated Redis instance on 6379 is a compromise waiting to happen. The number of open ports matters far less than what each one exposes.

How do I check ports on a machine I cannot log into?

Externally only, with the port checker, nmap, or nc -zv. You will see what is reachable, not what is bound. Scan only hosts you are authorised to test.

What is the difference between closed and filtered?

Closed means the host responded with a TCP RST — nothing is listening, but the host is reachable and no firewall intervened. Filtered means no response at all, because something dropped the packet. The distinction tells you whether a firewall is in the path.

Does closing ports on my home router make me safer?

Marginally, since NAT already blocks unsolicited inbound connections. The larger risks on a home network are UPnP allowing devices to open ports without your knowledge, and IoT devices making outbound connections that NAT does not restrict at all. Disabling UPnP and segmenting IoT devices onto a separate network does more than auditing inbound ports.