跨境連線故障排查手冊

排查順序:三項判斷先於任何設定

連線故障看起來千頭萬緒,實際上只分三層:帳號與訂閱、用戶端與裝置、線路與網路。三層中任何一層出問題,表現出來的症狀都可能一樣——轉圈、逾時、頁面打不開。所以本手冊的順序是先定位層級,再改設定;一次只改一個變數,改完立刻重新測試。同時改三個地方,即使恢復了也不知道是哪一處起作用,下次復發還得從頭再來一遍。

判斷一,帳號與訂閱是否有效。登入使用者面板,確認方案在有效期內、當月流量沒有用完。流量依開通日每月重置,用完不會自動續,表現是所有線路都連不上,或者連上之後沒有流量。這一步只看面板,不動用戶端。

判斷二,故障是全面還是單點。換一台裝置、換一個網路(例如用另一台裝置開熱點)、換一個目標網站,三次裡只要有一次正常,就說明帳號和線路池本身沒問題,問題在本地。三樣全失敗,才值得懷疑線路。

判斷三,問題在用戶端還是在線路。同一條線路反覆失敗、換一條線路就正常,是線路問題;換哪條線路都一樣失敗,是用戶端或本地網路問題。這項判斷決定了後面該看第 2 章還是第 3 章。

把這三項做完,通常已經能確定該跳到哪一章。下面這張表把常見症狀與章節對應起來,可以先按症狀找,再回到章節裡逐條做。

開始排查前,順手準備三樣東西:出問題的裝置、出問題的時間點、用戶端日誌裡對應時間的那幾行。客服單裡最有價值的資訊不是「連不上」三個字,而是「某時某分、某條線路、錯誤原文是什麼」。日誌的取法在第 10 章統一說明。

重新測試的方法也要固定:同一個目標網站、同一個時段、同一條指令。改完設定立刻打開三個不同地區的網站,比反覆點連線更能說明問題。如果改完第一次就通了,先別急著收工,隔十分鐘再測一次——間歇性故障最容易被第一次成功掩蓋。

完全連不上:從訂閱到本機連接埠逐層排除

先把「連不上」拆成三種表現:點連線後一直轉圈、幾秒內直接失敗、顯示已連線但流量計數始終為零。第一種多半卡在握手,第二種多半是本機設定或連接埠,第三種通常意味著通道建立了但沒有流量通過。三種表現對應不同的排查起點,混在一起看只會越查越亂。

下面六步依帳號到本機的順序排列,每一步都能獨立得出結論。做到哪一步通了,就停在該步,不必繼續往下。

1. 確認訂閱在有效期內、當月流量未用完

   登入使用者面板,看方案到期時間與當月剩餘流量。月租方案的流量依開通日每月重置,用完不會自動續;流量包用完為止、永久不過期,與月租方案的流量分開計算。這一步只看面板,不改用戶端。

2. 換一條線路再試

   同地區換城市(東京換首爾),或換線路類型(IEPL 換中轉)。連續三條不同地區的線路都失敗,基本可以排除單一線路的問題;只有一條失敗,那就是這條線路的事,換掉即可。

3. 換一個網路

   用另一台裝置開熱點給電腦,或改用行動網路。辦公網路、校園網路、飯店網路常做連接埠與協定限制,換網路就通,說明是本地網路的策略,不是帳號問題。這一條能省下大量改用戶端的時間。

4. 校正系統時間

   把系統時間設為自動同步。時間偏差超過幾分鐘,TLS 握手就會失敗,而用戶端通常只報一句「連線失敗」,看不出真正原因。校正後重新啟動用戶端再試一次。

5. 結束其他代理類軟體

   兩個用戶端同時執行會搶同一個本機連接埠,後啟動的那個往往無聲失敗。檢查系統匣與工作管理員,把不用的代理、加速器、封包擷取工具全部結束,只留一個。

6. 檢查防火牆與安全軟體

   首次執行時被攔下的輸入規則不會自己恢復。在系統防火牆裡找到該用戶端,確認輸入與輸出都是允許;第三方安全軟體的「網路防護」也可能攔截通道,先暫時關閉再測。

幾個容易被忽略的原因

本機連接埠衝突。用戶端預設的本機連接埠可能已經被別的程式佔用。表現是介面正常、連線按鈕也能點,但系統代理指向的連接埠上沒有服務。改一個連接埠或結束佔用者即可。

