#故障排查

先确定当前账号、Space、Device/Node 与连接状态，再检查资源授权和真实网络。以下顺序尽量只读。

ns --version
ns info
ns status --all
ns doctor

#浏览器授权完成但客户端仍未登录

确认回到发起登录的同一个 App/终端，浏览器账号正确且旧授权标签页已关闭。退出当前流程再发起一次新会话，不连续打开多个回调。记录发生时间、平台、App/CLI 版本与活动日志；不要发送 token。卸载不保证清除系统安全存储，因此不是首选诊断。

#登录后没有 Space 或资源

管理员在 用户核对账号成员关系，在左上角核对 Organization/Network，在 访问授权核对主体和资源。成员首页/Node/Service 应按可见范围返回；只授权某 Node 时不应看到其他 Node。新授权后等待一次权威刷新，不使用旧 Network 缓存覆盖。

#刚登录或切换后连接 busy

等待当前切换确认，避免重复点击。关闭重复 App 实例，或先 ns down 再连接。资源刷新优先级低于连接，不应让已确认 Profile 的连接持续失败；若可稳定复现，提供准确时间帮助定位 Core owner 与 refresh 争用。

#Space 切换一直加载

网络慢时加载弹层会阻止冲突操作，超时后允许取消。取消后界面必须显示实际 Space；CLI 用 ns info 与 ns space list核对。结果不确定时保持断开，不自动启动旧/新 Network。

#服务可见但无法访问

依次核对：当前 Space → 已连接 → Service 所属 Node 在线 → L4 授权 → services.toml → Node 本机端口/防火墙。目录可见与数据通道连接是两个状态。

#Node ping 不通

核对双方 Node IP、双方连接、L3 授权与当前 Network；再检查目标主机 ICMP 防火墙。用 SSH/明确端口交叉验证。被授权整个 Node 才应看到其必要地址信息。

#出口无法开启

先选择已授权出口；未选择时 App 提示“请先选择出口”。再核对网关在线、Exit 能力、访问授权和重连。不要把“指定服务出网”当作默认互联网出口。

#系统网络残留

先正常 ns down 并退出 App。ns doctor 后仍异常时执行普通 sudo ns reset，它保留身份与 Profiles。只有确定重新注册新 Device 才执行 sudo ns reset --all --yes。

#反馈

执行 ns report 获取预填入口；提交前检查内容。最小材料：时间/时区、版本、OS、预期和实际 Space、复现步骤、错误截图、ns doctor 与脱敏日志。