I can confirm this. Don't know when it started tbh. More interesting is it's not just partner caches but appears to be steams own origins?
ex:
[2020-12-08 08:16:58] HTTP (SteamCache,171) - cache23-iad1.steamcontent.com (162.254.192.14:80 / 162.
254.192.14:80, host: cache23-iad1.steamcontent.com): Received 0 (Invalid) HTTP response for depot 620
981
Somewhat amusing and possibly related is this broken garbage from akamai
[%] host steamcdn-a.akamaihd.net 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
steamcdn-a.akamaihd.net is an alias for steamcdn-a.akamaihd.net.edgesuite.net.
steamcdn-a.akamaihd.net.edgesuite.net is an alias for a1843.g1.akamai.net.
a1843.g1.akamai.net has address 23.204.152.169
a1843.g1.akamai.net has address 23.204.152.150
[%] host a1843.g1.akamai.net 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
a1843.g1.akamai.net has address 184.50.238.179
a1843.g1.akamai.net has address 184.50.238.202
[%]
Goodluck finding anyone at cloudflare or Valve but neither the glue nor direct are "correct". First is hijacked by Zayo, second is Telia.
Since a1843.g1.akamai.net.0.1.cn.akamaitech.net is correct that would mean someone did it intentionally. Google (8.8.8.8), is also correct.
tl;dr some fuckery Vale might want to follow up on.
I've just noticed that with a recent Steam update this issue has been resolved, for reference here's the updated system information:
@kisak-valve looks like for whatever reason this behaviour has regressed again with both the stable and beta version of Steam on Linux.
The stable version with issues is:
The stable version of Windows client which doesn't exhibit these problems is:
So an update to this issue, looks like the trigger which causes the Adding cache type 'LANCache' on host to either work or not work in my case is 100% reproducible and related to IPv6 being disabled on the interface in question.
So for clarity if either of the following are set to 1 (replace lan0 with the name of your interface):
cat /proc/sys/net/ipv6/conf/all/disable_ipv6
0
cat /proc/sys/net/ipv6/conf/lan0/disable_ipv6
0
When IPv6 is enabled (set to 0) the LANCache cache type is added and http fallback works without any issues.
Question for Valve: Is this expected behaviour? At this stage I'm assuming because the LANCache is added as an IPv6 to IPv4 address so perhaps IPv6 is required for this to function properly?
@h1z1 it would be good for you to also test and confirm the behaviour I've documented.
I've personally tested this on two completely different LANCache stacks with different server and client OSes with success.
Hey guys, i would like to add on this as i am having issues with lancache and a steamdeck-like container.
So the container i am using is this one https://docs.linuxserver.io/images/docker-steamos which is a new one by linuxserver.io and i have it configured to use my lancache which it does correctly. Using "dig lancache.steamcontent.com" for example returns the correct ip of the lancache container i am running, though running steam i dont see any entries in the /data/logs/access.log file, so the steam client seems like its completly ignoring lancache here. I assume its because of the steam client, not because of lancache (because lancache is working correctly with windows and other things, just not linux).
I also made sure to check the information provided by nightah and fir nem /all/disable_ipv6 returns 1 while /eth0/disable_ipv6 returns 0 which should work if i understood that correctly?
I've been having issues with recently installed (ubuntu 24.04 LTS and Fedora 38/39/40) steam clients , they dont appear to be looking for lancache.steamcontent.com.
I can use my pihole to wildcard all A record look ups for *.steamcontent.com to my lancache server, but that wont cache anything when its only using HTTPS mode (based on the content_log.txt for steam client) .
My older installs of steam still use HTTP when talking to my lancache, so content they pull down does get cached.
Getting steam to change to HTTP mode hasnt been easy or repeatable.
I have discovered that the Steam client only looks up lancache.steamcontent.com if IPv6 is enabled on my system.
When IPv6 is enabled, in ~/.steam/steam/logs/content_log.txt it shows:
[2025-05-24 20:44:00] Enabling local content cache at '::ffff:a0a:a0c' from lookup of lancache.steamcontent.com.
[2025-05-24 20:44:00] Adding cache type 'LANCache' on host '::ffff:a0a:a0c'
If IPv6 is disabled, this lookup doesn't occur and Steam connects directly to external CDN servers, completely bypassing the Lancache.
I've confirmed this issue is exclusive to Steam - other game launchers correctly use the Lancache regardless of IPv6 being enabled or disabled.
This behavior is counterintuitive since Lancache typically works most reliably when using only IPv4. The DNS resolution for lancache.steamcontent.com correctly returns my Lancache server's IPv4 address, but Steam only performs this lookup when IPv6 is enabled on the system.
On a system with IPv6 enabled (but not with my router configured to do DHCP for IPv6), if I add an IPv4 entry for lancache.steamcontent.com to /etc/hosts, I can get things working. Steam then sees the DNS entry I have in my DNS server for lancache.steamcontent.com as ::ffff:a00:fa, which is just the IPv4 address encoded in IPv6.
I adjusted my DNS server to filter out AAAA records and things are working on my linux desktop, but not on my Steam Deck. I think that's more to do with the Steam Deck than anything else.
Similar to others, I just configured LANCache with IPv6 instead of forcing IPv4, and that worked too.
Even using IPv6 doesn't seem to be fixing it for my SteamDeck. I hope they can fix this with the release of the GabeCube if it's related to SteamOS, otherwise that's gonna get a ban from LAN events.
I have had to enable (and setup) ipv6 on my lan just so steam deck would use my lancache server. Just turning it on in the network config doesnt work.
Can confirm that just enabling ipv6 on the device is enough to get my Linux clients working. I do not have ipv6 configured on my LAN and lancache had only ipv4 dns entry.
This worked for 2 separate Linux machines, one running SteamOS and another a different arch based distribution. Simply change ipv6 from disabled to automatic in the KDE network setting and apply- Lancache worked straight away.
I want to say a big thanks for posting this info above, I spent a day trying to troubleshoot this and would never have thought to enable IPv6!! THANK YOU!
With the increase in public events/LAN parties + the rise of the steam machine/SteamOS deployments -- what else is needed to start working on this issue from the dev side? Seems isolated to just the linux builds across multiple distro's regardless of overrides that can be applied.
Nothing extracted yet.
Your system information
System Information
Please describe your issue in as much detail as possible:
I have a local content cache setup and it appears that when running Steam in Linux, some download regions do not perform the required http fallback to ensure content is pulled from said cache.
lancache.steamcontent.comDNS entry has been poisoned to an RFC 1918 address (10.10.10.200) in my instance.I can see both in my Steam
content_log.txtand cache server logs that some of the chunks are still being retrieved over https.I successfully tested pulling down some chunks through my browser to ensure that the issue is not related to specific CDNs only allowing access on https/port 443 and having http/port 80 blocked.
Given that I also have a Windows dual boot I attempted the same tests on Windows, it seems that the Windows Steam client does not have any issues performing http fallback irrespective of the CDN, the following entry also are in the
content_log.txtwhen running from Windows:I have also observed with my testing that changing the Download Region in the Steam Settings will result in some regions performing appropriate http fallback, however the fallback appears to be dependent on specific hosts.
For example the following regions result in no http fallback and all content is sourced over https:
cache1-mel-aubb.steamcontent.com,cache2-mel-aubb.steamcontent.com,steamcdn-a.akamaihd.net)cache1-per-edgx.steamcontent.com,cache2-per-edgx.steamcontent.com,steamcdn-a.akamaihd.netThe following regions result in intermittent http fallback:
cache1-syd1.steamcontent.comcache2-syd1.steamcontent.comcache3-syd1.steamcontent.comcache1-mel-aubb.steamcontent.comcache2-mel-aubb.steamcontent.comcache1-per-edgx.steamcontent.comcache2-per-edgx.steamcontent.comsteamcdn-a.akamaihd.netcache1-syd1.steamcontent.comcache3-syd1.steamcontent.comsteamcdn-a.akamaihd.netcache1-mel-aubb.steamcontent.comcache2-mel-aubb.steamcontent.comcache1-per-edgx.steamcontent.comcache2-per-edgx.steamcontent.comsteamcdn-a.akamaihd.netcache3-syd1.steamcontent.comcache1-per-edgx.steamcontent.comcache2-per-edgx.steamcontent.comsteamcdn-a.akamaihd.netgoogle.cdn.steampipe.steamcontent.comsteamcdn-a.akamaihd.netsteampipe.akamaized.netEDIT/TLDR: I've just noticed that there are no entries in the Linux Steam clients
content_log.txtfor Enabling local content cache like the Windows client, instead I'm getting something like this:Does the Linux client not support this feature?
Steps for reproducing this issue: