跨境網路故障排查手冊

排查總綱:先判斷故障落在哪一層

排查的目標不是把每一項設定都改一遍,而是用最少的動作把問題鎖定在一段鏈路上。一次跨境存取至少要經過四段:裝置到本地網路、本地網路到線路入口、線路入口到目標網站、目標網站回傳結果。任何一段出問題,使用者看到的現象都可能是「打不開」,但處理方式完全不同。

先分清「連不上」和「連上了但慢」是兩回事。前者是鏈路建立失敗,後者是鏈路可用但品質不夠,兩者的排查路徑並不重疊,混在一起改設定,只會把問題越改越亂。還要區分兩種時間線:首次設定就失敗,多半是設定方式或平台相容問題;用了一段時間後突然失效,多半是網路環境、線路調度或帳號狀態發生了變化。時間線不同,先查的方向也不同。

四層模型:把現象對應到鏈路段

這張表的作用是讓你在三十秒內決定先動哪裡。如果現象落在「本地網路」一行,先中斷用戶端,確認本地網路本身可用——本地網路不通的情況下,任何代理設定都不會生效,繼續調用戶端只是白費時間。

三步定位法

按下面三步依序替換變數。每一步只改一個條件,結果才有參考價值;一次改三樣,即使恢復了也不知道是哪一樣起的作用。

1. 換線路

   在用戶端裡切換到另一條線路,優先切到 IEPL 專線。如果切換後恢復正常,問題集中在原線路上:記下線路名稱、所在地區與出問題的時間段,提交工單時一併附上。切換後仍然失敗,繼續第二步。

2. 換裝置

   用同一個帳號在另一台裝置上連線同一條線路。如果另一台裝置正常,問題在原裝置的用戶端或系統設定上,回到對應平台的章節自查;如果兩台裝置同時失敗,繼續第三步。

3. 換網路

   用行動網路熱點替換目前的 Wi-Fi 或寬頻,再連一次。如果熱點下恢復正常,問題在原網路的出口、路由器或電信業者鏈路上,與帳號和線路都無關。

三步全部失敗,基本可以判定不是單點故障,直接進入第九章的工單流程,不要繼續在用戶端裡反覆試。反覆重裝、反覆切換,只會把原本正常的設定一起破壞掉,給後續定位增加干擾。

排查前先記錄五項資訊

記錄不是形式主義。線路調度是動態的,同一個問題在不同時間段的表現可能不同,有記錄才能判斷規律;沒有記錄,只能憑印象描述,溝通成本會成倍上升。

• 問題發生的時間,精確到分鐘,並註明所在時區。
• 當時使用的線路名稱與所在地區,以及是否換過其他線路。
• 用戶端所在平台與系統版本(Windows / macOS / iOS / Android / Linux)。
• 錯誤訊息原文或截圖,不要只寫「打不開」。
• 已經做過的動作,例如「已切換三條線路、兩台裝置、兩個網路」。

什麼時候該找客服

下面這些情況建議直接提交工單,不必繼續自查:

• 同一帳號在兩條以上線路、兩台以上裝置、兩個不同網路下都無法連線。
• 單條線路連續失敗超過一天,而其他線路正常。
• 帳號層面的異常:無法登入、訂閱取得失敗、訂單或付款狀態與預期不符。
• 用戶端本身崩潰、反覆閃退或無法完成安裝。

反過來,下面這些情況建議先自查:只有一台裝置出問題、只有某一個網站打不開、只在某個時段變慢、換一條線路就能恢復。這些都屬於單點現象,自查往往比等待回覆更快。

完全連不上:從本地網路查到帳號狀態

「完全連不上」指用戶端點下連線後一直停在「正在連線」,或者直接提示連線失敗,任何網站都打不開。這一章按從近到遠的順序排查:裝置 → 系統 → 本地網路 → 線路 → 帳號。順序不要跳,跳著改會同時引入多個變數,最後連「改之前是什麼樣」都說不清。

