Loading... 最近在折腾 VPS 网络调优，发现与其手动复制一堆 sysctl 参数，不如直接交给一个能 SSH 上机、能读现状、能跑测试、还能解释结果并保留回滚路径的 AI 智能体来做，比如 Codex、Claude Code、Hermes 这类支持终端操作的 agent。 原因很简单：中转机和落地机的调优逻辑完全不一样，100M、1G、10G 口的目标也各不相同。像 MTU=1440、TBF=1000Mbit、TCP buffer=256MB 这些参数都只是「候选值」，绝对不能当成万能答案直接套用。 ## 先说清楚边界 这套思路只适合调你自己名下的 VPS。别拿去测试、压测、扫描不属于你的机器。如果是生产节点，建议先只检查和测试，别让 AI 一上来就改配置。 ## 动手之前要准备什么 硬件性能、内核版本、网卡、sysctl、qdisc 这些信息不需要你手动整理，AI 登录后自己就能读出来。 **1. 配好 SSH alias** 建议先在本地 ~/.ssh/config 配好别名，之后给 AI 的目标就写 `ssh my-relay`、`ssh my-landing` 这种。千万别把私钥内容或云厂商后台 token 发给 AI。 **2. 准备测试对端** 至少准备一台对端机器，最好 3 到 6 台覆盖不同方向。每台对端要提供名称、IP 或域名、iperf3 端口、是否允许 ping、能否 SSH、角色（中转/落地/测试机/真实业务 peer）。对端上起一个 iperf3 server 即可：`iperf3 -s -p 25201`。如果有防火墙或云厂商安全组，记得放行测试端口。 **3. 说清业务链路** AI 需要知道流量到底怎么走，比如「用户 -> 日本中转 -> 日本落地 -> 目标网站」。别只说「帮我优化网络」——中转机和落地机的关键方向不同，AI 不知道链路就很容易优化错方向。 **4. 交代代理协议** 告诉 AI 你跑的是什么，比如 sing-box、xray、realm、gost、iptables/nftables DNAT 等。TCP 类协议直接受 BBR、fq、TCP buffer 影响；而 HY2、TUIC、QUIC 这类 UDP/QUIC 协议不吃 Linux TCP buffer，但仍会受 MTU、qdisc、出口 shaping 影响。 **5. 划定 AI 的权限边界** 每次都明确边界，比一句「你看着办」安全得多。例如：先只检查不改配置；允许逐个跑 iperf3；允许测 PMTU；不允许重启；不允许改 MTU；改 sysctl 前先给计划等我确认。 ## 默认优化目标 - 优先降低重传，而不是追求单次测速截图好看 - 优先优化用户关键方向（用户下载、落地出站、relay 到 landing） - 保持网页、视频、短连接的启动速度 - 避免过度 buffer 导致排队延迟 - 不从单个异常 peer 推导全局配置 - 每次只改有证据支持的参数 - 所有持久化配置必须能回滚 中转机重点看「流量从哪进、从哪出、瓶颈是不是本机出口」；落地机重点看「它是不是 TCP 终点或重新发起方、出站访问目标网站的路径是否稳定」。 ## MTU 不要靠猜 很多人喜欢直接把 MTU 改成 1440，有时候确实能绕开一些路径或封装问题，但它不是默认答案。更合理的判断顺序是： 1. 当前公网接口是不是 1500 2. 到主要 peer 的 PMTU 是否正常 3. 是否存在隧道、WireGuard、overlay、嵌套代理 4. 真实协议是 TCP 还是 UDP/QUIC 5. 是否有分片、黑洞、重传、QUIC loss 的证据 加密算法本身通常不改变底层 PMTU，真正改变载荷大小的是传输方式和封装层。 ## TBF/HTB 也不要靠猜 `TBF=1000Mbit` 对某些 1G 口机器可能刚好合适，但它仍然只是候选值。更好的做法是先找到「实测稳定上行」，再按 95%、90%、85%、80%、75% 做阶梯。选择标准不是「哪个测速最好看」，而是重传是否明显下降、qdisc drop/backlog 是否下降、用户关键方向吞吐是否还够、是否只影响弱 peer 而没有拖累健康 peer。 如果本机 qdisc 的 dropped 是 0、backlog 也不堆，但 iperf3 还是高重传，那更可能是路径、对端或上游拥塞——这时候全局限速可能只是把速度压低，并没真正解决问题。 ## 关于 TCP buffer TCP buffer 上限要根据实测的带宽时延积（BDP）、机器内存、角色和并发来算，不要靠加 buffer 去掩盖丢包。小水管 100M 中转机，保守的 buffer 上限通常就够；1G 中转/落地机在 RTT 和内存允许时 64-128MB 比较合理；高带宽高 RTT 的落地机，只有测试证明 BDP 确实是瓶颈时，128-256MB 才说得过去。关键不是数值本身，而是它有没有测量依据。 ## 落地机要分协议看 SS2022 TCP、VLESS REALITY TCP 这类连接，BBR、fq、TCP buffer、tcp_notsent_lowat 的影响更直接；HY2/TUIC/QUIC 走 UDP，不吃 Linux TCP buffer，但仍会受 MTU、出口队列和本机 CPU 调度影响。别拿 TCP iperf3 的结论硬套到 UDP 协议上。 ## 调优的落地流程 当 AI 获得改配置的许可后，按这个流程走：先解释计划并说明测量依据 -> 备份现有 sysctl 文件 -> 按角色写入 /etc/sysctl.d/ 下的统一文件（如 99-auto-tune-relay.conf）-> 保留有用的旧设置避免冲突 -> sysctl --system 生效 -> 确认 SSH 仍正常 -> 读回生效值 -> 重跑关键测试 -> 变差就回滚 -> 写一份 profile 记录角色、测试、选值、理由和备份路径。 ## 结语 中转机调优很容易误判，看到重传就加 TBF 不一定对，先看本机有没有真丢包，再看路径和对端。如果是多入口、多来源 IP、多 peer 且线路质量差异大的机器，固定 TBF/HTB 就不够用了，可以按端口、peer 或来源 IP 做动态调整——这属于更进阶的话题，留到下一篇再展开。 --- *本文由 NodeSeek 技术帖整理改写，原文链接：https://blog.ibytebox.com/posts/ai-agent-vps-tcp-tuning/* Last modification：August 9, 2026 © Allow specification reprint Like 如果觉得我的文章对你有用，请随意赞赏