連線故障排解手冊

01 · 定位

先判斷問題出在哪一層

連線失敗很少是單一原因。把可能出問題的地方分成三層，排查會快很多：第一層是裝置本身——用戶端設定、系統時間、防火牆、省電策略；第二層是本地網路出口——家用寬頻、公司網路、公共 Wi-Fi 對協定與連接埠的限制；第三層才是線路與帳戶——線路壅塞、訂閱到期、流量用盡。三層的處理方式完全不同，先定位在哪一層，再談解決辦法。

順序比努力重要。很多人一遇到連不上就重新安裝用戶端，結果把介面上那句最關鍵的提示原文弄丟了。重新安裝只在設定檔確實損壞時有用，其餘情況下它只是把排查時間歸零。

還有一點值得說明：三層之間會互相影響。裝置效能不足會讓線路看起來「慢」，本地 DNS 設定錯誤會讓「連不上」和「連得上但打不開」同時出現。所以每章末尾都會寫清楚「什麼情況該回到上一層」，不必在一章裡死磕到底。

三個三十秒動作

不需要任何工具，三個動作就能把範圍縮掉一大半。

1. 關掉用戶端，直接打開一個普通網頁。打不開說明本地網路已經斷了，先解決網路，別在用戶端裡找原因。
2. 保持裝置和網路不變，換一條線路重連。能連上說明是單條線路的問題，去節點線路挑一條同地區、不同類型的備用線路。
3. 換一台裝置，或把同一台裝置換到另一個網路。換裝置能連上，問題在原裝置的本地設定；換網路能連上，問題在原網路的出口策略。

把現象記下來，而不是急著重新安裝

提交工單時最有價值的資訊不是「連不上」三個字，而是下面這幾項。提前記下來，就算最後要找人幫忙，也能省掉一輪往返。

• 出問題的時間點與時區，是否集中在某個時段
• 平台與系統版本（Windows / macOS / iOS / Android / Linux）
• 用戶端介面上提示的原文，截圖或逐字抄下來
• 當時選中的線路名稱與線路類型
• 是否在路由器上使用，路由器下掛了幾台裝置
• 出問題前改過什麼：換過 DNS、裝過安全軟體、切換過分流模式

什麼情況可以直接跳到最後一章

有兩種情況不用逐章排查：一是面板上訂閱已過期或流量已用盡，屬於帳戶問題，直接看「帳戶與工單」；二是同一帳戶在多台裝置上同時出現完全相同的現象，且換網路、換線路都無效，這通常是帳戶端的工作階段狀態問題，提交工單比繼續嘗試更快。除此之外，其餘症狀都建議按章節順序走一遍，因為很多現象是同一個原因的不同表現。

02 · 連線建立

完全連不上

用戶端按下連線後一直轉圈、跳出錯誤，或剛連上就斷開，都歸到這一類。先看用戶端給出的提示屬於哪一類，四類提示的處理路徑完全不同。

先分清四種「連不上」

帳戶與流量

登入使用者面板，確認兩件事：訂閱是否在有效期內、流量是否還有餘量。月訂閱的流量依開通日每月重置，不是日曆月；流量包用完為止、永久不會過期，所以包裡剩餘的額度不會因為月份切換消失。面板上會分別顯示兩類額度的剩餘量，以面板顯示為準。

如果面板顯示訂閱有效、流量充足，用戶端卻提示認證失敗，先登出再重新登入，讓用戶端重新取得一次帳戶資訊。仍然失敗，再提交工單。流量包與月訂閱怎麼搭配更划算，流量包和包月怎麼選裡有依用量估算的算法。

系統時間

加密連線依賴憑證驗證，而憑證驗證的第一道關卡是時間。系統時間與真實時間相差超過幾分鐘，握手就會失敗，提示往往與「網路不通」很像，容易誤判。Windows、macOS、iOS、Android 都提供自動對時開關，打開它，再手動同步一次。

# Linux：查看時間、時區與同步狀態
timedatectl status

# 開啟自動對時並立即同步一次
sudo timedatectl set-ntp true

本地網路出口

公司網路、校園網路、部分飯店與公共 Wi-Fi 會對 UDP 與非常用連接埠做限制。判斷方法很簡單：同一台裝置切到另一條網路再連一次。原網路不能連、另一條網路能連，問題就在原網路的出口策略上。這種情況可以嘗試在用戶端裡切換傳輸協定，從 UDP 系列切到 TCP 系列，或換一個更常見的連接埠。