先讀懂用戶端的三種狀態

用戶端的「已連線」只代表本地通道建立完成,不代表出口可用。真正能確認生效的是出口 IP 發生變化。所以第一步不是看按鈕顏色,而是開啟 IP 查詢頁,確認出口 IP 的歸屬地是否與所選線路的地區一致;不一致,說明流量並沒有真正走出去,後面所有「打不開」的判斷都不成立。

五個平台的用戶端都提供執行日誌(部分平台叫「連線日誌」)。日誌最後一行通常能看出卡在哪一步:卡在握手,多半是本地網路封鎖了連接埠或系統時間偏差;卡在認證,多半是帳號或訂閱狀態有問題;日誌裡反覆重新連線、間隔很短,多半是本地網路不穩定或網路卡在省電。

系統時間偏差是最容易被忽略的原因

連線過程依賴 TLS 握手,而 TLS 要求裝置時間與標準時間偏差在幾分鐘以內。系統時間不準,表現就是一直停在「正在連線」或者提示憑證錯誤,但使用者往往以為是線路壞了,於是持續換線路,問題依舊。

• Windows:設定 → 時間與語言 → 日期和時間,開啟「自動設定時間」。
• macOS:系統設定 → 一般 → 日期與時間,開啟自動設定。
• iOS:設定 → 一般 → 日期與時間,開啟「自動設定」。
• Android:設定 → 系統 → 日期和時間,開啟自動設定(不同廠商的選單路徑略有差異)。

修改後重新啟動用戶端再試一次。長期不連網的裝置,時間偏差可能累積到幾十分鐘,這種情況尤其要先校正時間再看別的。

本地網路與安全軟體

• 第三方防火牆或安全軟體的「網路防護」「流量監控」可能攔截通道建立,先暫時關閉再試一次。
• 檢查系統代理設定是否殘留了舊的代理位址(Windows:設定 → 網路和 Internet → 代理)。
• 路由器上的上網管控、家長監護、廣告過濾功能可能把線路入口當成可疑目標攔掉。
• 公司或學校的網路可能只放行一般連接埠,這種情況換協定或換連接埠通常可以恢復。

換線路與換協定

先切到 IEPL 專線再試一次。如果所有線路都失敗,再換協定:Trojan、VLESS、Hysteria2、Shadowsocks 之間切換,每次只換一項。某一種協定在特定網路下被攔截是常見現象,換一種協定往往立刻恢復,這不需要重新購買或重新匯入訂閱。

帳號狀態自查

• 方案是否在有效期內,流量是否已經用完(流量按開通日每月重置)。
• 訂閱網址是否被分享給其他人使用,導致登入狀態互相頂掉。
• 是否在短時間內多地重複登入,觸發了異常判定。

註冊不需要電子郵件地址,使用者名稱 + 密碼即可完成註冊,因此帳號相關的操作都在使用者面板內完成;忘記密碼走面板的找回流程,不需要額外提供其他資訊。

現象對照表

能連上但打不開網頁

這一類問題的共同點是:用戶端顯示已連線,但瀏覽器裡網頁一直在轉圈,或者提示「無法存取這個網站」。先不要動線路,按下面的順序確認流量到底有沒有走代理。絕大多數「連上了卻打不開」都停在前兩步。

「已連線」不等於「已代理」

用戶端有兩種運作方式。系統代理模式只改寫系統的代理設定,瀏覽器和遵循該設定的應用程式會走代理,其他應用程式不受影響;TUN(虛擬網路卡)模式接管全部流量,包括不識別系統代理的應用程式。如果用戶端處於系統代理模式,而瀏覽器裝了會接管代理設定的擴充功能,系統設定就會被覆蓋,表現就是用戶端說連上了、瀏覽器還是打不開。

