Paste a host and port to see if it’s reachable from the internet. ScanPort helps you troubleshoot routers, firewalls, NAT, and services—plus clear fixes for common port-forwarding and ISP issues.

When something won’t connect—game servers, self-hosted apps, remote desktops—it’s usually a port problem. Is the service actually listening? Did the router forward correctly? Is a firewall snipping the traffic? ScanPort cuts through the guesswork. Enter a public host/IP and a port, choose TCP or UDP, and the tool reports whether that port responds from the outside world. You’ll also get context that turns results into steps: what likely blocks the path and how to fix it.

This article is written from scratch to be original, clear, and SEO-friendly. It explains what ScanPort checks, why open ports matter, how to read results, and the most common misconfigurations to fix first—without drowning you in jargon.

What ScanPort actually does (in plain language)

• External reachability test: From a vantage point on the internet, ScanPort tries to reach the host and port you specify.
• TCP vs. UDP awareness: For TCP, it checks if the three-way handshake succeeds or fails. For UDP, it sends a small probe and watches for likely signs of reachability (see the UDP section below).
• Service hints (optional): If a TCP connection succeeds, it may read a short banner when safe (e.g., generic “HTTP” or “SSH” signal) to confirm you reached the intended service—without collecting content.
• Timing & path clues: It distinguishes between connection refused (something is there, but not listening), timeout (filtered or blackholed), and network unreachable (DNS/routing issue).
• Basic hygiene checks: Reminds you to avoid scanning hosts you do not control or have permission to test.

Result: A simple “reachable / not reachable” verdict plus meaningful next steps based on what failed.

Why open ports matter

• Troubleshooting: If the world can’t reach your port, clients will fail regardless of your app’s code.
• Security: Any open port is a doorway; you want it intentionally open and properly secured.
• Networking clarity: Tests from outside your network catch issues internal tests miss (NAT, ISP blocks, hairpin quirks).
• Uptime & reliability: Verifying ports during deploys or after router changes prevents late-night outages.

How to use ScanPort well (60-second workflow)

1. Choose the target: Use your public DNS name (e.g., example.mydomain.com) or your public IP.
2. Pick the protocol: TCP is most common (web servers, SSH, RDP). Choose UDP for services like game servers, WireGuard, or custom UDP daemons.
3. Enter the port: e.g., 22 (SSH), 80/443 (web), 25565 (Minecraft), 1194/51820 (VPN).
4. Run the check: You’ll see Reachable / Not reachable plus a short explanation (refused vs. timed out).
5. Apply the fix from the sections below—then retest to confirm.

Interpreting results (and turning them into fixes)

TCP results

• ✅ Reachable (TCP handshake succeeded)
  Your port is open from the internet and a service is listening. If you still can’t connect from a client, look at application-level issues (TLS/SNI, authentication, IP allowlists) or client-side firewalls.
• 🟥 Connection refused (RST)
  The probe reached your host, but no service is listening on that port—or a local firewall rejected it.
  Fixes:
  • Ensure the app is running and bound to the correct interface (often 0.0.0.0 or the server’s private IP).
  • Verify the port number in the app’s config.
  • Check host firewall rules (Windows Defender Firewall, ufw/firewalld/security groups) to allow inbound on that port.
• 🟧 Timed out (filtered)
  Something dropped the packet—common with router firewalls, ISP filters, or cloud security groups.
  Fixes:
  • On home/office networks, create/verify port forwarding (NAT) to the correct internal IP of your device.
  • Open the port on the router firewall and the host firewall.
  • Ask your ISP if they block inbound ports (some block 25, 80, 445, etc.). If so, use an alternate port or a reverse proxy/tunnel.
  • In cloud environments, align security groups / network ACLs with the instance’s OS firewall.

UDP results

UDP is connectionless—there’s no handshake. That makes “open” harder to prove.

• 🟩 Likely reachable (UDP response observed)
  The target answered (e.g., an expected reply or ICMP port-unreachable behavior flipped). This usually means the path is open.
• 🟨 Inconclusive (no response)
  Many UDP services don’t reply to random probes. The path might be open, but silent.
  Fixes:
  • Temporarily configure your UDP service to respond to a known probe if possible, or test with the real client.
  • Ensure port forwarding includes UDP, not just TCP.
  • Check router features like SIP ALG / “helper” that sometimes mangle UDP traffic—turn them off for testing.
• 🟥 ICMP unreachable (port/host/network)
  Upstream devices signaled a block or no route.
  Fixes: Verify routing, firewall rules, and NAT for UDP; some ISPs filter popular UDP ports due to abuse.

The usual suspects (and how to fix them fast)

1) Port forwarding/NAT is wrong

• Symptom: Timeouts from outside, but local clients work.
• Fix: In your router, forward the correct public port to the correct internal IP and port, with the right protocol (TCP/UDP). Reserve the device’s IP with DHCP reservation so it doesn’t change.

2) Hairpin NAT (NAT loopback) confusion

