DNS Tools
WEBSITE TRANSPORT

HTTPS Checker

See whether your domain is reachable over HTTPS, which IPv4 and IPv6 addresses accept connections, and how long each step takes.

Run HTTPS connectivity

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What the HTTPS checker does

The checker resolves the domain, connects to the site over HTTPS on port 443, validates the certificate against a standard trust store for the name it contacted, and records what came back. It then follows redirects only between the apex name and its www counterpart, up to four requests, and re-validates every hop before contacting it. The result shows the start URL, the final URL, the final status, the host where a visitor lands, the address used, the TLS version and cipher, and timing for the TCP connect, TLS handshake and first byte of each request.

A second table tries a TCP connection to port 443 on every published address, IPv4 first and IPv6 as a fallback. That matters because a site with several servers can look healthy from one address while another quietly refuses connections.

How to read the results

The headline combines transport and certificate: reachable and trusted, reachable but the certificate needs attention, or not reachable at all.

  • Final status: a 200 means the landing page loaded. A 301 or 302 chain that ends in 200 is normal. A 403 or 429 may mean the site blocks automated clients, not that it is down.
  • Connected address and family: shows whether the check used IPv4 or IPv6.
  • TLS and cipher: the session the default client negotiated, which describes this scanner's client, not every browser.
  • Timing: connect, handshake and first-byte times in milliseconds from this scanner's location. Treat them as a rough indication, not a performance benchmark.
  • Per-address result: OPEN, REFUSED, TIMEOUT or NO ROUTE. NO ROUTE for IPv6 means the scanner has no IPv6 connectivity, so it was not tested.

When HTTPS fails

The tool distinguishes three failure types. If no A or AAAA record exists at the apex or www, there is no website to test and the result is not applicable. If port 443 refuses connections, nothing serves HTTPS at that address. If the TLS handshake completes but certificate verification fails, the reason is shown, such as expiry, a hostname mismatch, a self-signed certificate or an untrusted issuer.

A certificate failure is a different problem from a connection failure. Browsers show a warning for the first and a plain error for the second; the repair differs as well. The certificate expiry and TLS tools go deeper into the certificate itself.

Common problems

  • Only the apex or only www has HTTPS: the certificate or virtual host covers one name. Add the missing name to the certificate and server configuration.
  • One address refuses 443: a stale A or AAAA record points to a server that no longer serves the site.
  • Certificate for the wrong name: the server presents a default host certificate because the requested name is not configured.
  • HTTPS works but HTTP does not redirect: visitors who type the plain address are not moved to HTTPS; see the redirect checker.
  • 403 or 503 for the scanner only: a bot-protection layer may be blocking automated requests.

How to fix HTTPS problems safely

Prerequisites: control of the web server or CDN configuration and a certificate that covers every name you serve. Risk: replacing a certificate or changing listeners can interrupt visitors for a moment. Rollback: keep the previous configuration file and certificate so you can reinstate them.

  1. Confirm which servers answer for the domain by listing every A and AAAA record and testing each address.
  2. Remove records that point to retired servers, or restore the service on them.
  3. Install a certificate whose subject alternative names include both the apex and www, with the full intermediate chain.
  4. Reload the server and verify with a browser and with this tool.
  5. Only after HTTPS works everywhere, consider redirects from HTTP and HSTS.

Limits

Only the apex and www names are contacted. The checker identifies itself honestly rather than imitating a browser, so some sites that block automated clients will not show their real behaviour. It speaks HTTP/1.1 only, so HTTP/2 and HTTP/3 support is not tested. One path, the site root, is requested from one network position; other pages, regions and load-balanced nodes may differ.

Frequently asked questions

Does a successful result mean my site is secure?

No. It means the site answers over HTTPS with a trusted certificate. Headers, application security and server patching are separate.

Why does my site work in a browser but fail here?

A bot-protection layer, a regional rule or an IPv6-only path can make an automated client behave differently from a browser.

Why is IPv6 listed as NO ROUTE?

The scanner could not use IPv6, so those addresses were not tested. That is not a failure of your site.

Are the timings reliable?

They are single measurements from one location and indicate order of magnitude only.

Why was the redirect to another host not followed?

For safety the checker stays within the domain's apex and www names; off-site redirects are reported but never contacted.

Is www required?

No. But if www exists in DNS, it should serve HTTPS with a valid certificate too.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.

Written by DNS Tools editorial · Last updated 2026-10-09