VPN 故障排除手冊

從現象開始，不從猜測開始

有效排查的起點不是「線路壞了」或「用戶端有問題」，而是可重複觀察的現象。例如：所有線路都無法建立連線；只有目前網路環境無法連線；連線狀態已顯示成功，但瀏覽器與其他應用程式都無法存取；只有某個應用程式不走代理；訂閱連結可以開啟，卻無法更新線路清單。這些描述分別指向傳輸層、系統網路、DNS、分流規則與訂閱解析等不同環節。先寫清楚現象，之後每次變更才有明確的驗證目標。

建議先保留目前設定，不要立刻刪除訂閱。確認方案仍有效、可用流量尚未用盡，並觀察用戶端能否正常顯示原有線路。月訂閱流量會依開通日每月重設；若剛好接近重設時間，應以使用者面板顯示的狀態為準。若使用流量包，流量用完為止且永久不過期。方案規則可在價格頁面核對，帳戶中的實際狀態則應以面板為準。

用對照測試找出範圍

最有價值的對照通常來自網路、線路、用戶端與裝置。目前網路無法連線時，切換到另一個可用的網路環境；某條線路異常時，切換到不同地區或不同類型的線路；某個用戶端異常時，在保留訂閱的前提下檢查另一個受支援的平台；某台裝置異常時，對照同一帳戶下其他裝置的表現。VPNQD 不限同時上線裝置數，因此多裝置對照不會因固定裝置上限而自然失效，但同一裝置內重複匯入、殘留程序與系統網路擴充功能仍可能互相影響。

每次對照只變更一個條件。若同時更換網路、線路並重新安裝用戶端，即使問題消失，也無法知道究竟是哪一步生效。更穩妥的記錄方式是寫下「變更前現象、唯一修改項目、變更後結果」。結果不必複雜，只需區分能否連線、能否解析網域、能否開啟網頁、是否只有個別服務異常，以及斷線能否重現。這類記錄也能顯著提高後續工單的處理效率。

保留可恢復的基準狀態

在編輯規則、替換 DNS 或修改系統網路前，應先記錄原始狀態。用戶端支援匯出設定時，可儲存一份副本；不支援匯出時，則可記錄模式名稱、目前線路與已啟用的系統代理選項。不要將真實訂閱網址貼到公開論壇、截圖或共用文件中。需要示範格式時，應使用明顯的假值，例如：

https://example.com/sub?token=YOUR_TOKEN

排查完成後，應撤銷不必要的臨時修改，尤其是全域代理、除錯記錄，以及為了驗證而關閉的分流規則。最終設定應回到可解釋、可重現，也能在重新啟動後持續運作的狀態。若必須依賴一組無法說明原因的偶然設定，問題通常尚未真正定位。

先區分「沒有線路」與「線路握手失敗」

用戶端畫面空白、線路清單過期，以及點擊連線後持續等待，是不同的問題。若用戶端內沒有任何線路，優先前往訂閱更新章節；若看得到線路，但點擊後立即回到未連線狀態，應查看用戶端是否提示權限、設定或驗證錯誤；若長時間停留在連線中，則更可能與目前網路、線路可達性、系統時間或殘留程序有關。不要將這些現象一概歸為伺服器故障，因為處理路徑並不相同。

登入使用者面板，確認帳戶狀態與訂閱是否有效。若近期更換了使用者名稱或密碼，不應將面板密碼誤填到用戶端的其他驗證欄位。訂閱通常由面板提供，不需要手動拆分成多個未知參數。若面板可以正常進入，但用戶端訂閱已失效，應從面板重新取得目前訂閱，再替換舊內容；不要自行在舊網址後新增參數，也不要透過第三方轉換站處理真實訂閱。

核對系統網路權限與殘留狀態

Windows 與 Linux 的常見問題是用戶端未取得建立網路介面或修改路由所需的權限；macOS、iOS 與 Android 則可能在首次連線時出現系統網路擴充功能或 VPN 設定確認。拒絕過權限後，用戶端介面仍可能允許點擊連線，但系統不會真正建立通道。應進入系統網路設定，確認對應設定存在且處於允許狀態。若系統中同時保留多個舊設定，應先退出相關用戶端，再刪除確定不再使用的舊項目，避免多個網路擴充功能競爭控制權。

