排队、空间与上传失败
从队列状态和资源条件开始，避免先做破坏性的磁盘清理。
一直排队时的顺序#
- 用
/status检查是否暂停；需要恢复时执行/resume。 - 看目的目录是否可达，网关是否登录且挂载有效。
- 检查本地任务额度与磁盘安全线，以及资源采样是否新鲜。
- 用
/doctor做只读诊断。 - 需要时执行对应 Edition 的真实 WebDAV 验收。
- 先恢复一个测试任务，确认原因修复后再批量重试。
有空闲空间但预算满#
实际磁盘空间和任务预留预算是两个指标。普通文件、下载预留、失败保留文件都可能影响调度，不要只看 df 的一个数字。
不要为了立即放行任务把保留空间设得很低。详见 资源预算。
上传失败后文件还在 VPS#
普通模式保留完整本地文件是用于重试的保护，不一定是垃圾。先看 /task 编号，修复网关、凭据、网络或配额问题后，再 /retry 编号。
没有确认这些文件对应的任务和恢复需求前，不要手动批量删除下载目录。
流式任务失败#
流式模式通常没有完整本地副本，重试可能从头读取。源站获取、VPS 网络、网关限流和存储异常都可能中断管道。
不能把“支持重启恢复任务”理解为“任何网络中断都逐字节断点续传”。
重试后仍失败#
/retry all 一次处理最多 100 个可重试任务，但不负责修复根因。先单任务验收，避免把同一个错误放大成大批量失败。
遗留临时文件#
先使用只读的 /orphans 检查。需要清理时，按 /orphans clean 返回的一次性确认流程操作。
这个巡检面向特定临时文件，并不等于扫描并自动删除所有未知文件。清理会保护活动任务路径，不应手工绕过这些保护。
速度突然下降#
分别查看来源下载、远端上传和流式送入速度，同时看 CPU、内存和磁盘。出现 429 先减压，不要盲目把上传并发拉高。
速度记录要区分 Bot 完成时间与云盘官方可用时间。理论估算见 流式与速度。