Diagnostic baseline
完全無法連線:先確認故障停在哪一層
「完全無法連線」至少包含幾種不同現象:用戶端無法啟動、訂閱已匯入但沒有線路、點擊連線後立即回到未連線、連線過程長時間停留,以及系統顯示已連線卻沒有任何流量。它們看似相近,處理路徑卻不同。第一步應觀察用戶端目前能否正常開啟設定頁面、能否看到訂閱中的線路名稱,以及失敗發生在點擊連線之前還是之後。若用戶端本身無法開啟或權限要求尚未完成,應先處理安裝與系統權限;若線路清單為空,則跳到訂閱章節;只有在線路存在且連線動作失敗時,才進入網路與線路檢查。
建立最小測試環境
先關閉會改變路由的其他工具,包括系統中殘留的代理設定、瀏覽器個別設定的代理、企業網路用戶端,以及曾啟用過的虛擬網路介面。不要同時執行兩個負責系統代理或通道功能的程式,因為後啟動的程式可能覆寫預設路由,先啟動的程式又可能繼續接管網域解析,最後形成「介面看似正常、流量卻沒有明確出口」的狀態。關閉這些程式後,完全退出 46VPN 用戶端再重新開啟,而不是只在視窗中反覆點擊連線。
接著固定一個網路入口進行測試。若目前使用無線網路,就先維持該網路不變,不要在測試過程中頻繁切換其他連線方式。開啟一個原本就能存取的普通網頁,確認基礎網路本身可用;如果未連線 46VPN 時所有網頁都無法開啟,故障位於本地網路入口,繼續更換線路不會產生有效結論。基礎網路正常後,選擇另一條可用線路重新連線。選擇線路不要只憑名稱連續試遍,而應先切換到不同地區或不同線路類型,用於判斷問題是單一線路異常,還是連線機制整體失敗。完整線路範圍可在全球節點頁面查看。
檢查系統權限與虛擬網路介面
桌面系統上的用戶端通常需要建立或呼叫虛擬網路介面。首次執行時若系統跳出權限確認,取消後可能出現用戶端可開啟、線路也看得到,但通道無法建立的情況。Windows 可在網路介面卡清單中確認相關虛擬介面是否存在且未被停用;macOS 應在系統網路設定與隱私權與安全性提示中確認網路延伸功能已獲允許;Linux 則要確認目前帳戶具備執行用戶端所需的網路權限。不要隨意刪除不熟悉的系統介面,應先完全退出用戶端,再透過用戶端本身的修復或重新授權流程處理。
行動系統也會要求確認 VPN 設定。若曾拒絕、刪除或重置系統網路設定,需要重新從用戶端發起連線,讓系統再次顯示設定確認。點擊連線按鈕後立即恢復原狀,常見原因是系統設定未獲准、既有設定處於異常狀態,或作業系統的網路保護策略阻止新通道。此時應先刪除由目前用戶端建立且已失效的設定,再從用戶端重新產生;不要刪除企業或工作環境中由管理員設定的項目。
用交叉測試收斂結論
交叉測試應圍繞裝置、網路、線路三個面向展開。維持裝置與網路不變,只更換線路,可以判斷單一線路問題;維持裝置與線路不變,更換網路,可以判斷入口網路問題;維持網路與訂閱不變,更換另一台受支援平台的裝置,可以判斷本機環境問題。46VPN 支援 Windows、macOS、iOS、Android、Linux,且不限台數裝置同時上線,因此可利用現有裝置做對照,不必先刪除其他裝置。
如果所有線路在同一網路都失敗,但換網路後恢復,應記錄失敗網路的類型、是否需要瀏覽器登入認證,以及是否存在企業或校園網路策略。若只有一條線路失敗,暫時切換其他線路即可,並把線路名稱與失敗時間提交給支援人員。若所有裝置、所有網路、所有線路都失敗,應確認帳戶與訂閱是否仍可在使用者面板正常讀取,再進入訂閱檢查。排查過程中不要把反覆重新安裝用戶端作為第一選擇;重新安裝會清除日誌、設定與可重現狀態,適合在確有權限或設定損壞證據時使用,而不是代替診斷。
Reachability and DNS
能連線但無法開啟網頁:區分路由、解析與瀏覽器狀態
用戶端顯示連線成功,只能證明通道或系統代理已進入執行狀態,不能單獨證明網域解析、預設路由與瀏覽器請求都已正確經過線路。排查時先區分「所有網頁都無法開啟」、「只有網域無法開啟但直接存取已知服務有回應」、「只有某個網站無法開啟」以及「瀏覽器無法開啟但其他應用程式可用」。這些邊界決定應檢查系統網路、DNS、網站本身還是瀏覽器擴充功能。不要把單一網站的維護、帳戶地區限制或登入狀態問題直接歸因於線路。
先驗證基礎請求,再檢查網域解析
連線後先開啟多個用途不同的網站。如果全部失敗,退出瀏覽器並重新開啟,避免舊連線繼續重複使用連線前的網路工作階段。若仍然失敗,查看用戶端是否有流量經過、系統代理是否已正確啟用,以及連線模式是否只代理特定規則。接著在終端機檢查網域是否能解析。範例使用公共測試網域,不包含任何真實訂閱資訊:
nslookup example.com
ping example.com
nslookup若能回傳解析結果,表示系統至少能取得網域記錄;若顯示找不到伺服器、要求逾時或沒有結果,問題更接近 DNS 鏈路。ping不一定能收到回應,因為目標服務可能不回應此類探測,因此不能作為網站可用性的唯一依據;更值得觀察的是指令能否將網域轉換為位址。若網域可解析而瀏覽器仍然失敗,應繼續檢查代理路由、瀏覽器安全 DNS、擴充功能與快取,而不是持續更換 DNS。
清除快取並處理 DNS 異常
作業系統、瀏覽器與用戶端都可能快取網域結果。切換線路後,舊結果仍指向先前的存取路徑,便會出現連線已更新但頁面仍然失敗的情況。先完全退出瀏覽器,再依平台清理系統快取。Windows 可使用:
ipconfig /flushdns
macOS 可在終端機執行系統快取刷新指令:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
採用 systemd-resolved 的 Linux 環境可使用:
sudo resolvectl flush-caches
執行指令後重新開啟瀏覽器並再次測試。若瀏覽器啟用了獨立的安全 DNS,可能繞過系統解析路徑,導致系統測試正常而瀏覽器異常。可暫時關閉該選項進行對照,確認問題後再決定使用系統解析或瀏覽器指定的解析服務。這裡的「暫時關閉」只是診斷變數,不代表長期設定建議。排查完成後應恢復符合自身安全要求的設定。
只影響部分網站時,不要擴大故障範圍
單一網站無法開啟時,先在無痕視窗測試,以排除舊 Cookie、網站儲存資料與擴充功能的影響;再切換另一條同地區線路,觀察是否與出口變化有關。若首頁可開啟,但登入、影片或 API 請求失敗,應記錄失敗的具體頁面與操作,不要只寫「網站無法開啟」。不同子資源可能使用不同網域,頁面框架成功載入不表示後續請求走相同路徑。開發者可在瀏覽器網路面板中查看失敗請求的網域、狀態與是否長時間等待,但提交工單時應刪除請求中的帳戶資訊、授權欄位與私人內容。
若所有網域都失敗,而退出 46VPN 後立即恢復,請檢查用戶端目前模式是否完整接管系統流量,以及系統中是否殘留手動代理。Windows 與 macOS 可在系統網路代理頁面確認位址與連接埠是否由目前用戶端維護;退出用戶端後若代理仍保留,應先關閉殘留設定,再重新執行用戶端。行動裝置則可關閉連線,短暫停用再啟用網路介面後重新連線,讓系統重新建立預設路由。若症狀在切換網路後出現,尤其應執行一次完整斷線與重新連線,避免舊網路的 DNS 與新通道同時存在。
確認線路正常後,可依照出口 IP 與 DNS 檢查方法驗證請求是否真正經過預期出口。驗證時應同時關注出口、DNS 與具體應用程式,不能只依賴用戶端按鈕的顏色。若出口已變更、DNS 也能解析,但特定服務仍拒絕存取,則更可能是該服務的帳戶、地區策略或網站狀態問題,應分別處理。
Performance isolation
速度緩慢與尖峰時段卡頓:分開測試入口、線路與應用程式
速度問題最容易被一句「節點很慢」概括,但實際鏈路包含本地連線、電信業者出口、線路入口、跨境區段、目標服務與終端效能。任何一段壅塞都會呈現為載入緩慢。正確做法是先建立未連線狀態下的本地網路基準,再比較不同線路、不同時間與不同應用程式,而不是只看一次測速結果。測速工具會選擇自己的目標伺服器,其路徑可能與實際使用的網站完全不同,因此測速頁面很快,不代表串流媒體、AI 工具或程式碼儲存庫一定快,反過來也一樣。
先排除本地無線網路與背景流量
在連線前後都觀察普通網頁是否穩定,並暫停雲端硬碟同步、系統更新、大型檔案下載與區域網路備份。無線網路訊號波動時,VPN 通道只會把原有的丟包放大成重傳與停頓。靠近無線基地台、避免裝置在多個無線基地台之間切換,或在條件允許時使用更穩定的本地連線進行對照。若未連線時已出現影片自動降低畫質、網頁偶發逾時或遠端工作階段停頓,應先修復入口網路;在不穩定的基準上切換再多線路,也難以得到可信結論。
終端效能也會影響加密與轉送。若只有一台裝置速度慢,而同一網路中的其他裝置正常,應檢查該裝置是否處於省電模式、儲存空間不足、背景工作繁忙,或安全軟體正在掃描全部網路流量。瀏覽器開啟大量頁面、開發者工具持續擷取請求、容器或虛擬機器佔用網路時,也會改變實際體感。先關閉與測試無關的工作,再使用同一個目標頁面重新測試,避免把裝置負載誤判為線路問題。
依用途選擇線路,而不是只看地名
實體距離通常會影響往返時間,但不是唯一因素。目標服務的部署位置、入口電信業者、線路類型與當時壅塞情況同樣重要。存取日本地區服務時,可先比較日本及鄰近地區線路;存取面向美國的開發服務時,地區更接近目標不一定優於路由更穩定的入口。應以實際用途作為判斷標準:網頁瀏覽關注首位元組與連續請求,影片關注持續傳輸,終端工作階段與 AI 程式設計工具更重視長連線穩定性,檔案傳輸則更依賴持續吞吐量。
| 使用情境 | 優先觀察 | 常見誤判 | 建議作法 |
|---|---|---|---|
| 網頁與搜尋 | 首屏回應、連續跳轉 | 只看下載峰值 | 比較不同地區線路的實際頁面 |
| 影片播放 | 持續載入、拖曳後恢復 | 只測試首頁能否開啟 | 固定畫質並觀察連續播放 |
| 開發與終端機 | 長連線、請求重試 | 測速快就認為工作階段穩定 | 用真實儲存庫或工具流程驗證 |
| 檔案傳輸 | 持續吞吐量、是否中斷 | 用瞬時峰值代表全程 | 暫停其他下載後單獨重新測試 |
判斷尖峰時段卡頓的證據
如果同一裝置、同一網路、同一目標服務在其他時段穩定,而尖峰時段反覆變慢,應記錄發生時段、使用線路、目標服務與症狀類型。記錄「開始載入緩慢」、「播放過程中停頓」、「終端工作階段中斷」比只寫「速度慢」更有價值。接著切換到不同地區或不同線路類型做對照。如果一組線路普遍受影響而另一組正常,可暫時使用後者;若所有線路同時變慢,還要檢查本地電信業者、家庭網路共用與目標服務本身是否也處於高負載。
46VPN 涵蓋 90+ 個國家、200+ 條線路,線路數量提供避開局部壅塞的選擇空間,但不代表所有地區都適合所有目標。使用時應保留幾條對自身網路表現穩定的候選線路,而不是長期只依賴單一出口。線路恢復後也可以切回原線路重新測試,以確認問題是否具有時間相關性。若某條線路持續出現同類故障,把線路名稱、發生時段、入口網路與目標服務交給支援人員,比提交一張孤立的測速截圖更容易定位。
流量餘額同樣需要確認。月訂閱提供 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB,流量依啟用日每月重置;流量包為 ¥158/300GB、¥358/1000GB、¥658/3000GB,用完為止且永久不過期。若帳戶端流量狀態異常,應先進入使用者面板核對方案,而不是把無法繼續傳輸誤判為線路壅塞。中途升級時,差額會按剩餘天數折算。具體選擇可查看方案與流量包。
Session continuity
頻繁斷線與行動裝置背景斷線:檢查工作階段生命週期
頻繁斷線要先判斷是通道真正中斷、應用程式長連線重建,還是裝置網路入口發生切換。用戶端仍顯示已連線,但某個聊天、終端機或影片應用程式重新載入,可能只是該應用程式的工作階段失效;用戶端狀態同時恢復為未連線,才更接近通道中斷。還應觀察斷線是否總發生在鎖定螢幕、休眠、切換無線網路、離開某個基地台或系統進入省電狀態之後。具有明確觸發條件的問題通常能透過系統設定修復,而隨機出現的問題更需要日誌與多線路對照。
桌面端先排查休眠與網路切換
桌面裝置從睡眠恢復時,原有網路介面可能已重新取得位址,而用戶端仍保留睡眠前的通道狀態。此時介面可能短暫顯示已連線,但請求已沒有正確路由。恢復後若網頁無法開啟,應先斷線再連線,不必立即重新啟動系統。若每次休眠後都重現,可檢查用戶端是否允許系統啟動後執行、網路恢復後是否自動重新連線,以及作業系統是否在省電時關閉網路介面卡。
無線網路在多個基地台之間切換,也會造成底層連線變化。即使網路名稱相同,裝置也可能切換到另一條鏈路,既有通道需要重建。排查時固定在同一位置,關閉會自動連線其他網路的選項,觀察斷線是否消失。同時連接有線與無線網路的裝置,應避免作業系統在兩者之間自動調整優先順序。若斷線只發生在某個入口,問題可能位於入口網路或路由器;若所有入口都發生,再檢查用戶端、系統權限與線路。
行動裝置背景策略是主要變數
行動作業系統會限制背景活動以節省電量。螢幕關閉後,系統可能凍結用戶端、延遲網路工作或回收工作階段,重新亮屏時便出現短暫無法使用。Android 應檢查應用程式電池策略、背景執行權限、數據節省模式與系統內建的應用程式休眠功能,將用戶端設定為允許必要的背景執行;不同廠商的介面名稱可能不同,應圍繞「電池」、「背景」、「自動啟動」、「數據用量」尋找,而不要依賴固定選單路徑。調整後鎖定螢幕並等待,再重新開啟實際使用的應用程式驗證。
iOS 上應確認系統中的 VPN 設定仍然存在,並檢查低耗電模式、網路切換與隨選連線行為。若問題只在無線網路與行動網路互換後出現,可先完全斷線,待新網路穩定後重新連線。不要在訊號反覆切換時連續點擊連線,系統可能同時處理舊工作階段清理與新工作階段建立,導致狀態顯示與實際路由暫時不一致。若背景恢復後只有一個應用程式失敗,先結束該應用程式並重新開啟;若所有應用程式都失敗,再重新連線通道。
| 平台 | 重點檢查 | 重現方式 | 優先處理 |
|---|---|---|---|
| Windows | 介面卡省電、休眠恢復、殘留代理 | 睡眠恢復後開啟同一網頁 | 重新連線並檢查網路介面卡狀態 |
| macOS | 網路延伸功能權限、無線切換、系統代理 | 鎖定螢幕或切換網路入口後重新測試 | 確認延伸功能權限並重建連線 |
| Android | 電池最佳化、背景限制、數據節省 | 鎖定螢幕後重新開啟目標應用程式 | 允許必要的背景執行 |
| iOS | 系統設定、低耗電模式、網路切換 | 切換網路後檢查所有應用程式 | 網路穩定後重新連線 |
| Linux | 網路管理程式、休眠掛鉤、解析服務 | 工作階段恢復後檢查路由與 DNS | 重新啟動連線並確認預設路由 |
區分線路中斷與應用程式重新連線
選擇一個普通網頁和一個長連線應用程式同時觀察。若網頁持續可用而長連線應用程式斷線,問題更可能與應用程式工作階段、心跳或目標服務有關;若兩者同時失敗且用戶端重新連線,則更接近線路或入口網路波動。再更換另一條線路並維持相同操作,如果症狀隨線路消失,應記錄原線路;如果所有線路都在同一網路下斷開,而換網路後正常,應記錄入口網路。這樣的結果比「經常斷線」更具操作價值。
若斷線與帳戶同時上線裝置無關,也不必透過刪除裝置來試錯。46VPN 支援不限台數裝置同時上線,數台自有裝置正常連線本身不會造成裝置數超限。真正值得檢查的是多台裝置是否同時進行大量傳輸、家庭入口網路是否壅塞,以及某台裝置是否不斷重新連線造成局部干擾。裝置維度用於對照故障,不應被視為需要清空的限制項目。
Subscription state
訂閱更新失敗與裝置提示異常:從來源到本地快取逐一核對
訂閱更新失敗通常發生在「使用者面板產生訂閱資訊」、「用戶端存取訂閱」、「用戶端解析內容」、「本地儲存新設定」其中一個環節。首先確認帳戶可以正常登入,方案狀態與流量資訊能在面板中讀取。46VPN 註冊不需要電子郵件地址,使用者名稱與密碼即可完成註冊,因此排查帳戶時應以實際使用者名稱為準。若忘記憑證或登入狀態異常,應從面板的帳戶流程處理,不要反覆建立新帳戶,否則方案與訂閱會分散在不同帳戶中。
確認訂閱來源與存取路徑
用戶端與訂閱都應從使用者面板取得,不要使用他人轉發的網址、截圖中的文字或儲存已久的第三方紀錄。行銷頁面不會提供靜態安裝套件直連或公開訂閱網址;進入面板後才能取得與帳戶對應的用戶端與訂閱。若訂閱過去可以更新,後來突然失敗,先回到面板重新複製目前入口,避免繼續使用已失效、被截斷或包含多餘空格的舊內容。
複製時應確保文字從開頭到結尾完整,不要手動修改查詢參數,也不要把通訊軟體自動產生的預覽文字當作網址。為說明格式,以下只使用明顯的假值,不能用於真實連線:
https://example.com/sub?token=YOUR_TOKEN
若瀏覽器可以存取訂閱入口而用戶端無法更新,問題更可能位於用戶端匯入方式、格式相容性或本地快取;若瀏覽器與用戶端都無法存取,則要檢查帳戶狀態、目前網路與入口有效性。不要把真實訂閱內容貼到公開論壇或公開工單截圖中。訂閱入口屬於帳戶憑證的一部分,洩露後應在使用者面板中依可用流程更新,而不是繼續轉發用於排錯。
處理快取、重複設定與解析失敗
更新前記錄目前可用線路,避免清理後失去回復路徑。先在用戶端內執行訂閱更新,而不是直接刪除設定。若提示格式錯誤,檢查是否匯入了網頁網址、帶引號的文字或不完整內容;若提示網路錯誤,切換到基礎網路可用的環境後重試;若提示寫入失敗,檢查用戶端是否具備儲存設定所需的系統權限。只有確認本地設定損壞時,才刪除對應的舊訂閱並重新匯入。
用戶端中存在多個同名訂閱時,使用者可能更新了舊項目,卻連線到另一個項目中的線路。可透過訂閱更新時間、線路名稱與來源進行核對,保留目前有效項目,刪除明確重複且失效的副本。操作前最好匯出不含帳戶憑證的設定說明或記錄線路名稱,以便復原。若重新匯入後線路仍為空,應保留用戶端錯誤原文與訂閱更新時間,提交給支援人員檢查伺服器端回應與用戶端解析是否相符。
如何判斷裝置數超限提示
46VPN 的同時上線裝置數不限台數,因此正常使用自有裝置時,不應把「裝置數超限」視為方案規則。若用戶端、系統或其他軟體顯示類似提示,先確認提示來源:是 46VPN 使用者面板、目前用戶端、作業系統,還是另一個同時執行的網路工具。截圖應包含視窗標題與完整提示區域,避免只截取一句文字而無法判斷來源。若提示並非來自 46VPN,應在對應軟體或系統環境中處理。
若使用者面板實際出現與不限台數規則不一致的狀態,應停止刪除裝置或重複購買方案,直接提交工單。工單應附上帳戶使用者名稱、方案名稱、出現提示的平台、操作路徑與完整截圖,但不要附上密碼或訂閱入口。支援人員需要核對帳戶端狀態,而不是讓使用者透過重新安裝用戶端掩蓋問題。多個平台同時出現相同提示時,應說明 Windows、macOS、iOS、Android 或 Linux 中哪些平台受到影響;只有單一平台出現時,則同時檢查該用戶端的本地快取與登入帳戶是否正確。
若需要核對付款狀態,應以使用者面板的訂單記錄為準。46VPN 支援支付寶、微信、USDT。提交付款相關工單時,可提供訂單狀態、付款方式與面板可見的訂單識別資訊;不要提交付款密碼、完整帳戶憑證或與核對無關的私人資訊。若對方案選擇有疑問,請先閱讀價格與方案說明。本服務提供 60 天無理由退款,退款問題應透過面板工單依網站條款處理,不應透過重複建立訂單測試。
Application routing
某個 App 不經過代理:檢查模式、程序與獨立網路堆疊
當瀏覽器可以存取、出口也已變更,但某個 App 仍沿用原本的網路,或完全無法連線,問題通常位於應用程式路由,而非整條線路。應用程式可能不讀取系統代理、使用獨立 DNS、直接建立特定類型的連線、啟動輔助程序,或在連線前已建立工作階段。排查時要先證明「只有這個 App 異常」:用同一裝置上的瀏覽器與另一個應用程式做對照,確認系統整體可用,再處理該應用程式的網路行為。若所有應用程式同時失敗,應返回網頁與 DNS 章節。
先重建應用程式工作階段
許多應用程式在啟動時讀取系統代理,並持續重複使用既有連線。若先開啟應用程式、再連線 46VPN,應用程式可能不會自動切換到新路徑。應完全退出應用程式,包括系統匣程序、選單列程序與背景輔助服務;連線 46VPN 後再重新啟動。只關閉視窗通常不會結束背景程序。開發工具、遊戲平台、即時通訊與同步軟體尤其常駐背景,應在系統工作管理員介面確認程序已經結束。
重新啟動後,使用應用程式本身的帳戶重新整理、內容載入或網路診斷功能再次測試。若恢復,表示問題來自舊工作階段,不需要變更全域設定。若仍然失敗,查看應用程式是否提供「使用系統代理」、「自動偵測代理」、「直接連線」或自訂網路設定。通常應先讓應用程式跟隨系統設定;若其中儲存了舊代理位址,應清除舊值。不要在不了解用途時同時設定系統代理與應用程式代理,這會形成重複轉送,或讓請求送往已關閉的本地連接埠。
規則模式與全域模式的對照
用戶端採用規則模式時,只有符合相應規則的請求會經過線路。某個應用程式使用的網域、位址或協定若未被規則涵蓋,就會走原本的網路。診斷時可以暫時切換到涵蓋範圍更完整的連線模式進行對照:若應用程式隨即恢復,問題位於規則匹配;若仍未恢復,則繼續檢查應用程式網路堆疊與系統權限。對照結束後應恢復原模式,再針對應用程式網域或程序調整規則,避免長期改變其他應用程式的存取路徑。
若用戶端支援依應用程式選擇,應確認目標應用程式本體與輔助程序都已包含。瀏覽器通常只有主要程序名稱,而開發工具可能由啟動器、背景服務與執行環境共同發起請求。只選擇看得到的主程式,下載、登入或更新模組仍可能直接連線。可在系統工作管理工具中觀察應用程式啟動後新增的相關程序,再依用戶端提供的分應用程式功能進行設定。不要複製來源不明的完整規則;規則應盡量圍繞實際應用程式與網域,方便後續維護。
| 現象 | 可能邊界 | 驗證方法 | 處理方向 |
|---|---|---|---|
| 瀏覽器正常,App 無法登入 | App 未讀取系統代理 | 連線後完全退出並重新開啟 App | 啟用跟隨系統代理或檢查分應用程式設定 |
| App 首頁正常,下載失敗 | 輔助程序或資源網域未匹配 | 觀察失敗操作對應的程序與請求 | 補充程序或網域規則 |
| 切換到完整模式後恢復 | 規則匹配範圍不足 | 恢復原模式後再次重現 | 針對目標服務修正规則 |
| 只有更新模組失敗 | 更新程式獨立執行 | 檢查背景新增程序 | 讓更新程式使用相同的網路路徑 |
開發工具與命令列的特殊情況
終端機程式通常不會自動讀取圖形介面中的瀏覽器代理設定。某些指令會讀取環境變數,另一些工具使用自己的設定檔,還有些會直接跟隨系統路由。因此出現瀏覽器正常而命令列失敗時,應先確認用戶端提供的是系統代理還是虛擬網路介面接管。若需要設定環境變數,只應使用用戶端介面明確顯示的本地位址與連接埠,不要從其他教學照抄固定值。範例僅展示變數形式,不提供虛構連接埠:
export HTTP_PROXY="http://LOCAL_PROXY"
export HTTPS_PROXY="http://LOCAL_PROXY"
unset HTTP_PROXY
unset HTTPS_PROXY
診斷結束後使用 unset 清除暫時變數,避免終端機在用戶端退出後仍指向失效位址。Git、套件管理器、容器環境與整合開發工具也可能各自儲存代理設定,應逐層檢查。容器內的網路環境與主機不同,主機可存取不代表容器會自動繼承;遠端開發情境還要確認請求究竟由本機還是遠端主機發出。先確定請求的執行位置,再決定在哪一側設定網路,能避免在本機反覆修改卻始終無效。
AI 程式設計工具對長連線、終端機工作階段與輔助程序較為敏感,可進一步閱讀AI 程式設計 VPN 選擇與穩定性說明。如果應用程式透過瀏覽器登入後再回到用戶端,應同時檢查瀏覽器回呼、用戶端主程序與背景服務,確保它們使用一致的網路路徑。若只有特定帳戶失敗而其他帳戶正常,應將帳戶地區、服務策略與網路故障分開判斷,不要繼續擴大代理範圍。
Escalation and recovery
何時尋求客服:將一次故障整理成可重現工單
排錯不是無限循環。完成基礎網路確認、單一變數切換與交叉測試後,如果問題能穩定重現,繼續隨機更換設定只會破壞現場。適合提交工單的情況包括:多條線路在多個網路下出現同類連線失敗;某條線路持續異常而其他線路正常;使用者面板與不限台數、方案流量或訂單狀態顯示不一致;訂閱入口可存取但用戶端持續解析失敗;系統權限已確認,用戶端仍無法建立連線;以及同一應用程式在完整路由模式下仍穩定失敗。
工單必須包含哪些背景資訊
一份可處理的工單應先寫清楚症狀,而不是先下結論。建議描述「點擊連線後用戶端回到未連線狀態」、「連線成功後所有網域都無法解析」、「解除鎖定螢幕後所有應用程式都沒有網路」或「只有某個應用程式的登入請求失敗」。接著寫明受影響平台,平台範圍使用 Windows、macOS、iOS、Android、Linux 中實際涉及的項目;再說明目前網路類型、線路名稱、發生時段、是否每次都能重現,以及最近一次正常使用與異常之間做過哪些變更。
接著列出已完成的對照:是否更換線路、是否更換網路、其他裝置是否正常、其他應用程式是否正常、退出後重新開啟是否恢復、清除 DNS 快取是否改變結果。每一項只寫實際做過的動作,不要為了讓工單看起來完整而填入未驗證的結論。若問題與網站或 App 有關,應提供服務名稱、失敗操作與錯誤原文;若問題與訂閱有關,應提供用戶端顯示的錯誤類型與更新時間,但不要貼上真實訂閱入口。
可複製的工單格式
問題現象:
受影響平台:
目前網路:
所選線路:
受影響的應用程式或網站:
是否能穩定重現:
已完成的對照:
錯誤原文:
可提供的去識別化截圖或日誌:
截圖、日誌與隱私界線
截圖應包含用戶端狀態、線路名稱、錯誤提示與必要的系統時間背景,但應遮蓋使用者名稱以外的敏感帳戶資訊。密碼、訂閱入口、付款憑證、Cookie、授權權杖與私人通訊內容不應出現在附件中。提交日誌前先搜尋是否包含完整請求網址或帳戶欄位;若用戶端提供去識別化匯出,應優先使用該方式。無法確認日誌內容時,可以先在工單中說明可提供日誌,再由支援人員告知所需範圍。
網路診斷截圖應呈現測試條件。例如提交某個網站失敗的截圖時,同時寫明其他網站是否正常、目前是否已連線、使用哪條線路。單獨一張錯誤頁面無法區分目標服務故障、DNS、線路與瀏覽器狀態。速度問題也不應只附測速頁面,應說明真實應用程式中的表現、未連線狀態是否正常,以及切換線路後的差異。頻繁斷線則要寫明是否與鎖定螢幕、休眠或網路切換有關。
等待處理期間保持可回復狀態
提交工單後,優先使用已驗證可用的備用線路,不要繼續刪除全部設定。保留能重現故障的線路名稱與操作路徑,同時將日常使用切換到穩定候選線路。若問題出現在單一應用程式,可暫時恢復原規則並使用其他可用方式完成工作,避免為了一個應用程式修改整個系統。若問題出現在訂閱更新,而舊線路仍可用,應保留舊設定直到確認新訂閱成功匯入。
進行重大變更前記錄目前狀態,包括用戶端連線模式、系統代理是否啟用、DNS 是否由系統管理、訂閱項目名稱與可用線路。這樣即使嘗試無效,也能恢復到已知狀態。重置網路、清除用戶端資料與重新安裝屬於影響範圍較大的操作,應放在已取得權限、快取與設定問題明確證據之後。執行前確認帳戶憑證可用,並從使用者面板了解重新取得用戶端與訂閱的路徑。
恢復後進行一次完整驗證
問題看似恢復後,應重新執行原本失敗的操作,而不是只看用戶端顯示已連線。連線類問題要確認普通網頁與目標應用程式都可用;DNS 問題要確認網域解析與出口路徑恢復;速度問題要在真實用途下觀察持續表現;行動裝置問題要經過鎖定螢幕與網路切換的原觸發條件;訂閱問題要確認線路清單已更新且可連線;應用程式路由問題要確認主程序與輔助功能都能正常運作。
最後記錄真正有效的變更,並撤銷診斷期間無效的暫時設定,例如暫時代理環境變數、瀏覽器測試開關或完整路由模式。保留一份簡短結果,寫明症狀、原因邊界、有效處理方式與回復方法。下次出現相似現象時,可以先驗證同一邊界,而不是從頭試遍所有設定。若問題由線路局部異常引起,可查看全球節點並準備替代出口;若涉及訂閱與預算,可回到方案頁核對流量與週期。
46VPN 提供 60 天無理由退款。若問題經過支援流程後仍無法滿足實際使用需求,可依服務條款處理。排錯與退款是不同流程:技術工單用於確認連線、線路、用戶端與帳戶狀態,退款申請則依據條款與訂單狀態進行。將兩類需求分別說明,有助於避免技術資訊與訂單資訊混在同一份問題描述中。
Resolution checklist
故障閉環檢查
- 先定義邊界:確認是單一裝置、單一網路、單一線路、單一應用程式,還是所有環境。
- 再變更變數:每次只更換線路、網路或裝置其中一項條件,並重新測試同一操作。
- 保留證據:記錄平台、線路、時段、錯誤原文、觸發操作與已完成的對照。
- 謹慎重置:重新安裝、清除資料與重置網路放在診斷後段,執行前保留可回復狀態。
- 及時升級:問題穩定重現後提交去識別化工單,不要在現場繼續隨機修改。