疑難排解大全:依症狀逐層定位

排查框架:先定位故障層級

疑難排解裡最耗時間的部分從來不是修復,而是找錯方向。同樣一句「連不上」,可能來自帳戶狀態、本地網路、用戶端設定或目標服務本身,這四處的位置相差很遠,處理方式也完全不同。如果一上來就反覆切換線路,往往只是把同一個錯誤重演幾遍,還順手掩蓋了真正的線索。

本章先給一套分層框架和一份資訊蒐集清單。後面八章依具體症狀展開,每章都可以獨立閱讀,但建議先花三分鐘走一遍本章的分診流程,確認問題落在哪一層,再跳到對應章節。第一次接觸本服務的讀者,也可以先看 上手教學 把註冊、選方案、匯入訂閱這條主線走完,再回到這裡。

四個層級各自負責什麼

帳戶層。帳戶層管的是「有沒有資格連線」。訂閱是否在有效期內、當月流量是否已經用盡、方案是否到期,這三點決定了用戶端能不能從伺服器端取得有效的線路設定。VPNWing 的月訂閱分三檔:¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB,流量依開通日每月重置;另有流量包 ¥158/300GB、¥358/1000GB、¥658/3000GB,用完為止,永久不過期。如果當月額度已經用盡,用戶端通常表現為能連上但很快斷開,或者直接提示訂閱失效。中途升級方案時,差價會折算成剩餘天數,不需要重新計算週期。

網路層。網路層管的是「本地能不能出去」。這裡包括 Wi-Fi 訊號品質、路由器狀態、所在網路是否對特定連接埠有限制、DNS 是否能正常解析。判斷方法很直接:完全退出用戶端,只用本機網路存取幾個常用的本地網站,如果這一步就不通,那問題與 VPNWing 無關。

用戶端層。用戶端層管的是「設定對不對」。包括用戶端版本、訂閱是否成功匯入、分流規則是否把目標網域判給了直連、系統代理或虛擬網卡是否被其他軟體佔用。這一層的問題最容易被誤判成線路故障,因為表現同樣是「連上了但打不開」。

目標服務層。目標服務層管的是「對方是否正常」。有些網站會針對資料中心 IP 段做限制,有些服務在特定時段做維護,還有些區域限制與線路無關、只與出口歸屬地有關。判斷方法是換一條不同地區的線路再試同一個網站,如果所有線路都失敗,大概率是目標側的問題。

三分鐘分診:依序走一遍

1. 開啟使用者面板,確認訂閱狀態、剩餘流量與到期時間。這一步排除帳戶層。
2. 完全退出用戶端,用本機網路存取兩個常用網站,確認本地網路本身可用。這一步排除網路層的基礎連通性。
3. 重新開啟用戶端,切換到一條與目前不同的線路,優先換不同地區、不同線路類型,例如從直連換到 IEP 專線。這一步區分是單條線路問題還是全域問題。
4. 在瀏覽器裡先存取一個先前確認可用的網站,再存取先前失敗的目標網站。兩步對比可以區分「整體不通」和「單一網站不通」。
5. 如果以上都正常但目標網站仍然失敗,記錄下失敗時的具體提示文字,進入對應章節深入排查。

走完這五步,大多數問題已經能定位到具體章節。剩下的時間花在細節上,而不是反覆試錯。

關於同時在線裝置數的常見誤解

VPNWing 同時在線不限台數,一個帳戶可以在 Windows、macOS、iOS、Android、Linux 上同時使用,不需要為每台裝置單獨開通。因此當你看到與「連線數」「裝置數」相關的提示時,通常不是帳戶額度限制,而是本地環境的連線表被打滿了。

常見的兩個來源:一是家用路由器的 NAT 工作階段表容量有限,當同一網路裡同時有大量下載、影片、遊戲連線時,新建連線會失敗,表現和「裝置數超限」很像;二是作業系統本身的檔案描述符或連接埠佔用達到上限。這兩種情況的共同特徵是,中斷部分裝置或暫停大流量任務後連線立即恢復。如果符合這個特徵,處理方向是重新啟動路由器、減少並行連線數,而不是更換方案。

提工單前需要準備的資訊

工單裡資訊越完整,定位越快。以下幾項建議一次附上:

• 註冊時使用的使用者名稱,不需要提供密碼。
• 出問題的平台與系統版本,例如 Windows 用戶端、macOS 用戶端、iOS 用戶端、Android 用戶端、Linux 用戶端。
• 用戶端裡顯示的線路名稱與線路類型,例如東京 · IEPL 專線、香港 · 中轉。
• 故障開始的時間點,以及是持續出現還是間歇出現。
• 重現步驟:從開啟用戶端到出現問題的完整動作順序。
• 錯誤提示的原文或截圖,不要只寫「連不上」。
• 已經做過的自我檢查項目,例如換過哪幾條線路、換過哪個網路環境、是否重新安裝過用戶端。

什麼情況應當直接提工單

有三種情況不必繼續自我檢查,直接提交工單效率更高:一是同一帳戶下的所有裝置、所有線路在同一時間段全部失敗;二是用戶端在啟動或匯入訂閱時直接報錯退出,無法進入主介面;三是已經依對應章節的步驟完整走完一遍,問題仍然穩定重現。

