| PORT | SERVICE | STATUS | RESPONSE |
|---|---|---|---|
| ⟳ no scan results yet | |||
Nine times out of ten, when someone tells me “the application isn’t connecting,” the first thing I do is check whether the port it needs is actually reachable. Don’t assume. Don’t guess based on the firewall config doc that was last updated two years ago. Check. Because firewall rules drift, ISPs silently block ports, and services go down without anyone noticing until something else breaks.
That’s exactly what this tool is for: a fast, no-install way to see whether a specific port on a host is open, closed, or being blocked before you spend an hour chasing the wrong problem.
Enter any IP address or domain name below, choose which ports to test, and get a result in seconds. No account required. No software to install. Works from any browser, including on mobile.
How to Use the Port Scanner
Using the tool takes about 20 seconds. Here’s exactly what to do:
- Enter a hostname or IP address in the target field, either a domain like example.com
- or a raw IP like 192.168.1.1 Both formats work.
- Choose which ports to scan. Hit “Common Ports” to test the most frequently used ports (HTTP, HTTPS, SSH, FTP, and others) in one go, or enter a specific port number manually if you’re checking one service in particular.
- Click Scan and wait a few seconds for results. Each port comes back as Open, Closed, or filtered, and what each status means is covered in the next section.
Quick tip: If you’re testing a server you manage, scan it from an external connection, not from the same network the server is on. A port can look open from inside the LAN but be completely blocked from the internet by a firewall or your ISP. Testing from outside is the only way to see what the rest of the world actually sees.
What Your Scan Results Actually Mean
This is the part most port scanner pages skip entirely, and it’s the part that matters most. Getting a result and not knowing what to do with it is just as frustrating as not checking at all.
Open
The port is reachable, and a service is actively listening on it. If you were checking port 443 and it comes back Open, your web server is accepting HTTPS connections. If you were checking port 22 and it’s Open, SSH is running and reachable.
An open port is not automatically a problem — you want your web server’s port 443 to be open. The question is whether the ports that are open are the ones that should be open, and nothing else.
Closed
The host is reachable, but nothing is listening on that port. The connection was actively refused. This usually means the service either isn’t running or is configured to listen on a different port. A closed port is different from a filtered port, and that difference matters a lot for troubleshooting.
Filtered
This is the result that confuses people the most. “Filtered” means the probe sent no response at all; the packet was dropped silently, usually by a firewall. You can’t tell from this result whether a service is running behind the firewall or not. Most people see “filtered” and assume the firewall is blocking access. That’s usually correct, but it can also mean the host is offline or the IP doesn’t exist. The key difference from Closed: a closed port sends back a rejection; a filtered port sends back nothing.
Here’s the practical implication I learned the hard way early in my career: when you’re troubleshooting a broken connection and the port shows “Filtered,” don’t just go straight to the firewall team. First confirm the host itself is up. A filtered result on a host that’s offline looks identical to a filtered result on a host that’s online but protected by a firewall. Ping it first, or run a DNS lookup to confirm the name resolves—then dig into the firewall rules.
| Status | What it means | Common cause | What to do next |
|---|---|---|---|
| Open | Service is running and reachable | Service is correctly configured, and firewall allows the port | Verify it’s a port that should be open—close anything unexpected |
| Closed | Host is up, but nothing is listening | Service not running, wrong port configured, service crashed | Check if the service is running on the host; check its configured port |
| Filtered | No response — packet dropped silently | Firewall blocking the port, host offline, ISP blocking | Confirm host is reachable first, then check firewall rules |
When Would You Actually Use a Port Scanner?
Port scanning is one of those skills you use constantly once you know it exists and seldom before. Here are the three scenarios I reach for it most often:
Troubleshooting a service that won’t connect
An application reports it can’t connect to the database. Email isn’t sending. A web service is timing out. Before touching a single config file, scan the relevant port. If port 3306 (MySQL) shows Filtered when it should be Open, you know the database isn’t the problem — the network path is. That one check redirects the next hour of troubleshooting toward the right person and the right fix.
Verifying a firewall rule change actually took effect
After submitting a firewall change request and getting approval, the rule is supposedly live. But has it actually been applied? Scan the port from the relevant source, and you’ll know in seconds whether the change worked as intended—no waiting, no guessing, no “it should be fine” from the firewall team.
Checking a new server before going live
Before pointing traffic at a new server, a quick port scan confirms the right ports are open, and the wrong ones aren’t. Web server on 443? Open. Database port 3306 reachable from the internet? That should definitely be Closed or Filtered — if it’s Open, that’s a security problem to fix before the server goes anywhere near production.
Common Mistakes When Running a Port Scan
A few things I see regularly that produce misleading results or missed problems:
Scanning from inside the same network as the server. Your internal network probably doesn’t apply the same firewall rules as external traffic does. Scanning from inside gives you a view that the internet never sees. Always test from an external connection if you’re trying to verify public-facing port accessibility.
Treating a browser-based scanner the same as a server-side scanner. SubnetLab’s port scanner runs checks from your browser using HTTP/HTTPS probes and TCP handshake detection. This is fast and works for most common ports, but it behaves differently from a command-line tool like Nmap that sends raw packets. For standard troubleshooting and verification, a browser-based tool is perfectly adequate. For deep security audits or scanning UDP ports, Nmap running locally gives you more control.
Confusing ISP port blocking with a server firewall. Some internet service providers block specific ports at the ISP level on residential connections—port 25 (SMTP) and port 80 are common examples. If a port shows Filtered and you’ve already confirmed the server’s firewall allows it, the block may be happening at the ISP before the traffic ever reaches your host. This is particularly worth checking for anyone running a home server or small business server on a residential internet connection.
Scanning a port but not verifying the service behind it. An open port means something is listening — it doesn’t mean the right thing is listening. A web server misconfigured to run on port 8080 instead of 80 will show port 80 as Closed and port 8080 as Open. Always pair a port check with a service-level test to confirm what’s actually running behind the open port.
Frequently Asked Questions
Is it legal to scan ports with this tool?
Scanning ports on systems you own or have explicit permission to test is completely legal and is standard network administration practice. Scanning systems without permission can violate computer access laws in many countries. Only use this tool on hosts you own or are authorized to test.
Why does a port show as Open here but the service still won’t connect?
An open port means something is accepting connections on that port — but it doesn’t guarantee the service behind it is healthy or responding correctly. The service could be running but returning errors, or you could be hitting the wrong service on that port entirely. An open port is the starting point of troubleshooting, not the end of it.
What’s the difference between a closed port and a filtered port?
A closed port actively sends back a rejection — the host is up and explicitly saying “nothing is here.” A filtered port sends nothing — the packet is dropped, usually by a firewall, and you can’t determine whether a service is running behind it. Filtered is harder to troubleshoot because the silence gives you less information than a rejection does.
Can I scan UDP ports with this tool?
This tool primarily tests TCP ports using HTTP/HTTPS probes and TCP handshake detection, which covers the majority of services engineers need to check. UDP port scanning requires sending UDP packets and interpreting the absence of a response, which needs a server-side scanner like Nmap running locally. For UDP-specific checks, use nmap -sU from a terminal.
Why does the same port show different results at different times?
Network conditions, load balancers, rate limiting, and temporary service restarts can all cause a port to return different results between scans. If you’re getting inconsistent results, scan the same port two or three times a few minutes apart before drawing conclusions. Consistent Filtered results point to a firewall or routing issue; intermittent results often point to the service itself.
Related Tools on SubnetLab
Port scanning is usually one step in a larger troubleshooting workflow. If your port check raised more questions, these tools are the natural next step:
DNS Lookup Tool — If a hostname isn’t resolving to the IP you expect, a port scan against it will point at the wrong host entirely. Before scanning by domain name, confirm the DNS record is correct and up to date.
MAC Address Lookup Tool — When you’re troubleshooting at the device level on a local network and need to identify which physical device is associated with an IP address you’re scanning, a MAC address lookup is the fastest way to confirm you’re looking at the right machine.