Open Port Checker

To check whether a port is open, enter the target public IP or hostname and the TCP port number, then run the test. The checker attempts a connection from outside your network. If the service accepts the TCP connection, the port appears open. If the host refuses it, the port is closed. If no response comes back, it may be filtered by a firewall. For example, testing TCP 443 on a web server confirms whether HTTPS is reachable externally, not whether the application behind it is healthy.

A port may show closed because no service is listening, the wrong IP was tested, the server firewall blocks it, the router is not forwarding it, or the ISP filters that port. For home labs, NAT is a common cause: the server is listening internally, but the router has no port-forward rule. For cloud servers, check security groups and network ACLs. Also confirm the service is bound to the correct interface. A local test can pass while an external checker fails if the firewall path is different.

To test port forwarding online, run the service on the internal server, create the router forwarding rule, then test the public IP and port from an external checker. The outside test is important because testing from inside the LAN may hit NAT loopback behavior and give a misleading result. Make sure the server's local firewall allows the port and that the router forwards to the correct internal IP. If your ISP uses CGNAT, port forwarding may not work even when your home router configuration is correct.

A filtered port usually means the probe received no clear response. A firewall may be silently dropping the packets, or an upstream device may be blocking them. This is different from closed, where the target actively refuses the connection. Filtered results can also happen due to rate limiting, wrong public IP, routing issues, or provider security policies. In troubleshooting, check the path step by step: service listening, host firewall, network firewall, NAT rule, public IP, and ISP restrictions. Do not assume filtered means the server is down.

To check whether port 80 is open on your server, enter the server's public IP or domain and test TCP 80. If it is open, an HTTP service or proxy is accepting connections. If it is closed, confirm that the web server is running and listening on port 80. Then check the operating system firewall, cloud security group, load balancer, and router NAT rules. Also remember that many sites redirect HTTP to HTTPS, but port 80 still needs to be reachable if you expect that redirect to work.

To check a TCP port from outside your network, use an online port checker or a remote host that is not behind the same firewall. Enter the public IP and TCP port. This tests the external view, which is what clients on the internet see. A local test from the server only proves the service is listening locally. If the outside test fails, check NAT, firewall policy, cloud security groups, ISP filtering, and whether the public DNS name points to the right address. External perspective is the key.

An open port checker is usually best for TCP. UDP is harder to confirm because UDP has no handshake like TCP. A UDP service may not reply unless it receives a valid protocol-specific request, so a generic test can falsely look closed or filtered. For UDP, use a tool that understands the service, such as DNS on port 53, or test from the application itself. Firewalls can also treat UDP differently. So yes, UDP testing is possible, but it needs more context than a simple TCP connect check.