An open port checker tells you whether a specific TCP port on your public IP address or hostname accepts connections from the internet. To check whether a port is open, run an external test against your public IP or hostname and the exact port number, then read the result: open means a TCP handshake completed, closed means the host refused, and filtered or timed out means something on the path dropped the attempt. That one result separates “my service is down” from “my firewall or router is in the way.”
The catch is that a port test from inside your own network can pass while outside visitors still can’t connect. NAT loopback, host firewalls, cloud security groups, and carrier-grade NAT all change what the outside world sees.
PacketTools builds its browser-based diagnostics from nearly three decades of production IT work, and the open port checker follows the same rules as the rest of the site: no sign-in, no tracking, and no IPs, queries, or test data logged or stored. Once you know how to read open, closed, and filtered results, you can tell which layer to fix and stop changing router settings at random.
How Do You Check Whether a Port Is Open?
You check a port by pointing an external tester at the exact public address and port number a remote client would use. Getting the target right (public IP or the hostname clients resolve) and testing from outside your LAN accounts for most of the accuracy.
Choose the Public IP Address or Hostname and Port
Start with the address the internet sees. Your PC’s 192.168.x.x or 10.x.x.x address is private and unreachable from outside, so a port checker needs your public IP address. You can check your IP address to get the value your router presents to the world.
If clients connect by domain name, test the hostname too. That adds DNS to the check: if the hostname resolves to an old IP, you’ll be testing the wrong machine. A quick DNS propagation checker run confirms the A or AAAA record points where you expect.
Pick the port deliberately:
- The port clients connect to, which may differ from the internal port if your router maps 8443 externally to 443 internally.
- The right protocol. Most online port testing is TCP. UDP services need a different approach (covered below).
- The right address family. An IPv6 address bypasses NAT entirely, so an IPv6 test may succeed while IPv4 fails, or the reverse. The IPv4 vs IPv6 differences explain why the two paths behave so differently.
Run a Safe Browser-Based Check from Outside Your Network
A browser-based online port checker sends one TCP connection attempt from a server on the internet to your target. That external vantage point is the whole value: it walks the same path a real visitor takes, through your ISP, router, and firewalls.
A clean workflow looks like this:
- Confirm the service is running locally first.
- Enter your public IP or hostname and a single port.
- Run the open port check and note open, closed, or filtered.
- Change one thing (a firewall rule, a forward), then retest the same port.
Avoid testing from a device on the same LAN through your own public IP. Many routers loop that traffic back internally, so the result says nothing about outside reachability. If you need a second outside view, use a phone on cellular data.
PacketTools’ open port checker runs these tests in real time without storing the target or the result, which suits checks against production hosts you’d rather not leave in someone’s logs. It sits alongside the ping test and other network tools on the site.
What Do Open, Closed, and Filtered Results Mean?
Each port status describes what happened to the connection attempt, and only “open” confirms service availability. Closed proves the host is reachable but idle on that port; filtered proves only that no answer came back, and UDP results carry even less certainty.
| Result | What came back | What it tells you |
|---|---|---|
| Open | SYN-ACK, handshake completed | A service is listening and reachable from the test location |
| Closed | TCP RST (refusal) | Host is reachable, nothing listens on that port |
| Filtered / timeout | Nothing, or an ICMP prohibited message | A firewall, router, or broken path dropped the attempt |
What a TCP Connection Can Confirm
TCP is connection-oriented, so a successful handshake is hard evidence. When the checker gets a SYN-ACK, some process accepted the connection on that port, from that vantage point, at that moment.
It does not confirm the right application answered. A reverse proxy, a default web page, or a leftover service can hold the port. If port 443 shows open but your site still fails, test the application layer next: TLS certificate, HTTP response, and logs.
Results are also location-relative. The Nmap reference guide notes that a scan from the same network may show a port as open while the same port shows filtered from across the internet at the same time. Port state belongs to the path, not the port itself.
Why a Timeout Does Not Prove a Port Is Closed
A timeout means silence, and silence has several causes. A firewall rule set to drop packets, a host that is powered off, a missing port forward, or a routing problem all look identical to a single external probe.
Dropping is the normal behavior for well-configured firewalls, because it gives scanners nothing to work with. So a filtered result on a port you never meant to expose is good news. On a port you need open, it points you at filtering somewhere between the tester and the service.
To narrow it down, confirm the host answers at all (ping, if ICMP is allowed, or a known-open port like 443), then use how to trace a route techniques to see where the path stops.
Why UDP Needs a Different Test
UDP has no handshake. Send a packet to an open UDP port and the service may ignore it unless the payload matches its protocol. Send one to a closed UDP port and the host might return an ICMP port-unreachable, or a firewall might drop that reply.
That leaves most UDP checks with two outcomes: “closed” when an ICMP error arrives, and “open or filtered” when nothing does. Nmap labels this state open|filtered for exactly that reason. For DNS, game servers, VoIP, or WireGuard, test with a protocol-aware client (a DNS query with dig, the game client itself, a VPN handshake) and treat silence as inconclusive.
Why Is a Port Unreachable When the Service Is Running?
A running service is unreachable when something between the socket and the internet blocks or misroutes the connection. Work outward from the server: bind address and host firewall first, then the router or cloud edge, then your ISP’s network.
Check the Listening Service and Host Firewall
Confirm the process listens on the right interface. On Linux, ss -tlnp lists TCP listeners with their owning process; on Windows, netstat -ano | findstr LISTENING does the same.
Read the local address column carefully:
0.0.0.0:8080or[::]:8080means all interfaces, which is what you want for external access.127.0.0.1:8080means localhost only. No firewall change will fix this; edit the server configuration to bind to the LAN address or all interfaces.
Next, test from another machine on the same private LAN with netcat: nc -zv 192.168.1.50 8080. Success here proves the service and host firewall pass LAN traffic.
If the LAN test fails, inspect the host firewall. On Ubuntu, sudo ufw status verbose shows allowed ports; sudo iptables -L -n -v reveals raw rules and drop counters. Windows Defender Firewall rules are profile-specific, so a rule scoped to “Private” won’t help when the adapter is classified as “Public.”
Trace Port Forwarding, NAT, and Cloud Rules
At home or in a small office, NAT hides your LAN behind one public IP. Port forwarding settings tell the router which internal host receives traffic for a given external port. Common mistakes in a port forwarding test:
- The forward points to an old internal IP after DHCP reassigned the server. Use a DHCP reservation.
- The rule covers UDP when the service needs TCP, or the reverse.
- External and internal ports are mismatched.
- Double NAT: an ISP modem routes in front of your own router, so the forward on the inner router never sees traffic. Log into your router IP address and compare the WAN address with your public IP.
In the cloud, the equivalent layers are security groups and network ACLs. An AWS security group, Azure NSG, or GCP firewall rule must allow inbound traffic on the port from the right source range, and the instance’s own OS firewall still applies on top.
Rule Out CGNAT, VPN Routing, and ISP Filtering
If your router’s WAN address falls in 100.64.0.0/10 or doesn’t match your public IP, you’re behind carrier-grade NAT. CGNAT means inbound connections stop at your ISP’s NAT, and no router setting can forward them. Your options are an IPv6 path, a static public IP from the ISP, or a tunnel to a host with a public address.
A VPN client on the server changes routing too. Return traffic may leave through the tunnel, so the remote client sees replies from the wrong IP and drops them. Split tunneling or policy routing fixes that.
ISP filtering is the last suspect. Residential providers commonly block inbound port 80 and outbound or inbound port 25. If every other layer checks out, run the service on an alternate port such as 8080 and retest; a success there points at the provider. The broader network troubleshooting guidance on PacketTools covers isolating ISP-side faults.
Which Ports Should You Test?
Test the ports your public services need, plus the ones that should stay closed. Well-known server ports run from 0 to 1023, and application ports sit above that, often on defaults that attackers scan for constantly.
Common Web, DNS, Mail, and Remote-Access Ports
These are the common ports you’ll verify most:
| Port | Protocol | Service | Should it face the internet? |
|---|---|---|---|
| 80 | TCP | HTTP | Yes for web servers, mainly to redirect to HTTPS |
| 443 | TCP | HTTPS | Yes for web servers |
| 53 | TCP/UDP | DNS | Only on authoritative or intended public resolvers |
| 25 | TCP | SMTP (server-to-server mail) | Yes on mail servers only |
| 587 / 465 | TCP | Mail submission | Yes when clients send through your server |
| 22 | TCP | SSH | Restrict by source IP or put behind a VPN |
| 3389 | TCP | RDP | No; use a VPN or gateway |
| 21 | TCP | FTP | Rarely; prefer SFTP over port 22 |
| 23 | TCP | Telnet | No, it sends credentials in clear text |
| 445 | TCP | SMB | No |
If SMTP looks broken, check port 25 first, both inbound to your server and outbound from it, since many residential and cloud networks restrict it. PacketTools’ Email Health and SuperTool checks cover the DNS side of mail (MX, SPF, DKIM, DMARC) once the port answers.
Application, Database, Game, and P2P Ports
Databases are the ports you most want to see filtered from outside:
- MySQL / MariaDB: 3306
- PostgreSQL: 5432
- Redis: 6379
- MongoDB: 27017
An open result on any of these from the public internet usually means a bind address of 0.0.0.0 plus a permissive firewall or security group. Redis and MongoDB in particular have a long history of exposed instances with weak or no authentication.
Application ports vary by product. Alternate web ports 8080 and 8443 are common for admin panels and dev servers, and those panels deserve the same scrutiny as databases.
Game ports and P2P ports are the classic port forwarding cases. A Minecraft Java server defaults to TCP 25565; Plex uses 32400; torrent clients let you choose a port. Use the exact number configured in the application, and remember that many game servers also need UDP, which a TCP-only check won’t confirm.
How Can You Test Ports Responsibly?
Responsible port testing means checking only systems you control or have written permission to test, and treating a reachability result as one input to network security. A single connection attempt is ordinary traffic; sweeping thousands of ports on someone else’s hosts is reconnaissance.
Check Only Systems You Own or Are Authorized to Test
A one-port check against your own server is the same as a browser visit. A port scanner that sweeps ranges is different. By default, nmap <target> probes 1,000 TCP ports on the host, and running that against networks you don’t own can breach acceptable-use policies, trigger abuse reports, and in some jurisdictions create legal exposure.
Practical boundaries:
- Scan your own public IPs, domains, and cloud instances freely.
- For client or employer networks, get scope in writing: IP ranges, time windows, and allowed tools.
- Many cloud providers publish penetration testing policies; read them before running a network scanner against hosted assets, even your own.
- On shared hosting, your IP may front other customers. Test your port, not the whole address range.
A single-port checker fits verification work: “did my forward work?” Full port scanning with nmap fits audits, where you need an inventory of open ports and have authority to collect it. Keep the two jobs separate. An IP scanner on your own LAN helps with inventory before you expose anything.
Use Local and External Checks Without Mistaking Reachability for Security
Run both views. Local checks (ss, netstat, netcat from a LAN host) tell you what the server offers. External checks tell you what the internet can reach. A gap between the two shows which layer filters traffic.
An open result answers “can I connect?” and nothing more. Port 443 open on a web server is the goal. Port 3306 open to the world is an incident waiting to happen, even with a strong password.
After every external test, ask three things:
- Does this port need to be public at all?
- Can access be limited by source IP, VPN, or an identity-aware proxy?
- Is the service behind it patched and authenticated?
Retest ports you closed on purpose. A filtered result on RDP or a database from outside confirms the block works. More hardening material lives in the cybersecurity section.
Confirm the Path, Then Fix the Right Layer
A port check is most useful when you read it as evidence about a path. Open means a TCP handshake completed from that location. Closed means the host answered with a refusal. Filtered means silence, which could be a firewall, a missing forward, a dead host, or a broken route.
When a service runs but the port won’t open, work outward in order:
- Bind address and listener (
ss,netstat) - Host firewall (
ufw,iptables, Windows Defender Firewall) - Router port forwarding, NAT, or cloud security groups
- CGNAT, VPN routing, and ISP filtering
Treat UDP silence as inconclusive and verify with a protocol-aware client. Keep databases, RDP, SMB, and Telnet filtered from the internet, and limit scanning to systems you’re authorized to test. After each change, retest the single port from outside your network and compare the new result with the last one.
Leave a Reply