工單入口在使用者面板內,提交後可以在同一頁面查看回覆。如果問題與計費或退款相關,VPNWing 提供 30 天無條件退款,在工單裡說明訂單資訊即可,不需要額外提供其他資料。

完全連不上:三個環節逐段判斷

「完全連不上」指用戶端無法建立連線:按鈕一直轉圈、進度停在某個百分比,或者剛顯示已連線就立刻退回未連線。這三種表現的成因差別很大,先分清屬於哪一種,能省掉大半試錯。

三種「連不上」的區別

第一種是握手前失敗:按下連線後很快報錯,連轉圈的時間都很短。這通常意味著用戶端根本沒能與線路入口建立工作階段,方向在本地網路或入口可達性。

第二種是握手中失敗:轉圈持續數秒到數十秒後失敗。這說明網路路徑是通的,卡在驗證、設定下發或加密協商環節。

第三種是握手後立即斷開:短暫顯示已連線,幾秒內又回到未連線。這類問題往往與設定完整性、系統代理衝突或安全軟體攔截有關。

握手前:先確認本地環境

第一步永遠是裸連對照。完全退出用戶端,不是最小化到系統匣,用本機網路存取兩個常用網站。如果這一步就打不開,問題不在 VPNWing,先處理本地網路:重新啟動路由器、切換 Wi-Fi 頻段,或者改用行動網路對比。

第二步檢查系統時間。加密握手依賴憑證有效期驗證,系統時間偏差過大,常見於長期休眠後喚醒或手動改過時區的裝置,會讓握手在第一步就失敗,而且錯誤提示通常很含糊。各平台的自動時間同步開關都在系統設定裡,開啟後重新啟動用戶端再試。

第三步檢查安全軟體。部分防毒軟體與防火牆會把用戶端建立的虛擬網卡判定為異常網路介面並攔截,表現為用戶端顯示已連線、但系統裡沒有出現新的網路介面。處理方式是把用戶端加入白名單,或者暫時關閉防護做一次對照測試。測試完記得恢復。

第四步檢查是否有第二個代理軟體在執行。兩個用戶端同時接管系統代理或同時建立虛擬網卡,會互相覆蓋設定,結果是兩邊都連不上。同一時間只保留一個。

握手中:驗證與訂閱

如果網路路徑確認通暢,下一步看訂閱。在使用者面板裡核對三件事:訂閱是否在有效期內、當月流量是否還有剩餘、方案是否已經到期。這三項任意一項不滿足,用戶端都會在驗證階段被拒絕。

訂閱匯入失敗也會表現為「連不上」。判斷方法是在用戶端裡手動觸發一次訂閱更新,看是否提示成功。如果更新失敗,直接跳到後面的訂閱更新章節,那裡有完整的排查路徑。

還有一種情況是用戶端版本與訂閱格式不匹配。訂閱內容會隨用戶端類型下發不同格式,如果手動貼上過設定,格式錯位會導致解析失敗。處理方式是清空目前設定,重新從面板取得一次訂閱,不要在舊設定上追加。

握手後:連上就斷

短暫連線後立刻斷開,常見原因有三個。

一是分流規則與本地網路衝突。例如規則把用戶端自身的更新網域判給了代理,而該網域在代理側不可達,用戶端在啟動自檢時就會失敗。處理方式是把用戶端更新網域加入直連規則,或暫時切換到全域模式做一次對照。

二是 MTU 不匹配。封裝後的資料包超過路徑 MTU 又沒有被正確分片,會導致大封包被丟棄,表現為連上了但幾秒內斷線。這個問題在部分行動網路和撥號環境下更常見,後面「能連上但網頁打不開」一章有詳細的判斷方法。

三是帳戶在別處被重複登入。雖然 VPNWing 同時在線不限台數,但如果同一帳戶在短時間內被大量裝置反覆登入,伺服器端可能觸發保護性限流。處理方式是確認沒有其他裝置在循環重連。

現象對照表

仍然不通時

如果換過至少兩條不同地區、不同類型的線路,直連與 IEPL 專線各一條,換過至少一個網路環境,問題仍然穩定重現,就應當提交工單。工單裡附上用戶端顯示的完整錯誤文字、故障開始時間、以及已經試過的線路名稱,能顯著縮短處理時間。

如果只是某一條線路在特定時段不可用,可以先換用其他線路繼續使用,同時在工單裡說明具體線路名與時段,便於針對性排查。

能連上但網頁打不開:分流、DNS 與 MTU

用戶端顯示已連線,狀態燈是綠的,但瀏覽器一直在轉圈,或者只有一部分網站打不開。這是排查裡最常見也最容易誤判的一類。它幾乎不是「線路壞了」,而是「流量有沒有走對路」的問題。

先分清兩種範圍

第一種是全都不通:連上之後任何網站都打不開,包括先前能正常存取的。這類問題通常出在系統代理設定、虛擬網卡沒有正確接管流量,或者 DNS 完全失效。

第二種是部分不通:一部分網站正常,另一部分打不開;或者同一個網站,首頁能開、點進詳細頁就失敗。這類問題通常出在分流規則、DNS 解析結果或 MTU。

判斷方法很簡單:連上之後依序存取三個網站,一個本地網站、一個常用的國際網站、一個先前失敗的目標網站。三步的結果組合基本能定位方向。

