Cloudflare Error, seemingly not making a request to our server

I get the same experience on both sites, although the cart & heart icons in upper right on test. do not appear.

TLS/SSL is set to full (strict), that is the best setting, but you need to ensure you have a certificate on the origin server and you may want to enable Always use https from the SSL/TLS menu.

The error you describe does not sound like a cf error and I cannot reproduce any issue, can you attach a screen shot of what you’re seeing?

Yes. I can. I have to stop bypassing Cloudflare in order to generate it, and it completely breaks the website, so I cannot leave it for long.

Again, the request never reaches our server because I have echo exits (by using some obscure request variables) in place shortly after it reaches our server and it works fine on test.

Several other observations:

  • Development Mode does not help
  • Under Attack Mode does not work
  •” breaks while Cloudflare is active for the primary domain “” because the artifacts (js, css, images, etc) paths are hard-coded to the primary domain name, and therefore result in 503 errors (on each and every request)
  • I absolutely have a certificate on the origin server, as it works just fine when I bypass Cloudflare.
  • Screenshot is attached, again the exact same issue as was reported on the previous thread that my response was deemed “off-topic”

Response headers are as follows:

  1. alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
  2. cf-cache-status: DYNAMIC
  3. cf-ray: 6fe6fda70b9a191e-EWR
  4. content-type: text/html
  5. date: Tue, 19 Apr 2022 16:24:30 GMT
  6. expect-ct: max-age=604800, report-uri=“
  7. server: Cloudflare
  8. x-dc: gcp-us-east1
  9. x-request-id: a7f6b62f-e663-46e4-93b8-e69440d63039

Request to /cdn-cgi/trace results in the following:
uag=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36

Again, they exact same host/site works perfectly with alternate domains (, or by bypassing Cloudflare completely.

How else am I supposed to show that this is DEFINITELY a Cloudflare issue.

1 Like

Again, all requests to the primary domain “” result in a 503 error, though similar URLs on alternate domains using the same host work fine.

  1. Request URL:
  2. Request Method: GET
  3. Status Code: 503
  4. Remote Address:
  5. Referrer Policy: strict-origin-when-cross-origin

Same result on something as simple as the logo.

  1. Request URL:
  2. Request Method: GET
  3. Status Code: 503
  4. Remote Address:
  5. Referrer Policy: strict-origin-when-cross-origin

Did you ever have this domain active with a Cloudflare SaaS solution? Or did you recently purchase this domain?

You have the www hostname setup as a CNAME setup. When requested via the :orange: version the Origin appears to be GCP, but your Origin appears to be Linode.

If my guess is correct, the quick solution would be to have the previous owner remove the domain from their Cloudflare account.


Did you ever have this domain active with a Cloudflare SaaS solution?

  1. No.

Or did you recently purchase this domain?

  1. It is a recent domain purchase by my customer, so it could have been used by a previous domain owner.

You have the www hostname setup as a CNAME setup. When requested via the :orange: version the Origin appears to be GCP, but your Origin appears to be Linode.

  1. My Cloudflare zone, however, is working fine, as I am able to connect through an alternate sub-domain ( without a problem, Enabling & pausing the Cloudflare service works perfectly through the Cloudflare interface, and using the Cloudflare API I can create/delete the Cloudflare zone & set/change the origin server location, also we don’t get any kind of an error when setting up the Cloudflare zone that would indicate that it existed within anybody else’s account.

Where do you get the info that it goes to GCP with the :orange: version? If this is happening, it is wrong and due to a faulty connection/cache from within the Cloudflare infrastruture.

We would have no knowledge of any previous owners or what Cloudflare account this service would exist in.

Also, this is the exact same issue reported in this thread: Cloudflare breaks one of my websites

But it was deemed “off-topic”.

I was thinking maybe this had something to do with the Wordpress Cloudflare plugin, however, since I can’t even load the direct link to the website’s logo, that would seem to dispel this theory.

% curl  -o /dev/null --dump-header - --connect-to :: --silent
HTTP/2 503
x-dc: gcp-europe-west1

A quick search gives me the impression that this is a Shopify header. Could you check if your client used the www name with Shopify? If yes, they should ask Shopify to disconnect the hostname. If no, drop a note here and I can escalate to get the old SaaS integration removed.


@michael Dude! They did in fact have a Shopify site prior to the launch of this one. Looks like the domain was still connected to their account. I’ve removed their domain and am reaching out to Shopify to see if they need to do anything else to release the domain (since it is still seemingly being hijacked to go to GCP). Thank you for your guidance!

1 Like

Shopify is not helpful at all, and requests are still directing to GCP more than an hour after I removed their domain from Shopify. What do I need to do to get this corrected?

If you can convince Shopify of the issue then this should not be a difficult fix for them, have you asked them to remove any Cloudflare configurations for your domain, specifically SSL for SaaS / Custom Hostnames? Their support may have to escalate it to someone who can actually resolve this if removing it from Shopify’s panel is not fixing this as it should.

the convincing, and the repeating is another story altogether/ i’ve been on with 3 different support reps over the last 2 hours. each & every one requires a full on re-explanation, and then in the end doesn’t help me anyways. this is soooo aggravating.

why does Cloudflare allow them to hijack a domain that isn’t pointing to them anymore???

they keep telling me i need to do something with the domain’s DNS which is just plain wrong. UGH!

Cloudflare for SaaS overrides most other Cloudflare configurations due to certificate & hostname priority. This should not be an issue as the SaaS provider should remove the custom hostname when you stop using their service.

If they do not do this automatically, the provider has to manually remove that configuration and if they refuse to then Cloudflare has to go and manually remove it themself. That is the last resort if you don’t get anywhere and will likely take a few days to go through verification and get it sorted.

Shopify Support should be able to escalate this to their technical team, but i guess they’re not doing that then.

After spending over an hour on a chat with one rep, and waiting a significant amount of time between responses, I was disconnected because I was on another browser tab, you know, getting some work done. This is so ridiculous. Isn’t there some domain validation I can do to remove our domain from their configurations?

Shopify make what should be a simple process infuriatingly difficult.

Please email [email protected] from the email on your Cloudflare account stating that you used to use Shopify and are no longer using them and that Shopify say they are unable to remove the custom hostname from their account, which is preventing you from using Cloudflare directly. You’ll receive an autoresponse with a ticket number - please post that here so I can escalate it. Note that this might take a few days due to the manual steps involved.

1 Like

Thank you! Ticket #2428521:

This is one of my regular gripes. There is no way for you to see what is happening here, and it is far too difficult for you to correct. There is a thread on this Community that says an identifier on the dashboard is on the roadmap, as well as a way for users to disconnect the SaaS configuration. But I have no idea about the timeline.


This! Customers should be in control of their own domain names. Make them verify or whatever, but then give them control. Shopify (or other cloud partners) have no incentive to release domain names, they are theoretically losing the business, why make it easier for the customers new provider (and at the same time make it seem like this is the new providers fault for some reason)? Our industry is already riddled enough with this mindset (excessively long TTLs on DNS, forced to jump through hoops to transfer a domain name, etc), Cloudflare should be completely neutral between providers and focused on the value to the end-client.

P.S. Shopify relayed that they typically won’t release a domain name for 7-10 days after it is removed from their console. It has now been 8 days since we switched hosting on this domain, but only removed it from the Shopify console yesterday. This is ridiculous and goes to my point above - they are able to lock out the ability to use a great resource like Cloudflare, and in the meantime the customer is just going to be frustrated & think that Cloudflare is the problem. Really can’t blame this mentality if you cannot quickly tell the customer why their setup won’t work, and not give any means to correct it.