不想开系统代理,给 Steam 单独接了个代理
从没传进 WebHelper 的启动参数,到进程接管和独立转发,记录这次 Steam 网页代理的改造。
Steam 下载一直正常,社区却打不开。本机已经有 SOCKS5 8899 和 HTTP 8898 两个代理端口,但不想开系统代理,也不想为了逛一下社区把整台电脑的流量接进 TUN。
最初想省点事,给 Steam 快捷方式加上 --proxy-server 就结束。试了等号和空格两种写法,完整退出 Steam 再启动,结果都没看到代理参数传进 steamwebhelper.exe。
检查用的是这条命令:
Get-CimInstance Win32_Process -Filter "Name='steamwebhelper.exe'" |
Select-Object ProcessId, ParentProcessId, CommandLine
测试用的是 Steam build 1791918634。两种写法都没起作用,接下来改用进程代理。
网页交给 WebHelper,下载先别动
观察连接时,网页请求在 WebHelper 上,下载则能在 steam.exe 上看到。于是第一版只接管 WebHelper 的完整路径,把 steam.exe 明确排除。
这里用了免费开源的 ProxiFyre。它能拦下指定进程的连接,转交给本机代理。Steam 不需要知道代理端口,Windows 系统代理也可以继续关着。
第一轮接好以后,商店打开了,社区还是失败。同一个 SOCKS5 端口单独访问社区却能成功。顺着查下去,发现 Steam 已经在本机把社区域名解析成了异常 IP,转发器接到的也是这个 IP。
最后又加了一层独立 Mihomo,识别连接里的域名,再把请求交给上游。链路成了这样:
WebHelper → ProxiFyre → 本机 Mihomo → 已有代理
steam.exe → 原来的网络连接
这层 Mihomo 默认监听 127.0.0.1:18899,不开 TUN。界面里选 SOCKS5,就接 8899;选 HTTP,就接 8898。两个上游端口不会同时使用。后来本机迁移时旧实例还占着 18899,新实例改用了 18898。
这个工具不依赖 Clash。已有代理提供 SOCKS5 或 HTTP 端口,就可以填写地址和端口使用,不需要另装 Clash。目前支持 SOCKS5,不支持 SOCKS4,也暂不支持需要用户名、密码的代理。
工具自带一份独立的 Mihomo,用来转发和识别域名,会随程序一起启动。它和用户选择哪款代理软件没有绑定关系。
多这一层的原因和对照命令,单独写在了 DNS 排障那篇。
实际用起来,多了哪些麻烦
这套方案要安装驱动和服务,首次启用会弹出管理员授权。退出也多了一步:先恢复进程规则,再结束转发程序。
装好以后,平时只需运行原来的代理软件,再打开这个工具。地址和端口按自己的配置填写,SOCKS5、HTTP 都能选。
第一版测到商店、社区主页面都返回 200,也完成了一次约 7.33 MiB 的独立游戏下载。当时下载连接由 steam.exe 直接连向 CDN。测试没有靠“下载速度看起来正常”来判断,过程放在了下载验证记录。
WebHelper 发出的请求都会使用这套代理,包括它加载的其他页面和资源。
后来遇到了第一版管不到的事
商店和社区已经能打开了,《流放之路》却还是显示“当前地区不可用”。继续查连接记录,才发现 Steam 登录时仍在直连。第一版排除了 steam.exe,这部分自然没有用上代理。
1.1.0 为此加了一个默认关闭的会话选项,让 CM 登录连接使用代理,下载继续直连。实际遇到的上游规则和启动参数问题,写在了《流放之路》那篇。如果只是想恢复商店、社区访问,保持默认网页模式即可。