同一个代理，curl 能开 Steam 社区，客户端却打不开

给 WebHelper 接上进程代理后，商店恢复了，社区没恢复。代理端口没有填错：通过同一个 SOCKS5 端口单独请求社区，能拿到页面。

单独请求时，可以让代理去解析 steamcommunity.com。Steam 则先在本机查出了 IP，再连接过去。这个 IP 有问题，ProxiFyre 又原样把它交给了代理，社区于是一直打不开。

先把这两种请求摆在一起

遇到类似情况，可以用 curl 做下面的对照。这里使用 SOCKS5，不限定代理软件；把 8899 换成自己的 SOCKS5 端口：

curl.exe --noproxy localhost --socks5 127.0.0.1:8899 --connect-timeout 10 --max-time 25 -o NUL -sS -w "HTTP=%{http_code}\n" https://steamcommunity.com/
curl.exe --noproxy localhost --socks5-hostname 127.0.0.1:8899 --connect-timeout 10 --max-time 25 -o NUL -sS -w "HTTP=%{http_code}\n" https://steamcommunity.com/

第一条在本地解析域名，第二条把域名交给代理。这里写 curl.exe 是为了避开旧版 PowerShell 的 curl 别名；--noproxy localhost 则限定免代理名单，避免环境中的其他设置让测试请求绕开指定代理。参数说明见 curl 手册。

如果只有第二条成功，就值得查本地解析，以及上游对域名和 IP 是否用了不同规则：

Resolve-DnsName steamcommunity.com -Type A
Resolve-DnsName steamcommunity.com -Type AAAA

这里同时查 A 和 AAAA 记录，分别对应 IPv4、IPv6。Steam 也可能使用 IPv6 地址。

这次在转发时找回域名

最终没有给社区写死 hosts，而是在 ProxiFyre 后面加了一层独立 Mihomo。连接虽然只带着目标 IP 进来，TLS 等协议里仍可能看得到域名，可以用识别到的域名重新连接。

第一版的相关配置是：

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: true
  sniff:
    TLS:
      ports: [443]
    HTTP:
      ports: [80]
    QUIC:
      ports: [443]

parse-pure-ip 允许处理只有 IP 的连接，override-destination 让识别结果参与实际目标选择。Mihomo 文档有各项含义。上面只是配置片段，需要放进完整的转发配置里。

加上这层转发后，社区恢复了访问，系统 DNS 和原来的 Clash 设置都保留了下来。这种处理依赖连接中可见的域名信息；碰到识别不出域名的连接，还得另查。

修完以后，浏览器里那个 IP 仍然不对

社区主文档已经返回 200，页面标题是“Steam 社区”，加载完成，有 128 个链接，磁盘缓存标记也是 false。但调试记录里的 remoteIPAddress 仍显示原来的异常地址。

进程接管发生在浏览器看到的连接下面。浏览器记录的目标地址，和转发器最后实际连接的地址，可能不同。如果当时只看这一列，就会误以为修复没生效。

当时又核对了一遍页面内容和转发记录，确认社区已经正常加载。128 是那次页面里的链接数，后续页面更新时会变。

遇到同样的情况，可以先跑一下前面那两条 curl 命令。如果把域名交给代理后就能打开，排查时便可以先从本地解析查起。