網路對 UDP 的限制。部分網路對 UDP 限速或直接丟棄。在用戶端裡切換到 TCP,或換一種傳輸方式再試,能連上就說明是這個原因。

迴圈代理。分流規則如果把訂閱網域、面板網域也判給代理,而代理這時還沒連上,更新訂閱與建立連線就會互相等待,看起來像怎麼都連不上。把這兩個網域設為直連,再重新連線。

路由器端的攔截。家長監護、上網時間管理、DNS 過濾都會在路由器層攔截。用行動網路對比一次就能確認。

什麼時候該停下來提交客服單

三條不同地區、不同線路類型的線路都失敗,兩個不同網路下同樣失敗,系統時間已校正、其他代理軟體已結束——三項同時成立,基本可以判斷不是本地問題。這時候提交客服單,並附上用戶端日誌與出問題的時間點,比繼續試下去更有效率。客服單要附哪些資訊,見第 10 章。

能連上卻打不開網頁:先分清全部還是部分

用戶端顯示已連線、流量也在跑,瀏覽器卻打不開頁面。第一件事不是改設定,而是做一個區分:所有網站都打不開,還是只有一部分打不開。這個區分決定了後面九成的路徑。

全部打不開

全部打不開通常意味著 DNS 沒有跟著通道走,或者封包在鏈路上被丟掉了。依下面三條依次驗證。

DNS 是否在通道內解析。在用戶端裡確認「DNS 由通道解析」一類的選項是開啟的,並且系統 DNS 沒有被改成某個固定的本機位址。判斷方法在第 9 章。

MTU 是否相符。通道封裝會佔用一部分封包長度。本地仍是 1500 時,大封包會被丟棄,典型表現是首頁能打開、圖片與影片載不出來、頁面卡在一半。用不分片的 ping 測一次:

# Windows
ping -f -l 1472 example.com

# Linux / macOS
ping -M do -s 1472 example.com

1472 加上 28 位元組的標頭正好是 1500。能通說明 MTU 沒問題;提示需要拆分封包或直接逾時,就把數值逐步降到 1400 附近再試,並把用戶端的 MTU 調到 1400 到 1450 之間。這是通道類問題的常見取值,不需要反覆試到剛剛好。

分流規則是否把瀏覽器判成了直連。切到全域模式跑一次,能打開就說明是規則問題,再回到規則模式逐條補白名單。

部分打不開

只有特定網站打不開,問題通常在目標網站一端,不在通道。

地區限制。網站依出口地區提供服務,用對應地區的線路即可。常用地區與適用場景的對照在第 4 章。

出口 IP 觸發驗證。同一出口被多人使用時,網站可能要求額外驗證或直接拒絕。換一條同地區的其他線路,通常就能通過。

本機快取。瀏覽器與應用程式快取了舊的解析結果或舊的連線。清一次 DNS 快取(指令見第 9 章)再重新整理。

串流影音與帳號地區。串流服務除了出口地區,還看帳號註冊地區。出口換了、帳號地區沒換,照樣只能看到部分內容。這類情況換線路解決不了,需要帳號端一致。

分流模式怎麼選

排查時先用全域模式跑一遍。全域能通、規則不通,九成是分流規則的問題;兩種模式都不通,回到 DNS 與 MTU 那兩條。定位清楚之後再回到規則模式,把漏掉的網域加進白名單,而不是長期掛著全域——全域模式會把內網存取、區域網路裝置、本機開發服務一起塞進通道,代價不小。

速度慢與晚間尖峰卡頓:先分清三種慢

慢至少有三種:一直慢、特定時段慢、特定網站慢。三者的成因與處理方式完全不同,混在一起改只會白費功夫。先花兩分鐘確認屬於哪一種,再動手。

一直慢

從連線開始到現在,任何時段都慢,通常出在本地。依次檢查:本地寬頻本身的實際速率;Wi-Fi 是否工作在 2.4GHz 頻段(近距離優先使用 5GHz);路由器是否老舊或開啟了限速;背景是否有系統更新、雲端硬碟同步、雲端備份在跑。

