HTTP to HTTPS redirects and redirect chain analysis

1. What is HTTPS and why it matters

HTTPS is HTTP over TLS (formerly SSL). It encrypts the connection between the browser and your server so that passwords, session cookies and personal data cannot be read or modified in transit.

Why your site should be HTTPS-only

Running your site over HTTPS protects visitors against eavesdropping and tampering, improves trust, and is now a ranking factor for search engines. Many modern browser features, such as HTTP/2, Service Workers or powerful APIs, are only available on secure origins.

How HTTPS relates to DNSprobe checks

The SSL section of DNSprobe validates your certificate and chain, while the HTTPS section focuses on how users are redirected from HTTP to HTTPS and how many hops it takes to reach the final secure URL.

2. Automatic HTTP to HTTPS redirect

Ideally, any request to http://yourdomain/ should immediately redirect to https://yourdomain/ with a permanent redirect (301 or 308).

Why forcing HTTPS is important

If HTTP stays accessible without redirecting to HTTPS, some visitors or old links may continue to use the insecure version of your site. This weakens security, can cause duplicate-content issues for SEO, and may break cookies that are marked as secure-only.

How to configure the redirect

You can enforce HTTPS at the web server level with rewrite rules, in your application, or via your CDN / reverse proxy. For best results, the redirect should be applied as early as possible, directly at the front web server or load balancer.

Best practices for the HTTP → HTTPS redirect

• Use a permanent redirect (301 or 308) from HTTP to HTTPS for the canonical hostname.
• Avoid unnecessary intermediate redirects such as HTTP non-www → HTTPS non-www → HTTPS www when a single hop can do the job.
• Keep the path and query string unchanged when redirecting (for example, /page?ref=x should stay /page?ref=x on HTTPS).

3. Redirect chain and number of hops

When DNSprobe tests your domain, it starts from http://example.com/ and records every redirect (3xx status code) until a final response is reached or a hop limit is exceeded.

What is a hop?

Each redirect from one URL to another is counted as one hop. For example, http://example.com/ → https://example.com/ is 1 hop; http://example.com/ → http://www.example.com/ → https://www.example.com/ is 2 hops.

Why too many hops are a problem

Every extra hop adds at least one additional round-trip between the browser and your server. This increases page load time, multiplies TLS handshakes, and can make your site feel slow on mobile or high-latency connections. Long redirect chains also increase the risk of misconfigurations, redirect loops, loss of tracking parameters and SEO issues.

How DNSprobe interprets the redirect chain

DNSprobe shows the full redirect chain in the report, with the HTTP status code and the destination of each hop. If it detects a hop where the scheme switches from HTTP to HTTPS, the test is marked as passing. If the final URL still uses HTTP or no redirect is seen, DNSprobe warns you so that you can enforce HTTPS.

4. Common redirect scenarios

Here are some frequent patterns you may see in the HTTPS report and what they typically mean:

• HTTP non-www → HTTPS non-www (1 hop): simplest configuration when your canonical hostname is example.com.
• HTTP non-www → HTTP www → HTTPS www (2 hops): often used when www is the canonical hostname but can usually be simplified.
• HTTP → CDN or reverse proxy → HTTPS origin: redirection handled by a CDN such as Cloudflare, which then connects securely to your server.
• Multiple HTTP hops or cross-domain redirects: can indicate legacy rules, chained load balancers, or misconfigurations that should be cleaned up.

5. Best practices and troubleshooting

If DNSprobe reports that your site stays on HTTP or uses too many hops, use the following checklist to improve your configuration.

Server-side recommendations

• Configure a single, clear redirect rule from HTTP to the HTTPS canonical hostname, ideally at the first entry point (front web server or CDN).
• Remove old or overlapping rewrite rules in .htaccess, nginx.conf, virtual host files or application frameworks.
• Make sure the SSL certificate for the final HTTPS hostname is valid and matches the domain, so that browsers do not display security warnings.

Debugging redirect issues

• Use tools like curl, your browser’s network panel or the DNSprobe HTTPS report to inspect each hop and its HTTP status code.
• Watch out for redirect loops (for example, HTTP → HTTPS → HTTP) and inconsistent hostnames (mixing www and non-www).
• When using a CDN or reverse proxy, ensure that both the proxy and the origin server agree on the final HTTPS URL to avoid double redirects.

6. Test HTTP→HTTPS redirects manually from your own terminal

The HTTPS section in DNSprobe checks whether your site correctly redirects plain HTTP traffic to HTTPS and counts the number of hops in the redirect chain. You can reproduce the same behaviour from a terminal using curl to inspect the HTTP response headers and follow redirects.

Linux: using curl to inspect the redirect chain

On most Linux distributions, curl is installed or available in the default repositories. The following commands first show you how the server responds to a direct HTTP request, and then how the full redirect chain behaves when you allow curl to follow redirects:

                curl -I http://example.com/
    
                # First request: check if HTTP (port 80) returns a redirect status such as 301/302 pointing to HTTPS    
                curl -I -L http://example.com/
        

macOS: using curl from the built-in tools

macOS ships with curl as part of its standard command-line tools. Open Terminal and run the same commands as on Linux to see whether your site performs an HTTP→HTTPS redirect and how many hops are involved:

                curl -I http://example.com/
    
                # First request: check if HTTP (port 80) returns a redirect status such as 301/302 pointing to HTTPS    
                curl -I -L http://example.com/
        

Windows: using curl from Command Prompt or PowerShell

On modern versions of Windows 10 and 11, curl is included by default. From a Command Prompt or PowerShell window, you can use curl in exactly the same way as on Linux/macOS to verify that HTTP redirects to HTTPS and to inspect the redirect chain:

                curl -I http://example.com/
    
                REM First request: check if HTTP (port 80) returns a redirect status such as 301/302 pointing to HTTPS    
                curl -I -L http://example.com/
        

Important: only test hosts and domains that you own or are authorised to analyse. Repeated automated HTTP/HTTPS checks against third-party systems without permission may be treated as abusive behaviour by some providers.