「白天能跑 200Mbps，晚上 8 点一到，同一个节点只剩 1–3Mbps，看 1080p 都要缓冲。」这是自建节点最典型、也最磨人的一类故障。它的麻烦不在修复，而在定位：慢的是哪一段？家里的 Wi-Fi、运营商出口、跨境那几跳、机房入口，还是 VPS 自己的内核和代理进程？不把这几段拆开，你就只会在「换节点、换协议、重装系统」之间反复横跳，每次都觉得好像好了一点，第二天晚上又一样。
本篇不教工具用法，也不重讲协议原理，只解决一件事：把「慢」拆成可以分别取证的几段，每段拿到一个数字，再按成本从低到高处置。全文给的命令和判定阈值都可以直接照抄，示例输出取自一台联通宽带下的 Linux 主机（凌晨非高峰时段采样，地址做脱敏处理），它演示的是「怎么读数」，不代表任何特定 VPS 的实际表现。
开始之前先补一个容易被跳过的前提：准备一份已知可用的对照样本。自建节点的排障最怕变量太多，如果手上还有一份能正常跑的订阅，用它做对照，你可以在半分钟内把「本地/出口问题」和「这台 VPS 的问题」切开——比如瑶瑶领先的入门档（¥9.9/384GB）价格低、额度够跑几十轮吞吐测试，当对照组比拿生产节点反复折腾省事得多。对照组的唯一职责是「证明你的宽带本身没问题」，所以它不需要是最好用的那一个。
一、先把「慢」拆成三个正交指标
「慢」在日常语境里是一个词，在链路上是三件事：带宽被限、延迟被拉长、丢包触发重传。它们的证据来源完全不同，混在一起就永远说不清。先建立一个对照表，后面每一段都只回答「这一段在这三个指标上正不正常」。
| 指标 | 怎么取 | 正常范围（家用宽带出境） | 异常时的体感 |
|---|---|---|---|
| 延迟 RTT | ping -c 20 目标，看 avg 与 mdev | 同城 < 10ms；日韩 40–90ms；美西 140–200ms；欧洲 200–280ms | 网页首字节慢、点开要转圈、视频起播慢，但一旦开始播就能跑 |
| 延迟抖动 | 同上，看 min 与 max 的差 | max − min 不超过 avg 的 30% | 通话断续、游戏跳 ping、直播卡顿，测速数字却还行 |
| 丢包率 | mtr -rwzbc 30 目标，只看最后一跳的 Loss% | 0–0.5%；> 2% 已明显影响吞吐 | 速度像被「按阶梯」砍掉、重传多、TLS 握手偶尔失败 |
| 吞吐 | 单线程 curl -o /dev/null -w '%{speed_download}\n' 一个下载地址 | 取决于套餐与出口，重点是白天/晚高峰的比值 | 一切表现的总和，但它是结果，不是证据 |
这张表里最容易被忽略的是最后一行：吞吐是结论，不是证据。你测出晚高峰 1Mbps，只能说明「有问题」，不能说明「问题在哪一段」。所以每次取样都要同时记录时段、RTT、丢包和吞吐四个数，否则第二天你无法判断改动有没有生效。
四条测量纪律，违反任何一条得出的数字都不可用：
- 同时在两个时段各测一轮——白天（比如 14:00）和晚高峰（20:30–22:30）各一轮，其他时段的数据只是噪音。只有对比才有信息量。
- 同一个测点、同一个目标、同一个并发数。换了测速站、换了协议、换了并发，前后两组数字就没有可比性。单线程和十六线程测出来的东西完全不是一回事。
- 别用浏览器下载当指标。浏览器会开多连接、走缓存、受扩展影响；用
curl单线程测吞吐，用ping／mtr测延迟和丢包，分工明确。 - 先做对照再动手改。改配置之前先用对照样本跑一遍完全相同的测试；如果对照组在同一时段也慢，你改自己的 VPS 是在白费功夫。
二、五段链路：每一段只有两类证据
把「你的手机」到「网页服务器」之间的一切切成五段，每段只问同一个问题：延迟是不是在这一段抬升的、丢包是不是从这一段开始的。这就是分段排障的全部逻辑，剩下都是工具细节。
| 段 | 包含什么 | 主要取证命令 | 这一段的典型证据 | 处置方向 |
|---|---|---|---|---|
| ① 本地设备 | 电脑/手机 → Wi-Fi → 路由器 LAN | ping -c 20 路由器网关 | 内网 RTT > 5ms，或 min/max 差出好几毫秒 | 换有线、换信道、查路由器负载 |
| ② 本地出口 | 路由器 WAN → 运营商网关 → 城域网 | mtr -rwzbc 30 国内对照点 | 国内段就出现丢包或抖动 | 查上行占用、错峰、报修 |
| ③ 跨境去程 | 国内骨干出口 → 国际段 → 目的国入口 | mtr -rwzbc 30 VPS的IP | 某一跳之后 RTT 出现 100ms 级「台阶」 | 换线路类型、上中转 |
| ④ 海外入口 | 国际段 → 机房接入 → 你的 VPS IP | 从一台海外机器反向 mtr 你的 VPS | 海外侧同样慢、或去程/回程严重不对称 | 换机房、换 IP、升带宽 |
| ⑤ VPS 内部 | 内核网络栈 + 代理进程 + 磁盘/CPU | ss -tin、sysctl、uptime | cwnd 上不去、retrans 猛涨、steal 高、MTU 分片 | 调内核参数、换协议、换拥塞控制 |
顺序不能乱：① → ② 是「你家到国内」的闭环，③ → ④ 是「出境到落地」的闭环，⑤ 是「机器自己」。每一步只允许一个变量——你在改 VPS 参数的同时换了 Wi-Fi 信道，那这轮数据作废。真要同时改，就先各改一次、各测一轮，别指望一轮出结论。
三、第①②段：本地与本地出口
这两段是所有排障的起点，因为它们的成本最低、误判率最高。很多人跳过它们直接怀疑 VPS，结果折腾一晚上才发现是路由器在跑满 CPU，或者某个网盘客户端正在后台把上行占满。
先量内网。对路由器网关连打 20 个包：平均延迟应当是个位数毫秒的零头，且 max 与 min 接近。如果内网 RTT 就上到 10ms 以上，或者抖动超过 5ms，问题在你家里，与任何海外节点无关——无线干扰、同频邻居、2.4GHz 拥塞、弱信号下的重传，都会让「看起来连上了」变成「延迟忽高忽低」。
再看路由器本身。家用路由器在开启透明代理、规则分流、全量 DNS 重定向之后，处理每个包都要走一遍规则匹配；一旦流量上到几十兆，单个 CPU 核心很容易被软中断打满，此时的表现恰恰是「内网 ping 还好，一出网就慢」。判断方法是登录路由器看 CPU 占用与连接数，而不是盯着运营商测速。软路由侧的转发性能、MTU 调优与 QoS 设置在软路由性能优化完全指南里讲过，这里只强调它在排障里的位置：它是第①②段的问题，不要用第⑤段的手段去治。
顺带一个极便宜的分段技巧：把测试流量换成设备上的客户端直连，绕开路由器的透明代理那一段。走自家客户端的方案天生适合干这件事——例如自由猫由客户端管理节点、不参与路由器侧的规则匹配，在电脑上装好客户端跑一轮，就能立刻回答「瓶颈是路由器还是出口」。代价是它不适合软路由与透明代理场景，所以这个办法只用来做对照，不能替代你最终要走的链路形态。
最后量出口。挑一个国内的公共 DNS 或任意国内站点，用 mtr -rwzbc 30 跑一轮，看它在国内段（通常是前 5–8 跳）有没有出现丢包或延迟抬升。正常情况下国内段应该是「几毫秒到几十毫秒，全程平稳」。如果晚高峰这段就抖，选项只有三个：查自己的上行占用（同步盘、BT、直播推流、群晖备份都会吃掉上行，而上行饱和会连带拖垮下行，因为下行数据的 ACK 要从上行挤过去）、把大流量任务挪到凌晨、或者向运营商报修。
还有一个常被忽视的细节：如果家宽是 PPPoE 拨号，路径 MTU 通常是 1492 而不是 1500。这个差值平时看不出来，一旦你在这条链路上再叠加隧道（WireGuard、OpenVPN、TLS 封装的代理），封装开销会把可用载荷继续压小，于是出现「ping 得通、小网页能开、大文件一直卡在同一进度」的诡异症状。第⑤段会给出探测方法，但根因属于第①②段：本地链路的 MTU 上限，决定了你整条隧道能设多少。
四、第③段：跨境去程，看「台阶」出现在哪一跳
这是自建节点晚高峰掉速最常见的一段。做法只有一个：从你家对着 VPS 的 IP 跑 mtr，看 RTT 在哪一跳之后从几毫秒跳到一百多毫秒。下面三段真实输出可以帮你建立「正常长什么样」的直觉（联通宽带，凌晨 02:00 采样，同一台机器）：
| 采样目标 | 国内段 | 跨境跳 | 末跳 | 形态判读 |
|---|---|---|---|---|
| 国内对照点（223.5.5.5） | 3.5–6ms | 无台阶 | 34–37ms | 全程平稳，说明第①②段没问题 |
| Cloudflare（1.1.1.1） | 4.8–6.5ms | 6.5ms → 166.8ms（同一运营商骨干内相邻两跳） | 164.4ms | 典型「一步到位」台阶：出境那一跳直接把 +160ms 加上 |
| Quad9（9.9.9.9） | 3.3–6.1ms | 37.2ms → 261.6ms（同一跳 min 186ms / max 347ms） | 185.7ms | 「台阶 + 大抖动」：出口侧排队，晚高峰会更严重 |
读这三行可以学到三件事。
第一，台阶的位置比台阶的高度更重要。如果抬升发生在最后一两跳（已经进入目的国骨干），那是对方网络的常态，你能做的不多；如果抬升发生在国内骨干出口那一跳，说明拥塞点在国内出口与国际互联段，这是能通过换线路类型或加中转改善的。国内三大运营商各自有不止一层国际出口，普通国际出口与优质国际出口在晚高峰的差距往往是几倍，线路层级怎么分、机场标签怎么对应，国际线路科普：163、CN2 与 CMI 的分层里有完整对照。
第二，抖动是出口拥塞的指纹。同一跳的 min 与 max 差出 160ms，意味着这一跳前面有队列在堆积、等待时间不稳定。这种形态在晚高峰会放大成「速度像被按阶梯砍掉」。而「一步到位但稳定」（比如稳定在 165ms 左右、max−min 只有 20ms）通常是路径选择的问题而非拥塞，换时段改善有限，只能换路径。
第三，用物理下限制约你的预期。光纤里往返的有效速度按 20 万 km/s 估算，广东到美西约 11500 公里，理论地板就是 115ms 左右；实测 186ms 意味着中间多花了 60% 的时间在绕行、排队和设备处理上——这还在合理范围，但如果你看到 300ms 以上，先怀疑绕路而不是「网络就是这样」。判断真伪与绕行形态的读法（每一跳的 AS 号、去程回程各测一次、中间跳丢包的假象），路由追踪与去程回程判读里有逐跳的对照表，本篇不重复。
这一段能做的处置，按成本排：错峰（免费但只能缓解）→ 换协议与端口（免费，部分出口对特定端口更友好）→ 换线路类型（有一定成本）→ 加一层中转（自建国内中转机把跨境段从「可能被拥堵的直连」换成「可控的中转路径」，具体选机与 realm/gost 配置见自建中转加速完全指南）。如果排障的目标只是「晚上能稳定看视频」，也可以直接跳过自建跨境段这一环，用一份标准订阅的专线方案来承担出口——例如官方支持 OpenWrt 及主流客户端、订阅可直接导入 PassWall/OpenClash 的SS-ID，它把「跨境段怎么走」这件事交回给服务方维护，你只需要保留 VPS 做落地或干脆全交给它。
五、第④段：海外入口与落地 IP
判断第③段与第④段谁背锅，只有一个办法：从链路的另一端测一次。找一台已经在海外的机器（另一台 VPS、朋友的机器、或者云厂商的按量实例），对着你的 VPS IP 跑一次 mtr -rwzbc 30，同时用 curl 从它那里拉一个你的节点能访问的大文件。
- 海外侧也慢、也抖动 → 问题在机房入口或 VPS 本身，回程与你无关，去第⑤段或考虑换机房。
- 海外侧很快，只有你家去程慢 → 问题在第③段（跨境），处置见上一节。
- 两头都还行，但一到晚高峰就慢 → 高度怀疑机房接入口的超售与突发限速，这类问题平时测不出来。
第④段还有两个容易被归错类的问题。一是绕行：去程走 A 线路、回程走 B 线路，这在自建节点里非常常见，所以两边都要测，只测一头会得出相反结论。二是IP 属性被误当成带宽问题：出口 IP 是机房段、原生段还是住宅段，影响的是「服务侧怎么对待你」（风控强度、流媒体解锁、账号关联判断），不是你的带宽。很多人抱怨「晚高峰变慢」其实是晚间访问的站点开始限速或降码率，此时换机房毫无用处，要换的是出口属性。住宅 IP 与原生 IP 的差别、什么场景值得为它多付钱，仙路湾这类主打住宅/原生出口、面向跨境多账号与流媒体场景的方案正好是反例参照：它的价值在出口属性，而不在峰值带宽，如果你的瓶颈确实是第③段的拥塞，换它并不会变快。
如果你确认问题在机房侧（入口拥塞、超售、回程绕路），下一步不是换参数而是换机房。地区、机房与回程线路怎么挑、下单前怎么验、到手后发现不合适有哪几条处置路径，自建节点选机房完全指南里已经拆得很细——注意那是「买之前」的决策，本篇是「已经买错、正在慢」的排障，两者不重复。
六、第⑤段：VPS 内部与应用层
当跨境与入口都被排除，剩下的就是机器自己。这里有五处最常出问题，按检查顺序排列。
1）CPU 与「被偷走的时间」。先看 uptime 的负载和 top 里的 %st（steal）。steal 表示宿主机把 CPU 时间分给了别的租户、你的虚拟核在等——它在低价超售的机器上晚高峰抬升得非常明显，而这正是「白天好晚上坏」的经典成因之一：邻居忙起来了。如果 steal 经常上到 10% 以上，任何参数调优都是在错误的战场上努力。
2）拥塞控制到底有没有真的在跑。这是最常见的「以为改了其实没改」。在 VPS 上依次执行：
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
modinfo tcp_bbr | head -3在一台内核 6.17 的机器上，实际输出是 available = reno cubic、current = cubic、qdisc = fq_codel，而 modinfo tcp_bbr 显示模块存在但没被加载（lsmod | grep bbr 返回 0）。也就是说：内核提供 BBR，但没有任何配置启用它，很多教程里「写入 sysctl 就生效」的说法在模块未加载、或者配置被后加载的 drop-in 文件覆盖时会静默失败。BBR 与拥塞控制在晚高峰为什么有用、传统算法为什么在跨境线路上水土不服，原理部分见晚高峰变慢与 BBR 的完全指南；这里只记一条：改完必须回读——重启后再执行一次上面的第二条命令，并且用 ss -tin 确认连接的 cong_alg 字段确实是你要的算法。
3）吞吐受窗口与 RTT 共同限制。这一点能解释大量「晚高峰只剩 1Mbps」的案例，而且不需要测速就能算。
| 场景 | RTT | 在途窗口 | 理论上限 | 说明 |
|---|---|---|---|---|
| 白天理想 | 40ms | 500KB | 约 100Mbps | 窗口刚好够跑满百兆 |
| 晚高峰同一节点 | 200ms | 仍是 500KB | 约 20Mbps | RTT 涨 5 倍，吞吐掉到 1/5 |
| 晚高峰 + 窗口被限死 | 200ms | 64KB | 约 2.5Mbps | 这就是「1–3Mbps」的由来 |
| 晚高峰 + 换到美西 | 200ms | 2.5MB | 约 100Mbps | 要跑满百兆，窗口必须跟着 RTT 一起涨 |
公式只有一行：吞吐上限 ≈ 在途窗口 ÷ RTT。晚高峰 RTT 从 40ms 涨到 200ms 时，如果窗口没跟着变大，上限就直接掉到五分之一；如果窗口再被默认接收缓冲或中间设备压到 64KB，2–3Mbps 就是天花板。所以要同时看两侧的接收缓冲（sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem）和连接的真实 cwnd／rtt 读数——ss -tin 里 cwnd 长期停在低位、retrans 却持续增长，说明不是窗口小，而是丢包在拖后腿，该回到第③④段找丢包源。
4）MTU 与分片黑洞。本地路径 MTU 限制会沿着隧道一路传递。探测方法是从小到大试「禁止分片」的 ping：
ping -M do -s 1472 -c 2 1.1.1.1
ping -M do -s 1464 -c 2 1.1.1.1实测结果很有代表性：1472 直接报 ping: local error: message too long, mtu=1492，而 1464 正常通过——把 1464 加上 28 字节的 IP+ICMP 头，正好是 1492。也就是说这条 PPPoE 家宽的路径 MTU 是 1492，而不是很多人默认的 1500。内核文档对 net.ipv4.tcp_mtu_probing 的定义是三档：0 关闭、1 仅在检测到 ICMP 黑洞时启用、2 始终启用，实测这台机器是 0。它的意义在于：当链路上某台设备悄悄丢弃「过大的包」而不回 ICMP 消息时，TCP 不会自动降级，症状就是「能 ping 通、小页面正常、大文件永远卡住」。处置上把隧道内层 MTU 设到一个稳妥值（PPPoE 加 TLS 封装在家宽环境里常用 1400 上下起步，再逐步上调探测），并给内网设备统一口径，比事后猜要快得多。
5）代理进程与封装开销。每一层封装都要吃掉载荷和一点 CPU：TLS 记录头、WebSocket 帧、gRPC 分帧、多级转发都会；而「一条连接复用多个请求」的复用设置虽然能减少握手，却会在一条连接上串行化所有请求，单条连接一旦遇到丢包，所有复用的请求一起等。排障时可以把它当开关用：关掉复用、换一个协议、换一个端口，各测一轮，用数据说话——单线程吞吐提升了就是它，没有变化就排除它。
七、处置顺序：从零成本到换方案
拿到分段结论后，按成本从低到高依次尝试，不要跳级。跳级会让你同时改掉多个变量，最后不知道是哪一步起了作用。
| 顺序 | 动作 | 成本 | 适用结论 |
|---|---|---|---|
| 1 | 调内核与链路参数：MTU、拥塞控制（含确认真的加载）、qdisc、收发缓冲 | 0 | 第⑤段证据：cwnd 上不去、MTU 分片、steal 之外的机器侧问题 |
| 2 | 换协议/端口/封装层数，关掉不必要的复用 | 0 | 第③段疑似拥塞但幅度不大，或特定端口被针对 |
| 3 | 加一层自建中转（国内中转机 + 落地） | 中 | 第③段台阶落在国内骨干出口那一跳 |
| 4 | 换机房、换 IP、升带宽档 | 中高 | 第④段证据：海外侧也慢、去程回程不对称、机房超售 |
| 5 | 换线路类型（普通国际出口 → 优质国际出口/专线） | 高 | 反复对比后确认是出口层级问题，且用量值得这个价 |
如果五步走完都不满意，那就到了该算总账的时候：把「排障花掉的时间 × 你的时薪」和「网络开支的差额」放进同一张表，很多人会发现在中低用量下，自建的经济性本来就不成立——12 个月的开支拆解与盈亏平衡点，自建与机场的总持有成本账本里有现成的算法可以套。真到了那一步，退回去用一份面向普通客户端的机场方案就是完全合理的结论——把「用哪个工具」和「由谁维护跨境这一段」分开想，排障时就不会在错误的层面上努力。反过来说，如果你的出口必须挂在路由器上，可选范围会窄一截：得挑那种提供标准订阅、能被 PassWall、OpenClash 这类插件直接导入的方案，这件事最好在选型阶段就定下来，而不是排障排到一半才发现换不了。
八、六个最常见的误判
| 误判 | 为什么错 | 正确的做法 |
|---|---|---|
| 中间跳丢包 60%，认为链路在丢包 | 路由器对探测包的响应限速是常态，只有末跳丢包才反映真实损失 | 只看最后一跳的 Loss%，中间跳丢包配合延迟平稳即可忽略 |
| RTT 高就是带宽小 | 带宽上限 ≈ 窗口 ÷ RTT，两者是乘法关系 | 先算在途窗口需求，再决定是加缓冲还是换路径 |
| 测速站跑得动，说明节点没问题 | 测速站通常就近接入、多连接并发，和你实际访问的站点不是一条路 | 用与真实用途同类的目标做单线程测试 |
| 白天快晚上慢 = 人多了 | 也可能是本地上行排队、机房入口突发限速、宿主机 steal 抬升 | 按五段分别取证，用数据区分 |
| VPS 负载很低，机器肯定没问题 | 负载看不到 steal、单核软中断、MTU 与内核参数 | 看 %st、看 ss -tin，别只看 load average |
| 换个节点就变快了，排障结束 | 换的可能只是同机房不同 IP，也没搞清楚是路径变了还是入口变了 | 记录新节点的 AS 号与路径，确认变化发生在哪一段 |
九、十分钟取证流程
把上面的动作压成一个可以照着敲的顺序。先记下四个数（时段、RTT、末跳丢包、单线程吞吐），再动手改配置；改完重新跑一遍同样的四条命令，两组数字对比。
# 0) 基线：国内对照点，确认第①②段干净
mtr -rwzbc 30 223.5.5.5
# 1) 第①段：内网
ping -c 20 你的路由器网关
# 2) 第③段：从家到 VPS 的去程，找台阶落在哪一跳
mtr -rwzbc 30 你的VPS_IP
# 3) 第④段：在一台海外机器上反向测你的 VPS（去程回程各一次）
mtr -rwzbc 30 你的VPS_IP
# 4) 第⑤段：机器侧
uptime
sysctl net.ipv4.tcp_congestion_control net.core.default_qdisc net.ipv4.tcp_mtu_probing
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
ss -tin state established | head -20
# 5) 吞吐：单线程，两个时段各一次，同目标同命令
curl -o /dev/null -w '%{speed_download}\n' --max-time 60 你的下载测试地址三条读表要点：mtr 的结论只看末跳丢包和台阶位置；ss -tin 的 rtt／cwnd／retrans／pmtu 是机器侧最直接的四个数（字段含义以 man ss 为准，cwnd 是拥塞窗口、pmtu 是路径 MTU、retrans 是重传计数）；curl 的 speed_download 单位是字节每秒，换算成 Mbps 要乘以 8 再除以 1e6，别把 500KB/s 看成 500Mbps。
如果一轮下来「到处都正常」，别急着换机器——先把两组时段的数据贴在同一个表里。晚高峰掉速大多不是某个组件坏掉，而是两个各自都还行的环节在高峰期叠加：RTT 抬升吃掉窗口裕量、出口排队带来 0.5% 的丢包，两者乘起来就是你看到的那个数字。经典模型里，丢包率从 0.1% 涨到 1% 时，同样 RTT 下允许的吞吐上限大约只剩原来的三成——这就是为什么「丢包看起来只有 1%」却能把速度砍掉一大半。
十、常见问题（FAQ）
Q1：ping 只有 5ms，为什么下载还是只有 1MB/s？
5ms 说明路径近，不代表窗口够大。按「吞吐上限 ≈ 窗口 ÷ RTT」倒推，1MB/s（8Mbps）在 200ms RTT 下只需要 200KB 的窗口，任何默认配置都能满足——所以这种组合通常不是窗口问题，而是链路中途有丢包或限速，回头查末跳丢包率和第④段。
Q2：晚高峰丢包 1% 严重吗？
严重。TCP 对丢包的吞吐惩罚大致与丢包率的平方根成反比，1% 能让理论上限掉到原来的三成左右，而 0.1% 几乎看不出来。所以排障时不要只看「有没有丢包」，要看它随时段的变化：白天 0%、晚高峰 2%，这就是明确的拥塞证据。
Q3：换成 UDP 类协议就能绕过晚高峰吗？
不一定。UDP 在出口侧可能被单独限速或整段丢弃，换来的是「白天更快、晚上更不可用」；而且它绕开拥塞控制后会挤占同一链路里其他流量。这件事的取舍与 UDP 443 为什么总被特殊对待有关，QUIC 与 UDP 443 的处置里讲得比较清楚。
Q4：加了中转反而更慢，正常吗？
常见。中转的价值在于「把不可控的跨境段换成可控路径」，如果中转机自己的线路比你原本的直连还差，就是纯粹的负优化。判断方法很简单：从中转机到落地的这一段单独跑一次 mtr，和直连的同一段对比。
Q5：VPS 显示带宽 1Gbps，为什么从没跑到过？
标称带宽是端口上限。在多租户机房，实际可用带宽取决于接入口超售比、你与邻居的共用程度、以及跨境链路的容量。晚高峰前后各测一次单线程吞吐，两者的比值比绝对值有意义得多。
Q6：什么时候该停止排障、直接换方案？
给自建算一条时间线：如果连续三个晚上、每天投入超过一小时，问题仍在第③④段反复，就把它当成本题算账——同样的时间用在内容或业务上，收益通常大于省下的那点网络开支。
推荐阅读
- 软路由流量监控与带宽归因完全指南：看清每台设备与每条代理连接的去向——排障时先确认「带宽被谁用掉了」，能省掉一半的怀疑对象。
- 同一份机场订阅换 4 款客户端对比：内核差异、启动与内存占用——同一份配置在不同客户端上表现不同，能帮你排除「客户端在拖后腿」这一变量。
- 手机科学上网息屏掉线完全指南：Doze 与隧道重连机制——移动端还有一层系统级的断流问题，和本文的分段思路可以拼在一起用。