如何开启应急访问
为你的用户配置应急访问（OLCRTC）：Pro 订阅、应急线路、集群开关以及每台服务器的 runtime——按正确的顺序逐步完成。
本页是写给你——服务的所有者的。它讲的是如何开启应急访问，好让你的用户能够依靠它。面向用户本身另有单独的页面：应急访问——它如何运作、封锁期间该怎么做，以及安装应急客户端——在哪里下载应用、如何安装。
**应急访问（OLCRTC）**是面向白名单网络的备用通道，在这类网络里常规连接完全无法通过。流量仍然走你自己的服务器，只是被伪装成在许可服务上的一场视频通话。它不是第二种协议，也不是主连接的替代品：速度更慢，只适合短时间会话，由用户手动发起，并且只在其他一切都已失效时使用。
该功能属于实验性质，且正在分阶段放量。即便所有开关都已打开，应急 runtime 也可能还没有装到你的服务器上，会话启动也可能尚未生效：访问权限是逐步开放的。如果你启用之后，服务器长时间都没有变成「健康」，那多半只是放量还没轮到你。
它同样并非在每个网络、每个国家都能用，而且依赖外部视频服务和电子邮件是否可达。不要把它当作有保障的能力去承诺——请把它作为应对严厉封锁的一份保险来介绍。
你需要准备什么
- 一份 Pro 订阅（或 Max，它包含 Pro 的全部内容）；
- 至少一条被标记为应急的线路；
- 集群上已启用的 OLCRTC 开关；
- 该集群中至少有一台启用了 runtime 的服务器；
- 用户拥有已验证的邮箱和处于活跃状态的账户（详见下方的限制一节）。
操作顺序
开关一共有三个，分处三个不同的位置，而且很容易混淆——其中两个的名字几乎一模一样：
| 你要启用的对象 | 位置 | 名称 |
|---|---|---|
| 线路 | 线路设置（编辑时） | 「应急线路 (OLCRTC)」 |
| 集群 | 集群页面，线路列表上方 | 「为此集群启用 OLCRTC」 |
| 服务器 | 服务器面板，「编辑」按钮 | 「在此服务器上运行 OLCRTC」 |
顺序很重要：只要还没有应急线路，集群就不允许你启用 OLCRTC。先线路，后集群。
订阅 Pro。 进入账单 → 订阅板块。没有生效中的 Pro，应急访问的各个开关根本不会显示：集群页面上取而代之的是一张「应急访问 (OLCRTC)」卡片和一个**「升级」**按钮。
把线路标记为应急——在线路自身的设置里。 打开该线路进行编辑，在「应急访问 (OLCRTC)」板块中打开**「应急线路 (OLCRTC)」**。
这个开关只在编辑已有线路时才会出现。新建线路的表单里没有它：先创建线路，然后打开它的设置，再把它标记为应急。
这条线路上的服务器会加入应急池。你可以标记多条线路——池会把它们全部合并，如果某条线路上没有合适的服务器，连接就会落到另一条线路的服务器上。被标记的线路会在线路列表中显示应急标签。
为整个集群启用 OLCRTC。 这是第二个、独立的开关——不是线路里的那个。它位于集群页面上、带 OLCRTC 标记的「应急访问」板块中，就在线路列表上方，名称是**「为此集群启用 OLCRTC」**。
这是总开关：只要它是关的，无论你标记了多少条应急线路，该集群的用户都无法发起任何请求。开关下方可以看到池中已有多少条应急线路。
允许在服务器上启动会话。 点击某台服务器打开它的面板，找到应急 Runtime (OLCRTC) 板块，点击**「编辑」，打开「在此服务器上运行 OLCRTC」，然后点击「保存」**。
runtime 会在后台自行安装和更新——你不需要登录服务器。在它安装完成并开始上报之前，状态会显示为**「不健康」**；这是正常现象，请等待出现「健康 · N/M 活跃」。
该板块只在常规界面模式下可见——简化的 **Single（单台服务器）**模式里没有它。
设置容量。 还是在同一板块——最大并发会话数。你可以留空，但最好不要：见下一节。
一台服务器能承载多少会话
一个应急会话不是「多了一个 VPN 用户」——它的代价要高得多：服务器要把流量打包进视频流，而这需要消耗 CPU 时间。
在真实会话上的实测（Full HD 视频，约 5 Mbit/s）表明，一个会话大约占用一个核心的 15% 和 31 MB 内存。内存几乎无关紧要；真正的瓶颈是 CPU。
| 服务器核心数 | 合理的容量 |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
即使是独立服务器，也不建议超过这些数值：单个核心上跑四个会话，就已经占掉大约 60% 再加上后台负载。另外请注意，该测量是在观看视频（约 5 Mbit/s）时做的；如果用户把隧道跑满，一个会话的开销可能明显更高。
容量字段留空意味着「不限」。 这时唯一的保护就是那套自动机制：它会停止把新会话放到严重过载的服务器上。但它的反应有延迟，而在性能较弱的服务器上，到那时你的常规用户已经在受影响了。在单核服务器上，请明确设置容量。
均衡在一定程度上有帮助：如果线路使用最少负载算法（默认设置），CPU 占用高的服务器上报的可用带宽更少，新的常规用户就会被分配到负载较低的服务器上。但这是基于整体 CPU 占用的修正，而不是对应急会话的计数，而且它有几分钟的滞后——它不能替代明确设置的容量。
界面上都显示些什么
在每台服务器的应急 Runtime (OLCRTC) 板块中：
- 功能——是否允许在这台服务器上运行会话；
- 容量——你设定的并发会话上限（「未设置」= 不限）；
- Runtime——状态：「健康 · N/M 活跃」、「不健康」或「尚未上报」。
刚启用之后，出现**「不健康」**是预期之中的——这很正常，服务器还在安装 runtime，尚未上报。如果它长时间保持这个状态，请检查服务器是否还在线。「尚未上报」只会在页面加载的瞬间一闪而过。
值得提前了解的限制
一个会话最长存活 12 小时，之后自行停止。它无法延长——用户需要创建一场新的通话并发送一封新的邮件。
每个用户同时只能有一个会话。 第二封邮件不会创建任何东西，也不会得到回复——最好提前向用户说明，免得看起来像出了故障。
下行约 14 Mbit/s，上行不足 1 Mbit/s，延迟 175–235 毫秒。看视频和处理邮件很舒适；发送大文件、视频通话和玩游戏则不行。这是当前隧道配置的上限，而不是主连接的上限。
对用户的要求比看上去更严格。 必须有已验证的邮箱——你手动创建、没有邮箱的用户无法发起请求。账户还必须处于活跃状态：已暂停、已过期、流量已用尽以及等待首次付款（on_hold——所有自行注册但尚未付款的人）的账户都会被拒绝。邮件必须通过发件人身份验证，并且频率有上限：每个用户每小时五次请求，整个服务每小时一百次。
在这些检查上的拒绝是静默的：用户根本收不到任何回复。如果有人抱怨「我发了邮件，什么都没回来」，请先从账户状态入手，再确认发送的是不是正确的通话链接。
多跳线路不参与。 应急会话只使用直连线路。
iPhone 更麻烦。 iOS 客户端只能通过 sideload 安装——Apple 不上架它。你的 iPhone 用户需要提前、并且更仔细地做好准备；安装指南里有相关说明。
如何关闭
你可以随时取消为此集群启用 OLCRTC——新的会话将不再启动。已经在运行的会话会跑完它们的期限。
在 OLCRTC 处于开启状态时，最后一条应急线路既不能取消标记也不能删除：请先标记另一条线路，或者关闭集群上的 OLCRTC。
如果你的 Pro 订阅已经到期，你仍然可以关闭这些开关，但要重新开启就必须先续订。