Cloudflare Error 1014: How a Cancelled Service Took a Ghost Website Offline

A website can appear healthy one day and become completely inaccessible the next—even when its hosting is running, its content is intact, and nobody has changed the website itself.

That is what happened to an independent digital publisher using Ghost(Pro), Cloudflare, and a third-party translation service. Visitors suddenly saw:

Error 1014: CNAME Cross-User Banned

The hosting platform was not down. The domain had not expired. The publication had not been hacked. Instead, a cancelled third-party service remained embedded in the website’s DNS route.

The subscription ended, but the dependency did not.

This case study explains what Cloudflare Error 1014 means, how a stale CNAME record can take a website offline, why the first apparent fix produced an SSL error, and how the Ghost website was restored within the same support session.

The situation: a working Ghost website suddenly went offline

The publisher’s main website was hosted on Ghost(Pro), with DNS managed through Cloudflare. It had also used Weglot to provide translated versions of the site.

The translation account was later cancelled because the free service was no longer being used. However, the domain’s root DNS record still sent visitors through Weglot’s translation infrastructure before reaching Ghost.

The route effectively looked like this:

Visitor → main domain → translation service → Ghost website

Once the translation service stopped recognizing the domain, that route broke. Every visitor using the main domain was sent toward a service that no longer accepted it.

Cloudflare returned Error 1014 before the request ever reached Ghost.

What does Cloudflare Error 1014 mean?

Cloudflare describes Error 1014 as “CNAME Cross-User Banned.” It occurs when a CNAME points between domains associated with different Cloudflare accounts without the destination being configured to accept that custom hostname through an approved arrangement such as Cloudflare for SaaS.

In plain English, one domain is pointing at infrastructure controlled through someone else’s Cloudflare account, but the receiving service is not currently authorized to serve that hostname.

That does not automatically mean the website owner has done anything malicious. It often indicates a broken or incomplete custom-domain relationship with a hosting, translation, commerce, or software-as-a-service provider.

In this incident, the timing supplied the missing context: the provider had cancelled the account, while the publisher’s DNS still relied on the provider’s Cloudflare-hosted endpoint.

The visible error belonged to Cloudflare, but the root cause was lifecycle management: a third-party service had been cancelled without removing or replacing the DNS dependency attached to it.

Cloudflare’s technical explanation is available in its official Error 1014 documentation.

The DNS record that created the dependency

The important record was the CNAME at the root, or apex, of the domain. It followed this pattern:

Type: CNAME
Name: @
Target: [translation-endpoint].translate-cf.weglot.io
Proxy status: DNS only

The @ symbol means the bare domain—for example, example.com rather than www.example.com. Cloudflare often replaces @ visually with the full domain name in its dashboard. That display behavior is normal; it does not mean the user entered the record incorrectly.

The record had been valid while the translation service was active and had registered the domain as an accepted hostname. Once that provider-side relationship ended, the same record became a dead route.

This is why simply asking, “Is the DNS record present?” is not enough. A record can exist, resolve, and still point to a service that no longer recognizes the domain.

Why changing the orange cloud would not solve the underlying problem

Cloudflare records can be set to Proxied or DNS only. It is tempting to treat that switch as a universal fix for Cloudflare errors.

It is not.

In this case, the CNAME depended on the translation provider accepting the publisher’s hostname. Changing the proxy status could alter how the request travelled, but it could not reactivate a cancelled account or restore the missing provider-side authorization.

The durable choices were:

1. Reactivate and correctly revalidate the translation service; or
2. Remove it from the website’s delivery path and connect the domain directly to Ghost.

Because translations could remain offline and the priority was restoring the main publication, the second option was the appropriate recovery path.

The first recovery attempt—and the SSL error it revealed

A common Ghost(Pro) DNS configuration uses an A record pointing to 178.128.137.126. Ghost documents this IP as part of its redirect setup.

However, the correct use of that A record depends on whether the primary website address is the root domain or the www subdomain.

The first attempt replaced the obsolete translation CNAME with an A record at the root. The Cloudflare 1014 page disappeared, but the browser then reported:

This site can’t provide a secure connection — ERR_SSL_PROTOCOL_ERROR