用戶端異常退出後，背景程序可能仍佔用系統代理或虛擬介面。此時重複點擊連線只會疊加錯誤。應先完全退出用戶端，而不是只關閉視窗；接著確認系統代理是否仍指向已停止的本機程序，再重新啟動。若裝置剛從睡眠狀態恢復，也可以先中斷現有連線，等待系統網路恢復後再連線。不要在用戶端仍執行時頻繁重設系統網路，這會讓介面狀態與系統實際狀態分離。

比較目前網路與其他線路

先在未啟用加速連線的狀態下，確認目前網路能正常存取一般網站。若基礎網路本身無法解析網域、需要網頁驗證，或處於受限的訪客網路，用戶端通常也無法建立連線。公共網路常要求先在瀏覽器完成接入確認；若該頁面未出現，可以暫時關閉系統代理後重新開啟一般網頁，讓網路完成自身驗證流程，再回到用戶端連線。

基礎網路正常後，從伺服器頁面了解 IEPL 專線、中轉與直連的用途，再選擇不同類型或不同地區的線路進行對照。若只有目前線路失敗，保留錯誤資訊並切換同地區的其他線路即可；若所有線路都失敗，再更換可用網路環境重新測試。不同網路下結果相反，表示問題較接近本地網路路徑；不同網路下結果一致，則應繼續檢查用戶端權限、訂閱內容與系統時間。

何時應停止本機嘗試

如果帳戶有效、訂閱可以更新、系統權限已確認，且在不同網路環境下所有線路都無法建立連線，應提交工單。工單需要寫明平台名稱、用戶端名稱、故障開始時的操作、是所有線路還是個別線路受影響、不同網路下的對照結果，以及用戶端顯示的完整錯誤資訊。若記錄中包含訂閱網址或驗證內容，應先遮蓋敏感部分；不要只寫「連不上」，因為這項描述無法區分網路拒絕、權限錯誤、設定損壞與訂閱失效。

若只有某個系統使用者、某個網路介面或某次系統升級後出現異常，也應一併說明。客服會根據這些範圍資訊判斷是否需要更換線路、重新下發訂閱，或引導清理系統殘留。沒有範圍資訊時，處理只能從最基本的步驟重新詢問，反而會延長定位過程。

連線狀態不等於完整存取鏈路已可用

用戶端顯示已連線，只能說明本機用戶端與所選線路完成了連線流程。瀏覽器存取還要經過系統路由、代理接管、網域解析、目標服務回應與應用程式自身快取。若連線後所有網站都無法開啟，先判斷系統流量是否真的進入用戶端；若只有網域無法開啟但已知網路請求仍可送出，應優先檢查 DNS；若只有個別網站異常，則更可能與目標地區、瀏覽器狀態、分流規則或目標服務自身策略有關。

首先關閉用戶端中的臨時規則修改，回到可辨識的預設設定。檢查系統是否同時啟用了手動代理與用戶端的虛擬網路模式。兩種接管方式疊加時，瀏覽器可能將請求送到已不存在的本機連接埠，或形成重複轉送。若用戶端支援系統代理與虛擬介面兩種工作方式，應依照其說明選擇一種主要方式測試，而不是全部開啟。驗證期間也應退出其他會修改代理、DNS 或網路過濾的工具。

用網域解析命令分離 DNS 問題

命令列測試的目的不是追求複雜，而是確認系統能否將網域解析為位址。Windows 可使用系統內建的名稱查詢命令，macOS 與 Linux 也可以使用常見的查詢工具。範例網域應選擇公開且穩定的測試網域，不要把真實訂閱網址放入命令歷史：

nslookup example.com

curl https://example.com

如果名稱查詢失敗，而用戶端記錄持續出現解析相關提示，問題集中在 DNS 或系統網路；如果查詢成功但瀏覽器失敗，應繼續檢查瀏覽器代理、擴充功能與快取；如果命令列與瀏覽器都失敗，但關閉連線後恢復，則需要比較線路與接管模式。命令輸出不要只截取最後一行，完整的錯誤類型、查詢對象與所使用的解析器更有價值。

