I've also been experiencing this issue.
I hope they fix it soon. I personally consider the network an integral part of the service in 2026 ;/
https://wiki.archlinux.org/title/Steam/Troubleshooting#Unusually_slow_download_speed
Are you sure you aren't hitting this?
Fixed it by adding to /etc/hosts 0.0.0.0 + slow steam cdn servers. Launch steam with steam://open/console. Start download and write in console download_sources. Add any slow cdn to hosts with 0.0.0.0
My steam_dev.cfg
@nClientDownloadEnableHTTP2PlatformLinux 0
@fDownloadRateImprovementToAddAnotherConnection 1.1
@cMaxInitialDownloadSources 15
@cMaxContentStatsdays 30
@cMaxPendingUploads 4
https://wiki.archlinux.org/title/Steam/Troubleshooting#Unusually_slow_download_speed
Are you sure you aren't hitting this?
Thanks for the advice, yes I tried the solutions described in the arch wiki that you linked and the download of the games does not go beyond 40MB/s, I think it is a limitation of the 32bit linux steam client, I don't know what else it could be.
Fixed it by adding to /etc/hosts 0.0.0.0 + slow steam cdn servers. Launch steam with steam://open/console. Start download and write in console download_sources. Add any slow cdn to hosts with 0.0.0.0 My steam_dev.cfg
@nClientDownloadEnableHTTP2PlatformLinux 0@fDownloadRateImprovementToAddAnotherConnection 1.1@cMaxInitialDownloadSources 15@cMaxContentStatsdays 30@cMaxPendingUploads 4
Ok I'll try, thanks for the advice
[#12178](https://github.com/ValveSoftware/steam-for-linux/issues/12178) pretty sure it’s the same issue
No, it doesn't seem the same to me, mine never goes above 40MB/s at peak, even though on every other download I do outside of Steam I go well over 200MB/s
[#12178](https://github.com/ValveSoftware/steam-for-linux/issues/12178) pretty sure it’s the same issue
No, it doesn't seem the same to me, mine never goes above 40MB/s at peak, even though on every other download I do outside of Steam I go well over 200MB/s
Same as we are not getting the full speed as compared to windows if you look at my issue in the last comment I attached an ss of steam runing on wine and im getting my full 1gbps.
[#12178](https://github.com/ValveSoftware/steam-for-linux/issues/12178) pretty sure it’s the same issue
No, it doesn't seem the same to me, mine never goes above 40MB/s at peak, even though on every other download I do outside of Steam I go well over 200MB/s
Same as we are not getting the full speed as compared to windows if you look at my issue in the last comment I attached an ss of steam runing on wine and im getting my full 1gbps.
ok i found the problem, i used strace, check out my post i updated it
@davgar99 @bblacher @desx88
Fingers crossed Valve sees this post 🤞🏻
@kisak-valve
Hi! It is now August 30th 2026 and I've run into this bug as well, very frustrating, here's all the data I gathered trying to fix it on my own:
I hit this exact issue and did fairly extensive isolation testing across two separate Linux machines. Posting my findings since I was able to rule out basically every non-client explanation, plus some strace data that may point at the actual mechanism.
Setup:
Ruled out:
Network/ISP/routing — non-Steam downloads (wget, generic CDN) hit full line rate consistently
MTU/PMTU blackholing — found and fixed a real 1492 MTU mismatch (PPPoE), confirmed via ping -M do, had zero effect on Steam specifically
TCP buffer sizes / congestion control — increased net.core.rmem_max/wmem_max and tcp_rmem/tcp_wmem to 256MB, switched congestion control to BBR+fq — no change
Filesystem/CoW — tested on both btrfs (with chattr +C NOCOW, no compress-force) and a fresh EXT4 install — same ~20MB/s cap on both
Disk I/O — same disk sustains 110MB/s+ on a plain sequential write (wget test), so raw disk throughput isn't the ceiling
CPU — confirmed via btop during a capped download, no core anywhere near saturated (highest ~14%), load average low
DNS — already on 1.1.1.1/1.0.0.1 via NetworkManager by default; no change
steam_dev.cfg — full recommended set applied and confirmed present:
@nClientDownloadEnableHTTP2PlatformLinux 0
@fDownloadRateImprovementToAddAnotherConnection 1.0
@cMaxInitialDownloadSources 15
@cMaxContentStatsdays 30
@cMaxPendingUploads 4
Download region — tried Toronto, Ottawa, Montreal — no change
Bandwidth limiter — confirmed unchecked/disabled in Settings → Downloads
download_sources output during a capped download (Cyberpunk 2077, ~20MB/s total):
15-16 simultaneous connections open, each individually capped in the 0.3–1.8MB/s range, summing to the ~20MB/s ceiling. Every connection is throttled roughly uniformly — this doesn't look like a "one bad CDN node" issue, since none of the 15+ sources are meaningfully faster than the others.
strace evidence:
Attached strace to the download thread handling actual TLS traffic to steamcontent.com. Sample of recvmsg() calls:
18308 recvmsg(235, ...iov_len=65536..., MSG_DONTWAIT) = 1400 <0.000013>
18308 recvmsg(235, ...iov_len=65536..., MSG_DONTWAIT) = 5600 <0.000012>
18308 recvmsg(162, ...iov_len=65536..., MSG_DONTWAIT) = 516 <0.000014>
18308 recvmsg(172, ...iov_len=65536..., MSG_DONTWAIT) = 5600 <0.000021>
Every call requests up to 65536 bytes but consistently returns small counts (mostly 1400-5600 bytes, occasionally as low as 516-518), always with MSG_DONTWAIT. This matches the "small read sizes" behavior described in this issue — the client appears to poll each socket non-blocking and drain only whatever has already arrived, rather than accumulating a larger buffer before reading. This would explain the throttled per-connection throughput even with many parallel connections open (15-16 in my case, ~1-2MB/s each, summing to the same ~20MB/s ceiling regardless of connection count).
Hope this can help somehow, thank you!!!
I've done some further research and it appears the issue is with the caching on the Valve fco server.
EDIT
Problem Found!
TL;DR
the reduced download performance of the Steam Linux client is caused by inefficient socket consumption behavior, characterized by small read sizes and long idle intervals. This leads to a persistently low receive window and severely constrained throughput. The findings demonstrate a clear case of receiver-side application throttling, where the network stack and underlying system are capable of high performance, but are underutilized due to the client’s internal design.
This analysis investigates a reproducible throughput limitation observed in the Linux client of Valve Corporation Steam on Arch Linux system. The issue initially appears as degraded network performance during game downloads, but detailed inspection reveals that the bottleneck is not located in the network stack, congestion control algorithm, or kernel configuration. Instead, it originates from the application’s data consumption behavior.
TCP metrics collected during active downloads show a consistent pattern: congestion window (cwnd) grows normally from its initial value, indicating no network congestion; however, the receive window (rcv_wnd) remains abnormally small (on the order of ~180 KB), and the delivery rate reported by BBR remains limited (~1 Mbps per connection) despite multiple parallel connections. In contrast, a reference downloader such as aria2c, executed on the same system and network path, achieves full line-rate throughput (200 MB/s+) with significantly larger receive windows (3 MB+) and efficient parallelization.
To isolate the cause, system call tracing was performed on the Steam client process using strace, focusing on recvfrom and event loop behavior. The process was confirmed to run in 32-bit mode, though this characteristic alone does not directly imply reduced network performance. The observed behavior reveals a highly inefficient read pattern: data is consumed in small chunks (~6.7 KB per recvfrom call), followed by substantial idle periods ranging from hundreds of milliseconds to several seconds. Each read cycle consists of a small header read, a payload read, and then an immediate EAGAIN, after which the process remains idle before repeating the pattern.
This intermittent consumption directly impacts TCP flow control. Because the application does not continuously drain the kernel receive buffer, the buffer fills up, causing the advertised receive window to shrink. As a result, the sender reduces its transmission rate despite the absence of network congestion. This produces a classic application-limited throughput scenario, where the transport layer is effectively throttled by the receiver’s inability (or unwillingness) to consume data promptly.
The behavior contrasts sharply with high-performance downloaders such as aria2c, which employ aggressive and continuous read loops, larger buffer sizes, and efficient multithreading. These characteristics ensure that the receive buffer remains mostly empty, allowing TCP window scaling to function optimally and enabling the sender to fully utilize available bandwidth.
The root cause is therefore attributable to the internal design of the Steam client’s data pipeline on Linux. The observed pattern suggests a synchronous or poorly parallelized processing model, potentially involving sequential stages such as network read, decompression, validation, and disk write operations. If these stages are not decoupled through asynchronous I/O or multithreaded buffering, the network read phase becomes intermittently blocked, leading to the burst-and-stall pattern observed in the trace.
While the client operates in 32-bit mode, this is not the direct cause of the issue. Rather, it is indicative of legacy architectural decisions that may correlate with suboptimal I/O handling and event loop design. The limitation persists regardless of kernel tuning, TCP congestion control (including BBR), or increased socket buffer sizes, confirming that the bottleneck is entirely application-side.
16:30:35.331635 recvfrom(128, "q9\275\0\0\0\200\3\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0 \10\377\0\0\0\0"..., 6732, 0, NULL, NULL) = 6732 16:30:35.332277 recvfrom(128, "\1\0\v\0\0\0\223\6", 8, 0, NULL, NULL) = 8 16:30:35.332315 recvfrom(128, "q9\275\0\0\0\200\3\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0 \10\377\0\0\0\0"..., 6732, 0, NULL, NULL) = 6732 16:30:40.380843 recvfrom(71, "\1\0\v\0\0\0\223\6", 8, 0, NULL, NULL) = 8 16:30:40.380891 recvfrom(71, "q9\275\0\0\0\200\3\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0 \10\377\0\0\0\0"..., 6732, 0, NULL, NULL) = 6732 16:30:40.381503 recvfrom(71, "\1\0\v\0\0\0\223\6", 8, 0, NULL, NULL) = 8 16:30:40.381516 recvfrom(71, "q9\275\0\0\0\200\3\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0 \10\377\0\0\0\0"..., 6732, 0, NULL, NULL) = 6732This is typical of software born on Windows and ported to Linux without rethinking asynchronous I/O 🐧 :(
likely a suboptimal design of the network loop and data pipeline