Whether 4K streaming holds up does not depend on the peak number a speed test shows — it depends on whether the international route can keep supplying the bitrate for the entire playback session. When sustained throughput falls below the source bitrate, the player's adaptive bitrate algorithm steps down: 4K drops to 1080p, then to 720p, and finally settles at 480p.
Below we start with how bitrate and bandwidth relate, break down the common reasons 4K drops to 480p, compare direct, relay and IEPL routes, and cover the metrics to check when choosing an international route, plus how to keep quality stable at peak hours.
Bitrate vs. Bandwidth: How the Two Numbers Relate
Bitrate is how much data the source produces per second; bandwidth is how much data the link can carry per second. Both are measured in Mbps, but they mean different things — bitrate is demand, bandwidth is supply. On mainstream platforms, the 4K tier usually sits at 15–25 Mbps, 1080p at about 5–8 Mbps and 480p at about 1–2 Mbps. Dropping from 4K to 480p is an order-of-magnitude fall in data.
Players do not look at average speed alone. Adaptive bitrate (ABR) chooses a tier from download speed over short windows, buffer headroom and packet loss: once the playable buffer time falls below a threshold it steps down immediately, and if throughput stays short it settles at 480p. So "a 100 Mbps speed test but only 480p playback" is no contradiction — peak speed is not sustained throughput.
Five Common Reasons 4K Drops to 480p
The local connection is saturated by other devices
Home broadband is shared. System updates, cloud drive sync and a livestream on another device all eat into the headroom before playback even starts. The test is simple: leave only one device playing and see whether quality returns to the 4K tier.
Packet loss and jitter on the international link
Packet loss along the cross-border path triggers transport-layer retransmissions, effective throughput collapses within a few hundred milliseconds, and ABR steps down right after. Packet loss and jitter usually affect picture quality more directly than average latency: a high-latency but stable route is often better for 4K than a low-latency route with heavy jitter.
Circuitous routing and peak-hour congestion
On direct routes, the international path is decided by peering between carriers and is outside the user's control, so it is easily crowded out at peak hours. The classic pattern: fine during the day, a consistent step-down after 20:00, and back to normal in the same window on a dedicated line.
DNS resolution and broken CDN proximity
Streaming relies on CDN edge nodes serving content from nearby. If DNS requests are resolved remotely, you get the address of a distant node and your data takes a long detour. Start by checking whether DNS results match expectations and whether DNS leaks are occurring, then look at whether nearby node scheduling is working properly.
Account and region policies on the platform side
Some platforms cap maximum quality based on plan tier, region detection and the number of simultaneous streams. If only one platform steps down while others are fine, the route is probably not the problem — check your plan tier and the platform's playback device limits first.
A speed test measures peak speed to a nearby test server, while 4K playback uses a sustained connection to a streaming CDN — different paths entirely. When troubleshooting a step-down, look at download speed and packet loss over 10 seconds or more, not the result of a single peak speed test.
| Symptom | More likely cause | What to check first |
|---|---|---|
| Stuck at 480p from the start | Not enough local headroom, or the route's throughput ceiling is below the source bitrate | Stop downloads and livestreams on other devices, then retry with one device |
| Steps down after a few minutes of playback | Jitter or packet loss on the link; sustained throughput is unstable | Measure download speed and packet loss continuously, not with a single speed test |
| Only steps down at peak hours | Congested shared exit, circuitous direct routing | Switch to a dedicated line and compare the same time window |
| Only one platform steps down | Plan tier or region policy on the platform side | Play the same bitrate tier on another platform as a control |
| Normal again after switching devices | Client decoding capability or an outdated protocol stack | Update the client and confirm hardware decoding is enabled |
Route Types Compared: Direct, Relay and IEPL Dedicated Lines
The difference between the three common paths comes down to how data leaves the region and who decides the route. Direct routing is determined by carrier peering; relay adds a hop but keeps the path more controllable; IEPL runs end to end on a dedicated line and never touches the public exit.
| Route type | Data path | Peak-hour stability | Best suited for |
|---|---|---|---|
| Direct | Leaves the region straight from the local exit; path set by carrier peering | Noticeable fluctuation | Web browsing, light use |
| Relay | Connects to a relay entry point first, then goes international | Relatively stable | Everyday video, meetings |
| IEPL dedicated line | End-to-end dedicated line, no public exit involved | Lower jitter and packet loss | 4K streaming, long online sessions |
With relay, everything depends on the quality of the entry point: if the entry itself is congested, a stable back end means nothing. An IEPL line has a fixed path and does not compete with other public traffic, at the cost of being more expensive — usually billed by bandwidth or data volume. Which one to pick depends on how much step-down risk you can accept, not on which name sounds better in a list.
What Protocols Can and Cannot Fix
Shadowsocks, VMess, Trojan and VLESS run over TCP/TLS, offer broad compatibility and suit ordinary network conditions; Hysteria2 and TUIC are built on QUIC (UDP) and use more aggressive congestion control and retransmission strategies on lossy links, recovering part of the effective throughput when packets are being dropped. But protocols change transport strategy, not the physical ceiling: a route that sustains only 5 Mbps will not carry a 25 Mbps 4K source no matter which protocol you use. Switching protocols is a good way to test whether a step-down is caused by link loss; it is not a way to make up for a route that simply lacks bandwidth.
Metrics Worth Checking When Choosing an International Route
- ✅ Bandwidth specifics: does it state the per-account bandwidth and how throttling works, rather than just a peak number?
- ✅ Route types: does it distinguish direct, relay and IEPL lines and explain what each is suited for?
- ✅ Peak-hour disclosure: does it describe real peak-hour performance instead of a vague "fast and stable"?
- ✅ Protocols and ports: are both TCP and UDP (QUIC) based protocols available, so you can switch and compare on lossy links?
- ✅ Concurrent devices: is there a cap on simultaneous devices — 4K playback alone takes a sizeable share of the bandwidth?
- ❌ Picking only the "lowest latency" node in the list: latency is an instant reading, and nodes with heavy jitter are the ones that step down most often.
- ❌ Choosing on price alone: the usable throughput of a cheap route at peak hours is often the direct cause of a step-down.
How to Keep Picture Quality Stable at Peak Hours
- Run a sustained throughput test before playback: download continuously for 10–15 seconds and watch whether the rate holds steady, instead of running a single peak speed test.
- Use split-routing rules to pin streaming domains to the dedicated line while everything else goes direct, so download-heavy apps do not crowd the same exit.
- Pin a single node and leave auto-switching off: changing the exit IP mid-playback forces the platform to renegotiate, and some platforms re-evaluate your region.
- Turn off heavy background tasks on the same network: system updates, cloud sync and livestreams on other devices all count.
- Prefer nodes with low jitter: the latency figure in the list is just an instant reading, so measure a few times in a row.
# 100 consecutive packets: check whether loss and jitter stay steady
mtr -rwzbc 100 cdn.example.com
# Download for 15 seconds straight and watch whether the average rate holds
curl -o /dev/null --max-time 15 \
-w "average speed: %{speed_download} B/s\n" \
https://cdn.example.com/test.binThe two commands answer two different questions: the first shows whether the link is steady, the second whether sustained throughput is sufficient. Speed tests report peaks, but these two are what adaptive bitrate actually reacts to.
Conclusion: Check Sustained Throughput First, Then Pick a Route
When 4K drops to 480p, look at sustained throughput first, then at the route type. A peak speed test only shows the link's ceiling; what decides picture quality is sustained throughput and packet loss across the whole playback. Pinning streaming traffic to a low-jitter dedicated line works better than switching nodes over and over.
Stick to a fixed troubleshooting order: rule out local congestion first, then check DNS resolution and packet loss, and finally compare sustained throughput across route types in the same time window. Follow that order and most step-down problems can be traced to a specific link in the chain, instead of ending at "try another node".