防火牆與安全軟體

桌面端的安全軟體、系統內建防火牆，以及某些「網路最佳化」工具會攔截虛擬網卡。表現是用戶端顯示已連線，但系統沒有新增虛擬網卡，或連線瞬間被切斷。處理方式：把用戶端加入白名單，允許它建立虛擬網卡、修改 DNS 設定；排查期間可以暫時關閉第三方安全軟體做一次對照測試，測完立即恢復。

路由器與多裝置

在路由器上設定時，用戶端不參與，問題通常出在路由器的韌體、時間同步，以及規則檔案的相容性上。依序確認：路由器本身能正常上網、路由器時間已同步、訂閱成功取得規則、規則格式與韌體相符。四項都通過仍然連不上，把路由器的型號與韌體類型記下來，提交工單時一併附上。

03 · 解析與分流

連得上但打不開網頁

用戶端顯示已連線、出口地區也切換了，瀏覽器卻一直轉圈，或只有一部分網站能打開。這一類問題的共同點是：通道已經建立，卡住的是通道之上的解析與分流。

先分清三種表現

DNS 洩漏與 DNS 失敗的差別

DNS 洩漏指查詢沒有走通道，暴露了本地 DNS；DNS 失敗指查詢根本沒有傳回結果。兩者都會表現為「打不開網頁」，但處理方式不同：洩漏要改用戶端的 DNS 接管設定，失敗要先看系統 DNS 是否可達。

# Windows：查看 DNS 設定並清除快取
ipconfig /all
ipconfig /flushdns

# macOS：清除 DNS 快取
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux（systemd-resolved）：查看狀態並清除快取
resolvectl status
sudo resolvectl flush-caches

# 通用：查詢某個網域解析到哪個位址
nslookup example.com

如果 nslookup 傳回的是本地電信業者或路由器的位址，而用戶端裡已經開啟 DNS 走通道，說明查詢被系統繞過了。處理方式：在用戶端裡把 DNS 設定為由通道接管；或手動指定一個可用的公共 DNS，例如 1.1.1.1、8.8.8.8，改完清除一次系統快取。

分流模式與規則

規則模式下，用戶端依網域清單決定走代理還是直連。目標網站不在清單裡、或清單版本過舊，就會走直連。判斷方法：把模式臨時切成全域，如果全域下能打開、規則下打不開，問題就在規則上。處理方式是更新規則，或把該網域加入自訂規則。

分流規則還有一個容易忽略的邊界：同一個網域可能同時被「直連清單」和「代理清單」命中，最終結果取決於用戶端的優先順序。規則寫得多不等於寫得好，衝突規則會讓排查變得很難。規則盡量保持精簡，只補真正需要的項目。

MTU 與大型封包丟棄

通道會額外封裝一層標頭，實際可用的最大傳輸單元比實體鏈路小。MTU 設定偏大時，小請求能過、大回應被丟棄，表現為頁面骨架出來了但圖片和樣式載入不出來，或登入類操作一直轉圈。把 MTU 調小一級再試，是成本最低的驗證方式。

04 · 吞吐量

速度慢

慢是最難量化的一類。先建立一個基準：不掛代理時本地網路的實際速度是多少，掛上之後掉了多少。沒有基準，「慢」只是主觀感受，換十條線路也未必有改善。

先測基準，再談最佳化

在關閉用戶端的狀態下，用同一台裝置、同一個位置測一次本地頻寬，記錄下來。然後連上代理，用同一個測速方式再測一次。兩次結果的差距，才是代理鏈路帶來的損耗。如果本地本身頻寬就很低，換線路不會有明顯改善——瓶頸根本不在線路上。

測速本身也有講究。測速伺服器的位置會顯著影響結果：測速節點在本地、代理出口在境外，測出來的數字反映的是「本地到本地」，不是真實跨境速度。更接近實際體驗的做法是打開日常使用的網站，看首屏時間、圖片載入、影片起播這三項。

單執行緒與多執行緒

單執行緒下載反映單條連線的品質，多執行緒下載反映總頻寬。單執行緒慢、多執行緒正常，說明線路對單一連線的限速較嚴，適合多工平行，不適合大檔案單執行緒下載。多執行緒也慢，說明瓶頸在鏈路總頻寬或本地出口。判斷時用同一個檔案、同一個時段各測一次，才有可比性。

線路類型的影響

