RegionRestrictionCheck 一类脚本的输出项怎么读

先确认出口，再读单项，最后归并成四类

读 RegionRestrictionCheck 一类脚本的输出，顺序比细节更重要：先看顶部的环境信息，确认这次检测确实从你想测的节点出口发出；再逐项读各平台的状态词；最后把各种状态词归并成“可用、部分可用、不可用、未得出结论”四类，并标上检测时间。任何一项结论都只是这一次、这个出口的快照。

本文只讲怎么读输出，不提供修改脚本或改变检测结果的方法；本站对 17 个品牌均为 Not Tested，文中不出现任何品牌的检测结果。脚本的推断原理见检测脚本如何判断地区。

输出的三层结构

这类脚本的输出版式随版本变化，但大体可以分成三层：

• 环境信息层：脚本启动后显示的系统信息、检测所用的 IP 协议、当前出口 IP（常做部分遮挡）以及其所属网络的简要信息。这一层回答“这次是谁在测”。
• 平台分组层：检测项通常按地区或平台类型分组，例如跨地区通用的平台一组，再按北美、欧洲、亚洲等地区分组。分组只是脚本作者的组织方式，不代表平台本身的分类。
• 单项状态层：每个平台一行，显示状态词，部分还附带地区代码或补充说明。

很多读者直接跳到第三层找“绿色”，这是误读的主要来源。环境信息层只要有一项不对，第三层就没有意义。

环境信息层要核对的三件事

1. 出口 IP 与预期是否一致：将脚本显示的出口与客户端当前选中的节点对照，必要时再用两个 IP 查询站点交叉确认。不同站点显示的地区可能不一致，原因见为什么不同 IP 查询网站显示的地区不一样。
2. IPv4 与 IPv6 各自走了哪里：如果两组都有结果，要分别确认出口；只有一组经过代理时，另一组结果应注明“本地网络”，不纳入节点记录。
3. 脚本版本与运行时间：版本决定规则，时间决定快照位置，两者都要记录。

单项状态词的归并对照

不同版本的具体字样可能不同，以下按常见形态归类，读者以自己所用版本的实际输出为准：

把七种形态压成四类的目的，是避免把“没测出来”当成“测出来不行”。在记录表里，“未得出结论”应该单独成列。

三个常见误读

误读一：地区代码就是节点地区。 地区代码是平台对这次请求的归类，它可能与节点名称上的地区标签、IP 查询网站的结果都不同。三者不一致时，以平台返回为准理解“平台怎么看”，但不要据此给节点改名或下结论。

误读二：代理识别类结果说明节点“坏了”。 被识别为代理往往与共享出口的使用情况、平台名单的更新节奏有关，同一出口在不同日期可能结果不同。它更适合作为向服务商反馈的依据，而不是一次性的判决。共享出口如何受影响，可延伸阅读共享出口 IP 的信誉。

误读三：结果可以加总成“解锁率”。 各检测项的判定规则与重要程度不同，失败原因也各异。把它们简单计数，会让单次快照看起来像一个稳定指标。本站在数据状态与标注规范中把这类结果归为某一时间点的观测，不做汇总评分。

同一份输出里，各项结果不能互相推导

一份输出里往往有几十个检测项，读者容易用其中几项推断其余项，例如“某个片库平台显示可用，同地区的另一个平台应该也没问题”。这种推断缺乏依据：各平台使用的地理库不同，代理识别名单的维护方和更新节奏也不同，同一出口在不同平台上被归入的地区、被识别的程度都可能不一样。AI 服务与流媒体之间更是如此，前者还关心滥用风险。

因此，读输出时只把每一项当作“这一项在这一刻的结果”，你真正需要的服务，就看对应那一行；输出里没有覆盖的服务，应当用手动方式单独确认，而不是从相邻项推测。

读完之后怎么落到记录上

建议每读完一次输出，就把以下内容写进记录：检测时间、脚本版本、客户端模式、节点名称、出口 IP（可部分遮挡）、IP 协议，以及按四类归并后的结果。完整字段可以直接使用解锁检测记录模板。

如果脚本结论与实际使用体验矛盾，例如显示可用却无法播放，应以账号层的实际体验为准，排查思路见检测显示 Yes 但实际无法播放。

运行脚本的边界

脚本请从其官方仓库获取，运行前先通读内容，确认会访问哪些地址、是否会改动系统设置。检测与使用都应遵守所在地法律法规和各平台服务条款，本站不提供调整脚本规则或规避平台判定的方法。更多检测方法见解锁检测方法与结果解读专题。