DNS still points to an old origin while the certificate belongs to the new origin when recursive resolvers, local networks, or regional caches have not converged. Check authoritative DNS first, then global and China public resolvers, then the actual remote IP and TLS certificate SAN on the origin that receives the Host. If the Host is supposed to be global-only or otherwise single-origin, remove stale vhosts, certificates, and proxy rules from non-target origins instead of expanding service there; add a short-term compatibility rule only when the business explicitly needs temporary dual-origin handling.
DNS / SSL / dual-origin diagnostic topic
DNS old-origin and certificate mismatch troubleshooting tools
A workflow for subdomain moves where some resolvers still land on an old origin and trigger HTTPS certificate hostname mismatch errors.
old origin certificate mismatchDNS points to old server SSL errorcertificate hostname mismatch fixdual-origin HTTPS certificate auditChina global DNS cache driftcacti.chakan.com certificate mismatch troubleshootingBaiduspider HTTPS certificate errorAI crawler TLS certificate issue
Separate authoritative correctness from resolver cache drift
After a DNS change, the authoritative server can be correct while public resolvers still return an older IP. Use authority checks, resolver propagation, actual remote IP, and TTL together before blaming the certificate.
- Must Do: query authoritative NS for the intended A record.
- Must Do: compare public resolver answers in global and China views.
- Should Do: record old-origin hits and classify them as resolver cache, wrong DNS, or stale non-target vhost residue.
Non-target origins must not accidentally serve the Host
If a Host belongs only on the global origin, the China origin or any other non-target origin should not retain that server_name, certificate directory, or proxy rule. Check the serving boundary before adding a fallback.
Common lookup scenarios
A subdomain should be global-only but some visitors still reach an old IP
Browsers report certificate common-name or hostname mismatch
Search or AI crawlers hit HTTPS certificate errors during a DNS migration
A dual-origin deployment needs separate checks for certificate, Host header, regional behavior, and service boundary
Recommended workflow
- Check authoritative NS records for the intended A record
- Compare global and China resolver answers and note stale resolver IPs
- Inspect certificate CN/SAN coverage for the current Host on every reachable origin
- Remove stale vhosts, certificate directories, or proxy rules from non-target origins; add a short-term compatibility rule only when explicitly required
- Record only verified repair evidence and avoid ranking, indexing, or AI-citation claims
Related tool entries
A workflow for subdomain moves where some resolvers still land on an old origin and trigger HTTPS certificate hostname mismatch errors.
DNS propagation checker
Compare DNS records across multiple public resolvers and check whether a target value has propagated.
LookupToolChakanAuthoritative NS difference checker
Query authoritative name servers directly, compare multi-NS record consistency, inspect SOA serial drift, and see how public resolvers align with the authoritative result.
LookupToolChakanSSL certificate checker
Use this ssl certificate checker tool to inspect, convert, or generate a clear result directly in your browser.
LookupToolChakanHTTP status checker
Check one public URL for final HTTP status, redirect chain, key response headers, Baidu verification file readiness, release troubleshooting, and sitemap.xml.gz canonical redirect diagnostics.
LookupToolChakanHTTP headers checker
Use this http headers checker tool to inspect, convert, or generate a clear result directly in your browser.
LookupToolChakanRedirect chain checker
Trace HTTP redirects, final URL, status codes, hop count, protocol or host changes, and SEO risks.
LookupToolChakanFAQ
DNS still points to an old origin while the certificate belongs to the new origin when recursive resolvers, local networks, or regional caches have not converged. Check authoritative DNS first, then global and China public resolvers, then the actual remote IP and TLS certificate SAN on the origin that receives the Host. If the Host is supposed to be global-only or otherwise single-origin, remove stale vhosts, certificates, and proxy rules from non-target origins instead of expanding service there; add a short-term compatibility rule only when the business explicitly needs temporary dual-origin handling.
Why can DNS be correct but users still hit the old origin?
Authoritative records can update before recursive resolvers, ISP caches, or local caches expire. Check public resolver answers and actual remote IPs before assuming the migration is complete.
Is waiting for TTL enough?
Sometimes yes, but waiting does not fix wrong DNS or a stale vhost. First decide whether the Host is single-origin. If it is, remove non-target-origin residue and verify resolver convergence.
Continue with these topics
Searchable topic pages that group related tools, answer specific lookup intents, and make Chakan easier for search engines and AI systems to understand.
TDEE, BMR, sleep-cycle, and daily water-intake planning
A local-first planning topic that connects TDEE, BMR, BMI, healthy-weight range, sleep-cycle timing, and daily water-intake estimates without medical claims.
Open topicStock profit, dividend yield, savings-goal, compound interest, and inflation planning
A safe formula-based topic for stock profit, dividend yield, savings-goal backsolving, monthly compounding, retirement gaps, inflation-adjusted purchasing power, ROI, CAGR, and target-price planning.
Open topicChina AI search answer-source and citation readiness checklist
A public-page readiness checklist for China AI search and answer systems: source visibility, title alignment, structured data, FAQ, internal links, keyword coverage, robots, sitemap, llms.txt, and log evidence without citation guarantees.
Open topic