直連線路路徑最短，但經過的公網節點多，尖峰時段容易受國際出口壅塞影響；中轉線路中間多一跳，路徑更可控；IEPL 專線走獨立通道，延遲與抖動更穩定，成本也更高。同一個地區可能同時存在三種類型的線路，速度表現差別很大，值得逐條試過去。節點線路頁依地區列出每條線路的類型，選線時可以對照。

裝置與 Wi-Fi

加密與解密要消耗 CPU。老舊裝置、低功耗模式下的筆電、背景跑滿的程式，都會讓實際吞吐低於線路能力。判斷方法：換一台效能更好的裝置連同一條線路對比。Wi-Fi 方面，2.4GHz 頻段的實際吞吐遠低於 5GHz，隔牆之後掉得更快，有線連線是最穩定的對照。

只有特定網站慢

如果只有某個網站慢，其餘正常，問題多半不在線路上。CDN 調度會依出口 IP 分配節點，出口地區選得遠，分配到的 CDN 節點也遠。把出口地區換成離目標網站服務區更近的一個，往往比換線路更有效。覆蓋 100+ 國家 / 220+ 線路的規模，意味著大多數目標服務都能找到地理上更近的出口。

05 · 時段

尖峰時段卡頓

如果問題只在固定時段出現——白天正常、晚上卡——那它不是隨機故障，而是有規律的壅塞。中國大陸的家用寬頻與國際出口在傍晚到夜間承載量最高，跨境鏈路的延遲與封包遺失都會上升，直連類線路受影響最明顯。

為什麼尖峰時段會更明顯

跨境鏈路要經過國際出口，出口頻寬是共享資源。尖峰時段家用寬頻同時在線的使用者最多，出口的排隊延遲上升，封包遺失率也跟著上升。封包遺失對傳輸的影響是疊加的：一次遺失會觸發重傳與壅塞視窗收縮，實際吞吐下降的幅度遠大於遺失率本身的百分比。這就是為什麼尖峰時段「只是稍微卡一點」在體感上卻是「影片一直轉圈」。

先確認時間規律

連續幾天在同一線路、同一時段做記錄：連線是否正常、打開網頁要幾秒、影片緩衝幾次。三天的記錄足以看出規律。如果卡頓與時間無關，回到「速度慢」那一章；如果卡頓只在某一條線路上出現，問題在線路本身，換線路即可。

線路類型的選擇

尖峰時段的表現與線路類型高度相關。直連線路走公網，壅塞時抖動明顯；中轉線路在中間節點做了收斂，穩定性好一些；IEPL 專線走獨立通道，受公網壅塞影響最小。預算允許時，尖峰時段切到專線類線路是最直接的改善方式。

出口地區的選擇

同一個網站在不同出口地區的回應差別很大。亞洲方向的線路在尖峰時段的延遲通常低於跨太平洋方向。如果目標服務在多個地區都有節點，優先選地理上更近的那個出口；如果目標服務只在某一個地區有節點，那就只能在這個地區裡挑線路類型。

使用習慣上的調整

• 把大檔案下載、系統更新安排在離峰時段
• 影片畫質從自動改為固定檔位，避免位元率反覆切換造成反覆緩衝
• 同時觀看的裝置越多，單台分到的頻寬越少——不限台數不等於不限總頻寬
• 遊戲類應用優先看延遲與抖動，而不是峰值頻寬

直播與賽事情境

體育直播對延遲與同時連線數更敏感。開賽前十分鐘是連線建立的高峰，提前連好、提前打開播放頁，比開賽後臨時切換線路更穩。賽事期間的選線思路在體育直播線路對比裡有更細的對照。

06 · 穩定性

頻繁斷線與行動端背景斷線

斷線分兩種：連線被主動斷開，和連線還在但應用層沒有流量。前者用戶端會顯示斷開重連，後者看起來一直連著、實際什麼都不通。兩種的處理方式完全不同。

固定間隔斷線

每隔固定時間斷一次，通常與心跳逾時或閒置逾時有關。中間設備會清理長時間無流量的工作階段表項目，用戶端認為連線還在，設備那邊已經忘了這條工作階段。處理方式：在用戶端裡開啟或縮短心跳間隔；或讓連線保持一點輕量的背景流量。

隨機斷線

沒有規律的斷開，多半是鏈路抖動。判斷方法：斷線時立刻看用戶端狀態。顯示「已連線但無流量」，問題在鏈路；顯示「已斷開」，問題在本地網路或虛擬網卡。Wi-Fi 訊號弱、路由器負載高、電信業者線路抖動都會造成這一類。

