WordPress loopback tests can fail with a certificate name error even when DNS resolves and the web server responds. TLS SNI chooses a virtual host before the HTTP Host header is processed, so a proxy, IPv6 route, or default certificate can send the self-request to the wrong site.
Use this when Site Health reports loopback or REST failures with certificate, hostname, SSL, cURL 60, wrong-site, or redirect symptoms, especially behind a CDN or reverse proxy.
Quick answer
WordPress Loopback TLS SNI Mismatch Debug Guide should be handled with a narrow evidence-first workflow: map dns paths, inspect sni certificate, force each origin ip, then verify the result before making broader changes.
What to check first
- Resolve the public hostname over IPv4 and IPv6 from the WordPress host and record every returned address.
- Use openssl with the expected server name to inspect the certificate subject, SANs, issuer, chain, and selected virtual host.
- Compare a normal HTTPS request with requests forced to each origin IP while preserving SNI and Host.
- Review proxy, load balancer, CDN, and web-server virtual-host order for the hostname.
- Retest WordPress cron, REST, and Site Health after the narrow routing or certificate fix.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Map DNS paths | Resolve the public hostname over IPv4 and IPv6 from the WordPress host and record every returned address. | Every active IPv4 and IPv6 route serves a certificate valid for the public hostname. |
| Inspect SNI certificate | Use openssl with the expected server name to inspect the certificate subject, SANs, issuer, chain, and selected virtual host. | Forced-origin requests reach the same canonical WordPress site. |
| Force each origin IP | Compare a normal HTTPS request with requests forced to each origin IP while preserving SNI and Host. | Site Health loopback, REST, and cron tests complete without TLS errors. |
| Fix virtual-host routing | Review proxy, load balancer, CDN, and web-server virtual-host order for the hostname. | The change does not bypass CDN, WAF, or authentication controls for public traffic. |
Why this usually happens
- The default TLS virtual host can serve a certificate for another domain.
- IPv6 DNS can point to an origin that lacks the matching certificate or site mapping.
- A proxy can preserve Host but use a different SNI name for its upstream connection.
- A temporary certificate renewal or origin migration can update one edge path but not another.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
dig +short A example.com
dig +short AAAA example.com
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
curl -sS -I --resolve example.com:443:203.0.113.10 https://example.com/wp-cron.php
wp cron test
wp site-health status
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Map DNS paths
- Inspect SNI certificate
- Force each origin IP
- Fix virtual-host routing
- Retest WordPress self-requests
What to tell the client or owner
Provide DNS answers, SNI name, certificate SANs, origin IPs, virtual-host mapping, cURL result, and the final Site Health and cron evidence.
Production verification checklist
- Every active IPv4 and IPv6 route serves a certificate valid for the public hostname.
- Forced-origin requests reach the same canonical WordPress site.
- Site Health loopback, REST, and cron tests complete without TLS errors.
- The change does not bypass CDN, WAF, or authentication controls for public traffic.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, diagnose WordPress loopback and hosting failures.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references
Compare the complete intermediate certificate chain
If SNI reaches the correct host but server-side curl still rejects HTTPS, use the WordPress loopback intermediate certificate guide to compare fullchain delivery, IPv4, IPv6, load-balancer nodes, and PHP and curl CA stores.