還有一種常見情況是出口地區選得太遠。物理距離決定下限,從亞洲存取歐洲出口,線路再好也要多走一段。就近選地區,是提升體感最直接的一步。

特定時段慢

白天正常、晚間變慢,是國際頻寬的普遍現象,不是某一家服務的問題。晚間的處理思路不是反覆重連,而是換線路類型。

線路類型在用戶端的線路列表裡就能看到,每條線路後面都標了類型。晚間把常用線路從直連換成同地區的 IEPL 專線,通常比換地區更有效。

特定網站慢

只有某個網站慢,先懷疑網站本身:它是否對共享出口限速、是否對單一連線限速、CDN 是否把你調度到了遠端節點。判斷方法很簡單——同一條線路打開另一個同類網站,速度正常,就不是通道的問題。

瀏覽器擴充功能也會拖慢:廣告封鎖、腳本管理、翻譯外掛在跨境存取時會放大等待時間。用無痕視窗(預設不載入擴充功能)對比一次即可確認。

怎麼測才算數

不要看測速軟體的峰值,看真實任務的完成時間:同一部片從點開到能播放用了多久,同一份檔案從開始到下載完成用了多久。測的時候固定三件事——同一個目標、同一個時段、同一個操作。線路 A 與線路 B 各測三次取中位數,兩次結論才有可比性。

本站的線路表不列延遲數字,頁面上也不放即時測速。延遲隨本地網路、時段、目標網站變化,寫一個固定值沒有參考意義;真實體感只能在自己的網路下測出來。

依用途選出口地區

更完整的選線規則見 線路選擇入門指南;全部地區與線路分布見 伺服器 頁。

什麼時候該考慮換方案

慢與「流量用完」是兩件事:流量用完通常直接不通,不是變慢。如果確認是流量不夠用,月租方案有三檔可選:¥9.9 每月含 60GB、¥18 每月含 250GB、¥28 每月含 500GB,流量依開通日每月重置,中途升級依剩餘天數折抵差價。用量波動大的場景,也可以加購流量包:¥158/300GB、¥358/1000GB、¥658/3000GB,用完為止、永久不過期。詳細比較見 方案 頁。

頻繁斷線:依斷線的時間規律反推原因

斷線最容易被誤判成線路不穩。先別換線路,先看規律:固定間隔斷、隨機斷、換網路時斷。三種規律對應三套完全不同的原因,規律看對了,原因基本就出來了。

固定間隔斷

每隔五分鐘、每半小時斷一次,時間點幾乎一致。這類斷線通常不是線路掉了,而是工作階段被回收。

心跳與逾時。用戶端在一段時間內沒有資料往來時會主動斷開重連。掛著不動就斷、一有流量就正常,就是這個原因。在用戶端裡開啟「保持連線」「定時心跳」一類的選項即可。

工作階段逾時。路由器或電信業者端會回收長時間閒置的工作階段。表現與心跳問題一樣,處理方式是把路由器的工作階段逾時調長,或讓用戶端定期送出探測封包。

隨機斷

沒有固定時間,斷完能自動恢復或需要手動重連。常見原因有三個:Wi-Fi 漫遊(裝置在多個存取點之間切換時通道重建)、訊號弱、省電策略(見第 8 章)。

處理順序:固定在一個 Wi-Fi 頻段與一個存取點做對照;關閉系統的「Wi-Fi 助理」「自動切換網路」;記錄斷線時的位置與動作。移動過程中斷、坐下來就恢復,基本可以確定是漫遊。

換網路時斷

從 Wi-Fi 切到行動網路、或從一張 SIM 卡切到另一張卡時斷線,本身是正常現象,通道需要重建。要確認的是它是否自動重連:在用戶端裡找「網路變化自動重連」一類的開關,打開。部分系統在切換網路後會回收連線授權,需要重新確認一次。

記錄什麼才有用

三次斷線就能看出規律,前提是記錄對了。記四樣:時間點(精確到分鐘)、持續多久、當時在做什麼(掛著不動還是正在傳輸)、是否換了網路。再加上用戶端日誌裡對應時間的那幾行,這四樣加日誌,足夠判斷屬於上面哪一類。

用戶端側的四個開關

