Loading... # 实测让单线程 TCP 翻倍：开源一键调优脚本 Tcpfit 最近逛 NodeSeek 看到一个很有意思的项目——**tcpfit**，一个由作者本人（与 Claude 合作）写的一键式 TCP 调优脚本。它的卖点不是再塞一套"玄学"参数，而是**按每台机器实测数据去推导**最佳 TCP 参数，再用免费的 iperf3 节点自动跑测速。作者在自家全部优化机器上跑过之后才敢推荐，这个路子比较扎实。 项目开源在 GitHub：**Kylin010/tcpfit**，MIT 协议，截止本文共 71 个 star，仍在活跃更新。 ## 先说结论：效果怎么样 作者用一台 500Mbps 的 VMISS 9929 做了前后对比，我挑两组最有代表性的数据列出来。 **TcpQuality 综合测速（九节点均值）** | 对比项 | 回程 | 去程 | | --- | --- | --- | | 原厂内核 | 144.0 Mbps | 53.0 Mbps | | tcpfit 调优后 | **471.1 Mbps** | **76.1 Mbps** | | 提升倍数 | **3.27 倍** | 1.44 倍 | 单节点最高是上海电信：131.7 → **545.4 Mbps**。 **单线程 iperf3 测速** | 对比项 | 平均 | 峰值 | | --- | --- | --- | | 原厂内核 | 186.44 Mbps | 217.83 Mbps | | tcpfit 调优后 | **401.69 Mbps** | **485.72 Mbps** | 重点在于：**2.2 倍的提升，用的就是原厂内核，不换内核、不重启。** 去程只提升 1.44 倍是正常的——去程是国内往服务器发数据，发多快由国内那台机器说了算，服务器端只能控制接收窗口，所以去程天然不如回程吃改动。 ## 单线程为什么跑不满：卡在带宽×RTT 的天花板上 作者在 TcpQuality 的注释里看到一句话：以美西为例，"160ms 延迟 + 4M 发送缓存 = 理论单线程 200Mbps"。这台机器原厂发送缓冲恰好就是 **4M**，实测 RTT **164ms**，套进公式： `4 MB × 8 ÷ 0.164s ≈ 205 Mbps` 而原厂实测峰值 **217.83 Mbps**——说明它正是死死卡在这个由"发送缓冲 × RTT"算出的天花板上。 tcpfit 的逻辑是按"带宽 × RTT"把缓冲区抬到 **18.1M**，天花板一举抬到 949 Mbps，实测峰值也顺带冲到了 485.72 Mbps。这是很干净的数学题：带宽延迟积（BDP）算得准，缓冲区给够，单线程自然跑得动。 ## 脚本到底做了什么 原理分三块。 **一、基础调优。** 按"带宽 × RTT"算出 BDP，缓冲区给 2 倍 BDP，同时上限跟内存挂钩（不超过 TCP 全局预算的 1/8）。再叠上 BBR + fq 队列、起步优化（`slow_start_after_idle=0`、`initcwnd 32`）以及队列和连接相关参数，一共 32 项。 **二、限速器拐点探测。** 先不限速跑一次，找到拐点后留一点安全余量，用 **HTB 聚合限速 + fq 叶子 pacing** 把整形应用上去。 这里有个反直觉的点：**限速反而更快。** 作者用另一台 500M 机器实测： - 不限速：吞吐 481 Mbps，10 秒内重传 61,266 次 - 限到 530：吞吐 499 Mbps，10 秒内重传 5 次 限速器看的是瞬时速率。不加 pacing 的 TCP 是突发式发送，平均速率没超也会瞬间打穿上限、引发丢包；而 fq 的逐包 pacing 让发送节奏贴着真实上限走，几乎不丢包。重传从六万多骤降到个位数，吞吐反而更高，这是非常符合 TCP 原理的。 **三、回滚。** 首次改动前会自动存快照，记录全部 33 项参数的原始值。回滚也很简单： ```bash tcpfit rollback # 完整回滚 tcpfit shape --off # 只去掉整形，保留基础调优 ``` 所有改动落在以下位置，便于自查： ``` /etc/sysctl.d/99-tcpfit.conf /etc/systemd/system/tcpfit-qdisc.service /usr/local/sbin/tcpfit-qdisc.sh /etc/networkd-dispatcher/routable.d/50-tcpfit-initcwnd /etc/modules-load.d/tcpfit-bbr.conf /var/lib/tcpfit/ ``` ## 怎么用 一键安装： ```bash bash <(curl -fsSL https://raw.githubusercontent.com/Kylin010/tcpfit/main/tcpfit.sh) ``` 跑完出菜单，选 1 全自动，只问三个问题（是否使用免费节点、是否用内存限制、是否开启限速器）。装好后敲 `tcpfit` 就进管理菜单。 脚本自带 18 个免费 iperf3 节点（香港、新加坡、东京、悉尼、法兰克福、阿姆斯特丹、伦敦、洛杉矶、旧金山、西雅图、达拉斯、芝加哥、纽约、迈阿密、蒙特利尔等），会并发 ping 一圈自动挑最近的。有自己的另一台机器更好，在那边跑 `iperf3 -s` 把 IP 填进去即可，对端越近测得越准。 ## 流量和时间成本 拐点扫描要真跑流量，作者给了大概的用量： | 带宽档位 | 有限速器 | 没有限速器 | | --- | --- | --- | | 300M | 3.5 GB / 3 分钟 | 0.4 GB / 1 分钟 | | 500M | 8.8 GB / 4 分钟 | 0.7 GB / 1 分钟 | | 1000M | 22 GB / 4.5 分钟 | 1.5 GB / 1 分钟 | 它先只测一档判断存不存在限速器，没有就停手，不会瞎跑。速率超过 2500M 会提醒。如果想省事，菜单选 2 走"只要基础调优"，1 分钟搞定、几乎不耗流量。 ## 调不了的情况 作者也坦诚地说了边界：瓶颈在国际链路而非你的端口时，调服务器没用。典型表现是**不限速跑也不丢包，但到国内就是上不去**——脚本会报"未检测到限速器"，基础调优仍然生效，但整形那部分没有收益。 ## 小结 tcpfit 的核心思路值得肯定：不套用固定参数，而是先测这台机器、这条线路的真实 BDP 和限速拐点，再据此调。实测数据支撑也够硬——同一台机器、原厂内核，单线程 2.2 倍、回程 3.27 倍。对跑 VPS、优化线路、看视频卡顿的朋友值得一试。 - 源码（MIT）：https://github.com/Kylin010/tcpfit - 作者 TG 更新频道：https://t.me/Tcpfit - 讨论群：https://t.me/tcpfit_chat --- *本文改写自 NodeSeek 论坛同主题原创帖，经原作者 Kylin2333 发布。原文：https://www.nodeseek.com/post-865242-1* Last modification：August 9, 2026 © Allow specification reprint Like 如果觉得我的文章对你有用，请随意赞赏