功能定位：为什么需要手动校准
kuailian（QuickLink）v7.4.0 之后，客户端默认启用「AI 绕行选路」+「量子密钥轮换」双引擎：晚高峰每 90 秒就可能换一次出口 IP，峰值速率能抬升约 20%，却也把内置测速采样点不断带偏，最终让订阅列表里的 Latency 比真实 RTT 高出 10–40 ms。直接按这份“虚高”延迟排序，最通畅的节点往往被挤到队尾，游戏或会议反而卡顿。
手动校准就是绕过客户端的“短时采样”误差，用本地长时 ping 与握手时延重新给节点打分，再把修正值写回订阅文件。全程零日志、零额外流量，只在本机完成。
前置检查：确认异常是否值得校准
不是所有“红延迟”都值得动手。先跑完下面三步，避免白忙活：
- 连续 3 次「节点测速」→ 结果波动 > 20 ms；
- 同节点在系统终端 ping 平均值比客户端显示低 > 15 ms；
- 切换后实际游戏/会议延迟与客户端显示不符，差异 > 20 ms。
同时命中两条，再进手动校准；否则先试试「关闭量子密钥轮换」或「改 MTU 1320」这类轻量方案，通常就能拉齐差距。
平台差异：最短入口与回退
Windows / macOS
主界面右上角「≡」→ 诊断工具 → 节点校准 → 导出原始列表（JSON）。回退：同路径「恢复默认」一键还原。
Android
我的 → 设置 → 高级 → 节点校准 → 分享副本到系统下载。回退：删除 /Android/data/com.quicklink/files/custom_ping.json 后重启客户端。
iOS
受沙箱限制，需借助「文件」App → 快连 → 订阅 → 长按节点列表 → 拷贝到「iCloud 云盘」再编辑。回退：卸载 App 重装即可，订阅码可重新输入。
三步校准：抓真实 RTT → 改基准 → 写回
Step 1 抓真实 RTT
先关闭「量子密钥轮换」，防止 IP 漂移。用系统 ping 对节点域名发 100 包，取「平均」与「95% 置信上限」两项。示例：香港 HK05 节点，客户端显示 58 ms，终端 ping 均值 39 ms，95% 上限 44 ms。
Step 2 改本地基准
打开导出的 JSON，找到对应节点 id，把 "ping_ms": 58 改为 "ping_ms": 44，并新增字段 "manual": true，声明该值已人工校准。若节点为 IPv6 双栈，建议 v4/v6 分别测后取最小值写入。
Step 3 写回并验证
将文件重命名为 custom_ping.json 并放回原目录；返回客户端 → 节点列表下拉刷新，延迟列出现「✋」图标即表示启用人工值。再跑 3 次测速，若新排序与真实 RTT 误差 ≤ 5 ms，校准完成。
经验性观察：何时不该手动改值
1. 节点位于「AI 绕行」动态出口池（域名含 .pool.quicklink.xyz），IP 每 120 秒轮换，人工值 2 分钟后即失效。
2. 你处于公司多层 NAT 环境，本地 ping 被劫持到缓存网关，结果比客户端更低，反而误导排序。
3. 订阅链接所有者启用了「云端强制刷新」策略，每次拉取会覆盖本地 JSON，手动修改丢失。
边界条件判断：若节点域名解析到 10 段或 172.16 段私网地址，切勿采信本地 ping，应改用 tcping 443 端口作为替代。
与第三方工具协同：最小权限原则
有人习惯用 PingInfoView、Hping3 批量跑节点，再粘贴回 JSON。可行，但需关闭「发送 ICMP 时间戳」选项，防止部分 IDC 把异常 ICMP 计入攻击阈值导致节点临时拉黑。建议每 IP 每秒 ≤ 2 包，并发 ≤ 8，超时 800 ms 即停止，降低 collateral damage。
故障排查：现象→原因→验证→处置
现象 A：写回后客户端仍显示旧值
可能缓存未清 → 退出账号 → 强制停止 App → 重启 → 重新登录；若仍无效，检查 JSON 语法，多逗号少括号均会导致回退到默认值。
现象 B：出现负延迟
把本地时钟与 NTP 同步；若你用了 Wi-Fi 6 路由的「数据包聚合」功能，先把其关闭再测，否则时间戳被提前。
现象 C：校准后反而丢包
经验性观察：部分游戏反代节点（名字带 game- 前缀）在晚高峰启用「UDP over TCP 伪装」，ping 值低但 UDP 通道被限速。此时应放弃 ping 排序，改用「实际游戏大厅」延迟为准。
适用/不适用场景清单
| 场景 | 建议 |
|---|---|
| 个人游戏加速，节点 < 15 个 | 手动校准收益高，值得做 |
| 企业 API 批量下发 200+ 节点 | 用官方 RESTful 校准接口，勿手工改 |
| 节点域名每日变更（动态池） | 不适用，改值 2 分钟后失效 |
| 合规审计要求零本地文件修改 | 禁用此流程，改用云端排序 |
最佳实践 5 条
- 每次大版本升级（如 7.x→8.x）后，重新抽检 3 个常用节点，防止测速算法变更导致旧值漂移。
- 把 custom_ping.json 加入系统备份列表，换机时一并迁移，省去重复劳动。
- 同时开启「量子密钥轮换」与「手动校准」时，每周抽 5 分钟复查一次，误差 > 10 ms 即更新。
- 对 P2P 专用节点（NL/CH/SE）不测 ICMP，直接用 tcping 443，结果更接近真实下载速率。
- 分享订阅给他人前，删除 JSON 中 "manual" 字段，防止你的本地网络环境误导他人排序。
版本差异与迁移建议
v7.3 及更早版本使用 XML 存储节点信息，校准需改 hosts 文件，操作繁琐且易被更新覆盖；v7.4.0 起全面切至 JSON 并支持「✋」图标回显。若你仍停留在老版本，建议先升级至最新版再执行本文流程，否则路径与字段名均不兼容。
FAQ（结构化数据）
手动校准后会影响流媒体解锁吗？
不会。校准仅改排序用延迟字段，不涉及出口 IP 或区域标识，Netflix、Disney+ 等解锁逻辑保持不变。
iOS 无法编辑 JSON 怎么办？
用「快捷指令」App 自带 Base64 编码动作，把节点列表 AirDrop 到 Mac 编辑完再传回，可绕过沙箱限制。
企业账号禁止本地文件修改，有无替代方案？
调用官方 RESTful 校准接口，提交节点 ID 与 RTT 数组，云端会在 5 分钟内重排并推送到设备，无需触碰本地文件。
收尾：下一步行动
至此，你已拥有「快连订阅节点延迟测试异常时手动校准测速结果」的完整闭环：判断异常 → 导出 → 测 RTT → 改 JSON → 验证。今晚即可挑 3 个常用节点实操，把游戏延迟再压 10 ms。若一周后误差仍稳定 < 5 ms，可把流程写成脚本定时执行，让排序永远保持真实。未来版本若推出「云端自学习延迟补偿」，本地手动步骤有望进一步简化，但现阶段，这份“✋”图标仍是精准排序的最短路径。
