My server 8.217.\*\*\*\*\* is advertised as 200Mbps outbound, but actual upload is around 1Mbps.

Back

Resolved

?王czDEVELOPER5/10/2026

My server 8.217.***** is advertised as 200Mbps outbound, but actual upload is around 1Mbps.

speedtest-cli:
Upload: 1.16 Mbit/s

curl large POST:
upload=159476B/s

This started today. Please check host-level QoS, bandwidth cap, routing, or network degradation.

6 Replies

BCBohan ChenEMPLOYEE5/11/2026

Checked from inside the server — re-ran speedtest-cli (still installed at /usr/bin/speedtest-cli):

Server: Sun Mobile (Hong Kong), 3.92 km, 3.9 ms ping
Download: 218.71 Mbit/s
Upload: 247.89 Mbit/s

The box is currently operating slightly above the 200 Mbps spec, both directions.

A few observations:

Host-side is clean. tc qdisc on eth0 is kernel default — no shaping, no rate-limit sysctls. The kernel hasn't rebooted since April 25 (last reboot), so yesterday's dashboard "reinstall" event was a Zeabur-system component redeploy, not a kernel reboot — no network-stack change happened there.
Your measurements at the time were real. Multiple independent tools converging on ~1 Mbps is too consistent to be a tooling artifact. Something upstream was throttling outbound during that window, and has since cleared.

Without Aliyun's instance-level network metrics, pinpointing the cause of a now-cleared transient from host data alone is tough — typical suspects on Aliyun HK are a brief Anti-DDoS Basic rate-cap, congestion on the HK international transit, or a short EIP bandwidth fluctuation, none of which leave host-side traces.

If it recurs, please capture the timestamp (to the minute) and we'll pull the provider-side metrics for that window. For now, the server is back at spec.

?王czDEVELOPER5/12/2026

Right now, at this very moment, from 6:00 PM until 23:08 (GMT+8), it has been stuck at around 1.09 Mbit/s.

speedtest-cli Retrieving speedtest.net configuration... Testing from Alibaba (8...*)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by STC (Hong Kong) [3.92 km]: 2.703 ms Testing download speed................................................................................ Download: 1.09 Mbit/s Testing upload speed...................................................................................................... Upload: 1.33 Mbit/s

?王czDEVELOPER5/12/2026

urgent！！！！urgent！！！！urgent！！！！
23:10 （GMT+8）

speedtest-cli
Retrieving speedtest.net configuration...
Testing from Alibaba (8.********)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by GSL Networks (Hong Kong) [3.92 km]: 2.153 ms
Testing download speed................................................................................
Download: 0.62 Mbit/s
Testing upload speed......................................................................................................
Upload: 1.16 Mbit/s

?王czDEVELOPER5/12/2026

00:44 (GMT+8) Download: 0.04 Mbit/s!!!!!

speedtest-cli Retrieving speedtest.net configuration... Testing from Alibaba (8.*****)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Netvigator (Hong Kong) [2.77 km]: 37.944 ms Testing download speed................................................................................ Download: 0.20 Mbit/s Testing upload speed...................................................................................................... Upload: 1.13 Mbit/s speedtest-cli Retrieving speedtest.net configuration... Testing from Alibaba (8.****)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by GSL Networks (Taipei) [809.12 km]: 15.529 ms Testing download speed................................................................................ Download: 0.04 Mbit/s Testing upload speed...................................................................................................... Upload: 0.53 Mbit/s

BCBohan ChenEMPLOYEE5/13/2026

I have pulled the data from Alibaba Cloud for the corresponding period:

Plan: 200 Mbps peak, no traffic package included — so it is not a case of "monthly traffic exhausted → rate limiting".
Anti-DDoS Basic events for your server over the past 7 days: 0. Instance status during the event: Normal.
Inbound bandwidth was locked at 1.02 Mbps from 16:30–17:15 UTC on 5/12 — this is a characteristic of hard rate limiting by the upstream, not congestion jitter.
Current status (5/13 03:03 UTC) re-tested from within the machine: 232.66 / 257.07 Mbps, fully recovered.

I can confirm the rate limiting is real and occurred upstream of your VM. After ruling out possibilities one by one: there is no shaping/packet loss on the host side, Anti-DDoS was not triggered, and there is no traffic quota to exhaust. The only remaining explanation is that Alibaba Cloud Hong Kong's shared international transport/peering links experienced degradation during that period — this layer belongs to Alibaba Cloud's network layer and is not something Zeabur can control or adjust on your behalf.

If it recurs during the same period, you may consider:

Placing Cloudflare in front (enable proxy) — most user traffic will be absorbed by the CDN edge, so the origin server's egress bandwidth will no longer be a bottleneck.
Changing regions (Singapore, Tokyo) — to use different international routes.
Changing providers — the shared transport model of Alibaba Cloud Hong Kong SWAS inherently carries this risk.

If you encounter this again, please provide the timestamp, and I will pull the data again.

AAnonymous5/17/2026

This post has been inactive for a while. We will be closing it in 2 days if there is no new activity.

This issue has been marked as resolved

New replies are disabled for resolved issues.

Forum

6 Replies