External probe
Check reachability from outside your local network to spot firewall, router, ISP, or CGNAT issues.
Run one external check and see TCP and UDP reachability side by side. Use Port Checker to verify open ports, troubleshoot port forwarding, and separate closed services from filtered or inconclusive paths.
Enter an IP address or hostname with a target port.
Always confirm you have permission before scanning or testing endpoints you do not own.
Instant port testing
Port Checker combines a fast external test with practical context for port forwarding, firewalls, TCP, UDP, and filtered network paths.
Check reachability from outside your local network to spot firewall, router, ISP, or CGNAT issues.
See TCP and UDP side by side, including inconclusive UDP results that should not be treated as closed.
Use clear next steps for closed, filtered, and open-or-filtered results during network changes or outages.
How it works
The test runs from an external network, so it shows whether a TCP or UDP service is reachable from the public internet rather than only from your local machine.
Provide a public IP address, IPv6 address, or hostname and the port you want to check.
Port Checker sends TCP and UDP probes from an external network, similar to how remote clients would reach your service.
A TCP handshake or UDP response means open. Refused, timed-out, or silent responses are interpreted separately.
Use the result to verify port forwarding, firewall rules, cloud security groups, CGNAT, and service availability.
Result meanings
TCP and UDP behave differently. Read each status with your firewall, router, ISP, NAT, and application configuration in mind.
TCP accepted a connection or UDP returned a response.
Confirm the exposed service is expected, patched, authenticated, and monitored.
The target explicitly rejected the check or reported that nothing is listening.
Check whether the service is running, listening on the right interface, and allowed through the firewall.
Packets appear to be blocked or dropped before a clear TCP response is received.
Review host firewalls, cloud security groups, ACLs, router rules, ISP filtering, and source-IP allowlists.
UDP did not respond, so the port may be open but silent, filtered, or dropped by NAT or a firewall.
Use a protocol-specific client test and compare the router WAN IP with your public IP to check for CGNAT.
Instant port testing
Jump into common port guides, then run an open port check to confirm TCP and UDP reachability where it matters.
Encrypt web applications with TLS certificates on port 443.
Transfer files securely through SSH tunnels.
Manage servers remotely with encrypted shell access.
Serve file shares and authentication over TCP.
Serve web traffic without encryption on port 80.
Legacy plaintext remote console access.
Provide name resolution for infrastructure.
Monitor infrastructure with SNMP polling and traps.
Set up VoIP signaling on SIP ports.
Connect to remote desktops with VNC on port 5900.
Provide Windows remote desktop access.
Distribute precise time to fleet devices.
Test reachability and latency with ICMP echo.
Expose internal apps through reverse tunnels.
Host multiplayer Minecraft worlds.
Serve classic file transfers on ports 20/21.
Retrieve email messages from servers.
Expose relational databases to applications.
FAQ
Get clear answers about open port checks, TCP and UDP results, port forwarding, and filtered network paths.
An open port checker tests whether a remote TCP or UDP service can be reached from the public internet. It helps confirm service exposure, port forwarding, firewall rules, and basic reachability.
Port forwarding maps an external port on your router or firewall to an internal service. It enables access from the internet to devices on private networks.
The service may not be listening, the firewall may still block inbound traffic, the router rule may point to the wrong device, or the connection may be behind double NAT or CGNAT. Compare the router WAN IP with your public IP and verify the service locally.
TCP has a connection handshake, so open, closed, and filtered states are easier to infer. UDP has no handshake, so many valid UDP services stay silent unless they receive a protocol-specific request.
If a UDP probe receives no response, the port may be open but silent, filtered by a firewall, dropped by NAT, or blocked upstream. No response is inconclusive, so it should not be treated as closed.
Consumer ISPs often block ports such as 25, 80, or 445 to reduce malware and spam. Contact your provider about business plans if you need them opened.
We process the host and port you submit to run checks and keep limited technical logs for reliability and abuse prevention. See the Privacy Policy for details on retention and handling.
No. This tool is best for point-in-time diagnostics. For production systems, pair it with continuous monitoring, service health metrics, and alerting.