TCPFit 调优脚本实测样本留档

【数据补充】给 Tcpfit 原帖补一份 9 台机器的实测样本：4 台扫出拐点收益明显，5 台干净线路结果分享

fable 5 AI 分析仅供参考

原帖：【原创调优脚本】Tcpfit — 单线程 186 → 401 Mbps，动态 TCP 调优，优化线路机器通用一键开源脚本（作者 Kylin010，仓库 github.com/Kylin010/tcpfit）

近期正好对手里 9 台机器逐台做了一轮 TCP 栈调优（全部 sweep 扫描，其中 Gen2 一台做了完整的多链路前后对照），数据整理出来补充给这个帖子——多一份多机器样本，方便后来人对号入座判断自己的机器属于哪一类。先谢过作者开源：工具把改动集中在自己的专属文件里（/etc/sysctl.d/99-tcpfit.conf、qdisc systemd 服务等，不碰 /etc/sysctl.conf，改动前快照存 /var/lib/tcpfit/），并提供 rollback 一键回退——我们这轮没触发过回滚，但这个可逆设计让逐台实验的心理成本低很多，做得很规矩。

IP 脱敏说明：机器只保留 IP 前两段（如 191.222.*.*），完整 IP 不公开。

一、我们怎么跑的

每台机器同一个套路：先做基础调优（BBR + fq + 按实测 BDP 设缓冲区），再扫限速器拐点；扫出拐点的机器把出向整形压到拐点下沿并留档整形值，没拐点的不整形。命令语法以 README 为准（tune --role proxy --bw <标称> / sweep --peer <近端 iperf3> --nominal <标称> / shape --rate <值> / rollback；sweep 需要一个近端 iperf3 对端）。

前后对照的口径分两档，如实说明：Gen2（四条链路）+ 品川对照组做了完整的 36 站 + Cloudflare 25MB 样本背靠背对照（表见第四节）；其余机器为 sweep 结果 + 单流吞吐观察（USLA Pro 有量化的单流前后记录）。

时间：2026-08-08/09。9 台覆盖东京 ×4、洛杉矶 ×3（含 DMIT 美西）、西雅图 ×1、华东入口 ×1。

二、9 台 sweep 结果总表

机器	线路	sweep 结果	整形	效果记录
USLA Pro（`154.12..`）	洛杉矶	拐点 ~211M	196M	✅ 单流稳定化（有量化前后数据，见下节）
USLA 9929（`154.64..`）	洛杉矶	拐点 ~212M	197M	✅ 防丢包尖刺（整形后观察）
DMIT 美西（`179.255..`）	洛杉矶	拐点 ~497M	482M	✅ 防高负载丢包（整形后观察）
Misaka（`103.170..`）	东京	拐点 ~624M	609M	✅ 防超载丢包（整形后观察）
DMIT 品川（`191.222..`）	东京	782M 无拐点	未整形	➖ 作为 Gen2 对照组同测了 36 站前后
RFC（`23.249..`）	东京	741M 无拐点	未整形	➖ 无感（sweep 干净 + 抽测）
PO0（`115.159..`）	华东入口	789M 无拐点	未整形	➖ 同上
bugnet（`72.18..`）	西雅图	601M 无拐点	未整形	➖ 同上
V.PS Gen2（`45.89..`）	东京	755M 无拐点	未整形	➖ 有完整前后对照表，见下

一个值得分享的细节：同一家 DMIT，美西那台扫出 ~497M 拐点、品川 782M 干净——同商不同线的运营策略可以完全不同，所以确实像原帖说的，逐台扫一遍最靠谱，别按品牌想当然。

三、扫出拐点的 4 台：收益与原帖描述一致

USLA Pro 是最典型的一台：调优前单流在 4.5-5.75 MB/s 之间波动，sweep 扫出 ~211M 处的限速器拐点，整形到 196M 之后单流拉成 5.8 MB/s 的稳定直线——不去触碰限速器的惩罚逻辑，反而比顶着限速跑更快更稳。需要说明可比性：这与原帖同属"存在限速器"的场景，是方向上的同向佐证；但我们这台的收益体现在稳定化（46 Mbps 量级的单流），与原帖 186 → 401 Mbps 的吞吐倍增不在一个量级，不构成对其数值的复现。

另外三台整形值同样压在各自拐点下约 15M，档案记录的收益为防高负载丢包尖刺（整形后观察，这三台没有做量化前后对照）。对这一类机器，这个脚本解决的是真问题。

四、没扫出拐点的 5 台：数据如实分享

这部分不是给工具挑刺——README 里作者自己写了"瓶颈在国际链路而非端口时，整形不会带来提升"，我们的数据正好是这句话的多机器版佐证，贴出来帮大家建立预期。

V.PS Gen2 做了最完整的前后对照（四条链路 + 品川对照组，单连接/4连接聚合 Mbps，chatgpt.com TTFB）：

链路	调优前	调优后
Gen2 直出	387.0 / 776.5，103.1ms	363.9 / 629.7，101.6ms
Gen2→Zoro 家宽	312.2 / 381.6，114.2ms	305.6 / 384.7，123.0ms
Gen2→bugnet	155.9 / 366.7，360.5ms	136.0 / 362.8，366.8ms
Gen2→bugnet→163	49.4 / 60.4，726.9ms	49.8 / 59.8，712.2ms
（对照组）DMIT 品川直连	300.7 / 360.7，97.3ms	287.6 / 559.9，98.6ms

读法：单连接口径五条链路前后变化 +0.8% 到 -12.8% 方向不一（变化最大的 bugnet 跨太平洋链本身轮间方差就大）；聚合口径的大幅波动（-19%/+55%）是聚合指标自身的跨轮方差，不是调优造成的。结论就是"无系统性差异"——这台机器 sweep 755M 无拐点，默认栈本来就够用，符合预期。

给同样测出"无感"的朋友一个判断参考：这不代表脚本没用，代表你的机器不在它的目标病症里。sweep 干净本身就是有价值的信息——说明商家没有藏限速器，这台机器你可以放心跑。

五、几条使用心得（供后来人参考）

tune 和 shape 分开看：BBR+fq+缓冲区（tune）对长肥管道基本是白赚的，可以无脑上；整形（shape）一定要以 sweep 结果为准，无拐点不整形。
高峰掉速先看时段规律再动手：我们有台机器单连接平峰 352 Mbps、深峰 248 Mbps（-29%），次日晚高峰同时段的 TcpQuality 显示是移动骨干进京段拥塞（回程 54.8 Mbps、重传 6962 次）——限速器全天候存在、拥塞只在高峰出现，后者不在 TCP 调优的解决范围，开并发或换路由才有效（同机深峰 4 连接聚合 682 Mbps 反而是三轮最高）。
先排除客户端家宽段：本地到入口这段是瓶颈的话，服务端怎么调都体现不出来，容易误判"没效果"。
复测别只看一轮聚合：聚合方差大（上表 +55% 的对照组就是例子），看单连接中位数和长时间稳定性更靠谱。
sweep 需要近端 iperf3 对端，测完记得把 iperf3 服务端关掉，别留端口挂着。

六、一句话总结

先 sweep 再决定：有拐点，整形是刚需（4/9 台扫出拐点并完成整形，其中 USLA Pro 有量化前后数据、另 3 台为整形后观察）；没拐点，说明线路本身干净，留着 BBR+fq 就够了（5/9 台无拐点，Gen2 有完整前后对照佐证，与作者 README 的说明一致）。再次感谢 Kylin010 开源。