Steam takes very long to start, failed to connect to websocket

[peacememories]

Your system information

• Steam client version (build number or date): 1714854927
• Distribution (e.g. Ubuntu): Ubuntu 24.04
• Opted into Steam client beta?: No
• Have you checked for system updates?: Yes
• Steam Logs: not available right now, I can post them when I next start steam, but the extract below should be the relevant information
• GPU: AMD Radeon 7900 XTX

Please describe your issue in as much detail as possible:

Recently when starting Steam, the tray icon appears immediately, but using any of the menu items does not work, and the Steam client does not appear.

Sometimes the client does appear after waiting for several minutes. I am not sure If this is always the case and I just was not patient enough most of the time.

When launching from the console it outputs this after hanging:

src/steamUI/webuitransportcontroller.cpp (206) : Failed to connect to websocket

This seems to me like something tries to connect to a websocket and the interface only continues initializing after the connection timeouts.

After appearing the interface does seem to work normally, so I am not sure what kind of websocket connection is failing.

This might be connected to #9658, but the problem started very recently for me and the mentioned issue seems to be a lot older.

Steps for reproducing this issue:

1. Start steam
2. The interface does not appear
3. Try to click on the tray icon and select "Library
4. The interface still does not appear
5. Wait for several minutes
6. The interface appears

[kisak-valve]

Hello @peacememories, can you check if this is the same issue as discussed on #9383?

[usersteamdebian]

I have the same problem, since the last update it doesn't work well.
I tried uninstalling and purging ~/.steam/ ~/.steampath ~/.steampid but the problem persists

Your system information

Steam client version (build number or date): 1714854927
Distribution (e.g. Ubuntu): Debian GNU/Linux 12 (bookworm) (64 bit)
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
Steam Logs: logs.zip
GPU: Radeon Vega 6

[YoinkerBoinker]

Same issue. I also reported another issue which seems pretty much the same thing (The behaviour is the same - really long dealys till it somehow seems to "refresh" itself). See #10853 I think the issue with the start might be related to that small popup that sometimes shows up when starting steam to inform you about new offers/releases.

I checked he issue kisak-valve shows but i don't have a igpu since this is on 5700x3d / Rx7700 XT

[UrsusLvovich]

I had a similar issue, started last tuesday for me. I guess when Steam had their last maintenance. When trying to open with the icon, the steam logo would show up in the task tray. But the main window wouldn't show up. I was able to still launch games by clicking the icon in the task tray though.
I then tried to run steam with sudo from the terminal. It did some update and the steam store actually came up this time. I thought I had resolved the issue, but trying to launch steam normally still resulted in the same behavior as before

[OdinVex]

I have the same issue with extremely stupidly long startup times (15 ****ing minutes on 16C32T@4.5GHz 64GB DDR4 4x2TB NVMe RAID0, so it's NOT my ****). I've resorted to starting steam in a shell and spamming Ctrl+C sporadically terminating crap in the background it attempts to launch, it can speed up my startup times. Do it enough and you'll notice patterns around that plagueware of Chromium underneath and the entire websocket garbage. Edit: I despise this new UI so much. I miss the old Steam UI, functional and fast (aside from DPI issues and rasterized images). My frustration with this stems from a year of this expecting better but getting the same no-dpi-slider crap.

Steam Version: 1715635533
Distro: Manjaro KDE (64 bit) Wayland
GPU: RX 5700 XT x 2

[wwmm]

I faced the same issue today. Steam's tray icon and the corresponding menu is in the system tray. But the window does not open. A curious workaround is disabling the internet connection before launching Steam. The window opens as usual this way without delay.

[wwmm]

I faced the same issue today. Steam's tray icon and the corresponding menu is in the system tray. But the window does not open. A curious workaround is disabling the internet connection before launching Steam. The window opens as usual this way without delay.

I think that the issue on my side may not be related to internet services. Having my xbox joystick plugged is what is actually making Steam's window to not be shown. Weird...

[fmorgner]

I am seeing a similar problem (on Arch). Checking the logs, I see the following in webhelper.txt:

[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: websocket connect retry: limit exceeeded, bailing - steamUI
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to re-connect to websocket after close
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: OnWebsocketReconnect: Failed to reconnect to steam client
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: websocket connect retry: limit exceeeded, bailing - clientdll
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to re-connect to websocket after close
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: OnWebsocketReconnect: Failed to reconnect to steam client
[2024-05-18 00:47:07] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-05-18 00:47:07] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
[2024-05-18 00:47:07] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-05-18 00:47:07] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state

