連線故障排查手冊

完全無法連線：先確認失敗發生在哪一層

「按下連線卻沒有反應」只是表面症狀，背後可能是用戶端沒有取得有效訂閱、所選線路暫時無法連通、本地網路本身未連線、系統代理狀態沒有切換，或舊設定仍占用通道。排查時不要同時修改線路、協定、規則與 DNS。一次只改一個變因，修改後重新測試；否則即使恢復，也無法確認究竟是哪一步生效，下次還得重新摸索。

先做最基本的判斷

第一步是完全退出用戶端後重新開啟，確認介面中看得到線路名稱，而不是空白清單、過期提示或訂閱讀取錯誤。接著中斷目前線路後重新連線，觀察狀態停在哪個階段：如果按下後立刻回到未連線，優先檢查設定是否完整；如果長時間停留在連線中，通常較像線路無法連通或本地網路受到攔截；如果介面顯示已連線卻完全無法瀏覽網頁，應進入下一章檢查系統代理與 DNS，而不是持續重複點擊。

接著確認本地網路。暫時中斷加速連線，開啟平時能正常存取的網站。如果基礎網路本身也無法開啟，請先修復本地網路；用戶端無法憑空替中斷網路的裝置造出一條通道。若基礎網路正常，再選擇不同地區的另一條線路測試。JVVPN 覆蓋 90+ 個國家 / 200+ 條線路，切換線路的目的不是盲目碰運氣，而是判斷故障屬於單一線路，還是整個用戶端環境。只有某條線路失敗時，記下故障線路名稱，換線繼續使用；所有線路都失敗時，再檢查用戶端與系統層。

清除互相搶奪控制權的程式

系統中同時執行多個代理、網路過濾、防護或企業連線工具時，這些程式可能爭用同一組系統代理設定。常見情況是用戶端顯示連線成功，但系統流量沒有經過它；也可能是前一個工具退出後留下代理位址，讓網頁持續轉向已不存在的本機入口。排查時要完全退出其他同類程式，不只是關閉視窗，也要確認系統匣或選單列沒有殘留程序。接著在系統網路設定中確認代理由目前用戶端接管，不要手動保留來源不明的位址。

Windows 可從系統代理設定確認自動或手動代理是否與目前用戶端狀態同步；macOS 應檢查目前正在使用的網路服務，而不是另一個閒置介面；Linux 則要留意圖形桌面代理、終端機環境變數與應用程式自身代理，這三套設定可能彼此不相認。若終端機曾設定代理環境變數，可先查看目前工作階段：

env | grep -i proxy

如果看到舊位址，先在目前終端機取消對應變數，再重新啟動要測試的命令列程式。不要把來源不明的代理變數寫入全域啟動檔，那就像替每個終端機塞進一張過期登機證。

重設順序比重新安裝更重要

仍然完全無法連線時，請依「中斷連線、退出用戶端、關閉其他網路工具、重新開啟用戶端、更新訂閱、切換另一條線路、再次連線」的順序執行。只有在用戶端無法啟動、設定檔損壞或系統授權明顯缺失時，才考慮重新取得用戶端。用戶端必須從使用者面板的下載入口取得，不要使用來源不明的安裝檔。重新安裝前先退出舊用戶端，避免新舊程序同時執行。

如果更換網路環境後能夠連線，原本的網路可能存在路由、DNS 或存取策略差異；如果所有網路環境都失敗，但同一帳戶在另一台裝置上正常，問題集中在目前裝置；如果多台裝置與多條線路同時失敗，請記錄發生時間、用戶端平台、線路名稱與錯誤原文，直接進入工單章節。這種分支判斷比「再重新啟動一次試試」更有價值，也更省心力。

能連線但網頁無法開啟：拆開檢查代理與 DNS

用戶端顯示已連線，只能證明連線流程完成，不代表網域解析、系統代理與應用程式流量都走在同一條路徑上。網頁無法開啟時，先區分「所有網站都失敗」「只有網域解析失敗」「只有某個網站失敗」，還是「瀏覽器失敗但其他應用程式正常」。這幾種表現看起來相似，處理方式卻完全不同。

用網域與基本請求區分故障

先中斷連線確認基礎網路可用，再重新連線並開啟多個不同網站。若所有網站都無法載入，而用戶端沒有明顯錯誤，請檢查系統代理是否啟用，以及瀏覽器是否設定了獨立代理。瀏覽器擴充功能可能覆蓋系統設定，測試時應暫時停用相關擴充功能，並使用一般視窗，而不是保留大量舊狀態的工作階段。若只有單一網站異常，優先清除該網站的快取與登入狀態，再換線測試；不要因為一個網站維護，就判定整個用戶端失效。

