Our production site https://www.olgagazhienko.ru/ renders the start of pages on affected networks, but larger Vercel-served images, CSS, and JS can remain incomplete. We have not identified whether transmission stops at the edge or later on the route. I am looking for Vercel/CDN guidance on how to correlate the following request IDs with edge-side bytes sent.
Reproducible public resource: https://www.olgagazhienko.ru/images/figma/olga-portrait.webp returns HTTP 200, Content-Length: 148926, Content-Type: image/webp, X-Vercel-Cache: HIT. Three consecutive HTTP/1.1 downloads from one affected client/network, each to 216.198.79.65:443 with a fresh connection, all ended in curl error 28 after 12 seconds:
UTC 2026-10-19 | x-vercel-id | bytes received 16:49:48.536 | fra1::g2sf4-1792428588641-c7e4985ec178 | 21,222 / 148,926 16:50:00.593 | fra1::mt8m6-1792428600695-dab3ba99039a | 21,222 / 148,926 16:50:12.629 | fra1::nhg66-1792428612722-a5736593c036 | 14,148 / 148,926
Command: curl.exe --http1.1 --resolve www.olgagazhienko.ru:443:216.198.79.65 --max-time 12 -o portrait.webp https://www.olgagazhienko.ru/images/figma/olga-portrait.webp
This also happens with a larger JS chunk, CSS, /_next/image, and a larger HTTP/2 homepage body. A ~13.9 KB JS file and 16 KiB image ranges finish; 32 KiB image ranges often stall. A separate product JPG downloaded directly from public Supabase Storage finishes (95,156/95,156 bytes); that same JPG through Vercel /_next/image stops at 13,672/44,306 bytes. A 200 KB file from Cloudflare completes in ~1.3 seconds on the same client/network.
A filtered client-side TCP-header capture for one failed transfer shows TCP/TLS established, inbound data ACKed, then 11.726 seconds with no further inbound packets until the client times out. In that capture we saw no RST, retransmission, duplicate ACK, or zero receive window. This does not prove whether the edge stopped sending or packets were lost before the client.
Can Vercel staff check whether the fra1 edge emitted the complete 148,926-byte response body for these request IDs? If it did, we can focus on the downstream route. If it did not, what edge/CDN diagnostic or supported routing test would help locate the stall? A traceroute reaches the destination at hop 13 (~52 ms), and 1472-byte DF pings pass; TCP PMTU remains unconfirmed. No DNS, project configuration, Production code, Supabase, or router changes were made during this investigation. Client public IP and raw packet capture are intentionally not posted publicly.
Additional lookup context: Production deployment https://recipe-pdf-store-7a5vil23o-richbankers-projects.vercel.app/ ; deployment ID 2JXdkotg8RwS3akcB2NQNrpAxHcU ; main commit 6070be5. External Check-Host report: https://check-host.net/check-report/52095e72ke3d . Six external nodes returned HTTP 200 for the raw image, but that test did not verify complete response-body bytes.