系統查閱手冊

VPN 故障排除大全

先判斷故障發生在哪一層,再變更一個變因並重新測試。本頁用於系統化診斷;如果尚未完成首次設定,請先依照快速上手教學完成註冊、方案、用戶端與訂閱匯入流程。

Windows / macOS / iOS / Android / Linux 120+ 國家 / 240+ 條線路 不限台數 14 天無理由退款
範圍 單一應用程式、單一裝置或所有環境
狀態 訂閱、用戶端、線路與系統網路
對照 更換網路、裝置或線路後重新測試
記錄 保留時間、錯誤訊息與重現路徑

DIAGNOSTIC METHOD

先建立可驗證的診斷方法

網路故障最容易被誤判的原因,是多個變因同時被修改。使用者看到連線失敗時,往往會同時重新安裝用戶端、切換線路、調整系統代理、重新整理訂閱並重新啟動裝置。故障可能暫時消失,卻無法確認真正有效的是哪一步;問題再次出現時,只能重複整套操作。更可靠的做法是先記錄目前狀態,再一次只變更一個變因。每次變更後,都使用同一個網站、同一個應用程式或同一條指令重新測試,結果才具備可比性。

開始排查前,應先確認故障範圍。若只在某個應用程式出現,通常優先檢查應用程式本身的代理功能、分流規則與快取;同一裝置上的所有應用程式都異常,應檢查用戶端、系統網路與 DNS;同一網路中的多台裝置同時異常,則較可能與目前的接入網路、路由環境或共用線路有關。判斷範圍不是為了直接下結論,而是決定從哪一層開始,避免在無關位置浪費時間。

保留一個穩定的對照環境

對照環境可以是另一條可用網路、另一台已完成正常設定的裝置,或同一用戶端中的另一條地區線路。它的作用不是取代目前環境,而是協助區分本地問題與線路問題。例如,目前網路下所有線路都無法建立連線,但更換接入網路後恢復,表示應優先檢查原網路的限制、DNS 或閘道狀態;若只有某條線路異常、其他線路正常,則不應立即重新安裝用戶端,而應先更換線路並記錄異常節點名稱。

測試過程中要維持存取目標一致。不要用不同網站的開啟速度直接比較線路,因為網站本身的伺服器位置、快取與資源大小都不同。可以先造訪一個長期穩定的一般網頁,再測試實際需要使用的 AI 工具、串流媒體或工作應用程式。如果一般網頁正常,但特定服務異常,故障範圍已從「整體連線」縮小為「目標服務、地區出口或應用程式規則」。這比籠統描述「網路不好」更容易獲得有效處理。

先看範圍:確認問題是單一應用程式、單一裝置、單一網路,還是所有環境都能重現。
再看狀態:確認方案有效、流量狀態正常、訂閱已更新,並核對用戶端是否確實進入已連線狀態。
建立對照:只更換線路、網路或裝置其中一項條件,其他條件維持不變。
記錄結果:保存錯誤訊息原文、線路名稱、系統平台、問題發生時段與已嘗試的操作。

區分「連線成功」與「服務可用」

用戶端顯示已連線,只能表示本地用戶端與所選線路完成了某種連線程序,並不代表網域解析、系統代理、應用程式分流與目標服務都已正常。反過來,用戶端顯示失敗,也不能只根據一段狀態文字判斷是帳戶、線路還是目前網路的問題。排查時應將鏈路拆分為訂閱讀取、線路選擇、建立連線、DNS 解析、系統轉送、應用程式存取與目標回應等環節,再根據現象判斷中斷位置。

命令列可以提供輔助證據,但不應單獨決定結論。以下範例只會存取公開的示範網域,不含任何真實訂閱網址或憑證。若指令能解析網域並取得回應,而瀏覽器仍無法開啟,應繼續檢查瀏覽器擴充功能、快取、系統代理接管與安全軟體;若網域解析本身失敗,則優先進入 DNS 章節,而不是反覆切換瀏覽器。

基礎連通性與網域解析範例

ping example.com
nslookup example.com
curl -I https://example.com/

最後,排查記錄要使用可複製的文字,而不是只寫「不能用」「很卡」。有效描述應包含發生平台、使用的接入網路、選擇的線路、受影響的應用程式、錯誤訊息原文,以及切換哪些條件後結果發生變化。只要資訊完整,即使問題無法自行解決,也能讓工單直接進入技術判斷,而不必從基礎問題重新詢問。

CONNECTION

完全無法連線與建立連線失敗

「完全無法連線」應先確認具體表現:用戶端是否無法啟動、訂閱清單是否為空、按下連線後立即出錯、長時間停留在連線中,還是顯示連線完成後立刻斷開。不同表現對應不同層級。用戶端無法啟動屬於本地軟體或系統權限問題;沒有可選線路通常與訂閱讀取有關;所有線路都在建立連線階段失敗,則需要對照目前網路、系統時間、用戶端權限與本地安全策略。

先檢查方案與訂閱狀態,再處理用戶端。進入使用者面板確認方案仍處於可用狀態,並重新取得訂閱內容。不要把瀏覽器網址列中儲存的舊頁面、聊天記錄裡的舊文字或其他裝置匯出的設定當成目前訂閱。VPNBi 註冊不需要電子郵件地址,只要使用者名稱和密碼即可註冊,因此排查帳戶時應重點核對目前登入的使用者名稱是否正確,避免在多個瀏覽器環境中誤用其他帳戶的訂閱。