That change bypassed the cancelled translation service, but it did not connect the publication’s primary hostname to the correct Ghost endpoint. The redirect IP was being used where the primary-domain CNAME was required.

This distinction is easy to miss:

• If www.example.com is the primary Ghost domain, www points to the publication’s ghost.io hostname and the root A record performs the redirect.
• If example.com is the primary Ghost domain, the root points to the publication’s ghost.io hostname and the www A record performs the redirect.

The IP is not a universal replacement for every Ghost DNS record.

The final Ghost(Pro) DNS configuration

Because the bare domain was the publication’s primary address, the final website records followed Ghost’s root-domain configuration:

• Type: CNAME; Name: @; Target: [publication].ghost.io; Proxy status: DNS only; Purpose: Connects the primary root domain to Ghost
• Type: A; Name: www; Target: 178.128.137.126; Proxy status: DNS only; Purpose: Redirects the non-primary www address

The old translation-service CNAME was removed rather than supplemented. A CNAME and an A record should not coexist at the same hostname as competing routes.

Ghost’s official Cloudflare domain setup guide says Ghost records should remain DNS only and provides separate tables for root-domain and subdomain configurations.

Once the correct root CNAME was saved, the publication became accessible again over HTTPS. Ghost(Pro) provides SSL for correctly activated custom domains, so no separate certificate purchase was required. Ghost explains this in its custom-domain documentation.

What we verified before declaring the incident resolved

A website loading once is encouraging, but it is not a complete DNS validation. We checked the website from the public internet and confirmed the following:

• The root domain resolved to the intended Ghost publication.
• The old Weglot CNAME was no longer in the website’s active path.
• HTTPS loaded without a certificate or protocol error.
• The server returned a successful HTTP response.
• The non-primary hostname redirected to the canonical domain.
• Existing email-related MX, SPF, DKIM, and verification records were not altered during the emergency repair.
• The change worked outside the original device and network, reducing the chance that a local DNS cache was hiding a problem.

This last point matters. DNS caches can make different users see different results for a short period after a change. Testing through another network or an independent DNS resolver helps separate propagation delay from a genuinely incorrect record.

Why the outage was harder to diagnose than it appeared

Several details made this more than a simple “delete the CNAME” problem.

1. The error page named Cloudflare, not the cancelled service

Visitors saw a Cloudflare error, so Cloudflare looked like the cause. In reality, Cloudflare was enforcing a security rule at a broken cross-account CNAME connection. The failed relationship involved the third-party translation endpoint.

2. Ghost itself was still available

The publication’s content and hosting were working. Only the public domain route was broken. That is why checking the origin platform separately is an important diagnostic step.

3. Removing a record is not the same as replacing a route

Deleting the obsolete CNAME removed the broken dependency, but the main domain still needed a correct destination. DNS remediation requires both halves: remove the invalid route and establish the valid one.

4. Ghost supports two domain patterns

The root-primary and www-primary setups use the same record types in opposite positions. Applying the wrong pattern can replace one visible error with another.

5. DNS, hosting, redirects, and SSL overlap

These systems are related but distinct. A successful DNS lookup does not guarantee that the destination recognizes the hostname, serves the right site, or presents a valid SSL certificate.

The larger lesson: cancelled software can remain active in DNS

Businesses often review recurring payments more carefully than DNS records. That creates a blind spot.

Cancelling a platform does not normally remove the DNS entries created for it. The software account can disappear while the domain continues pointing to its old endpoint indefinitely.

This can affect more than translation tools. Similar dependencies are created for:

• Website hosting and content delivery networks
• Landing-page builders
• Email marketing platforms
• Customer portals
• Payment and checkout services
• Image optimization services
• Help desks and knowledge bases
• File storage and download systems
• Analytics and verification services

A stale record may cause an outage, weaken email authentication, expose an abandoned subdomain, or simply make the DNS zone too confusing to audit safely.

Every DNS record should therefore have an identifiable owner, purpose, and associated active service.

A safer process for cancelling a website service

Before cancelling any service connected to a domain, use this checklist.

Before cancellation

