外观
数据贡献与纠错
最需要的四类贡献
按对读者的价值排序。
一、来自不同网络环境的实测（最有价值）
为什么最有价值：跨环境不可比，而本站的测试环境是单一的。
| 变量 | 本站的覆盖 | 需要的 |
|---|---|---|
| 宽带运营商 | 单一 | 移动、联通宽带的数据尤其稀缺 |
| 所在省份 | 单一 | 各地区 |
| 城域网条件 | 单一 | — |
影响结果的六个变量里有四个不可消除，所以来自不同环境的数据能填补本站最大的空白。
需要提供：
| 项目 | 必需 |
|---|---|
| 运营商、城市、宽带带宽 | 是 |
| 有线还是 Wi-Fi | 是（Wi-Fi 的数据会被标注局限） |
| 客户端与版本、协议 | 是 |
| 日期与时刻 | 是 |
| 节点的完整名字 | 是 |
| 节点倍率 | 建议 |
| ping 100 次的丢包与延迟分布 | 是 |
| 多线程下载三次的中位数 | 是 |
| 白天与 21:00 各一轮，连续三天 | 是（单次不作数） |
详见 实测方法与环境说明。
二、补全只有 1 家披露的字段
这四个字段目前各只有 1 家披露，补全它们对所有读者都有帮助：
| 字段 | 为什么重要 | 需要的依据 |
|---|---|---|
| IP 类型（原生 / 家宽 / 机房） | 解锁能力的唯一线索 | 官网页面或客服回复截图 |
| 退款条款（天数、流量上限、是否按比例） | 决定验证成本 | 同上 |
| 客服方式 | 出问题时的可达性 | 官网页面截图 |
| 官网主域名 | 核对域名防假站 | 需要可靠依据（本站在这项上最谨慎） |
另外三个字段站内完全没有：
| 字段 | 为什么重要 |
|---|---|
| 节点倍率 | 2 倍率会让 500GB 变成 250GB |
| 订阅格式支持 | 决定能用哪个客户端 |
| 设备数上限 | 多设备用户的硬约束 |
这些通常只能通过客服问答或导入订阅后观察得到——如果你已经买了某家，这些信息你手上就有。
三、可核实的状态变化与变动事件
| 类型 | 需要的依据 |
|---|---|
| 价格 / 套餐变更 | 官网页面截图（含日期）+ 你的旧订单 |
| 域名更换 | 官方渠道的公告截图 |
| 事故 | 带时间与方法的测试记录 + 多来源一致 |
| 状态变化（不可用、失联、恢复） | 带时间的访问记录截图 |
| 支付方式或客服渠道变化 | 官网页面前后截图 |
详见 变动记录时间线 与 收录、标注与撤销标注的规则。
四、对标注或数据的异议
| 类型 | 需要的依据 |
|---|---|
| 服务已恢复（撤销异常 / 失联） | 本站会自行复查（官网 → 后台 → 订阅 → 抽查节点） |
| 中断是计划维护 | 当时的官方公告（含时间） |
| 数据字段有误 | 官网页面或客服回复截图 |
| 派生字段计算有误 | 欢迎核对（每 GB = 月均价 ÷ 月流量，可自己验算） |
| 事件日期有误 | 可核对的时间依据 |
服务商与用户走同一流程、适用同一证据标准。
补充品牌资料
- 打开
data/brands/<slug>.json，对照data/schema.md数据规范填写； - 没测过的字段留
null，不要填推测值； - 在
sources里写明信息来源（官网页面、测试日期与环境）； - 全部关键字段核实后，把
verified改为true，品牌才会进入排行榜与推荐位。
提交实测
复制 data/benchmarks/_template.json，填写 env（运营商 / 城市 / 宽带 / 客户端 / 协议）与 samples，published: true。实测记录会出现在 实测中心 与对应品牌页。
报告状态变化 / 风险
在品牌 JSON 的 timeline 增加一条 { date, type, note }，并视情况修改 status。类型：price 价格、domain 域名、plan 套餐、incident 事故、status 状态、other 其他。
对标注有异议
提供可核实的依据（官网公告、可访问的订阅地址、客服回复截图等），本站复查后更新状态并在 timeline 记录复查结果。规则见 收录、标注与撤销标注的规则。
不接受什么
收录标准严格是本站的选择，这一节说清界线。
| 不接受 | 为什么 |
|---|---|
| "听说……" | 无法核对 |
| 转载的社区帖子（无原始依据） | 传闻链 |
| 单个用户的"我这里不行" | 跨环境不可比——可能是本地或配置问题 |
| 没有时间戳的截图 | 无法定位事件时间 |
| 主观评价（"变差了"、"不好用"） | 不是可核对的事实 |
| 匿名的"内部消息" | 无法核实 |
| 对未来的担忧 | 本站不做未发生事件的预测 |
| 推测的字段值 | 空白比推测值更诚实 |
| 从测速图 OCR 出的"精确"数据 | 会制造虚假精度 |
| 从测速图推导的线路类型或解锁结论 | 逻辑上做不到 |
为什么标准这么严
一条错误的记录会造成真实的伤害：
| 风险 | 说明 |
|---|---|
| 错误的"跑路"记录 | 对服务商不公平 |
| 错误的价格记录 | 误导读者的预算判断 |
| 错误的域名记录 | 可能把读者引向假站 |
| 错误的解锁结论 | 让读者跳过自己的验证 |
最后两项最严重——这也是本站在域名字段上只收录 1 家、解锁矩阵完全留空的原因。
宁缺毋滥：这让收录变慢，但让每一条记录都可信。
先自查再提交
"我连不上"或"变慢了"通常不构成记录——因为跨环境不可比的因素让单点观察难以作为整家的事件。
提交前的五分钟自查
| 顺序 | 检查 | 说明 |
|---|---|---|
| 1 | 关闭代理，国内网站正常吗？ | 不正常 → 本地或城域网问题 |
| 2 | 用的是有线还是 Wi-Fi？ | Wi-Fi 的丢包会污染所有判断 |
| 3 | 手动更新订阅了吗？ | "全部节点连不上"最常见的原因是订阅过时 |
| 4 | 客户端真的启用了代理吗？ | 看连接日志有无请求 |
| 5 | 换同地区其他节点试过了吗？ | 多是节点级问题 |
| 6 | 规则里国内域名走的是直连吗？ | "国内变慢"几乎一定是这个 |
多数情况会在这六步里解决。 详见 超时与连接失败 与 速度慢怎么排查。
自查后仍确认是整家的问题
那就值得提交了。请附上：
| 项目 | 说明 |
|---|---|
| 完整的环境说明（运营商、城市、宽带、有线、客户端、协议） | 必需 |
| 你测了哪些节点（完整节点名） | 必需 |
| 测试的时间与方法 | 必需 |
| 具体的数据（丢包率、速度） | 必需 |
| 已排除的本地因素 | 帮助判断 |
| 是否有其他来源一致 | 加强可信度 |
一个好的报告示例：
运营商：某运营商 / 城市：某市 / 宽带：某带宽 / 有线 客户端：Clash Verge Rev（版本号） 测试时间：2026-09-18 21:00–21:30 测的节点（完整名）：香港 xx、香港 yy、新加坡 zz 结果：三个节点 ping 100 次丢包均在 4–6%，白天同节点丢包 0% 已排除：国内网站正常、已换有线、已手动更新订阅、已换同地区其他节点 另有两位用户在社区报告同样现象（附链接）
这份报告可以核对，而"我这里连不上"不能。
提交后会发生什么
| 步骤 | 说明 |
|---|---|
| 1 | 本站核对依据 |
| 2 | 依据充分 → 收录 / 更新，标注日期与依据类型 |
| 3 | 依据不足 → 回复说明需要补充什么 |
| 4 | 涉及状态变化的 → 同步 机场状态页 |
| 5 | 涉及可核实的变动 → 记入 变动记录时间线 |
| 6 | 涉及异常 / 失联的 → 从推荐位与排行榜下线 |
| 7 | 实测数据 → 出现在 实测中心 与对应品牌页 |
第 6 步是硬规则，不受推广关系影响。 见 收录、标注与撤销标注的规则。
处理的时限
| 项目 | 说明 |
|---|---|
| 核实是人工的 | 没有固定周期 |
| 涉及状态的会优先 | 影响读者的购买决定 |
| 依据不足的会回复 | 说明需要什么 |
| 重复提交 | 可以，但需提供新的依据 |
本站不声称有快速响应能力——这是诚实的说明，而不是推脱。
数据规范的关键要求
如果你直接编辑 JSON 文件，这几条最容易出错。
一、未测过的字段留 null，不填推测值
| 做法 | 说明 |
|---|---|
| 正确 | "unlock": null 或整个字段不写 |
| 错误 | "unlock": { "netflix": true } ——没测过就填 |
| 为什么 | 空白表示"未实测"，推测值会被读者当成事实 |
页面会把 null 渲染成"—"，这是明确的"未实测"标记。
二、只给年付价的套餐，price 留空、只填 monthly
| 情况 | 怎么填 |
|---|---|
| 品牌公布"年付 79 元" | price: 79、cycle: "year" |
| 品牌只公布"折算 6.58 元/月" | price: null、monthly: 6.58 |
| 为什么 | 页面会显示"折算"，让读者看到它不是月付价 |
同时：如果年付档的每月流量与月付档不同，要在备注里写明——否则折算出的每 GB 会误导。
三、sources 里写明信息来源
| 需要写 | 说明 |
|---|---|
| 官网页面（含访问日期） | 最基本 |
| 客服回复（截图或转述 + 日期） | — |
| 测试日期与环境（如果是实测字段） | 必需 |
| 资料整理的来源 | — |
没有 sources 的字段无法被后续核对——这会让整条记录的可信度下降。
四、verified 的含义
| 状态 | 含义 |
|---|---|
verified: false | 资料已录入但未经人工复核 |
verified: true | 已人工复核，品牌才会进入排行榜与推荐位 |
不要为了让品牌出现在推荐位而提前改 verified——那会让"复核"这个环节失去意义。
五、派生字段不要手填
| 字段 | 说明 |
|---|---|
| 月均价 | 构建时由周期价格 ÷ 月数计算 |
| 每 GB | 构建时由月均价 ÷ 月流量计算 |
| 完整度 | 构建时由字段填写比例计算 |
hasReview / reviewUrl | 构建时检测评测文件是否存在 |
手填派生字段会与自动计算冲突。 只填源数据（价格、流量、周期），派生字段自己会算。
详见 data/schema.md。
提交实测记录的细节
模板与字段
复制 data/benchmarks/_template.json，关键字段：
| 字段 | 内容 | 必需 |
|---|---|---|
env | 运营商 / 城市 / 宽带 / 客户端 / 协议 / 有线或 Wi-Fi | 是 |
| 日期与时刻 | 每次测试 | 是 |
| 节点的完整名字 | 原样抄下来 | 是 |
| 节点倍率 | 如可知 | 建议 |
samples | 具体的测量数据 | 是 |
published | 设为 true 才会展示 | 是 |
快照 vs 完整实测
本站区分两类实测数据：
| 类型 | 内容 | 本站的处理 |
|---|---|---|
| 快照 | 一张测速图 + 节点分布 + 范围性观察 + 异常项 | 只做范围性记录——不 OCR 成精确表、不据此排名、不推导线路类型或解锁 |
| 完整实测 | 连续三晚的 ping 100 次 + 多线程下载 + 完整环境说明 | 可用于判断线路方案 |
如果你只有一张截图，它会被作为快照记录——这仍然有价值（作为只读的原始证据），但不能支撑线路类型的结论。
如果你有完整的三晚数据，那对本站与其他读者的价值大得多。
为什么需要连续三晚
| 天数 | 结论的可靠性 |
|---|---|
| 1 天 | 不可靠——单次受偶然因素影响太大 |
| 2 天 | 有参考 |
| 3 天 | 一致时结论可信 |
| 三天波动大 | 说明超卖或线路在调整——这本身是有价值的结论 |
"三天波动大"不是"没测出来"，而是一个明确的负面信号。
给不同贡献者的建议
普通读者：最有价值的是你自己的三天实测——尤其如果你用的是移动或联通宽带。附上完整的环境说明（运营商、城市、宽带、有线、客户端、协议、日期）与节点的完整名字，这份数据能填补本站最大的空白。
已经买了某家机场的人：你手上有本站缺的几个字段——节点倍率（看节点名）、订阅格式支持（看后台提供哪些链接）、设备数上限与退款条款（客服回复）。这些各只需要一张截图。
遇到问题想报告的人：先做五分钟自查（关代理测国内网站、换有线、手动更新订阅）。多数"连不上"会在这里解决——而"我这里不行"因为跨环境不可比，通常不构成整家的事件记录。
想纠正数据的人：欢迎核对派生字段（每 GB = 月均价 ÷ 月流量，所有数字都在表格里）。如果发现计算不符，请指出——派生字段的价值之一就是它可以被验算。
想投稿评测的人：适用同样的硬性要求——附实测记录、写明测试环境、结论段写"适合谁 / 不适合谁"、有利益关系必须披露。见 评测方法与写作规范。
服务商：申诉与用户走同一流程。最能帮助读者的是主动披露 IP 类型、退款条款的具体条件、节点倍率、订阅格式支持、以及年付档的每月流量——这些直接降低读者的验证成本。本站不接受以商业合作换取撤销标注或更正面的内容。
发现本站违反自己规则的人：请指出。 本站在 关于本站 与 免责声明 里列出了可核对的检验点（有推广关系的品牌是否也会被标为异常、空字段是否真的留空、快照是否被用于排名等）。
注意安全的人：绝对不要提交完整的订阅链接或带完整 URL 的截图。 需要引用时只给后六位。如果不确定历史截图是否露出过，在机场后台重置订阅链接——成本只是重新导入一次。
数据结构说明（给直接编辑文件的人）
如果你想直接改 JSON 而不是提交描述，先读 data/schema.md。这一节是关键点的速查。
文件位置
| 类型 | 位置 |
|---|---|
| 品牌数据 | data/brands/<slug>.json |
| 品牌模板 | data/brands/_template.json |
| 实测记录 | data/benchmarks/*.json |
| 实测模板 | data/benchmarks/_template.json |
| 榜单口径 | data/rankings.json |
| 对比组合 | data/compare.json |
| 数据规范 | data/schema.md |
| 信息架构（唯一来源） | docs/.vitepress/ia.mjs |
新增品牌
bash
npm run new:brand <slug> "<名称>"或复制 data/brands/_template.json。 品牌页、数据库表、价格行、聚合视图会自动生成——不需要手写页面。
改完必跑
bash
npm run check && npm run buildfrontmatter 含中文冒号或引号时，用 node scripts/fix-frontmatter.mjs 规范化。
五个容易出错的地方
| 错误 | 正确做法 |
|---|---|
| 未测过的字段填推测值 | 留 null（页面渲染为"—"） |
只给年付价时也填 price | price 留空、只填 monthly（页面显示"折算"） |
| 手填月均价或每 GB | 不要填——构建时自动计算 |
为了进推荐位提前改 verified | 只在人工复核后改 |
没写 sources | 必填（官网页面 + 访问日期，或测试日期与环境） |
数据层级怎么标
| 你填的字段 | 应该标为 |
|---|---|
| 品牌资料里的价格、流量、协议、地区、线路标注 | vendor |
| 推广链接、优惠码 | commercial |
| 你自己测出的数据 | measured（需完整环境说明） |
| 编辑判断（适合人群、定位） | editorial |
| 未测试的 | 留 null |
品牌自己标注的"原生 IP"与你查出口 IP 得出的结论，不能混在一个字段里——前者是 vendor，后者是 measured。
本地预览的注意
vitepress preview 会缓存文件元数据，重新 build 后必须重启 preview，否则会出现资源 404 与全文搜索索引报错。
一个提醒
如果你不确定某个字段该不该填，留空。
空白表示"未实测"，这是诚实的状态；推测值会被读者当成事实。 这是本站最基础的数据规则。
为什么本站的收录会很慢
诚实说明：严格的证据标准让收录速度明显慢于"转载社区信息"的做法。
成本对比
| 做法 | 速度 | 可信度 |
|---|---|---|
| 转载社区帖子 | 快 | 低（传闻链） |
| 收录单个用户的报告 | 快 | 低（跨环境不可比） |
| 要求可核对的依据并核实 | 慢 | 高 |
这个选择的代价
| 代价 | 说明 |
|---|---|
| 风险事件记录目前是空的 | 读者拿不到历史信息 |
| 解锁矩阵是空的 | 读者要自己测 |
| 官网域名只有 1 家 | 读者要自己交叉确认 |
| 评测很少 | 每篇需要约五周 |
| 看起来不如"信息丰富"的站点 | — |
本站接受这些代价，因为替代方案的代价更大：
| 如果降低标准 | 后果 |
|---|---|
| 收录传闻 | 一条错误记录会伤害服务商，且纠正成本远高于收录成本 |
| 收录未核实的域名 | 可能把读者引向假站 |
| 填推测的解锁结论 | 读者跳过自己的验证 |
| 给一个编造的评分 | 同上 |
读者可以怎么加速这个过程
| 做什么 | 效果 |
|---|---|
| 提交带完整环境说明的实测 | 直接可收录 |
| 提交带日期的官网截图 | 直接可核对 |
| 提交客服回复的截图 | 补全缺失字段 |
| 自己先做五分钟自查 | 减少无效提交 |
| 提供多个独立来源的交叉印证 | 加强可信度 |
本站的收录瓶颈不是"不愿意收"，而是"符合标准的依据不够多"。
三十秒速查
最需要的贡献（按价值）：
| # | 贡献 | 为什么 |
|---|---|---|
| 1 | 来自不同网络环境的实测（移动 / 联通宽带尤其稀缺） | 跨环境不可比，本站的测试环境单一 |
| 2 | 补全只有 1 家披露的字段（IP 类型、退款条款、客服方式、官网域名） | 对所有读者有价值 |
| 3 | 站内完全没有的三项（节点倍率、订阅格式支持、设备数上限） | 需要问客服或看订阅才知道 |
| 4 | 可核实的状态变化与变动事件 | 需可核对依据 |
所有提交都需要：可核对的依据 + 日期。
不接受： 传闻 · 主观评价 · 单个用户的"我这里不行" · 无时间戳的截图 · 对未来的担忧 · 推测的字段值
提交前的五分钟自查：
| # | 检查 |
|---|---|
| 1 | 关代理，国内网站正常吗？（不正常 = 本地问题） |
| 2 | 有线还是 Wi-Fi？（换有线） |
| 3 | 手动更新订阅了吗？（"全部连不上"最常见的原因） |
安全提醒：
绝对不要提交完整的订阅链接或带完整 URL 的截图。 需要引用时只给后六位。
编辑 JSON 时最容易错的三条：
未测过的字段留 null（不填推测值）· 只给年付价时 price 留空、只填 monthly · 派生字段不要手填（构建时自动计算）
服务商的申诉指南
服务商与用户走同一流程、适用同一证据标准。这一节是给服务商的具体说明。
常见的申诉类型与所需依据
| 申诉内容 | 需要的依据 | 本站会做什么 |
|---|---|---|
| 服务已恢复（撤销异常 / 失联） | 说明恢复情况 | 本站自行复查：官网 → 后台 → 订阅 → 抽查节点 |
| 中断是计划维护 | 当时的官方公告（含时间） | 改判为"维护中" |
| 域名更换记录有误 | 官方渠道的说明 | 核对后更正 |
| 价格 / 套餐记录有误 | 官网页面的存档或截图（含日期） | 核对后更正 |
| 数据字段有误 | 官网页面或后台截图 | 核对后更正 |
| 事件从未发生 | 说明 + 可核对的反证 | 核查后处理 |
| 补充缺失字段 | 官网页面或后台截图 | 收录并标注来源 |
复查的具体步骤
本站收到"服务已恢复"的申诉后会做的事：
| 顺序 | 检查 |
|---|---|
| 1 | 官网是否可访问 |
| 2 | 后台是否能登录（如有账号） |
| 3 | 订阅链接是否能返回配置 |
| 4 | 抽查节点是否可连通 |
| 5 | 官方渠道是否恢复响应 |
第 3 步最关键——它比"官网可达"更能确认服务在运行。
两种结果都会记录
| 结果 | 处理 |
|---|---|
| 恢复正常 | 状态改回；时间线记录"复查恢复"（含日期） |
| 维持标注 | 时间线记录复查结论（含日期与理由） |
为什么维持标注也要记录： 否则读者只看到"一直是异常"，不知道本站是否重新核实过。
本站不接受的
| 不接受 | 说明 |
|---|---|
| 以商业合作换取撤销标注 | 标注由证据触发 |
| 以商业合作换取更正面的内容 | — |
| 要求删除不利的实测结果 | — |
| 要求不写"不适合谁" | 评测的硬性要求 |
| 代写或审稿 | — |
| 仅凭声明而无依据的撤销请求 | 需可核实的依据 |
最有价值的服务商贡献
除了申诉，服务商最能帮助读者的是补全缺失字段：
| 字段 | 为什么对读者有价值 |
|---|---|
| IP 类型（哪些节点是原生 / 家宽） | 解锁能力的唯一线索 |
| 退款条款的具体条件 | 决定读者的验证成本 |
| 节点倍率 | 直接影响实际可用流量 |
| 订阅格式支持 | 决定读者能用哪个客户端 |
| 设备数上限 | 多设备用户的硬约束 |
| 年付档的每月流量 | 折算价的常见陷阱 |
主动披露这些字段会提高你的品牌资料完整度，而完整度是本站的一个派生字段（构建时计算）。
注意：披露这些字段不等于本站会推荐你——本站不做实测排名，综合榜是编辑排序。但完整的披露确实降低了读者的验证成本，这本身是一个竞争优势。
提交时的安全注意
提交内容时最容易泄露的是你自己的凭证。
绝对不要提交的
| 不要提交 | 为什么 |
|---|---|
| 完整的订阅链接 | 等同账号密码——任何拿到它的人都能用你的流量 |
| 带完整订阅 URL 的截图 | 最常见的泄露方式 |
| 账号密码 | — |
| 付款账号信息 | — |
| 你的个人身份信息 | 本站不需要 |
截图前的检查
| 检查位置 | 说明 |
|---|---|
| 订阅 / 配置页面顶部 | 最常见露出订阅 URL 的地方 |
| 配置名称 | 部分客户端用 URL 片段做默认名 |
| 日志区域 | 更新日志会记录完整 URL |
| 浏览器地址栏 | 如果你在浏览器里打开过订阅 |
| 错误提示弹窗 | 有时会显示完整 URL |
最保险的做法：用涂抹工具遮住所有长串随机字符，然后再看一遍整张图。
需要引用订阅时怎么做
| 做法 | 说明 |
|---|---|
| 只给后六位 | 足够本站定位，不泄露凭证 |
| 描述症状而不发截图 | 文字能表达全部排查所需信息 |
| 截图时裁掉顶部的订阅区域 | 只保留出错的部分 |
提交后的建议
| 情况 | 建议 |
|---|---|
| 如果你不确定截图是否露出了 URL | 在机场后台重置订阅链接 |
| 如果你用过在线的订阅检测工具 | 同上 |
| 如果你把订阅粘贴到了任何第三方服务 | 同上 |
重置的成本只是在自己的设备上重新导入一次，而不重置的代价可能是整个周期的流量。
详见 订阅链接安全。
补全字段的具体做法
站内有七个字段缺失严重，这一节说明各自需要什么依据。
IP 类型（仅 1 家披露）
| 怎么获得 | 依据 |
|---|---|
| 官网页面有标注 | 截图（含日期与 URL 可见部分，遮住敏感信息） |
| 客服回复 | 截图或转述 + 日期 |
| 自己查出口 IP 的 ASN | 这是 measured 而非 vendor——需注明是自己测的 |
注意区分两类：
| 类型 | 层级 | 说明 |
|---|---|---|
| 品牌自己标注"原生 IP / 家宽 IP" | vendor | 品牌自述，未验证 |
| 你查出口 IP 的 ASN 得出的结论 | measured | 你自己的观察，需注明节点名与日期 |
两者都有价值，但不能混在一个字段里。
退款条款（仅 1 家披露）
| 需要问清 | 为什么 |
|---|---|
| 天数限制 | 三天验证需要在窗口内 |
| 流量使用上限 | 如果要求"未使用流量"，那你连测试都做不了 |
| 是否支持按比例退款 | 影响年付的风险 |
| 退款渠道与到账时间 | — |
| 加密货币付款能退吗 | 通常不能 |
提供客服回复的截图（含日期）是最好的依据。
客服方式（仅 1 家披露）
| 需要记录 | 说明 |
|---|---|
| 渠道（官方客服 / 知识库 / 即时通讯） | — |
| 是否有响应时间承诺 | — |
| 你实际的响应时间 | 这是 measured，需注明询问日期 |
官网主域名（仅 1 家收录）
本站在这项上最谨慎，因为一个错误的域名可能把读者引向假站。
| 可接受的依据 | 说明 |
|---|---|
| 多个独立来源交叉一致 | 最基本的要求 |
| 你自己账号后台或订单邮件里的域名 | 最可靠（与真实交易关联） |
| 官方渠道的公告 | 可靠 |
| 单一来源 | 不接受 |
| 群里流传的链接 | 不接受 |
提交时请说明依据来源。 本站会再次核对。
节点倍率（站内完全没有）
| 怎么获得 | 说明 |
|---|---|
导入订阅后看节点名（×2、2.0x、[2x]） | 最直接 |
| 客服回复 | — |
| 注意 | 倍率是节点级的且会变，需注明观察日期与节点名 |
因为倍率会变，这类信息的保质期较短——提交时务必带日期。
订阅格式支持（站内完全没有）
| 需要记录 | 说明 |
|---|---|
| 后台提供哪些格式的链接 | Clash / sing-box / 通用 Base64 / Shadowrocket |
| 是否按 User-Agent 自动适配 | 部分机场只给一条链接 |
| 是否有强制指定格式的参数 | 如 &flag=clash |
这个信息直接决定读者能用哪个客户端，价值很高。
设备数上限（大多未提供）
| 怎么获得 | 说明 |
|---|---|
| 官网套餐页 | 部分有标注 |
| 客服回复 | 最常见 |
| 后台是否显示在线设备列表 | 这也是一个值得记录的字段（判断泄露的依据） |
一份完整的实测投稿模板
照这个格式提交，能直接被收录。
环境（整个测试周期内保持不变）
| 项目 | 填什么 |
|---|---|
| 运营商 | 电信 / 联通 / 移动 |
| 城市 | — |
| 宽带带宽 | — |
| 有线 / Wi-Fi | 有线（Wi-Fi 的数据会被标注局限） |
| 设备 | — |
| 客户端与版本 | — |
| 协议 | VLESS / Trojan / Hysteria2 / … |
| 是否开 TUN | — |
单次测试
| 项目 | 填什么 |
|---|---|
| 日期与时刻 | 2026-09-18 21:10 |
| 节点完整名 | 原样抄下来（含特殊符号、空格、emoji） |
| 节点标注的地区 | — |
| 倍率 | 1x / 2x / 未知 |
| ping 100 次：丢包率 | % |
| ping 100 次：min / avg / max | ms |
| 抖动（max-min 或 stddev） | ms |
| 多线程下载三次的中位数 | Mbps |
| traceroute 的关键观察 | 有无 202.97 等公网出口跳点、跳数、异常跳 |
三晚汇总
| 节点完整名 | 白天速度 | 21:00（第 1 晚） | 21:00（第 2 晚） | 21:00（第 3 晚） | 平均降幅 | 平均丢包 | 一致性 |
|---|---|---|---|---|---|---|---|
| — | — | — | — | — | — | — | 一致 / 波动大 |
解锁测试（如有）
| 节点完整名 | 测试日期 | 方法 | ChatGPT | Claude | Gemini | Netflix（非自制剧） | Disney+ |
|---|---|---|---|---|---|---|---|
| — | — | 无痕窗口 | ✓ / ✗ | — | — | — | — |
必须注明用了无痕窗口，以及流媒体测的是非自制剧——否则结论无法采纳。
观察与局限（很重要）
| 项目 | 填什么 |
|---|---|
| 范围性观察 | 比如"三个香港节点晚高峰丢包都在 0.1–0.3%" |
| 异常项 | 比如"某节点延迟 40ms 低于日本的物理下限，可能落地不在标注地区" |
| 本次测试的局限 | 比如"只测了香港与新加坡，未测美国" |
| 已排除的本地因素 | 有线、国内网站正常、已更新订阅 |
主动写"局限"会让你的数据更可信——它说明你知道这份数据能证明什么、不能证明什么。
为什么这个格式能被直接收录
| 特点 | 价值 |
|---|---|
| 环境完整 | 读者能判断对自己是否适用 |
| 节点名原样 | 后续可核对与复测 |
| 连续三晚 | 结论可靠 |
| 区分了丢包与速度 | 丢包是判断的核心 |
| 注明了测试方法 | 可复现 |
| 主动写局限 | 不夸大 |
名词速查
| 名词 | 含义 |
|---|---|
| 可核对的依据 | 官网截图（含日期）、官方公告、客服回复、带时间与方法的测试记录 |
null | 未测试 / 无依据，页面渲染为"—" |
monthly | 月均价；只给年付价时用它，price 留空 |
| 折算 | 页面对只有年付价的套餐的标注 |
verified | 是否已人工复核（影响是否进入排行榜与推荐位） |
| 派生字段 | 月均价、每 GB、完整度——构建时计算，不手填 |
sources | 信息来源记录 |
| 快照 | 一张测速图的范围性记录（不能支撑线路类型结论） |
published | 实测记录是否展示 |
一句话总结
本站最需要的贡献是来自不同网络环境的实测——因为跨环境不可比（六个影响变量里四个不可消除），而本站的测试环境是单一的，移动与联通宽带的数据尤其稀缺。其次是补全那些只有 1 家披露的字段（IP 类型、退款条款、客服方式、官网域名）以及站内完全没有的三项（节点倍率、订阅格式支持、设备数上限）。所有提交都需要可核对的依据：官网截图（含日期）、官方公告、客服回复、或带时间与方法的测试记录——本站不采纳传闻、主观评价、单个用户的"我这里不行"（跨环境不可比）、或对未来的担忧。提交前请先做五分钟自查（关代理测国内网站、换有线、手动更新订阅）——多数"连不上"会在这里解决。直接编辑 JSON 时最容易出错的是：未测过的字段要留 null 而不是填推测值、只给年付价的套餐 price 留空、只填 monthly、派生字段不要手填（构建时会自动计算）。
相关页面
- 规则：免责声明 · 收录、标注与撤销标注的规则 · 关于本站
- 方法：实测方法与环境说明 · 评测方法与写作规范 · 排行榜方法论
- 数据：机场数据库 · 实测中心 · 机场状态页 · 变动记录时间线
- 自查：超时与连接失败 · 速度慢怎么排查 · 节点波动
常见问题
我能贡献什么？
四类：补充品牌资料的缺失字段（IP 类型、退款条款、客服方式、官网域名各只有 1 家披露）、提交实测记录（尤其来自移动或联通宽带的数据）、报告可核实的状态变化或变动事件、以及对标注提出异议。
提交需要什么依据？
可核对的依据：官网页面截图（含日期）、官方公告、客服回复截图、可查的域名记录、或带时间与方法的测试记录。本站不采纳无依据的传闻、单个用户的主观描述或匿名消息。
什么贡献最有价值？
来自不同网络环境的实测——因为跨环境不可比，而本站的测试环境是单一的，移动与联通宽带的数据尤其稀缺。其次是补全那些只有 1 家披露的字段。
我连不上能提交事故报告吗？
通常不构成事故记录，因为单点观察难以作为整家的事件。先按超时与连接失败排查（手动更新订阅、换有线、测国内网站）——多数情况会在那里解决。
服务商可以申诉吗？
可以，与普通用户走同一流程、适用同一证据标准。恢复正常的复查步骤是官网 → 后台 → 订阅 → 抽查节点。本站不接受以商业合作换取撤销标注。
提交后多久会处理？
本站的核实是人工的，没有固定周期。依据充分会收录并标注日期；依据不足会回复说明需要补充什么。涉及状态变化的会同步到机场状态页。
为什么收录标准这么严？
因为一条错误的记录会直接影响服务商的声誉，也会误导读者——尤其错误的域名可能把读者引向假站。宁缺毋滥：这让收录变慢，但让每条记录都可信。
为什么未测过的字段要留 null 而不是填推测值？
"因为空白表示"未实测"，而推测值会被读者当成事实。一份不可靠的数据会让读者跳过自己的验证，而验证恰恰是唯一可靠的方法。