[2026.9.28] Oracle VPS体验

🦯

大放水敲开龟壳

速览

走招行万事达（注册预扣减SGD1.38，升级预扣减大概SGD138，不时二验SGD1.38，需要有足够余额，大概至少留个800块在上面，卡也可以套Google Pay走OpenAI与Anthropic支付与CF羊毛（R2存储、SaaS，裸验不过，套皮可以）），美西凤凰城(phoenix)，三个区域AD，纯Free Tier不升级随便开，没有碰到限制带宽情况，上下行目前都跑满100M带宽，443 上 TCP Reality + UDP Hy2；纯IP直连。Always Free 保活走内存过 20% 线（ARM机器，非ARM不行）。

升级前：

升级后：

IP情况

一般机房IP，可用

邻居卧龙凤雏

机器参数

原则上升级后可以4 + 24 + 200，付磁盘费跨区开

没有需求，直接Always Free

项	选择	原因
规格	A1.Flex 2 OCPU / 12 GiB	Always Free 额度内
系统	Ubuntu ARM64	官方镜像
核心进程	sing-box 1.14	Reality + Hy2
公网端口	TCP 22、TCP 443、UDP 443	其余 REJECT；监控和隧道不对外

AI做的节点设置调整

“Oracle 镜像常见组合：socket 缓冲只有约 200 KiB、网卡 qdisc 是 fq_codel（BBR 对不上）、cloud-init 把 WAN 口 MTU 设成 9000。跨境 RTT 大约两百毫秒量级时，窗口和第一包分片都会吃亏。

落地且持久化：

rmem_max / wmem_max 提到 16 MiB，TCP 窗口跟着抬

enp0s6 qdisc 换成 fq，BBR 才真正干活

MTU 9000 → 1500（VCN 巨帧，出公网是 1500；Hy2 / QUIC 第一包最容易踩 PMTU）

tcp_slow_start_after_idle=0、tcp_mtu_probing=1、tcp_fastopen=3

Reality 开 TFO；两条都开 UDP fragment

调完再握手，出口仍是这台机。2 秒采样网卡利用率约 0.01%，开机均值也远低于标称 2 Gbps。瓶颈在路径丢包，不在实例带宽。”

保活（ARM）

“官方回收窗口大约 7 天，三条同时低于 20% ：CPU p95、网络、A1 内存。一般APP与代理打不满 CPU 和网卡，所以只能压力内存。12 GiB 的 20% 是 2.4 GiB；”

暴力做法：一个低优先级的 systemd 服务，持有约 6 GiB 私有匿名页（MAP_PRIVATE）。MAP_SHARED 会记成 Shmem，计量不一定算进那条线。观察 used 大约一半以上即可。

实际做法：在VPS上配了qwen tts，CPU跑TTS任务，内存里常驻TTS模型

存储中转TG

借道cloudflare-imgbed项目，中转VPS传到TG，获取视频公网访问链接，用来给Gemini视频理解转阅读学习

AI诊断CF中转问题

“Pages Function 把十几 MiB 分片收进内存再转 Telegram，免费档会 Worker exceeded resource limits。同一套软件改到这台 VPS 上跑，738 MiB 能传完、能 Range；播放慢的是 Telegram getFile，不是 Tailscale。

先复用已有的 Cloudflare Pages 图床。小文件没问题：音频扩展名在白名单里，登录态实测 wav / mp3 / flac / opus / ogg 都能 200，回 Content-Type 和 Range 206。前端 <input accept> 是空的，不拦非图片。

大文件协议是 16 MiB 分片 → 边缘 Worker 再 sendDocument 到 Bot。单片 Telegram 能收；Worker 不行。738 MiB（47 片）试了两次：

试次	结果
并发 3	38/47 成功，后段 503
串行 + 单片最多 8 次重试	前几片成功后从某一片起连续 503，merge 没发生

失败页是 Cloudflare 自己的 Worker exceeded resource limits / 524，不是 Bot 的 file too big。缺片可以在同一 uploadId 上补，但 isolate 打满后同一片再打还是 503。结论：问题在 Pages Function，不在 Telegram、不在这个文件。”

改VPS

“约束没变：公网只 22 / TCP 443 / UDP 443，管理面走 Tailscale，盘当临时中转（72h cron 删）。装了 Docker，官方 arm64 镜像，容器只绑回环和 Tailscale 地址，本机公网 IP 扫对应端口超时。

