延迟就是数据从你的设备发出、到达节点、再返回所花的时间，单位是毫秒（ms）。QuickQ 在节点列表和状态面板里都会实时显示这个数值，数字越小代表响应越快。
数值范围上，50ms 以内算优秀，50 到 100ms 属于良好，100 到 200ms 属于可用，超过 200ms 就能感觉到等待了。理解这个刻度，再看界面上的数字就有参照。
延迟和网速不是一回事
很多人把延迟和网速混为一谈，其实是两个指标。
延迟衡量的是「反应快不快」。你发出一个请求，多久能收到回应，这个时间是延迟。它决定的是操作跟不跟手。
网速衡量的是「管道宽不宽」，单位通常是 Mbps，决定单位时间内能传多少数据，比如下载一个大文件要多久。
一条线路可能网速很高但延迟不低，也可能延迟很低但带宽有限。看 QuickQ 界面上的数值时，先明确你看的是哪个。
在 QuickQ 里哪里能看到延迟
桌面端有两个地方能看。
一是节点列表。展开节点列表后，每个节点右侧会显示一个毫秒数值，这是当前时刻该节点的探测结果。数值会随着刷新更新。
二是状态面板。Windows 上把鼠标悬停在托盘图标上，macOS 上点开菜单栏面板，都能看到当前使用节点的延迟。
移动端的展示更集中，节点列表里直接带数值，主界面上通常也会显示当前连接节点的延迟。
延迟数值多少算正常
没有一个绝对标准，但可以按体感分档。
30ms 以内，几乎感觉不到任何等待，操作和本地响应接近。30 到 80ms，体验顺畅，日常浏览、看内容都没问题。80 到 150ms，能用，但连续操作时会有一点滞后感。150ms 以上，感知明显。超过 200ms，就不太适合对响应要求高的用途了。
要注意的是，这个刻度是体感参考，不是硬性门槛。同一台设备上，不同用途能接受的延迟上限不一样。
延迟和丢包要一起看
只看延迟不看丢包，判断容易出错。
丢包指的是发出的数据包里有多少没成功到达，用百分比表示。丢包率哪怕只有百分之几，也会让延迟数值失去意义——因为延迟低但丢包高，实际体验照样是卡顿、断续。
QuickQ 的探测会同时评估这两项。如果某个节点延迟很低但丢包偏高，它不会成为首选。AI 智能选路的判断依据里，这两个指标是合并计算的，不是只看延迟。
所以自己手动比较节点时，也别只盯着毫秒数。数值漂亮但用起来不顺畅，多半就是丢包在作怪。
为什么每次看到的数值都在变
延迟是一个动态指标，不是固定值。变来变去才是正常的。
原因有几层。本地网络本身在波动，Wi-Fi 信号强度、同一网络下其他设备的占用，都会影响结果。节点侧也有负载变化，用的人多了，响应自然会慢一点。中间的链路也会变，路径不是一成不变的。
正常的波动幅度一般在十几毫秒以内。如果数值在几十毫秒之间来回跳，或者短时间内持续攀升，那就值得看一眼了。
另外，探测本身有采样间隔。界面上显示的是最近一次探测的结果，不是每一毫秒的实时值。所以刷新时数字变化，不代表连接出了问题。
AI 智能选路怎么影响显示的数值
智能选路的工作方式是并行探测，同时测多个候选节点，然后挑当前表现最好的那个。
这意味着你看到的延迟，是「已选中节点」的数值，不是所有节点里的最低值。系统选的是综合表现最好的，不一定是毫秒数最小的那个。
有时候你会看到某个手动节点数值比当前连接的低，但系统没选它。这很正常，可能那个节点在丢包或稳定性上不占优势。
想了解这套机制更多细节，可以看 AI 智能选路那篇，里面有并行探测和评估维度的说明。这里只需要记住一点：显示的数值是结果，不是全部依据。
手动选节点时怎么比较
如果你决定手动选，比较方法很简单：看节点列表里的数值，再结合自己的实际感受。
先在列表里找数值较低的几个，逐个连上试一下。不要只看数字，实际打开几个页面、操作几下，感受一下响应速度。数值和体感一致，那就选它。
数值和体感不一致的情况也存在。这时候优先相信体感，因为界面上的数值是探测采样结果，体感是完整的实际体验。
选好之后，这个偏好会保存在本地。下次启动客户端，如果手动选择仍然有效，会继续用这个节点。想交回自动，切回智能选路即可。
用第三方测速工具结果对不上
这是常见疑问：QuickQ 显示 40ms，第三方工具测出来却是 200ms。
原因是两者测的对象不同。QuickQ 显示的延迟，是设备到当前节点的往返时间。第三方测速工具测的通常是设备到某个测速服务器的往返时间，这个服务器和节点不是一回事。
两个数值本就不该一样，放在一起比较没有意义。判断连接质量，看客户端里显示的数值更直接，因为那才是你实际走的路径。
如果一定要用第三方工具，注意选择测速目标。测速服务器的位置、当前网络状况都会影响结果，单次测量参考价值有限。
延迟突然变高怎么排查
按从近到远的顺序查。
先看本地网络。Wi-Fi 信号弱、路由器负载高、同网络下有大流量任务在跑，都会推高延迟。换到有线连接或靠近路由器试试，如果数值明显回落，问题就在本地。
再看节点。切换一个节点，观察数值是否改善。如果换节点后恢复正常，说明原来那个节点当前状况不理想，等一会儿再切回来，或者就让系统自己重新选。
然后断开再连接一次。这一步会让客户端重新走一遍选路流程，有时候卡住的状态就恢复了。
以上都不行，重启客户端。还不行，去 QuickQ下载 页确认一下当前版本，安装包约 150MB，当前版本为 Build 1449。版本过旧的话，更新到最新版再看。
不同平台的延迟显示差异
桌面端的展示更细。Windows 托盘悬停提示里带节点名和延迟，macOS 菜单栏面板里也能看到。节点列表的数值刷新频率相对高。
移动端为了省电和流量，探测频率会低一些，数值变化不如桌面端频繁。这是设计上的取舍，不是功能缺失。
平板上因为屏幕更宽，节点列表能展示的信息更多，比较起来比手机上方便。
各平台之间的数值不宜直接横向对比。同一时刻、同一节点，桌面端和移动端测出来也可能有差异，因为设备本身的网络模块和系统调度不同。这也是同一个 QuickQ 在不同设备上读数不一致的主要原因。
延迟低就一定体验好吗
不一定。
延迟低是好事，但它只说明响应快，不说明持续传输能力。看长时间内容、下载大文件这类用途，更依赖带宽和稳定性。
连接稳定性方面，节点在线稳定性为 99.9%，这个指标反映的是节点可用程度，和单次延迟测量不是一回事。
另外，从连接到可用还有一段时间。正常情况下 3 秒内连接完成，这段时间和连接建立后的延迟是两码事。
判断体验好不好，把延迟、丢包、稳定性放在一起看，比只盯一个数字靠谱得多。
测试前建议做的几件事
想让测量结果有参考价值，先做几件准备。
把当前网络里的大流量任务停一下，比如正在下载的文件、正在同步的云盘。这些会明显影响测量结果。
连接方式尽量统一。这次用 Wi-Fi，下次也用 Wi-Fi，换到有线再测出来的数值不能直接比较。
测的时候多测几次，看平均表现，不要拿单次结果下结论。延迟本身有波动，单次数值可能偏高或偏低。
时间点也值得留意。同一节点在高峰时段和空闲时段的数值会有差别，这属于正常范围。
几个常见疑问
延迟多少算能用？看用途。日常浏览 100ms 以内都比较顺，对响应敏感的操作希望控制在 50ms 以内。
为什么节点列表刷新后数值全变了？每次刷新都会重新探测一遍，网络状况在变，结果自然不同。
能自己指定只测某几个节点吗？目前 QuickQ 节点列表展示的是系统探测范围内的结果，不支持自定义探测目标。
延迟数值和加密有关系吗？传输层用的是 AES-256-GCM 高强度加密，架构上遵循零日志原则，不保留使用日志。加密对延迟的影响在客户端数值里已经包含，不需要单独考虑。
换设备后延迟会不一样吗？会。不同设备的网络模块、系统调度、甚至摆放位置都不同，数值有差异是正常的。
延迟这个数值，看的时候记住两件事：它是动态的，单次结果别当结论；它只是参考之一，丢包和稳定性同样重要。养成偶尔看一眼数值、结合体感判断的习惯，比追求某个具体数字更有用。