大多數斷線問題,靠這四個開關就能解決:開機自動連線(避免重新啟動後忘記連)、斷線自動重連(避免手動介入)、保持連線與心跳(對抗工作階段回收)、僅在使用時連線(行動裝置省電,但會犧牲背景連續性)。四個開關依使用場景取捨,桌面端建議前三個全開,行動裝置則依是否需要背景常駐決定第四個。

什麼時候是上游問題

如果同一條線路在不同裝置、不同網路下都在相近的時間點斷,而且換線路就好,那才輪到上游。這時候換線路並把時間點寫進客服單,比反覆重連有用。

訂閱更新失敗:從連結完整性查到拉取網路

訂閱更新的本質,是用戶端向訂閱位址發一次請求,拿回一段設定文字。失敗只有四類原因:連結不對、請求送不出去、請求被中間頁接管、用戶端沒儲存成功。依序排除,四步之內必有結論。

1. 重新複製完整連結

   從使用者面板複製,不要手抄,也不要用聊天軟體裡轉過一手的文字——中間的換行與空格會被一起複製進去。連結裡帶參數,少一個字元就取不到設定。

2. 在瀏覽器裡直接打開一次

   正常的回應應該是一段純文字或一個下載檔案。如果打開的是登入頁、錯誤頁、或一片空白,說明連結失效或請求被中間頁接管了。這一步是整章裡最有效的一步。

3. 先連上再更新

   訂閱位址本身可能需要透過通道才能存取。先用一條可用線路連上,再點更新。反過來做,會卡在「沒連上所以更新不了、更新不了所以連不上」的迴圈裡。

4. 刪掉舊訂閱重新加入

   比反覆點更新可靠。部分用戶端在更新失敗後會保留舊設定,看起來像更新成功但節點沒變。

習慣用指令列的,可以直接用一條指令驗證鏈路是否通:

curl -sS -m 15 "https://example.com/sub?token=YOUR_TOKEN" | head -n 5

範例位址是假值,只用來示範指令形狀,實際連結請從面板複製。指令回傳一段文字,說明鏈路通、內容對;回傳一段 HTML,說明請求被中間頁接管;直接逾時,說明請求送不出去。三種結果對應三種處理方向。

更新成功但節點變少或變空

變少。線路池會隨營運調整,數量有增有減,屬正常現象。只要常用地區還在,不必處理。

變空。通常是拿回了一個錯誤頁,用戶端解析不出任何節點。回到第 2 步,用瀏覽器驗證連結本身。

瀏覽器也打不開。問題在帳號端,登入面板確認方案狀態與剩餘流量。

多裝置共用一個連結

本站同時線上裝置不限台數,同一個訂閱連結在多台裝置上匯入是允許的,不需要為每台裝置單獨申請。需要注意的是,不要在多台裝置上反覆重置訂閱——部分用戶端的重置會作廢舊設定,導致其他裝置一起失效。需要換設定時,先把新連結匯入,確認可用,再刪舊的。

時間不同步也會導致更新失敗

HTTPS 請求需要驗證憑證有效期限。系統時間偏差過大時,憑證驗證直接失敗,用戶端只報一句更新失敗,沒有任何細節。把系統時間設為自動同步,重新啟動用戶端再試一次,是這類問題唯一的處理方式。

單一應用程式走不了代理:先看它走不走系統代理

瀏覽器正常、某個應用程式不行,說明通道本身是通的,問題出在這個應用程式怎麼發請求。應用程式的網路行為分三類:跟隨系統代理、自己直連、走 UDP。先判斷屬於哪一類,再決定用哪種接管方式。

三類應用程式

跟隨系統代理。大多數瀏覽器與部分桌面應用程式屬於這一類。系統代理一開,它們就跟著走。

自己直連。很多遊戲啟動器、軟體更新器、指令列工具不讀系統代理設定,必須用虛擬網路卡(TUN)模式接管全域流量才能涵蓋。

走 UDP 或 QUIC。部分瀏覽器與影音應用程式預設走 QUIC。通道對 UDP 支援不好時會表現為卡住而不是報錯,很容易誤判成這個應用程式不能用。

平台差異

處理順序

1. 切到 TUN 模式

   這是涵蓋面最廣的一種接管方式,能涵蓋不讀系統代理的應用程式。切完重新啟動目標應用程式再試。

2. 關掉應用程式的 QUIC 與 HTTP3

   瀏覽器裡通常有關閉選項;關掉之後流量回到 TCP,通道處理起來穩定得多。

