Steam Sign-In Works, the Game Does Not: Check Each Path

Launch Steam, sign in, and everything looks healthy until the game cannot find a session. Treat that as three separate network questions rather than one. The store and account screens, the content download and the game session can each reach different endpoints over different transports. Run these checks in order and stop at the first one that fails, because everything after it is a guess.

Step 1: confirm sign-in is the only thing that worked

Sign-in proves that the account reached the identity service with the credentials and any second factor the account requires. It says nothing about content delivery, and it says nothing about the game's own hosting arrangement. Write down which of the three operations you actually tested, since people routinely report a failed game after testing only the launcher.

Read the failure text before the network. A game that reports no servers available is telling you something different from a launcher that cannot reach the store. The two errors come from different layers and rarely mean the same thing. The distinction decides whether the next check is about name resolution, about UDP, or about a region setting.

Record the account, the region, the game and the time. Without those four values, a later comparison is between two different tests that happen to share a name.

Step 2: name the transport for each operation

Content delivery behaves like a large HTTP transfer, and it tolerates latency far better than it tolerates loss. Matchmaking and in-game sessions often use UDP, where a path that drops packets looks like a broken game rather than a slow download. Those two profiles fail differently on the same tunnel, which is why a fast download does not predict a working session.

Check the destinations and the sockets in flight rather than the vendor port list first. The list tells you what the platform may use, while the sockets tell you what this client is doing right now.

nslookup api.steampowered.com
ss -uanp | head -20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://store.steampowered.com/

If the game process holds a UDP socket with traffic on it while the transfer path is fine, the failure is in the UDP leg. That narrows the problem to the tunnel's handling of UDP rather than to the account or the store.

Step 3: check the inclusion policy before the port list

Many VPN clients apply policy per application, per address range or per address family rather than to the whole machine. A launcher can be inside the tunnel while a separately launched game binary is outside it, and the two then disagree about the world. Application-level inclusion is the usual culprit on gaming laptops with a vendor client installed. Read the policy that is actually in force, not the profile you saved last month.

Look at the route table and the interface that owns the default route. A split-tunnel rule based on destination prefixes will show up there, and an application-level exclusion will not. That difference is worth knowing before you change either one.

ip route show default
ip -brief addr
Get-NetAdapter | Select-Object Name, Status, InterfaceDescription

If the game's traffic leaves through the physical adapter while the store goes through the tunnel, the inclusion policy is the finding. No port exception will fix a routing decision, and adding one only widens the surface.

Step 4: rule out a SOCKS path that cannot carry UDP

Tor provides a SOCKS proxy, and SOCKS support across the ecosystem is inconsistent about UDP. Tor's documented behaviour does not implement UDP ASSOCIATE, so a game whose session traffic is UDP cannot use that path no matter how the client is pointed at it. A browser that works through the proxy proves only that the browser's TCP flows work.

Test the claim rather than the intention. If the game still reports an unavailable session while a TCP-only test through the same proxy succeeds, the proxy path is not carrying the traffic the game needs.

Treat a routed VPN and a SOCKS proxy as different tools with different capabilities. Swapping one for the other is a design change, not a configuration preference.

Check the record against the agreement

Network reachability and account permission are separate questions, and only the first one is answered by a working tunnel. The restriction is about the intent behind the proxying rather than about the protocol you selected. The agreement in force limits IP proxying whose purpose is to disguise where the account holder lives, so a path that works may still sit outside the terms you accepted. Read the agreement rather than treating connectivity as approval.

For an honest comparison, change one variable at a time and keep the same game, server region, account and operation. Then check the outcome on the same four operations you recorded at the start.

tracert -h 12 store.steampowered.com
ss -uanp | grep -i -E 'game|steam'
curl -sS -o /dev/null -w '%{remote_ip} %{time_connect}\n' https://store.steampowered.com/

When the record shows sign-in working, the download working and the session failing, the remaining question is about UDP on the path. When all three work, the original complaint was about something else, and the next useful step is the game's own log rather than the tunnel. Either way, the checklist has replaced an argument with a specific observation.