方向一:分流規則

分流規則決定哪些流量走代理、哪些直連。規則出錯有兩種典型表現。

一是該走代理的走了直連。目標網域被規則判為直連,於是請求直接從本地網路發出,自然打不開。這種情況在規則庫更新落後、或者目標網站更換了網域時出現。處理方式是在用戶端的規則清單裡搜尋目標網域,看它落在哪一條規則上;如果確實被判為直連,手動加一條代理規則,或者暫時切換到全域模式驗證。

二是該直連的走了代理。本地網站被送進代理通道,反而變慢或失敗。這類問題不影響連通,但會浪費流量,也容易讓人誤以為線路慢。

判斷技巧:切換到全域模式再試一次。如果全域模式下目標網站能開啟,問題就在分流規則;如果全域模式下仍然打不開,繼續往下看 DNS 和 MTU。

方向二:DNS 解析

DNS 問題的典型表現是能 ping 通位址,但網域打不開。原因是網域解析傳回了錯誤結果,或者解析請求根本沒有得到回應。

判斷方法是在命令列裡對同一個網域做一次解析,看傳回的位址是否合理。如果解析結果明顯異常,或者解析逾時,基本可以確認是 DNS 環節。

處理方式有三種,依侵入性從低到高:

1. 在用戶端裡切換 DNS 模式。多數用戶端提供跟隨系統、使用內建 DNS、指定上游這幾種選項,切換到內建 DNS 通常能避開本地電信業者的解析問題。
2. 手動指定一個可用的上游 DNS。設定後需要清除一次系統 DNS 快取,否則舊的解析結果還會被沿用。
3. 如果只有個別網域解析異常,可以在用戶端裡為該網域單獨指定解析方式,或者改用位址直接存取做一次對照。這種方式僅用於驗證,日常仍建議用網域。

方向三:MTU 與分片

MTU 問題的表現很有辨識度:小頁面能開啟,大頁面載入到一半停住;圖片顯示不全、影片卡在第一格、登入頁面提交後一直轉圈。原因是封裝後的資料包超過了路徑允許的最大長度,而路徑上的裝置又沒有正確傳回分片所需的控制訊息,於是大封包被無聲丟棄。

判斷方法是使用不允許分片的探測封包測試。在 Windows 上可以用 ping 的 -f 與 -l 參數組合,在 macOS 與 Linux 上用 ping 的 -D 與 -s 參數組合,逐步增大封包長度,找到不分片仍能收到回覆的最大值,再加上封包標頭長度就是可用 MTU。

處理方式是在用戶端或系統網路設定裡把 MTU 調低。常見的取值在 1400 附近,具體值需要依上面的探測結果確定,不要照抄別人的數字。調整後中斷重連一次讓設定生效。

用命令列縮小範圍

以下指令僅用於驗證連通性,不涉及任何帳戶資訊:

# 檢查網域解析結果
nslookup example.com

# 檢查目標是否可達(僅驗證連通性)
ping -c 4 example.com

# 檢查 HTTP 回應標頭,確認是網路問題還是網站問題
curl -I https://example.com

Windows 下把 ping -c 4 換成 ping -n 4。如果 nslookup 傳回異常位址,問題在 DNS;如果解析正常但 ping 全部逾時,問題在路由或分流;如果 ping 正常但 curl -I 逾時,問題更可能在 MTU 或目標網站側。

處理順序

建議依分流規則、DNS、MTU 的順序排查,因為三者的判斷成本依次上升。分流規則只需要切換一次全域模式;DNS 需要一條指令;MTU 需要多組探測。依這個順序走,大多數問題在前兩步就能解決。

如果三步都確認正常,但目標網站仍然打不開,換一條不同地區的線路再試。如果換線路後恢復,說明是原線路到該網站的路徑問題,記錄下來提工單即可。如果換線路後依舊,而本地網路存取該網站正常,那更可能是目標側對該地區出口做了限制。

速度慢:先分清頻寬不足還是線路繞路

「速度慢」是描述最模糊的一類回饋。同樣一句「慢」,可能是本地頻寬不足、可能是線路繞路、可能是目標網站限速,也可能是裝置本身在背景執行著別的任務。先把瓶頸定位到具體一段,再談最佳化。

先確認瓶頸在哪一段

一條完整的存取路徑可以拆成四段:裝置到路由器、路由器到本地電信業者、本地電信業者到線路入口、線路出口到目標網站。四段裡任何一段壅塞,最終表現都是「慢」,但處理方式完全不同。

一個基本的判斷原則:經過代理的速度不會超過本地出口頻寬。如果本地寬頻上行本身只有很小的值,那麼無論換哪條線路,上傳方向都不會變快。同理,如果家裡其他裝置正在做系統更新或雲端硬碟同步,可用頻寬會被先佔掉一部分。

分段測量的方法

第一步,中斷用戶端,測一次本地網路到本地網站的速度,記錄結果。這是基準值。

第二步,連上用戶端,測一次到同一地區網站的速度。如果這一步就明顯下降,問題在裝置到路由器這一段,檢查 Wi-Fi 訊號強度、頻段(2.4GHz 與 5GHz 的實際吞吐差別很大)、以及是否有同頻干擾。

