Chatbox 1.22.3 换机导入后服务商不能用先检查 Settings 和 API KEYChatbox 换机或重装后最容易混淆的现场有两个自定义服务商根本没迁过来服务商名称、API Host 和模型都在但对话仍然提示鉴权失败。两者不能用同一个动作修复。前者通常要回到导出范围后者则要确认备份是否按你的选择排除了凭据。本文只解决一个具体问题Chatbox 1.22.3 使用 ZIP v2 备份迁移后怎样在不打印任何 Key 的前提下判断自定义服务商卡在哪一层。先做最小检查环境、位置、命令和成功信号适用环境Chatbox1.22.3官方设置页注明 ZIP 备份只能导入 Chatbox1.22或更高版本。导出入口Settings - General - Data Backup导入入口在同页的Data Restore。目标是迁移自定义服务商的非敏感配置Provider、API Host、模型清单。真实 API Key 不进入本文命令、日志或截图。最小导出选择至少勾选[x] Settings [ ] API KEY License这是一条更安全的迁移路径先迁移配置导入后再从自己的安全存储中重新填写凭据。官方 v1.22.3 源码会在未勾选API KEY License时移除 provider credential但保留apiHost等非敏感字段。不要先解压并cat settings.json。若导出时曾包含 credential这样会直接把敏感值打到终端历史。只读 manifest 就够做第一层判断BACKUPchatbox-backup-2026-8-24.zipunzip-p$BACKUPmanifest.json\|jq{format, formatVersion, application, exportItems, settings: .data.settings.path, warningCount: .stats.warningCount}第一层成功信号应包含format: chatbox-backup formatVersion: 2 exportItems: [..., setting, ...] settings: settings.json失败路径也很直接如果exportItems没有setting或settings是null这份归档没有导出设置。不要在新机器上反复导入回原机器重新导出一次。为什么“服务商还在”和“已经可用”不是一回事Chatbox v1.22.3 把导出范围拆成四类Settings、API KEY License、Chat History和My Copilots。设置页源码的默认选择包含 Settings、会话和 Copilot但不包含 Key。因此一次安全导出可以同时出现以下两个事实settings.json中仍有自定义服务商 ID、名称、API Host 和模型信息。provider 的apiKey、OAuth、Access Key、Secret Key、Session Token 等 credential 已被移除。这不是导入损坏而是导出选项生效。新机器导入后看到 Provider 并不代表能直接调用它只说明非敏感配置被迁移。要恢复可用状态还需要在 Chatbox UI 中重新安全填写凭据再做一次最小对话。第一步先核对归档版本不猜旧格式Chatbox 当前手动备份格式是带版本的 ZIP。根目录的manifest.json记录应用版本、平台、导出范围、设置条目、每个条目的大小和 SHA-256。历史单 JSON 备份仍有兼容入口但不要把 JSON 教程套到 ZIP v2 上。建议先列目录不展开内容unzip-l$BACKUP最小设置备份至少应看到manifest.json settings.json如果 manifest 的formatVersion不是2不要手工改数字骗过导入。官方导入器只接受明确支持的版本未知版本应回到能识别它的 Chatbox 版本先处理。第二步用选择矩阵判断 credential 是否应该存在导出选择API Host / 模型credential导入后的预期未选 Settings不进入备份不讨论自定义服务商不会随设置迁移选 Settings未选 API KEY License保留移除Provider 可见但需要重新填写凭据选 Settings同时选 API KEY License保留可能进入归档可迁移但归档本身变成敏感文件第三种不是默认推荐。官方测试明确表明勾选后 provider key、OAuth、MCP 环境变量或请求头等用户选择保留的 credential 可能写入备份。此时不要把 ZIP 上传到公共网盘、工单、群聊或文章附件也不要用通用日志工具展开settings.json。对于大多数换机场景更稳妥的是第二种迁移非敏感配置在目标机器重新填写 Key。这样即使 ZIP 被误传也不会因为本文步骤把 credential 打到屏幕上。第三步导入前把覆盖和校验当成正式步骤设置页会提示导入后现有数据可能被覆盖。不要在目标机器已有重要会话时直接试。先用目标机自己的 Chatbox 做一份独立备份并确认文件真实落盘再选择待迁移 ZIP。官方导入器不是“解压后直接覆盖”它先把条目写入临时区再校验 manifest、路径唯一性、条目大小、SHA-256、session/resource 映射和统计校验通过后才 commit。commit 中途失败会恢复之前的 KV/meta 快照并删除新资源。这也解释了另一条失败路径如果有人编辑settings.json后重新压缩却没有同步更新 manifest 的 size 和 SHA-256导入应当被阻断。正确动作是从源机器重新导出而不是关闭校验。第四步导入后必须重启再逐字段回读ZIP 导入完成后Chatbox 的 UI 会要求继续并 relaunch。重启不是装饰动作设置和查询缓存要从持久化状态重新加载。跳过重启就开始判断“字段没生效”会把缓存状态和迁移结果混在一起。重启后只核对非敏感字段自定义 Provider 名称和类型API Host 是否仍是预期主机与版本路径模型 ID 是否存在是否只是展示名如果未迁移 credentialKey 输入框应重新安全填写不截图、不复制到日志保存并再次打开设置确认字段持久化。自定义 Provider 的 v1.22.3 schema 要求id、name、type和settings.apiHostapiPath、apiKey、models是可选字段。因此“服务商卡片存在但 Key 为空”在 schema 上是可能状态不应自动判为归档损坏。第五步用最小对话确认不靠设置页猜成功最终成功信号不是“卡片能看见”而是同一 Provider、同一 API Host、同一模型 ID 能完成一次最小对话。建议使用无副作用的短输入例如只回复 MIGRATION_OK并记录当前 Chatbox 版本Provider 名称与脱敏 Host模型 ID请求时间与时区成功文本或脱敏错误类型。如果设置能保存、重开也存在但最小对话是 401优先回到凭据恢复如果是 404核对 API Host 与路径如果是model_not_found核对真实模型 ID。不要同时改 Host、Key 和模型名否则无法知道哪一项生效。本地实测只审计合成 ZIP不读取真实备份为了验证 manifest、settings、checksum 和安全排除路径我运行了一个 Python 3.9.6 标准库探针。它只在内存中创建合成 ZIP不安装或运行 Chatbox不读取真实备份也不请求任何在线服务。执行命令python3 03-test/audit_chatbox_backup.py脱敏输出PYTHON_VERSION3.9.6 FIXTUREsynthetic Chatbox ZIP v2 in memory FORMATchatbox-backup FORMAT_VERSION2 APPLICATION_VERSION1.22.3 SETTINGS_PATHsettings.json CUSTOM_PROVIDER_COUNT1 PROVIDER_ID_PRESENT1 API_HOST_PRESENT1 MODEL_COUNT1 CREDENTIAL_FIELD_COUNT0 CHECKSUMmatch NO_SETTINGS_STATUSblocked NO_SETTINGS_REASONsettings_not_exported CORRUPT_STATUSblocked CORRUPT_REASONsettings_checksum_mismatch ONLINE_SERVICE_REQUESTNO SUMMARYpass safe_config_only1这组结果只证明审计方法能区分三种归档状态配置完整且无 credential、未导出 Settings、checksum 被破坏。它不能证明真实 Chatbox 已完成导入、重启或在线对话。一张表决定下一步观察结果判断下一步manifest 无setting导出范围不含设置回源机器重新导出勾选 SettingsProvider/Host/模型存在Key 为空很可能是安全排除生效从安全存储重新填写凭据再做最小对话checksum/size 不匹配归档被修改或损坏停止导入重新导出或重新传输导入完成但未 relaunch缓存可能仍是旧状态按 UI 完成重启再回读字段设置重开存在最小对话 401鉴权层只检查 credential不先改 Host/模型设置重开存在最小对话 404路径层检查 API Host、版本前缀和 apiPath设置重开存在model_not_found模型映射层使用服务端真实模型 ID三个不要做1. 不要把真实 settings.json 打到终端即使你认为没有勾选 Key也只读 manifest。真实归档是否含敏感字段应在本机 UI 和安全流程中判断不把内容贴到聊天、Issue 或文章。2. 不要修改 ZIP 后关闭校验size 或 SHA-256 不匹配是保护信号。重新导出比手工修 manifest 更可审计也不会把不受支持的字段强塞进目标版本。3. 不要把“卡片存在”写成迁移成功完整链路是导出范围正确、归档校验通过、导入完成、应用重启、字段回读、credential 安全恢复、最小对话成功。少一步都只能算迁移到一半。总结Chatbox 1.22.3 换机后自定义服务商不能用先不要同时改 Host、Key 和模型。第一步只读manifest.json确认 ZIP v2 和setting第二步按导出时是否勾选API KEY License判断 credential 缺失是不是预期第三步让导入器完成 size/SHA-256 校验并 relaunch第四步回读 Provider、API Host 和模型 ID安全恢复凭据后做一次最小对话。把“设置迁移”和“凭据恢复”拆开既能减少误判也能避免为了排错把真实 Key 暴露在终端、截图或公开内容中。参考资料Chatbox v1.22.3 releaseChatbox 官方数据备份文档备份 credential 清理实现ZIP v2 manifest schema导入校验与回滚实现