ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

AList 接入 PikPak 令牌失效?3 步修复 Refresh Token 过期

AList 接入 PikPak 令牌失效?3 步修复 Refresh Token 过期 AList 接入 PikPak 令牌失效3 步修复 Refresh Token 过期【免费下载链接】alist️A file list/WebDAV program that supports multiple storages, powered by Gin and Solidjs. / 一个支持多存储的文件列表/WebDAV程序使用 Gin 和 Solidjs。项目地址: https://gitcode.com/GitHub_Trending/al/alist当 AList 里的 PikPak 文件夹突然转圈、点文件没反应、报错 AList PikPak 401 错误时十有八九是令牌问题。这篇带你走完整条链路先做诊断确认病灶再按成本从低到高动手恢复最后把 PikPak 刷新令牌失败的复发概率压下去。现象自查 判断标准很简单同机器的其他云盘本地、OneDrive正常唯独 PikPak 挂载点异常且错误集中在 401 或错误码 412x基本可以锁定是 AList 云盘访问异常里的令牌环节。动手前先过一遍这份清单排除干扰项其他存储local / OneDrive 等正常只有 PikPak 挂载点 401 或无响应报错里反复出现4121 / 4122 / 4126这类 PikPak 错误码用 PikPak 手机 App 或网页能正常登录排除账号被封服务器能curl通api-drive.mypikpak.net排除网络/代理问题近期改过密码、在别的设备上登录过或更换了出口 IP原理速览结论先行AList 的 PikPak 驱动是双令牌协作——长期靠 Refresh Token 维持登录态每次调 API 用短期有效的 Access TokenAccess Token 一过期就自动换新并重放请求正常时你根本感知不到。关键分支就这两段drivers/pikpak/driver.go 决定要不要重新登录if d.Addition.RefreshToken ! { if err d.refreshToken(d.Addition.RefreshToken); err ! nil { return err } } else { if err d.login(); err ! nil { return err } }拿到令牌后request把Bearer access_token挂到每个 API 请求头。服务端回4122 / 4121 / 16Access Token 过期时驱动自动刷新一次并重试原请求——这是响应式刷新。而 drivers/pikpak/util.go 里的refreshToken成功时会换回一对新令牌并op.MustSaveDriverStorage(d)落库所以数据库里存的 Refresh Token 一直在滚动。失效按时间线看有三段1~2 小时是 Access Token 的自然寿命驱动会自动续一般无感7~30 天不活动Refresh Token 本身到期自动刷新失败还有与时间无关的第三种——换设备、换 IP、改密码或 PikPak 风控直接把旧令牌吊销。急救修复按成本从低到高 3 条路径 ️三条路径都能救顺序即推荐顺序先试最省事的。路径 A只替换 Refresh Token适用账号密码没变只是 Refresh Token 失效或你手头有现成的新 Refresh Token。登录 PikPak 网页端确认账号状态正常拿到新的 Refresh Token或干脆留空交给路径 B 的自动登录AList 管理面板 → 存储 → 编辑该 PikPak只改refresh_token字段保存即触发Init重走认证关键配置字段refresh_tokenusername / password 保持不变作为 4126 时的兜底。路径 B清空令牌触发完整重新登录适用Refresh Token 彻底报废但账号密码还在。编辑该 PikPak 存储把refresh_token字段清空确认username、password是最新的有效凭据保存——Init看到空令牌会走login()拿回双令牌并自动落库路径 C切换 platform 字段适用换了令牌还是反复失效怀疑是某个平台的令牌策略在针对你。编辑存储把platform从web改成android或pc保存观察是否还报刷新失败稳定后固定该平台注意不同平台的 ClientID、User-Agent 各不相同见 drivers/pikpak/driver.go切换等于换了一套客户端身份长效加固多平台冗余 ️自动刷新有一个薄弱点它只在你发请求、且服务端明确回 412x 时才触发。刷新请求本身赶上网络抖动、代理抽风refreshToken直接报错返回、不会重试错误被写进存储的 Status 字段而 PikPak 的 Refresh Token 又对闲置敏感7~30 天没人访问令牌先于你到期。所以最稳的姿势是 PikPak platform 切换做冗余同一账号建两个存储实例android做主力pc做热备一个平台策略抽风时另一个顶上来。精简配置示例Web 界面新建两个存储即可[ { name: pikpak-main, mount_path: /pikpak, driver: PikPak, username: you, password: pwd, platform: android }, { name: pikpak-backup, mount_path: /pikpak-bk, driver: PikPak, username: you, password: pwd, platform: pc } ]疑难定位grep 一行加错误码对照 先抓日志一行命令锁定刷新失败现场路径按你的部署改grep -nE 4122|4121|4126|refresh_token|work /path/to/alist/data/log.log | tail -50错误码含义定义在 drivers/pikpak/types.go 的ErrResp常用对照错误码含义处置动作4122 / 4121Access Token 过期驱动会自动刷新若反复出现检查 Refresh Token 有效性4126Refresh Token 无效走路径 A/B已配账号密码时驱动会自动补登录9验证码 token 过期按提示打开验证链接完成后刷新页面16令牌过期或账号权限不足先确认账号没被风控再试刷新顺带纠个错当前版本的 CLI 只有alist storage list和alist storage disable没有alist storage test子命令。想测配置就在 Web 管理界面保存一次存储触发Init成功与否会直接显示在存储状态里或调 API 验证curl -H Authorization: Bearer token AList地址/api/fs/list?p/挂载点。最后四条别踩坑的提醒定期备份refresh_token和device_id前者是救命稻草后者是设备指纹别乱改账号别频繁换设备、换网络环境登录风控一触发多好的令牌都白搭看到日志里自动刷新失败别硬等趁密码还热乎赶紧走路径 B 重登跟进 AList 和 PikPak 的版本更新driver 里内置的 ClientID、算法串是跟着对方客户端走的本文基于 AList v3.x当前仓库 drivers/pikpak 目录编写不同版本 CLI 子命令与驱动细节可能有差异以你实际部署的代码为准。【免费下载链接】alist️A file list/WebDAV program that supports multiple storages, powered by Gin and Solidjs. / 一个支持多存储的文件列表/WebDAV程序使用 Gin 和 Solidjs。项目地址: https://gitcode.com/GitHub_Trending/al/alist创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表