命令列可用以下方式檢查網域是否能解析，範例網域不涉及真實訂閱或憑證：

nslookup example.com

curl -I https://example.com

前一個命令若無法回傳解析結果，而其他基本網路操作正常，問題較接近 DNS；前一個正常、後一個失敗，則繼續檢查代理路徑、憑證時間與應用程式設定。系統日期明顯不正確時，加密連線可能因憑證驗證失敗而遭拒，因此應先啟用系統自動校時。不要跳過錯誤訊息：瀏覽器顯示「找不到位址」「連線遭重設」與「憑證無效」，指向的是不同故障層。

DNS 異常的典型表現

DNS 負責將網域轉換為網路可識別的位址。切換連線後，系統可能仍使用舊快取；用戶端可能接管了解析，但某個應用程式仍堅持使用自己的解析方式；家用網路設備也可能快取先前的結果。常見現象包括網域間歇性無法開啟、同一網站在瀏覽器與應用程式中的結果不同、切換線路後內容地區沒有變化，以及中斷連線後仍指向舊位址。

處理時先關閉發生問題的應用程式，中斷用戶端連線，再重新連線後開啟應用程式。若問題仍存在，可清除作業系統 DNS 快取後再試。Windows 可在具備相應權限的終端機執行：

ipconfig /flushdns

macOS 與 Linux 的快取機制會隨系統環境而異，不建議從不明教學複製一長串高權限命令。較穩妥的方式是重新連線目前網路、重新啟動系統解析服務，或直接重新啟動裝置。若用戶端提供 DNS 接管選項，應與目前模式保持一致；不要一邊啟用用戶端解析，一邊在瀏覽器中強制使用另一套解析，還期待兩者像訓練有素的編隊一樣協作。

確認規則模式沒有把請求送錯出口

規則模式會依網域或位址決定流量走加速線路或本地網路。如果規則過舊、分類不完整，或自訂規則排列位置錯誤，網站可能被誤判為直連。測試時可暫時切換至全域模式：若全域模式正常、規則模式失敗，表示線路本身可用，問題集中在規則；若兩種模式都失敗，則回頭檢查 DNS、系統代理或線路層。

有些使用者搜尋「翻牆軟體故障」時，實際遇到的是 DNS 與規則分流不一致，而非用戶端完全失效。診斷重點應放在可驗證的請求路徑：網域是否完成解析、規則命中了什麼、請求最終從哪個出口送出。保留錯誤截圖與重現網域，能讓客服直接判斷規則問題，遠比一句「網頁不能用」更有幫助。

速度變慢與尖峰時段卡頓：先找出瓶頸位置

速度變慢不代表線路故障。實際體驗會同時受到本地連線品質、無線干擾、線路距離、目標服務回應、規則模式、裝置負載與使用時段影響。只測一次、只測一條線路、只看峰值，得到的往往是情緒而不是結論。更完整的測速方法可參考VPN 測速怎麼測才準，本章聚焦於故障現場如何快速定位。

先比較中斷與連線後的差異

在同一台裝置、同一個網路環境與相近時間內，分別測試中斷連線及連線後的網頁開啟、檔案傳輸或串流媒體播放。若中斷時也明顯緩慢，瓶頸首先在本地網路；若中斷正常、連線後所有線路都慢，請檢查用戶端模式、裝置資源使用量，以及本地網路對加密連線的影響；若只有特定線路速度慢，則切換至距離較近或路徑更合適的地區。

測試時關閉正在同步、下載或上傳的程式。雲端硬碟、系統更新、視訊會議與區域網路備份都可能占用連線，尤其上傳頻寬用滿時，網頁請求也會顯得遲鈍。無線網路還會受到距離與同頻干擾影響，若能使用穩定的有線連線，可做一次對照。這項對照不代表必須長期改用有線，只是用來確認問題是否發生在無線這一小段。

延遲、吞吐量與穩定性不是同一項指標

延遲影響點擊後的回應速度，吞吐量影響持續傳輸能力，穩定性則決定播放或會議是否會週期性停頓。低延遲線路未必最適合大型檔案，高吞吐量線路也未必在短請求中回應最快。選擇線路時應依照使用情境：網頁與互動工具更重視回應連續性，串流媒體更重視持續吞吐量，遠端協作則特別怕抖動與短暫斷流。

