Intermittent slowness on one specific ISP using Worker as Origin (proxy) / maybe all Cloudflare
Hi - we've got two reports now (myself being one) of https://bgp.tools/as/7303 working surprisingly slow intermittently when users browse through our sites with that specific ISP (and no reports yet on any other ISPs/regions). This has been the case for a few weeks now – not a recent event.
In general we've replicated it mostly over our sites (hosted on Pages, we have a Worker as origin which is a very simple proxy that just passes through the request and assigns a header with the hostname for routing purposes).
Here's a video showing more details https://www.loom.com/share/26eaa5343cf54fa2a66b36539e795206.
Things I've tried:
- Using 1.1.1.1 as resolver or not (said WARP but it wasn't enabled) – same result
- Proxying against our own zone vs *.pages.dev – same result (so not zone-specific settings)
- Not related to any Cache HIT/MISS. F.e. for media we use Cache API and send a server-timing header (which actually also includes the worker startup time) – you can see the time wasn't spent on any app logic of ours
- When things work as expected, most of those requests that took seconds resolve in XX/XXX ms.
- Not seeing any security events (e.g. thought we could be triggering some) when proxying against our zone
- Not seeing anything abnormal doing traceroute / ping to either our site, cloudflare.com or 1.1.1.1 (example in the video)
- Not seeing related errors nor traces anywhere (a few Client Disconnected on the proxy which could be related but also could be normal)
- Not seeing anything odd when opening speed.cloudflare.com (e.g. 0% packet loss)
What'd be recommended ways to debug or understand this issue deeper? Is there any known security mechanism that could make requests stuck as opposed as to 429 / challenge / etc? We're funneling quite a few requests to the same worker but it's still odd to see it only happening with one specific ISP so far.
Has the time come where I'll need to learn how to use Wireshark?
Thanks!
In general we've replicated it mostly over our sites (hosted on Pages, we have a Worker as origin which is a very simple proxy that just passes through the request and assigns a header with the hostname for routing purposes).
Here's a video showing more details https://www.loom.com/share/26eaa5343cf54fa2a66b36539e795206.
Things I've tried:
- Using 1.1.1.1 as resolver or not (said WARP but it wasn't enabled) – same result
- Proxying against our own zone vs *.pages.dev – same result (so not zone-specific settings)
- Not related to any Cache HIT/MISS. F.e. for media we use Cache API and send a server-timing header (which actually also includes the worker startup time) – you can see the time wasn't spent on any app logic of ours
- When things work as expected, most of those requests that took seconds resolve in XX/XXX ms.
- Not seeing any security events (e.g. thought we could be triggering some) when proxying against our zone
- Not seeing anything abnormal doing traceroute / ping to either our site, cloudflare.com or 1.1.1.1 (example in the video)
- Not seeing related errors nor traces anywhere (a few Client Disconnected on the proxy which could be related but also could be normal)
- Not seeing anything odd when opening speed.cloudflare.com (e.g. 0% packet loss)
What'd be recommended ways to debug or understand this issue deeper? Is there any known security mechanism that could make requests stuck as opposed as to 429 / challenge / etc? We're funneling quite a few requests to the same worker but it's still odd to see it only happening with one specific ISP so far.
Has the time come where I'll need to learn how to use Wireshark?
Thanks!
Welcome to the official Cloudflare Developers server. Here you can ask for help and stay updated with the latest news
87,353Members
Resources
Was this page helpful?
