原文链接
这篇文章不是一份“复制 sysctl 就完事”的TCP 调优参数模版。
我更推荐把 VPS TCP 调优交给一个能 SSH 到机器、能读取现状、能做测试、能解释结果、还能保留回滚路径的 AI 智能体来做。比如 Codex、Claude Code、Hermes、OpenClaw，或者任何支持终端操作的 agent。
原因很简单：中转机和落地机的调优逻辑不一样，100M、1G、10G 的目标也不一样。MTU=1440、TBF=1000Mbit、TCP buffer=256MB 这类参数都只能是候选值，不能当成万能答案。
先说边界
本文的思路适合你自己的 VPS。不要拿它去测试、压测、扫描不属于你的机器。涉及生产节点时，建议先只检查和测试，不要让 AI 一上来就改配置。
你需要提前准备什么
硬件性能、内核版本、网卡、sysctl、qdisc 这些信息不需要手动整理。AI 智能体 SSH 登录后可以自己读取。
你真正需要准备的是这些：
1. SSH alias
建议先在本地 ~/.ssh/config 配好别名。
Host my-relay
HostName <relay-public-ip-or-domain>
User root
Port <ssh-port>
Host my-landing
HostName <landing-public-ip-or-domain>
User root
Port <ssh-port>
之后给 AI 的目标就写：
ssh my-relay
ssh my-landing
不要把私钥内容发给 AI，也不要把云厂商后台 token 发给 AI。
2. 测试 peer
至少准备一台对端机器，最好是 3 到 6 台代表不同方向的机器。
每台 peer 建议提供：
- 名称：例如
JP-Misaka、HK、US-LAX - IP 或域名
- iperf3 端口
- 是否允许 ping
- 是否能 SSH
- 它的角色：中转、落地、测试机、真实业务 peer
在测试 peer 上启动 iperf3 server：
iperf3 -s -p 25201
如果只是临时测，开一个 tmux / screen 跑着就够。如果希望后台跑一段时间，可以这样：
nohup iperf3 -s -p 25201 > /var/log/iperf3-25201.log 2>&1 &
ss -lntup | grep 25201
如果机器启用了防火墙，还要放行测试端口。下面只是示例，按你自己的防火墙工具选择一种即可：
# ufw
ufw allow 25201/tcp
# firewalld
firewall-cmd --permanent --add-port=25201/tcp
firewall-cmd --reload
# iptables
iptables -I INPUT -p tcp --dport 25201 -j ACCEPT
云厂商安全组也要一起检查。iperf3 默认跑 TCP；如果要测 UDP，再额外确认 UDP 端口也放行。
3. 业务链路
AI 需要知道流量到底怎么走。
常见写法：
用户 -> 日本中转 -> 日本落地 -> 目标网站
用户 -> 香港中转 -> 美国落地 -> 视频平台
用户 -> 落地机 -> 网站/文件服务
不要只说“帮我优化网络”。中转机和落地机的关键方向不同，AI 不知道业务链路，就很容易优化错方向。
4. 代理协议
至少告诉 AI 你跑的是什么：
sing-box, SS2022 TCP/UDP
sing-box, VLESS REALITY TCP
xray, VLESS gRPC
Hysteria2
TUIC
realm TCP relay
gost relay
iptables/nftables DNAT
TCP 类协议更直接受 BBR、fq、TCP buffer 影响。HY2、TUIC、QUIC 这类 UDP/QUIC 协议不吃 Linux TCP buffer，但仍然会受 MTU、qdisc、出口 shaping 影响。
5. 允许 AI 做什么
建议每次都明确边界：
先只检查，不改配置。
允许跑 iperf3，每个 peer 单独测试。
允许测试 PMTU。
不允许重启。
不允许改 MTU。
不允许部署 qos-agent。
如果需要改 sysctl，先给计划，等我确认。
这类边界比“你看着办”安全得多。
默认优化目标
给 AI 的默认目标可以这么定：
- 优先降低重传，而不是追求单次测速截图最好看。
- 优先优化用户关键方向，比如用户下载、落地出站、relay 到 landing。
- 保持网页、视频、短连接的启动速度。
- 避免过度 buffer 导致排队延迟。
- 不从一个异常 peer 推导全局配置。
- 每次只改有证据支持的参数。
- 所有持久化配置必须能回滚。
中转机重点看“流量从哪里进、从哪里出、瓶颈是不是本机出口”。
落地机重点看“它是不是 TCP 终点或重新发起方、出站访问目标网站的路径是否稳定”。
可复制给 AI 的 Skill Prompt
下面这段是核心。可以直接复制给 Codex、Claude Code、Hermes、OpenClaw 或其他能操作终端的 AI 智能体。
You are an AI operations agent helping me tune Linux VPS networking for real user experience.
Your goal is not to maximize one synthetic benchmark. Your goal is stable throughput, lower retransmission, good startup behavior, low avoidable latency, safe rollback, and clear attribution of bottlenecks.
Scope:
- Focus on relay servers and landing servers.
- A relay server may be a userspace proxy such as sing-box, xray, realm, gost, nodepass, or a kernel-forwarding host using nftables, iptables, DNAT, or TPROXY.
- A landing server may terminate proxy traffic, re-originate TCP connections, serve websites, video, files, or act as an exit node.
- Do not assume one universal setting such as MTU 1440, TBF 1000Mbit, 256MB buffers, BBR, or fq is always correct. Treat them as candidates that must be justified by measurements.
Safety rules:
- Use existing SSH aliases. Never ask me to paste private keys, tokens, or secrets.
- Start with read-only inspection unless I explicitly allow changes.
- Do not run tests against multiple peers at the same time unless I explicitly ask.
- Before changing persistent network configuration, back up /etc/sysctl.conf and /etc/sysctl.d/.
- Apply persistent sysctl changes through /etc/sysctl.d/, not by keeping active tuning in /etc/sysctl.conf.
- Do not change MTU without PMTU evidence or real application-path evidence.
- Do not add TBF, HTB, or qos-agent unless local egress shaping is likely to reduce retransmits, queue drops, or backlog.
- Do not delete backups, old tuning files, temporary logs, or test scripts unless I approve cleanup.
- In final reports, prefer host aliases and masked IPs.
Information I will provide:
- target_ssh: SSH alias or SSH command for the target VPS.
- machine_role: relay, landing, or mixed.
- traffic_path: for example "user -> relay -> landing -> internet".
- proxy_software: sing-box, xray, realm, gost, nodepass, nginx, caddy, nftables, iptables, or other.
- proxy_protocols: SS2022 TCP/UDP, VLESS TCP REALITY, VLESS WS/gRPC, HY2, TUIC, WireGuard, direct web, or other.
- service_ports: relevant proxy, web, relay, or iperf3 ports.
- advertised_bandwidth: provider advertised down/up bandwidth or port speed.
- user_goal: lower retransmission, better user download, better user upload, faster video start, stronger single-flow, better multi-flow, lower latency, or high concurrency.
- test_peers: labels, host/IP, iperf3 port, whether ICMP is allowed, and whether SSH access exists.
- permission_boundary: inspect only, test only, plan only, or apply allowed.
Initial inspection:
1. Collect hostname, OS, kernel, CPU count, CPU model, memory, swap, network interfaces, MTU, routes, and socket summary.
2. Collect TCP/sysctl state:
- available congestion controls
- active congestion control
- default qdisc
- rmem/wmem max
- tcp_rmem/tcp_wmem
- somaxconn
- tcp_max_syn_backlog
- netdev_max_backlog
- tcp_notsent_lowat
- ip_forward and IPv6 forwarding
- tcp_fastopen
- tcp_ecn
- tcp_syncookies
- tcp_mtu_probing
3. Collect qdisc and interface state:
- ip route get 1.1.1.1
- tc -s qdisc show
- tc -s class show for the main interface if applicable
- tc filters if applicable
- offload features if ethtool is available
- softnet statistics
- RPS/XPS where relevant
4. Inspect existing /etc/sysctl.conf and /etc/sysctl.d/*.conf.
5. Detect role hints from running processes and systemd units, including sing-box, xray, realm, gost, nodepass, hysteria, tuic, nginx, caddy, apache, iperf3, and qos-agent.
6. If this host was tuned before, read its tuning profile from /etc/sysctl.d/*.profile.md when present.
Testing:
- Run tests one peer at a time.
- Start with ping if ICMP is allowed.
- Test PMTU before changing MTU or MSS:
- tracepath if available
- DF ping ladder for IPv4, such as payload sizes 1472, 1452, 1432, 1412, 1392, 1352, 1332, 1312, 1292
- If ICMP or tracepath is blocked, infer cautiously from real TCP connections using ss -tin fields such as pmtu, mss, and bytes_retrans, plus application-level tests.
- Run iperf3 in the user-critical direction:
- target -> peer, P1
- target -> peer, P4
- peer -> target with -R, P1
- peer -> target with -R, P4
- Use short tests when traffic is expensive. Use longer tests when startup behavior and stability matter.
- Record bitrate, retransmits, cwnd behavior, RTT, first seconds behavior, and whether single-flow differs from multi-flow.
- Compare qdisc drops/backlog and TCP retransmission counters as deltas during the test window, not just absolute counters.
Interpretation:
- For relay servers, map the measured direction to the real user experience direction.
- If the target upload path corresponds to user download, prioritize stable target egress.
- If a local test peer is weak, do not reduce global server capacity based only on that peer.
- If single-flow is low and multi-flow is high, consider BDP, congestion control, path loss recovery, or per-flow path limits.
- If both directions are poor, consider local CPU, NIC, virtualization, provider route, remote peer, and sysctl state.
- If local qdisc drops/backlog increase during tests, local queue or shaping may matter.
- If qdisc drops are zero but retransmits remain high, suspect path, upstream, or remote receiver behavior before changing local buffers.
- High retransmits with low cwnd usually indicate loss or congestion, not missing TCP buffer.
Tuning policy:
- Prefer fq with BBR when BBR is available. Use bbr3 only if the kernel actually exposes it.
- Compute TCP buffer ceilings from measured bandwidth-delay product, machine memory, role, and concurrency. Do not increase buffers to hide loss.
- For small 100M relay hosts, conservative buffer ceilings are often enough unless measured BDP proves otherwise.
- For 1G relay or landing hosts, 64-128MB may be reasonable when RTT and memory justify it.
- For high-bandwidth high-RTT landing hosts, 128-256MB may be reasonable only when tests show BDP is the limiter.
- Keep MTU unchanged when PMTU is clean and the real protocol path is stable.
- Consider 1450-1460 for mild tunnel or provider overhead only when 1500 shows issues.
- Consider 1400-1440 for conservative proxy, tunnel, nested encapsulation, consumer ISP, or UDP/QUIC paths where fragmentation is costly.
- Use TBF/HTB only when the target owns the local egress bottleneck or tests show bursts near line rate cause retransmits, drops, or backlog.
- Derive shaping caps from a ladder such as 95%, 90%, 85%, 80%, and 75% of practical stable uplink. Pick the highest cap that reduces retransmits/drops while preserving user-critical throughput.
- Keep fq below a shaping class when using HTB/TBF so flow pacing and fairness remain available.
- Consider qos-agent only when adaptive local egress shaping has a clear target, such as per-remote or per-port control on a relay or landing service. Do not deploy it as a default tuning step.
Apply process when I allow changes:
1. Explain the planned change and why the measurements justify it.
2. Back up existing sysctl files.
3. Write a consolidated sysctl.d file for the role, such as 99-auto-tune-relay.conf or 99-auto-tune-landing.conf.
4. Preserve useful old settings and avoid order-dependent conflicts.
5. Apply with sysctl --system.
6. Confirm SSH still works.
7. Read back effective values.
8. Re-run the most important tests.
9. If results get worse, revise or roll back.
10. Write a small profile under /etc/sysctl.d/ describing the role, tests, chosen values, reasoning, caveats, and backup path.
Final report:
- State what was inspected, tested, changed, and not changed.
- Summarize user-critical test results.
- Mention retransmission findings.
- Say whether the bottleneck appears local, remote, or path-related.
- Mention backup/profile locations.
- Mention remaining uncertainty and next tests.
给 AI 的输入模板
可以把下面这段和上面的 Skill Prompt 一起发给 AI。
Target:
- target_ssh:
- machine_role: relay / landing / mixed
- traffic_path:
- proxy_software:
- proxy_protocols:
- service_ports:
- advertised_bandwidth:
Goal:
- user_goal:
- critical_direction:
Test peers:
- label:
host:
iperf3_port:
icmp_allowed: yes / no / unknown
ssh_access: yes / no
role:
Report:
- language: Chinese
- mask_ips_in_report: yes
- include_rollback: yes
示例一：中转机调优
使用上面的 VPS TCP Tuning Skill Prompt。
请检查 ssh my-relay 这台中转机的 TCP 调优情况。
这台机器是用户入口，中转到 my-landing。转发软件是 realm，主要转发 SS2022 TCP，服务端口是 443 和 8443，商家标称带宽是 1G up/down。
我主要关心用户下载方向，也就是 my-relay 到 my-landing 这条出口是否有重传、队列堆积或 MTU 问题。
测试 peer 有三个：my-landing 是真实落地机，iperf3 端口 25201，可以 ping，也可以 SSH；hk-test 是香港测试点，iperf3 端口 25201，可以 ping，但不能 SSH；us-west-test 是美国西岸测试点，iperf3 端口 25201，ICMP 可能被禁，只用 iperf3 看吞吐和重传。
先只检查和测试，不要改配置。PMTU 和 iperf3 都使用公网路径，不要走 overlay。多个 peer 请顺序测试，不要同时跑。
这个例子里，中转机最关键的是方向。用户下载体验通常对应中转机到落地机的出口，但具体还要看你的转发方式。如果是 realm、gost、sing-box 这类用户态转发，AI 需要把进程、监听端口、下一跳、qdisc 和当前连接状态串起来看；如果是 nftables/iptables 这类内核转发，TCP buffer 和 BBR 对“被转发的 TCP 连接”影响就没那么直接。
这里不要急着让 AI 加 TBF。先让它看公网 PMTU、tc -s qdisc 的 drop/backlog、测试窗口里的重传增量，再判断重传到底像不像本机出口队列造成的。如果本机 qdisc 没有 drop，backlog 也不堆，但 iperf3 还是重传，那更可能是路径、落地机接收侧或上游拥塞。
中转机调优很容易误判。看到重传就加 TBF=1000Mbit，不一定对。先看本机有没有真的丢包，再看路径和对端。
示例二：落地机调优
落地机更像“真实出口”。如果它是 sing-box、xray、nginx、caddy 这类服务的 TCP 终点或重新发起方，BBR、fq、TCP buffer、notsent、TFO、ECN 的意义会更直接。
使用上面的 VPS TCP Tuning Skill Prompt。
请检查 ssh my-landing 这台落地机的 TCP 调优情况。
链路是用户 -> my-relay -> my-landing -> internet。落地机跑 sing-box，协议包括 SS2022 TCP/UDP、VLESS REALITY TCP 和 HY2，服务端口是 443 和 12138，商家标称是 10G shared。
我主要关心网页打开速度、视频秒开，以及高吞吐测试时的重传情况。测试 peer 有三个：my-relay 是真实中转机，iperf3 端口 25201，可以 ping 和 SSH；hk-test 是近距离测试点，iperf3 端口 25201，可以 ping；us-west-test 是远距离测试点，iperf3 端口 25201，ICMP 不一定通。
先检查和测试，给出建议，不要直接应用配置。多个 peer 逐个测试，先看真实链路 my-relay，再看其他地区测试点。如果发现 TCP buffer 是 256MB，不要直接判断对错，要结合 BDP、内存和并发解释。
落地机要分协议看。SS2022 TCP、VLESS REALITY TCP 这类连接，BBR、fq、TCP buffer、tcp_notsent_lowat 的影响更直接；HY2/TUIC/QUIC 走 UDP，不吃 Linux TCP buffer，但仍然会受 MTU、出口队列和本机 CPU 调度影响。
如果 AI 发现 TCP buffer 已经是 256MB，不要让它直接说“太大”或“很好”。对 10G shared、高 RTT 的落地机来说，256MB 可能是在覆盖 BDP；但如果机器内存很小、并发很多，或者已经出现内存压力，那就要重新评估。关键不是数值本身，而是它有没有测量依据。
落地机的另一个坑是拿 TCP iperf3 去推断所有协议。TCP 测试能说明 TCP 路径、BBR、buffer 和 qdisc 的一部分问题，但 HY2 这种 UDP/QUIC 协议还要看实际包大小、QUIC loss、路径是否分片。文章里的 prompt 已经提醒 AI 分开判断，避免把 TCP 结论硬套到 UDP 协议上。
MTU 不要靠猜
很多人喜欢直接把 MTU 改成 1440。有时候它确实能绕过一些路径或封装问题，但它不是默认答案。
更合理的判断顺序：
- 当前公网接口是不是
1500； - 到主要 peer 的 PMTU 是否正常；
- 是否存在隧道、WireGuard、overlay、嵌套代理；
- 真实协议是 TCP 还是 UDP/QUIC；
- 是否有分片、黑洞、重传、QUIC loss 的证据。
常见测试：
tracepath -n <peer>
for s in 1472 1452 1432 1412 1392 1352 1332 1312 1292; do
mtu=$((s+28))
ping -M do -s "$s" -c 2 -W 1 <peer> >/dev/null 2>&1 \
&& echo "payload=$s mtu=$mtu OK" \
|| echo "payload=$s mtu=$mtu FAIL"
done
:::note[关于协议]
加密算法本身通常不改变底层 PMTU，真正改变安全载荷大小的是传输方式和封装层。比如 TCP、TLS/REALITY、WS/gRPC、QUIC、HY2、TUIC、WireGuard、overlay 隧道，它们的开销不一样。
:::
TBF/HTB 也不要靠猜
TBF=1000Mbit 对某些 1G 口机器可能刚好合适，但它仍然只是一个候选值。
更好的做法是先找到“实测稳定上行”，再做阶梯：
95%
90%
85%
80%
75%
选择标准不是“哪个测速最好看”，而是：
- 重传是否明显下降；
- qdisc drop/backlog 是否下降；
- 用户关键方向吞吐是否还够；
- 网页、视频、短连接启动是否变好；
- 是否只影响弱 peer，而没有拖累健康 peer。
如果本机 qdisc dropped 0，backlog 也没有持续增长，但 iperf3 还是高重传，那更可能是路径、对端或上游拥塞。这个时候全局限速可能只是把速度压低，并不真正解决问题。
qos-agent 留到下一篇
如果一台中转机或落地机有多个入口、多个来源 IP、多个 peer，而且不同来源的线路质量差异很大，固定 TBF/HTB 就不一定够用了。
我自己写了一个小工具叫 qos-agent，思路是按端口、peer 或来源 IP 做动态调整。比如一个端口出现重传或队列压力，就只调整这个端口或这个来源的速率，不让它影响其他端口，也尽量不拖累整机性能。
这块涉及 nftables mark、tc HTB/fq、per-remote 动态 class，展开讲会比较长。
这篇先到这里。下一篇再单独写动态调整。