• Symptom: Host works by public name from inside your LAN but fails for external users—or vice versa.
• Fix: Test from a cellular network or outside Wi-Fi to get a real external perspective. If hairpin fails, add split DNS for internal clients or enable NAT loopback on the router.

3) Host firewall blocking

• Symptom: “Connection refused” or “timeout” despite forwarding.
• Fix: Allow inbound on the port in Windows Firewall, ufw/firewalld, or security groups. Confirm the service binds to the right interface.

4) Service not listening (or wrong bind)

• Symptom: Refused connections.
• Fix: Start/restart the service; verify it listens on the intended port and all network interfaces, not just 127.0.0.1 (loopback).

5) ISP or hosting provider blocks

• Symptom: Persistent timeouts on well-known ports (25, 80, 443, 445).
• Fix: Ask the ISP about inbound filtering or CGNAT (Carrier-Grade NAT). Use different ports, request a public/static IP, or place the service behind a reverse proxy / cloud tunnel.

6) CGNAT (no true public IP)

• Symptom: Your router’s “WAN IP” differs from your public IP on “what’s my IP” sites; port forwards never work.
• Fix: Request a public IP from your ISP, upgrade plan, use IPv6 if supported (and forward appropriately), or use reverse tunnels (Cloudflare Tunnel, Tailscale Funnel, etc.).

7) DNS issues

• Symptom: IP works, hostname doesn’t.
• Fix: Fix A/AAAA records and TTLs; ensure the name points to your current public IP. For dual-stack, ensure the service is reachable on both IPv4 and IPv6 or limit the record accordingly.

TCP or UDP? Pick the right test

• TCP: Web servers (80/443), SSH (22), RDP (3389), MySQL/Postgres (3306/5432), game servers with TCP components.
• UDP: Many game servers, VoIP, WireGuard/OpenVPN, DNS (53), streaming telemetry. Remember: UDP “silence” ≠ closed.

Safety & etiquette (important!)

• Test only hosts you own or have permission to test. Port probing can trigger alerts.
• Keep exposure intentional. If a port is reachable, harden the service (auth, TLS, least privilege, IP allowlists where appropriate).
• Avoid default ports for sensitive admin interfaces exposed to the public internet; prefer VPN, zero-trust access, or at least strong auth and rate limiting.

Quick decision tree (clipboard-friendly)

1. Scan says “reachable” → App still failing?
   • Check app logs, TLS/SNI, credentials, allowlists, or protocol mismatch.
2. “Refused” →
   • Service down or wrong port/bind. Start service, correct bind, open host firewall.
3. “Timeout/filtered” →
   • Router/NAT/ISP filtering. Verify port forwarding (TCP/UDP), router firewall, cloud security groups, ISP blocks, or CGNAT.
4. UDP “no response” →
   • Could be fine. Test with the real client, ensure UDP forwarding, and disable “helpful” router ALGs.

Who benefits from ScanPort

• Home lab & gamers: Validate server reachability for Minecraft, Valheim, Plex, etc.
• IT & MSPs: Rapid checks after firewall/router changes; share a one-page result with clients.
• Developers & DevOps: Confirm staging/production ingress after deploys; sanity-check load balancer or reverse proxy rules.
• Educators & learners: See real networking behavior (refused vs. filtered vs. open) without complex tooling.

FAQs

Can ScanPort check multiple ports at once?
Yes—run them sequentially or via a quick batch. Prioritize the exact ports your app needs.

Does it work with IPv6?
If your hostname has an AAAA record and the service listens on IPv6, ScanPort can test it. Ensure your firewall/NAT rules include IPv6 where relevant (no NAT with v6, but you still need rules).

What about services behind a reverse proxy?
Scan the proxy’s public endpoint. If that’s reachable but the app fails, inspect proxy routing and upstream health checks.

Is UDP reliable to test?
We provide best-effort signals. For certainty, test with the actual client or configure your service to reply to a known probe.

Will this fix my router automatically?
No. ScanPort diagnoses from the outside; you’ll apply the router/firewall changes.

Suggested hero image & alt text

Concept: A clean “ScanPort — Open Port Checker” dashboard on a laptop showing Host and Port inputs, Protocol: TCP/UDP toggle, and a big Test button. Results show a large Reachable / Not reachable badge, a small line with Refused / Timed out / Handshake OK, and a side card “Likely cause & next steps” listing Port forwarding, Firewall, ISP block/CGNAT. Neutral UI, no real domains/IPs.

Alt text: “Open port checker interface showing host/port inputs, TCP/UDP toggle, and a clear reachable status with suggested fixes.”

Final takeaway

Ports are either listening and reachable, listening but blocked, or not listening at all—and knowing which one you’re dealing with is half the battle. ScanPort gives you a fast, outside-in verdict and plain steps to fix the rest: correct NAT/forwarding, open the right firewall rules, ensure the service is bound and running, and steer around ISP blocks or CGNAT. Retest after each change, and you’ll go from “it doesn’t work” to “we’re live” in minutes.