所有線路都無法建立連線

如果線路清單能正常顯示,但任一線路都連線失敗,先退出用戶端並重新開啟,再確認系統日期與時區由系統自動維護。憑證驗證、加密握手與訂閱請求都依賴合理的系統時間;時間明顯偏差時,可能表現為連線失敗、訂閱讀取異常或網頁憑證錯誤。接著檢查用戶端是否取得建立網路連線所需的系統權限。Windows 與 macOS 可能要求確認網路延伸功能或系統授權,行動平台也會顯示建立 VPN 設定檔的系統提示;拒絕後,用戶端通常無法真正接管流量。

接著更換接入網路進行對照。可以從目前的有線或無線網路切換到另一條可使用的網路,但不要同時更換用戶端與線路。若同一裝置、同一用戶端、同一線路在另一個網路下可以連線,表示帳戶與訂閱大致正常,應將重點放在原網路的 DNS、閘道、存取控制或路由器設定。若不同網路下所有線路仍然失敗,再用另一台裝置匯入同一帳戶目前產生的訂閱,判斷是否為單一裝置問題。

本地安全軟體或系統防火牆也可能阻止用戶端建立通道,但排查時不建議長期關閉防護。較穩妥的做法是查看封鎖記錄,確認是否存在與用戶端程序、網路延伸功能或虛擬網路卡相關的封鎖項目,再依軟體提供的方式放行受信任程式。測試完成後只保留必要規則即可。若裝置由單位統一管理,網路延伸功能、代理與憑證設定可能受管理政策控制,此時應聯絡裝置管理員,而不是強行修改受管理的設定。

只有部分線路無法連線

當其他線路可用,只有某個地區或某條線路失敗時,用戶端和帳戶通常不是首要懷疑對象。先記錄異常線路的完整名稱,再在鄰近地區或同一地區的其他線路之間切換。VPNBi 涵蓋 120+ 國家 / 240+ 條線路,選線時可前往節點頁面了解地區與線路類型,再依目標服務所在地區選擇替代線路。問題只集中在單一線路時,不要反覆解除安裝用戶端,這會清除既有記錄與對照條件。

如果異常會隨接入網路改變,例如家用網路下某條線路失敗而其他網路可用,應將接入網路資訊一併寫入工單。若異常與網路無關,且同一線路在不同裝置上都失敗,則更接近線路端問題。使用者無法透過修改本地 DNS 或重設瀏覽器來修復線路端的建立連線失敗,繼續嘗試只會增加變因。此時保留線路名稱、發生時段與錯誤訊息原文,比重複操作更有價值。

訂閱清單為空或匯入後沒有節點

線路清單為空時,不要直接歸類為網路斷線。先確認匯入的是完整訂閱內容,而不是方案頁面網址、登入頁面網址或從瀏覽器複製出的截斷文字。訂閱網址應從使用者面板取得;行銷頁面不會提供靜態訂閱網址。若需要在文件或工單中說明格式,只能使用明顯的假值,例如下方範例,不能提交真實憑證。

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

重新匯入前,應先在用戶端中移除明顯失效的重複設定,避免多個同名設定互相覆蓋。接著從面板複製目前訂閱,使用用戶端提供的「從連結匯入」或同等入口完成更新。如果用戶端能提示訂閱請求失敗,應保存原始提示;如果沒有任何提示但清單仍為空,可嘗試在另一個平台匯入同一訂閱進行對照。不同平台都失敗時,較可能與訂閱狀態或請求鏈路有關;只有單一平台失敗,則優先檢查該用戶端的匯入方式與系統權限。

完成本章排查後,應能將問題歸入本地用戶端、接入網路、訂閱讀取、單一線路或帳戶狀態其中一類。若仍無法分類,不要繼續同時修改多個設定。恢復到最簡單的預設設定,選擇一條容易識別的線路,以一般網頁作為測試目標,並記下從啟動用戶端到出現錯誤的完整路徑。技術支援需要的是可重現的過程,而不是結論式猜測。

WEB AND DNS

已連線但網頁無法開啟與DNS 異常

用戶端顯示已連線但網頁無法開啟,表示故障通常發生在建立連線之後。此時最重要的判斷是:網域無法解析、所有網路請求都無法通過、只有瀏覽器異常,還是只有某個網站異常。先不要連續切換大量線路。維持目前線路不變,分別使用一般網頁、目標服務與命令列測試,觀察故障是否只出現在網域存取、特定應用程式或特定地區內容。

可以先開啟作業系統的網路設定,確認沒有殘留的手動代理位址與目前用戶端衝突。某些瀏覽器擴充功能也會自行設定代理或攔截請求,導致系統流量與瀏覽器流量走不同路徑。若其他應用程式可以存取而瀏覽器無法存取,可暫時停用與網路、隱私過濾或代理相關的擴充功能,並使用瀏覽器的新工作階段測試。這樣做的目的不是永久關閉擴充功能,而是判斷衝突是否位於瀏覽器層。

判斷是否為 DNS 解析失敗

