Port Checker

A port checker — also called a port scanner (though this tool scans one port at a time, deliberately) — answers a simple question: if something out on the internet tries to connect to this host on this port, will the connection succeed? This is the networking equivalent of knocking on a door to see if someone answers. It is one of the most common diagnostic actions in system administration and web development: confirming that a web server is actually listening on port 443 after deploying an SSL certificate, verifying that a MySQL database is not accidentally exposed to the public internet on port 3306, checking whether the IT team really did open port 587 on the corporate firewall for the new email relay, or diagnosing why an API client can reach the server but gets connection-refused errors (often a firewall allowing traffic on port 443 but the application only listening on localhost).\n\nThe tool attempts a TCP connection from our server to the host and port you specify using PHP\u0027s fsockopen function with a 3-second timeout. If the three-way TCP handshake completes (SYN, SYN-ACK, ACK), the port is reported as open and the connection is immediately closed — no data is sent, no banner is read, no authentication is attempted. If the connection is refused (TCP RST), the port is reported as closed, which usually means no service is listening on that port but the host is reachable. If the connection times out (no response in 3 seconds), the port is also reported as closed — the host is either unreachable, a firewall is silently dropping packets to that port, or the network path has high latency.\n\nA deliberate design decision keeps the tool simple and safe: it only accepts well-known service ports (1-1023 plus a handful of common alternatives like 3306, 5432, 6379, 8080, 8443). This prevents the tool from being used as a general port scanner for reconnaissance, and ensures it is only used for the legitimate diagnostics it is designed for. The server-side approach is necessary because browsers cannot open raw TCP connections to arbitrary hosts — they are restricted to HTTP(S) and WebSocket protocols. The connection appears to come from our server\u0027s IP, not from yours, which means this tool cannot test whether a firewall rule that is scoped to your specific IP address is working — it tests connectivity from our infrastructure perspective.\n\nA subtle but important point: an "open" result means TCP connectivity succeeded; it does not mean the service on that port is functioning correctly. A database server could accept TCP connections on port 3306 but reject every authentication attempt because of a misconfigured user table. A web server could accept connections on port 443 but serve a 500 Internal Server Error for every request. Port checking tests network-level reachability, not application-level health. For that, you would need a service-specific health check (an HTTP request to a health endpoint, a database login attempt with test credentials, etc.).\n\nRate limiting is conservative — 15 checks per minute — because each check involves a real network connection from the server. This is intended for occasional manual diagnostics, not for automated monitoring or bulk scanning. For production monitoring, a dedicated monitoring service with configurable intervals, alerting, and historical uptime data is the right tool.