桌面端休眠喚醒

筆電闔上上蓋休眠後喚醒，虛擬網卡可能沒有重新接管流量，用戶端顯示已連線但實際不通。斷開重連一次即可恢復。如果每次喚醒都要手動重連，檢查用戶端的開機自動啟動與網路變更時自動重連選項。

路由器下的工作階段表

路由器要維護 NAT 工作階段表，表滿了新連線就建不起來，表現為「網路還在、但打不開新頁面」。入門路由器的工作階段表容量有限，裝置一多、同時連線一高就容易觸頂。重新啟動路由器能暫時緩解，長期方案是減少同時連線的裝置，或換一台記憶體更大的路由器。

行動端背景斷線

iOS 與 Android 都會限制背景應用程式的網路活動。切到背景一段時間後，系統可能回收 VPN 設定或暫停用戶端程序，回到前景時顯示重新連線中。這是系統策略，不是線路故障。

• iOS：確認 VPN 設定裡的隨選連線已開啟、關閉該用戶端的低耗電模式限制、允許背景 App 重新整理。
• Android：在電池最佳化裡把用戶端設為不受限制；關閉廠商省電策略對該應用程式的清理；允許背景活動。
• 通用：不要用「清理背景」的方式關閉用戶端，很多系統會連同 VPN 設定一起停掉。

07 · 設定檔取得

訂閱更新失敗

訂閱更新的本質是用戶端向伺服器端取得一份設定檔。失敗的原因集中在三個環節：取得時沒有走代理、訂閱位址失效、用戶端快取了舊設定。依這個順序查，絕大多數情況一輪就能定位。

先確認取得路徑

很多用戶端在更新訂閱時不走代理，直連去取得。如果訂閱位址在目前網路下不可達，更新就會失敗。處理方式：先把用戶端切到全域模式，或讓更新請求走已建立的通道，再點更新。更新成功後再切回規則模式。

訂閱位址與憑證

訂閱位址裡帶著身分資訊，等同於密碼。位址一旦被重設或過期，更新會傳回錯誤。在使用者面板裡重新取得一次訂閱位址，替換用戶端裡的舊位址。

# 範例：訂閱位址的形態（範例值，不是真實位址）
https://example.com/sub?token=YOUR_TOKEN

上面的位址只用於說明形態。真實的訂閱位址請從使用者面板取得，不要複製網路上流傳的範例，也不要把自己的位址貼到公開場合。

用戶端快取

更新成功但線路清單沒變，通常是用戶端用了快取。清除快取或刪除訂閱後重新匯入，能強制重新整理。部分用戶端需要手動點「全部更新」才會重新取得規則，只更新節點不會更新分流規則。

路由器上的更新

路由器環境裡，更新失敗常見於三個原因：路由器時間未同步導致憑證驗證失敗、DNS 無法解析訂閱網域、儲存空間不足導致寫入失敗。逐項排除：先對時，再換 DNS，最後看儲存空間。

訂閱格式與用戶端相容性

同一條訂閱位址，在不同的用戶端裡可能需要不同的格式。格式不相符時，用戶端要嘛提示解析失敗，要嘛匯入成功但線路清單是空的。遇到這種情況，先在面板確認訂閱的格式選項，再在用戶端裡選擇對應的匯入方式。分不清格式時，優先使用用戶端預設推薦的那個。

08 · 分流接管

某個 App 走不了代理

瀏覽器正常、某個應用程式卻連不上，說明通道本身是通的，問題出在這個應用程式的流量沒有被接管，或被接管後解析失敗。

先做全域對照

把用戶端切成全域模式，再打開同一個應用程式。全域下正常，說明規則沒有涵蓋這個應用程式的網域；全域下也不正常，說明應用程式沒有走虛擬網卡，或它有自己的網路實作。

系統代理與虛擬網卡

系統代理只對會讀取系統代理設定的應用程式生效。很多應用程式——尤其是遊戲、部分桌面用戶端、命令列工具——不讀系統代理，只走虛擬網卡。用戶端需要開啟 TUN 模式或虛擬網卡模式，才能接管這類流量。

應用程式內建的網路實作