DNS 負責將網域轉換為網路可使用的位址。連線已建立,但解析請求仍送往不可用或衝突的解析器時,使用者會看到網頁長時間等待、提示找不到伺服器,或部分網域能開啟、部分網域無法開啟。執行 nslookup example.com 可以查看系統是否能取得解析結果;若指令直接回報解析失敗,而用戶端狀態正常,應優先檢查 DNS 接管、系統快取與網路介面卡,而不是只清除網頁快取。

先使用用戶端預設的 DNS 策略。許多故障來自同時在系統、路由器、瀏覽器與用戶端中設定不同的解析方式,最終請求去向難以判斷。排查階段應盡量減少自訂項目:還原用戶端預設設定,關閉瀏覽器個別啟用的實驗性解析選項,重新連線後再測試。若還原預設後恢復正常,再逐項加入確有需要的自訂設定,每次只啟用一項,才能找出衝突來源。

系統 DNS 快取可能保留舊結果。Windows 可使用系統提供的 DNS 快取更新指令;macOS、Linux 與行動平台則可透過中斷網路、重新連線或重新啟動網路服務,讓解析狀態重新建立。由於不同系統發行環境的指令與權限要求不同,本頁不將任何高權限指令視為通用方案。執行管理員指令前,應確認指令來源與作用;受單位管理的裝置則應遵循管理員政策。

網域能解析但網頁仍無法載入

如果解析指令能回傳結果,curl -I https://example.com/ 也能收到回應,而瀏覽器仍然失敗,重點轉向瀏覽器快取、擴充功能、憑證檢查與系統代理衝突。可以使用新的瀏覽器工作階段測試,但不要立即刪除所有瀏覽資料,以免遺失工作狀態。若新工作階段正常,再回到原本環境逐項排除擴充功能與網站快取。若命令列與瀏覽器都無法存取,則繼續檢查線路與路由,而不要停留在瀏覽器設定。

若一般網頁正常,只有某個網站無法開啟,應檢查目標服務是否要求特定地區出口、是否限制帳戶所在地區,或服務本身是否在目前時段發生異常。切換到目標內容所在的地區線路後重新測試,並確認應用程式或瀏覽器確實使用目前的連線。對於串流媒體情境,可參考解鎖支援頁面了解地區選擇;對於日本地區內容,可閱讀日本地區線路選擇與實測說明。這些檢查用於定位地區與應用程式差異,不代表所有目標服務都會在所有線路上呈現相同內容。

觀察到的現象 優先檢查 不應先做的操作
網域解析失敗 用戶端 DNS、系統快取、網路介面卡 反覆重新安裝瀏覽器
命令列可存取,瀏覽器失敗 瀏覽器擴充功能、快取、獨立代理設定 同時更換帳戶與方案
一般網頁正常,特定網站失敗 目標地區、應用程式規則、服務本身狀態 直接判斷所有線路都不可用
所有請求都沒有回應 線路、系統路由、接入網路 只清除網站 Cookie

連線中斷後仍然無法上網

如果退出用戶端後一般網路也無法恢復,可能是系統代理、虛擬網路介面卡或路由狀態沒有正常還原。先完全退出用戶端,而不是只關閉視窗;接著檢查系統代理是否仍指向本地用戶端,確認網路介面卡沒有保留手動設定。再中斷並重新連線目前網路,讓系統重新取得閘道與 DNS。不要在不了解用途的情況下刪除系統網路元件,因為這可能影響其他工作軟體。

若重新啟動裝置後恢復,表示問題可能與用戶端異常結束或系統網路狀態殘留有關。應記錄當時是正常退出、系統休眠、強制結束程序,還是網路突然切換。若頻繁出現,更新訂閱並使用用戶端預設網路模式重新測試;如果仍可重現,將退出方式、系統平台與恢復步驟寫入工單。技術支援需要知道「中斷後無法上網」是偶發狀態還是固定流程必現,兩者的處理方向不同。

DNS 問題修復後,應再次測試一般網頁與實際業務應用程式,並確認退出用戶端後本地網路能正常恢復。不要只以某個快取頁面能開啟作為成功依據,因為快取內容可能沒有產生新的網路請求。選擇一個先前未開啟的一般頁面,或使用命令列請求回應標頭,更容易確認解析與連線鏈路確實恢復。

PERFORMANCE

速度緩慢、晚間尖峰卡頓與線路選擇

速度問題必須先區分「持續緩慢」與「特定時段緩慢」。持續緩慢可能來自本地網路、無線訊號、裝置負載、線路距離或目標服務;只在晚間尖峰出現,則需要比較不同時段、不同線路與不同接入網路的表現。不要用單次測速結果概括整體體驗,也不要把目標網站下載緩慢直接等同於線路速度慢。目標伺服器本身、跨區內容傳遞與應用程式限速都可能影響最終速度。

排查前先建立本地基準。中斷用戶端,在同一裝置、同一位置測試一般網路能否穩定存取日常網站,並觀察是否有無線訊號波動、路由器負載或其他裝置大量占用網路。若基礎網路本身就不穩定,任何跨境線路都會疊加這個問題。先修復本地網路,再比較線路,得到的結論才有意義。

依地理距離與目標地區選擇線路

