设备在多个同名热点之间切换时，连接可能短暂中断。问题常被误判为应用崩溃。
版本更新后出现变化时，先记录系统、应用版本和发生时间。保留这些信息，后面无论恢复设置还是联系支持都会更有效率。
先看现象，不要先猜原因
最有效的第一步通常不是修改，而是对照。找一台正常设备、一个正常账号或一条正常网络，使用相同样本比较结果。差异出现在哪里，就从那一层继续缩小范围。
| 观察到的情况 | 更合适的第一步 |
|---|---|
| 只在一台设备出现 | 优先看本机权限、存储、后台任务和网络，不要先改账号。 |
| 换网络后恢复 | 保留网络差异，继续比较 DNS、代理、路由或运营商限制。 |
| 所有设备同时出现 | 记录准确时间和共同版本，再判断服务状态或统一配置。 |
| 偶发且难以复现 | 缩小变量，连续完成三次同样的小任务并记录结果。 |
按顺序处理，每一步都要复测
1. 记录问题发生的位置
处理“记录问题发生的位置”前先说明预期结果和回退方法。完成后用固定样本验证，并检查是否影响其他设备、账号或文件。
2. 查看实际连接的接入点
进行“查看实际连接的接入点”时不要顺便更新软件或清理数据。保留对照条件，测试完成后只留下确实有效的改动。
3. 固定一个位置做基准
执行“固定一个位置做基准”时先保存当前状态，只改变一个条件。操作后立即回到原场景复测；没有变化就恢复原值，不把无关改动带到下一步。
4. 关闭再开启无线网络复测
把“关闭再开启无线网络复测”做成可重复的小动作，记下开始时间、使用设备与结果。连续两次得到相同结果后再继续，避免把偶然恢复当成结论。
5. 必要时调整热点功率和漫游设置
处理“必要时调整热点功率和漫游设置”前先说明预期结果和回退方法。完成后用固定样本验证，并检查是否影响其他设备、账号或文件。
原来的现象不能再稳定复现，核心任务连续完成两次，重新打开程序后结果仍然一致；同时清楚哪项改动有效、怎样恢复原值，才算真正完成。
无线漫游场景还要多看一层
网络问题需要把解析、建立连接、持续传输和应用处理分开。一次测速只能说明当时的大致吞吐量，无法替代延迟、丢包、抖动和不同时间段的对照。调整 DNS、代理、路由或防火墙前先保存原值，测试后及时恢复无关改动。
个人使用时可以把记录控制在一页以内：上半部分写现象和环境，下半部分只写有效步骤。下一次遇到相同问题，先照这页复测；如果环境已经变化，再新增一条记录，不要覆盖旧结论。这样既能保留历史，也不会形成没人愿意看的长文档。
先确认问题边界
先回答三个问题：从什么时候开始、是否只影响一台设备、最近改过什么。能明确其中两个，排查范围通常已经缩小一半。若所有环境同时异常，不要反复重装客户端。
把真实任务当作验收标准
设置页面显示成功只是中间状态。真正的验收是重新打开程序，完成一次平时最常做的任务，并在另一台设备或另一个账号上确认结果。团队场景还要让接手的人能照记录复现。
一个可直接照着做的小例子
例如上午九点电脑端出现异常、手机端正常。先记下两端版本和网络，用同一对象完成最小测试。若只有电脑失败，就从电脑权限、存储和网络查起；若换手机热点后恢复，继续检查本机网络配置，而不是退出所有设备。
常见误区
- 从不相关的设置开始调整，改动范围不断扩大。
- 忽略系统时间、存储空间和后台任务。
- 在公共或共享设备留下自动登录。
- 未恢复测试用权限和临时文件。
把结果留给下次
保存三类证据就够用：准确时间、版本与设备、最后一个正常步骤。敏感信息先遮挡，验证码和密钥不进入记录。后续需要支持时，这三类信息比一大段描述更有用。
常见问题
是不是重装最快？
只有程序文件损坏时，重装才可能直接有效。账号、网络、权限和数据问题不会因为重装自动消失，反而可能先清掉本地线索。
需要连续测试多久？
至少覆盖两次真实任务和一次程序重启。网络类问题最好再跨一个不同时段复测，避免把短时恢复当作长期稳定。
哪些内容不应该写进排查记录？
验证码、完整密钥、密码、个人证件和不必要的客户隐私都不应保存。需要截图时先裁切和遮挡，记录现象而不是敏感值本身。
最后检查
重新启动 Clash 后，不看设置页面，直接执行最常见的真实任务。确认结果稳定，再恢复为测试而修改的无关选项，并保存最终记录。