试用期 30 分钟验收流程：新买的服务到底能不能用
退款窗口是你唯一能低成本验证一项服务的时间段。错过它，之后的每一次"好像有点慢"都只能忍着。
但大多数人的验收方式是"打开几个网页，感觉还行"——这个方法测不出任何有意义的东西：单次网页打开的成功不能预测长连接的稳定性，白天的顺畅不能预测晚高峰的表现。
这篇给出一份按时间轴排布的验收流程，30 分钟跑完，产出一张可对照的结果表。它不告诉你"这家好不好"，它告诉你这家对你的网络、你的用途合不合适——这两件事完全不同，而后者才是你需要的答案。
开始前：记下三件事
验收的本质是对照，没有基线就没有对照。花两分钟记录：
- 你的网络环境：家宽 / 公司 / 蜂窝，运营商，大致带宽；
- 当前时段：白天和晚高峰的结论可能完全相反，务必记下；
- 你真正要用的场景：只是浏览网页，还是需要长时间流式传输、多设备同时在线、或者特定平台的访问。
第 3 条决定了后面哪些步骤对你最重要。只浏览网页的人不必纠结长连接测试；要跑流式任务的人则应该把重心放在那里。
0–5 分钟：导入与端口确认
目标：确认订阅真的导入成功了。 这一步失败的比例比多数人以为的高。
先导入订阅，然后不要急着看节点列表，先确认本地端口在监听：
connproof doctor看"常见本地代理端口"一项。列表里出现了端口才算导入成功——客户端界面显示节点列表，不代表内核起来了。如果端口是空的，多半是内核解析配置失败（协议字段太新、客户端版本太旧），详见 PROXY-003。
顺便看 doctor 输出的另外两项：系统时间是否准确、系统代理指向是否与客户端端口一致。这两项不对，后面所有测试的结论都会是错的。
5–10 分钟：分层检测
目标：确认节点在网络层是健康的。 挑三个不同地区的节点，每个跑一次：
connproof diagnose 节点域名 --port 节点端口判读标准：
| 观察项 | 可接受 | 需要警惕 |
|---|---|---|
| DNS 解析 | 几十毫秒内返回 | 数百毫秒以上，或只有 AAAA 记录 |
| TCP 建连 | 与地理距离相称（同区域几十毫秒，跨洋一两百） | 明显超出距离预期，说明绕路 |
| TLS 握手 | 约为 TCP 耗时的一到两倍 | 数倍于 TCP，或直接超时 |
| 三层结果 | 全部 pass | 任意一层 fail |
三个节点里有一个失败可能是个例；三个全部在同一层失败，说明这家在你的网络下有系统性问题——这是最有价值的早期信号，值得直接退款。
同时验证订阅链路本身：
connproof subscription "订阅地址"正常结果是 HTTP 200 且内容判定为"疑似订阅文本"。如果这一步就返回 HTML 或空内容，参见 SUB-003、SUB-002。
10–20 分钟：长连接稳定性
目标：找出连接能活多久。 这是网页浏览测不出、却决定实际体验的关键指标。
如果你的服务提供 WebSocket 端点，直接测：
connproof websocket wss://你的地址/路径 --hold 300000连续跑三次，记录每次的存活时长。判读：
- 三次都跑满五分钟 → 长连接稳定，可以放心用于流式任务；
- 三次时长高度接近（比如都在 60 秒左右）→ 链路上存在固定超时策略，参见长连接专题。这不一定是服务商的问题（可能是你的路由器 NAT），但会实际影响体验；
- 时长杂乱、忽长忽短 → 稳定性问题，重度用途要谨慎。
没有 WebSocket 端点的话，用一个实际的长任务代替：开一个大文件下载、跑一段流式输出，看它能否走完。中途断掉的话对照 LONG-001。
20–30 分钟：场景实测
目标：验证你真正要用的那个场景。 前面三步测的是"通不通"，这一步测的是"够不够用"。
按你在开始前记下的第 3 条，只测你真正需要的：
- 网页浏览：打开几个平时常用的站点，注意首屏时间而不是"能不能打开"；
- 流式与 AI 工具：跑一次完整的长输出任务，看是否中途中断——这是长连接问题的直接检验；
- 视频：连续播放十分钟，注意是否有卡顿与自动降清晰度；
- 多设备：同时连上两三台设备，看是否触发客户端数量限制或明显降速；
- 特定平台访问：直接试你需要的那一个。别信任何静态的"支持列表"——解锁状态随平台策略频繁变动，只有当下的实测算数。
结果记录表
把上面的结果填进这张表，它就是你的决策依据，也是将来出问题时的对照基线：
| 项目 | 结果 | 判定 |
|---|---|---|
| 端口监听 | 通过 / 失败 | |
| 节点 A 分层检测 | 三层耗时 | |
| 节点 B 分层检测 | 三层耗时 | |
| 节点 C 分层检测 | 三层耗时 | |
| 订阅链路 | 状态码 + 内容类型 | |
| 长连接三次时长 | 秒 / 秒 / 秒 | |
| 目标场景 | 可用 / 勉强 / 不可用 | |
| 测试时段 | 白天 / 晚高峰 |
把它导成文件存档：
connproof diagnose 节点域名 --port 节点端口 --format markdown --output baseline.md这份基线报告的价值会随时间增长。 三个月后你觉得"最近变慢了"，把新报告和它一比，是真的退化还是错觉，一目了然。
决策：什么情况下该退款
明确该退的：
- 三个节点在同一层系统性失败（不是个例，是这家在你的网络下不通）；
- 你的核心场景实测不可用，且换节点无改善；
- 长连接稳定性无法满足你的用途，且客服无解决方案。
不该急着退的：
- 单个节点有问题（换一个即可）；
- 白天正常、晚高峰差（这是容量问题，多数服务都有，看你能否接受）；
- 首次导入失败（先确认是不是客户端版本太旧——PROXY-003 那一类问题换服务也不会好）。
退款前务必先做一次归因：问题真的在服务端吗？完整判断方法见是机场问题还是我的问题。在自己配置有问题的情况下连退五家，是很多人真实经历过的浪费。
三个常见误区
误区一：只在白天测。 晚高峰（大致 20:00–23:00）是容量压力最大的时段，也是绝大多数体验落差发生的时段。至少在两个时段各测一轮。
误区二：把测速网站当唯一标准。 测速站测的是到那个测速节点的瞬时吞吐，它不能预测长连接稳定性、不能预测你实际用的那个平台的表现。分层检测 + 场景实测比它有信息量得多。
误区三：拿别人的评测当自己的结论。 同一条线路在不同城市、不同运营商、不同时段可以差出数倍。任何第三方跑分都不能迁移到你的网络上——这也是为什么这篇文章从头到尾在教你自己测，而不是给你一个排行榜。