Layer0 is designed and built to be the component of your site to which your users will directly connect to from their devices. Such components are colloquially known as "edge components". But sometimes you may prefer to run Layer0 behind a third-party CDN due to a preexisting contract. Layer0 fully supports this use case but it's important to call out some common pitfalls with this kind of network topology.

Layer0 does not support HTTP traffic and has a built-in redirect to HTTPS. That redirect relies on the value of host request header in order to form the value of location response header (e.g. a host value of docs.layer0.co will result in a location value of https://docs.layer0.co). When a third-party CDN is in front of Layer0, the host header is not the public facing domain but rather the domain to which the downstream CDN is routing traffic. If the downstream CDN allows HTTP traffic to reach Layer0 then Layer0 will respond with an incorrect value in location response header.

Options to solve these all rely on different ways of configuring the third-party CDN:

  1. Add an HTTP to HTTPS redirect on the CDN rather than relying on Layer0.
  2. Rewrite the location header on the CDN whenever you see a response from Layer0.
  3. Use the Layer0 domain for IP resolution on the CDN but set the value for host to be the same as the public facing domain. In this case the Layer0 site has to be configured to accept requests with this header so that the reverse proxy works correctly.

Layer0 offers fully featured split testing. When Layer0 is running behind another CDN, the CDN must be configured in a very specific way in order for split testing to work:

  1. Downstream CDN must be configured to not cache anything.
  2. The CDN must be configured to not affect any cookies that begin with layer0_.

Unless these conditions are met, the users will almost certainly receive a mix of content from both experiences in the split test, which can lead to a broken app and invalid split testing results.

When Layer0 is behind a third-party CDN, we strongly recommend that all caching on it be turned off. If you cannot do this for whatever reason, it is then your responsibility to purge the cache on Layer0 and only afterwards on CDN - in that exact order. Failing to do so will almost certainly lead to a situation where stale responses that you wanted to purge are served from Layer0 to your CDN and cached there as non-stale responses before Layer0 itself is purged (so-called cache poisoning).

Caching and traffic metrics are another area that is affected by CDN caching or any kind of traffic shaping where Layer0 no longer sees all the traffic that your site is serving. If the downstream CDN is caching responses then perceived cache hit ratio on Layer0 will be lower than it actually is (Layer0 would only serve cache misses but never cache hits). If the downstream CDN is routing some traffic away from Layer0, then the traffic metrics will be affected as the Layer0 Developer Console will only provide statistics for the traffic that goes through Layer0.

When behind a third-party CDN, Layer0 will analyze x-forwarded-for to correctly extract the client IP from it and inject it into x-0-client-ip. You can continue to use x-0-client-ip as you otherwise would.

Layer0 access logs continue to function normally but since they are not on the edge they may not include all of the traffic that comes to your site.

Layer0 does not block any validly formed HTTP traffic coming from any IP so there is no need to specifically whitelist the backend IPs of your third party CDN.