• 自帶 DNS 的應用程式：繞過系統 DNS，直接向固定位址查詢，分流規則可能判錯。
• 硬編碼 IP 的應用程式：不經過網域解析，依網域寫的規則命中不了。
• 使用 QUIC 的應用程式：走 UDP，部分網路會限制，表現為連線建立但載入不出來。
• 走獨立協定的用戶端：需要單獨設定代理，或強制走虛擬網卡。

分應用程式代理

部分用戶端支援依應用程式分流：指定哪些應用程式走代理、哪些直連。規則寫反了會出現「該走的不走、該直走的不直走」。檢查清單裡目標應用程式是否在代理一側，改完重新啟動一次應用程式再測。

命令列工具與環境變數

命令列工具通常只認環境變數，不讀系統代理。在終端機裡設定一次，再執行需要連網的命令。

# 連接埠以用戶端實際監聽的為準
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890

# 驗證出口：傳回值應與目前線路的出口地區一致
curl -s https://example.com/ip

驗證是否真的走了代理

在應用程式裡打開一個查詢出口位址的頁面，看傳回的位址是不是線路的出口。這一步能確認流量到底有沒有被接管。更完整的自我檢查方法在連上後怎麼驗證生效裡。

09 · 帳戶與人工

帳戶、裝置與工單提交

前面八章處理的是技術故障。這一章處理帳戶層面的問題，以及確實需要人工介入時該怎麼做。

不限台數的含義

本站方案不限台數，不依裝置數量計費。同一個帳戶可以同時安裝在 Windows、macOS、iOS、Android、Linux 上，不需要為第二台裝置再買一份。不限台數指的是裝置數量，不等於不限總頻寬：同一時間在線裝置越多，單台分到的頻寬越少。

路由器與共用

在路由器上設定時，路由器算一台裝置，它後面掛的所有裝置共用這條連線。家庭情境下這是最省事的做法，但要注意路由器的效能：入門路由器的加密吞吐有限，裝置一多就容易成為瓶頸。判斷方法很簡單：把用戶端直接裝在電腦上對比，如果直連明顯更快，瓶頸就在路由器。

裝置數量相關的提示怎麼理解

本服務不限台數，正常情況下不會因為裝置數量被拒絕。如果某個用戶端彈出與裝置數量有關的提示，先登出再重新登入，讓用戶端重新取得帳戶資訊；提示仍然存在，截圖後提交工單，並註明出現提示的用戶端與時間。

流量與到期

月訂閱的流量依開通日每月重置，不是日曆月；中途升級方案時，差額折算為剩餘天數。流量包用完為止，永久不會過期，不受月份切換影響。兩種額度在面板上分別顯示，續訂前先看清楚是哪一種額度先用完。

帳戶憑證的保管

註冊只需要使用者名稱與密碼，無需電子郵件信箱，所以帳戶憑證就是這兩項。這也意味著沒有信箱可以走找回流程，密碼務必自行保管，不要與訂閱位址一起放在公開的地方。方案等級與流量包的對應關係見方案價格，付款方式支援支付寶 / 微信 / USDT。

退款

30 天無理由退款。申請入口與所需資訊見退款政策，提交時附上訂單時間與方案名稱，核對會更快。

什麼情況該找客服

• 換過至少三條不同地區的線路、換過網路、切換過協定，仍然完全連不上
• 面板顯示訂閱有效、流量充足，用戶端始終提示認證失敗
• 訂閱更新在多個網路下都失敗
• 某條線路連續多天在固定時段無法使用
• 帳戶相關的計費、退款、方案變更問題

工單要附什麼

一條資訊完整的工單，通常一輪就能定位問題。附上這些：

• 出問題的時間點與時區
• 平台與系統版本
• 用戶端介面提示的原文，截圖或文字
• 當時選中的線路名稱與線路類型
• 已經做過的排查動作與結果
• 是否在路由器上使用，路由器下掛幾台裝置

問題現象：連線後瀏覽器打不開網頁，用戶端顯示已連線
發生時間：2026-10-20 21:30 (UTC+8)
平台：Windows / 用戶端目前版本
目前線路：日本 · 東京（中轉）
已排查：切換全域模式無效；更換 DNS 後仍失敗；
        改用新加坡線路可正常開啟
補充：路由器下掛三台裝置

不要附上完整的訂閱位址、密碼或其他憑證。需要說明帳戶時，提供使用者名稱即可。

提交之前先查一次

很多問題在幫助中心裡已有現成答案，尤其是計費與方案相關的那一類。查過之後再提工單，問題描述會更準確，也能避免同一個問題重複排隊。