Hi, @idex. Actually, the following is not true:
Somehow, you are not proxying to Netlify when using the production domain. The proof of this can be found in the absence of the HTTP response header named
We always return this header with a string which uniquely identifies that exact HTTP response. There is more about the
x-nf-request-id header in this support guide.
Here is the proof. For
client-staging-alpha.idex.io, the header is returned:
$ curl -svo /dev/null https://client-staging-alpha.idex.io/ 2>&1 | grep 'x-nf-request-id'
< x-nf-request-id: 3a7971ba-d33f-489f-bbb8-cb3a7353b87b
exchange.idex.io , there is no header which proves that Netlify is not the origin for that URL:
$ curl -svo /dev/null https://exchange.idex.io/ 2>&1 | grep 'x-nf-request-id'
To resolve your caching issue, you will need to find the actual origin for that domain. You can then update that origin.
You might also resolve this by making Netlify the origin for that domain. You state the content is correct for the alternative domain and I did confirm that domain is proxied to Netlify (but your production domain is definitely not proxied to Netlify at this time). If you configure your production domain to work the same way as the alternative domain, that should be all that is required to resolve this. However, I don’t know what your settings are at Cloudflare so I cannot tell you what to change there.