判斷方法很簡單:開啟本服務的 IP 查詢頁,看顯示的出口 IP 歸屬地是不是所選線路的地區。不是,說明流量沒有走代理,問題在用戶端模式或瀏覽器擴充功能;是,說明代理已經生效,繼續往下看。

用命令列把問題縮小到一層

瀏覽器給出的錯誤訊息往往很籠統,命令列能直接把範圍縮小。下面三行指令分別回答三個問題:目標網站通不通、網域能不能解析、解析結果穩不穩定。

# 1. 目標網站是否可達(範例網域,替換成你實際要存取的網站)
curl -I --max-time 10 https://www.example.com

# 2. 只做 DNS 解析,看網域能不能解析出位址
nslookup www.example.com

# 3. 用指定 DNS 再解析一次,比對兩次結果是否一致
nslookup www.example.com 1.1.1.1

curl 回傳 200 或 301,說明鏈路本身是通的,問題在瀏覽器端;curl 逾時但 nslookup 有結果,問題在出口或目標網站;nslookup 本身就失敗,直接跳到第八章的 DNS 排查。三次測試要在同一個網路環境下做,否則結果沒有可比性。

分場景判斷

• 所有網站都打不開:先看 DNS 與通道是否生效,再看線路,最後看帳號狀態。
• 只有部分網站打不開:檢查分流規則裡這些網域是不是被寫進了直連,或者目標網站本身在維護。
• 只有瀏覽器打不開,其他應用程式正常:檢查瀏覽器擴充功能、瀏覽器內建的加密 DNS 設定。
• 只有一台裝置打不開:與另一台裝置比對,確認是裝置端問題而不是帳號問題。

IPv6 造成的「一半能用」

部分寬頻同時配發 IPv4 與 IPv6 位址,系統會優先使用 IPv6。如果線路只處理 IPv4,存取就可能出現「有的網站能開、有的網站一直轉圈」這種看似隨機的現象。處理方式有兩種:在用戶端裡開啟 TUN 模式,讓全部流量進入通道;或者在系統的網路設定裡暫時關閉 IPv6,再測一次比對結果。

目標網站端的問題

不要忽略目標網站本身的故障。用另一條線路、另一台裝置、另一個網路分別存取同一個網站,如果三者都失敗,而其他網站一切正常,基本可以判斷問題在目標網站一端,與本服務無關,等待對方恢復即可。

瀏覽器擴充功能與安全軟體

廣告封鎖、腳本管理、代理切換類擴充功能都會改動請求的走向。排查時先全部停用,確認恢復正常後再逐個開啟,定位到具體是哪一個擴充功能造成的影響。這一步只需要幾分鐘,卻能排除掉相當一部分看似複雜的問題。

訂閱更新失敗:連結、快取與狀態檢查

訂閱是用戶端取得線路清單的通道。更新失敗時,用戶端通常仍保留上一次成功取得的節點,所以現象可能是「能連,但節點清單是舊的」,也可能直接提示訂閱更新失敗。先看屬於哪一種,再決定處理方式——前者往往不影響使用,後者需要立刻處理。

先確認三件事

• 裝置目前能正常上網。更新訂閱本身需要一次正常的網路請求,斷網狀態下點更新,報錯是必然的。
• 系統時間是自動設定的。時間偏差會讓請求在 TLS 階段失敗,錯誤提示卻往往與網路有關。
• 方案在有效期內,流量沒有用完(流量按開通日每月重置)。

三項都正常再往下看。這三項涵蓋了訂閱更新失敗裡最常見的原因,先排除掉能省下大量時間。

訂閱網址的形態

訂閱網址是一段帶憑證的連結,用戶端透過它取得線路清單。下面只是格式示範,真實網址請登入使用者面板後在「總覽」頁複製。

# 訂閱網址範例:僅示範格式,不是可用的真實網址
https://example.com/sub?token=YOUR_TOKEN

# 部分用戶端支援依類型回傳不同格式(範例)
https://example.com/sub?token=YOUR_TOKEN&flag=clash

