Error 1016 for one subdomain, but not any other domains

I have one domain that is constantly returning 1016 since some time ago (I don’t monitor it so I don’t know when exactly this started). I have completely no idea why this could go wrong.

In the dashboard this domain is configured with an orange cloud :orange: CNAME record pointing to, which is my GitHub Pages site. It can be confirmed that GitHub Pages is running normally using cURL client, by forcing domain resolution to GitHub Pages.

$ curl -ks --resolve
<meta charset="utf-8">
<title>Page OK</title>
<body bgcolor="white">
<center><h1>200 OK</h1></center>
  If you're seeing this page, it means <a href="">this issue</a>has been resolved.

Another subdomain that’s also pointing to GH Pages works fine, and it too is an orange cloud :orange: record with CNAME target (it’s This means Cloudflare should not actually have any problem resolving the origin domain.

I have tried the following fixes, but none of them made any difference - not even changing 1016 to another error code:

  • Visiting from another location using VPSs (checking /cdn-cgi/trace for the colo= line, I reached HKG, SIN, NRT, SJC - all of them returned the same 1016 response)
  • Turned off orange cloud :grey: and turned it backed on :orange:
  • Deleted and re-created the CNAME record with the same parameters (hostname image, target, orange cloud :orange:), so as to eliminate the (unlikely) possibility of a typo
  • Changed the record to point to something else
  • Deleted the record and added A records pointing to GitHub Pages IP addresses
  • Changed the A records to point to something else
  • Deleted the record again, waited for 5 minutes (default TTL for “Auto”), then added the record back
  • Purged Cache
  • Using Cloudflare’s Diagnostic Center, no problem was found except for HTTP status code (was 530)
  • Deleted and re-added whole zone on Cloudflare dashboard

When deleting the record from the dashboard, I can see DNS resolution disappears immediately from the assigned authoritative nameservers (using dig It also comes back as soon as I add them back in the dashboard.

I have no other things configured for this specific subdomain. To be as detailed as possible, here’s what I’ve checked:

  • I am on Free Plan
  • I have no Workers route configured on this domain
  • I have no Page Rules configured for this domain (if I add one it doesn’t work - still error 1016)
  • I have no Transform Rules configured (at all)
  • I have no Load Balancing enabled
  • I have no Firewall Rules configured, and all settings in Firewall section are left with their default values
  • I have no Access policies configured for this domain
  • I have no Apps installed

I’m more inclined to believe that Cloudflare may have “disabled” this specific subdomain for whatever reason. Is there anything I might have missed, or will Cloudflare look into this?

Extra information of why I think Cloudflare may have “disabled” this particular subdomain

When forcing DNS resolution to Cloudflare’s home page server ( / using the following cURL command, setting the Host header to generates an HTTP status code of 530 (and the Error 1016 page), while all other Host values returns 403.

curl -vso /dev/null --resolve -H 'Host:'

I tested over 200 different values for the Host header, and all of them returns HTTP 403, including:
... and many more

This peculiarity looks very suspicious to me. This is clearly an indication that something special has been applied to this very subdomain.

1 Like

Great post @ibugone, thank you.

No, I can see it is active on Cloudflare.

Can you give an example?

Update: This “diagnostics” about delay during TLS handshake appears to be wrong.

@cloonan I already gave one in the original post, you can click the link to see it loads correctly.

Another subdomain that’s also pointing to GH Pages works fine, and it too is an orange cloud record with CNAME target (it’s This means Cloudflare should not actually have any problem resolving the origin domain.

You can use the following cURL commands and watch for the delay between each output lines:

$ curl -vso /dev/null
$ curl -vso /dev/null --resolve
1 Like

@cloonan Any updates for this? I’m pretty sure I’ve exhausted available troubleshooting methods on my side.

@cloonan Two more points of clarification:

  • By “disable” I refer to the specific subdomain in question ( I suspect Cloudflare may have applied special settings that “disables this domain from working on Cloudflare CDN”.
  • Page Rules doesn’t work. I added one “Forwarding URL” rule and make it 302 to somewhere, and it’s still error 1016.
    • This is not the case even for a non-existent domain. If I add a Page Rule for and use curl -v --resolve, I can see the 302 response even though no DNS is configured in the dashboard.

@MoreHelp Please take a look at this issue. It’s been 5 days since the last perceivable Community Team input, and I posted all troubleshooting steps I’ve taken (unlike vague descriptions from “typically new” users), to the extent that it matches Stack Overflow quality requirement for an “answerable question”.

At this point, I firmly believe this issue requires Cloudflare staff intervention, and not just a simple “configuration error” or “misunderstanding”.

1 Like

If you look at the payload of that cURL you will see:

There isn't a GitHub Pages site here.

You need to resolve that or nothing will work.

1 Like

@michael I understand what you’re referring to. Let me clarify my problem once more:

  • It is expected that GitHub Pages returns 404 for the root path of the domain. (I did not configure a page for the root path, but there should not be anything wrong on Cloudflare’s side.)
  • It is unexpected, however, that Cloudflare returns Error 1016 instead of showing GitHub’s 404 page.

I need this issue to be resolved, that any HTTP visit to the domain receives GitHub Pages’ response, but not hit an error on Cloudflare.

(Have you read the top post thoroughly? I never said “I want the page working”, but only “get rid of Cloudflare 1016 error”.)

Update: I have now put a dummy page for The top post has been updated with the content of the new placeholder HTML. Please now consider a 200 response with that content as “expected and working”.

@cloonan Hello, in case you didn’t understand my note about “Cloudflare may have disabled this domain”, please check the top post (updated again to add my latest analysis).

@cloonan @michael Let’s continue this issue in ticket #2261969

Final Update

Problem resolved through support ticket 2261969.

Based on support replies, there’s a Cloudflare Pages site associated with this particular subdomain that has since been deleted. As I can vaguely recall, this subdomain remained attached to the CFP site when the site was purged, which may be the cause of this strange issue.

Turns out my guess was right: something hidden behind the Cloudflare dashboard was going wrong and that a support ticket was necessary to get things done right.


This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.