尖峰時段要做跨時段與跨線路對照

如果白天正常、晚上反覆卡頓，表示故障具有明顯的時段特徵。不要只在卡頓時反覆重連同一條線路，而應選擇不同地區或不同線路類型做對照，並記錄哪些線路在相同時段較穩定。線路詳細資訊與類型說明可查看線路頁面。直連路徑通常較直接，但對本地網路變化較敏感；中轉路徑會增加中間環節，卻可能避開不理想的跨境路徑；IEPL 專線適合重視路徑穩定性的情境。具體選擇仍應以目前網路的實際體驗為準，而不是把某個標籤當成萬用解法。

串流媒體畫質下降時，還要區分服務端自動調整與連線速度。播放器會根據一段時間內的持續傳輸狀態調整畫質，剛切換線路後立刻觀察通常不準。可停止播放、切換線路、重新開啟內容，再觀察是否持續穩定。關於位元率、頻寬與畫質降級的關係，可繼續閱讀看 4K 總是掉到 480p 怎麼辦。

若所有線路在相同網路下都很慢，但換到另一個網路後明顯恢復，應把本地網路類型與發生時段寫進工單；若只有某個目標服務速度慢、其他網站正常，則記錄目標網域與使用地區；若速度忽快忽慢，請附上持續一段時間的現象描述，而不是只截取某次峰值。穩定性問題需要時間線，單張截圖很難說明路徑在哪一秒發生偏差。

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

頻繁斷線要先區分「用戶端主動中斷」「系統暫停網路」「無線網路切換」與「應用程式退到背景後遭系統凍結」。前景持續使用時穩定、鎖定螢幕或切換應用程式後斷線，通常應優先檢查背景權限與省電策略；前景使用時也按固定節奏斷線，則較像網路波動、線路工作階段失效或多個網路工具衝突。

桌面版先排除休眠與網路切換

Windows、macOS 與 Linux 在睡眠、喚醒、切換無線網路，或從有線轉為無線後，原本的連線可能仍顯示為啟用，但底層網路路徑已經改變。最穩妥的恢復方式是先中斷用戶端連線，確認新的基礎網路能夠開啟網頁，再重新連線。若每次喚醒後都出現異常，可檢查系統電源設定是否允許網路介面在閒置時關閉，並關閉會自動接管網路的其他工具。

如果裝置連接著多個可用網路，系統可能在訊號變化時自動切換。連線工作階段建立在舊介面上，新介面接管後便可能中斷。診斷期間固定使用一個網路，暫時關閉自動加入其他網路的選項。若固定後恢復穩定，問題不在線路本身，而在網路介面切換。不要一邊在不同存取點之間漂移，一邊要求工作階段像焊死在軌道上一樣穩定。

iOS 與 Android 的背景策略

行動裝置系統會根據電量、背景活動與應用程式使用狀態暫停程序。若用戶端退到背景後不久失效，先檢查是否允許該應用程式維持網路連線、是否被加入嚴格省電清單，以及系統是否在鎖定螢幕時關閉目前網路。不要使用一鍵清理工具強制結束用戶端，也不要在多工畫面手動滑掉仍需運作的程序。

iOS 上應確認用戶端所需的網路設定仍然存在；切換網路或系統喚醒後若沒有自動恢復，可開啟用戶端手動重新連線。Android 裝置的省電實作差異很大，應在系統的電池或應用程式背景設定中允許用戶端持續執行，並確認資料使用權限未受到限制。設定名稱會因裝置環境而異，判斷標準只有一個：退到背景後，用戶端程序與網路連線是否仍被允許保留。

透過時間規律判斷是線路還是裝置問題

斷線完全隨機時，記錄當時是否發生網路切換、鎖定螢幕、喚醒或大量資料傳輸；只在某條線路發生時，換線並保留線路名稱；所有線路都在同一台裝置上斷線，而其他裝置正常時，優先檢查目前裝置；多台裝置在同一網路上同時斷線，但更換網路後恢復時，問題較接近本地網路。這種交叉驗證不需要複雜工具，只要每次少改一個變因。

若中斷後用戶端自動重新連線，但應用程式沒有恢復，請關閉並重新開啟受影響的應用程式，因為它可能仍持有舊的網路工作階段。若用戶端本身也無法恢復，請完全退出後重新開啟。反覆發生且能穩定重現時，不要持續重新安裝；把「前景是否穩定、鎖定螢幕後是否發生、換線是否恢復、換網路是否恢復」寫入工單，客服就能沿著工作階段生命週期排查。