訂閱網址與帳號綁定,包含存取憑證,等同於密碼。不要傳到群組、不要截圖外傳、不要貼進公開的設定檔或程式碼儲存庫。需要在多台裝置上使用時,在每台裝置上分別匯入同一個網址即可,不需要額外申請,也不受裝置數限制。

兩種匯入方式

連結匯入是首選。手動新增節點是備用方案:在用戶端裡逐條填寫伺服器端位址、連接埠、協定與憑證。手動新增的節點不會隨後續更新變化,如果發現某條手動線路連不上,先換回連結匯入的方式確認是不是線路本身調整了。

更新失敗的常見原因

更新頻率與時機

建議每週更新一次;換線路、換地區或感覺速度下降時,先手動更新一次再看,不要急著改協定。更新後節點清單會依地區重新分組,如果發現某個地區的節點數量變化,通常是伺服器端在做線路調整,過一段時間再更新一次即可。

速度慢與晚高峰卡頓

「慢」是一個結果,不是原因。先量出瓶頸在哪一段,再決定改什麼。整章按「先測本地、再測出口、最後調線路」的順序展開;順序反過來做,很容易把本地頻寬的問題誤判成線路問題,換了一圈線路也沒改善。

先量本地頻寬

中斷用戶端,先測一次本地寬頻的實際速度,記下結果;連線用戶端後再測一次。兩次結果的差距,才是代理鏈路帶來的損耗。如果本地寬頻本身的數值就不高,那麼換任何線路都不會變快,這時應該先聯絡寬頻業者。

測速時注意兩點:兩次使用同一個測速服務,結果才有可比性;關掉背景的下載、雲端硬碟同步與系統更新,它們會佔滿頻寬,讓結果嚴重失真。測速結果本身受伺服器端負載影響,單次結果不說明問題,連續測三次取中間值更可靠。

線路類型的差別

三類線路都涵蓋在 110+ 國家 / 250+ 線路的範圍內,用戶端裡可以直接依地區與類型篩選。晚高峰優先 IEPL 專線,是因為專線通道不經過公共網際網路的國際出口,受整體壅塞的影響更小;直連線路路徑最短,但恰恰最容易在高峰時段被公共出口的壅塞拖慢。

協定與開銷

協定決定封裝方式與額外開銷。Hysteria2 基於 QUIC,在封包遺失較多的網路裡更穩,適合線路品質波動大的場景;Trojan 與 VLESS 走 TLS,相容性好,適合大多數日常使用;Shadowsocks 開銷小,在舊裝置上表現更好。協定之間可以隨時切換,切換後需要重新連線一次,不需要重新匯入訂閱。

裝置端的瓶頸

• Wi-Fi 頻段:2.4GHz 涵蓋範圍廣但速度上限低,近距離優先連線 5GHz。
• 舊裝置的加密效能:較舊的處理器在加解密上開銷更大,表現為網頁能開但影片卡。
• 背景工作:系統更新、雲端硬碟同步、遊戲平台下載都會持續佔用頻寬。
• 路由器效能:入門級路由器在多裝置同時使用時,轉發能力可能比寬頻更早到達瓶頸。

晚高峰的應對順序

按下面的順序依序嘗試,每次只改一項,改完立刻複測。

1. 切到 IEPL 專線

   優先選擇距離目標網站較近的地區。同一地區有多條專線時,逐條試,記錄哪一條在高峰時段更穩。

2. 切換協定

   在 Trojan、VLESS、Hysteria2、Shadowsocks 之間換一種,尤其是網路封包遺失明顯時,基於 QUIC 的協定通常改善更明顯。

3. 檢查分流

   讓中國大陸的網站走直連,減少通道內的無效流量;同時確認沒有規則把目標網站錯誤地放行到直連。

4. 確認不是本地問題

   換一台裝置、換一個網路再測一次。如果只有原裝置慢,問題在裝置或本地網路,與線路無關。

時段與建議

