Traffic from Cloudflare's Seattle PoP enters Fly at NRT for an app in LAX

Questions / Help
1

Hi Fly team,

Our API runs on one machine in lax and sits behind Cloudflare (proxied, with the certificate issued by Fly). Every request Cloudflare forwards from its Seattle PoP (cf-ray suffix SEA) enters Fly at the NRT edge: the fly-request-id suffix was -nrt on every request we sampled on 2026-10-18 between 17:10 and 18:45 UTC.

The endpoint we timed answers in about 1 ms on the machine itself, and takes 220 to 285 ms through that path. A Seattle to Los Angeles trip should be closer to 30 to 40 ms.

Some fly-request-id values from that window:

  • 01M58026H0S6CXB0RS1XMBEBXZ-nrt
    • 01M581ER42Z0WKVR8BH10VC0G1-nrt
    • 01M5802H2NHW2YBD583DY16G1C-nrt
      The app has a dedicated anycast IPv4 and a dedicated IPv6. Separately, from a home connection in Tacoma (AS14677), every Fly anycast address we tried, ours and shared ones like debug.fly.dev, lands on ORD rather than SEA.

Is the SEA to NRT path something you can look at on your side? Happy to share the app name and addresses privately.

Thanks!

2

This is an issue with Cloudflare. We have contacted them but have not yet received a response. If you are able, please contact them as well and ask for their NOC to reach out to us at ops@fly.io.