第三步,連上用戶端,測一次到目標地區網站的速度。這一步反映的是跨境鏈路的品質。

三次結果放在一起看:如果第一步就慢,問題在本地;如果第一步正常、第二步明顯下降,問題在用戶端或路由器;如果前兩步正常、第三步慢,問題才在跨境線路。

需要強調的是,單次測速結果的波動很大,受測速伺服器負載、時段、瀏覽器快取影響。判斷時應連續測三次以上,看中位數而不是單次峰值。

線路選擇:地理鄰近不等於路由最佳

很多人預設「離得越近越快」,實際並不總是如此。跨境鏈路的品質取決於路由跳數、經過的骨幹網路、以及是否走獨立通道,而不只是直線距離。三類線路的差異可以這樣理解:

線路類型說明:IEPL 專線走獨立通道,中轉經骨幹節點轉發,直連為本地出口。完整的地區與類型清單可以在 線路列表 頁查看。

如果某條線路在白天表現良好、晚上明顯變慢,大概率是共用鏈路在尖峰時段壅塞,換到 IEPL 專線通常能改善。如果某條線路在任何時段都慢,那更可能是路由繞路,換地區比換類型更有效。挑選線路的通用方法可以參考 依地區、線路類型與用途選線 這篇。

用戶端設定的影響

幾個容易被忽略的設定項:

• 通訊協定與加密套件。加密強度越高,運算開銷越大。在低功耗裝置上,例如舊款行動裝置或入門級路由器,這部分開銷可能成為瓶頸。如果裝置效能有限,可以選用開銷更低的組合。
• 多工複用。開啟後多條連線共用同一條隧道,能減少握手次數,但在丟包率高的鏈路上可能放大阻塞。可以試著開關對比。
• 分流規則的複雜度。規則條目極多時,每次請求都要做一次比對,在低效能裝置上會帶來可感知的延遲。精簡規則或改用依網域後綴比對能緩解。
• 背景任務。系統更新、雲端硬碟同步、照片備份都會在背景佔用頻寬,而且往往在夜間自動啟動。排查速度問題時先確認這些任務的狀態。

什麼時候是方案額度的問題

如果速度下降的同時伴隨連線不穩定,建議先開啟使用者面板看一眼當月流量。VPNWing 的三檔月訂閱分別是 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB,流量依開通日每月重置。當月額度接近用盡時,部分用戶端會給出提示。

如果只是某個月用量偏大,可以購買流量包補充:¥158/300GB、¥358/1000GB、¥658/3000GB,用完為止,永久不過期。流量包與月訂閱的額度分開計算,不衝突。如果長期用量都超過目前檔位,升級月訂閱更划算,差價會折算成剩餘天數。三檔的完整對照可以在 方案與價格 頁看到。

不要用單次測速下結論

測速結果受太多因素影響,單次數字沒有參考價值。判斷一條線路是否適合自己,更實用的做法是在自己的常用時段、用自己常存取的網站,連續觀察幾天。如果某條線路在多數時段都穩定,就不必因為某一次測速數字偏低而換掉它。

如果依上面的方法分段測完,確認瓶頸在跨境鏈路,而且換過至少兩條不同地區的線路都沒有改善,可以把三次測量的時間、線路名稱與結果一併提交工單。

晚間尖峰卡頓:壅塞來源與線路切換

如果白天的連線一切正常,到了晚上七點到十一點之間開始卡頓、影片頻繁緩衝、會議聲音斷斷續續,這大概率不是裝置故障,而是跨境鏈路的共用資源在尖峰時段被佔滿。

為什麼偏偏是晚上

跨境存取的路徑上有一段是共用的。平日晚間是家用網路使用最集中的時段:影片、遊戲、下載、視訊會議同時湧入,國際出口的頻寬被大量佔用。與此同時,目標側的伺服器也處在自己的尖峰時段,回應速度同樣會下降。

這意味著兩件事。第一,晚間尖峰的卡頓往往是雙向疊加的結果,不完全是線路的問題。第二,單純換一條同類型的線路,改善可能很有限,因為新線路走的還是同一段壅塞鏈路。

三類線路在尖峰時段的表現差異

不同類型線路對壅塞的敏感度不同:

• IEPL 專線走獨立通道,不經過公共網際網路的壅塞段,在尖峰時段受到的影響最小。代價是單位成本更高,通常用於對穩定性要求高的場景。
• 中轉經骨幹節點轉發,前半段走最佳化路徑,後半段仍共用公共鏈路。尖峰時段表現介於專線與直連之間。
• 直連為本地出口直接出網,完全依賴公共鏈路,尖峰時段波動最明顯。

VPNWing 目前提供 120+ 國家 / 160+ 線路,涵蓋三種線路類型。日常瀏覽用直連通常夠用;如果晚間尖峰是主要使用時段,優先選 IEPL 專線或中轉。完整的線路清單與類型標註可以在 線路列表 頁查看,依地區分組,每條都標了類型。

先排除家裡的變數

在把問題歸給線路之前,先花兩分鐘排除本地因素:

1. 家裡是否有其他裝置在做大流量任務。系統更新、雲端硬碟同步、電視盒快取影片都會佔用頻寬,而且往往在晚間自動啟動。
2. Wi-Fi 是否被鄰居的同頻訊號干擾。晚間尖峰同樣是鄰居用網的尖峰,2.4GHz 頻段的干擾會明顯加劇。切換到 5GHz 頻段通常立刻改善。
3. 路由器是否長時間沒有重新啟動。部分家用路由器在連續運作數週後,工作階段表碎片化會導致新建連線變慢。重新啟動一次做對照。
4. 裝置本身是否在降頻。筆記型電腦在電池模式下會限制效能,加密解密的開銷隨之上升。

這四項排除掉之後,再把問題歸到線路上,判斷才準確。

可以做的五件事

第一,依用途選線路。視訊會議和大檔案傳輸優先 IEPL 專線;日常瀏覽和短影音用中轉或直連即可。不必所有場景都用同一條線路。

第二,錯開尖峰安排大流量任務。系統更新、備份、大檔案下載可以安排在白天或深夜,避開尖峰時段。

第三,減少並行。同一帳戶同時在線不限台數,但同時執行多個高頻寬任務會互相排擠。晚間尖峰期間可以暫停不必要的背景同步。

第四,關閉不必要的運算開銷。在效能有限的裝置上,選擇開銷更低的加密組合能騰出一些處理能力。

第五,記錄時段與線路。如果某條線路在固定時段穩定變慢,記錄下來。這份記錄對判斷是線路問題還是整體壅塞很有價值,也是提工單時最有用的資訊。

關於速率承諾

需要說明的是,VPNWing 不承諾具體的速率數字。跨境鏈路的實際速度受本地頻寬、目標網站、時段、路由等多重因素影響,任何固定的速率承諾都無法反映真實情況。可以確認的是線路類型與覆蓋範圍:120+ 國家 / 160+ 線路,三種線路類型可選,同時在線不限台數。

如果晚間尖峰的卡頓已經影響到正常使用,而且換過專線類型仍然沒有改善,建議提交工單,附上具體時段、線路名稱與使用場景。這類問題往往需要按線路逐個排查,提供的資訊越具體,定位越快。

頻繁斷線:重連策略與網路切換

斷線比連不上更讓人煩躁,因為它打斷的是正在進行的事情。排查斷線的關鍵不是「重連」,而是找出斷線的規律:間隔是否固定、是否與某個動作同時發生、是否只在某個網路下出現。規律一旦確認,原因基本就鎖定了。

三種斷線規律

第一種,間隔固定。每隔幾分鐘或幾十分鐘斷一次,間隔大致相同。這類問題通常與保活機制、心跳逾時或伺服器端的工作階段時限有關。

第二種,隨機出現。沒有固定間隔,有時幾小時不斷,有時十分鐘斷三次。這類問題多與網路環境有關:Wi-Fi 訊號波動、行動網路在基地台之間切換、或者上游鏈路抖動。

第三種,閒置後斷線。正在使用時不斷,放下不管一段時間後回來發現已經斷開。這是典型的 NAT 工作階段逾時,屬於預期行為而不是故障。

判斷方法很直接:記錄三次以上斷線的時間點,看間隔是否接近。三次就足夠看出規律。

規律性斷線:保活與逾時

如果間隔固定,先檢查用戶端的保活設定。多數用戶端提供心跳間隔或保活開關,開啟後用戶端會週期性地發送小封包維持工作階段。關閉保活時,鏈路上的中間裝置可能因為長時間沒有資料而回收工作階段,表現為固定間隔斷線。

第二個檢查點是伺服器端的工作階段時限。部分線路為了均衡負載會設定單次連線的時長上限,時間到後強制重連。這種情況的表現是:斷線後立刻能重連成功,而且重連後又能穩定使用一個相同的時長。如果符合這個特徵,說明不是故障,可以考慮換一條工作階段策略不同的線路。

第三個檢查點是系統休眠。筆記型電腦闔上螢幕、行動裝置鎖定螢幕後,系統會暫停網路活動,喚醒時隧道已經失效。處理方式是在系統電源設定裡允許網路裝置在睡眠時保持活動,或者養成喚醒後手動重連的習慣。

隨機斷線:網路切換與訊號

隨機斷線的排查重點是網路環境。

Wi-Fi 訊號波動。距離路由器較遠、中間隔牆、或者周圍同頻裝置多,都會導致丟包率上升。丟包達到一定程度後,用戶端判定鏈路不可用並觸發重連。判斷方法是靠近路由器再做一次對照,如果斷線頻率明顯下降,問題就在訊號。

行動網路切換。在移動中使用時,裝置會在基地台之間切換,每次切換都會短暫中斷資料連線。如果用戶端沒有做快速重連,表現就是斷線。這類問題在通勤路線上尤其明顯,屬於網路特性,處理方向是開啟用戶端的自動重連並縮短重試間隔。

雙網並存。部分裝置同時開著 Wi-Fi 與行動網路,系統會在兩者之間做智慧切換。切換瞬間隧道會失效。如果不需要雙網加速,建議關閉其中一個。

上游鏈路抖動。如果同一網路下的其他裝置也在同一時間出現網路中斷,問題在本地電信業者或上游,與 VPNWing 無關。判斷方法是同時觀察一台沒有走代理的裝置。

閒置後斷線:NAT 工作階段逾時