The following part keeps repeating every couple of seconds:

[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state

[OdinVex]

Replying to #10879 (comment)

Same but Manjaro, my webhelper is filled with entries alike.

Edit: My DNS server protects clients by preventing DNS rebind (removes any local-addresses from DNS records, reports NX for domains). I added it to the allowlist, no change in Steam's behavior.

Edit: Steam isn't listening on 443, so I'm wondering how it's trying to capture that loopback. 443 is a privileged port anyway (<=1024), regular processes wouldn't be able to open it anyway.

Edit: Adding CAP_NET_BIND_SERVICE to steamwebhelper and steam (purely for the sake of testing) had no effect, not to mention steam isn't a binary.

Edit: This is also what causes games such as HMCC to hitch terribly keeping the FPS to maybe 1 frame per 30 seconds (HMCC calls some Steam APIs constantly in a blocking mode, made evident by patching steam_api to circumvent to test and suddenly vsync and fine).

Edit: A little poking around, this looks like IPC behavior. Chromium (the @!*%ty underneath of Steam's UI since they ruined it) uses IPC like this and it's just awful.

[peacememories]

Hello @peacememories, can you check if this is the same issue as discussed on #9383?

DRI_PRIME is not set on my machine, which makes sense since it's a desktop with only one, dedicated, GPU (the 5800x3d does not even have an IGP)

[RisaI]

This happens to me too, also tested with the flatpak version and steam-runtime.

Steam client version (build number or date): 1716584667
Distribution (e.g. Ubuntu): Arch Linux
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
Steam Logs: -
GPU: AMD Radeon 7900 XTX

[OdinVex]

To help establish how long this issue has existed...it's been this way since the UI revamp. That long. -_- I've figured out that starting Steam in a shell and then waiting until after it initializes Vulkan to constantly spam Ctrl+C helps. Each call to the CEF's IPC like that needs a Ctrl+C. I can select a new game and wait ages for it to "load" the library details or I can alt-tab and Ctrl+C the shell and the library details instantly load. @!Q# Chrome/Chromium and CEF. This 'web browser as software' ^%#* should be outlawed. Edit: The Ctrl+C technique works for nearly everything, even for right-clicking the Steam icon to exit. Right-click and wait forever or right-click, alt-tab to the shell and Ctrl+C, bam instant menu. It even helps Steam shut down faster.

[OdinVex]

I tried setting ip_unprivileged_port_start to 1 (just for testing), no go. Steam doesn't open 443 and I disabled httpd beforehand so nothing would be bound or listening on 443, but no go. This loopback way of doing stuff is broken.

[RisaI]

@OdinVex Interestingly enough, Steam works just fine on my laptop with an almost identical Arch installation. I wasn't able to isolate anything yet though.

[oliverlynch]

Also experiencing this issue on EndevourOS, Steam takes over a minute to launch, CS2 is unplayable with massive frame rate drops every few seconds. I collected logs based on this request, which seems to be relevant to this issue.

Logs & System information: Gist

It looks like steam generated a dump file at launch, if that is useful I can upload it.

[RisaI]

After spending some minutes staring at lsof output, I realized Steam was somehow using my work-related loopback hostnames I had defined in /etc/hosts. After I removed those, the issue went away as well as other Big Picture issues including the startup intro being transparent and the escape menu not working.

[OdinVex]

After spending some minutes staring at lsof output, I realized Steam was somehow using my work-related loopback hostnames I had defined in /etc/hosts. After I removed those, the issue went away as well as other Big Picture issues including the startup intro being transparent and the escape menu not working.

Nothing funky in my /etc/hosts. Shouldn't matter anyway so long as none are 'steamloopback.host'. Issue still exists.

[RisaI]

I've further narrowed it down to Steam having problems with loopback hostnames containing hyphens. By appending /etc/hosts with:

127.0.0.1 te-st

I've been able to reproduce the issue on previously unaffected machines. Replacing te-st with test makes Steam work well again.

@OdinVex try to run lsof -c steam while Steam is running and watch out for similar lines:

steam     359053 USER  42u     IPv4            2732420       0t0      TCP te-st:57343 (LISTEN)

[OdinVex]

I've further narrowed it down to Steam having problems with loopback hostnames containing hyphens. By appending /etc/hosts with:

127.0.0.1 te-st

Valid host names are a-z9-0 and -. If CEF/Steam has an issue with that then Steam is the problem. I use IPv6, so there's no way I can remove the IPv6 loopbacks. I'm not going to, either. CEF needs to go. Steam should just use something cross-platform like Qt.

Edit: To hammer this home:

# Standard host addresses
127.0.0.1  localhost
::1        localhost ip6-localhost ip6-loopback
ff02::1    ip6-allnodes
ff02::2    ip6-allrouters

These are stock, minimal entries when using IPv6. It's going to have dashes because it's valid.

Edit: This also an older hosts file. Newer ones (depending upon distro) have even more dash-containing entries. Note: https://gist.github.com/ghoneycutt/e531984406b4b86ace687ea8958a6dc3

Edit: lsof -c steam didn't provide anything useful on my end, just perfectly valid DNS:

steam     36796 <REMOVED>  42u     IPv4             116630       0t0         TCP localhost:57343 (LISTEN)
steam     36796 <REMOVED>  45u     IPv4             151016       0t0         TCP localhost:55613 (LISTEN)
steam     36796 <REMOVED>  74u     IPv4             116638       0t0         TCP localhost:27060 (LISTEN)
steam     36796 <REMOVED>  75u     IPv6             136738       0t0         TCP <REMOVED>.local:50531->[2602:801:f002:101::a2fe:c00e]:http (ESTABLISHED)
steam     36796 <REMOVED>  76u     IPv4             136650       0t0         TCP <REMOVED>.local:63995->a23-48-99-150.deploy.static.akamaitechnologies.com:http (ESTABLISHED)
steam     36796 <REMOVED>  77u     IPv4             152929       0t0         TCP localhost:52999 (LISTEN)
steam     36796 <REMOVED> 107u     IPv4             121601       0t0         TCP localhost:52999->localhost:55716 (ESTABLISHED)
steam     36796 <REMOVED> 108u     IPv4             116686       0t0         TCP <REMOVED>.local:62239->a23-210-138-105.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
steam     36796 <REMOVED> 109u     IPv4             153863       0t0         TCP <REMOVED>.local:57637->162-254-199-181.valve.net:27031 (ESTABLISHED)
steam     36796 <REMOVED> 110u     IPv4             134575       0t0         TCP localhost:55613->localhost:59616 (ESTABLISHED)
steam     36796 <REMOVED> 112u     IPv4             153860       0t0         TCP <REMOVED>.local:56697->162-254-199-163.valve.net:27035 (ESTABLISHED)
steam     36796 <REMOVED> 115u     IPv4             153861       0t0         TCP <REMOVED>.local:64847->162-254-199-163.valve.net:https (ESTABLISHED)
steam     36796 <REMOVED> 116u     IPv4             121598       0t0         TCP localhost:52999->localhost:51848 (ESTABLISHED)
steam     36796 <REMOVED> 117u     IPv4             134573       0t0         TCP localhost:55613->localhost:61278 (ESTABLISHED)
steamwebh 37141 <REMOVED>  28u     IPv4             159849       0t0         TCP localhost:51848->localhost:52999 (ESTABLISHED)
steamwebh 37141 <REMOVED>  29u     IPv4             159851       0t0         TCP localhost:61278->localhost:55613 (ESTABLISHED)
steamwebh 37141 <REMOVED>  31u     IPv4             145628       0t0         TCP localhost:59616->localhost:55613 (ESTABLISHED)
steamwebh 37141 <REMOVED>  34u     IPv4             145629       0t0         TCP localhost:55716->localhost:52999 (ESTABLISHED)

Edit: Interestingly enough, lsof does seem to pause for quite a while just before it displays a first TCP entry for any software.

Edit: Removed all entries except host name (has no dashes) and localhost, no change, still crap performance.

[cpmiller]

Arch Linux, up-to-date.

Adding a +1 to Steam not handling hyphenated hostnames. I've been experiencing the same startup patten described here. My hostfile looked exactly like this (EAC Workaround provided by https://github.com/starcitizen-lug/lug-helper for Star Citizen)

# Static table lookup for hostnames.
# See hosts(5) for details.

127.0.0.1 modules-cdn.eac-prod.on.epicgames.com #Star Citizen EAC workaround

Added a # to comment out the EAC line and Steam starts right away.

[OdinVex]

A Steam friend of mine that does not experience this bug and is on Arch-based distro like me sent me their hosts file, contains dashes. Dunno why some people would have issues and others wouldn't. I removed all dashes, problem still exists. They have dashes, no issue. (Edit: In short, I don't think it's dash-related. Maybe lookup-related or something, but not particularly about dashes.)

[gtdm]

Gentoo here. Removing dashes from /etc/hosts fixes the issue for me too. I also noticed that the "Waiting for network...", "Logging in..." and "Loading user data..." screens only show up after removing the dashes in /etc/hosts.

[OdinVex]

For anyone else having this issue that uses external DNS (eg. no system caching because caching can be problematic or for DNS sinkholing to protect your systems/networks) you've probably disabled the $*%&show that is systemd-resolved and have NetworkManager alone doing its thing. Even though getaddrinfo will work correctly...Steam won't. You'll have to re-enable the freakshow systemd-resolved. My guess, Steam or something it depends upon reads resolv.conf directly instead of obeying. See https://wiki.archlinux.org/title/Systemd-resolved#DNS for more details. (Edit: I won't use ResolveD, has no business existing.)

[fmorgner]

I'm not running systemd-resolved on any of my systems but my laptop (same OS as my main machine) does not exhibit the slow startup/reaction time of steam. I experimented with the NSS config of my main machine, and going from mdns to mdns_minimal seems to have resolved the slow down on that specific machine.

[OdinVex]

I'm not running systemd-resolved on any of my systems but my laptop (same OS as my main machine) does not exhibit the slow startup/reaction time of steam. I experimented with the NSS config of my main machine, and going from mdns to mdns_minimal seems to have resolved the slow down on that specific machine.

Interesting. I disabled systemd-resolved and switched to minimal, working.

[DiegoGiovany]

same erros using crossover 24 on macos, tried wineskin, whisky and vanilla wine, everything with same results....

==> /Users/diego/Library/Application Support/CrossOver/Bottles/Steam-2/drive_c/Program Files (x86)/Steam/logs/webhelper.txt <==
[2024-06-24 19:24:56] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: websocket error
[2024-06-24 19:24:56] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-06-24 19:24:56] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
[2024-06-24 19:24:56] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-06-24 19:24:56] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state

