10 月中旬前后，iPhone 侧载圈子里这两天算得上集体翻车：AltStore、SideStore、Sideloadly、iloader 这些常用签名工具，几乎在同一时间段登录 Apple ID 时弹出同一句提示——「This action cannot be completed at this time.（-80045）」。不少用户第一反应是密码错了或者账号被封，重置密码、换数据线折腾半天毫无效果。实际上这不是你这边的问题，而是苹果在服务端收紧了校验。这篇教程把报错含义、各工具的修复进度和能落地的自救步骤一次讲清。
报错含义：不是密码错，是设备身份被拒
从 10 月 12 日开始，免费签名工具的 Apple ID 登录请求被苹果服务器成批拒绝，返回的就是 -80045。拒绝发生在密码校验之前，账号密码根本还没走到验证那一步，所以改密码没有意义。
要理解这次风波，得先知道 anisette 是什么。侧载工具登录 Apple ID 时，需要附带一组设备身份数据，用来向苹果证明请求来自一台真实的苹果设备，社区把这组数据叫 anisette。公共 anisette 服务器大多用安卓的核心代码生成这份数据，却对外声称自己是 Mac 或 Windows 客户端。苹果这次开始严格核对请求头里的客户端信息与 User-Agent 是否和生成数据的设备一致，对不上的请求直接拒绝，一部分安卓特征的请求后来干脆收到 503 错误页。同一个账号在某个工具里能登、换一个就报错，原因就在这里。
苹果没有给出官方说明，开发者们只能各自调整实现，所以修复是分批落地的。
先更新：iloader 与 Sideloadly 的修复进度
iloader 是这一波里恢复最快的。2.3.7 版本在 10 月 13 日首次修复登录问题，苹果随后又调整了两次策略，官方在 10 月 15 日到 18 日之间接连放出 2.3.8 到 2.3.10，跟着切换新的 anisette 服务器。实际用下来，把 iloader 更到最新、并且只用它内置列表里的服务器（自定义服务器地址已经全部失效），登录基本能恢复正常。设备端安装器 SideInstaller 也在 1.5.0 修复，后续持续跟进到 1.5.3，不过作者提醒，由它装出来的 SideStore 和 LiveContainer 本体还得等各自修复。
Sideloadly 这边，当前版本 0.71.0 重写了向苹果发起登录的方式，更新日志没有明确点名 -80045，考虑到登录逻辑确实动了，先到 Sideloadly 官网把版本更新到最新再试，是成本最低的一步。
SideStore 手动自救：改 anisette 配置的完整步骤
SideStore 目前还没有正式修复版，最新正式版仍是 9 月的 0.7.0-alpha，但 nightly 测试版已经带上 10 月 13 日的双重认证修复，官方问题追踪区给出的临时改法被不少人验证有效：
- 用 iLoader 等工具把最新 nightly 版 SideStore 覆盖安装到手机上；
- 进设置里的 User Customizations，关闭 On-Device Anisette，重启应用；
- 打开 Anisette Client Configuration，在 Client Info 里填入 <PC> <Windows;6.2(0,0);9200> <com.apple.AuthKit/1 (com.apple.iTunes/12.12.4.1)>，User Agent 填 akd/1.0 CFNetwork/808.1.4，注意首尾不要多出空格，保存覆盖；
- 强制退出并重开 SideStore，重新登录 Apple ID，验证码用受信任设备上弹出的六位码；
- 仍然失败的话，重置 adi.pb 数据、换一个 anisette 服务器再走一遍。
这套改法的思路，是让 SideStore 以 Windows iTunes 的客户端特征去请求苹果，能救回一部分账号，但不是人人有效。完整讨论可以在SideStore 官方仓库的问题追踪区看到。
AltStore 现状：官方修复在路上，Windows 用户多留一步
AltStore 团队在 10 月 13 日表态称问题疑似出在苹果侧，社区补丁一度没有合并。转机出现在 10 月 21 日：AltStore Classic 2.3.1 与 AltServer for macOS 1.8.2 同步发布，把 macOS 27 上生成身份数据的方式切换到 Windows anisette v3 服务器，官方 Mac 通道恢复可用。升级路径是先在 AltServer 菜单里点 Check for Updates，再到 My Apps 标签更新 AltStore；应用自身更新失败的话，用新版 AltServer 覆盖安装即可，官方特意提醒不要先删除旧应用。
Windows 用户要多留个心眼：修复发布几小时后，部分 AltServer 用户又碰到了新的 -80046，提示文字一模一样。官方建议临时继续用 Remote AltServers 连接远程服务器，本地 Windows AltServer 的修复还在跟进。项目动态见AltStore 官方 GitHub。
替代方案：LiveContainer 一拖多的思路
如果暂时修不好登录，可以把应用塞进 LiveContainer 过渡。它的原理是把其他应用当作库加载进宿主应用里运行，iOS 只看到 LiveContainer 这一个应用，免费 Apple ID 的三应用限额对容器内的应用不再生效。10 月 4 日官方 GitHub 仓库被隐藏后，最后的官方构建是 9 月 18 日的 nightly（版本号 3.8.10），目前通过社区镜像LiveContainerMirror分发，下载后务必核对官方公布的 SHA-256 哈希再用，来历不明的改版包能读到你容器里的全部数据。
要注意 LiveContainer 只解决应用位数量，7 天一次的签名刷新依然要靠 SideStore 或 AltStore 完成，登录通道被卡住时它一样签不了名。所以它更适合当作节省应用位的长期方案，而不是这次报错的直接解药。
注意事项
- 别反复重试同一个 Apple ID，失败次数太多会被苹果限流，越试越登不上；换一个网络环境或备用账号是更常见的出路。
- 双重认证验证码只用受信任设备弹出的那一种，短信验证码通道在多个工具里目前是坏的。
- 如果报错从 -80045 变成了 -22411，说明已经越过了封锁，苹果把验证码改成了自动下发，等支持新流程的版本更新即可。
- 多台设备侧载尽量各用各的 Apple ID，共用账号容易陷入互相吊销证书的死循环。
- 配对文件包含设备身份，不要发给任何人；网传改 DNS 屏蔽苹果服务器、安装来路不明的第三方验证服务，都不要尝试。
总结
这次 -80045 风波，本质是苹果收紧了免费签名通道的设备身份校验，把借来的身份拦在门外，殃及所有第三方侧载工具。对普通用户来说，眼下最稳的路径是：iloader 和 Sideloadly 优先更新到最新版，SideStore 用 nightly 加手动配置过渡，AltStore 等 2.3.1 之后的版本铺开。这类拉锯每隔一段时间就会来一轮，工具修好一个就用一个，别把常用账号折腾到限流。
不少侧载用户也在社区里留下了自己的经历：
- iloader 更新到 2.3.10 之后一次就登上了，比想象中顺利。
- SideStore 那串 Client Info 填完真的能过，但我的小号还是 -80045，看脸。
- 等了快两周才有像样的修复，这期间签名早就过期了，只能干着急。
以上评论仅代表网友个人观点，不代表官方立场。
