VPS

发布时间：

最近给自己的几台设备搭了一条轻量的个人网络链路，初衷很简单：有些海外 SaaS、代码仓库和 AI 工具在不同网络环境下访问质量不稳定，公共服务又经常受共享用户、线路策略和客户端规则影响。与其每天在不同节点之间切来切去，不如自己维护一条可观测、可回滚、只服务个人设备的小链路。

2026 年 11 月 6 日 05:59:42，更新，已过时/

这条链路的设计原则是尽量简单：一台海外 VPS 作为唯一中转入口，服务端跑基于 UDP/QUIC 的轻量隧道服务，客户端通过私有订阅文件同步配置，日常只服务自己的电脑和手机。我没有装控制面板，个人使用场景下面板本身经常比服务更复杂，真正需要稳定维护的东西其实不多：一个 systemd 服务、一个服务端配置、一个私有订阅文件、几条防火墙规则，以及一套能快速判断问题在哪一层的检查命令。而且，我还有 codex！就够了。搭建的时候也是直接让 Codex 自己 SSH 进去一通操作🤣，先看系统版本、服务状态、端口监听、防火墙和订阅文件，再写 systemd、生成配置、拉起服务，最后用 curl 和临时客户端做验证。

排查卡顿与调优

用了一段时间后遇到过一次明显卡顿，Codex 连续报错。我按从近到远的顺序逐层排查。先看本地出口，确认客户端当前实际走的链路、出口 IP、机房位置和路由符合预期，排除客户端还停留在旧节点的情况。接着对比本地接入网络，发现手机热点和公司 Wi-Fi 差异很大：热点下单连接下载只有 1~2 MB/s，切到公司 5G Wi-Fi 后同一个测试源能到 3~6 MB/s，部分源还能更高，说明接入网本身就占了一部分卡顿原因。再 SSH 到 VPS 看服务、端口、CPU、内存、磁盘和出口速度，当时服务端没有资源瓶颈，VPS 访问 Cloudflare、GitHub、OpenAI 也很快，问题不在服务器负载上。最后查到协议和内核参数，才定位到两个根因：一是服务端版本有安全和稳定性更新待升；二是 Linux 默认的 UDP socket buffer 只有二十多万字节（212992），对跨国 UDP/QUIC 传输来说明显偏小，容易造成内核缓冲区丢包。

定位清楚后做了四项改动：

  1. 将 Hysteria 2 服务端从 v2.8.2 升到 v2.9.2。因为升级要重启服务，先让 Codex 备份了配置与二进制文件并备好回滚脚本，防止升级失败把当前连接掐断。
  2. 调大系统 UDP 缓冲区，把 rmem_max 和 wmem_max 从默认的 212992 调到 16777216，减少长距离 UDP/QUIC 传输因内核缓冲区过小引起的丢包和抖动。
  3. 在服务端内部加了一层 Cloudflare 出站分流。Codex 和部分海外 SaaS 对机房直连 IP 的风控比较严，给特定域名走常见网络出口更贴近正常用户访问。
  4. 把客户端的下行带宽参数从激进的 200 Mbps 回调到 80 Mbps，上行保持 50 Mbps。这个参数决定了服务端往客户端发包的激进程度；当实际链路单连接稳定吞吐只有几十 Mbps 时，配得太高反而会导致排队、丢包和延迟飙升，设在比实际稳定吞吐略高一点的位置最合适。

Mac 客户端最后我还是用了 Shadowrocket。之前也折腾过 Clash/Mihomo 这一套，功能确实强，但日常用起来我还是觉得 Shadowrocket 更省心，更稳。付费软件有时候就是这样，少折腾就是最大的价值。

排查过程中也顺手排除了几个容易混淆的方向。比如那两天 X 上有人提到（推文链接），部分基于 REALITY 的配置把微软站点作为伪装目标时，会因为证书链变大触发握手异常，表现为 EOF、reset 和断流；但我的链路没有用 Xray、VLESS 或 REALITY，这条原因自然排除。另外服务端日志里确实能看到一些 Microsoft、Teams、Office 域名的 reset 或 timeout，不过那是 VPS 访问目标站点时的连接异常，跟客户端到 VPS 的入口隧道无关。至于混淆、端口跳跃、IPv4-only 出口这些手段，在没有证据表明入口被主动干扰或 UDP 端口受限之前我也没有加，没证据就叠复杂度只会让下次排查更痛苦😭🤣。

压测结果与复盘

调优完成后，在本机跑了几组实测：

  • networkQuality 测速下行约 160 Mbps，上行约 250 Mbps。
  • Cloudflare 10MB 单连接平均约 4.5 MB/s，25MB 单连接平均约 6.5 MB/s。
  • Cachefly 10MB 平均约 7.6 MB/s，峰值超过 10 MB/s。
  • ChatGPT 首页请求耗时约 0.57s，GitHub 首页约 1.5s。
  • 服务端 UDP buffer error 保持为 0。

折腾这一圈下来有几点体会。网络调优不能盲目把带宽、窗口、并发这些参数往大了填，超过真实链路的承载能力后，发包太猛反而会让延迟变高、页面卡顿甚至偶发断流。排查时要把本地接入网、中转入口服务、远端目标站点三段拆开看，VPS 出口快不代表客户端到 VPS 这段质量好，本地测速高也不代表访问某个具体海外站点就快；同样是 EOF、reset 或 timeout，必须先分清发生在哪一段，再动手改配置。所有涉及服务端升级、内核参数和 systemd 重启的变更，先留好备份和回滚脚本，改完用实际请求验证，比凭感觉调参靠谱得多。