[OdinVex]

I narrowed down the reason for mine a bit more, to avahi and/or mdns/_minimal combined, having nothing to do with systemd-resolved (that simply got avahi re-enabled which was a false lead on systemd-resolved):

If I disable avahi-daemon it's fine. If I enable avahi-daemon and set mdns to mdns_minimal it's fine. If I enable avahi-daemon but leave it as mdns the issue suddenly presents.

Edit: I always disable DNS caching and never have anything open on 53, I don't allow any hosts to cache DNS responses in my network, just my DNS servers do that (and they also handles mDNS). I wonder if Steam developers are assuming something about mDNS or DNS caching?

[fmorgner]

I don't think it's entirely on Steam. The only difference between mdns and mdns_minial is that mdns_minimal will only ever try to resolve .local domain names. I experimented with calling avahi directly to try to resolve steamloopback.host, which took multiple seconds to fail the first couple of times. Afterward, avahi seam to have cached the result of it not resolving and it started to fail faster.

Additionally, I tried adding an entry to /etc/avahi/hosts for steamloopback.host which seemed to have resolve the issue in a way that Steam was "fast" again with mdns instead of mdns_minimal. However, after a few restarts of Steam, it became slow again, which was only fixed by going back to mdns_minimal.

It seems to as though there is some strange interaction happening in the name resolution logic of avahi, in that it should not take seconds to conclude that a .host name does not resolve via mDNS. I have yet to scour the relevant RFCs though, so I'm not sure if trying really hard to resolve a .host name is according to spec. Something for the weekend ;)

