Check if a port is open from anywhere on the internet.

首先确认服务正在监听所有网络接口，而不仅仅是本地回环地址（127.0.0.1）。然后检查主机防火墙是否允许该端口的入站流量，如果你在路由器后面，还需在路由器上配置 NAT 端口转发。使用我们的 端口检查器 to test from an external network. A closed result means the host is actively rejecting connections, which usually points to a missing firewall rule or a service that is not running. A filtered result means a firewall is silently dropping packets before they reach the host.

Enter a domain name or IP address and a port number between 1 and 65535, then click Check Port. The tool attempts a TCP connection from our server to your target, testing reachability from outside your own network. Open means the port accepts external connections. Closed means the host actively refused the connection with a TCP RST packet. Filtered means no response was received within the timeout period, which typically indicates a firewall is dropping packets silently.

A port checker sends a TCP SYN packet to a specified host and port, then interprets the response. If the port is open, the host replies with TCP SYN-ACK, completing the connection handshake. If closed, the host returns a TCP RST packet, actively refusing the connection. If filtered, no reply arrives and the request times out, indicating a firewall is silently dropping packets.

Port knocking hides a service port (typically SSH on port 22) by keeping it firewalled until a client sends connection attempts to a predefined sequence of ports in the correct order, for example 7000, 8000, 9000. The firewall detects this sequence and temporarily opens the target port for that specific IP address. Port knocking reduces exposure to automated scanners and brute-force attacks but is not a substitute for strong authentication.

A port is problematic when it is in an unexpected state. An unexpectedly open port may indicate a misconfigured service, a rogue process, or a compromised host. An unexpectedly closed or filtered port on a required service means traffic is being blocked. The key distinction is between closed and filtered: a closed port sends a TCP RST response, meaning the host is reachable but the service is not running. A filtered port returns nothing, meaning a firewall is blocking access before the host can respond.

TCP (Transmission Control Protocol) is connection-based and guarantees reliable, ordered delivery through a three-way handshake (SYN, SYN-ACK, ACK). Common TCP ports include 22 (SSH), 25 (SMTP), 80 (HTTP), 443 (HTTPS), and 3306 (MySQL). UDP (User Datagram Protocol) is connectionless and sends packets without confirming delivery, which reduces latency. Common UDP ports include 53 (DNS queries), 67 and 68 (DHCP), 123 (NTP), and game server ports such as 27015 (Counter-Strike). Most port checkers, including ours, test TCP connectivity.

Network ports are divided into three ranges defined by IANA. Well-known ports (0 to 1023) are assigned to standard protocols and include HTTP (80), HTTPS (443), SSH (22), FTP (21), SMTP (25), and DNS (53). Registered ports (1024 to 49151) are used by applications that registered with IANA, including MySQL (3306), PostgreSQL (5432), Redis (6379), and MongoDB (27017). Ephemeral or dynamic ports (49152 to 65535) are assigned temporarily by the operating system for outgoing connections.

Most residential ISPs block inbound connections on port 25 (SMTP), port 80 (HTTP), port 443 (HTTPS), and port 8080 to prevent customers from running public-facing servers on consumer connections. Port 25 is almost universally blocked on residential IPs to reduce spam origination. Some ISPs also block port 22 (SSH) inbound. Business-grade or static IP plans typically allow these ports.

Port forwarding is a NAT (Network Address Translation) rule configured on a router that redirects inbound traffic arriving on a specific external port to a private IP address and port inside the local network. When a packet arrives at your router's public IP on the forwarded port, the router rewrites the destination address and forwards the packet to the internal device. Without port forwarding, all unsolicited inbound traffic is dropped at the router because the router has no mapping for where to send it. To verify a port forward is working, use an external port checker after configuring the rule - if the port shows as open, the router is correctly forwarding to the internal service.

TCP port checking works by initiating a connection handshake (SYN) and interpreting the response: SYN-ACK confirms open, RST confirms closed, and no reply indicates filtered. UDP has no handshake mechanism - it sends a datagram and receives no acknowledgment if the port is open. An open UDP port simply accepts the packet silently. The only way to detect a closed UDP port is when the host returns an ICMP port-unreachable message, but many hosts suppress these messages, making UDP open and UDP filtered indistinguishable to a remote prober. This unreliability makes external UDP port checking impractical for most use cases.

The port checker confirms the TCP port accepts connections at the network level, but application-layer issues can still prevent your software from working. Common causes: the service requires TLS and your client is connecting without it (or vice versa); the service requires a specific hostname via SNI or virtual hosting that differs from the IP being tested; the application has IP allowlisting that blocks your client's IP while permitting the prober's; or the service accepts the connection then immediately closes it due to authentication failure. A port showing as open means the TCP handshake completed - it does not guarantee the service behind it will accept your specific request.

No. An external port checker sends probes from a server on the public internet and cannot reach private IP address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or the loopback address (127.0.0.1). These addresses are not routable on the public internet - packets sent to them are dropped at the first router. To test ports on a local machine or private network, use command-line tools such as nc (netcat), telnet, or nmap directly from within the same network. External port checkers are only useful for testing public-facing services.

The principle is to expose only the ports your service explicitly requires and firewall everything else. High-risk ports that are frequently targeted by automated scanners include: 22 (SSH) - restrict to specific source IPs or move to a non-standard port; 23 (Telnet) - disable entirely, use SSH instead; 3389 (RDP) - never expose publicly without a VPN in front; 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB) - database ports should never be publicly accessible. FTP (21) should be replaced with SFTP over SSH. Run a port scan against your own server periodically to confirm no unexpected services have been exposed.

The TCP three-way handshake is the connection establishment sequence used before any data is exchanged. Step 1: the client sends a SYN (synchronize) packet with a randomly chosen sequence number. Step 2: if the port is open, the server responds with SYN-ACK, acknowledging the client's sequence number and sending its own. Step 3: the client sends ACK to confirm receipt, completing the handshake. Port checkers use this mechanism to determine port state: a SYN-ACK in step 2 confirms the port is open. A RST (reset) response instead of SYN-ACK means the port is closed. No response within the timeout period means the port is filtered by a firewall.