A service can be healthy inside a server and still be unreachable from the public Internet. A TCP port check answers the boundary question: will a connection from the WebLens server reach this port? What WebLens testsThe WebLens Port Checker attempts a TCP connection to…
A service can be healthy inside a server and still be unreachable from the public Internet. A TCP port check answers the boundary question: will a connection from the WebLens server reach this port?
What WebLens tests
The WebLens Port Checker attempts a TCP connection to the host and port you provide. If the connection succeeds, the result is open. If it cannot establish the connection within the timeout, the result is reported as closed or filtered. The response also includes the host, port, and connection time.
If no port is specified, WebLens uses port 80 by default. You can supply a port such as example.com:443 to test another TCP service.
How to check a service
- Enter the public hostname or IP and, when needed, a port.
- Run the WebLens Port Checker.
- Compare the state with the service you expect to be listening.
- If a web service is involved, use Website Status or HTTP Status afterward.
Open, closed, and filtered
An open result means the TCP connection was accepted from the WebLens environment. That is evidence that something is listening and reachable on that port from this source.
A closed or filtered result is intentionally broad. The destination may reject the connection, a firewall may drop it, the service may be stopped, the host may not be reachable, or an upstream network control may prevent the connection. The checker cannot distinguish every case from the socket result alone.
Example: HTTPS works but port 80 is closed
That can be normal. A server may intentionally expose HTTPS on 443 while refusing direct HTTP on 80. If the architecture requires HTTP-to-HTTPS redirects, however, port 80 may be expected to answer. The service design determines the correct interpretation.
Example: an internal application port is not public
A database or internal API might listen on a private network while a firewall blocks Internet access. A public check returning closed or filtered can therefore be evidence that the service is not exposed externally, which may be exactly what the architecture intends.
Why location matters
Firewall policies can be geographic or source-aware. A cloud provider may also apply network controls differently from your office connection. WebLens tests from its own infrastructure, so a port can be open to WebLens and blocked from another network, or the reverse.
Limits of a TCP port check
An open port does not prove that the application protocol is healthy. A process can accept TCP connections and then return errors at the HTTP, TLS, SMTP, or application layer. A filtered result does not prove that the service is stopped.
Need a public reachability check? Run the WebLens Port Checker with the host and port you need to inspect.
Check the service you actually intend to expose
A port number is only meaningful in relation to a protocol and architecture. Port 443 normally suggests HTTPS, while port 25 is commonly associated with SMTP, but a custom application can use almost any port. Confirm which process should be listening before deciding that an open or closed result is unexpected.
For an open port, follow up with a protocol-level check. For a closed or filtered port, inspect the service listener and firewall rules from inside your authorized environment. The public result tells you what an external connection can observe; it does not replace local socket or firewall inspection.
Why filtered results are intentionally ambiguous
Network devices may silently drop connection attempts. That can look similar to a stopped service from the outside. This is useful from a security perspective because an external observer often cannot tell which internal component made the decision. Use your own firewall and server logs to identify the exact cause.