Edge behind a Cloud LB / CDN
Managed load balancers and CDNs often terminate TLS upstream, which weakens the edge's connection-level signal — preserve termination, or accept reduced confidence.
This is the setup that needs the most care. AWS ALB, GCP HTTP(S) LB, and CDNs like Cloudflare or Fastly typically terminate TLS themselves and forward a fresh connection to your origin. When they do, the edge sees the load balancer's connection, not the browser's.
If a layer-7 / TLS-terminating LB or CDN sits between the browser and the edge, it becomes the connection-terminating hop. The edge's connection-level timing signal then reflects that intermediary instead of the browser, and confidence drops. The integration still produces verdicts from the remaining signals — but you lose the strongest one.
How to preserve termination
Pick whichever fits your platform:
- Layer-4 (TCP) pass-through. Use a network/L4 load balancer that forwards the raw TCP connection instead of terminating TLS — for example an AWS NLB (rather than ALB), GCP TCP/SSL proxy in pass-through mode, or Cloudflare Spectrum. The browser's connection then reaches the edge host intact.
- Run the edge at the true edge. Place the edge on the host that first faces the public internet for the Octet path (see Standalone / container), with no TLS-terminating hop in front of it.
- A dedicated hostname. Route a dedicated host (e.g.
octet.yourapp.com) straight to the edge tier, bypassing the CDN/LB that fronts the rest of your app.
Always make sure the source IP reaches the edge (via X-Forwarded-For) regardless of topology.
If you can't preserve it
That's a supported configuration — the verdict still comes back, just with the connection-level signal contributing less. Discuss your exact topology with Octet during onboarding; this is precisely the kind of infrastructure detail that's worked out per partner.
Where to go next
- Deploy the Edge. The termination rule in full.
- Standalone / container. The termination-preserving setup.