3. 檢查應用程式是否用了自己的 DNS

   部分應用程式內建私有加密 DNS,繞過系統設定。關閉應用程式的「安全 DNS」選項,讓它跟隨系統。

4. 指令列工具手動指定代理

   在用戶端介面裡找到本機連接埠,寫進環境變數,或在指令裡加參數。背景服務需要單獨設定,它不繼承使用者的環境變數。

5. 確認分應用程式代理清單

   Android 等支援分應用程式代理的平台上,目標應用程式必須在代理清單裡被勾選,否則它走的是直連。

驗證指令列工具到底有沒有走通道,用一條只輸出狀態碼的指令最直接:

curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://example.com

回傳 200 說明這條指令的流量通了,回傳 000 說明沒通。開代理前後各跑一次,對比結果即可。同樣的方法也適用於判斷某個腳本、某個建置工具是否走了通道。

仍然不通的幾種情況

應用程式寫死了 IP 或使用私有協定。這類流量繞過分流規則,只能靠 TUN 模式整體接管。

應用程式有獨立網路權限。行動裝置上部分應用程式被系統單獨限制了網路權限,在系統設定裡放行。

應用程式自身的地區限制。出口換了但帳號地區沒換,應用程式照樣拒絕服務,這與通道無關。

開發場景下的長連線需求(補全請求、套件管理器、模型介面)對穩定性要求更高,選線與分流的細節見 AI 程式設計工具的網路與線路說明。

行動裝置背景掉線:省電策略比線路更常見

鎖定螢幕幾分鐘後連線消失,解鎖後要重新連。這類問題九成不是線路,而是系統的背景管理:為了省電,行動系統會凍結背景程序、回收網路設定、限制背景資料。先依平台處理系統設定,再考慮線路。

iOS

低耗電模式。開啟後會限制背景重新整理與網路活動,通道首當其衝。關閉後再測一輪,這是最容易被忽略的一條。

背景 App 重新整理。關閉後,應用程式無法在背景維持連線。在系統設定裡為該用戶端單獨打開。

依需求連線。開啟後,系統會在需要網路時自動拉起通道,不必手動點連線。這是行動裝置最省心的一個開關。

網路切換。Wi-Fi 訊號弱時系統會切到行動網路,切換過程通道重建,表現為每次走到某個房間就斷。固定使用其中一種網路做對照即可確認。

Android

電池最佳化。系統會把不常用的應用程式放進受限狀態,背景網路被切斷。把用戶端加入電池最佳化白名單,並允許背景活動。

自啟動權限。部分客製化系統預設禁止應用程式自啟動,重新啟動後連線不會自動恢復。在應用程式管理裡單獨放行。

從最近任務清單滑掉。很多系統會連帶結束該應用程式的通道。需要背景常駐時,在多工介面把該應用程式鎖定。

通用檢查清單

1. 關閉系統對該應用程式的省電最佳化

   包括智慧省電、深度睡眠、背景限制這類開關,逐項確認。

2. 允許背景資料與背景活動

   系統的流量節省模式也會切斷背景連線,需要單獨放行。

3. 雙卡裝置固定資料 SIM 卡

   兩張卡來回切換會導致通道反覆重建。固定一張做資料卡,訊號更穩。

4. 用另一台裝置做對照

   同一網路下另一台不掉線,基本可以確定是本機的系統策略,不是線路。

什麼情況不是省電問題

解鎖狀態下也頻繁斷,回到第 5 章看時間規律;只在換 Wi-Fi 時斷,是漫遊;只在某個應用程式切到前景時斷,是該應用程式搶佔了網路或改寫了 DNS;連線圖示一直在、但背景下載停止,是系統限制了背景資料,而不是通道斷了。

把這四種情況區分開,能避免在系統設定裡反覆改卻不見效。行動裝置的省電策略是逐版本變化的,系統大版本更新之後如果出現新的掉線規律,優先回到這一章重新過一遍清單。

DNS 異常:能 ping 通卻解析不出網域

DNS 負責把網域名稱轉譯成 IP 位址。它出問題時,表現很像斷網:瀏覽器提示找不到伺服器,但直接 ping 一個 IP 卻是通的。判斷方法很簡單——先 ping 一個 IP,再 ping 一個網域,兩次結果一比就清楚了。

