系统刚进入桌面时，网络、代理、安全软件和应用会同时启动。依赖顺序不稳定时，应用可能先失败再等待重试。
这类问题适合先做一个小样本，不需要一次调整所有设置。每完成一步就回到原场景复测，并把发生变化的时间记下来。
先看现象，不要先猜原因
排查前先做快照式记录：截取当前页面、记下版本和网络，再执行一次最常见的小任务。不要在测试过程中顺手更新、清缓存或切换多个账号，否则对照条件会被破坏。
| 观察到的情况 | 更合适的第一步 |
|---|---|
| 只在一台设备出现 | 优先看本机权限、存储、后台任务和网络，不要先改账号。 |
| 换网络后恢复 | 保留网络差异，继续比较 DNS、代理、路由或运营商限制。 |
| 所有设备同时出现 | 记录准确时间和共同版本，再判断服务状态或统一配置。 |
| 偶发且难以复现 | 缩小变量，连续完成三次同样的小任务并记录结果。 |
按顺序处理，每一步都要复测
1. 记录开机到网络可用的时间
进行“记录开机到网络可用的时间”时不要顺便更新软件或清理数据。保留对照条件，测试完成后只留下确实有效的改动。
2. 确认应用是否过早自启
处理“确认应用是否过早自启”前先说明预期结果和回退方法。完成后用固定样本验证，并检查是否影响其他设备、账号或文件。
3. 检查代理或安全软件启动顺序
执行“检查代理或安全软件启动顺序”时先保存当前状态，只改变一个条件。操作后立即回到原场景复测；没有变化就恢复原值，不把无关改动带到下一步。
4. 手动启动做对照
把“手动启动做对照”做成可重复的小动作，记下开始时间、使用设备与结果。连续两次得到相同结果后再继续，避免把偶然恢复当成结论。
5. 只调整一个启动项后复测三次
由一人完成“只调整一个启动项后复测三次”，另一人只记录时间和现象。若结果与预期不同，先停下并恢复原设置，再讨论下一项。
完成意味着现象、原因边界和有效动作都被记录。即使仍不能确认最终原因，也应知道问题只出现在哪个设备、网络或版本，从而避免扩大改动。
启动连接场景还要多看一层
网络问题需要把解析、建立连接、持续传输和应用处理分开。一次测速只能说明当时的大致吞吐量，无法替代延迟、丢包、抖动和不同时间段的对照。调整 DNS、代理、路由或防火墙前先保存原值，测试后及时恢复无关改动。
个人使用时可以把记录控制在一页以内：上半部分写现象和环境，下半部分只写有效步骤。下一次遇到相同问题，先照这页复测；如果环境已经变化，再新增一条记录，不要覆盖旧结论。这样既能保留历史，也不会形成没人愿意看的长文档。
记录要短，但必须能复用
一条有效记录至少包含日期、设备、版本、网络、改动和结果。不要只写“已修复”或“恢复正常”，因为下次无法判断当时改了什么。把截图与文字放在同一目录，并使用能看懂的文件名。
先确认问题边界
先回答三个问题：从什么时候开始、是否只影响一台设备、最近改过什么。能明确其中两个，排查范围通常已经缩小一半。若所有环境同时异常，不要反复重装客户端。
一个可直接照着做的小例子
团队成员反馈“偶尔不行”时，让对方在下一次出现问题的当下记录时间、设备和最后一步，不要事后凭印象回忆。收集到两到三次一致记录后，再安排改动，通常更容易找到共同条件。
常见误区
- 只在管理员账号测试，忽略普通用户权限。
- 清理前没有抽样打开备份。
- 反复点击重试，触发频率限制。
- 问题暂时消失就删除日志和截图。
把结果留给下次
最终记录可压缩为五行：现象、环境、改动、结果、回退方法。文件名加入日期和版本，截图只保留相关区域。记录不必很长，但必须让没有参与处理的人也能复现。
常见问题
是不是重装最快？
只有程序文件损坏时，重装才可能直接有效。账号、网络、权限和数据问题不会因为重装自动消失，反而可能先清掉本地线索。
需要连续测试多久？
至少覆盖两次真实任务和一次程序重启。网络类问题最好再跨一个不同时段复测，避免把短时恢复当作长期稳定。
哪些内容不应该写进排查记录？
验证码、完整密钥、密码、个人证件和不必要的客户隐私都不应保存。需要截图时先裁切和遮挡，记录现象而不是敏感值本身。
最后检查
让实际使用者在 Clash 中完成一次日常流程，处理者只观察不提示。若对方能够顺利完成，并且没有新增弹窗、权限或文件问题，就可以结束本次调整。