Dynamic requests fail from Celerity/PuntoNet Ecuador (Cloudflare UIO) but work via Movistar

Summary

CommandCode dynamic requests are reproducibly failing when accessed through Celerity / PuntoNet Ecuador (AS22724), while the same MacBook, account/API credentials, and endpoints work immediately when switching to Movistar Ecuador.

The failure appears specific to dynamic CommandCode traffic entering Cloudflare through the UIO (Quito) PoP. Static assets from the same domain load normally at high speed.

Environment

• Country: Ecuador
• Affected ISP: Celerity / PuntoNet
• ASN: AS22724
• Alternative ISP tested: Movistar Ecuador
• Same MacBook and same CommandCode account/API credentials used for both networks
• Another independent CommandCode user on Celerity/PuntoNet reports the same inability to access CommandCode

Browser behavior

• Celerity/PuntoNet: https://commandcode.ai/ does not load
• Movistar Ecuador: https://commandcode.ai/ loads normally

Homepage reproduction

Movistar Ecuador

HTTP=200
REMOTE_IP=172.67.167.23
CONNECT=0.248369s
TLS=0.351510s
STARTTRANSFER=0.881522s
TOTAL=1.076917s
SIZE=232418
cf-ray: a351479cec685cf1-MIA
cf-placement: remote-LAX

Celerity / PuntoNet

curl: (28) Operation timed out after 30005 milliseconds with 0 bytes received
HTTP=000
REMOTE_IP=172.67.167.23
CONNECT=0.015248s
TLS=0.063954s
STARTTRANSFER=0.000000s
TOTAL=30.005524s
SIZE=0
cf-ray: a35148cdf9019d34-UIO
cf-placement: remote-LAX

HTTP/1.1 vs HTTP/2 on Celerity

Both transports fail, so this does not appear to be HTTP/2-specific:

HTTP/1.1:
CONNECT=0.071170s
TLS=0.082962s
START=0
TOTAL=20.006s
SIZE=0
timeout

HTTP/2:
CONNECT=0.008441s
TLS=0.021694s
START=0
TOTAL=20.003s
SIZE=0
timeout

Both Cloudflare Anycast IPs tested explicitly

172.67.167.23
HTTP=200
CONNECT=0.005310s
TLS=0.020793s
START=7.976469s
TOTAL=20.001645s
SIZE=1182
timeout

104.21.49.202
HTTP=200
CONNECT=0.030844s
TLS=0.045795s
START=5.846401s
TOTAL=20.005682s
SIZE=9656
timeout

Static assets work normally via Celerity

A static JS asset from the same domain downloads normally and very quickly:

GET /assets/entry.client-DPSbUKbt.js
HTTP=200
CONNECT=0.011425s
TLS=0.022999s
START=0.044854s
TOTAL=0.057734s
SIZE=247337
SPEED=4284078 B/s

This suggests this is not a generic DNS, TLS, bandwidth, MTU, or Cloudflare reachability problem.

Provider API

From Celerity/PuntoNet:

• GET /provider/v1/models returns HTTP 200 normally.
• POST /provider/v1/chat/completions establishes DNS/TCP/TLS/HTTP2 successfully, sends the request body, but has been observed receiving 0 bytes for 60 seconds and timing out.

Example failure:

Connected to api.commandcode.ai
TLSv1.3 established
HTTP/2 stream opened
POST /provider/v1/chat/completions sent
Operation timed out after 60002 milliseconds with 0 bytes received
curl: (28)

The same inference request succeeds via Movistar:

model=deepseek/deepseek-v4-flash
response=COMMANDCODE_MOVISTAR_OK
HTTP=200
TOTAL=1.847907s

A later inference request via Celerity also succeeded but was much slower (~11.3s), indicating the issue may be intermittent/degraded rather than a hard block.

Observed path difference

Celerity/PuntoNet -> Cloudflare UIO -> dynamic CommandCode path -> stalls/timeouts
Movistar          -> Cloudflare MIA -> dynamic CommandCode path -> works

Both homepage responses report:

cf-placement: remote-LAX

Suspected area

Because static edge/cache assets work normally through Celerity while dynamic HTML and inference traffic stall, this looks more like an issue involving Cloudflare Worker / Smart Placement / origin or backend routing for traffic entering through UIO, rather than a generic ISP outage.

Could you please check Worker/Smart Placement/backend traces for requests entering through the UIO PoP, especially around the CF-Ray IDs above?

I can provide additional curl traces if useful.

Bắt đầu với các ID CF-Ray đã được báo cáo và so sánh các request động của homepage và inference đi vào qua UIO PoP với đường đi Movistar/MIA đang hoạt động bình thường. Kiểm tra các trace của Worker, Smart Placement và backend routing; công việc được xem là hoàn tất khi đã xác định và khắc phục nguyên nhân khiến các request động đôi khi bị treo mà không làm hỏng các static assets hoặc Provider API đang hoạt động.