處理 DNS 快取與解析衝突

切換網路、線路或代理模式後，系統與瀏覽器可能繼續使用舊的解析結果。應先完全退出瀏覽器再重新開啟，並使用系統提供的網路重新整理方式清理過期狀態。若用戶端允許選擇由系統解析或由用戶端解析，可以分別測試，但一次只保留一種設定。不要同時在路由器、系統、瀏覽器與用戶端中填入多組自訂 DNS；層級越多，就越難判斷查詢實際經過哪裡。

部分瀏覽器具備獨立的安全 DNS 功能，可能繞過系統設定。若其他應用程式可以存取，只有瀏覽器的網域解析異常，可以暫時讓瀏覽器跟隨系統設定進行對照。驗證後再決定是否恢復瀏覽器的獨立解析。企業網路或受管理裝置還可能下發固定代理與憑證策略，這類策略應由裝置管理員確認，不宜透過刪除管理設定來規避。

個別網站無法開啟時不要重設整個網路

個別網站異常時，先用同一條線路存取其他服務，並換另一個瀏覽器或隱私視窗，排除舊 Cookie、快取與擴充功能的影響。接著檢查該網域在規則中是直連、代理，還是被錯誤攔截。若切換到接近目標地區的線路後恢復，表示應調整線路選擇，而不是重新安裝用戶端。相關地區與線路類型可在伺服器目錄中查詢。

如果不同裝置、不同網路與不同線路都只對同一個目標服務出現異常，可能需要由客服確認線路端情況。提交工單時附上目標網域、發生時使用的線路名稱、是否能開啟同類網站、網域查詢結果與瀏覽器錯誤頁。不要只傳送整頁截圖而省略網址列，也不要在截圖中暴露帳戶憑證或真實訂閱網址。

先確認慢在哪裡

「速度慢」至少應拆分為建立連線慢、網頁首次開啟慢、持續下載慢、影片緩衝、互動延遲明顯，或速度忽快忽慢。網頁首次開啟慢，往往與 DNS、建立連線或目標網站回應有關；持續傳輸慢則更接近本地網路品質、線路壅塞或目標服務限速；互動遲緩則更受距離、路由與抖動影響。不同現象需要不同對照，不能只憑一次測速結果判斷所有應用程式的體驗。

測試前先關閉正在同步、備份、下載或更新的工作，確認同一網路下沒有其他裝置持續佔用出口。接著記錄未連線時的基礎表現，再於同一裝置、同一網路與同一目標下測試所選線路。若基礎網路本身不穩定，跨境線路無法修復本地無線干擾或上游寬頻壅塞。相關測速方法可參考VPN 速度實測怎麼做，重點是維持測試條件一致，而不是追逐單次峰值。

尖峰時段要比較時段，不要只比較節點名稱

尖峰時段卡頓常表現為白天正常、集中使用時段出現波動。判斷時應保留同一條線路，在不同網路時段重複相同操作；接著在同一時段比較不同線路類型。如此可以區分目標服務波動、目前網路出口壅塞與線路路徑變化。如果只在卡頓時連續切換許多節點，短暫恢復可能只是目標服務重新建立連線，不能證明最後選擇的節點長期更合適。

IEPL 專線、中轉與直連的路徑結構不同。線路名稱不是速度承諾，也不能脫離所在地與目標服務單獨排名。距離較近的地區通常適合作為起點，但目標內容位於其他地區時，出口位置同樣重要。應依用途建立自己的常用線路組：網頁與 AI 工具重視互動穩定性，持續傳輸更看重長時間吞吐量，串流媒體還要考慮內容所在地區。不要讓一條線路承擔所有情境。

檢查協定、接管模式與裝置負載

裝置效能不足、節能模式、背景安全掃描與虛擬介面衝突，都會影響吞吐量。行動裝置處於低電量策略時，系統可能限制背景網路；桌面裝置同時執行虛擬機器、容器或其他網路過濾程式時，資料會經過更多處理層。排查時應關閉無關的高負載工作，並觀察用戶端程序是否異常佔用資源。若只有某台舊裝置速度慢，而同一線路在其他裝置正常，重點應轉向裝置與系統環境。

