會搜「Android VPN 推薦」的人,大多已經試過一兩款用戶端:裝好、連上、白天能用,第二天早上卻發現通知列的連線圖示不見了。問題通常不在協定,而在系統怎麼對待一個長期常駐的背景服務。Android 從 Doze 到背景執行限制,再到各家廠商自己的電池管理,每一層都在回收看起來沒在用的程序。本文依背景常駐、分應用程式代理、耗電三條線拆開比較,最後給一份可以直接照做的設定清單。所有比較都落在可重現的檢查項目上,不給無法核對的跑分數字。
先分清兩件事:能不能通,和能通多久
連線失敗和連線中斷是兩類問題,排查方向正好相反。前者看協定、訂閱與線路是否可用;後者看省電策略、背景權限與網路切換。把兩者混在一起,就會出現「換了三個協定還是斷」的循環。
中斷通常有三種表現。一是螢幕熄滅放置一段時間後,任何應用程式都請求逾時,點亮螢幕幾秒後自己恢復,這是系統把程序凍結了。二是從室內 Wi-Fi 走到室外切到行動網路,連線不自動恢復,要手動點一次重新連線,這是長連線在換網時失效。三是通知列圖示消失,但系統設定裡仍顯示連線已建立,這多半是殘留的通道介面,流量其實已經回到本地網路。
判斷通道是否還在,不要看用戶端介面,要看實際出口。疑似斷線時,開啟一個只有在走線路時才打得開的網址:立刻失敗代表通道已斷;仍然打得開,則更可能是應用層快取或分流規則放行,而不是連線真的還在。
背景常駐:三層設定,缺一層就會斷
Android 的省電機制分三層:系統級的 Doze 與應用程式待機、應用程式級的背景執行限制、廠商自訂的電池管理。三層各自獨立,只做其中一層,夜間斷線大概率還是會出現。
-
把用戶端加入電池最佳化白名單
路徑通常是「設定 → 應用程式 → 特殊應用程式存取權 → 電池最佳化」,把篩選切到「所有應用程式」,找到用戶端後選「不要最佳化」。Android 6 引入的 Doze 會在螢幕熄滅後延後網路存取與喚醒,白名單是目前最穩定的豁免方式。部分廠商把這一項收進「電池 → 應用程式耗電管理」,名字不叫電池最佳化,要找的是「允許背景活動」這類開關。
-
開啟廠商的自啟動與背景執行權限
自啟動、關聯啟動、背景執行這三項在不同系統裡叫法不同,作用卻一致:程序被回收之後還能不能被重新拉起。這一層不影響前景服務本身,但決定了被殺掉之後能不能自己回來。
-
保留常駐通知,並在最近使用的應用程式裡鎖定
以 VpnService 為基礎的用戶端必須以前景服務執行,通知就是它的可見性憑證。關掉通知權限後,部分機型會把服務判定為不可見並加速回收,所以不建議為了「通知列乾淨」去關它。另外,在最近使用的應用程式清單裡給用戶端鎖定,能減少一鍵清理時的誤殺。
-
確認省電模式沒有單獨限制它
不少系統會對「不常用應用程式」單獨凍結,也會在低電量模式下限制背景資料。把用戶端加入不受限制的名單,再檢查省電模式有沒有對背景資料做額外限制。
四步做完,夜間斷線基本上就會消失。如果還是會斷,優先懷疑兩件事:一是系統在低電量模式下統一掐斷背景資料,二是同時裝了另一個同樣以 VpnService 為基礎的用戶端在搶佔。
分應用代理:把通道收窄到需要的應用程式
Android 的 VpnService 提供允許與排除兩份應用程式名單,用戶端據此決定哪些應用程式的流量進通道、哪些走本地網路,這就是分應用程式代理。它有兩個作用:減少不必要的繞行以省電,以及避免某些應用程式因為出口地區變化而觸發風險控管。
名單有兩種寫法。白名單是「僅代理選取的應用程式」,只有勾選的應用程式走通道;黑名單是「排除選取的應用程式」,預設全部走通道,再挑出不需要的。日常更推薦黑名單:白名單容易漏掉系統元件,表現為下載管理員、推播、應用程式內更新時好時壞,排查起來很花時間。用戶端裡的入口一般叫「分應用程式代理」或「應用程式分流」。
| 應用程式類別 | 建議 | 原因 |
|---|---|---|
| 銀行與支付類 | 排除 | 出口地區頻繁變化容易觸發二次驗證,走本地網路更省事 |
| 應用程式商店與系統更新 | 排除 | 下載量大,走本地頻寬更快,也不佔用訂閱流量 |
| 螢幕投放、印表機、路由器管理 | 排除 | 存取的是私有網段,本來就不該進通道 |
| 在地生活與常用服務 | 視需要排除 | 減少繞行,降低喚醒次數與耗電 |
| 境外串流媒體與開發工具 | 代理 | 需要固定出口地區,且對連線穩定度敏感 |
| 即時通訊與推播 | 代理 | 長連線需要穩定出口,頻繁切換會造成訊息延遲 |
排除某個應用程式後,它的解析與連線都走本地網路,這是預期行為,不算洩漏。真正要核對的是走通道的那部分:如果用戶端允許自訂 DNS,把解析指定到通道內,再用解析測試確認結果沒有落到本地電信商。
耗電:協定與心跳的取捨
耗電由三塊構成:無線模組被喚醒的次數、加解密開銷,以及封包遺失後的重傳。三塊裡最容易被忽略的是第一塊,心跳與重連把裝置從休眠裡叫醒,代價往往高於加解密本身。
加解密開銷
現代 ARM 處理器普遍帶有 AES 指令集擴充,AES 系加密的額外開銷很小;在沒有硬體加速的環境裡,ChaCha20 一類串流加密反而更省。對 Android 裝置來說,這一項通常不是耗電主因,除非裝置較舊,或者同時跑著多個加密連線。
心跳與重連
心跳間隔越短,連線越不容易被中間設備判定為閒置而回收,但喚醒次數也越多。TCP 系協定在切換網路後需要重新握手,重連本身要消耗一次完整建連;QUIC 系的 Hysteria2 與 TUIC 支援連線遷移,換網後不必重新握手,在行動網路下更平順。
UDP 的現實問題
QUIC 系協定全部跑在 UDP 上。部分網路會對 UDP 限速甚至直接丟棄,這時用戶端會不斷重傳,耗電反而高於 TCP 系。判斷方法很簡單:同一條線路下切換協定,看裝置在螢幕熄滅狀態下的耗電速度與重連頻率,哪個更穩定就用哪個。
取捨結論:固定 Wi-Fi、封包遺失明顯的環境優先選 QUIC 系;以通勤為主、省電優先的場景優先選 TCP 系。協定影響的是效率,背景喚醒才是耗電的大宗,常駐設定沒理順之前,換協定帶來的改善很有限。
協定與用戶端:Android 端的對照
協定決定握手方式與傳輸層,用戶端決定訂閱怎麼匯入、分應用程式代理怎麼設。兩者要分開看,不要用用戶端的表現去推斷協定好壞。
| 協定 | 傳輸 | Android 端注意事項 |
|---|---|---|
| Shadowsocks | TCP / UDP | 開銷小、握手快;UDP 需要伺服器端開啟,否則語音與遊戲類流量走不通 |
| VMess | TCP / WebSocket / gRPC | 依賴裝置時間,時間偏差過大會直接握手失敗,先確認自動對時已開啟 |
| Trojan | TLS,通常 443 | 與一般 HTTPS 同連接埠;設定裡的網域要與憑證一致,否則握手被拒 |
| VLESS | TLS / REALITY | 本身不加密,安全性由外層 TLS 承擔;開銷低於 VMess,適合長時間在線 |
| Hysteria2 | QUIC(UDP) | 網路品質不佳時恢復快、換網不必重連;UDP 被限速時表現會明顯變差 |
| TUIC | QUIC(UDP) | 同樣支援連線遷移,對 UDP 品質敏感,適合網路條件較好的場景 |
用戶端方面,v2rayNG、NekoBox、sing-box 系與 Clash Meta 系都能直接匯入訂閱連結。匯入方式有兩種:複製訂閱位址後在用戶端裡選「從剪貼簿匯入」,或者直接掃描 QR Code。訂閱連結是一份設定集合,不是帳號密碼,換裝置時重新匯入同一條連結即可,線路有更新時在用戶端裡手動更新訂閱。更細的匯入步驟見使用教學。
訂閱連結等同於憑證,不要貼到公開群組或截圖裡;發現外洩就儘快更換,不要把舊連結留在聊天記錄裡。
一週自檢清單
下面這份清單依「裝好之後第一週」的實際使用順序排列,逐條核對即可,不需要額外工具。
- ✅ 螢幕熄滅放置一夜後,通知列的連線圖示仍在,開啟境外網站不需要手動重連
- ✅ 從 Wi-Fi 切到行動網路再切回,連線在幾秒內自動恢復,應用程式不需要重新啟動
- ✅ 分應用程式代理名單與預期一致:被排除的應用程式查到的出口位址是本地位址
- ✅ 走通道的應用程式,解析結果落在通道內指定的 DNS 上,沒有落到本地電信商
- ✅ 訂閱更新後線路清單變化正常,舊設定被取代而不是層層疊加
- ❌ 通知權限被關閉,或用戶端仍處於「最佳化」狀態
- ❌ 同時開著兩個以 VpnService 為基礎的用戶端,互相搶佔,同一時間只有一個能生效
- ❌ 用一鍵清理清掉背景之後不再自動重連,也沒有加入任何白名單
選型:Android 端該看哪幾項
Android 端的選型順序與桌機端不同。桌機端先看協定與用戶端功能,Android 端要先看線路類型與常駐設定的配合度,再看流量與計費方式。
線路類型決定抖動。IEPL 專線、中轉、直連的差別在於中間經過幾段公共網路:專線把可控的一段收緊,中轉在入口做一次轉發,直連完全依賴公網路由。行動網路本身的抖動就大,專線的價值在於把線路這一側的變數先降下來。
流量與計費方式依使用習慣選。經常線上追劇、長期掛著用戶端的,月訂閱更合適:¥9.9 每月含 60GB、¥18 每月含 250GB、¥28 每月含 500GB,流量依開通日每月重置,中途升級差價折算成剩餘天數。偶爾用、或者只在出差期間用的,流量包更划算:¥158 含 300GB、¥358 含 1000GB、¥658 含 3000GB,用完為止,永久不過期。
註冊環節也值得看一眼。VPNLS 不需要電子郵件地址,使用者名稱加密碼即可開通,付款走支付寶、微信或 USDT;VPNLS 固定不記錄日誌,這一點在選型時比多一個協定更有意義。
選型結論:Android 端的穩定度排序大致是常駐設定、線路類型、協定、用戶端。先把電池最佳化與通知權限理順,再談協定;順序反了,換什麼協定都會在夜裡斷一次。如果只做一件事,把用戶端加入電池最佳化白名單並保留它的常駐通知;如果做兩件事,再加上分應用程式代理的排除名單。