線路不是越遠越好,也不是地區名稱越熱門就越適合。一般瀏覽通常先選擇地理位置較近、路由較直接的地區;存取特定地區內容時,再選擇與目標服務相符的出口。VPNBi 提供 120+ 國家 / 240+ 條線路,可以在節點頁面查看地區與線路類型。選線時先固定目標應用程式,再在少量候選線路之間比較,不要連續隨機切換大量節點,否則很難判斷差異來自線路還是目標服務的動態狀態。

若一條遠距離線路開啟一般網頁很快,但影片緩衝明顯,不一定是基礎連線失敗。串流媒體通常會進行分段請求、畫質自適應與地區驗證,對持續吞吐量與出口地區的要求不同於網頁首屏。應在應用程式內觀察畫質是否穩定,並與同一地區的其他線路對照。若只有某個平台卡頓,其他串流媒體與一般下載正常,應優先判斷目標平台或出口適配,而不是將整個網路定義為速度故障。

晚間尖峰卡頓的對照方式

排查晚間尖峰卡頓時,需要保留時段資訊。遇到卡頓時記錄目前接入網路、線路名稱、目標應用程式與具體表現,例如網頁等待、影片降低畫質、語音延遲或檔案傳輸停頓。接著只切換到同一地區的另一條線路重新測試;若同地區線路都很慢,再換到鄰近地區;若所有跨境線路都很慢,同時本地網路也出現波動,應先檢查接入網路。如此可以逐步區分單線擁塞、地區路徑與本地出口問題。

不要只記錄「測速值低」。測速站點的伺服器位置會影響結果,不同測試目標無法直接橫向比較。更實用的方法是使用實際業務執行固定動作,例如開啟同一份文件、載入同一部公開影片、同步同類型檔案,並記錄是否能穩定完成。為避免快取干擾,可使用未預先載入的內容或應用程式本身的網路狀態提示。排查追求的是可重複的差異,而不是尋找一個看起來漂亮的瞬時數字。

無線網路環境還應檢查訊號品質與頻繁漫遊。裝置在不同存取點之間切換時,底層網路路徑會短暫改變,用戶端可能需要重新建立連線,表現為影片緩衝或語音中斷。測試時盡量保持裝置位置穩定,並關閉會主動切換網路的省電或智慧連網功能進行對照。若有線環境穩定而無線環境異常,重點應放在本地無線網路,而不是遠端線路。

用戶端模式與分流造成的差異

如果用戶端提供全域、規則或系統代理等模式,不同模式的涵蓋範圍可能不同。全域模式便於判斷所有受支援流量是否能經過線路,但日常使用未必需要長期維持;規則模式依賴規則命中,某些新網域或應用程式連線可能不如預期;僅設定系統代理時,不讀取系統代理的應用程式可能直接連線。排查速度時應先確認目前模式,避免把「應用程式沒有經過線路」誤判成「線路速度特別快或特別慢」。

自訂規則過多也會增加判斷難度。建議暫時使用用戶端預設設定,針對實際目標重新測試。若預設設定正常,再逐項恢復自訂規則。每次恢復後都檢查目標網域、應用程式程序與 DNS 處理是否仍符合預期。規則問題通常具有穩定重現的特徵:同一應用程式、同一目標在相同模式下持續異常,而切換模式後立即改變。線路擁塞則較可能隨時段與節點變化。

效能表現 可能層級 建議對照
所有網路活動持續緩慢 本地網路、裝置負載、目前線路 中斷用戶端建立本地基準
僅晚間尖峰明顯卡頓 接入網路或線路的時段差異 記錄時段並比較同一地區的線路
一般網頁快,影片不穩定 持續吞吐量、出口地區、目標平台 與同地區線路及其他平台對照
只有某個應用程式速度慢 應用程式分流、快取或目標服務 檢查模式並測試應用程式網頁版

當速度問題能穩定重現且與單一線路有關時,應提交線路名稱、目標服務、接入網路類型、發生時段與替代線路的表現。若問題只出現在某個應用程式,還要說明該應用程式的網頁版或其他裝置是否正常。這些對照資訊能協助技術支援判斷是線路、出口適配、應用程式規則還是本地環境,而不必從「是否重新啟動過裝置」重新開始。

STABILITY

頻繁斷線與行動裝置背景掉線

頻繁斷線應先區分主動中斷、底層網路切換與用戶端程序遭系統暫停。主動中斷通常伴隨用戶端明確報錯或線路狀態變化;底層網路切換常發生在無線網路與其他接入方式之間切換時;背景暫停則多見於行動平台鎖定螢幕、省電或記憶體回收之後。三種情況表面上都像「突然不能用」,但修復方向完全不同。

先觀察斷線發生的觸發條件。是在鎖定螢幕後、裝置移動時、切換存取點時、啟動特定應用程式時,還是沒有進行任何操作也會發生。若每次鎖定螢幕後都重現,優先檢查背景執行與省電策略;若移動到不同房間或網路涵蓋區域時發生,重點檢查網路漫遊;若只有某條線路斷開、其他線路穩定,則記錄線路名稱並進行線路端對照。

為何行動裝置在背景中容易掉線

iOS 與 Android 都會管理背景活動,以控制電量與資源使用。用戶端退到背景後,系統可能限制其執行、暫停網路活動,或在記憶體不足時結束程序。排查時應確認用戶端允許背景執行,並檢查系統是否將其列入嚴格省電、自動休眠或背景限制清單。設定名稱因系統廠商而異,應以系統設定中的電池、應用程式管理、背景活動與 VPN 設定頁面為準。