訂閱更新失敗：逐段核對連結與設定

訂閱會將可用線路與設定交給用戶端。更新失敗時，用戶端可能繼續顯示舊線路，也可能清空清單。先不要刪除仍能運作的舊設定；錯誤地先刪除再更新，會把「部分可用」變成「完全空白」。正確順序是確認帳戶狀態、重新取得訂閱、在瀏覽器或用戶端中驗證連結是否能存取，再決定要替換或重新匯入。

確認取得的是目前的訂閱入口

登入使用者面板，在總覽或訂閱相關區域重新複製目前的訂閱入口。不要從聊天記錄、舊文件或其他裝置的歷史剪貼簿取得連結。訂閱入口屬於帳戶交付資訊，只應匯入受信任的用戶端，不要發布到公開頁面，也不要交給不明轉換服務。教學範例可以長這樣，但它不是可用位址：

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

如果複製時混入空格、換行或標點，使用者端可能將其識別為無效位址。請直接使用面板的複製按鈕，並完整替換用戶端中的舊值。若用戶端支援更新現有訂閱，優先使用更新；只有訂閱項目本身損壞、名稱重複或無法編輯時，才建立新項目。確認新項目成功後再刪除舊項目，避免兩份設定同時失效。

依錯誤類型處理

「網路錯誤」通常表示用戶端未能成功存取訂閱入口，可先中斷目前代理後更新，再嘗試連線至一條可用線路後更新，藉此判斷入口在目前網路下的存取路徑。「格式錯誤」較接近用戶端不支援回傳格式、連結複製不完整，或內容被其他頁面取代。「授權失敗」則應重新登入面板取得目前入口，不要反覆編輯連結字元。用戶端顯示更新成功但線路沒有變化時，請檢查是否開啟了另一個同名訂閱，或用戶端仍在使用快取設定。

有些用戶端支援自動更新，但系統背景限制可能導致自動工作沒有執行。先手動更新一次，確認訂閱本身可用，再處理自動更新。若手動成功、自動失敗，問題屬於用戶端排程或系統背景權限；若手動也失敗，則繼續檢查網路與訂閱入口。不要把自動更新頻率調得過於密集，頻繁請求不會讓線路憑空變新，還可能讓記錄塞滿沒有診斷價值的重複錯誤。

避免設定疊加與舊規則殘留

重新匯入後，用戶端可能同時保留舊訂閱、手動線路與新訂閱。選擇線路前先確認它屬於哪一組，刪除完全重複且已停用的設定。若線路出現但無法連線，回到「完全無法連線」章節，不要繼續把問題歸咎於訂閱。訂閱更新解決的是設定取得，線路連線解決的是網路工作階段，兩者是前後相鄰的艙段，不是同一個零件。

若帳戶可以正常進入面板，但任何用戶端都無法更新，可記錄使用平台、用戶端名稱、錯誤原文，以及「中斷連線後更新」和「連線後更新」各自的結果。若只有某個平台失敗、其他平台正常，問題更可能在該用戶端的匯入格式或網路權限。第一次匯入流程不熟悉時，可閱讀iOS 訂閱匯入完整流程，或返回使用指南重新核對主要步驟。

某個 App 不走代理：檢查規則、程序與網路堆疊

瀏覽器正常、某個 App 卻無法存取，通常表示整體連線沒有故障，問題集中在應用程式自身的代理策略、分流規則或網路實作。有些應用程式遵循系統代理，有些提供獨立代理開關，另一些則直接建立連線，不讀取系統設定。先確認問題只發生在單一應用程式，再決定要修改用戶端規則或應用程式設定。

用全域模式進行一次隔離測試

保持同一條線路，暫時從規則模式切換至全域模式，完全退出問題應用程式後重新開啟。若全域模式恢復正常，線路與應用程式本身大致可用，問題落在分流規則；若仍然失敗，請檢查應用程式是否設定了獨立代理、是否快取舊網路工作階段，以及目標服務是否只在特定地區提供內容。測試結束後恢復原本的規則模式，再處理具體規則，不建議長期將診斷狀態當作最終設定。

規則通常依序比對，前面的寬泛規則可能先命中，讓後面的精確規則永遠沒有機會。檢查自訂規則時，請注意目標網域、相關子網域與應用程式實際存取的服務網域，而不是只盯著產品首頁。若用戶端能顯示連線記錄或規則命中結果，可在開啟應用程式時觀察對應請求是走直連還是代理。記錄中不應包含完整訂閱入口，分享截圖前也應遮蓋帳戶相關資訊。