家用路由器和電信業者閘道器都會維護一張 NAT 工作階段表,表項有存活時間。一條長時間沒有資料的連線會被回收,回收之後隧道就斷了。這是所有基於 NAT 的網路都會遇到的現象,不是 VPNWing 特有的問題。

處理方式有兩種:一是開啟用戶端的保活,讓連線上始終有少量資料流動;二是在路由器設定裡延長 NAT 工作階段的逾時時間,部分路由器提供該選項,名稱可能是「TCP 逾時」「工作階段保持」之類。

需要注意的是,保活間隔不宜過短。間隔太短會讓用戶端持續發送小封包,在行動網路下增加耗電。多數場景下,幾十秒到幾分鐘的間隔已經足夠。

系統層面的干擾

幾個容易被忽略的干擾來源:

• 省電策略。Windows 的節電模式、macOS 的低耗電模式、Android 與 iOS 的電池最佳化,都會在背景限制網路活動。把用戶端加入白名單可以避免。
• 安全軟體的連網控制。部分安全軟體會對每個程式的連網行為做審核,在背景無聲阻斷重連請求。
• 虛擬網卡衝突。安裝過其他 VPN 或虛擬機軟體後,系統裡可能殘留多個虛擬網卡,路由優先順序混亂會導致間歇性斷線。清理不用的虛擬網卡通常能改善。
• 系統代理被改寫。部分軟體會定時改寫系統代理設定,改寫瞬間連線中斷。檢查是否有這類軟體在執行。

處理清單

1. 記錄三次以上斷線的時間點,確認是否有規律。
2. 開啟用戶端保活,觀察是否改善。
3. 換一個網路環境做對照,例如從 Wi-Fi 換到行動網路。
4. 檢查系統電源與省電設定,把用戶端加入白名單。
5. 清理不用的虛擬網卡與多餘的代理軟體。
6. 換一條不同線路類型的線路做對照。

如果依清單走完,斷線仍然穩定出現,而且能提供斷線時間點與線路名稱,就可以提交工單。這類問題通常需要結合伺服器端日誌排查,時間點越精確越有幫助。關於連線成功率與斷線率怎麼自己測,穩定性自測方法 這篇給了可重現的步驟。

訂閱更新失敗:位址、時間與格式三處核對

訂閱是用戶端與帳戶之間的設定通道。用戶端定期向訂閱位址請求一次,取得線路列表、分流規則與連線參數。訂閱更新失敗意味著用戶端拿不到最新設定,表現可能是線路列表為空、線路全部顯示逾時,或者用戶端提示設定無效。

訂閱是怎麼運作的

訂閱位址是一串帶權杖的連結,權杖與帳戶綁定。用戶端發起請求後,伺服器端依權杖識別帳戶,傳回對應格式的設定內容。整個過程有三個環節可能出錯:請求能不能發出去、伺服器端認不認這個權杖、傳回的內容用戶端能不能解析。

對應到排查上,就是三個方向:位址、時間、格式。

需要說明的是,訂閱位址屬於帳戶憑證,應當只在使用者面板裡取得,不要貼到公開管道,也不要發給他人。如果懷疑位址已經外洩,可以在面板裡重設。

方向一:位址本身

最常見的失敗原因是位址不完整。訂閱位址通常較長,從通訊軟體、郵件或筆記裡複製時容易被截斷,或者被自動加上換行與空格。

檢查三點:位址是否以完整的通訊協定開頭,中間沒有空格與換行;位址是否被通訊軟體做了智慧辨識,把一部分字元變成了連結或表情符號;位址末尾的參數是否完整,尤其是權杖部分。

另一個常見原因是位址被安全軟體改寫。部分安全軟體會對所有加密請求做中間人檢查,改寫請求後伺服器端無法識別權杖。判斷方法是在用戶端裡用同一網址請求兩次,如果兩次都失敗,而瀏覽器存取其他網站正常,可以嘗試暫時關閉這類檢查做對照。

方向二:時間與憑證

訂閱請求走的是加密連線,憑證驗證依賴系統時間。系統時間偏差過大時,憑證會被判定為無效,請求在握手階段就失敗,而用戶端給出的提示通常只是「更新失敗」,不會說明具體原因。

檢查方法:開啟系統時間設定,確認自動設定時間處於開啟狀態,並核對時區是否正確。跨時區旅行、長期休眠、手動改過時間都可能導致偏差。

如果時間正確但依然失敗,再看是否安裝了會攔截加密流量的軟體。這類軟體會替換系統憑證鏈,導致用戶端無法驗證伺服器端憑證。

方向三:格式匹配

訂閱內容會依用戶端類型下發不同格式。如果用戶端的類型辨識錯誤,或者手動選擇了不匹配的格式,解析就會失敗。

判斷方法:在面板裡重新取得一次訂閱,依用戶端類型選擇對應格式,不要手動拼接。如果用戶端支援多種格式,優先使用用戶端自動辨識的那個。

格式不匹配的另一個表現是「更新成功但線路列表為空」。這說明請求成功了,但傳回的內容沒有被正確解析。處理方式是清空目前設定後重新匯入,而不是在舊設定上追加。

用命令列驗證位址可達性

以下範例使用預留位址,僅用於說明方法。不要替換成真實訂閱位址後貼到公開場合:

# 檢查訂閱位址是否可達,只看回應標頭
curl -I "https://example.com/sub?token=YOUR_TOKEN"

# 檢查傳回內容的前幾行,確認是設定而不是錯誤頁
curl -s "https://example.com/sub?token=YOUR_TOKEN" | head -n 5

如果第一條指令傳回 4xx 或 5xx,說明伺服器端拒絕了請求,重點檢查權杖與位址完整性;如果傳回 200 但第二條指令輸出的是網頁而不是設定文字,說明請求被中間裝置攔截或重新導向了。

重新匯入的完整步驟

1. 在使用者面板裡確認訂閱處於有效狀態,當月流量未用盡。
2. 重新複製一次訂閱位址,複製後先貼到純文字編輯器裡檢查有沒有多餘字元。
3. 在用戶端裡刪除目前設定,建議先匯出備份,不要直接覆蓋。
4. 新增設定,貼上位址,等待更新完成。
5. 確認線路列表有內容,隨便選一條線路連線測試。
6. 如果用戶端支援,開啟自動更新,並設定一個合理的間隔。

仍然失敗時

如果依上面三步都確認無誤,訂閱仍然更新失敗,可以嘗試換一個網路環境再更新一次,部分公共網路會對非標準請求做攔截。如果換網路後成功,說明原網路存在限制。

如果所有網路環境下都失敗,提交工單時請附上更新失敗的具體提示文字、使用的用戶端平台、失敗開始的時間,以及是否在多個網路環境下重現。不要把完整訂閱位址貼在工單裡,只說明權杖末幾碼即可。

單一應用走不了代理:分流規則與轉發方式

瀏覽器一切正常,某個特定應用卻始終連不上。這類問題的排查思路與前面幾章完全不同。它不是「網路不通」,而是「這個應用的流量沒有依預期進入隧道」。

為什麼只有某個應用不行

不同的應用處理網路請求的方式差別很大:有的遵循系統代理設定,有的自己實作網路堆疊,有的直接用位址而完全跳過網域解析,還有的優先使用 UDP。分流規則通常依網域或行程比對,一旦應用的行為超出規則的涵蓋範圍,流量就會漏出去。

判斷的第一步是確認這個應用到底有沒有走代理。方法是連上用戶端後,在用戶端的連線日誌裡觀察是否有該應用的請求記錄。如果沒有記錄,說明流量根本沒進隧道;如果有記錄但請求失敗,說明進了隧道但目標側拒絕。

原因一:不讀系統代理

系統代理是一種約定,應用可以選擇遵守,也可以選擇忽略。部分應用直接建立連線,不查詢系統代理設定,於是流量繞過隧道直接發出。

處理方式是把用戶端切換到 TUN 模式,有的用戶端叫虛擬網卡模式或增強模式。TUN 模式在網路層接管流量,不依賴應用是否遵守系統代理,涵蓋範圍更廣。

代價是 TUN 模式需要更高的系統權限,並且在部分系統上可能與安全軟體衝突。切換後如果系統網路異常,先把模式切回來再排查。

原因二:硬編碼解析位址

有些應用內建了解析伺服器位址,或者直接寫死了伺服器端的位址,完全跳過系統解析。這種情況下,即使分流規則裡寫了對應網域,也不會被比對到。

判斷方法:在用戶端的連線日誌裡看目標位址。如果日誌裡顯示的是網域,說明走了系統解析;如果顯示的是位址,說明應用自己做了處理。

處理方式有兩種:一是把該應用的目標位址段加入代理規則;二是把用戶端切換到全域模式,讓所有流量都進隧道。全域模式只建議暫時使用,長期開啟會浪費流量,也會讓本地網站變慢。

原因三:UDP 與 QUIC

多數代理通訊協定對 TCP 的支援是完備的,對 UDP 的支援則要看具體實作。如果應用主要使用 UDP,例如語音通話、即時對戰遊戲、部分即時通訊,而用戶端沒有開啟 UDP 轉發,這些流量就會直接失敗。

另一個相關的問題是 QUIC。QUIC 基於 UDP,被不少網站用作首選傳輸方式。如果 UDP 被阻斷,而用戶端又沒有做回退處理,表現就是網頁一直轉圈,但換成別的瀏覽器又能開。

處理方式:在用戶端裡開啟 UDP 轉發,如果提供該選項;如果只影響瀏覽器,可以在瀏覽器設定裡關閉 QUIC,強制回退到 TCP;對於遊戲與語音類應用,優先選擇對 UDP 支援良好的線路。

原因四:憑證固定

少數應用會把伺服器端憑證的指紋寫死在程式碼裡,只信任特定憑證。這類應用經過任何中間人解密都會失敗,而代理正好會做類似的事情。

表現為應用提示網路異常或連線不安全,但同一裝置上的瀏覽器存取同一服務正常。這類問題通常沒有用戶端側的解決辦法,只能把該應用的網域加入直連規則,讓它走本地網路。如果本地網路本身無法存取該服務,那就只能等應用側調整。

依應用類型對照

排查順序