不要永久關閉所有省電功能。更合理的做法是只允許需要持續連線的用戶端執行背景活動,然後鎖定螢幕重新測試。若問題消失,表示斷線與背景管理有關;若仍然斷線,再查看底層網路是否在鎖定螢幕時切換或休眠。有些裝置會在螢幕關閉後降低無線活動,重新點亮時才恢復;這類現象與線路故障不同,通常在未連線服務時也能觀察到網路恢復延遲。

行動平台也可能在網路切換後保留舊工作階段。裝置從無線網路切換到其他接入方式時,原連線使用的本地位址與路由已經改變,用戶端需要重新建立鏈路。若用戶端沒有自動恢復,可以回到前景手動中斷後重新連線。若每次網路切換都無法恢復,應記錄切換方向、用戶端前景或背景狀態,以及恢復操作;提交工單時,這些資訊比單純描述「行動端不穩定」更有價值。

桌面端休眠、喚醒與虛擬網路狀態

Windows、macOS 與 Linux 在休眠後可能重新初始化網路介面卡。用戶端介面有時仍保留休眠前的已連線狀態,但底層路由已經改變。喚醒後若網頁無法存取,先觀察一般網路是否已恢復,再在用戶端中執行一次明確的中斷與連線。若一般網路也尚未恢復,應先處理系統網路,而不是立即更換訂閱。

如果每次喚醒都出現問題,可以關閉用戶端的自動連線功能進行對照:先讓系統完成網路恢復,再手動連線。若這樣便穩定,表示自動連線發生得太早,用戶端在系統網路尚未就緒時建立了失效工作階段。若手動連線也失敗,則檢查虛擬網路介面卡、系統代理殘留與安全軟體記錄。不要同時重設所有網路元件,因為這會清除判斷自動連線時序所需的證據。

桌面系統中的大型同步、備份或開發工具也可能改變網路狀態。某些軟體會安裝自己的網路過濾器、虛擬介面卡或代理。若斷線總是在啟動某個工具後發生,可以先退出該工具重新測試,再檢查兩者的網路接管方式是否衝突。單位裝置上的過濾器通常由管理政策安裝,不應自行刪除;應將衝突現象提供給管理員或技術支援。

區分線路中斷與應用程式工作階段中斷

語音、遊戲、遠端桌面或長連線應用程式可能在網路短暫波動後中斷,即使用戶端線路隨後自動恢復,應用程式工作階段也未必會自動重新連線。此時應同時觀察用戶端狀態與應用程式提示。如果用戶端始終顯示連線正常,一般網頁也能存取,只有業務工作階段中斷,重點應放在應用程式重連機制、網路切換與目標服務,而不是直接判斷線路已中斷。

反之,若用戶端明確從已連線變為中斷,所有應用程式同時失去存取能力,則要記錄中斷前後的網路環境與線路。可以選擇同一地區的另一條線路進行較長時間的實際使用對照,但不要在短時間內連續切換。若不同線路都在同一裝置、同一觸發條件下中斷,優先檢查裝置電源與網路管理;若只有一條線路異常,再按線路問題提交。

平台情境 常見觸發條件 排查重點
iOS 鎖定螢幕、網路切換、系統資源回收 VPN 設定檔、背景狀態、切換後重新連線
Android 省電、背景限制、廠商應用程式管理 背景活動權限與電池策略
Windows 休眠喚醒、介面卡重建、安全軟體 一般網路恢復與虛擬介面卡
macOS 睡眠喚醒、網路延伸功能重新載入 系統網路狀態與連線權限
Linux 網路服務重新啟動、路由變化、權限 網路管理服務與用戶端記錄

穩定性問題的最終判斷依賴連續對照,而不是一次恢復。完成設定調整後,應在原本容易觸發問題的情境中再次使用,例如鎖定螢幕、喚醒或切換網路。如果只在改變測試情境後看似恢復,不能代表原問題已解決。重新測試時保留同一條線路與同一個應用程式,讓觸發條件成為唯一變因,才能驗證修復是否有效。

APPLICATION ROUTING

某個 App 未走代理與分流判斷

同一裝置上網頁正常,某個 App 卻無法存取,通常不是整體連線失效,而是應用程式流量沒有進入目前線路、應用程式使用了不同網域或協定、快取了舊地區資訊,或目標服務對帳戶地區有單獨判斷。排查時應先驗證其他應用程式與瀏覽器是否正常,再將範圍縮小到該 App。不要因為單一應用程式異常就重設整個系統網路。

首先確認用戶端目前使用的模式。如果是規則模式,應用程式存取的網域或程序可能沒有命中預期規則;如果只啟用了系統代理,部分不讀取系統代理的應用程式可能直接連線;如果用戶端提供全域模式,可以暫時切換進行對照。全域模式下恢復,表示問題較接近規則或應用程式接管;全域模式下仍然失敗,則繼續檢查目標地區、應用程式快取與服務本身狀態。

用網頁版與其他裝置建立對照

許多服務同時提供網頁版與 App。可以在同一裝置的瀏覽器中開啟該服務,觀察網頁版是否正常。網頁版正常而 App 異常,重點檢查 App 快取、登入狀態、系統網路權限與分流規則;網頁版與 App 都異常,則較可能與出口地區、目標服務或線路有關。若另一台裝置上的同一 App 正常,還應比較兩台裝置的用戶端模式與系統設定,而不是只比較線路名稱。

