會搜「Android VPN 推薦」的人,大多已經試過一兩款用戶端:裝好、連上、白天能用,第二天早上卻發現通知列的連線圖示不見了。問題通常不在協定,而在系統怎麼對待一個長期常駐的背景服務。Android 從 Doze 到背景執行限制,再到各家廠商自己的電池管理,每一層都在回收看起來沒在用的程序。本文依背景常駐、分應用程式代理、耗電三條線拆開比較,最後給一份可以直接照做的設定清單。所有比較都落在可重現的檢查項目上,不給無法核對的跑分數字。

先分清兩件事:能不能通,和能通多久

連線失敗和連線中斷是兩類問題,排查方向正好相反。前者看協定、訂閱與線路是否可用;後者看省電策略、背景權限與網路切換。把兩者混在一起,就會出現「換了三個協定還是斷」的循環。

中斷通常有三種表現。一是螢幕熄滅放置一段時間後,任何應用程式都請求逾時,點亮螢幕幾秒後自己恢復,這是系統把程序凍結了。二是從室內 Wi-Fi 走到室外切到行動網路,連線不自動恢復,要手動點一次重新連線,這是長連線在換網時失效。三是通知列圖示消失,但系統設定裡仍顯示連線已建立,這多半是殘留的通道介面,流量其實已經回到本地網路。

判斷通道是否還在,不要看用戶端介面,要看實際出口。疑似斷線時,開啟一個只有在走線路時才打得開的網址:立刻失敗代表通道已斷;仍然打得開,則更可能是應用層快取或分流規則放行,而不是連線真的還在。

背景常駐:三層設定,缺一層就會斷

Android 的省電機制分三層:系統級的 Doze 與應用程式待機、應用程式級的背景執行限制、廠商自訂的電池管理。三層各自獨立,只做其中一層,夜間斷線大概率還是會出現。

  1. 把用戶端加入電池最佳化白名單

    路徑通常是「設定 → 應用程式 → 特殊應用程式存取權 → 電池最佳化」,把篩選切到「所有應用程式」,找到用戶端後選「不要最佳化」。Android 6 引入的 Doze 會在螢幕熄滅後延後網路存取與喚醒,白名單是目前最穩定的豁免方式。部分廠商把這一項收進「電池 → 應用程式耗電管理」,名字不叫電池最佳化,要找的是「允許背景活動」這類開關。

  2. 開啟廠商的自啟動與背景執行權限

    自啟動、關聯啟動、背景執行這三項在不同系統裡叫法不同,作用卻一致:程序被回收之後還能不能被重新拉起。這一層不影響前景服務本身,但決定了被殺掉之後能不能自己回來。

  3. 保留常駐通知,並在最近使用的應用程式裡鎖定

    以 VpnService 為基礎的用戶端必須以前景服務執行,通知就是它的可見性憑證。關掉通知權限後,部分機型會把服務判定為不可見並加速回收,所以不建議為了「通知列乾淨」去關它。另外,在最近使用的應用程式清單裡給用戶端鎖定,能減少一鍵清理時的誤殺。

  4. 確認省電模式沒有單獨限制它

    不少系統會對「不常用應用程式」單獨凍結,也會在低電量模式下限制背景資料。把用戶端加入不受限制的名單,再檢查省電模式有沒有對背景資料做額外限制。

四步做完,夜間斷線基本上就會消失。如果還是會斷,優先懷疑兩件事:一是系統在低電量模式下統一掐斷背景資料,二是同時裝了另一個同樣以 VpnService 為基礎的用戶端在搶佔。

分應用代理:把通道收窄到需要的應用程式

Android 的 VpnService 提供允許與排除兩份應用程式名單,用戶端據此決定哪些應用程式的流量進通道、哪些走本地網路,這就是分應用程式代理。它有兩個作用:減少不必要的繞行以省電,以及避免某些應用程式因為出口地區變化而觸發風險控管。

名單有兩種寫法。白名單是「僅代理選取的應用程式」,只有勾選的應用程式走通道;黑名單是「排除選取的應用程式」,預設全部走通道,再挑出不需要的。日常更推薦黑名單:白名單容易漏掉系統元件,表現為下載管理員、推播、應用程式內更新時好時壞,排查起來很花時間。用戶端裡的入口一般叫「分應用程式代理」或「應用程式分流」。

分應用程式代理的常見分配方式,依應用程式類別給出建議
應用程式類別建議原因
銀行與支付類排除出口地區頻繁變化容易觸發二次驗證,走本地網路更省事
應用程式商店與系統更新排除下載量大,走本地頻寬更快,也不佔用訂閱流量
螢幕投放、印表機、路由器管理排除存取的是私有網段,本來就不該進通道
在地生活與常用服務視需要排除減少繞行,降低喚醒次數與耗電
境外串流媒體與開發工具代理需要固定出口地區,且對連線穩定度敏感
即時通訊與推播代理長連線需要穩定出口,頻繁切換會造成訊息延遲

排除某個應用程式後,它的解析與連線都走本地網路,這是預期行為,不算洩漏。真正要核對的是走通道的那部分:如果用戶端允許自訂 DNS,把解析指定到通道內,再用解析測試確認結果沒有落到本地電信商。

耗電:協定與心跳的取捨

耗電由三塊構成:無線模組被喚醒的次數、加解密開銷,以及封包遺失後的重傳。三塊裡最容易被忽略的是第一塊,心跳與重連把裝置從休眠裡叫醒,代價往往高於加解密本身。

加解密開銷

