Azure Blob Storage: identical 33 MB PDF downloads much slower than another host from Hungary and Sri Lanka

Problem description

We are investigating severe download-throughput problems from an Azure Blob Storage public endpoint.

We tested an identical 33,114,173-byte PDF hosted on Azure Blob Storage and on an independent general-purpose HTTPS host. Matching SHA-256 hashes confirm that the downloaded files are byte-for-byte identical.

The same clients downloaded the file over direct connections, with VPNs off:

ClientAzure: single GETAzure: six concurrent rangesOther host: single GETHungary17.20 s3.60 s1.49 sSri Lanka652.89 s80.70 s9.09 s

The other host was approximately 11.6× faster in Hungary and 71.8× faster in Sri Lanka when comparing the first single-stream measurements.

These are complete-file download timings; PDF parsing and rendering are excluded. The other-host results used ordinary full GETs, without parallel downloads.

The Azure tests occurred on 29 October 2026, approximately 20:27–20:39 UTC, and the other-host tests at approximately 21:01–21:02 UTC. They were not simultaneous, so network variability remains a consideration.

Environment

• Azure Blob Storage, public HTTPS endpoint.
• Blob type: BlockBlob, access tier: Hot.
• Storage configuration: StorageV2 (general-purpose v2), Standard performance, SKU Standard_RAGRS, with read-access geo-redundant storage (RA-GRS). Primary region: West US 2 (westus2). Secondary region: West Central US
• Windows clients using Chrome in Hungary and Sri Lanka.
• General connection benchmarks: approximately 850** Mbit/s in Hungary** and 50 Mbit/s in Sri Lanka.
• Browser tests used cache: "no-store".
• The Sri Lankan test tab remained in the foreground, with No throttling selected in Chrome DevTools.

Timing and troubleshooting evidence

For the slow Sri Lanka Azure single GET:

• Response headers arrived after approximately 1.54 seconds.
• Approximately 651 seconds were then spent receiving the response body.

This places almost all the delay after the initial response.

Additional findings:

• Slow single-stream downloads also reproduced outside Chrome in Hungary, including curl and Python measurements of approximately 15–18 seconds.
• AzCopy in Hungary took approximately 9 seconds with its normal parallel transfers, and 18.8 seconds with concurrency limited to one.
• The parallel browser tests successfully reconstructed the complete PDF from HTTP 206 responses, with matching checksums.
• No explicit proxy or TLS interception was identified in the Hungary tests.
• Earlier switching between Microsoft network routing and Internet routing did not produce a meaningful improvement.
• A separate, earlier Sri Lanka test improved substantially through a US VPN.

A broad, 24-hour GetBlob metrics view showed average Success E2E Latency of 313.27 ms versus Success Server Latency of 30.27 ms. These aggregates include unrelated requests and do not establish the server processing time for the specific slow PDF transfer.

We have not yet collected a packet capture or correlated per-request storage logs for the failing Sri Lanka transfer.

Questions

1. Which measurements would best distinguish routing/peering problems, packet loss, receive-window limitations, and storage-endpoint TCP behavior?
2. Can a Microsoft engineer correlate our exact request IDs and timestamps with available service telemetry through the linked private support case?
3. What remediation would provide reliable downloads from Hungary and Sri Lanka without requiring a VPN or modifying the existing production PDFs?

Parallel requests help, but 80 seconds remains too slow for interactive PDF loading in Sri Lanka.

Exact request IDs, JSON measurement reports, and storage configuration details can be supplied privately through the associated support case.