先建立可重現的排查基準
先描述症狀,不要急著描述原因
有效的排查從現象開始。把「服務壞了」改寫成可驗證的句子,例如:用戶端無法完成連線;用戶端顯示已連線,但瀏覽器無法開啟任何網站;只有某個 App 無法存取;一般時段可用,尖峰時段明顯卡頓;切換到行動網路後恢復,但目前的 Wi-Fi 仍然失敗。這類描述能直接決定下一步要檢查哪一層。相反地,「節點不行」「協定有問題」已經先帶入結論,容易讓後續操作朝錯誤方向進行。
記錄現象時,請保留四類脈絡:使用的平台、目前的網路入口、選擇的地區或線路類型,以及失敗發生在哪個動作。平台填寫 Windows、macOS、iOS、Android 或 Linux;網路入口只需區分家用寬頻、辦公室網路、公共 Wi-Fi 或行動網路;線路填寫用戶端顯示的完整名稱;動作填寫連線、開啟網頁、播放內容、更新訂閱或恢復背景運作。錯誤彈窗不要憑記憶轉述,請直接複製原文或截圖,因為「驗證失敗」「解析失敗」「連線逾時」對應的檢查層級完全不同。
建立最小對照組
最小對照組的目的不是立即恢復,而是判斷問題會隨著什麼變化。先保持同一台裝置與同一個用戶端不變,只把目前網路切換到另一個可用入口。如果症狀隨網路改變,優先檢查本機網路、路由器或網路供應商;如果兩個入口都失敗,再切換到另一個地區的線路。如果只有單一線路異常,問題範圍已縮小到線路;如果所有線路都失敗,再檢查帳戶狀態、訂閱內容與用戶端設定。
接著使用同一網路、同一訂閱,在另一個支援的平台上進行對照。另一台裝置可以連線,表示帳戶與線路大致仍可用,應回到原裝置檢查用戶端權限、系統代理、DNS、背景限制與舊設定殘留。另一台裝置也失敗,則不要繼續反覆安裝,先登入使用者面板確認訂閱狀態,並重新取得目前的訂閱。VPNRZ 支援 Windows / macOS / iOS / Android / Linux,同時連線不限裝置數,因此正常的多裝置對照不會因本服務的裝置數量限制而失去意義。
一次只改變一個變數
排查中最常見的誤區,是為了節省時間而同時修改多個項目。例如先清除設定,再切換協定,接著重新啟動路由器;即使最後恢復,也無法知道真正的故障點,下次仍要從頭開始。更穩妥的方式是建立簡短記錄:目前線路、目前協定、目前網路入口、目前結果。每次只修改其中一項,等連線狀態穩定後,再測試同一個目標。如果變更無效,先恢復原值,再進入下一項。
測試目標也要固定。先選一個平時穩定、無需登入的一般網頁,再選實際出問題的服務。一般網頁與目標服務都失敗,檢查連線、路由或 DNS;一般網頁正常而目標服務失敗,檢查出口地區、App 分流、目標服務本身的狀態或帳戶區域。不要一開始就把複雜 App 當作唯一判斷標準,因為 App 可能有獨立快取、私有 DNS、內建代理或區域策略,容易把線路問題與 App 問題混在一起。
完成本章後,應能把問題歸入一個明確入口:完全無法連線、顯示已連線但沒有網頁、速度或尖峰時段異常、頻繁斷線、訂閱更新失敗、特定 App 不使用代理、行動裝置背景斷線、DNS 異常,或帳戶狀態不一致。後續章節都沿用同一原則:先判斷層級,再執行動作,最後使用原始測試目標重新驗證。
用戶端完全無法連線時如何判斷
先區分「尚未設定」與「設定後失敗」
用戶端中沒有任何線路,或線路清單為空,通常不是連線協定本身的問題,而是尚未匯入訂閱、匯入內容已失效,或用戶端沒有讀取到設定。此時不要連續點擊連線按鈕,應先進入使用者面板重新取得訂閱,再依用戶端支援的方式匯入。訂閱內容屬於帳戶交付資訊,不要把完整網址貼到公開討論區,也不要用搜尋引擎開啟。如果只是第一次設定不熟悉,回到快速上手教學依平台完成匯入,比在空白設定狀態下排查連線更直接。
線路已顯示,但點擊後很快回到未連線狀態時,需要查看用戶端日誌或錯誤彈窗。驗證類錯誤優先檢查訂閱是否由目前帳戶產生、複製時是否遺漏字元、是否仍選用了舊設定;逾時類錯誤優先切換網路入口與線路;系統權限類錯誤則檢查用戶端是否取得建立網路連線所需的系統授權。不要看到「逾時」就認定帳戶失效,也不要看到「驗證」就反覆重新啟動路由器,錯誤類別本身已指出較接近的層級。
依帳戶、線路、網路、系統順序檢查
先登入面板確認帳戶可以正常進入,並檢查目前訂閱是否仍處於可使用狀態。月訂閱流量會依開通日每月重置;如果流量已用完,連線行為可能與正常狀態不同。流量包則是用完為止、永久不過期。核對狀態後重新取得訂閱,並讓用戶端更新設定。註冊無需電子郵件地址,使用者名稱加密碼即可註冊;但排障時必須確認目前登入的是原帳戶,而不是誤用了另一個使用者名稱所儲存的空帳戶。
帳戶正常後,切換到另一條地區線路。VPNRZ 覆蓋 100+ 個國家 / 220+ 條線路,不同線路會經過不同入口與中繼,單條線路失敗不能直接推論所有線路都不可用。先選擇與目前位置距離較近的地區,再嘗試另一種線路類型。線路清單與類型說明可在全球節點頁面查看。切換時等待前一次連線完全中斷,再建立新連線,避免舊工作階段尚未釋放而造成狀態顯示混亂。
多條線路都逾時後,再切換網路入口。家用寬頻失敗而行動網路正常,表示用戶端與訂閱本身具備連線能力,重點應轉向路由器、區域網路 DNS、辦公室網路策略或目前的接入環境。辦公室與公共網路可能限制部分連線方式,在這類環境中不應修改不屬於自己的網路設備;可以保留日誌,改用可管理的網路繼續確認。如果所有網路入口都失敗,再檢查系統時間是否自動同步、系統網路權限是否關閉,以及安全軟體是否剛調整網路規則。
清除舊工作階段,不要盲目重裝
用戶端偶爾會保留未正常結束的虛擬網路工作階段。先在用戶端內主動中斷連線,完全退出程式,再重新開啟。如果系統仍顯示代理或虛擬網路處於啟用狀態,可在系統網路設定中關閉對應項目,然後重新啟動用戶端。只有確認設定已備份、訂閱可以重新取得後,才考慮刪除舊設定或重新安裝。直接解除安裝可能同時刪除日誌與現場資訊,讓原本清楚的錯誤變成無法重現的偶發問題。
重新安裝後仍然完全無法連線,應避免繼續反覆重裝。此時更有價值的是交叉驗證:同一帳戶換另一台裝置、同一裝置換另一種網路、同一網路換另一條線路。三組結果可以把範圍縮小到裝置、網路或服務端線路。如果所有支援的平台、多個網路入口與多條線路在同一時間都失敗,將這些對照結果提交工單,比只寫「無法連線」更容易得到準確處理。
| 觀察到的狀態 | 優先檢查 | 不應先做的動作 |
|---|---|---|
| 線路清單為空 | 取得與匯入訂閱 | 反覆切換協定 |
| 提示驗證失敗 | 目前帳戶、訂閱內容、舊設定 | 連續重新啟動路由器 |
| 連線持續逾時 | 線路與網路入口對照 | 同時修改所有設定 |
| 系統拒絕建立連線 | 網路權限與安全規則 | 刪除所有現場日誌 |
如果錯誤只在特定網路出現,記錄網路類型與可重現的時間;如果只在特定線路出現,記錄線路完整名稱;如果只在某個平台出現,記錄系統與用戶端名稱。不要自行猜測服務端原因。排查的目標是把「完全無法連線」拆成可驗證的分支,確認失敗發生在設定產生、用戶端讀取、線路握手、本機網路還是系統權限。
顯示已連線卻無法開啟網頁與 DNS異常
「已連線」只代表通道已建立
用戶端顯示已連線,表示本機用戶端與所選線路已完成連線流程,但不代表網域解析、系統路由與目標服務一定正常。此時不要繼續把注意力放在連線按鈕上,而要分別測試網域、網路出口與 App。先開啟一個無需登入的一般網站;如果所有網站都失敗,再測試能否透過命令列取得回應標頭。一般網站全部失敗時,常見範圍包括 DNS 沒有回傳結果、系統流量沒有進入通道、舊代理設定仍在接管,或本機網路在連線後沒有正確更新路由。
如果只有網域無法開啟,而直接存取已知網路位址可以得到回應,問題較接近 DNS;如果網域可以解析,但請求一直等待,則較接近路由、線路或目標端回應。一般使用者不必憑感覺區分,可以使用系統內建工具查看。範例網域僅用於測試,不含任何真實訂閱資訊:
nslookup example.com
curl -I https://example.com
nslookup 能回傳解析結果,而 curl 無法建立請求,表示解析環節至少有回應,應繼續檢查系統代理、路由與線路。解析命令本身也失敗,則先清除系統 DNS 快取,再中斷並重新連線用戶端。執行命令時保留完整輸出,不要只截取最後一行,因為前面的伺服器來源、逾時描述與錯誤類型都可能有用。
清除快取前先確認影響範圍
瀏覽器無法開啟網頁,但其他 App 正常時,優先使用瀏覽器的私密視窗測試,並暫時停用瀏覽器內個別設定的代理擴充功能。瀏覽器可能快取了舊 DNS、憑證狀態或代理規則,這種情況不應立刻修改整個系統。相反地,如果瀏覽器、命令列與其他 App 都失敗,才需要檢查系統層級的 DNS 與代理。先中斷用戶端,確認本機網路在未連線時能正常存取一般網站;如果本機網路本身就異常,應先恢復基礎網路,再繼續排查加速連線。
不同系統清除 DNS 快取的方式不同。以下命令都是系統常用操作,執行後需要重新連線,再次測試同一個網域。Linux 的具體服務取決於目前的發行版與網路管理方式;命令無法使用時,應查看系統實際啟用的解析服務,而不是從網路複製不相符的設定檔。
| 平台 | 常用檢查或清除方式 | 之後的重新驗證動作 |
|---|---|---|
| Windows | ipconfig /flushdns |
重新連線後再次解析同一網域 |
| macOS | sudo dscacheutil -flushcache |
退出瀏覽器並重新開啟 |
| Linux | resolvectl flush-caches |
檢查目前解析服務是否回應 |
| iOS / Android | 中斷連線並重新建立網路工作階段 | 分別使用瀏覽器與目標 App 測試 |
檢查系統代理與 App 自己的解析路徑
系統代理與虛擬網路模式可能同時存在。如果曾手動填寫代理位址,後來改用用戶端的全域連線模式,舊位址仍可能攔截瀏覽器請求。進入系統網路設定,確認目前代理狀態與用戶端工作方式一致。不要隨意刪除企業管理設定或不熟悉的系統設定;如果裝置受組織管理,應先詢問管理員。個人裝置則可以記錄原值後暫時關閉手動代理,再重新連線用戶端驗證。
部分瀏覽器與 App 會啟用自己的安全 DNS 或私有解析功能,因此系統命令正常,不代表 App 一定使用相同的解析路徑。如果只有某個瀏覽器失敗,請在該瀏覽器設定中檢查是否指定了獨立 DNS;如果只有某個 App 失敗,請進入後文的 App 分流章節。排查時不要逐一亂試多個 DNS 位址。頻繁更換會讓快取、系統設定與用戶端設定同時變化,最後很難判斷是哪一項產生作用。
還有一種常見現象:一般網站可以開啟,但需要特定地區出口的服務提示區域不符。這個結果不屬於 DNS 故障,應確認目前選擇的線路地區,並重新啟動目標 App 以清除舊工作階段。目標服務可能根據帳戶區域、快取、出口地區或自身策略判斷內容範圍,不能只憑一個提示推斷線路完全不可用。先用同一條線路測試一般網頁,再換另一條符合情境的地區線路進行對照。
如果清除快取、關閉舊代理、切換線路與網路入口後,所有網域仍然無法解析,應將解析命令的完整輸出、目前平台、線路名稱與網路類型提交工單。如果只有目標服務異常,則附上一般網頁正常的對照結果。這些資訊可以明確告訴支援人員:通道已建立,問題位於解析、路由或目標服務層,而不是再次從帳戶登入開始重複詢問。
速度慢與尖峰時段卡頓的分層判斷
先區分吞吐量、回應速度與 App 緩衝
使用者口中的「慢」可能指三種不同現象:網頁第一次開啟等待很久、檔案傳輸持續速度低、影片或會議間歇性緩衝。網頁首次開啟較受解析與回應路徑影響;持續傳輸較受本機頻寬、線路壅塞與目標端限制影響;影片與會議則還會受到抖動、封包遺失與 App 自適應策略影響。排查前先說清楚是哪一種,不要只提交一張速度截圖。截圖只能反映某個測試目標在某次工作階段的結果,無法單獨解釋實際 App 為何卡頓。
先中斷用戶端,確認本機網路本身沒有明顯異常。基礎網路已經壅塞時,任何跨境線路都只能在現有條件下運作。接著保持裝置、網路與測試目標不變,連線到距離較近的線路,重複實際情境。不要同時開啟雲端硬碟同步、系統更新與大型檔案傳輸;這些背景工作會競用本機上傳與下載頻寬。排查會議問題時尤其要檢查上傳方向,因為畫面傳送受阻時,對方看到的卡頓可能比本機更明顯。
線路選擇要符合目標,不要只看地區名稱
存取位於亞洲的目標時,先從鄰近地區開始;存取歐美服務時,應結合目標服務所在區域與實際表現進行選擇。較近的地理距離通常代表較短路徑,但跨境鏈路還會受到入口、電信商互聯與中繼方式影響,因此不能把地圖距離當作唯一結論。VPNRZ 提供 IEPL 專線、中轉與直連等線路類型,適用情境與路徑結構各不相同。可以在全球節點查看線路說明,再用固定目標進行單一變數對照。
IEPL 專線適合更重視跨境路徑穩定性的情境;中轉線路透過額外入口安排跨境路徑;直連線路路徑更直接,但實際表現仍取決於本機網路與目標端。這些名稱描述的是線路組織方式,不代表對任何地點、任何時段都作出相同結果承諾。最可靠的選擇方法仍是:保持同一裝置、同一網路、同一目標,依序測試可選類型,並記錄實際 App 表現。
| 線路類型 | 排查價值 | 適合觀察的現象 | 切換後如何重新驗證 |
|---|---|---|---|
| IEPL 專線 | 與一般跨境路徑進行對照 | 尖峰時段穩定性、會議連續性 | 沿用原本的 App 與網路 |
| 中轉 | 避開目前入口的路徑差異 | 特定電信商入口的表現 | 只變更線路,不修改協定 |
| 直連 | 檢查較直接的路徑是否可用 | 一般瀏覽與目標網站回應 | 記錄首次開啟與持續傳輸表現 |
尖峰時段問題要用時間對照確認
如果一般時段正常,但尖峰時段反覆變慢,先判斷壅塞發生在本地接入還是跨境路徑。保持同一裝置與同一線路,在另一個網路入口重新驗證;如果另一個入口明顯正常,優先檢查原本的網路接入。如果不同入口都在相近時段出現類似現象,再切換線路類型或地區。不要直接比較相隔很久、目標不同的測試結果,因為目標服務負載與本機背景工作也可能改變。
尖峰時段卡頓時,連續切換大量線路通常會讓判斷更混亂。先選目前線路作為基準,再選一條鄰近地區線路與一條不同類型的線路,分別完成完整的實際任務。影片情境至少觀察開始播放、拖曳進度與持續播放;會議情境觀察語音連續性、畫面恢復與重新連線情況;AI 工具情境觀察頁面載入、提交請求與持續輸出回應。只要明確哪個階段異常,就能進一步區分解析、等待首個封包、持續傳輸與工作階段維持。
把協定切換放在線路與網路之後
協定會影響握手方式、傳輸特徵與對網路環境的適應性,但它不是所有速度問題的第一答案。先確認帳戶、基礎網路與線路可用,再嘗試用戶端提供的其他相容協定。切換協定前記錄原值,切換後只測試同一個目標。如果協定變更只改善連線成功率,沒有改善持續傳輸,就應繼續檢查線路與本機頻寬;如果只有某種網路入口對協定敏感,則一併記錄網路類型與錯誤日誌。
不要為了追求單次峰值而忽略穩定性。跨境存取更需要持續完成任務:網頁能否穩定載入、會議是否頻繁重新連線、串流影音是否反覆降低畫質、AI 回應是否中途停止。可參考部落格中的連線成功率與斷線率排查方法,用重複任務而不是單次峰值判斷線路。若需要比較年度選擇面向,可查看速度、穩定性與售後服務橫向比較。
當多條線路只對單一目標服務變慢,而一般網頁與其他 App 正常時,應考慮目標端狀態、帳戶區域與 App 快取;當所有目標都變慢,則檢查基礎網路與線路;當只有尖峰時段異常,則用不同網路入口與線路類型拆分壅塞位置。效能排查的核心不是找到一個最高數字,而是找出哪一段鏈路會隨條件改變,並選擇在目前網路與任務下更穩定的組合。
頻繁斷線與行動裝置背景斷線
先判斷是誰主動結束了工作階段
頻繁斷線可能來自本機網路短暫切換、系統回收背景工作、用戶端自行重新連線、線路工作階段逾時,或裝置從 Wi-Fi 切換到行動網路。觀察斷線前後的系統狀態,比立刻重新安裝更有用。如果每次鎖定螢幕後都出現,重點檢查背景執行與省電策略;如果走動時從一個網路切換到另一個網路後出現,重點檢查網路切換後的重新連線;如果裝置閒置、網路穩定時仍週期性中斷,才進一步比較線路與協定。
先確認基礎網路是否也同時中斷。斷線發生時,觀察 Wi-Fi 圖示是否消失、其他裝置是否也短暫無法存取、路由器是否重新撥號。如果整個區域網路同時異常,應先處理基礎網路。只有用戶端連線中斷而一般網路仍正常時,才進入線路、協定與背景權限排查。把兩類問題混在一起,會導致支援人員反覆檢查不存在的線路故障。
行動裝置要檢查背景策略與網路切換
行動作業系統會根據省電狀態、背景活動權限與網路品質管理 App。如果鎖定螢幕後連線消失,請檢查用戶端是否允許背景執行、系統是否對其啟用嚴格的省電限制,以及虛擬網路連線是否仍獲授權。調整後不要立即下結論,應重新連線、鎖定螢幕,再回到前景,用同一個網站或 App 重新驗證。如果只有長時間閒置後斷線,可記錄進入背景前後的用戶端狀態與系統提示。
從 Wi-Fi 切換到行動網路時,原有連線路徑已經改變,用戶端通常需要重新建立工作階段。如果切換後一直停留在「連線中」,先主動中斷,再重新連線;不要連續點擊開關。反過來,從行動網路回到 Wi-Fi 也要進行相同檢查。某些公共 Wi-Fi 需要先完成網頁驗證,如果基礎網路尚未真正連上網路,用戶端無法在其上建立穩定連線。先中斷用戶端完成網路驗證,再重新連線。
如果行動裝置只有某個 App 回到前景後無法存取,而瀏覽器正常,問題更可能在 App 工作階段快取或分流規則。完全關閉目標 App 後重新開啟,觀察是否恢復;如果恢復,表示線路並未整體中斷。如果所有 App 都失敗,再查看用戶端是否仍顯示已連線、系統是否保留虛擬網路圖示,以及 DNS 是否重新分配。不要把 App 本身的登入過期誤判為線路斷線。
桌面端要排除休眠、網卡與舊代理
Windows、macOS 與 Linux 在睡眠與喚醒後,網卡狀態、路由表與 DNS 可能發生變化。如果問題只在喚醒後出現,先中斷用戶端,等待基礎網路恢復,再重新連線。不要在基礎網路尚未取得位址時連續發起連線。外接網卡、擴充底座或 Wi-Fi 切換也可能讓原有工作階段失效,排查時應記錄是否剛發生休眠、網卡切換或網路入口變更。
桌面端若在裝置持續運作時反覆斷線,開啟用戶端日誌,查看每次中斷前是否出現相同錯誤。錯誤一致且只發生在某條線路,換同一地區的另一條線路進行對照;不同線路都在同一網路下斷開,再切換網路入口;只有某台裝置斷開,則檢查本機安全軟體、網路驅動程式與系統代理。不要一開始就升級所有元件或修改驅動程式,高影響操作應放在完成對照之後。
用穩定任務驗證,不要只看狀態燈
用戶端狀態燈保持連線,不代表 App 工作階段沒有中斷;狀態燈短暫重新連線,也不一定會影響具備恢復能力的 App。驗證應以任務為中心。瀏覽情境持續開啟相同網站,會議情境觀察語音與畫面是否恢復,終端情境查看長連線是否中斷。需要長時間維持的任務,盡量避免在過程中主動切換網路入口或線路。
如果只有串流影音播放一段時間後緩衝,不能直接歸類為連線中斷,應回到效能章節檢查持續吞吐量與目標端策略。如果頁面提示網域解析錯誤,則回到 DNS 章節。如果用戶端明確從已連線變成未連線,且日誌記錄了工作階段結束,才把重點放在線路、協定與系統背景。分類準確可以避免在錯誤章節重複操作。
持續斷線且無法透過網路、線路、裝置對照定位時,提交工單應附上斷線前後的日誌片段、平台、線路名稱、網路入口、是否發生鎖定螢幕或網路切換,以及一般網路是否也同時中斷。日誌可以隱藏個人訂閱內容,但不要裁掉錯誤時間附近的脈絡。支援人員需要看到工作階段是由哪一層結束,而不只是斷線後的最終畫面。
訂閱更新失敗與某個 App 不使用代理
訂閱更新失敗先檢查取得鏈路
訂閱更新包含幾個連續環節:登入正確帳戶、取得目前訂閱、用戶端發起讀取、解析設定、替換本機線路清單。任何一環失敗都會顯示「更新失敗」,因此需要確認失敗發生在哪裡。面板無法登入,應先處理帳戶憑證;面板可以登入但用戶端提示網址無效,重新複製目前的訂閱;用戶端能讀取卻提示解析錯誤,檢查使用的用戶端是否支援訂閱內容;更新成功但線路沒有變化,則檢查是否仍在查看舊設定群組。
複製訂閱時不要手動刪除或改寫字元,也不要把網址交給第三方短網址服務。訂閱屬於帳戶憑證,應只在自己的用戶端與使用者面板之間傳遞。如果懷疑訂閱已外洩,請進入面板重新處理帳戶交付資訊,並避免在工單正文貼上完整網址。提交問題時可以寫「訂閱讀取回傳驗證錯誤」,或附上遮蓋敏感部分的截圖,支援人員通常不需要公開看到完整憑證。
用戶端中存在多個設定時,更新按鈕可能只會更新目前選取的群組。確認正在操作的設定名稱,再執行更新;完成後查看線路清單是否改變。不要在多個用戶端之間反覆匯入經過編輯的設定副本,否則很難確認哪一份是目前來源。需要了解訂閱取得、匯入與外洩處理,可查看訂閱連結完整說明。
使用明顯的假網址檢查用戶端輸入格式
排查輸入框是否接受完整 URL 時,可以用文件範例確認格式結構,但不能把範例當成真實訂閱。以下網址明確使用公共範例網域與假令牌,只用於辨認用戶端需要的是完整連結,而不是一段被截斷的文字:
https://example.com/sub?token=YOUR_TOKEN
如果用戶端把網址辨識成搜尋詞、自動加上空格或只保留部分字元,應改用系統剪貼簿重新貼上,並確認輸入框類型是「從 URL 匯入」而不是「本機檔案」。QR Code 匯入失敗時,也應回到文字方式確認,避免把相機權限問題誤判為訂閱問題。更新完成後先選擇一條線路連線,再檢查 App;只看到線路清單不代表連線已建立。
某個 App 無法運作時先做瀏覽器對照
瀏覽器正常、某個 App 無法存取,表示帳戶、線路與基礎解析至少部分可用。此時重點檢查 App 是否遵循系統代理、是否使用獨立網路堆疊、是否被分流規則設定為直連,以及 App 啟動時是否快取了連線。先完全退出目標 App,確認用戶端已連線,再重新啟動目標 App。如果恢復,多半是舊工作階段問題;如果仍然失敗,切換用戶端的規則模式與全域模式進行對照,但修改前必須記錄原本的模式。
規則模式會依網域、位址或 App 匹配流量。規則缺失、規則過舊或目標服務新增網域時,主頁面可能可以開啟,但部分資源卻載入失敗。全域模式正常而規則模式失敗,表示應檢查規則集與 App 涉及的網域;兩種模式都失敗,則檢查線路地區、目標服務狀態與 App 帳戶區域。不要長期保留全域模式作為唯一修復結論,應理解它只是用來定位分流層的對照工具。
部分 App 不會讀取傳統系統代理,但會遵循系統建立的虛擬網路;另一些 App 可能啟用自己的 DNS 或連線最佳化。不同平台的行為也有差異。Android 與 Linux 上還可能存在按 App 選擇的分流設定,macOS 與 Windows 則常見系統代理與虛擬網路模式並存。排查時先確認用戶端目前使用哪種接管方式,再查看目標 App 是否被排除。不要照搬其他平台的選單名稱與設定路徑。
| 對照結果 | 較可能的範圍 | 下一步 |
|---|---|---|
| 瀏覽器正常,App 失敗 | App 快取、分流或獨立網路設定 | 重新啟動 App,比較規則與全域模式 |
| 全域模式正常,規則模式失敗 | 規則匹配或規則更新 | 更新設定並檢查目標網域路徑 |
| 所有 App 都失敗 | 連線、DNS、線路或基礎網路 | 返回連線與解析章節 |
| 更新成功但仍顯示舊線路 | 仍選取舊設定群組 | 核對目前設定來源 |
如果目標 App 只在某個地區線路失敗,而其他地區正常,請記錄線路與 App 名稱;如果所有線路都只對該 App 失敗,提交 App 啟動後的錯誤原文、規則模式與全域模式對照,以及瀏覽器是否正常。如果訂閱更新失敗,則提供面板是否可以登入、重新取得後是否仍失敗、用戶端解析提示與舊設定是否可以連線。將訂閱問題與 App 分流問題分開描述,能避免支援人員把兩個獨立故障當成同一個現象。
裝置數超限提示與帳戶狀態核對
先確認提示來自哪裡
VPNRZ 同時連線不限裝置數,因此看到「裝置數超限」或類似提示時,不能直接認定是本服務的限制。先確認提示來自使用者面板、用戶端、作業系統,還是目標 App。某些用戶端會限制本機設定實例,某些 App 會限制自身帳戶的登入裝置,企業網路也可能限制並行工作階段。這些提示雖然文字相似,處理位置卻完全不同。截圖時要保留視窗標題與提示來源,不要只截取中間的一句話。
如果提示來自目標串流影音、AI 工具或其他第三方帳戶,應查看該服務自己的帳戶規則,本服務無法改變目標服務的登入限制。如果提示來自用戶端,檢查是否匯入了重複設定、是否有舊程序仍在背景執行,以及用戶端是否將同一份設定辨識為多個本機實例。如果提示來自 VPNRZ 面板或線路連線過程,則記錄完整原文並提交工單,因為這與同時連線不限裝置數的事實不一致,需要核對帳戶工作階段狀態。
多裝置共用時保持帳戶來源一致
家庭或個人多裝置使用時,最容易出現的問題不是裝置數量,而是不同裝置儲存了不同時間取得的訂閱。某台裝置仍使用舊設定,另一台裝置使用目前設定,發生故障時看起來像「新裝置擠掉舊裝置」。正確做法是登入同一個帳戶,從面板重新取得目前訂閱,並在各裝置上確認設定來源。註冊無需電子郵件地址,使用者名稱加密碼即可註冊,因此尤其要保管好正確的使用者名稱,避免因相似名稱進入另一個帳戶。
更換密碼、重設帳戶資訊或更新訂閱後,舊用戶端可能仍保留快取。先在故障裝置上更新訂閱,再中斷並重新連線。不要為了同步而透過公開管道將設定檔傳給他人,也不要把訂閱網址放進共用文件。需要多人共同使用時,應明確由誰負責更新帳戶資訊,避免不同裝置各自編輯設定,最後無法確認哪一份仍然有效。
如果只有新裝置無法連線,而原裝置正常,帳戶與線路通常仍有可用路徑。比較兩台裝置的用戶端類型、設定群組、線路名稱與網路入口。先讓新裝置使用與原裝置相同的網路,再選擇相同線路;如果仍然失敗,問題較接近新裝置設定或系統權限。如果新裝置切換網路後恢復,則檢查原本的網路,不要繼續懷疑裝置數量。
帳戶可以登入不等於訂閱狀態完全正常
登入成功只代表憑證有效,還需檢查目前方案、流量狀態與訂閱是否屬於該帳戶。月訂閱包含 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB,流量依開通日每月重置,中途升級差額折算為剩餘天數。流量包為 ¥158/300GB、¥358/1000GB、¥658/3000GB,用完為止、永久不過期。如果方案狀態與預期不同,應先核對目前使用者名稱與訂單,而不是繼續修改用戶端。
中途升級後發現剩餘時間變化,應按照差額折算為剩餘天數來理解,不要把時間變化誤判為帳戶異常。月訂閱流量依開通日重置,也不是統一按照曆月變化。排查流量時應以面板顯示與開通日為準。如果只是需要重新選擇方案,進入價格頁面核對規則,再從使用者面板處理。支付寶 / 微信 / USDT 是支援的付款方式;付款完成後的帳戶狀態問題應保留訂單狀態頁面,不要重複建立多個相同操作。
區分帳戶、訂閱與目標服務帳戶
一次跨境存取可能同時涉及 VPNRZ 帳戶、用戶端本機設定與目標服務帳戶。VPNRZ 使用者名稱用於取得訂閱;用戶端讀取訂閱並建立連線;目標 App 則使用自己的登入系統。目標 App 要求重新登入,不代表 VPNRZ 帳戶已登出;用戶端提示設定過期,也不代表目標 App 帳戶失效。排查時將三者分開記錄,可以避免重設錯誤的憑證。
如果懷疑有人取得了訂閱資訊,應先保護 VPNRZ 帳戶並更新相關交付資訊,再逐台裝置重新匯入。不要在帳戶安全性仍未確認時,繼續把同一份訂閱複製到更多裝置。如果只是家庭共用的裝置管理問題,可參考多裝置帳戶與同時連線說明,重點區分登入數量、同時連線與用戶端本機實例這幾個不同概念。
工單中應提供目前使用者名稱的部分可辨識資訊、提示來源、平台、用戶端名稱、是否只有新裝置失敗、原裝置是否仍正常,以及重新取得訂閱後的結果。不要提交密碼或完整訂閱網址。如果涉及訂單,只需說明面板顯示的訂單狀態與預期不一致。支援人員需要核對的是帳戶歸屬與訂閱狀態,不需要取得你的私密憑證。
何時聯絡客服,以及工單應附哪些資訊
這些情況適合直接提交工單
完成基礎對照後仍無法定位,或問題明顯涉及帳戶、訂單、訂閱產生與多條線路共同異常時,就應提交工單。典型情況包括:面板顯示的方案或流量與實際訂單不一致;重新取得訂閱後仍出現驗證錯誤;多個支援平台、不同網路入口與多條線路同時失敗;同一條線路持續出現可重現錯誤;用戶端日誌顯示明確的服務端回應;VPNRZ 面板出現與同時連線不限裝置數不一致的限制提示。
如果只有一個瀏覽器擴充功能失效、目標 App 自身的帳戶提示受限,或基礎網路本身中斷,通常應先在對應產品或網路環境處理。支援人員可以協助判斷線路與訂閱,但無法修改第三方 App 帳戶或不屬於本服務的網路設備。說清楚問題邊界,反而能更快確認應由哪一方處理。
工單標題寫出症狀與範圍
標題不要只寫「不能用」「很慢」或「急」。更有效的結構是「平台 + 症狀 + 影響範圍」,例如「Windows 用戶端多條線路連線逾時」「iOS 鎖定螢幕後連線中斷」「訂閱更新回傳解析錯誤」「規則模式下某個 App 無法存取」。標題先讓支援人員知道故障層級,正文再提供重現流程。避免把多個無關問題塞進同一個標題;帳戶狀態與 App 分流若同時存在,分開描述更容易追蹤。
正文先寫預期結果,再寫實際結果。預期結果是連線後一般網頁與目標 App 都可以存取;實際結果則要精確到用戶端狀態、錯誤原文與受影響對象。接著列出已執行的對照:切換過哪些線路類型、切換網路入口是否恢復、其他裝置是否正常、一般網頁與目標 App 的結果是否一致。不要只寫「什麼都試過了」,因為支援人員無法知道「什麼」具體包含哪些操作。
保留足夠脈絡,同時隱藏敏感內容
截圖應包含用戶端名稱、線路名稱、狀態與完整錯誤,但要遮蓋使用者名稱、訂閱令牌、訂單識別資訊及其他私人內容。日誌截取錯誤發生前後的一段,不要只保留最後一句,也不要上傳與問題無關的完整系統資料。命令列輸出可以直接複製文字,方便搜尋;若包含本機使用者名稱或目錄,可在不破壞錯誤脈絡的前提下遮蓋。
訂閱網址與密碼不應寫進工單正文。若支援人員需要核對帳戶,通常可以透過已登入面板中的工單關聯完成。帳戶無法登入時,也只需提供使用者名稱與錯誤現象,不要主動提交密碼。VPNRZ 註冊無需電子郵件地址,使用者名稱加密碼即可註冊,因此使用者名稱是找回排查脈絡的重要線索,應準確填寫,但不應在公開頁面展示。
建議附上的現場清單
- 平台:Windows、macOS、iOS、Android 或 Linux。
- 用戶端:完整名稱,以及使用系統代理還是虛擬網路模式。
- 線路:地區、線路完整名稱與線路類型。
- 網路:家用寬頻、辦公室網路、公共 Wi-Fi 或行動網路。
- 現象:完全無法連線、已連線但無網頁、速度慢、斷線、更新失敗或 App 分流異常。
- 對照:切換線路、網路、裝置後的結果。
- 證據:錯誤原文、遮蓋敏感資訊的截圖、相關日誌片段。
如何描述可重現的流程
重現流程應從一個已知狀態開始,例如「基礎網路正常,用戶端處於中斷狀態」。接著寫下執行動作:「選擇某條線路並連線」「開啟一般網頁」「啟動目標 App」。最後寫出觀察結果:「用戶端顯示已連線,一般網頁正常,目標 App 一直等待」。這樣的順序讓支援人員能在相似條件下重新檢查。如果問題不是每次都發生,請寫明觸發條件,例如鎖定螢幕後、網路切換後、更新訂閱後或尖峰時段出現。
不要用未確認的原因取代現象。寫「線路伺服器壞了」不如寫「該線路連線逾時,另一條線路正常」;寫「DNS 污染」不如寫「網域解析命令逾時,直接連線測試有回應」;寫「被限速」不如寫「一般時段正常,尖峰時段持續傳輸下降,切換網路入口後恢復」。克制的描述不是少寫,而是把事實與推測分開。
收到回覆後的重新驗證方式
支援人員提供線路、設定或用戶端建議後,先回到原始基準重新驗證。只執行回覆中要求的變更,不要同時疊加其他網路上找到的設定。驗證成功時,回覆說明在哪個步驟後恢復,以及原問題是否仍能重現;驗證失敗時,提供新日誌與新錯誤,不要重複貼上舊截圖。這樣工單會形成清楚的變化鏈,後續處理不必從頭詢問。
帳戶或付款爭議應保留面板訂單狀態。VPNRZ 支援支付寶 / 微信 / USDT,並提供 60 天無理由退款;具體申請請透過使用者面板提交工單。工單中說明需要核對的訂單與目前狀態即可,不要在公開管道展示付款憑證。需要了解方案內容時,先查看方案價格,避免把月訂閱重置規則、流量包永久不過期與中途升級折算混為一談。
系統排查的終點不是把所有設定都修改一遍,而是得到一個邊界清楚的結論:問題會隨帳戶、裝置、網路、線路、時段、DNS、用戶端設定或目標 App 中的哪一項改變。能在本機解決的,就保留有效設定並記錄原因;需要支援介入的,就把最小重現路徑交給工單。下一次出現類似症狀時,從已建立的基準開始,不必重複整套高影響操作。