Open Port Checker

An open port checker tries to reach a TCP port from the internet, outside your network. It tells you whether a service on that port can be reached, which is the test you need after setting up port forwarding.

An open port checker tests whether a specific TCP port is reachable on a remote host by attempting a socket connection (RFC 9293) with a fixed timeout. In plain terms: it checks whether a device on the internet is accepting connections on a specific port — the same check your browser makes every time you load a website. The tool accepts any IPv4 address, IPv6 address, or hostname and returns an open or closed status based on whether the TCP three-way handshake completes within 4 seconds. It also tells a closed port (the host answers with a TCP reset) apart from a filtered one (no answer at all, usually a firewall silently dropping the packets).

The checker opens a TCP connection from our server. If the handshake completes, the port is open; a reset (RST) means closed; no answer within 4 seconds means filtered, usually by a firewall.

• TCP socket connection attempt. The tool calls Java's Socket.connect() targeting the specified host and port with a 4-second timeout. If the TCP handshake — SYN, SYN-ACK, ACK — completes within that window, the port is reported as OPEN. If the host answers with a reset (RST), the port is reported as CLOSED. If the timeout elapses with no response, it is FILTERED. This is the same method used by the telnet command and nc -zv.
• OPEN vs CLOSED vs FILTERED. A closed port returns an immediate TCP RST, so the tool reports CLOSED: the host is reachable but no service listens on that port. A filtered port drops the packet silently, so the attempt times out after 4 seconds and the tool reports FILTERED: a firewall or a missing port forwarding rule is the most likely cause. A very slow or overloaded host can also appear FILTERED.
• TCP only — no UDP support. UDP port checking requires sending a datagram and waiting for an ICMP port-unreachable response, which most firewalls suppress. This makes remote UDP testing unreliable and is not supported. For UDP port verification, use nmap -sU from within your local network.
• External test point — not from your local network. The connection originates from this tool's server, not from your device. The result reflects port reachability from the public internet — exactly what is needed for port forwarding verification and firewall auditing. Internal services not exposed to the internet will appear CLOSED or FILTERED from this tool.

Port numbers are assigned by IANA (Internet Assigned Numbers Authority) and divided into three ranges: well-known ports (0–1023) reserved for standard services, registered ports (1024–49151) assigned to specific applications, and dynamic or ephemeral ports (49152–65535) used by clients for outbound connections.

Ports 1433, 3306, 5432, 5900, 6379, and 27017 should never be open on the public internet without strict firewall rules restricting access to known IP addresses. If this checker shows these ports as OPEN on a production server, review firewall configuration immediately.

Verifying port forwarding after router configuration. A home server administrator sets up a port forwarding rule on their router to expose a Minecraft server on port 25565. After saving the rule, they run the port checker with their public IP pre-filled and port 25565 to confirm external traffic is being correctly routed to the internal server. A CLOSED result immediately identifies whether the problem is the forwarding rule, the local firewall, or the application not listening on 0.0.0.0.

Auditing firewall rules after cloud server deployment. A DevOps engineer deploys a new cloud server and needs to confirm only the expected ports are reachable: 22 (SSH), 80 (HTTP), and 443 (HTTPS). Running the port checker against database ports 3306, 5432, and 6379 verifies the security group or iptables rules are enforced correctly from an external perspective — more reliable than checking locally where rules may differ by network interface.

Diagnosing email delivery failures. A mail server administrator experiencing SMTP delivery rejections uses the port checker to verify port 25 is open on the mail server's public IP. A CLOSED result on port 25 while port 587 is open indicates the ISP is blocking inbound SMTP — a common restriction on residential and shared hosting connections. The next diagnostic steps are to verify the server's PTR record using Reverse DNS Lookup and confirm the sending IP is not listed on a DNSBL using the IP Blacklist Checker.