Steam 登录正常，游戏不通：逐条检查路径

启动 Steam、登录，一切看起来正常，直到游戏找不到会话。把这件事当成三个独立的网络问题，而不是一个。商店和账户页面、内容下载以及游戏会话可能各自经由不同的传输方式访问不同的端点。按顺序做这些检查，并在第一个失败处停下，因为之后的一切都是猜测。

第1步：确认登录是唯一成功的一环

登录只能证明账户带着凭据和账户所需的任何第二因素到达了身份服务。它说明不了内容分发的情况，也说明不了游戏自身的托管安排。记下三项操作中你实际测试了哪一项，因为人们常常只测了启动器就报告游戏故障。

先读失败提示，再看网络。提示“无可用服务器”的游戏，和连商店都到不了的启动器，说的不是一回事。两个错误来自不同层次，很少同义。这个区分决定下一项检查是针对名称解析、UDP，还是区域设置。

记录账户、区域、游戏和时间。没有这四个值，之后的比较就是在两个恰好同名的不同测试之间进行。

第2步：为每项操作指明传输方式

内容分发像一次大型 HTTP 传输，对延迟的容忍远好于对丢包的容忍。匹配和游戏内会话常用 UDP，在这条路上丢包会表现为游戏坏掉，而不是下载变慢。这两种特征在同一条隧道上失败的形态不同，所以下载快并不代表会话能通。

先查目的地和在途套接字，而不是厂商的端口清单。清单说明平台可能用哪些端口，套接字说明这个客户端此刻在做什么。

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

如果游戏进程持有带流量的 UDP 套接字，而传输路径正常，故障就在 UDP 这一段。这把问题收窄到隧道对 UDP 的处理，而不是账户或商店。

第3步：在查端口清单之前先查包含策略

许多 VPN 客户端按应用、按地址段或按地址族应用策略，而不是对整个系统生效。启动器可能在隧道内，而单独启动的游戏可执行文件在隧道外，于是两者对世界的认识不一致。在装有厂商客户端的游戏本上，应用级包含通常是元凶。要读真正生效的策略，而不是上个月保存的配置文件。

看路由表和拥有默认路由的接口。基于目标前缀的分流隧道规则会显示在那里，而应用级排除不会。改任何一项之前，值得先了解这个差别。

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

如果游戏流量从物理网卡出去，而商店走隧道，那么包含策略就是结论。任何端口例外都修不了路由决策，加一条只会扩大面。

第4步：排除无法承载 UDP 的 SOCKS 路径

Tor 提供 SOCKS 代理，而整个生态对 SOCKS 的 UDP 支持并不一致。Tor 的公开行为不实现 UDP ASSOCIATE，所以会话流量是 UDP 的游戏，无论客户端怎么指向它，都用不了那条路径。浏览器能通过代理工作，只证明浏览器的 TCP 流能通。

要验证主张，而不是意图。如果通过同一代理只做 TCP 测试能成功，游戏却仍报告会话不可用，那这条代理路径并没有承载游戏需要的流量。

把路由式 VPN 和 SOCKS 代理当成能力不同的两种工具。把其中一个换成另一个是设计变更，不是配置偏好。

把记录与协议条款对照

网络可达性和账户权限是两个问题，只有前者能由一条能用的隧道回答。限制针对的是代理背后的意图，而不是你选择的协议。生效的协议限制的是以伪装账户持有人居住地为目的的 IP 代理，所以一条能通的路径仍可能落在你已接受条款之外。要读协议，而不是把连通性当成许可。

要做诚实的比较，一次只改一个变量，并保持同一游戏、服务器区域、账户和操作。然后在开头记录的同样四项操作上检查结果。

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/

当记录显示登录正常、下载正常而会话失败时，剩下的问题就是路径上的 UDP。当三项都正常时，最初的抱怨其实是别的事情，下一步有用的是游戏自己的日志，而不是隧道。无论如何，清单已经用一次具体观察取代了一场争论。