應用程式可能快取地區、DNS 或登入工作階段。可以先完全退出 App,再重新開啟;必要時在應用程式本身提供的設定中清除快取或重新登入。不要直接刪除所有應用程式資料,尤其是包含離線內容或工作資料的應用程式。若重新登入後地區狀態發生變化,應記錄切換線路與重新登入的先後順序,因為部分服務只會在登入或啟動時判斷地區。

對於 AI 工具,瀏覽器工作階段、帳戶地區與出口線路可能共同影響存取。可以參考AI 工具存取說明,先確認一般網頁連線穩定,再測試目標工具。若使用者搜尋「翻牆軟體」時實際想解決的是某個 AI 服務無法開啟,排查重點仍應放在目標地區、瀏覽器工作階段與應用程式分流,而不是把搜尋詞本身當作技術結論。

檢查應用程式是否繞過系統代理

部分應用程式會使用自己的網路堆疊,不讀取系統代理設定;部分應用程式還會建立獨立的直連、即時通訊或背景連線。此時瀏覽器正常並不能證明 App 一定經過線路。若用戶端提供按應用程式接管、虛擬網路或全域轉送選項,可以使用預設建議設定進行對照。切換前先保存目前設定,測試結束後再決定是否保留,不要把臨時診斷模式直接當作長期設定。

在桌面平台上,可以觀察應用程式啟動前後用戶端記錄是否出現與目標網域相關的請求,但記錄可能包含本地路徑、帳戶識別資訊或存取目標,提交工單前應進行必要遮蓋。不要公開真實訂閱網址、存取權杖或完整身分資訊。技術支援通常需要錯誤訊息、目標網域類型與規則命中情況,不需要使用者公開可直接使用的憑證。

若用戶端規則允許新增自訂網域,排查時不要一次加入大量來源不明的規則。先識別應用程式實際使用的官方網域,再進行最小範圍調整。過寬的規則可能讓無關流量改變路徑,造成新的速度或地區問題。確認規則有效後,還應測試應用程式登入、內容載入與背景更新,避免只驗證首頁能開啟就結束。

串流媒體與地區內容的特殊情況

串流媒體 App 通常同時使用登入網域、內容介面、圖片資源與媒體傳遞網域。首頁能開啟並不代表播放鏈路完整,播放失敗也不一定代表所有請求都未經過線路。應分別記錄登入、瀏覽目錄、開始播放與持續播放在哪個環節失敗。接著選擇符合內容地區的線路,並完全退出 App 後重新啟動,讓應用程式重新建立工作階段。

若瀏覽器版可以播放而 App 版失敗,可以檢查 App 是否保留舊快取、是否使用裝置定位或商店地區資訊。VPNBi 提供網路線路,不會代替使用者修改應用程式商店帳戶或目標服務帳戶資料。排查時應將網路出口與帳戶狀態分開看,避免反覆切換線路卻忽略應用程式本身的地區規則。關於日本動畫情境,可繼續閱讀日本地區線路選擇與常見限制

企業應用程式與受管理裝置

企業辦公應用程式可能透過單位閘道、裝置管理政策或專用憑證建立連線,與個人網路用戶端產生路由競爭。若問題只出現在受管理裝置或單位應用程式中,不應嘗試移除管理設定。可以先確認單位是否允許同時使用其他網路連線,並將應用程式名稱、錯誤提示與開啟用戶端前後的差異提供給管理員。涉及內部系統時,不要將內部網域、檔案或記錄公開提交至一般管道。

如果應用程式在關閉用戶端後正常、開啟後異常,而其他網際網路應用程式都正常,可能存在目標位址被錯誤分流,或內部位址與線路路由重疊。這類問題需要最小化描述:說明是內部資源還是公開服務、是否只在受管理裝置出現、目前用戶端模式為何。技術支援不需要知道內部業務內容,也能根據流量範圍判斷是否需要調整規則。

完成排查後,應恢復到適合日常使用的用戶端模式,並再次驗證其他應用程式。臨時全域接管可能解決目標 App,卻讓本地服務或其他工作軟體走上不必要的線路。最終設定應同時滿足目標應用程式可用、本地網路正常,以及退出用戶端後網路能恢復。若只能在臨時模式下使用,應將模式差異寫入工單,由技術支援進一步判斷規則涵蓋範圍。

SUBSCRIPTION AND ACCOUNT

訂閱更新失敗、流量狀態與裝置連線

訂閱更新失敗與線路連線失敗是兩類問題。前者發生在用戶端取得設定的階段,常見表現是更新請求報錯、線路清單長期不變、匯入後為空或讀取到舊設定;後者則發生在已有線路建立連線時。先查看用戶端是否能顯示目前線路清單,再決定進入訂閱讀取或連線章節。混淆兩者會導致使用者反覆切換線路,卻沒有真正更新設定。

訂閱必須從使用者面板取得,不能使用行銷頁面網址、方案頁面網址或他人轉發的設定。VPNBi 不需要電子郵件地址,只要使用者名稱和密碼即可註冊,因此應妥善保存使用者名稱,並確認瀏覽器目前登入的是正確帳戶。若同時存在多個帳戶或瀏覽器設定,可先退出面板再重新登入,核對方案與訂閱狀態後複製目前連結。

