网盘（OpenList / AList 系）最容易踩的坑是：管理界面能打开，传大文件却又慢又断。根因经常不在「软件坏了」，而在 流量路径。
典型慢路径：全程隧道
客户端
→ Cloudflare 边缘
→ Tunnel
→ 控制中枢小机器
→ 本地磁盘（Local 存储）
问题叠加：
- 多跳与隧道抖动；
- 中枢内存小，代理大文件时容易顶到 swap；
- Local 存储无法像对象存储那样 302 直链，每个字节都经应用进程。
Tunnel 的正确角色更接近：把面板安全暴露出来，而不是当网盘 CDN。
改进路径：SNI 直连
在已经具备「HAProxy SNI → Caddy → 本机 OpenList」的前提下，可以把网盘域名：
- DNS 灰云 指向控制中枢；
- 从 Tunnel ingress 中移除；
- 应用只监听本机，由 Caddy 反代，并加长超时。
路径变为：
客户端 → 源站 443（SNI 命中网盘）→ Caddy → OpenList → 磁盘
少一跳隧道后，稳定性通常明显好于「全站 Tunnel」。上限仍受 机房带宽与到源站线路 限制。
存储后端演进
| 后端 | 适合 | 注意 |
|---|---|---|
| Local 磁盘 | 小规模、私密 | 受机器磁盘与带宽束缚 |
| S3 / R2 等 | 大文件、多端 | 配置直链/预签名，避免强制中转 |
| 网盘 OAuth 源 | 挂载已有云盘 | 受上游限速与合规约束 |
长期更优是：列表与鉴权在 OpenList，文件字节走对象存储。这需要单独一轮改造，但收益最大。
WebDAV 与强制代理选项
若 WebDAV 策略为「强制经服务端中转」，所有同步工具流量都会压在中枢进程上。能开官方直链/重定向的场景，优先避免无意义中转；Local 盘则往往只能中转——这是存储类型决定的，不是调参能彻底消除的。
运维检查清单
- 域名是否仍指向 Tunnel CNAME？
- OpenList 是否误暴露在公网高位端口？
- 反代超时是否覆盖最大文件？
- 客户端是否在规则里把网盘域名走了代理？（见第四篇）
小结
网盘性能首先看 路径：控制面可 Tunnel，数据面尽量直连或对象存储。下一篇写 Telegram 运维机器人与轻量多轮 AI Agent。