How to Fix ERR_SSL_PROTOCOL_ERROR After DNS or Hosting Changes

Overview

Use this article as a decision tree, not a theory lesson. The goal is to identify which layer is failing first.

ERR_SSL_PROTOCOL_ERROR commonly appears when one of these is true:

• Your domain now resolves to a different server, but that server does not have a valid certificate for the hostname.
• A CDN or proxy is enabled, but its SSL mode does not match what the origin server supports.
• The certificate exists, but only for example.com or only for www.example.com, not both.
• The web server is listening on port 80 but not correctly on 443.
• The reverse proxy is serving the wrong virtual host or wrong certificate after a deployment.
• DNS propagation is mixed, so some users reach the old server and some reach the new one.
• A redirect or forced HTTPS rule sends traffic into a loop or to a host that cannot complete TLS.

Before changing settings at random, work through a short baseline check:

1. Confirm which hostname fails: apex domain, www, subdomain, or all of them.
2. Check where DNS points right now.
3. Confirm whether a proxy or CDN is in front of the origin.
4. Test whether the origin itself has a valid certificate.
5. Verify that the server block, virtual host, or ingress rule for that hostname is actually loaded.

If your issue began immediately after a DNS update, pair this guide with a propagation workflow so you can tell the difference between a misconfiguration and a slow rollout. See DNS Propagation Checker Guide: How to Verify Record Changes and Troubleshoot Delays.

Checklist by scenario

Start with the scenario that best matches the change you just made.

1. You changed A, AAAA, or CNAME records and HTTPS stopped working

This is the most common case. DNS now points to a new destination, but the TLS setup on that destination is incomplete.

• Verify the current DNS answer for the exact hostname. Check both the apex and www if you use both.
• Make sure the new server, platform, or load balancer is expecting that hostname.
• Confirm a certificate is installed for the exact hostnames being requested.
• Check whether the platform needs domain verification before issuing its managed certificate.
• Wait for certificate provisioning if you just connected the domain to a managed host, but only after confirming the DNS target is correct.

Typical symptom: HTTP may work, while HTTPS fails. That usually means routing is fine but TLS termination is not.

If you recently repointed a domain and want a refresher on record types and host mapping, see How to Point a Domain to a Server: A Record, CNAME, Nameservers, and TTL Explained.

2. You enabled Cloudflare and now get SSL errors

Cloudflare changes the path between the browser and your origin. The browser talks to Cloudflare, and Cloudflare talks to your server. Both legs matter.

Check these items in order:

• Confirm the DNS record is proxied only if you intend Cloudflare to terminate SSL.
• Review Cloudflare SSL mode. If the origin has a valid certificate, Full or Full (strict) is usually the safer long-term direction than modes that tolerate missing or invalid origin certs.
• If using Full (strict), make sure the origin certificate is valid for the hostname and not expired.
• Make sure your origin server is listening on 443 and can complete a TLS handshake directly.
• Check whether origin redirects are forcing HTTP/HTTPS in a way that conflicts with Cloudflare settings.

A common mistake is enabling proxying while the origin only supports plain HTTP, or while the origin presents a self-signed or mismatched certificate that the current mode rejects.

For DNS-side setup patterns, see Cloudflare DNS Setup Guide for Domains, Subdomains, and Common Record Types.

3. You moved to Vercel, Netlify, or another managed host

Managed platforms usually automate certificates, but only after domain ownership and routing are correct.

• Check that the platform shows the domain as verified and assigned to the correct project.
• Confirm you added every hostname you intend to serve, such as both apex and www.
• Verify that the required DNS records match the platform’s instructions exactly.
• Remove conflicting old records that still point part of the hostname set elsewhere.
• Allow time for certificate issuance after DNS is correct, but do not assume time alone will fix a wrong record.

If only one hostname fails, the issue is often that one variation was never added to the project or never got its own certificate.

Related guides: How to Connect a Domain to Vercel Without DNS Errors and How to Connect a Domain to Netlify: DNS Records, SSL, and Common Fixes.

4. You changed Nginx, Apache, Docker, or a reverse proxy

In self-managed environments, the error often comes from the wrong server block being selected or port 443 not being configured as expected.

• Confirm the service is listening on 443.
• Verify the correct certificate and private key paths are loaded.
• Check that the server name matches the hostname the browser requests.
• Reload configuration and inspect for syntax or startup errors.
• If using Docker, verify the right container has mounted the current cert files and exposed the correct port.
• If using a reverse proxy in front of an app container, ensure TLS ends at the proxy unless you explicitly designed end-to-end TLS.

If the default server answers instead of the intended virtual host, browsers may see a certificate for a different domain and report a protocol or certificate-related failure.

For a deeper deployment pattern, see Nginx Reverse Proxy Setup Guide for Node.js, Docker, and SSL and Docker Deployment Tutorial for Small Production Apps.

5. The certificate was renewed or replaced during deployment

Automated renewals are reliable when the assumptions stay stable. After DNS or hosting changes, those assumptions may no longer hold.

• Check whether the ACME challenge method still works for the hostname after the move.
• Confirm the certificate covers all required names, including subdomains if applicable.
• Verify the full certificate chain is being served by the web server.
• Make sure the deployment did not revert to an older config pointing at expired cert files.
• Inspect post-deploy hooks or CI steps that copy or reload certificates.