現代 ARM 處理器普遍帶有 AES 指令集擴充,AES 系加密的額外開銷很小;在沒有硬體加速的環境裡,ChaCha20 一類串流加密反而更省。對 Android 裝置來說,這一項通常不是耗電主因,除非裝置較舊,或者同時跑著多個加密連線。

心跳與重連

心跳間隔越短,連線越不容易被中間設備判定為閒置而回收,但喚醒次數也越多。TCP 系協定在切換網路後需要重新握手,重連本身要消耗一次完整建連;QUIC 系的 Hysteria2 與 TUIC 支援連線遷移,換網後不必重新握手,在行動網路下更平順。

UDP 的現實問題

QUIC 系協定全部跑在 UDP 上。部分網路會對 UDP 限速甚至直接丟棄,這時用戶端會不斷重傳,耗電反而高於 TCP 系。判斷方法很簡單:同一條線路下切換協定,看裝置在螢幕熄滅狀態下的耗電速度與重連頻率,哪個更穩定就用哪個。

取捨結論:固定 Wi-Fi、封包遺失明顯的環境優先選 QUIC 系;以通勤為主、省電優先的場景優先選 TCP 系。協定影響的是效率,背景喚醒才是耗電的大宗,常駐設定沒理順之前,換協定帶來的改善很有限。

協定與用戶端:Android 端的對照

協定決定握手方式與傳輸層,用戶端決定訂閱怎麼匯入、分應用程式代理怎麼設。兩者要分開看,不要用用戶端的表現去推斷協定好壞。

常見協定在 Android 端的注意事項
協定傳輸Android 端注意事項
ShadowsocksTCP / UDP開銷小、握手快;UDP 需要伺服器端開啟,否則語音與遊戲類流量走不通
VMessTCP / WebSocket / gRPC依賴裝置時間,時間偏差過大會直接握手失敗,先確認自動對時已開啟
TrojanTLS,通常 443與一般 HTTPS 同連接埠;設定裡的網域要與憑證一致,否則握手被拒
VLESSTLS / REALITY本身不加密,安全性由外層 TLS 承擔;開銷低於 VMess,適合長時間在線
Hysteria2QUIC(UDP)網路品質不佳時恢復快、換網不必重連;UDP 被限速時表現會明顯變差
TUICQUIC(UDP)同樣支援連線遷移,對 UDP 品質敏感,適合網路條件較好的場景

用戶端方面,v2rayNG、NekoBox、sing-box 系與 Clash Meta 系都能直接匯入訂閱連結。匯入方式有兩種:複製訂閱位址後在用戶端裡選「從剪貼簿匯入」,或者直接掃描 QR Code。訂閱連結是一份設定集合,不是帳號密碼,換裝置時重新匯入同一條連結即可,線路有更新時在用戶端裡手動更新訂閱。更細的匯入步驟見使用教學。

訂閱連結等同於憑證,不要貼到公開群組或截圖裡;發現外洩就儘快更換,不要把舊連結留在聊天記錄裡。

一週自檢清單

下面這份清單依「裝好之後第一週」的實際使用順序排列,逐條核對即可,不需要額外工具。

  • ✅ 螢幕熄滅放置一夜後,通知列的連線圖示仍在,開啟境外網站不需要手動重連
  • ✅ 從 Wi-Fi 切到行動網路再切回,連線在幾秒內自動恢復,應用程式不需要重新啟動
  • ✅ 分應用程式代理名單與預期一致:被排除的應用程式查到的出口位址是本地位址
  • ✅ 走通道的應用程式,解析結果落在通道內指定的 DNS 上,沒有落到本地電信商
  • ✅ 訂閱更新後線路清單變化正常,舊設定被取代而不是層層疊加
  • ❌ 通知權限被關閉,或用戶端仍處於「最佳化」狀態
  • ❌ 同時開著兩個以 VpnService 為基礎的用戶端,互相搶佔,同一時間只有一個能生效
  • ❌ 用一鍵清理清掉背景之後不再自動重連,也沒有加入任何白名單

選型:Android 端該看哪幾項

Android 端的選型順序與桌機端不同。桌機端先看協定與用戶端功能,Android 端要先看線路類型與常駐設定的配合度,再看流量與計費方式。

線路類型決定抖動。IEPL 專線、中轉、直連的差別在於中間經過幾段公共網路:專線把可控的一段收緊,中轉在入口做一次轉發,直連完全依賴公網路由。行動網路本身的抖動就大,專線的價值在於把線路這一側的變數先降下來。

90+國家覆蓋,依地區選線路
210+線路可選,專線與中轉並存
不限台數同一訂閱可在多台裝置上使用
7 天無理由退款,先試再決定

流量與計費方式依使用習慣選。經常線上追劇、長期掛著用戶端的,月訂閱更合適:¥9.9 每月含 60GB、¥18 每月含 250GB、¥28 每月含 500GB,流量依開通日每月重置,中途升級差價折算成剩餘天數。偶爾用、或者只在出差期間用的,流量包更划算:¥158 含 300GB、¥358 含 1000GB、¥658 含 3000GB,用完為止,永久不過期。

註冊環節也值得看一眼。VPNLS 不需要電子郵件地址,使用者名稱加密碼即可開通,付款走支付寶、微信或 USDT;VPNLS 固定不記錄日誌,這一點在選型時比多一個協定更有意義。

選型結論:Android 端的穩定度排序大致是常駐設定、線路類型、協定、用戶端。先把電池最佳化與通知權限理順,再談協定;順序反了,換什麼協定都會在夜裡斷一次。如果只做一件事,把用戶端加入電池最佳化白名單並保留它的常駐通知;如果做兩件事,再加上分應用程式代理的排除名單。