115 网盘限流与目录缓存调优
为什么 115 特别容易 429
115 对接口请求频率限制较严。挂载盘一旦被某个程序高频遍历（刮削器扫库、备份扫描、资源管理器缩略图预读），请求量瞬间放大，服务端直接回 429 Too Many Requests。这不是软件故障，是网盘侧的风控在正常工作。
症状
- 挂载盘浏览突然变慢或报错，过一阵自己恢复
- 媒体库刮削到一半集体失败
- 任务页大量 429 错误
调优四步（按顺序做）
- 开目录缓存持久化：系统设置里勾上，目录列表落盘缓存，重复浏览不再反复打网盘接口——收益最大的一步
- 拉长默认目录缓存时长：缓存越久，同样操作产生的请求越少；115 目录不常变的话可以放得很长，机制见目录缓存与上传临时目录的权衡设置
- 收敛刮削与扫库节奏：媒体库刮削别开「立即全量刷新」，错峰、小批量跑；大扫库安排在夜里
- 优先走开放接口：115 提供官方 Open 接入方式，选它比走通用接口稳，背景见支持挂载的网盘与协议存储清单
用访问监控找元凶
到底是谁在狂发请求？开访问监控（见访问监控与按进程的权限控制），看实时列表里哪个进程的读取量异常，把不必要的拉黑或改配置——比盲调有效得多。
刮削玩家的完整组合
115 + 媒体库的重度用户，社区沉淀的完整节奏是：
- 挂载 → 媒体库直连（见挂载盘直连媒体库免下载看片）
- 变更通知接管自动扫盘（核心 Pro），刮削只在新增时小跑
- 缓存持久化 + 长缓存时长打底
- 需要软链与 strm 的，监控工具的扫描间隔也拉长，见网盘加软链与 strm 的进阶媒体方案
其他网盘限流了吗
429 式限流不独属 115，百度等也有各自的频控——思路通用：缓存打底、节奏放慢、监控定位。差异只在各家的阈值与恢复窗口，以实际报错为准。