HTTPS problems can block secure access, trigger browser warnings, and hurt user trust in seconds.
This guide explains how to fix HTTPS not working by tracing the issue from the browser to the server, including certificate errors, redirects, DNS, and mixed content.
What HTTPS Not Working Usually Means
When HTTPS fails, the problem is rarely the same twice.
The browser may show a privacy warning, a certificate error, a redirect loop, or a blank page that never loads over https://.
Common symptoms include:
- Certificate warnings such as “Your connection is not private”
- Redirect loops between HTTP and HTTPS
- Mixed content errors caused by insecure assets on a secure page
- Connection refused or timeout errors on port 443
- Cloudflare, proxy, or load balancer SSL errors
Check the SSL Certificate First
The most common cause is an invalid or misconfigured SSL/TLS certificate.
A browser will reject HTTPS if the certificate is expired, not trusted, or issued for the wrong hostname.
Verify the certificate status
Confirm that the certificate is active and has not expired.
If you use a managed certificate from Let’s Encrypt, Cloudflare, AWS Certificate Manager, or a hosting provider, check whether renewal failed.
Confirm the domain name matches
The certificate must match the exact site hostname, such as example.com and www.example.com.
A mismatch between the certificate’s Common Name or SAN entries and the URL causes browser trust errors.
Check the certificate chain
Some servers install the leaf certificate but forget the intermediate chain.
That can break trust even when the certificate itself is valid.
Tools like SSL Labs Server Test or OpenSSL can reveal chain issues.
Make Sure Port 443 Is Open and Listening
HTTPS depends on TCP port 443.
If the firewall, security group, or hosting environment blocks that port, browsers cannot complete the secure connection.
Review these layers:
- Server firewall rules such as ufw, iptables, or Windows Firewall
- Cloud firewall or security group settings in AWS, Google Cloud, or Azure
- Web server binding for Nginx, Apache, or LiteSpeed
- Load balancer listener configuration for HTTPS traffic
If HTTP works but HTTPS times out, port 443 or the SSL virtual host is a likely culprit.
Inspect Redirects and Canonical URLs
A site can appear to “not work” on HTTPS when it keeps bouncing back to HTTP or loops between the two.
Redirect misconfiguration is common after a migration or certificate install.
Look for redirect loops
Ensure only one component is responsible for forcing HTTPS.
For example, if both Cloudflare and the origin server force redirects incorrectly, the request can loop.
Update hard-coded URLs
Check site settings, application config files, and database-stored URLs for old http:// addresses.
Content management systems like WordPress, Drupal, and Magento often need a full URL update after SSL is enabled.
Also verify:
- Canonical tags point to HTTPS URLs
- Sitemap URLs use HTTPS
- HSTS settings are intentional and correct
Fix Mixed Content Errors
Mixed content happens when an HTTPS page loads scripts, images, stylesheets, fonts, or iframes over HTTP.
Browsers may block those resources or downgrade the page security status.
Typical mixed content sources include:
- Image URLs in page content or theme files
- JavaScript libraries loaded from insecure CDNs
- CSS files or web fonts served over HTTP
- Embedded widgets, tracking pixels, or video players
To fix this, replace all insecure asset URLs with HTTPS, preferably using relative or protocol-independent references only when appropriate.
Browser developer tools can help identify the exact blocked resources.
Check Server and Application Configuration
Sometimes HTTPS is correctly installed but the web server is not configured to serve the site properly.
This is especially common after moving to a new host or enabling SSL for the first time.
Nginx configuration issues
In Nginx, confirm that the server block listens on 443 and points to the correct certificate and key files.
Also make sure the server_name matches the domain being requested.
Apache configuration issues
In Apache, verify that the SSL virtual host is enabled, mod_ssl is active, and the certificate directives reference the correct files.
A missing VirtualHost entry can cause Apache to serve the wrong site or a default certificate.
Application platform settings
For platforms like WordPress, check the site URL and home URL values.
For apps behind a reverse proxy, ensure the application correctly detects the original request as HTTPS using headers like X-Forwarded-Proto when appropriate.
How to Fix HTTPS Not Working Behind a Proxy or CDN?
Reverse proxies and CDNs add another layer where SSL can fail.
If you use Cloudflare, Akamai, Fastly, or a load balancer, the browser may trust the edge certificate while the origin server still has a problem.
Check these settings:
- The CDN SSL mode matches the origin setup, such as Full or Full (Strict)
- The origin certificate is valid if the CDN verifies it
- The load balancer forwards HTTPS headers correctly
- The origin server responds properly on port 443
If the proxy terminates TLS, the origin still needs to be reachable in the expected mode.
A mismatch between proxy and origin is one of the fastest ways to break HTTPS.
Test DNS and Hostname Resolution
DNS errors can make HTTPS look broken even when the certificate is fine.
If the domain points to the wrong IP address, the browser may reach an old server, a staging host, or a default certificate.
Validate that:
- The A and AAAA records point to the correct server
- www and non-www versions resolve as intended
- Recent DNS changes have fully propagated
- No stale records are sending traffic to an old host
When IPv6 is enabled, make sure the AAAA record is correct.
A broken IPv6 endpoint can cause HTTPS to fail even if IPv4 works.
Use Browser and Command-Line Diagnostics
To isolate the failure, test the site from the browser and from the command line.
This helps determine whether the issue is certificate trust, routing, or server response.
Useful checks include:
- Browser dev tools for mixed content and security warnings
- curl -I https://yourdomain.com to inspect status codes and redirects
- openssl s_client -connect yourdomain.com:443 to review certificate details
- SSL Labs to scan for protocol, chain, and hostname issues
If the browser fails but command-line tools succeed, the problem may be local trust stores, antivirus interception, or a cached redirect.
Clear Cache and Recheck HSTS
After fixing the server, old browser data can keep the site looking broken.
Browsers may cache redirects, certificates, or HSTS policies that force HTTPS behavior.
Try:
- Clearing browser cache and cookies
- Testing in an incognito or private window
- Using another device or network
- Checking whether a previous HSTS header is forcing strict HTTPS behavior
If you enabled HSTS prematurely and HTTPS is still unstable, users may be unable to fall back to HTTP at all until the issue is fully resolved.
Most Reliable Fix Order
If you need a quick sequence, work through the problem in this order:
- Confirm the certificate is valid, trusted, and issued for the correct domain
- Verify port 443 is open and the SSL virtual host is listening
- Check redirect rules for loops or incorrect HTTP-to-HTTPS forwarding
- Remove mixed content from pages, themes, and scripts
- Validate proxy, CDN, and load balancer SSL settings
- Test DNS records and confirm the domain points to the right server
- Retest after clearing cache and checking HSTS behavior
Following this order usually identifies the root cause faster than changing settings randomly.
The key is to separate certificate problems, transport issues, and application-level misconfigurations before making edits.