訂閱無法更新時的處理順序

先確認一般網頁可以存取使用者面板。面板本身無法開啟時,應先解決目前網路或 DNS 問題;面板可開啟但用戶端更新失敗,則檢查複製內容是否完整、用戶端匯入方式是否正確,以及系統是否允許用戶端連線。手動複製時要避免包含前後空格、換行或聊天軟體加入的格式字元。最穩妥的方式是直接使用用戶端的連結匯入入口,而不是把網址改寫進來源不明的設定範本。

如果用戶端同時保留多個同名訂閱,更新操作可能會套用到舊項目。可以先辨識每個項目的來源與更新時間,刪除明確失效的重複項目,再重新匯入。刪除前應確認不會影響其他工作設定。重新匯入後,觀察線路名稱或清單是否變化,而不是只看「更新成功」的短暫提示。提示成功但內容沒有變化時,應關閉用戶端並重新開啟,以排除介面快取。

同一訂閱在一台裝置更新失敗、另一台裝置正常,表示帳戶與訂閱大致可用,應重點檢查故障裝置上的用戶端、系統時間、DNS 與網路權限。不同裝置、不同網路都失敗時,應記錄面板是否可存取、用戶端錯誤訊息原文與訂閱請求發生的時段,再提交工單。不要將真實訂閱網址貼到公開截圖或文章中;工單如需說明,可以遮蓋權杖部分。

月訂閱與流量重置的判斷

VPNBi 月訂閱包括 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB,流量依開通日每月重置,中途升級差額折算為剩餘天數。發現用戶端突然無法連線時,應進入面板核對方案是否有效、當期流量是否已用完,以及是否剛完成升級。不要以每月一日作為統一重置判斷,因為實際規則是依開通日每月重置。

若需要不按月重置的使用方式,流量包為 ¥158/300GB、¥358/1000GB、¥658/3000GB,用完為止,永久不過期。月訂閱與流量包的使用狀態應以面板顯示為準。排查時不要自行將價格、剩餘流量或週期換算成其他口徑,也不要根據用戶端快取推斷帳戶狀態。用戶端顯示的是設定與本地統計,最終方案狀態應回到面板核對。

升級後出現狀態不同步時,可以先退出用戶端、重新整理面板並重新取得訂閱。由於中途升級差額折算為剩餘天數,升級後的週期表現應以面板結果為準,不應根據原方案自行推算。若面板與用戶端顯示明顯不一致,保留兩個介面的截圖,但應遮蓋使用者名稱、訂閱權杖與付款識別資訊,然後在工單中說明升級前後所見的狀態。

不限台數不等於所有連線永遠維持相同狀態

VPNBi 支援不限台數,但不同裝置仍各自受到本地網路、系統背景管理、用戶端設定與線路狀態影響。一台裝置正常不能證明另一台裝置設定無誤,多台裝置同時異常也不一定是裝置數量超限。看到類似裝置限制提示時,先確認提示來自 VPNBi 面板、用戶端還是目標應用程式,因為目標網站與應用程式可能有自己的裝置管理規則,這不屬於本服務的裝置數量口徑。

若所有裝置在同一時間失效,應先檢查帳戶方案與流量,再比較不同網路。若只有新裝置無法使用,重點檢查訂閱是否完整匯入、系統權限是否已確認,以及用戶端是否支援目前平台。VPNBi 支援 Windows / macOS / iOS / Android / Linux;用戶端與訂閱取得入口位於使用者面板,靜態行銷頁面不提供安裝套件直連。需要重新取得用戶端時,應前往使用者面板下載頁

狀態 核對位置 下一步
線路清單為空 訂閱來源、匯入方式、用戶端提示 從面板重新取得並匯入
線路存在但全部失敗 方案、流量、接入網路、系統權限 建立跨網路與跨裝置對照
只有一台裝置異常 該裝置的用戶端與系統設定 維持帳戶不變,檢查本地環境
升級後顯示不一致 面板方案狀態與目前訂閱 重新整理面板並重新取得訂閱

涉及付款狀態時,VPNBi 支援支付寶 / 微信 / USDT。若付款已完成但面板狀態尚未更新,不要重複提交相同操作,也不要公開交易憑證。進入工單頁面說明付款方式、操作時段與面板目前狀態,並依工單要求提供經過遮蓋的必要證明。服務提供 14 天無理由退款,具體處理應以站內條款與工單流程為準。

SUPPORT HANDOFF

何時聯絡客服與工單資訊整理

自行排查的目標不是解決所有問題,而是將故障範圍縮小到技術支援可以直接處理的程度。遇到單一線路在不同網路、不同裝置上都無法連線,訂閱在多個平台均無法更新,面板狀態與用戶端持續不一致,或在相同觸發條件下反覆斷線時,應停止重複安裝並提交工單。繼續修改大量設定可能覆蓋記錄、破壞重現條件,反而延長判斷時間。

工單入口位於使用者面板。提交前先說明問題發生在哪個平台、使用什麼接入網路、選擇哪條線路,目標是一般網頁、串流媒體、AI 工具還是其他應用程式。還要說明問題是始終發生、只在特定時段出現,還是由鎖定螢幕、喚醒、網路切換或啟動某個應用程式觸發。技術支援依此才能選擇正確的重新測試條件。