用戶端提供多種接管模式時，應以預設建議作為基準。全域模式不一定更快，規則模式也不一定更慢；差異取決於請求是否被正確分類。若某個測速工具在規則模式下實際直連，所得結果不能代表線路。可以暫時使用全域模式，確認測試流量確實經過線路；完成後恢復日常規則，避免將本地服務與不需要加速的請求全部轉送。

避免將流量狀態誤判為速度問題

月訂閱包含的流量會依開通日每月重設，方案分別為 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB。若面板顯示流量狀態異常，應先核對目前週期，而不是反覆更換線路。流量包為 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完為止且永久不過期。中途升級時，差額會折算為剩餘天數，帳戶顯示可能因此有所變化。

確認帳戶正常後，如果多條線路在不同裝置上都於同一網路時段出現相同卡頓，而更換網路後明顯改善，應優先聯絡目前的網路供應商或檢查本地路由環境；若不同網路下問題一致，且集中於特定地區或線路類型，應向客服提交線路名稱、目標服務、發生情境與對照結果。不要在工單中填入自己推測的「頻寬不足」，可重現的現象比結論更有用。

區分線路中斷、網路切換與應用程式休眠

頻繁斷線可能發生在不同層級。用戶端明確顯示連線已中斷，表示通道本身沒有維持；用戶端仍顯示連線，但應用程式請求停止，可能是系統路由、DNS 或應用程式網路狀態異常；只有裝置鎖定螢幕後斷線，則更接近背景活動限制；從無線網路切換至行動網路時斷線，則屬於底層網路變更後的重新連線問題。先記錄斷線發生時的動作，比記錄「偶爾掉線」更能定位原因。

觀察斷線是否與休眠、鎖定螢幕、網路切換、低電量模式、用戶端切至背景或路由器重新撥號同步。若總是在同一個動作後發生，可以直接檢查對應的系統策略；若沒有固定動作，再比較不同線路與不同網路。不要開啟自動切換線路後再判斷某條線路是否穩定，因為自動策略會隱藏實際切換過程。排查期間應固定一條線路，關閉不必要的自動選擇功能。

行動裝置背景限制的處理方式

iOS 與 Android 都會管理背景網路活動，但具體入口與名稱會隨系統介面而變化。應在系統設定中確認用戶端獲准維持 VPN 設定與必要的背景活動，並檢查低電量或省電策略是否對其施加額外限制。Android 裝置還可能由製造商的電源管理單獨控制背景應用程式；應將用戶端加入允許持續執行的範圍，而不是關閉整個系統的電源管理。

鎖定螢幕後立即斷線，與放置一段時間後斷線，是不同的線索。前者通常與系統策略或網路切換有關，後者也可能來自路由器租約、無線休眠或線路維持失敗。測試時讓裝置保持在同一網路環境，先在前景執行，再鎖定螢幕重新測試，最後切換網路複測。每次測試前重新建立連線並確認網頁可存取，避免將前一次的失敗狀態帶入下一輪。

桌面系統的休眠與網路介面恢復

Windows、macOS 與 Linux 從睡眠狀態恢復時，實體網路介面、DNS 與虛擬介面的恢復順序可能不同。用戶端介面可能仍保留連線標記，但原通道已無法使用。遇到這種狀態，應主動中斷連線並重新連線，而不是直接疊加新的系統代理。若每次休眠後都會重現，應檢查用戶端是否具備隨網路變化重新連線的選項，並確保系統內沒有其他網路工具爭用預設路由。

頻繁在有線、無線與其他網路之間切換時，舊路由可能暫時殘留。完全退出用戶端後重新開啟，通常比連續點擊連線更容易恢復乾淨狀態。若必須重新啟動系統才能恢復，應儲存用戶端記錄，並說明「退出用戶端無效、重新啟動後恢復」這項範圍。這表示問題可能涉及系統網路擴充功能或殘留程序，而不只是某條線路。

何時提交斷線記錄