如果只在特定時間段變慢,而且換線路後明顯改善,基本可以確認是國際出口壅塞,而不是帳號或裝置的問題。體育直播這類對延遲更敏感的場景,選線思路可以參考 體育直播 VPN 推薦 一文。

頻繁斷線與行動端後台掉線

斷線分兩種:一種是真的中斷,用戶端狀態回到未連線;另一種是「假斷線」,用戶端顯示已連線,但流量停了。兩者的排查方向完全不同,先分清楚再動手,否則容易在錯誤的方向上折騰半天。

先分清真斷線與假斷線

• 真斷線:用戶端狀態回到未連線,日誌裡能看到中斷記錄。方向是本地網路、網路卡節能、鏈路品質。
• 假斷線:狀態仍是已連線,但網頁打不開。方向是保活機制、DNS、用戶端行程被系統回收。

判斷方法:斷線發生時立刻開啟 IP 查詢頁。能開啟,說明通道還在,是應用層的問題;打不開,說明通道確實斷了。這一步只需要幾秒鐘,卻能決定後面往哪個方向查。

桌面端:網路卡節能與電源計畫

• Windows:裝置管理員 → 網路介面卡 → 內容 → 電源管理,取消勾選「允許電腦關閉這個裝置以節省電源」。
• Windows:控制台 → 電源選項,把計畫改為「高效能」,避免處理器與網路卡頻繁降頻。
• macOS:系統設定 → 電池,關閉「低耗電模式」,或在使用時接上電源。

這三項是桌面端斷線最常見的來源。無線網路卡在閒置時進入省電狀態,恢復需要時間,表現就是每隔一段時間卡一下或者直接中斷。

行動端:後台被系統回收

iOS 與 Android 都會在記憶體吃緊或省電模式下回收背景行程。代理行程被回收,表現就是切到別的應用程式待一會兒再回來,連線已經斷了,而且沒有任何提示。

• iOS:設定 → 一般 → 背景 App 重新整理,允許用戶端重新整理;同時關閉低耗電模式。
• Android:設定 → 應用程式 → 用戶端 → 電池,選擇「不受限制」或加入省電白名單。
• Android:在最近使用的應用程式清單裡鎖定(上鎖)用戶端,避免被一鍵清理。
• 關閉系統內建的「智慧省電」「深度睡眠」類功能對用戶端的限制。

網路切換時的重連

從 Wi-Fi 切到行動網路、或從一個 Wi-Fi 漫遊到另一個時,通道需要重新建立。部分系統會等待十幾秒才恢復,這屬於正常現象;如果一直不恢復,手動中斷再連線一次即可,不需要重新啟動裝置。頻繁在兩種網路之間來回切換時,建議在穩定下來之後再開始長時間的任務。

路由器與數據機

長時間開機的路由器可能出現工作階段表滿、記憶體佔用高等問題,表現為整個網路間歇性卡頓,而不只是代理連線中斷。斷電重新啟動一次數據機與路由器,再觀察一天;如果斷線頻率明顯下降,問題就在本地網路裝置上。

雙頻合一與漫遊

部分路由器把 2.4GHz 與 5GHz 合併成同一個名稱,裝置在頻段之間來回切換時連線會短暫中斷。家裡有多台路由器時,漫遊設定不當也會造成同樣的現象。可以先把兩個頻段拆成不同的名稱,固定連線其中一個,觀察斷線是否減少。

記錄規律比反覆重裝有用

記錄斷線的間隔、持續時間、當時使用的線路與網路類型。固定間隔的斷線通常是保活或節能設定造成的;無規律的斷線更可能是鏈路品質或本地網路問題。Android 裝置的省電策略差異較大,從安裝到加入白名單的完整流程可以參考 Android VPN 從零開始。

某個 App 走不了代理

瀏覽器正常,但某個桌面軟體、遊戲或命令列工具連不上,通常不是線路問題,而是這個應用程式沒有進入代理。原因集中在三點:代理模式、分流規則、應用程式本身的網路行為。按這三點依序檢查,基本都能定位。