ping -c 4 1.1.1.1
nslookup example.com
nslookup example.com 8.8.8.8

第一條通、第二條失敗,是本機 DNS 的問題;兩條都通、第三條失敗,是本機 DNS 被改寫或快取了錯誤結果;三條全失敗,可能根本沒有網路,回到第 2 章。Windows 上把 ping -c 4 換成 ping -n 4 即可。

常見現象對照

清一次快取

改完設定先清快取,否則舊的解析結果還會繼續生效一段時間。各平台的指令如下:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux(systemd-resolved)
sudo resolvectl flush-caches

行動裝置沒有指令列,開關一次飛航模式即可讓系統重新發起解析。

為什麼會洩漏

多個網路服務。系統裡可能同時存在有線、Wi-Fi、虛擬網路卡等多個網路服務,代理只改了其中一個,解析請求從另一個出去了。

瀏覽器內建加密 DNS。瀏覽器可以自己指定加密解析伺服器,完全繞過系統設定。排查時先關掉它。

分流規則把 DNS 判成直連。規則裡如果只寫了網域比對,沒涵蓋解析請求本身,解析就會走本地。

排查順序小結

先確認通道內解析是否開啟,再清快取,再關掉瀏覽器與系統的加密 DNS,最後檢查分流規則。四步做完仍然解析失敗,把兩條 nslookup 的輸出附進客服單,比自己繼續猜快得多。

C6VPN 的隱私策略是匿名無日誌:不記錄瀏覽內容與存取目標。DNS 在通道內解析是這套策略的一部分,所以排查時優先讓解析走通道,而不是把請求交給本地電信業者。

多裝置、同時連線與客服單的提交時機

本章處理兩類問題:多台裝置同時使用時的表現,以及什麼時候該停止自行排查、改為提交客服單。

不限台數意味著什麼

同時線上裝置不限台數,同一個帳號可以在 Windows、macOS、iOS、Android、Linux 上同時登入,不需要為每台裝置單獨購買。這一點在 方案 頁也有說明。

但不限台數不等於每台裝置獨享頻寬。出口頻寬是共享的,多台裝置同時看 4K、同時下載大檔案,彼此會互相排擠。判斷方法很直接:關掉其他裝置再測一次,速度恢復就是同時使用佔用,不是線路變差。

路由器層級代理是另一種用法:把訂閱匯入路由器後,家裡所有裝置共用一個出口。好處是省事,代價是所有裝置同一個出口 IP,遇到網站風控時會一起受影響,排查時也不容易分清是哪台裝置的問題。建議先用單機方式確認線路可用,再決定是否上路由器。

關於裝置數已達上限的提示

本站帳號端沒有裝置數量限制。如果用戶端裡出現了類似提示,先看提示來自哪裡:多數情況是本機同時裝了兩個用戶端搶同一個本機連接埠,或路由器外掛對同時連線數做了限制。處理方式:結束多餘的用戶端,檢查路由器外掛的同時連線設定,再重新登入面板複製訂閱。

什麼時候該提交客服單

下面五條裡符合兩條以上,就值得停下來提交客服單,而不是繼續試:

• 三條不同地區、不同線路類型的線路都連不上
• 兩個不同網路(家用寬頻與行動網路)下同樣失敗
• 系統時間已校正,其他代理類軟體已全部結束
• 訂閱連結在瀏覽器裡能打開,用戶端裡更新失敗
• 同一條線路在另一台裝置上正常,本機始終失敗

客服單裡要附什麼

不要附什麼

帳號密碼、完整的訂閱連結、付款憑證截圖、身分證件。這幾類資訊對定位問題沒有幫助,只會增加外洩風險。訂閱連結需要展示時,把 token 段落塗掉。

入口與後續

客服單在使用者面板內提交,登入後進入客服單頁即可。提交前先看一遍 使用教學,有一部分問題在教學裡已有現成答案;也可以從 聯絡與支援 頁確認目前可用的聯絡方式。

如果排查到最後確認是服務不符合預期,30 天無理由退款可以在面板內申請。註冊本身不需要電子郵件地址,使用者名稱與密碼即可完成,這一點在退款流程裡同樣成立——不會因為找不到電子郵件而卡住。