當斷線可以穩定重現，且已排除鎖定螢幕、省電、網路切換與其他代理工具，應提交工單。說明使用平台、網路類型、線路名稱、斷線前正在進行的操作、用戶端狀態是否變化、重新連線能否恢復，以及其他線路是否相同。記錄應涵蓋斷線前後，但不應公開真實訂閱網址、使用者名稱或驗證內容。

如果問題只發生在行動裝置背景執行時，應附上背景權限與省電策略的文字說明；如果只在休眠恢復後發生，應說明完全退出用戶端是否有效。客服需要的是觸發條件與對照結果，而不是長時間未篩選的全部記錄。範圍越清楚，越容易判斷是系統生命週期、目前網路還是線路連線維持問題。

先確認訂閱失敗發生在哪一步

訂閱問題通常表現為無法取得內容、下載到內容但解析失敗、更新成功卻沒有線路，或線路存在但名稱與分組異常。無法取得內容較接近帳戶、網路或網址失效；解析失敗可能來自用戶端不相容、複製內容不完整或舊快取；更新後為空則需要檢查帳戶狀態與用戶端篩選設定；分組異常則可能是新舊訂閱疊加。先保留錯誤提示，不要立即刪除全部設定。

從使用者面板重新進入訂閱交付入口，確認目前帳戶可用。VPNQD 註冊無需電子郵件地址，使用者名稱與密碼即可註冊，因此排查時應確認登入的是最初使用的使用者名稱，而不是把其他資料當作帳戶識別。取得新訂閱後，應完整替換舊網址，不要手動截取其中一段，也不要將真實網址交給第三方頁面轉換。用戶端與訂閱都應從面板取得，行銷頁面不提供靜態安裝包或公開訂閱網址。

排除複製、快取與重複匯入

訂閱網址中可能包含對複製完整性敏感的字元。透過聊天軟體、富文字編輯器或自動換行的筆記應用程式轉存時，網址可能被截斷、插入空格或改寫符號。最穩妥的方式是直接從面板複製，再貼到用戶端的訂閱輸入框。需要展示格式時只能使用假值：

subscription:
  name: VPNQD-example
  url: https://example.com/sub?token=YOUR_TOKEN
  update: manual

若用戶端已有多個名稱相近的訂閱，應先辨認目前正在使用的設定。重複匯入會造成線路重名、規則來源混雜或更新錯誤項目。可以先停用舊訂閱，再匯入目前訂閱；確認新項目正常後，再刪除確定不再使用的副本。無法確認內容時，不要同時清除用戶端資料與系統網路設定，這會讓訂閱問題擴大為連線問題。

判斷網路取得失敗還是用戶端解析失敗

若用戶端提示無法下載訂閱，先確認一般網頁可以存取，並比較關閉連線與啟用連線時的結果。在某些情況下，舊代理狀態會影響用戶端自身的請求。完全退出用戶端、清理殘留的系統代理後重新開啟，再嘗試更新。若面板在瀏覽器中也無法進入，應先處理目前網路；若瀏覽器能正常進入面板，但用戶端始終無法取得，則應記錄用戶端錯誤並檢查其網路權限。

如果訂閱內容可以取得但解析失敗，不要嘗試手動修改服務端下發的內容。應確認使用的是面板提供的用戶端入口或受支援的匯入方式。不同用戶端對欄位、分組與規則的支援範圍不同，將一種格式強行匯入另一種用戶端，可能得到空白清單。此時應回到面板重新選擇對應平台的取得方式，而不是在本機猜測欄位含義。

更新成功但仍看不到新線路

更新成功後，用戶端可能仍顯示舊的分組快取。先切換至新的訂閱項目，確認目前設定來源，再重新載入設定。若設定了地區、協定或關鍵字篩選，也要檢查是否將所有線路隱藏。VPNQD 提供 120+ 個國家、180+ 條線路，但用戶端介面可能依分組、篩選與目前訂閱狀態顯示不同內容，不應僅憑某個折疊分組判斷訂閱為空。

