比较两份客户端配置时，先决定要验证哪个变化，再保持其余条件尽量一致。一次换节点、协议、DNS 和路由模式，即使速度提高，也无法知道真正原因。有效的对照测试不追求截图好看，而是让结果能够指导下一次修改。
从问题而不是参数开始
先写一句可以被结果支持或否定的问题。例如“为这个应用调整解析路径，能否减少首次连接失败”，比“哪份配置最好”更适合测试。前者有具体任务和指标，后者把速度、稳定性、功耗及隐私需求混在一起，很难得出有用结论。
确定基线配置甲和候选配置乙，只保留一个有意变化。两份文件都保存版本，凭证继续留在私有位置。客户端界面可能生成新的运行配置，因此还要确认最终生效内容确实只有预期差异，而不是仅比较源文件。
官方内核配置文档可以帮助理解字段作用，却不能替自己的网络给出性能结论。本文的实验流程属于编辑建议，不是某个客户端的官方评分标准。涉及语法与兼容性时仍应核对对应版本说明。
选对观察指标
首次连接问题记录成功率、错误阶段和完成时间；长连接问题记录中断次数和恢复时间；吞吐量问题记录持续区间而非单个峰值。不要用一个延迟数字替代全部体验。若关注日常网页，测试任务应包含实际打开页面，而不是只跑大文件下载。
提前定义失败如何记录。超时不能从样本中删除，也不能任意算成零毫秒。可以单独列出失败数量与原因，再比较成功请求的耗时。样本少时直接展示原始记录，比给出看似精确的综合分数更诚实。
保持测试目标和内容一致。不同文件大小、缓存状态、登录状态及服务端负载都可能影响结果。无法控制的因素要记录为限制，不要用“环境相同”四个字掩盖实际差异。测速窗口的概念见单位与时间窗口。
交替测试比先后各测一次更可靠
可以在允许的流量预算内采用甲、乙、甲、乙的交替顺序，尽量缩短每组之间的时间差。这样有助于观察晚高峰变化是否同时影响两份配置。它仍不能消除全部外部变化，所以结果应描述为当前条件下的观察。
每次切换后确认新配置已经生效，再重新建立需要测试的连接。旧长连接可能继续工作，缓存也可能使第二次请求天然更快。是否清缓存应与真实使用目的匹配，并在两组采取相同方法；不要只对其中一组做额外优化。
不要同时运行两个会争用系统代理或虚拟接口的客户端来做比较。竞争状态本身就会改变结果。需要快速切换时，也应按明确顺序停止旧接管、启动新接管并验证路径，而不是凭托盘图标判断。
一个规则调整的示例
以下是假设场景：某办公应用首次加载偶尔失败，怀疑目标的一部分域名走了不同策略。甲为原配置，乙只调整相关域名规则，节点和解析保持原样。测试记录包括启动任务、命中规则、所选出站、是否完成以及错误信息。
如果乙连续出现正确命中且失败减少，说明这个调整值得继续观察，但还需要检查其他功能是否受到影响。如果乙仍失败而规则已经按预期命中，就应转向连接或服务端条件，不再扩大规则范围。具体规则规划可参考分流规则实战。
若测试期间订阅自动更新，或自动选择策略切换了节点，应标记相关轮次不能直接比较。自动化并非坏事，但它改变了实验条件。必要时在可控时间内使用固定测试选择，结束后恢复自己的日常策略。
把结论限定在证据范围内
合理的结论可以是“在本次网络、任务和时间窗口下，乙减少了首次连接失败，仍需观察移动网络”。不合理的结论是据此宣布某个内核全面优于另一个，或保证某套餐长期稳定。证据覆盖到哪里，结论就写到哪里。
对于没有差异的结果也要保留。它说明当前修改没有解决目标问题，可以避免以后重复尝试。需要更长周期观察时，沿用网络观察日志记录，不要每天改变测量方法。
最终只保留有效改动，并回收测试时添加的临时开关、任务和日志等级。把候选配置为何被接受或拒绝写成两三句话。一个能解释的普通配置，往往比积累许多没有证据的“优化参数”更容易维护。
决定何时停止实验
开始前给测试设定时间和流量预算，并写下足以支持下一步操作的条件。例如，目标是判断一条规则是否命中，那么取得清晰的命中记录后就可以转向实际任务验证，不需要继续运行高流量测速。测试目的不同，停止条件也应该不同。
如果连续几轮结果相互矛盾，应先检查网络变化和自动策略，而不是只增加轮数期待出现漂亮平均值。将不确定性保留为结论，可以避免错误部署。对于会影响他人的家庭网络或工作设备，还要规定恢复时间；实验结束后确认打印、会议和后台同步等普通任务没有因临时配置受到影响。
参考资料
- Mihomo 配置文档，核验日期：2026-10-15。
- sing-box 配置文档，核验日期：2026-10-15。本文的对照方法为编辑建议，不构成实际测评结果。