Port Checker

About Port Checker

<p>Port Checker sends a TCP connection attempt from our server to a hostname or IP address on the port you specify, then reports one of three states: open, closed, or filtered. Each state means something distinct. Open means a service accepted the TCP handshake. Closed means the host responded with a TCP RST packet: the port is network-reachable but nothing is listening on it. Filtered means no response arrived before the timeout period ended: a firewall, cloud security group, or network ACL is silently dropping the packets before they reach the host.</p><p>The test originates from our server, not your browser, so the result shows public internet reachability from an external vantage point. It tells you what any user on the open internet would see when attempting to connect, which is different from what your local machine, corporate VPN, or internal network allows. Developers verify deployed services are reachable before pointing DNS at a new server. Sysadmins confirm a firewall rule change took effect. DevOps engineers isolate network faults: if Port Checker reports "filtered" and application logs show connection timeouts, the problem is a firewall rule, not the application.</p><h3>How to check a port</h3><ol><li>Enter the hostname (for example, <code>api.example.com</code>) or IPv4 address in the host field. Subdomains are supported; the tool resolves the hostname to an IP before testing.</li><li>Enter any port number from 1 to 65535, or click one of the common-port quick-select buttons: HTTP (80), HTTPS (443), SSH (22), FTP (21), MySQL (3306), SMTP (25 and 587), or HTTP-alt (8080).</li><li>Click <strong>Check port</strong>. The test runs from our server and returns a result in 2 to 10 seconds. Filtered ports take longer because the tool waits for the TCP timeout.</li><li>Read the result: <strong>Open</strong> (service is accepting connections), <strong>Closed</strong> (host reachable, nothing listening), or <strong>Filtered</strong> (firewall or ACL blocking the packet).</li></ol><h3>What open, closed, and filtered actually mean</h3><p>The three states map directly to what happens at the TCP layer:</p><ul><li><strong>Open:</strong> Our server sent a SYN packet. The remote host replied with SYN-ACK. A service is running and accepting connections on that port. The tool immediately sends RST to close the connection without completing a full session.</li><li><strong>Closed:</strong> Our server sent a SYN packet. The remote host replied with RST. The host is reachable at the network level, but no process is bound to that port. This is the expected state for ports your server is not using, and it is different from blocked: the host is responding, just rejecting the connection.</li><li><strong>Filtered:</strong> Our server sent a SYN packet. No response arrived before the timeout. A firewall, security group, or network ACL is dropping the packets silently rather than sending RST. Filtered ports take longer to test because there is no negative response to receive: the tool has to wait for the TCP connection to time out, typically 3 to 10 seconds.</li></ul><h3>Technical details</h3><p>The check runs from a fixed server IP address. This affects results in two cases: if the target applies source-IP allowlisting (permitting only specific IPs), our connection attempt will be blocked even if other IPs can connect freely; if the target applies geo-IP filtering, results may differ from what users in other regions see. The tool is an external public-internet connectivity check, not a test of local or VPN-internal reachability.</p><p>Private and loopback IP ranges are blocked from testing: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 127.0.0.0/8. Sending TCP probes from our server to RFC 1918 addresses would always time out and report "filtered," which gives no useful information and probes addresses in address space the requester may not own.</p>

Common use cases

• Firewall rule verification: Confirm that a new firewall or security group rule allowing a port is actually visible from outside the network, not just applied in the local ruleset.
• Post-deployment service health check: Verify that a newly deployed service is listening on the expected port and reachable from the public internet before pointing DNS or updating a load balancer target.
• Database and service connectivity diagnosis: Isolate whether a connectivity problem is a network/firewall issue (filtered) or an application issue (closed or open but refusing) without needing SSH access to the affected server.
• SMTP port availability check: Determine which outbound SMTP ports a hosting provider allows before configuring a mail relay, avoiding failed delivery attempts and log-based diagnosis.
• Third-party API reachability: Confirm a partner or vendor API endpoint is reachable at the TCP level before diagnosing application-layer errors, providing specific evidence for support escalations.

How to use this tool

1. Enter the hostname (for example, example.com) or IP address you want to check.
2. Type a port number between 1 and 65535, or click one of the common port quick-select buttons.
3. Click "Check port" to run a live TCP connection test from our server.
4. Review the result showing whether the port is open, closed, or filtered, along with the resolved IP and response time.

Frequently asked questions