If an OSS object download fails intermittently, the most likely cause is traffic hijacking — either OSS never received the request, or OSS responded but the response was intercepted before reaching your client.
Two indicators in the HTTP response header confirm hijacking:
| Indicator | Hijacked response | Normal response |
|---|---|---|
Server field | Empty | AliyunOSS |
Cache-Control header | Missing | Present |
Diagnose the issue
Start with the OSS access log — it is faster than a packet capture and is often sufficient.
Step 1: Get the request ID from the failed download.
Obtain the request ID captured in the failed download request.
To make log queries easier, enable OSS access logging before you start troubleshooting. For instructions, see Configure logging.
Step 2: Check the OSS access log using the request ID.
Look at the client IP address recorded in the log. If the object was downloaded from an Elastic Compute Service (ECS) instance, the client IP should match the public IP address of that instance. If it does not match, the download did not go directly from ECS to OSS — either a proxy is configured on your side, or the download traffic is being hijacked.
Step 3 (if needed): Capture and analyze packets.
Use a packet capture tool (such as Wireshark or tcpdump) if the log alone does not identify the cause. Compare the response headers of a failed request against a successful one:
Failed download: The
Serverfield in the response header is empty, and the Time to Live (TTL) of the TCP three-way handshake packet between the client and OSS is 64.Normal download: The
Serverfield isAliyunOSS, and the TTL is 53 (within the expected range).
Use these two signals to identify hijacking:
A valid OSS response always sets
ServertoAliyunOSS. An emptyServerfield means the response did not originate from OSS.OSS sends responses with a default TTL of 64. Because TTL decreases by 1 at each network hop, a client receiving a response with TTL = 64 indicates the packet traveled zero hops — a strong sign of hijacking.
The following screenshot shows a captured abnormal response. The Server field is empty and the TTL (packet #1153) is 64.
The following screenshot shows a captured normal response. The Server field is AliyunOSS and the TTL is 53.
Solution
If you confirm the download traffic is being hijacked:
Check your network environment for proxy configurations on the client side that may be routing traffic unexpectedly.
Switch to HTTPS to prevent traffic interception. For details, see How HTTPS access is implemented in OSS.