若重新取得、替換舊網址並取消篩選後仍然無法更新，應提交工單，附上平台、用戶端名稱、完整錯誤內容、面板能否開啟、訂閱是下載失敗還是解析失敗、是否存在舊訂閱，以及使用假值遮蓋後的網址結構。客服不需要使用者傳送真實訂閱內容。若需要重新下發，應只透過使用者面板或工單中的受控流程處理。

先確認是應用程式獨有問題

當瀏覽器與其他應用程式正常，只有某個應用程式無法存取時，不應先更換整個訂閱。先確認該應用程式在關閉連線時的表現，再確認啟用連線後是否發生變化。如果應用程式始終相同，可能沒有被用戶端接管；如果啟用後變得異常，可能命中了錯誤規則，或與目前網路模式不相容；如果應用程式部分功能正常、部分功能失敗，則可能使用了不同網域、獨立網路元件或多條連線路徑。

有些應用程式遵循系統代理，有些應用程式直接建立網路連線，另一些則將內容、登入與更新請求分散到不同網域。僅設定系統代理時，不遵循系統代理的應用程式可能繼續直連；使用虛擬網路模式時，接管範圍通常更廣，但仍會受到分流規則與系統權限影響。排查應圍繞「請求有沒有進入用戶端」展開，而不是只看用戶端是否顯示已連線。

用臨時全域模式驗證接管範圍

如果用戶端支援規則模式與全域模式，可以暫時切換至全域模式進行對照。全域模式下應用程式恢復，表示線路本身大致可用，問題集中在規則命中；全域模式下仍然失敗，則應檢查應用程式協定、線路地區、系統接管方式或應用程式自身狀態。驗證結束後應恢復日常規則，避免讓不需要跨境線路的本地請求持續經過代理。

修改規則前，先查看用戶端連線記錄或規則命中資訊。找到應用程式存取的網域後，判斷它被標記為直連、代理還是攔截。不要只憑應用程式品牌名稱編寫過寬的萬用規則，因為登入、內容分發與更新網域可能屬於不同服務。較穩妥的方式是從失敗請求著手，只調整必要網域，並在每次調整後重新啟動應用程式驗證。

檢查應用程式內部代理與快取

部分桌面應用程式具備獨立代理設定。應用程式內部代理與系統代理同時啟用時，可能形成重複轉送；若應用程式內部仍保留舊的本機位址，也會將請求送往已停止的程序。應先讓應用程式跟隨系統設定進行測試，確認正常後再決定是否需要獨立設定。不要將訂閱網址直接填入應用程式的代理位址欄，訂閱與本機代理連接埠不是同一種資訊。

應用程式在首次啟動時可能快取地區、解析結果或登入工作階段。切換線路後，舊連線仍可能維持原有路徑。應完全退出應用程式並重新開啟，而不是只關閉主視窗。若瀏覽器隱私視窗正常、應用程式仍異常，可以清理該應用程式允許清理的網路快取或重新登入，但不應先刪除全部使用者資料。涉及工作資料或本機專案時，清理前應確認資料同步與備份狀態。

特殊協定與受管理環境

某些即時通訊、遊戲、企業軟體或系統服務使用的連線方式與一般網頁不同，可能不遵循應用層代理。此時應優先使用用戶端推薦的系統接管方式，並確認系統網路擴充功能正常。企業裝置上的安全策略、憑證與網路過濾也可能限制應用程式連線，不應透過刪除管理策略處理；應向裝置管理員確認允許的網路方式。

向客服提交這類問題時，應說明應用程式名稱、失敗的具體功能、瀏覽器是否正常、全域與規則模式的對照、所用線路，以及應用程式完全退出後是否有變化。如果用戶端能顯示規則命中，應附上去識別化後的相關記錄。不要只寫「這個 App 不能用」，因為登入失敗、內容載入失敗、檔案傳輸失敗與即時連線失敗，對應的排查方向並不相同。

不限裝置數不代表裝置環境不會互相干擾

VPNQD 不限同時上線裝置數，因此出現連線問題時，不應先按固定裝置上限處理。但不限裝置數只表示服務端不以固定裝置數限制同時上線，並不代表同一裝置上可以同時執行多個用戶端、多個虛擬介面或重複的系統代理。多個用戶端爭用預設路由時，常見表現包括連線按鈕反覆切換、網頁偶爾可用、DNS 走向不一致，以及休眠恢復後無法重新連線。