渠道后来接到同一个图床 Bot：上传选 Telegram，VPS 当中转，不经 Cloudflare Worker。同一份 738 MiB：47/47 成功，约两分钟 merge。对外一条 /file/... 链接，Content-Length 等于原文件，头/中/尾 Range 都是 206，文件头是正常 mp4 ftyp。Telegram 聊天里仍是一串 document，浏览器那条 URL 是 Worker/Node 拼出来的完整视频。

路径	实测	含义
冷：VPS 向 Telegram 拉片	16 MiB 大约 5.7 s（约 2.8 MB/s）	播放卡的是这一跳
热：VPS 盘缓存后再经 Tailscale	16 MiB 大约 1.4 s；32 MiB 大约 4.3 s（约 7.8 MB/s）	Phoenix 直连够播，不是 WireGuard 拖后腿
Tailscale overlay RTT	大约 190–230 ms	跨境正常

笔记本访问的是 Tailscale 地址。策略路由里 Tailscale 表排在 Karing TUN 表前面，overlay 进 tailscale0，底层 WireGuard 对实例公网 IP 另有 lookup main 绕开 TUN。所以 Karing 连接列表里没有这路流量——设计如此，不是分流漏了。

开公网端口或 named tunnel 只换你到 VPS 那一跳，热路径已经够快；冷路径仍是 VPS → Telegram，开端口改变不了。要接近本盘速度，大文件应走本地磁盘渠道当源，Telegram 只当备份，不要当分片播放源。

GET 侧后来加了分片磁盘缓存和向前预取：同一段第二次明显快，第一次仍受 getFile 限制。缓存目录同样 72h 清。”

代理协议选型

延迟与带宽

延迟（每条链路 30 次连续小请求，统计 TTFB）：

指标	Hy2（UDP / QUIC）	Reality（TCP / TLS）
中位数	620 ms	1237 ms
p90	1111 ms	2549 ms
p99	1177 ms	3068 ms
最差单次	2007 ms	3954 ms
30 次请求失败数	0	0
空闲 60 s 后首个请求	520 / 694 ms	1310 / 2177 ms

带宽（校园网上限30M同一时段交错，两组数据）：

轮次	Hy2	Reality
30 MB × 3	0.92 / 1.61 / 1.70 MB/s	0.99 / 1.93 / 1.88 MB/s
20 MB × 4	1.40 / 1.52 / 1.41 / 1.48 MB/s	1.49 / 1.04 / 0.61 / 1.29 MB/s（1 次提前中止）

这一跳的瓶颈在路径丢包而不在实例带宽，跨境链路的丢包和抖动随时间漂移，协议差异被淹在里面了。而延迟那一列两组数据方向完全一致——延迟差距稳定，带宽差距不稳定。

恢复速度

为了区分「链路质量」和「故障时的行为」，单独建了个网络命名空间跑两套实例，在命名空间内把到 VPS 方向的全部流量 DROP 掉 25 秒再解除，每秒探一次：

阶段	Hy2	Reality
黑洞期间	25 次全部秒失败（会话已死，没有连接可等）	4 次全部挂满 12 s 超时才返回失败
解除后第一次成功	解除当刻（+0 s）	+3.0 s
恢复后首包	919 ms	2347 ms
恢复后稳态	420–490 ms	880–1030 ms

两侧故障粒度完全不同：Hy2 是秒失败、恢复快；Reality 是挂到超时、恢复慢。这对体感的影响比带宽大得多——秒失败能被上层立刻重试并降级，挂满 12 秒就是实打实的卡死。

「Hy2 偶发断开」

客户端核心日志里抓到过一次真实的三分钟全线故障：

同一时间窗内直连出口正常、服务端入站也正常。不是本地断网，也不是 VPS 挂了。

关键在错误签名的类型：Application error 0x0 (local) 是本地 QUIC 栈报的会话级错误，不是 TCP 那种 RST / FIN。所有 Hy2 流量复用同一条 UDP 会话，会话一死，挂在上面的连接一起死。Reality 每条连接是独立 TCP，挂一条只挂那条。

Hy2 是「整栋楼跳闸」，Reality 是「一间房跳闸」。