代理模式決定誰被接管

分流規則的比對順序

分流規則依網域、IP、應用程式名稱依序比對,先比對到的先生效。如果目標網域被寫進了直連規則,或者被某個更靠前的規則提前命中,這個應用程式就不會走代理——即使它在用戶端的應用程式清單裡。

排查方法:開啟用戶端的連線日誌,操作一次出問題的應用程式,看日誌裡有沒有出現對應的連線記錄。沒有記錄,說明流量根本沒有進入用戶端;有記錄但標註為直連,說明規則把它放行了;有記錄且走了代理,說明問題在應用程式本身或目標網站。

常見誤設

• 規則清單裡手動新增過「直連」項目,後來忘了刪除。
• 只代理了部分行程,應用程式不在清單裡。
• 應用程式自己走獨立的網路堆疊,部分下載工具、遊戲平台會繞過系統代理。
• 應用程式優先使用 IPv6,而線路只處理 IPv4。

遊戲與 UDP 應用程式

遊戲類應用程式大量使用 UDP,而系統代理通常只處理 TCP 流量,所以「瀏覽器正常、遊戲進不去」是典型現象。這類應用程式需要在用戶端裡開啟 TUN 模式,並確認用戶端支援 UDP 轉發;開啟後如果延遲反而升高,再換回延遲更低的地區節點。

AI 工具類應用程式

ChatGPT、Claude、Gemini 等 AI 工具對鏈路穩定性更敏感:它們大多是長連線,中途一旦中斷就需要重新建立工作階段,表現是「登入後一直轉圈」或者「回答到一半中斷」。遇到這種情況,優先切到 IEPL 專線,再確認應用程式是否在代理範圍內。更細的做法整理在 ChatGPT 加速 頁面。

驗證是否生效

最直接的驗證方式:在出問題的應用程式裡存取一個只有走代理才能開啟的位址,或者用應用程式內建的網路診斷查看出口位址。也可以用本服務的 IP 查詢頁確認目前出口。桌面端全域代理與分流之間的取捨,以及開機自動啟動的設定方式,整理在 Windows VPN 推薦 一文裡。

DNS 異常與出口 IP 自查

DNS 負責把網域轉譯成 IP 位址。DNS 出問題時,現象很有迷惑性:網頁打不開,但通訊類軟體正常;或者同一台裝置上有的網域能解析、有的不能。先分清屬於哪一類,再決定改什麼。

先分清三類問題

三類問題的處理方式不同:解析失敗多半是本地 DNS 服務不可用;解析異常通常是解析路徑上有干擾;DNS 洩漏則是設定問題,需要把解析請求收回通道內。

用 IP 查詢頁做三項自查

• 出口 IP 的歸屬地是否與所選線路的地區一致。
• 是否出現 DNS 洩漏提示。
• 中斷用戶端前後各查一次,比對兩次結果是否不同。

查詢入口在 我的 IP 頁面,不需要安裝任何額外工具,也不需要命令列基礎。三項結果記下來,提交工單時一併附上即可。

用戶端裡的 DNS 設定

優先使用線路內建的 DNS 解析,讓解析請求隨通道一起出境。如果手動把 DNS 改成了公共位址,解析請求可能繞過通道回到本地電信業者,既影響解析結果,也會讓解析記錄暴露在通道之外。除非有明確的理由,否則不要手動改動用戶端下發的 DNS 設定。

瀏覽器內建的加密 DNS

部分瀏覽器內建了加密 DNS(DoH),開啟後會繞過系統與用戶端的 DNS 設定。如果只在瀏覽器裡出現解析異常,先把這個選項關掉,或者改成「跟隨系統」,再測一次。這一項經常被忽略,卻能解釋「其他應用程式都正常,只有瀏覽器打不開」這類現象。

命令列排查

