判断TCP窗口瓶颈最有效方式是检查活跃连接rcv_wnd是否长期稳定在65535（64KB），并结合ss -i查看rcv_space是否被net.core.rmem_max截断、tcp_window_scaling与tcp_rmem设置是否匹配，以及三次握手时wscale选项是否双向协商成功。
直接看活跃连接的接收窗口是否卡在 64KB 附近，是判断 TCP 窗口是否成为瓶颈最快速有效的方式。
用 ss -i 观察实际窗口值
在宿主机或容器内执行：
ss -t -i 'dst <目标IP>'（例如 ss -t -i 'dst 10.10.10.20'）
重点关注输出中的 rcv_wnd（接收窗口通告值）和 rcv_space（内核为该 socket 分配的接收缓冲区大小）：
- 若
rcv_wnd长期稳定在 65535（即 64KB），基本可判定窗口缩放未生效或被限制 - 若
rcv_space明显小于你设置的tcp_rmem最大值（如设了 8MB 却只显示 256KB），说明被net.core.rmem_max截断 - 对比多个连接，看是否普遍存在该现象，排除单连接异常
验证窗口缩放是否真正协商成功
窗口缩放必须两端在三次握手时协商一致才起作用。仅服务端开启没用：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
抓取 SYN 包确认 wscale 选项存在：
tcpdump -i any 'tcp[tcpflags] & (tcp-syn) != 0' -nn -vv | grep -i wscale
- 看到类似
wscale 7表示客户端也支持并发送了缩放因子 - 若只有服务端 SYN-ACK 有 wscale，而客户端 SYN 没有，说明客户端禁用（如某些嵌入式设备、旧版 Windows 或 Android）
- 中间防火墙/NAT 设备剥离 TCP 选项也会导致协商失败
结合 RTT 和带宽估算 BDP 判断是否合理
窗口太小的本质是无法填满“带宽 × 往返时延”这个管道容量（BDP）。需实测并计算：
- 用 ping -c 4 <目标IP> 获取 RTT（取平均值，单位秒）
- 确认链路带宽（如网卡是 10Gbps = 1.25GB/s，或实测 iperf3 上限）
- 计算 BDP = 带宽（字节/秒）× RTT（秒）；例如 1Gbps + 50ms → 125MB/s × 0.05s ≈ 6.25MB
- 若当前
rcv_space远小于该值（如只有 256KB），就构成明显瓶颈
检查关键内核参数是否启用并匹配
窗口能撑开，依赖三个条件同时满足：
-
net.ipv4.tcp_window_scaling = 1：执行
sysctl net.ipv4.tcp_window_scaling确认返回 1 - net.ipv4.tcp_rmem 第三项 ≥ BDP：如 BDP 是 6MB，则第三项至少设为 8388608（8MB）
- net.core.rmem_max ≥ tcp_rmem 第三项：否则缓冲区上限被硬性截断
任意一项缺失或不匹配，都会导致窗口无法动态扩展，始终卡在默认或 64KB 封顶。