每台裝置應保留一個明確的主要用戶端與目前訂閱。需要比較用戶端時，應完全退出原用戶端，再啟動另一個進行測試；不要讓多個用戶端同時接管系統網路。家庭共用情境可參考多裝置 VPN 推薦與裝置數說明，重點是妥善保管帳戶資料、區分各裝置設定，並避免將真實訂閱網址傳到公開群組。

判斷帳戶問題還是單一裝置問題

如果同一帳戶在其他裝置正常，只有一台裝置異常，故障通常集中在該裝置的用戶端、權限、網路介面或本機設定。如果所有裝置同時無法更新訂閱，應先檢查帳戶狀態與目前網路；若不同網路下仍然一致，再提交工單。若只有某個家庭網路下所有裝置異常，而切換至其他網路後恢復，重點應轉向路由器、DNS 與上游網路，而不是逐台重新安裝用戶端。

路由器負責全屋網路時，終端裝置可能同時經過路由器加速與本機用戶端，形成重複路徑。排查時應先選擇一種方式：關閉終端用戶端，驗證路由器路徑；或讓終端繞過路由器上的相關規則，單獨驗證用戶端。全屋方案的取捨可參閱路由器 VPN 方案與適用範圍。未經確認不要同時修改路由器與所有終端，否則無法知道故障發生在哪一層。

提交工單前整理可重現的資料

高品質工單應包含症狀、環境、觸發條件、對照結果與錯誤證據。症狀要寫清楚是無法連線、連線後無法存取、速度波動、訂閱失敗，還是個別應用程式異常；環境包括 Windows、macOS、iOS、Android 或 Linux，以及用戶端名稱；觸發條件包括鎖定螢幕、網路切換、休眠恢復、更新訂閱或切換線路；對照結果則說明其他線路、其他網路與其他裝置是否相同。

錯誤證據可以是完整錯誤文字、去識別化記錄，或包含上下文的截圖。截圖應保留用戶端狀態、線路名稱與錯誤區域，同時遮蓋使用者名稱、密碼、真實訂閱網址及驗證內容。不要裁掉錯誤標題，也不要只提交一張沒有說明的圖片。若問題涉及目標網站或應用程式，應寫出目標名稱、失敗功能與同類服務是否正常，但不要提供不必要的個人資料。

哪些情況應直接聯絡支援

帳戶狀態與面板顯示不一致、所有受支援平台均無法取得訂閱、不同網路下所有線路都無法連線、同一地區多條線路持續出現一致異常，或用戶端回傳無法透過本機設定處理的驗證錯誤時，應直接提交工單。付款與退款問題也應透過受控工單處理。VPNQD 支援支付寶、微信與 USDT，並提供 30 天無理由退款；具體申請方式與訂單狀態應以帳戶及相關條款為準。

若問題來自操作順序不清，可先回到使用教學重新核對註冊、選擇方案、取得訂閱與匯入用戶端的流程。註冊無需電子郵件地址，使用者名稱與密碼即可完成。用戶端下載與訂閱都應從使用者面板取得，不應使用來源不明的安裝包或訂閱轉換頁面。若需要重新取得用戶端，可進入面板下載區域。

完成排查後的收尾

問題解決後，應撤銷僅用於驗證的全域模式、自訂 DNS、臨時規則與除錯記錄，保留最終生效的最小變更。接著重新啟動用戶端並進行一次正常使用驗證，確認系統重新啟動、網路切換或應用程式重新開啟後仍能正常運作。記錄最終原因與處理方式，可以避免下次再次從頭排查。

如果問題暫時消失但原因仍不清楚，應繼續保留觸發條件與對照記錄，不要把偶然恢復寫成已經解決。穩定的結論應能說明故障位於帳戶、訂閱、用戶端、系統權限、網路環境、線路、DNS、分流規則或目標服務中的哪一層。系統化排查的目標不是修改更多設定，而是用更少的變更得到可重複驗證的結果。