If the issue started right after an automated deployment, review the release pipeline rather than only the DNS layer. See GitHub Actions Deployment Guide: Build, Test, and Deploy Web Apps Reliably.

6. Only some users or regions see the error

That usually points to DNS propagation, split traffic, or a partially updated edge configuration.

• Check whether recursive resolvers still return the old IP for some networks.
• Verify that both old and new endpoints can serve valid HTTPS during the transition.
• Reduce confusion by keeping the old environment alive until DNS caches expire, if possible.
• Confirm there is no IPv6 record still pointing to an old server while IPv4 was updated.

Mixed A and AAAA behavior is easy to miss. A user reaching an outdated IPv6 destination can see SSL failure while others appear fine.

What to double-check

If you want a reusable pre-change and post-change checklist, this is the section to bookmark.

Hostname coverage

• Does the certificate cover example.com?
• Does it also cover www.example.com?
• Are any app subdomains, API subdomains, or admin hosts left out?

Many HTTPS failures after setup come from assuming a single certificate automatically covers every hostname variation.

DNS consistency

• Are A, AAAA, and CNAME records aligned with the intended destination?
• Did you leave old records in place that create conflicting answers?
• Did you change nameservers and records at the old provider by mistake?

If the wrong nameservers are authoritative, your “correct” record edits may have no effect. If your issue is broader than SSL and the domain itself is not resolving as expected, review How to Fix DNS_PROBE_FINISHED_NXDOMAIN for Websites, APIs, and Local Development.

Proxy and origin alignment

• Is a CDN or proxy enabled?
• If yes, is the origin configured for the SSL mode you selected?
• Can you reach the origin directly and complete TLS successfully?

Never assume the browser is talking directly to your server once a proxy is introduced.

Port 443 readiness

• Is the firewall allowing 443?
• Is the load balancer forwarding 443 correctly?
• Is the server process actually bound to 443?

A clean HTTP response on port 80 does not tell you anything about port 443 readiness.

Redirect logic

• Are you forcing HTTPS at the app layer, proxy layer, CDN layer, or all three?
• Do redirects preserve the correct hostname?
• Do apex and www redirects lead to a host with a valid certificate?

A redirect from a working host to an unprovisioned host is a quiet but common cause of SSL failures.

Certificate files and reloads

• Did the server reload after certificate changes?
• Do the configured file paths point to the new certificate and key?
• Was the certificate chain installed correctly?

On self-managed stacks, the certificate may exist on disk while the running process still serves an older one.

Common mistakes

Most recurring SSL incidents fall into a short list of avoidable patterns.

Changing DNS before the target is ready

Teams often update records first and finish certificate setup later. If the new target cannot serve the hostname over HTTPS yet, users will immediately see failures. A safer pattern is to provision the host, verify certificate issuance, then cut DNS.

Forgetting one hostname variant

You test example.com, but users land on www.example.com. Or the reverse. Always verify every hostname you publish externally, not just the one you type most often.

Mixing old and new records

Leaving stale A, AAAA, CNAME, or proxy settings in place can create inconsistent routing. This is especially common during migrations from one platform to another.

Using the wrong Cloudflare SSL mode

If Cloudflare is configured in a mode that expects an origin certificate, but your origin does not have one, HTTPS will fail. If Cloudflare is configured in a weaker compatibility mode and the origin has incomplete redirect logic, behavior may still be unreliable. The important point is not the label alone but whether the proxy-to-origin connection matches reality.

Assuming propagation is the only issue

Propagation delays are real, but they can also mask a genuine misconfiguration. If the new destination already fails a direct HTTPS test, waiting longer will not solve the root cause.

Ignoring IPv6

It is common to update the A record and forget the AAAA record. Some clients then reach a different server than others. If HTTPS appears broken “only sometimes,” compare both record types.

Not validating after deployments

A deployment that rebuilds containers, rotates load balancer listeners, or rewrites web server configs can unintentionally drop TLS settings. DNS changes and deploy changes are often blamed separately even when they happened in the same release window.

When to revisit

This topic is worth revisiting anytime the path from browser to origin changes. Build a small operating habit around that idea.

Review this checklist:

• Before changing nameservers, A records, AAAA records, or CNAME records
• Before enabling or disabling Cloudflare or another proxy
• Before migrating to a new host, platform, or region
• After renewing, replacing, or automating certificates
• After changing Nginx, Apache, ingress, or load balancer config
• After major CI/CD workflow changes that touch infrastructure
• During planned seasonal traffic prep, when reliability matters more than speed of change

A practical pre-flight routine looks like this:

1. List every public hostname involved.
2. Verify which DNS records will change.
3. Confirm the new destination can answer on 443 for each hostname.
4. Check whether a CDN or proxy will sit in front and validate its SSL mode.
5. Test redirects between apex, www, and subdomains.
6. Make the DNS change.
7. Run a propagation check.
8. Re-test HTTPS on every hostname from the browser and from the command line.

If you maintain multiple domains or environments, turn this into a runbook instead of repeating ad hoc debugging. A short checklist before each change is usually faster than investigating ERR_SSL_PROTOCOL_ERROR after users report it.

The main takeaway is simple: when HTTPS breaks after DNS or hosting changes, do not treat it as one opaque SSL problem. Treat it as a path problem. Identify the hostname, the DNS answer, the proxy layer, the origin server, and the certificate actually being served. Once those five pieces line up, the error usually disappears quickly.