本文目录
确认是整组测速误报
本文只处理 Windows 版 FlClash 的整组延迟测试异常：一次刷新后大量节点显示 Timeout，但点开其中一个节点单独测试能返回延迟，选中它也能完成真实访问。
官方 issue #2314 在 v0.8.95 上记录了这一组对照，同一份配置和网络回到 v0.8.94 后批量测试正常。v0.8.96 的发布说明随后明确列出 Windows 整组延迟测试修复。
如果单节点测试、真实请求和同组其他节点都失败，不能把它当成界面误报。此时更可能是节点、测试地址、DNS 或当前网络真的不可用。
先把 Timeout 分成两类
| 观察结果 | 更可能的结论 | 下一步 |
|---|---|---|
| 批量显示 Timeout，单测和真实访问正常 | Windows 整组测速误报 | 记录版本并准备升级 |
| 批量与单测都失败，真实访问也失败 | 节点或网络故障 | 转查节点、DNS 与测试地址 |
| 只有一个代理组异常 | 该组规模或配置差异 | 固定同一组做版本对照 |
| 开启 TUN 后整机断网 | 不是测速显示问题 | 先恢复系统代理并排查 TUN |
保存配置并固定测试条件
升级前先导出 Profile、覆写与应用设置，记录 FlClash 版本、Windows 版本、测试代理组和测试时间。订阅链接可能包含 token，截图和日志中必须脱敏。
本轮只改变客户端版本，不同时更新订阅、切换网络、开启严格 DNS 覆写或调整 TUN。测试条件不变，才能判断 Timeout 是否由整组测速链路造成。
准备一组可重复的样本
备份当前 Profile
保留订阅来源、覆写与当前策略选择，确认备份可以在本机找到。
记录应用版本
在关于或设置页面确认是否为 Windows v0.8.95，并保存版本截图。
固定一个代理组
选择包含较多节点、能够稳定复现大量 Timeout 的同一代理组。
挑选三个红色节点
记录节点名称，后续分别做单测、真实访问和升级后的复测。
用单测与真实访问做对照
从批量结果中选一个显示 Timeout 的节点，先单独点一次延迟测试，再把当前策略切到它并打开一个稳定网页。最后查看连接记录是否出现成功连接和实际出站。
再用另外两个红色节点重复。若多个节点都能单测或完成真实请求，说明批量徽章不能代表节点存活状态；不要立即删除订阅、重置规则或更换全部节点。
完成三层对照
单独测试节点
等待本次结果完成，不连续点击整组刷新，记录是否返回具体延迟。
固定当前节点
在手动选择组中选中该节点，避免自动策略在请求期间切换出口。
发起真实请求
打开平时可稳定访问的页面，并观察是否加载完成。
核对连接记录
确认请求进入 FlClash，并显示刚才选择的节点和成功连接。
单测有延迟，真实请求成功
节点可用，批量 Timeout 可以按本文处理。
单测失败，真实请求成功
检查延迟测试地址与测试链路，不要按节点故障删除。
单测成功，真实请求失败
转查规则、DNS、协议和目标网站，不是单纯批量测速问题。
两者都失败
先换网络或固定其他节点，按通用节点超时流程排查。
理解 Windows 批量测试回归
issue #2314 把问题限定在 v0.8.95 的 Windows 桌面链路：批量请求通过桌面 IPC 发送时可能拥塞，发送失败又被界面统一显示为 Timeout，因此单节点测试不一定复现。
官方修复提交减少了每批并发节点数量，并调整桌面 RPC 的等待与响应处理。这个改动位于 FlClash 的批量测试链路，不是更换节点协议或修改订阅内容。
这能解释 v0.8.95 的特定回归，但不能证明所有 FlClash Timeout 都来自 IPC。只有完成单测与真实请求对照，才适合继续升级验证。
三个层次不要混在一起
| 层次 | 失败时看到什么 | 能否说明节点损坏 |
|---|---|---|
| 整组测速界面 | 大量节点同时变成 Timeout | 不能单独证明 |
| 单节点延迟测试 | 一个节点无法返回延迟 | 仍需真实请求 |
| 真实连接记录 | 请求无法建立或节点报错 | 更接近实际可用性 |
升级到 FlClash v0.8.96
FlClash v0.8.96 于 2026 年 8 月 17 日发布，官方说明明确包含 Windows 整组延迟测试失败修复。符合前述特征时，应优先升级到 v0.8.96 或更新的稳定版。
从项目官方 Release 获取与 Windows 架构匹配的安装包。不要关闭安全软件或忽略来源告警来强行安装；无法核对文件来源时，先留在当前可用版本。
按可回退顺序升级
确认备份可用
检查 Profile、覆写和当前选择已经导出，并记录旧版本安装包位置。
完全退出 FlClash
从托盘退出应用，避免旧进程仍持有内核、配置或桌面服务。
安装官方稳定版
从官方 Release 选择正确架构，完成安装后再启动应用。
核对版本与配置
确认显示 v0.8.96 或更新稳定版，原 Profile 与策略选择仍然存在。
用同一代理组验证修复
保持原网络、订阅、测试地址和代理组不变，再执行一次整组延迟测试。重点观察升级前记录的三个红色节点，不能只看整体颜色变少。
随后逐个选择这些节点发起真实请求，并查看连接记录。整组结果恢复、样本节点有延迟且请求成功，才能确认本机的批量误报已经闭环。
修复完成标准
- 应用版本为 v0.8.96 或更新稳定版
- 同一代理组不再大面积同时显示 Timeout
- 升级前记录的样本节点能够返回延迟
- 至少一个样本节点完成真实网页请求
- 连接记录显示请求使用了当前选择的节点
- 订阅、覆写、DNS 与 TUN 设置没有被意外重置
升级后仍有 Timeout 怎么分流
少量不可用节点并不等于修复失败。稳定版只处理已确认的 Windows 整组测试问题，真实节点下线、测试地址不可达、DNS 异常和当前网络限制仍会产生正常的 Timeout。
官方 issue #2253 还记录了严格 DNS 覆写开启后批量测速异常的另一种场景，它没有被证明与 v0.8.95 的 IPC 回归完全相同。不要为追求全绿长期关闭必要的 DNS 设置。
只有少数固定节点失败
分别单测并发起真实请求，确认节点或测试地址是否不可达。
批量与单测仍全部失败
检查测试 URL、DNS、系统时间和当前网络，再换热点对照。
只在严格 DNS 覆写开启时异常
保存配置后做开关对照，并跟踪独立 issue，不把它归为已修复回归。
开启 TUN 后所有请求中断
先关闭 TUN 恢复系统代理，再检查路由、虚拟网卡和 DNS 劫持。
界面正常但自动组仍选错
查看内核的健康检查地址、间隔与策略组类型。
异常时回退到已知可用版本
若 v0.8.96 在本机无法启动、Profile 丢失或引入新的实际连接故障，先完全退出应用，再恢复升级前备份。不要在运行中反复覆盖配置目录。
issue #2314 的对照环境中，v0.8.94 的整组测试正常，因此它可以作为该特定回归的临时回退点。回退会失去 v0.8.96 的修复，不应成为长期停更理由。
恢复可用状态
退出全部进程
确认托盘、界面和内核都已退出，再开始更换版本。
安装已验证旧版
使用升级前保留的官方安装包，必要时回到本机已验证的 v0.8.94。
恢复配置备份
只恢复自己的 Profile 与覆写，不导入来源不明的完整目录。
验证真实连接
先用系统代理完成一次请求，再检查整组测速与连接记录。