Inside vs Outside: Test Both
"Is the port open" is really two questions. Locally, is a service actually running and listening on that port? Externally, can someone on the internet reach it through your router's firewall and port-forwarding rules? A port can pass the first test and fail the second — the service is up, but the router never forwards outside traffic to it. Always test in that order: confirm the service is listening, then confirm the outside world can reach it.
Step 1: Test From Inside (Is Anything Listening?)
Run these on the machine that should be hosting the service, or another device on the same network, pointing at the host's local IP (e.g. 192.168.1.50).
# See what your machine is listening on
# Windows
netstat -ano | findstr LISTENING
# macOS / Linux
sudo lsof -iTCP -sTCP:LISTEN -n -P
# Test reaching a specific port on a host
# macOS / Linux (netcat) — -z scan, -v verbose
nc -zv 192.168.1.50 25565
# Windows PowerShell
Test-NetConnection 192.168.1.50 -Port 25565
# Anywhere telnet is available
telnet 192.168.1.50 25565If nc -zv says succeeded or Test-NetConnection shows TcpTestSucceeded : True, the service is listening and reachable on your LAN. If it fails locally, the problem is the service itself or a local firewall — there is no point checking the outside world yet.
Step 2: Test From Outside (Can the Internet Reach It?)
You cannot test your own public IP from inside your network reliably — many routers do not "hairpin" traffic back, so it falsely looks closed. Use an external vantage point instead:
- Online port checkers — services like canyouseeme.org or a "port check tool" let you enter a port and test it against your current public IP from the internet's perspective. This is the single most reliable check for "can outsiders reach me."
- Your phone on cellular — turn Wi-Fi off so the phone is on the mobile network, then use a port-check app or
ncin Termux against your public IP. The phone is genuinely "outside" your home network. - A remote machine — if you have a VPS or a friend's computer, run
nc -zv your.public.ip 25565from there.
Find your public IP first by searching "what is my IP" or reading the WAN/Internet status page in your router admin panel.
Step 3: Read the Result
| Result | What it means | Where to look next |
|---|---|---|
| Open / succeeded | Service is listening and reachable from where you tested | Nothing — it works |
| Connection refused | Reached the host, but nothing is listening on that port (or a firewall reset it) | Start the service; check it binds to the right port and interface |
| Timed out (external only) | Packet silently dropped before reaching the service | Router port-forward rule, router firewall, or ISP/CGNAT |
| Open inside, closed outside | Service fine; router not forwarding or ISP blocking | Add a port-forward rule; check for CGNAT |
| Closed everywhere | Nothing listening at all | The service is not running — fix that first |
The Usual Culprits When a Port Won't Open
When the service listens locally but the outside world times out, the cause is almost always one of these, in rough order of frequency:
- No port-forwarding rule on the router, or the rule points at the wrong internal IP. If the host's IP changed because of DHCP, an old rule now forwards to nothing — assign the host a static/reserved IP.
- Carrier-grade NAT (CGNAT) — your ISP shares one public IP across many customers, so no inbound port can map to you. Compare your router's WAN IP to your public IP; if they differ (especially a 100.64.x.x WAN address), you are behind CGNAT. See double NAT for the closely related case of a second router in the chain.
- ISP port blocking — some providers block inbound 25 (SMTP), 80, or 443 on residential plans.
- Host firewall — Windows Defender Firewall or a Linux
ufw/firewalldrule blocking the port even though the service is up.
TCP vs UDP
Most of the tools above test TCP, where a successful handshake is a clear yes. UDP is connectionless — there is no handshake, so a "no reply" is ambiguous between "open but silent" and "blocked." Game servers and VoIP often use UDP, so if a TCP-style check shows nothing for a UDP service, that does not necessarily mean the port is closed. Use nc -u for a basic UDP probe, but trust the application's own connection test more than a generic port scan for UDP services.
Frequently Asked Questions
Why does a port show open locally but closed from outside?
Because two different things are being tested. A local test confirms the service is running and listening on your machine. An external test additionally has to pass through your router's firewall and any port-forwarding rule. If local works but external fails, the service is fine — the block is at the router (no port-forward rule) or at the ISP (CGNAT or a blocked port).
What does "connection refused" mean versus a timeout?
They are different failures. "Connection refused" means something answered and actively rejected you — usually nothing is listening on that port, or a firewall sent a reset. A timeout means nothing answered at all — typically a firewall silently dropping the packet, or the host being unreachable. Refused points at the service; timeout points at a firewall.
Why can't I open a port no matter what I do?
The most common reason today is carrier-grade NAT (CGNAT): your ISP shares one public IP among many customers, so there is no public address that maps to your router for an inbound port to reach. Some ISPs also block common ports like 25 or 80. Confirm by checking whether your router's WAN IP matches your public IP — if they differ, you are behind CGNAT and need a different approach such as a VPN or your ISP's static-IP option.
Is it safe to leave a port open?
An open port is only as safe as the service behind it. Exposing a well-maintained, authenticated service on a single forwarded port is routine. Exposing an unpatched service, or opening a wide range of ports "to be safe," increases your attack surface. Forward only the specific port the service needs, keep that service updated, and require strong authentication.