開啟緊急存取

為你的使用者設定緊急存取（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 訂閱已經失效，你仍然可以關閉這些功能，但要重新開啟就必須先續訂。