必須包含的基本資訊

系統平台應寫為 Windows、macOS、iOS、Android 或 Linux,並說明是單一裝置還是多台裝置重現。用戶端名稱與介面中的錯誤訊息原文應盡量完整複製,不要只改寫成「連線失敗」。線路問題要附上線路完整名稱;訂閱問題要說明線路清單是否為空、面板能否存取,以及重新匯入後的結果;網頁問題要說明一般網頁與目標網站是否都受到影響。

接入網路資訊只需說明網路類型與對照結果,不需要提交住家地址、單位名稱或其他無關隱私。例如可以寫「目前無線網路失敗,切換到另一條可用網路後恢復」,這已足以提示接入網路差異。若單位裝置受管理,應直接說明存在裝置管理政策,不要嘗試匯出內部憑證、內部網域或管理檔案。

時間資訊應包含問題發生時段與是否持續,不需要憑記憶提供虛假的精確數值。線路狀態可能隨網路路徑與時段變化,知道「只在晚間尖峰出現」或「任何時段都能重現」,比一張脫離上下文的測速截圖更有價值。若問題已經恢復,也應說明採取哪項操作後恢復,以便判斷是暫時的線路變化還是本地狀態重設。

截圖、記錄與隱私處理

截圖應涵蓋錯誤區域、線路名稱與用戶端狀態,但提交前要遮蓋使用者名稱、訂閱網址、權杖、付款識別資訊、私人訊息與和故障無關的檔案路徑。訂閱網址等同於存取憑證,不應出現在公開圖片、社群貼文或部落格留言中。工單如需進一步記錄,應依客服要求提供最小必要範圍,而不是直接上傳整個系統記錄目錄。

用戶端記錄可能包含存取網域、網路介面、設定名稱與本地路徑。先擷取問題發生前後的相關片段,刪除與問題無關的內容,並確認不含真實憑證。不要自行修改錯誤訊息,也不要只提供經壓縮後無法閱讀的圖片。可以同時附上可複製的文字,讓技術支援能搜尋錯誤關鍵字。

付款問題只透過使用者面板工單處理。VPNBi 支援支付寶 / 微信 / USDT,但工單通常不需要完整公開付款憑證。應先說明付款方式、面板狀態與操作時段,再依回覆補充必要證明。不要在一般網頁表單或公開頁面貼上敏感交易資訊。

可直接複製的工單格式

以下範本使用描述性欄位,不含任何真實帳戶資訊。填寫時應刪除不適用項目,並以真實現象取代說明文字。不要將範例中的佔位文字原樣提交,也不要附上真實訂閱連結。

問題類型:連線 / 網頁 / 速度 / 斷線 / 訂閱 / 應用程式分流
系統平台:填寫實際平台
問題線路:填寫用戶端中的完整線路名稱
接入網路:填寫網路類型與對照結果
影響範圍:單一應用程式 / 單一裝置 / 多台裝置
錯誤訊息原文:複製用戶端或系統提示
重現條件:說明何時、執行什麼操作後出現
已嘗試操作:依實際順序列出,每次只寫一個變因
對照結果:更換線路、網路或裝置後的變化
附件說明:已遮蓋憑證的截圖或必要記錄片段

哪些情況應優先處理本地環境

如果同一帳戶在其他裝置正常,只有一台裝置異常,應先處理該裝置的用戶端、系統權限、代理殘留與 DNS。若同一裝置在另一個網路下正常,則優先檢查原接入網路。若一般網頁和其他應用程式正常,只有某個 App 異常,則先檢查應用程式分流、快取與地區狀態。這些對照已明確指向本地或應用程式層,直接要求更換帳戶通常無法解決問題。

相反地,如果多台裝置、多個網路都在同一條線路上失敗,而其他線路正常,應將資訊交給技術支援;如果訂閱在多個平台都讀取失敗,但面板方案狀態正常,也應提交工單。判斷關鍵不是問題「看起來嚴重」,而是是否已跨越裝置與網路邊界穩定重現。跨環境重現越明確,線路或帳戶端的可能性越高。

問題解決後的收尾檢查

故障恢復後,不要立即刪除所有記錄。先確認一般網頁、實際目標應用程式與退出用戶端後的本地網路都正常,再保留最終有效設定。若排查期間啟用了全域模式、關閉了某個擴充功能或調整了省電策略,應逐項恢復非必要變更,並在每次恢復後重新測試。如此可以避免「修好一個問題,卻同時留下另一個隱患」。

建議保留一份簡短的個人環境記錄,包括常用平台、有效的用戶端模式、常用地區線路、行動裝置背景設定與曾出現衝突的軟體。記錄不應包含訂閱網址或密碼。下次遇到類似現象時,可以直接從已知穩定狀態開始對照,不必重複整套嘗試。對於需要長期維護隱私設定的使用者,可閱讀無日誌 VPN 核查清單,了解條款、註冊資訊與公共網路使用習慣。

VPNBi 技術支援入口

工單中附上平台、線路、網路類型、錯誤訊息原文、重現條件與對照結果。不需要公開真實訂閱網址,也不要提交與故障無關的私人資訊。

進入工單