# 用系統預設 DNS 解析
nslookup www.example.com

# 用指定 DNS 解析,比對兩次結果是否一致
nslookup www.example.com 1.1.1.1

# Windows:清空本地 DNS 快取
ipconfig /flushdns

# macOS:清空本地 DNS 快取
sudo dscacheutil -flushcache

兩次解析結果不一致,說明解析路徑上存在干擾;先清快取,再把用戶端的 DNS 設定恢復為預設值,然後重新連線一次。快取清理後第一次解析通常稍慢,屬於正常現象。

DNS 正常但網頁仍然打不開

如果解析正常、出口 IP 也正確,但網頁依然打不開,說明問題不在 DNS。回到第三章按「分場景判斷」繼續排查,重點看分流規則與瀏覽器擴充功能這兩項。

裝置數、帳號共享與工單提交

這一章處理帳號層面的問題,以及前面八章都排查完之後該怎麼做。帳號類問題的特點是:本地怎麼改都不會變好,只有從帳號端確認才能定位。

不限裝置數意味著什麼

VPNPF 的方案不限裝置數:同一帳號可以在 Windows、macOS、iOS、Android、Linux 上同時在線,不需要為每一台裝置單獨購買,也不需要數著裝置數量使用。換新裝置時,直接在新裝置上匯入訂閱即可。

不少服務按裝置數計費,超過數量就會提示「裝置數超限」並要求升級方案。本服務的方案沒有這個限制,所以你在自己的裝置之間切換時,不需要擔心裝置數問題。如果遇到登入後被頂下線的情況,更多是帳號共享造成的,而不是裝置數限制。

帳號共享會帶來什麼

訂閱網址與帳號綁定,等同於帳號憑證。把訂閱網址分享出去,等於把帳號交給別人使用。多人共用同一個帳號會帶來三個後果:同一時間的連線數被大量佔用,自己用的時候反而變慢;登入狀態互相頂掉,頻繁要求重新登入;出現異常登入記錄時,無法判斷來源。

如果需要給家人或同事使用,建議單獨註冊帳號,而不是共用同一個訂閱網址。註冊不需要電子郵件地址,使用者名稱 + 密碼即可完成,給家裡人單獨開一個帳號的成本很低。

這些情況必須提交工單

• 帳號無法登入,找回流程也走不通。
• 訂閱取得失敗,且換裝置、換網路後仍然失敗。
• 訂單或付款狀態與實際情況不符。
• 需要申請退款(60 天無條件退款)。
• 按本手冊前八章排查完,問題依然存在。

工單要附的資訊

資訊給得完整,通常一輪就能定位;資訊給不全,一來一回就要多花半天。按下面的清單整理,直接複製進工單即可。

1. 帳號資訊

   註冊時使用的使用者名稱。不要提供密碼,工單裡不需要密碼,也不會有人向你索取密碼。

2. 問題發生的時間

   精確到分鐘,並註明時區。時間點能幫助判斷是線路調整還是本地網路波動。

3. 線路名稱與地區

   出問題時使用的線路名稱、所在地區,以及是否換過其他線路、換過之後結果如何。

4. 用戶端與系統

   使用的平台(Windows / macOS / iOS / Android / Linux)與系統版本,以及用戶端的版本資訊。

5. 錯誤訊息原文或截圖

   直接複製用戶端的錯誤訊息文字,或附上一張包含完整錯誤資訊的截圖,不要只描述「打不開」。

6. 已經做過的排查

   例如「已切換三條線路、兩台裝置、兩個網路,現象一致」。這一項能省掉一輪來回確認。

提交之後

工單入口在使用者面板內,登入後即可提交與查看進度。提交前建議先在本手冊裡檢索對應症狀章節,大部分問題可以在自查階段解決。付款方式支援支付寶、微信與 USDT,訂單相關的問題在工單裡附上付款時間與金額即可,不需要提供付款憑證截圖以外的敏感資訊。