區分系統代理與虛擬網路模式

系統代理主要影響遵循作業系統代理設定的程式；虛擬網路模式則從更底層接管流量，通常能涵蓋更多應用程式。若某個 App 完全忽略系統代理，而用戶端提供相應的接管模式，可在理解系統授權提示後進行測試。切換模式前先中斷連線，切換後重新連線並重新啟動目標應用程式，避免舊工作階段繼續沿用先前路徑。

Linux 環境尤其需要區分圖形桌面代理、終端機環境變數、容器網路與應用程式內代理。終端機程式可以查看代理變數：

env | grep -i proxy

若目標程式執行在容器或獨立沙盒中，主機系統代理不一定會自動傳入。此時應依照該執行環境的網路設定方式處理，而不是把真實訂閱位址直接寫入映像檔或設定儲存庫。範例設定只能使用虛構值，並透過執行時環境提供所需的本機代理資訊。

處理快取、地區與登入工作階段

某些服務會同時參考出口地區、帳戶地區、快取與既有登入工作階段。切換線路後，舊的應用程式程序可能仍保留先前的連線，導致網頁內容已變更而 App 沒有變化。應退出應用程式、切換線路，確認連線穩定後再重新開啟。若仍然異常，可清除該應用程式的快取或重新登入，但不必一開始就刪除所有資料。先做可還原的操作，再做破壞性操作，是排查的基本原則。

若同一服務在瀏覽器可用、App 卻不可用，請記錄應用程式名稱、平台、所選線路、規則模式與全域模式的對照結果；若不同線路表現不同，可到線路頁面了解地區與線路類型，再選擇與目標服務相符的出口。使用者所說的「梯子連上但 App 沒反應」，很多時候就是應用程式不讀取系統代理，或規則把請求送錯出口。釐清這一層，比連續換一輪線路更有效。

若應用程式更新後突然失效，而其他環境沒有變化，應優先懷疑應用程式的網路行為或快取發生改變。可以用瀏覽器存取同一服務做對照，並在工單中說明「更新前可用、更新後異常」，但不要編造或猜測具體用戶端版本。客服需要的是可重現條件，而不是一串可能寫錯的版本號。

裝置與帳戶異常：不要把登入問題當成線路故障

JVVPN 不限同時上線的裝置數，因此正常情況下，不應因同時連線的裝置數量觸發方案裝置上限。出現「另一台裝置能用、目前裝置不能用」時，重點應放在目前裝置的設定、訂閱是否同步、帳戶狀態與流量狀態，而不是計算家中到底開了多少個螢幕。關於多裝置計數與家庭使用情境，可閱讀VPN 多裝置共用完整解析。

先檢查帳戶與方案狀態

進入使用者面板確認能正常登入，並查看目前服務狀態。JVVPN 註冊不需要電子郵件地址，使用者名稱與密碼即可註冊，因此請妥善保存使用者名稱。若忘記的是登入身分而不是用戶端設定，不要連續建立多個相似帳戶，否則容易在不同帳戶間購買、複製訂閱與提交工單，最後像把行李送上相鄰航班。

月訂閱包括 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量以開通日為基準每月重設，中途升級差額會按剩餘天數折算。流量包為 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完為止，永久不過期。若用戶端能連線但之後無法正常傳輸，應登入面板核對目前訂閱與流量狀態，而不是只在用戶端介面反覆重新整理。方案詳細資訊與選擇入口位於方案頁面。

不要在多台裝置間複製快取檔案

在新裝置上使用時，應從使用者面板取得適合目前平台的用戶端，並重新匯入目前訂閱。不要直接複製另一個系統的用戶端快取目錄，其中可能包含平台相關路徑、舊規則、失效工作階段或不相容設定。JVVPN 支援 Windows / macOS / iOS / Android / Linux，各平台的系統代理、背景權限與網路接管方式不同；訂閱內容可以一致，但用戶端執行環境不能直接複製。

若某台裝置的線路清單為空、其他裝置正常，先在問題裝置手動更新訂閱；若更新失敗，依訂閱章節處理。若清單存在但無法連線，依連線章節處理。若能連線但應用程式無法使用，依分流章節處理。這種按階段切分的方法，能避免把所有問題都塞進「帳戶異常」這個黑洞。

區分帳戶登入、用戶端訂閱與付款狀態

