先把连接失败写成可重复场景
节点连接失败可能发生在读取配置、发起连接、建立通道或访问目标任务之后。先记录第一条可见提示、发生时间、设备、系统版本、网络类型和配置更新时间。只写失败不写阶段，无法判断下一步。
选择一个低风险的普通任务作为固定目标，保持设备和网络不变完成两次测试。若两次停止点不同，先延长观察，不要立即宣布节点异常。
按顺序比较条件
第一轮比较网络，例如从家用Wi-Fi切到移动热点；第二轮恢复原网络，只更换设备；第三轮才核对配置更新时间。每轮保持目标任务与观察窗口一致。受控对照可以缩小范围，但单次成功或失败不能证明总体服务状态。
若同一设备在两个网络结果不同，继续检查本地DNS、网络限制和系统代理状态。若同一网络下只有一台设备异常，优先比较系统权限、客户端版本和本地缓存。
核对配置时间而不是只看名称
两个设备显示相同配置名称，不代表内容与更新时间一致。记录最后刷新时间、可见条目数量和更新后的第一条结果，不公开完整配置。旧设备正常而新设备异常时，先比较版本与刷新时间，再考虑重新导入。
重新导入前保存脱敏基线，并确认来源属于自己的已验证账号流程。反复导入会覆盖原有对照点，也可能让配置问题和网络问题混在一起。
把节点判断限制在证据范围
一台设备的一个任务失败，只能说明这组条件下没有完成目标。多台设备、两个网络在同一时间窗口出现相同停止点，才形成更强的共同条件线索；仍不能仅凭客户端画面确认实时维护或全局节点状态。
形成脱敏记录后，可提交设备类别、系统、App版本、配置刷新时间、网络类型、测试窗口和错误原文。密码、验证码、Cookie、付款资料与完整订阅地址全部排除。
恢复后再做反向验证
现象消失时恢复原条件再测试一次。如果恢复原网络后问题重新出现，网络条件的关联更强；如果结果没有重现，只记录暂时恢复，不写成永久解决。
保留成功与失败两种记录，让以后版本更新或设备迁移时可以复用相同方法。