故障排查与问题报告

排查时一次只改变一个变量，并先判断问题属于网络、认证、权限、驱动、扩展、客户端状态还是远端服务。记录 Navop 版本、平台、连接类型、发生时间和最小复现步骤，避免用更高权限掩盖根因。

数据库、Redis 与 MongoDB

数据库失败先检查 DNS、主机、端口、防火墙、账号、默认数据库、Schema、TLS、代理和 SSH 隧道，再检查驱动与服务器版本。SQL 错误应缩小到单条语句，并确认当前事务是否需要提交或回滚。对象不可见时检查权限和 Schema 过滤。

Redis 还需确认单机、Sentinel、Cluster 模式和节点可达性；重定向失败常与 Cluster 节点地址有关。MongoDB 检查连接字符串、认证数据库、TLS、副本集发现与 BSON 查询类型。不要用 FLUSH、删除集合或关闭证书验证作为诊断捷径。

SSH 依次检查主机指纹、用户名、密码或私钥、文件权限、SSH Agent、MFA、代理和服务器日志。能登录但 SFTP 失败时，再检查子系统、目录权限和磁盘。上传中断后比较远端大小，远程编辑冲突时保留双方内容。

终端乱码通常与远端 locale、字体或编码有关；分屏和广播异常先确认选中会话。端口转发失败应区分本地端口占用、SSH 断开、目标拒绝和监听地址错误。

扩展功能缺失时确认扩展已安装、启用、与当前平台和 Navop 版本兼容，并尝试重载。数据库驱动、ACP Agent 和远程桌面 Provider 都可能有独立日志。升级前工作的扩展在升级后失败，应记录两侧版本并测试兼容组合。

RDP/VNC 黑屏或认证失败需检查 Provider、Domain、证书、远端会话策略和网络。Serial 乱码则核对设备占用、波特率、数据位、停止位、校验位与流控。

模型请求失败时检查 Provider 状态、API key、base URL、模型名、网络和额度。工具未出现时确认当前模式、资源引用和权限。ACP 登录或授权成功不保证 Public MCP 自动放行，二次审批属于正常设计。

Public MCP 依次检查 Navop 是否运行、服务模式、Node.js 20+、npx、客户端配置、discovery 权限、Tool Exposure 和实时 Schema。endpoint 重启后让客户端重连，不要继续使用缓存端口或猜测资源 ID。

同步失败先确认登录账号、网络、主密钥、团队密钥、成员权限、客户端版本和冲突状态。主密钥遗失无法通过官网恢复；不要把密文数据库上传到公开渠道。团队轮换期间避免并发批量编辑。

更新失败时检查磁盘空间、安装包架构、系统安全策略和扩展兼容性。回退前备份本地数据目录，并确认配置格式是否兼容。

从设置找到日志路径，截取与发生时间相邻的最小片段。报告应包含平台、Navop 与扩展版本、预期结果、实际结果和可重复步骤。可以提供虚构主机、示例 Schema 和最小 SQL 来重现。

提交前删除密码、API key、Token、主密钥、SSH 私钥、证书私钥、完整连接字符串、内网地址、个人数据和业务结果。截图也要检查标签名、终端历史和文件路径。若问题涉及数据破坏，先停止重复操作并保存备份、日志和服务器审计证据。