为什么建议先测速、后做解锁检测？

测速可以先剔除超时和极不稳定的节点，避免在连不通的节点上做解锁检测，得到“检测失败”这类无法解读的结果。先筛选、后检测，也能减少检测次数，降低频繁请求带来的账号风险。

测速结果好，能说明这个节点可以解锁吗？

不能。测速反映的是连接路径的速度与平稳度，解锁取决于出口 IP 的类型与地区、平台策略和账号状态，两者没有对应关系。本站对 17 个品牌均未做 AI 与流媒体解锁实测（Not Tested）。

建议分成两张表，用测试时刻、节点名称和出口信息作为关联字段。两类测试的字段差别很大，合在一张表里容易互相混淆，也容易诱导人用速度去推断解锁。

测速和解锁检测回答的是不同的问题：前者看连接路径快不快、稳不稳，后者看出口在某个平台眼里属于哪个地区、能否使用。两者应分开操作、分开记录，但在同一时段对同一节点先后完成，并用统一的关联字段把两张记录表连起来。这样既能避免用速度推断解锁，又能在事后对照“某个节点在某一时刻”的完整状态。

本文只讲两类测试的衔接与记录方式。解锁检测本身的方法、脚本与结果解读，请看解锁检测方法与结果解读。所属专题为自己动手测速，测速的方法论总览见机场测速方法。

一张测速结果里没有任何字段能说明某个平台是否可用。速度快只说明路径通畅，出口 IP 的类型、地区归属、平台对该 IP 段的策略、账号所在地区，都不在测速范围内。反过来，速度一般的节点也可能在某个平台上表现正常。为什么两者无法互推，在测速快就能解锁流媒体吗中有详细说明。

本站对 17 个品牌均未进行 AI 与流媒体解锁实测（Not Tested）。品牌资料中关于 AI 或流媒体的描述，属于品牌提供的信息（Vendor Data），具体可用性、解锁状态及节点表现可能随 IP、地区、平台策略和测试时间变化，建议以最新实际测试结果为准。

顺序	好处	风险
先测速	先剔除超时与不稳定节点，检测对象更少	无
后检测	只对可连通节点检测，结果更容易解读	需要在同一时段内完成，避免出口变化
反过来先检测	—	可能在不可用节点上得到“检测失败”，无法区分是连接问题还是平台限制

还有一个现实考虑：频繁向平台发起检测请求，可能触发平台的风控。先用测速缩小范围，可以减少检测次数。

步骤 5 的作用是给解锁结果加一个“当时连接正常”的旁证。如果这次延迟测试出现大量超时，解锁结果应标注为“连接不稳定期间的检测”。

两张表各自保留自己的字段，只共享三个关联字段：

关联字段	测速表中	解锁检测表中	用途
测试时刻	每次测速的时刻	每次检测的时刻	按时间对齐
节点名称	订阅中的完整名称	同左	按节点对齐
出口信息	出口地区	出口地区与部分 IP	确认两次测试走的是同一出口

测速表的完整字段见测速记录表模板，解锁检测表的字段见解锁检测记录模板。同一节点在一段时间内可能更换出口 IP，所以“出口信息”这一关联字段很重要：如果两次测试的出口不同，就不能把它们当作同一状态的两面。

两张表关联起来之后，很容易出现“速度快的节点解锁也好”之类的归纳。即使在你的记录里看起来有这种趋势，样本量通常也很小，而且出口 IP、平台策略都会变化。对照的用途应该限于：

不要把两类结果合成一个综合评分，也不要据此给出“某个品牌能解锁”的结论。

解锁检测给出失败或异常结果时，先回到同时段的测速表，按三个问题依次判断：

这三个问题都依赖关联字段才能回答。没有同时段的测速记录，就只能对着一条孤立的检测结果猜测原因。

解锁结果随出口 IP 和平台策略变化，时效通常比测速结果更短。建议在多时段测速计划中，每隔几天对主要候选节点做一次解锁检测，并在每次检测时都附上同时段的测速记录。时段安排可参考晚高峰测速怎么安排。

使用 AI 工具与流媒体服务时，请遵守所在地法律法规与平台服务条款，不要尝试规避平台的地区限制或风控措施。