網站帳戶登入成功，不代表用戶端已匯入訂閱；用戶端存在訂閱，不代表已更新至目前狀態；付款完成後，也需要回到面板確認對應服務已顯示。支付寶 / 微信 / USDT 是本站支援的付款方式。遇到訂單狀態與預期不一致時，請透過使用者面板查看訂單並提交工單，不要重複建立訂單來測試系統。

如果問題與付款後的使用預期有關，可先查看方案條款。本站提供 7 天無理由退款，具體申請應透過使用者面板處理。排障與退款是兩條獨立流程：技術問題可以繼續提交工單定位，退款請求則應清楚寫出對應訂單與需求，避免客服從混雜描述中猜測使用者究竟要修復連線，還是處理訂單。

什麼時候找客服，以及如何撰寫工單

自我檢查的目的不是讓使用者兼任網路工程師，而是蒐集足夠資訊，快速判斷故障範圍。完成基礎網路確認、換線測試、重新啟動用戶端與更新訂閱後仍然失敗，就應提交工單。若多個平台、多個網路環境與多條線路出現相同問題，也不必繼續在本地拆解飛船；這類現象更值得交由服務端統一檢查。

以下情況適合直接提交工單

所有線路同時無法連線，且基礎網路正常；訂閱入口在不同用戶端都無法更新；某條線路持續異常，而換線後可恢復；存在付款記錄，但面板服務狀態未如預期顯示；同一問題能依固定步驟重現；用戶端提供明確錯誤代碼或錯誤原文。這些情況都有清楚的檢查對象，提交後客服可依帳戶、訂閱、線路或用戶端方向處理。

如果只是單一網站短暫無法開啟，可先換線並稍後重新測試；如果基礎網路本身中斷，應先處理本地網路；如果只有某個 App 無法使用而瀏覽器正常，應完成全域模式對照後再提交。工單不是許願池，資訊越具體，來回確認就越少。

一份可執行的工單應包含哪些內容

• 故障現象：說明是無法連線、連線後無網路、速度異常、頻繁斷線、訂閱更新失敗，還是單一應用程式無法使用。
• 發生環境：提供 Windows、macOS、iOS、Android 或 Linux，以及使用的用戶端名稱。
• 線路資訊：寫明發生問題的線路名稱，並說明更換其他線路後的結果。
• 網路對照：說明中斷連線時基礎網路是否正常，以及更換至另一個網路後是否恢復。
• 模式對照：若涉及單一應用程式，說明規則模式與全域模式的表現是否不同。
• 錯誤原文：直接複製用戶端提示，不要只寫「出現錯誤」，也不要自行改寫成猜測結論。
• 重現步驟：從開啟用戶端開始，依實際點擊順序描述直到錯誤出現。
• 必要截圖：截圖應包含狀態與錯誤訊息，但請遮蓋完整訂閱入口、帳戶憑證與付款敏感資訊。

建議的重現描述範本

問題類型：連線後無法開啟網頁
平台與用戶端：填寫實際平台和用戶端名稱
所選線路：填寫線路名稱
基礎網路：中斷用戶端後可以正常開啟網頁
對照結果：更換線路後的實際表現
規則模式：填寫目前模式與切換後的結果
錯誤原文：貼上用戶端顯示的完整提示
重現步驟：
開啟用戶端
更新訂閱
選擇線路
建立連線
開啟目標網站後出現錯誤

範本中的描述應替換成實際情況，不要附上完整訂閱入口，也不要上傳包含密碼的設定檔。若錯誤只在特定時段發生，請寫明大致時段與持續狀況；若問題隨機發生，說明最近一次發生前是否切換網路、鎖定螢幕、喚醒或進行大量資料傳輸。與其堆疊許多無關截圖，不如提供一條清楚的時間線。

提交後保留現場，避免繼續大幅修改

提交工單後，盡量保留能重現問題的線路名稱、用戶端設定與錯誤資訊。若必須繼續使用，可切換至正常線路，但不要立刻刪除所有設定、重新安裝系統或清空帳戶內容；現場被徹底改寫後，客服只能根據殘留片段推理。若問題自行恢復，也應在工單中補充恢復時間、是否換線以及執行過的操作，這些資訊有助於判斷是暫時的線路波動、快取失效，還是本地網路變化。

提交入口位於使用者面板的工單中心。客服需要的是可驗證的事實，不需要「肯定是伺服器掛了」這種先下結論的宇宙廣播。把現象、環境、對照與錯誤原文整理完整，排障就能從猜謎變成工程問題。處理完成後，再將用戶端恢復至日常規則與常用線路，避免長期停留在為診斷而暫時啟用的全域模式。