MSS 规则在路由器上有效，却漏掉了 Squid

管理员在 FORWARD 上加了 TCPMSS 钳制。直接路由的流量有所改善，但经由本机 Squid 实例的下载仍然卡住。代理与网站之间的连接，并不是客户端的 TCP 连接原样穿过那条链。

在普通的终止型正向代理中，面向客户端的那条连接在本地结束。代理会向源站或父代理 另开一条 TCP 连接。在 Linux 上，为这条连接生成的数据包走本机输出路径。

因此，只管 FORWARD 的规则可能完全正常，却抓不到它本想调整的那次握手。选择挂载点之前，先把真实连接和 SYN 的方向画清楚。容器或独立命名空间还可能多出一段路由，所以正确位置取决于进程在哪里运行。

不要把 PMTU 的数字直接塞进 MSS

路径 MTU 是 IP 包的大小。TCP MSS 描述的是 TCP 载荷，必须把相关头部算进去。同样，ping 的载荷长度也不是完整的 IP 包长度。熟悉的 28 字节加项对应的是基本的 IPv4 ICMP echo 结构，并不适用于所有地址族或封装方式。

TCPMSS 目标记录了显式取值和 PMTU 钳制。钳制仍依赖路由的 MTU 信息；它既不能证明路径发现是健康的，也不能替代放行必要的 ICMP 报文。

还要把症状与理论对上。握手完成、随后在较大传输上停住，才值得去查包大小。反复没有回应的 SYN 或立刻 reset 需要更宽的解释；小包失败并不能证明数据段过大。

在记录里把可用的直连和失败的代理连接分开。即使在同一台机器上，两者的来源、路由和封装也可能不同。