Shopify behind Cloudflare: 403 Errors & Orange-to-Orange

You moved your Shopify store's DNS to Cloudflare and the site now shows 403s, a "DNS points to prohibited IP" error, or random outages. This keeps coming up on the Cloudflare Community forum: here is what actually happens under the hood.

The architectural point everyone discovers too late

Shopify already runs its storefront on a Cloudflare edge infrastructure: invisible to the merchant, but it changes everything. When you proxy (orange cloud) your domain record pointing to Shopify, the request travels through your zone's Cloudflare proxy to reach... Shopify's own Cloudflare edge. How Cloudflare handles this "orange-to-orange" scenario depends entirely on the record type, and this is where most incidents start:

Proxied A record to a Shopify IP (typically 23.227.38.65): the proxy refuses to relay that traffic (error 1000 "DNS points to prohibited IP"), and your Cloudflare rules end up mostly decorative on storefront traffic.
Proxied CNAME to shops.myshopify.com: Cloudflare detects the target as another Cloudflare customer and routes the request through your zone first, then Shopify's, in order. This is orange-to-orange (O2O) routing, part of Cloudflare for SaaS, generally available since October 2021. When detection engages, a small Shopify icon appears next to the record in the Cloudflare dashboard.

Technically, this second setup works on any paid Shopify plan, not just Plus. But Shopify's official documentation states that Cloudflare proxy setups, including O2O, are not supported and "could break at any time": Shopify will not guarantee, debug, or fix a proxy layer it does not control. Real outages are reported in merchant communities (DNS failures after months of stable operation, SSL certificates that silently stop renewing).

The classic symptoms of a misconfigured zone: error 1000 "DNS points to prohibited IP", intermittent 403s when the storefront responds but rejects relayed traffic, or random outages when the record points to Shopify IPs that change. These symptoms feed dozens of threads on the Cloudflare Community forum and Shopify forums, with an almost identical outcome every time.

The configuration that works on a standard plan

Storefront on grey cloud, no exceptions. The domain's A record (typically 23.227.38.65) and the www CNAME to shops.myshopify.com stay DNS only. Shopify terminates HTTPS on its own edge, with its own certificate and CDN. Unless you have a specific need at the edge (a WAF you can tune, rate limiting, request-level logs, visibility into AI crawlers), there is little to gain by putting a proxy in front: Shopify already covers CDN, SSL and DDoS protection.
Cloudflare as DNS and adjacent-services manager. What the zone actually brings: fast nameservers, email management (MX, SPF, DKIM, DMARC), domain redirects via Redirect Rules on non-Shopify hostnames, and proxying of other subdomains (self-hosted app, documentation, blog, API).
Apex to www redirect, the right way. Redirecting the root domain to www requires a Redirect Rule, which requires proxying the apex. On Shopify, the proper route is to configure the primary domain inside the Shopify dashboard, where the redirect is handled natively, instead of forcing a proxying that triggers error 1000. If the registrar already handles it, leave it in place.
Email never touches the storefront. MX, SPF and DKIM are independent from the storefront's DNS: running them through Cloudflare Email Routing or managing them on the zone carries no risk for the store, as long as mail records stay on grey cloud.
Orange-to-orange: technically possible, officially unsupported. A proxied CNAME to shops.myshopify.com engages O2O routing on any paid Shopify plan (a proxied A record does not benefit from it). If you still want this setup, it requires a precise configuration: SSL/TLS mode on Full, Always Use HTTPS off (it blocks the ACME path Shopify uses to renew its certificates and can cause redirect loops), and no caching of the storefront HTML. Because the setup is officially unsupported by Shopify, treat it as a deliberate, monitored choice: test on a secondary subdomain first, and keep the rollback (grey cloud) within reach.

Telling a 403 apart: who sends it?

Faced with a 403, the first reflex is to look at who signs the error page:

Stylized Cloudflare error page: the block comes from YOUR rules (custom rules, IP Access Rules). Check Security > Events at the exact timestamp: the rule is identified by its ID, and the fix is a rule adjustment, not a DNS change.
Shopify error page: the 403 comes from Shopify, rejecting traffic it receives via your zone's proxy instead of the expected direct traffic. The fix is to switch the storefront record back to grey cloud. No Cloudflare setting makes this proxying officially supported by Shopify; a correctly configured O2O setup can work, but you carry the risk alone.
Error 1000 (DNS points to prohibited IP): same diagnosis, different signature: the proxy refuses to relay to Shopify IPs. Switch back to grey cloud.

Mistakes that prolong the incident

Looking for a magic rule on the Cloudflare side: the forum is full of attempts (security exceptions, SSL/TLS mode changes, cache tweaks) to "fix" storefront proxying that Shopify does not support in the first place. As long as the record is orange with an incorrect setup, symptoms come back.
Proxying then caching the store's HTML: Shopify already caches its content at its own edge with controlled headers. Stacking a Cloudflare cache on the storefront adds inconsistency risk (prices, stock) with no measurable gain.
Forgetting that the DNS moved, not the store: after the zone transfer, every domain change must happen in both the Shopify dashboard AND the Cloudflare zone. A domain declared on one side only produces redirect loops or invalid certificates.
Switching to orange "to test" mid-day: every activation of the proxy on the storefront is a traffic-plan change visible to every visitor. Test on a dedicated subdomain, during off-peak hours, with the rollback ready.

Frequently asked questions

Why does "DNS points to prohibited IP" appear with Shopify?

Because a proxied record pointing to Shopify, typically an A record to a Shopify IP, cannot be relayed by the proxy: the target belongs to another Cloudflare zone, so the proxy refuses it. A proxied CNAME to shops.myshopify.com engages orange-to-orange routing and avoids this error, but that setup remains officially unsupported by Shopify. The reliable fix is switching the record back to grey cloud.

Can you put Cloudflare in front of a Shopify store?

Technically yes: a proxied CNAME to shops.myshopify.com engages orange-to-orange routing on any paid Shopify plan, not just Plus. But Shopify's official documentation declares this setup unsupported, including O2O, and states it could break at any time. Cloudflare reliably brings fast DNS, email, redirects on non-Shopify hostnames, and proxying of other subdomains; proxying the storefront itself is a deliberate risk, not a recommended default.

Where do 403 errors between Shopify and Cloudflare come from?

Tell them apart by the error page: a Cloudflare-signed 403 comes from your own security rules (adjust the rule), a Shopify-signed 403 comes from the storefront rejecting unexpected proxied traffic (go back to grey cloud). Error 1000 has the same outcome.

What does Cloudflare bring to a Shopify store, then?

Fast nameservers, email management (MX, SPF, DKIM, DMARC), domain redirects via Redirect Rules on non-Shopify hostnames, and proxying of other subdomains (app, docs, self-hosted blog). A DNS-management and adjacent-services role, not a storefront proxy.

Shopify behind Cloudflare™: 403 errors, orange-to-orange, and outages