1. 確認應用的流量是否出現在用戶端日誌裡。沒有記錄,走「不讀系統代理」這條線。
2. 有記錄但失敗,看日誌裡的目標位址是網域還是位址。是位址,檢查硬編碼與規則涵蓋範圍。
3. 看是否與 UDP 相關。關閉 QUIC 或開啟 UDP 轉發做對照。
4. 仍然失敗,檢查憑證固定,把該應用的網域加入直連規則做對照。

如果確認是某條線路對該應用不友善,換一條線路類型再試。如果所有線路都一樣,記錄下應用名稱、平台,以及用戶端日誌裡的目標位址,提交工單時一併附上。遠距辦公場景下會議與協作工具的選線差異,可以參考 遠距辦公的線路選法 這篇。

行動裝置背景斷線與 DNS 解析異常

行動裝置的問題有兩個來源:系統對背景應用的限制,以及解析結果在切換網路後的殘留。這兩類問題在桌面端很少出現,在行動裝置上卻相當常見。

行動裝置為什麼會背景斷線

行動作業系統為了省電,會對背景應用做嚴格限制。當用戶端被切到背景,系統可能在一段時間後凍結它的網路活動,隧道隨之失效。回到前景時,用戶端需要重新建立連線,期間會出現幾秒到幾十秒的中斷。

這是系統設計使然,不是用戶端故障。判斷方法很簡單:把用戶端保持在前景,觀察是否還會斷線。如果前景穩定、背景斷線,就是系統的背景限制。

iOS 與 Android 的差異

iOS 對背景網路的限制更嚴格。系統會給 VPN 類應用一定的背景處理時間,但不會無限期保持。較長一段時間不使用時,連線可能被系統回收。iOS 上可做的設定有限,主要是允許用戶端使用背景重新整理、關閉低耗電模式,以及在需要長時間保持連線時把用戶端留在前景。

Android 的差異更大,因為各家廠商在系統層面做了額外的省電最佳化。常見的設定項包括電池最佳化白名單、背景活動限制、自啟動權限,以及鎖定背景之類的廠商特有開關。如果用戶端在某個品牌的裝置上特別容易斷線,優先檢查這幾項。

Linux 桌面端雖然不屬於行動裝置,但同樣存在類似的電源管理問題。筆記型電腦闔蓋休眠後,網路裝置可能需要重新初始化,隧道會失效。

讓行動裝置穩定在線的設定

依平台分別處理:

1. 系統設定裡找到該用戶端,把電池最佳化設為不限制,或加入白名單。
2. 允許背景活動與背景資料使用。
3. 關閉系統的智慧省電、超級省電模式,或在這些模式下把用戶端加入例外。
4. 在用戶端的設定裡開啟自動重連,並適當縮短重試間隔。
5. 如果不需要在行動網路下使用,可以設定為僅在 Wi-Fi 下保持連線,減少切換帶來的重連。

這些設定能減少斷線頻率,但無法完全消除。行動網路本身的切換、訊號死角、系統回收資源都會造成短暫中斷,這是行動場景的固有特性。

DNS 異常的典型表現

解析問題在行動裝置上更常見,因為裝置頻繁在 Wi-Fi 與行動網路之間切換,每次切換都會帶來解析伺服器的變化,而系統快取裡可能還留著上一次的解析結果。

典型表現有三種:能 ping 通位址但網域打不開,解析環節失敗但路由是通的;部分網域解析到錯誤位址,開啟後顯示的不是預期頁面;切換網路後一段時間內全部網域打不開,過幾分鐘自行恢復,這是快取過期後的自癒過程。

判斷方法:用系統內建的網路診斷工具,或者安裝一個能查詢解析結果的應用,對同一個網域做一次解析,看傳回結果是否合理。如果解析結果與在電腦上查到的不同,基本可以確認是解析環節。

各平台清除解析快取

清除快取能讓新的解析結果立即生效:

• Windows:在命令提示字元裡執行 ipconfig /flushdns。
• macOS:執行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。
• Linux:視發行版而定,使用 systemd-resolved 的系統執行 sudo resolvectl flush-caches。
• iOS 與 Android:系統沒有提供公開的快取清除入口,最直接的辦法是開關一次飛航模式,或者重新啟動裝置。

清除之後,建議在用戶端裡把解析方式設定為內建解析,避免再次被本地電信業者的解析結果影響。如果只是想確認目前出口的歸屬地,可以用站內的 IP 檢測 頁做一次查詢。

判斷順序與收尾

行動裝置問題建議依這個順序排查:

1. 確認是前景斷線還是背景斷線。背景斷線,走系統省電設定這條線。
2. 確認是否只在行動網路下出現。是,檢查網路切換與訊號。
3. 確認是全部網域失敗還是個別網域失敗。全部,檢查解析與隧道狀態;個別,檢查分流規則。
4. 清除解析快取,切換用戶端的解析模式,再試一次。

如果依順序走完仍然頻繁斷線,提交工單時請附上裝置型號與系統版本、用戶端平台、斷線發生時的網路類型,以及是否在背景時發生。這些資訊能幫助判斷是系統限制還是用戶端行為。

需要補充的是,VPNWing 同時在線不限台數,行動裝置與電腦可以同時使用同一個帳戶,不需要為行動裝置單獨開通。如果只是因為行動裝置偶爾斷線而想換方案,可以先依上面的步驟調整設定,多數情況下能明顯改善。