CF GarageThe 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. That scenario, called "orange-to-orange", is not allowed on a standard plan: it is reserved for Shopify Plus customers, whose architecture explicitly supports it.
Depending on how the zone is configured, the results are: 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
wwwCNAME toshops.myshopify.comstay DNS only. Shopify terminates HTTPS on its own edge, with its own certificate and CDN: those are its strengths, there is nothing to gain by putting a proxy in front. - 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.
- Shopify Plus: the orange-to-orange exception. Plus customers may proxy their storefront through Cloudflare (the integration is supported in that context). If you are on Plus and proxying, the store must stay functional at every switch: 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 (WAF, blocking 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 a standard plan compatible with storefront proxying.
- 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 (WAF exceptions, SSL/TLS mode changes, cache tweaks) to "fix" storefront proxying that simply should not exist on a standard plan. As long as the record is orange, 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 the domain record pointing to Shopify is proxied while that traffic is not allowed to be relayed on a standard plan. Shopify runs its own edge, and double proxying is only supported through Shopify Plus. The fix is switching the record back to grey cloud.
Can you put Cloudflare in front of a Shopify store?
The storefront must not be proxied on a standard plan: Shopify terminates HTTPS at its own edge and orange-to-orange is reserved for Shopify Plus. Cloudflare does bring fast DNS, email, redirects on non-Shopify hostnames, and proxying of other subdomains.
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.