Skip to main content

Port, TLS and HTTP checker

Test a public host from the PublicVPNList server. The tool reports DNS answers, TCP connect time and—when requested—TLS/SNI, certificate and first HTTP response signals. These backend measurements are not latency from your device and do not prove that a VPN tunnel works.

Run a public network probe

Only allowlisted public Internet ports are accepted. Generic UDP is not offered because a datagram alone cannot prove a service or protocol handshake.

What each result proves

  • DNS addresses: public A/AAAA answers observed before the connection.
  • TCP time: the server completed a TCP connection to the pinned address.
  • TLS: a handshake completed for the requested SNI; chain and hostname validation are reported separately.
  • HTTP status: the first response to a bounded HEAD / request. Redirects are reported but never followed.

A TCP or TLS success does not authenticate OpenVPN, WireGuard, VLESS or another tunnel protocol. Use a live catalog only when its dedicated client checker completed a full tunnel, HTTPS request and changed exit IP.

Advertisement

Backend safety controls

The endpoint rejects localhost, RFC1918, shared-address, link-local, benchmark, documentation, metadata and internal IPv6 ranges. It rejects mixed public/private DNS answers, pins the first validated public address, applies rate and input limits, uses short timeouts, reads only bounded headers and escapes output in the browser.

Certificate-focused viewValidate .ovpnFull-tunnel methodology

Frequently asked questions

Can this tool test a generic UDP port?
No. Without a protocol-specific handshake, a UDP datagram cannot establish that a service is listening or that a tunnel works.
Why can a host work for me but fail here?
Routing, geofencing, firewall rules and network paths differ. This result is from the PublicVPNList server.
Are redirects followed?
No. The first Location header is displayed, but the backend never follows it into another target.