本地HTTP代理比直连更快的原因探究及相关低速问题的调试咨询

看起来你遇到的这个问题挺有意思的——跨Windows 11和PS4两个设备，直连批量小HTTP请求的速度都远低于走本地tinyproxy的速度，而且浏览器测速又正常，这说明问题大概率出在小请求场景下的TCP交互特性或者链路层面的隐性限制上。结合你已经做的排查，我给你梳理几个更深入的调试方向：

1. 深挖TCP重传/重复ACK的具体原因 #

你已经通过Wireshark看到直连有大量重传和重复ACK，这是低速的核心表现，得搞清楚是丢包还是延迟导致的：

• 用Wireshark的过滤规则tcp.analysis.retransmission和tcp.analysis.duplicate_ack单独导出异常包，对比对应的SEQ/ACK编号：如果是重复ACK后触发的快速重传，说明是链路丢包；如果是超时重传（看你当前Initial RTO是1000ms，超时后才发起重传），说明是单向延迟过高。
• 对比代理模式的TCP流：代理和你的设备是局域网低延迟连接，而代理到目标服务器的连接可能复用了TCP长连接，跳过了每次请求的三次握手和慢启动。你可以统计直连和代理模式下的TCP连接数差异（Wireshark里看Statistics > Conversations > TCP），看直连是不是每个小请求都新建TCP连接。

2. 验证HTTP连接复用的影响 #

你的请求都是<1MB的小文件，TCP慢启动对这类请求的影响极大：

• 如果直连时你的软件没启用HTTP Keep-Alive，每个请求都要走三次握手、慢启动（初始窗口小，逐步提升速率），批量请求的话速度会被拖垮。而tinyproxy默认会开启Keep-Alive，复用和目标服务器的TCP连接，直接用满带宽。
• 你可以用curl做个快速测试：
  • 直连禁用Keep-Alive：curl -v --no-keepalive <你的目标小文件URL> -o /dev/null
  • 直连启用Keep-Alive：curl -v --keepalive <你的目标小文件URL> -o /dev/null
    对比两次的速度，如果启用Keep-Alive后速度接近代理模式，那问题就找到了。

3. 排查链路或服务器的TCP兼容性问题 #

跨设备出现同样问题，说明不是Windows单独的参数问题，可能是ISP或目标服务器的TCP限制：

• 临时调整Windows的TCP初始参数试试：
  • 降低初始RTO：管理员命令行执行netsh int tcp set global initial_rto=500，减少超时重传的等待时间
  • 切换拥塞控制算法：netsh int tcp set supplemental template=internet congestionprovider=ctcp，试试CTCP替代默认算法，看是否适配目标服务器的拥塞控制逻辑
• 用Linux设备直连目标服务器，用iperf3 -c <目标IP> -t 60测试单向带宽，同时抓包看TCP初始窗口大小，对比代理模式下代理到目标服务器的初始窗口，看是不是直连时初始窗口被限制了。

4. 检查DNS和路由路径差异 #

有时候DNS解析的节点差异会导致速度差：

• 对比直连和代理模式下的目标服务器IP：Windows上用nslookup <目标域名>，代理服务器上也执行同样命令，看是否解析到不同的CDN节点。如果代理解析到的是更近的节点，那速度差异就合理了。
• 对比路由路径：Windows用tracert <目标IP>，Linux代理用traceroute <目标IP>，看直连时有没有某个跳点延迟特别高（超过100ms）或者出现丢包（*号），这可能是ISP的链路瓶颈。

5. 反向验证代理的优化点 #

你可以临时修改tinyproxy的配置，去掉它的优化特性，看速度会不会降到直连水平：

• 打开tinyproxy的配置文件，把KeepAliveTimeout改成1，禁用连接复用；或者把MaxClients设为1，限制并发连接数，重启代理后测试速度。如果速度下降，说明代理的连接复用是核心优化点。

备注：内容来源于stack exchange，提问作者NeroP