On Demand 的三類觸發條件各自比對什麼、在 Settings → On Demand 裡怎麼加入規則、Action 要選 Connect 還是 Disconnect,以及規則沒生效時該依什麼順序排查。適合已經能在 Shadowrocket 手動連線、想讓它在切換網路時自動開關的讀者。
On Demand 是什麼:一個總開關加一組規則
Shadowrocket(小火箭)的 On Demand 就是「按需連線」:條件符合時由系統自動建立通道,條件消失時自動中斷,不必每次回到 Home 頁去點連線開關。入口在 Settings → On Demand,頁面結構只有兩部分——頂端的總開關決定這套機制是否啟用,下方的規則列表決定「在什麼條件下連線、在什麼條件下中斷」。
這些規則最後會寫進 iOS 的 VPN 設定,由系統在網路狀態變化時執行。所以 Shadowrocket 不必保持在前景,程序被系統回收後規則照樣生效。反過來也要留意:設定一旦寫入系統,移除 App 不會自動清掉它,「設定 → 一般 → VPN 與裝置管理 → VPN」裡可能還留著項目,需要在那裡手動刪除。
從條件符合到流量送出,中間隔著四個步驟。前三步由系統與 Shadowrocket 自動完成;第四步走哪條線路、哪些網域直連,仍然由 Home 頁的 Global Routing 與 Config 裡的規則決定。On Demand 只管「連不連」,不管「怎麼分流」,排查時不要把這兩件事混在一起。
On Demand 只決定連線時機,不提供線路。訂閱連結與節點請向你的服務商取得;客戶端買斷 ≠ 線路方案。
Wi-Fi 觸發:用 SSID 決定連線還是中斷
Wi-Fi 觸發比對的是目前連線的網路名稱,也就是 SSID。加入路徑是固定的:Settings → On Demand → 打開總開關 → 點規則列表右上角的 + → Type 選 Wi-Fi → 填 SSID → 選 Action。三個欄位各管一件事:Type 決定看什麼,Value 決定比對值,Action 決定符合後做什麼。
Action 只有 Connect 與 Disconnect 兩種值。家用 Wi-Fi 通常設 Disconnect:在家走寬頻直連,不需要通道;公司 Wi-Fi、飯店與咖啡廳的 Wi-Fi 設 Connect。省事的做法是只給「需要代理的網路」寫 Connect 規則,其餘網路不寫,保持手動控制。
Wi-Fi 觸發規則
- 入口
- Settings → On Demand → +
- Type
- Wi-Fi
- Value
- SSID,與系統顯示逐字元一致
- Action
- Connect / Disconnect
- 建議
- 家用 Wi-Fi 設 Disconnect
路由器改名或換裝置後,規則裡的 SSID 需要同步修改。
行動網路與網域觸發規則
- 入口
- Settings → On Demand → +
- Type
- Cellular
- Type
- Domain
- Value
- example.com,只寫主機名稱
- Action
- Connect
網域觸發會在系統準備存取該網域時啟動通道。
SSID 的比對是逐字元的:大小寫不同、結尾多一個空格、混入全形字元,規則都會安靜地不比對,介面上不會出現任何錯誤訊息。核對方法也很直接——在系統「設定 → Wi-Fi」裡看目前網路的名稱,把它和規則裡的 Value 對齊。
結論:先核對字串,再懷疑機制
Wi-Fi 規則沒生效時,先把 SSID 與系統裡顯示的字串逐字元對一遍;字串不一致是這類失效中最常見的原因,改完儲存即可重新生效,不需要重裝 App 或重開裝置。
行動網路與網域觸發:兩個不依賴目前 SSID 的條件
行動網路(Cellular)觸發看的是目前承載流量的網路類型:沒有連接 Wi-Fi、由行動數據提供網路時符合。典型組合是「Wi-Fi 規則負責在家斷開,行動網路規則負責出門連線」,從家門走出去的瞬間通道自動建立,不需要手動切換。
網域(Domain)觸發看的是請求目標:系統準備存取某個網域時把通道拉起來。寫法只填主機名稱本身,例如 example.com,不要帶 https://、不要帶路徑與連接埠,也不要寫成 IP 位址。它適合「只有存取某個服務時才需要代理」的情境,例如公司內網網域,或者只在特定網站使用的線路。
網域觸發有一個需要預期到的現象:規則在系統解析該網域、準備發起連線時生效,第一個請求有時已經先送出去,表現為第一次開啟頁面失敗、重新整理一次就正常。這是時序問題,不是規則寫錯。
三類觸發條件對照與常見設定錯誤
三類條件可以同時存在,系統依實際網路狀態與請求目標各自判斷。真正容易出錯的不是規則本身,而是幾條規則互相打架,或者規則與 Home 頁的 Global Routing 姿態對不上。
| 觸發類型 | 比對對象 | 典型用法與容易出錯的地方 |
|---|---|---|
| Wi-Fi | 目前連線的 SSID | 家裡設 Disconnect、公司設 Connect;SSID 逐字元比對,路由器改名後舊規則失效 |
| Cellular | 目前是否由行動數據承載 | 離開 Wi-Fi 後自動連線;與 Wi-Fi 互斥,同一時刻只有一個網路在承載流量 |
| Domain | 請求存取的主機名稱 | 存取 example.com 時自動連線;只寫主機名稱,第一個請求可能先走直連 |
結論:先用一條規則驗證機制,再補齊其餘條件
只給家裡 Wi-Fi 寫一條 Disconnect,在 Wi-Fi 與行動網路之間來回切換,看狀態列的 VPN 標記是否依預期出現與消失。機制跑通後再加行動網路與網域規則:從一條加到三條,排查成本不會翻倍;一次寫滿五條,出問題時得逐條二分。
開了 On Demand,連上家裡 Wi-Fi 反而上不了網?
先看規則列表裡針對家用 Wi-Fi 的那條是不是寫成了 Connect。家裡本來只需要直連,通道被拉起後如果線路本身不可用,就會表現為打不開頁面;把 Action 改成 Disconnect,再重新連一次 Wi-Fi。
換了路由器,原來的 Wi-Fi 規則沒反應了?
SSID 變了。回到 Settings → On Demand 點開那條規則,把 Value 改成新網路的名稱,大小寫與空格都要一致;舊值不會符合,與其留著不如刪掉這條再重新建立。
行動網路下頻繁自動中斷又重連?
多半是同一個情境裡同時存在 Connect 與 Disconnect 兩類規則,或者移動過程中網路類型反覆變化。先把規則收斂成「一個網路一個動作」,觀察是否還會跳動,再決定要不要保留行動網路規則。
網域規則要寫完整網址嗎?
不用。只寫主機名稱,例如 example.com,不要帶 https://、路徑、連接埠或查詢參數。帶路徑的寫法不會符合,因為觸發判斷發生在解析目標主機名稱這一步。
關掉 Shadowrocket 背景,On Demand 還生效嗎?
生效。規則寫在系統 VPN 設定裡,由系統在網路狀態變化時拉起通道;前提是這套設定已經成功建立過一次並在系統彈窗中取得授權,而且沒有在系統設定裡被刪除。
驗證與排查:按需連線沒依預期運作時怎麼辦
依固定順序排查,比反覆重裝 App 有效。以下五個步驟涵蓋了絕大多數情況,每一步都能在裝置上直接看到結果。
-
確認總開關Settings → On Demand 頂端的開關處於開啟狀態,規則列表裡至少有一條規則。
-
核對規則三要素Type、Value、Action 逐項確認;SSID 與系統「設定 → Wi-Fi」裡顯示的字串一致。
-
確認系統 VPN 設定iOS「設定 → 一般 → VPN 與裝置管理 → VPN」裡能看到對應設定;狀態列出現 VPN 標記,表示通道已經建立。
-
確認分流姿態Home 頁的 Global Routing 停在 Config,依規則分流;停在 Direct 時,即使通道建立也不會依預期走代理。
-
重建設定在 Home 頁把連線開關關掉再打開,讓 Shadowrocket 重新寫入 VPN 設定;仍不正常,就在系統 VPN 列表裡刪除舊設定後重新連線一次。
五步走完仍不生效,通常說明規則之間在互相干擾。把 On Demand 列表精簡到目前真正需要的兩三條,再逐條加回來,比一次寫十條規則更容易定位問題。規則本身只描述「何時連線」;連線之後能不能通,還要回到訂閱是否更新、線路是否可用這些環節去查。