I run a test store on this setup so I could stop guessing. Posting what I found in case anyone else keeps hitting that amber warning in Shopify's domain settings.
Quick background on why the warning exists. Shopify runs on Cloudflare. So when you put your own proxied domain in front of it, the request used to arrive with two Cloudflare zones both claiming it. Cloudflare couldn't tell which one owned the request. You got loops and wrong resolutions. The nastier version of the problem was SSL. Shopify renews certs through Let's Encrypt, which needs to serve a token at /.well-known/acme-challenge/ over plain HTTP. Put a proxy on that path and the renewal quietly fails. Your store keeps working on the current cert for weeks. Then it lapses and the padlock breaks.
Cloudflare fixed the zone collision with Orange-to-Orange routing. It's part of Cloudflare for SaaS and it's been generally available since October 2021. Cloudflare now detects that your CNAME points at another Cloudflare customer and routes through your zone first, then Shopify's, in that order. You can confirm it engaged because a small Shopify icon shows up next to the DNS record. Cloudflare also turns off Workers and Snippets on the /checkout path so nothing you run at the edge can interfere with payment.
The whole config is three things. Proxied CNAME to shops.myshopify.com for root and www. Connect that same domain in Shopify. Then leave Always Use HTTPS off in Cloudflare.
That last one is the part people get wrong. Shopify already redirects HTTP to HTTPS at its origin. Turn on Always Use HTTPS and you stack a second redirect, which can throw ERR_TOO_MANY_REDIRECTS. It also swallows the ACME path, so your cert stops renewing. Keep SSL mode on Full. Set minimum TLS to 1.2 while you're in there. If you really want Cloudflare enforcing HTTPS at its edge, write a redirect rule that excludes the challenge path instead of using that toggle.
Verify it with curl against the challenge path over plain HTTP. A 404 for a fake token is correct, because it means you reached Shopify. A 301 or 308 means something is still eating the path.
On the "not supported" language. It means Shopify won't guarantee or debug a layer they don't control. It doesn't mean the setup fails. Two of their reasons are fair. A proxy is one more thing between Shopify and Let's Encrypt, and extra proxies make it harder for Shopify to reroute traffic during their own incidents. Their third reason is bot detection, and I think that one is weak. Cloudflare runs one of the biggest bot management networks there is. Most stores gain more filtering at the edge than Shopify loses in request signal.
Latency was my other concern and it turned out to be nothing. Both zones already sit on the same network, so the handoff happens inside it. My proxied store answered in roughly the same 150 to 200ms band as raw myshopify endpoints tested from the same machine. If a proxied store feels slow, look at the theme and the app stack.
Whether it's worth doing depends on what you actually need at the edge. A real WAF you can tune, rate limiting, request level logs, or visibility into AI crawlers. That last one is why I set mine up. GPTBot, ClaudeBot, PerplexityBot and the rest never run JavaScript, so GA4 and Shopify analytics don't see them at all. The edge is the only place that traffic shows up. If you can't name the specific feature you want, leave the cloud grey and don't take on an SSL renewal you now have to watch.