#登录、切换与恢复

恢复时先确认“谁、在哪个 Space、谁持有 Core、系统网络是否干净”，再决定是否修改状态。

#推荐顺序

ns info
ns status --all
ns doctor

1. info 核对版本、Device、NSD、Space 与运行持有者；
2. status --all 核对连接和当前数据；
3. doctor 只读检查权限、DNS、进程和 NSD 可达性；
4. 必要时 ns down，关闭 App 后重试；
5. 系统网络残留时执行普通 ns reset；
6. 只有身份本身必须废弃时才 ns reset --all --yes。

#多账号登录异常

退出 A 账号后登录 B 账号时，先让 A 的浏览器授权流程结束或失效，再从 App 发起 B 的新会话。若 B 一直“等待授权”，关闭旧授权标签页，核对浏览器当前账号后重新发起一次。客户端应拒绝旧 session 回调；不要通过卸载 App 猜测解决，因为系统安全存储可能独立于应用文件存在。

#Space 切换卡住

切换会等待服务端确认并阻止同时连接。慢请求超过阈值后允许取消；取消后必须显示实际仍生效的 Space。CLI 可执行：

ns info
ns space list
ns space switch <NETWORK_ID>

切换成功后保持断开，重新 ns up。若界面出现目标 Network 但资源来自旧 Network，立即断开并反馈，这是作用域错误，不能用手动刷新掩盖。

#连接返回 busy

常见于刚登录/刚切换时后台资源刷新与连接争用 Core。连接应优先使用已确认 Profile/Node，刷新可后台重试。先等待当前一次切换完成；若持续 busy，关闭重复 App 实例或执行 ns down 后重连。不要连续快速点击连接开关。

#卸载与完整重置的区别

卸载通常删除 App 文件，但钥匙串/系统安全存储、系统 VPN 配置或共享状态可能保留。普通更新和普通 reset 应保留身份。只有确认要让服务端把本机视为新 Device 时，才完整重置并在 NSD 清理旧 Device；操作前记录 Node/Device ID 以便审计。

#反馈最小材料

• 发生时间与时区；
• App/ns --version；
• 平台与 OS 版本；
• 预期 Space（Organization + Network）和实际界面状态；
• ns doctor、ns info --json（上传前移除任何敏感字段）；
• 一张错误界面或短录屏。不要上传 token、私钥、完整邀请或真实客户数据。