(On a side note: I may try moving files up in the NSS stack and put an entry in there for steamloopback.host, maybe that would work too. Don't get me wrong, I'm not arguing that this would be an acceptable solution to this problem, but neither is having to fall back onto mdns_minimal)

[OdinVex]

...

Using plagueware like CEF masquerading 'web apps' as software and requiring a loopback host to begin with is the root of this issue, let alone considering some firewalls/DNS servers have options to prevent DNS rebind attacks/leaks by removing/refusing/rewriting/dropping DNS with private-IP range responses, even for 127.0.0.0/8 responses.

[mattaw]

I want to add that after switching hosts in /etc/nsswitch.conf from mdns to mdns_minimal steam starts right up. Before then I had a large delay, and the websocket warnings.

[another-username2]

I have the same issue with extremely stupidly long startup times (15 ****ing minutes on 16C32T@4.5GHz 64GB DDR4 4x2TB NVMe RAID0, so it's NOT my ****). I've resorted to starting steam in a shell and spamming Ctrl+C sporadically terminating crap in the background it attempts to launch, it can speed up my startup times. Do it enough and you'll notice patterns around that plagueware of Chromium underneath and the entire websocket garbage. Edit: I despise this new UI so much. I miss the old Steam UI, functional and fast (aside from DPI issues and rasterized images). My frustration with this stems from a year of this expecting better but getting the same no-dpi-slider crap.

Steam Version: 1715635533 Distro: Manjaro KDE (64 bit) Wayland GPU: RX 5700 XT x 2

I agree. JS on the desktop is inappropriate and a technically uninformed decision.

Though, I do admire Valve for being so... determined... as to make a thoroughly bad idea work as it does and ignore all the bright-red, illuminated flags.

I wonder if Steam developers are assuming something about mDNS or DNS caching?

Apparently, assumptions abound. It seems nobody thought enough about checking return values, either.

I may try moving files up in the NSS stack and put an entry in there for steamloopback.host, maybe that would work too. Don't get me wrong, I'm not arguing that this would be an acceptable solution to this problem, but neither is having to fall back onto mdns_minimal

When working knowledge disappears, workarounds become the 'fix'. It's pathetic and scary how commercial software is produced.

Interesting. I disabled systemd-resolved and switched to minimal, working.

If you have to reconfigure your system and network because of someone else's ignorant oversight, something has gone very wrong with both software development AND troubleshooting.

Appendix: OK, so... the host name steamloopback.host resolves to 127.0.0.1...
So, just in case I am missing something isn't 127.0.0.1/8 a standard IP address in the TCP/IP stack of, like, EVERY computer in existence??? Did Valve have to use another DNS record to point to 127.0.0.1 instead of simply using 127.0.0.1... Anyone else think they've walked around the block to go upstairs?

[OdinVex]

@another-username2, Preach brother!

I've updated the Arch Wiki's Steam troubleshooting subsection to reflect this issue. https://wiki.archlinux.org/title/Steam/Troubleshooting#Very_long_startup_and_slow_user_interface_response

[Not-Zero-Blank]

I've further narrowed it down to Steam having problems with loopback hostnames containing hyphens. By appending /etc/hosts with:

127.0.0.1 te-st

Valid host names are a-z9-0 and -. If CEF/Steam has an issue with that then Steam is the problem. I use IPv6, so there's no way I can remove the IPv6 loopbacks. I'm not going to, either. CEF needs to go. Steam should just use something cross-platform like Qt.

Im speechless thats just unprofessional

[OdinVex]

Im speechless thats just unprofessional

No one's paying us to debug Steam's problems. CEF itself is unprofessional. Masquerading a 'web app' as a desktop software is an unprofessional cop-out, especially since it's come at everyone's expense with massive buttons and underutilized space, poor layouts and 'trending/upsell/DLC' thrown in your face with unwanted "news" and a crappy experience. Uses more RAM, more resources, slower access, list goes on. Don't bother mentioning unprofessional because this is as good as it gets for what it is.

Edit: Not to mention that undoing 35+ years of a standard for naming machines just to appease a bug? No. This should never have happened, but it did. Fine. The problem is the lack of a fix after SO damn long and THIS (Steam client) is what we're left with. That's unprofessional.

[akrychowski]

On fedora 40 affected by this problem, removing the 127.0.0.1 view-localhost in hosts helped.