同一天 Reality 节点也有 14 条错误，但全是 no route to host / operation was canceled——那是客户端 TUN 重建时的本地路由抖动（用的FakeIP），不是协议层失败。别把这两种错误混在一起数。

Reality 走 TCP 443，TLS 握手是借一个真实站点的，在 DPI 眼里就是一次普通 HTTPS 访问——针对它的干扰手段基本只剩限速，不会 RST、不会掐会话。Hy2 走 UDP 443，QUIC 长包头本身就是指纹，而且 UDP 在这一跳的 QoS 通常比 TCP 差、丢包率高一个量级。

但更根本的一点是：上面那份日志里没有一条 RST，全是本地会话级错误。被掐的是会话不是连接，而会话级掐断是复用制协议才有的失效模式。Reality 根本没有共享会话，也就结构上不可能出现这种故障。

「抗干扰更强」翻译成工程语言就是：失效粒度更细。这跟它快不快无关。

正确用法：主力 + 兜底

Hy2 当主力（延迟低一半、故障秒失败、恢复快），Reality 当兜底（独立连接、指纹干净、只被限速不被掐会话）。两者不是替代关系。

Tailscale组内网

公网只留 SSH、TCP 443、UDP 443。监控、图床、配音网关都不对公网开端口，自用应用走 Tailscale。

Tailscale 1.102，两边都关了 MagicDNS（--accept-dns=false），也不接收别人宣告的路由（--accept-routes=false）。笔记本上的 MagicDNS 解析本身是坏的（systemd-resolved 和 NetworkManager 抢），所以访问管理面用 Tailscale 地址，不用主机名。

控制面被本地 TUN 的假 IP 吃掉过一次：tailscale up 连不上。处理是把控制面三个域名钉进 /etc/hosts，再加一条策略路由，让那一段地址走主表，不进 TUN。

和本地 TUN 怎么共存

笔记本同时开着 Tailscale 和 Karing TUN，两张策略路由表：

优先级	查哪张表	谁的流量
5270	Tailscale 表	去 Tailscale 地址的包
8987	主表	去这台 VPS 公网 IP 的包（SSH、探测）
9001	Karing 表	其余默认流量

所以浏览器打图床的 Tailscale 地址时，包先进 tailscale0，Karing 的连接列表里看不到——不是分流漏了。底层 WireGuard 打到实例公网 IP 的那一跳，另有一条主表规则绕开 TUN，避免 SSH 和探测被代理卷走。

VPS 侧 tailscale netcheck：UDP 通、有公网 IPv4、最近 DERP 是旧金山（约 22 ms）。笔记本侧 UDP 也通，但 MappingVariesByDestIP: true，最近 DERP 是纽伦堡（约 160 ms）。直连打洞没建立，overlay 流量经旧金山中继绕一圈。

这和前面图床那一节的体感对得上：Tailscale 往返大约两百毫秒，热路径够播放；冷路径慢在 VPS 向 Telegram 拉分片，不在这一跳是直连还是中继。开公网端口换不掉冷路径。

挂在上面的应用

容器或进程只绑回环，或者回环加 Tailscale 地址。公网扫这些端口应超时。tailscaled 自己还听着一个 Tailscale 地址上的 TCP 口，那是守护进程，不是业务。

应用	绑定	干什么
图床（Docker，官方 arm64 镜像，内存上限 1 GiB）	回环 + Tailscale 地址，同一端口	大文件中转。本地盘渠道和 Telegram Bot 分开；72 小时 cron 清盘和分片缓存。默认上传走 Telegram。HTTP，会话 cookie 不能开 Secure
Komari 监控面板	容器内监听全地址，宿主机只映射回环和 Tailscale 地址	2026-09-24 装的。agent 用 host 网络打回环上的面板，关了自动更新和网页 SSH。站点描述就是 "Komari Monitor"，主题 LuminaPlus，密码登录开着，OAuth 没开
Beszel	只绑回环（hub 和 agent 各一个口）	同一台机器的另一套监控。笔记本用 SSH 本地转发看，不放进 Tailscale 监听
Hermes	不监听	用户态网关，对接 Telegram。没有 dashboard 端口
配音网关	只绑回环	模型常驻，顺手把内存垫过 Always Free 的 20% 线。不给 Tailscale 地址