1. Export any content, translations, redirects, or configuration that must be retained.
2. Identify every DNS record the provider asked you to add.
3. Determine whether the provider is in the live website path or merely verifying ownership.
4. Prepare the replacement hosting or routing records.
5. Lower DNS TTL in advance when the provider and change window permit it.
6. Confirm who can edit DNS and who can roll back the change.

During the change

1. Capture the original records before editing.
2. Change only the records tied to the departing service.
3. Preserve email, verification, and unrelated subdomain records.
4. Apply the configuration documented by the destination platform.
5. Test both the root and www versions over HTTP and HTTPS.

After the change

1. Verify the canonical redirect.
2. Check SSL certificate validity.
3. Test from more than one network or resolver.
4. Monitor for errors after DNS caches refresh.
5. Update the DNS inventory so the removed dependency is documented.
6. Only then close the old account permanently.

How to audit a Cloudflare DNS zone for stale dependencies

A useful Cloudflare review should not be limited to whether each record has valid syntax. It should answer five practical questions for every record:

• Question: What service owns this record?; Why it matters: An unknown record cannot be safely maintained or removed.
• Question: Is that service still active?; Why it matters: Cancelled services can leave live dependencies behind.
• Question: Does the hostname still need this route?; Why it matters: Old migrations often leave duplicate or conflicting paths.
• Question: Should the record be Proxied or DNS only?; Why it matters: Web traffic and verification/email records have different requirements.
• Question: What would break if the record disappeared?; Why it matters: Impact must be understood before cleanup.

The final audit should also cover nameservers, DNSSEC, registrar security, account access, two-factor authentication, API tokens, redirects, SSL modes, email authentication records, and any third-party platform connected through CNAMEs.

Frequently asked questions about Cloudflare Error 1014

What is Cloudflare Error 1014: CNAME Cross-User Banned?

It means a CNAME is pointing toward a hostname associated with another Cloudflare account, but the cross-account custom-hostname relationship is not permitted or active. The destination provider may need to authorize the domain through Cloudflare for SaaS, or the DNS route may need to be replaced.

Can I fix Error 1014 by turning off the Cloudflare proxy?

Not reliably. Proxy status can matter in some configurations, but it cannot restore a cancelled service or make an unauthorized destination accept your hostname. Diagnose who owns the CNAME target before changing the orange-cloud setting.

Can I simply delete the CNAME record?

Only if the hostname no longer needs to resolve. For a main website domain, deleting the broken CNAME without adding the correct replacement usually creates a different outage. Document the existing record and prepare the destination record first.

Why does Cloudflare replace @ with the full domain name?

@ is shorthand for the zone’s root or apex domain. Cloudflare may display the complete domain after the record is saved. That is normal.

Why did the website show an SSL error after changing DNS?

The new destination may not have recognized the hostname, the wrong Ghost domain pattern may have been used, or the platform may still have been provisioning its certificate. Confirm the primary domain and apply the provider’s exact DNS configuration before assuming the problem is propagation.

How long do Cloudflare DNS changes take?

Cloudflare publishes DNS changes quickly, but recursive resolvers, devices, and internet providers may retain the previous answer until its TTL expires. Verify the authoritative result and test through a second resolver or network before repeatedly changing records.

Does Ghost(Pro) need Cloudflare proxying enabled?

Ghost’s Cloudflare setup guide instructs users to set the Ghost website records to DNS only. Do not enable proxying merely because Cloudflare offers it; follow the hosting platform’s supported configuration.

Conclusion: DNS records are live infrastructure, not historical notes

The website went offline because its domain continued relying on a service after the commercial relationship had ended. The recovery was not to rebuild the Ghost publication or purchase another SSL certificate. It was to understand the active request path, remove the obsolete dependency, and reconnect the primary domain using Ghost’s correct root-domain configuration.

The incident is a useful reminder for every organization using several cloud platforms: DNS records should be reviewed whenever a service is added, migrated, downgraded, or cancelled.

A clean DNS zone is not cosmetic housekeeping. It is part of website availability, email security, and operational resilience.

If your website is showing Cloudflare Error 1014, an SSL error after a DNS change, or unexplained routing behavior, More X Tech can review the complete path—from DNS and third-party dependencies to hosting, redirects, and certificate validation—and provide a documented remediation plan before changes are made.