AI 工具使用完整指南

AI 服務為何更依賴穩定網路

能成功開啟不代表工作階段穩定

一般網頁通常在頁面開啟後就完成主要內容傳輸，短暫抖動可能只表現為圖片稍晚出現。生成式 AI 的互動模式不同：使用者送出問題後，瀏覽器需要維持連線，伺服器持續回傳增量內容，前端再將片段逐步寫入頁面。頁面能夠開啟，只能表示網域解析、基礎連線與靜態資源載入已通過；這並不能證明後續的身分驗證請求、模型工作階段、檔案上傳、串流輸出與歷史記錄同步都能穩定完成。因此，「網站能進入但回答到一半停止」與「網站完全無法開啟」應視為兩類問題處理。

AI 產品往往由多個服務網域組成。主站負責介面，身分系統負責登入，API 網域負責工作階段，靜態資源網域提供腳本與字型，檔案網域處理附件，風控系統還會獨立判斷出口環境。如果只有主站經由加速線路，而其他請求仍透過本地網路直連，就可能出現登入頁循環、按鈕無回應、上傳停滯或歷史工作階段空白。排查時不要只看網址列中的主網域，也應同時觀察瀏覽器開發者工具中的失敗請求，確認它們是否使用同一套網路路徑。

另一個常見誤區是只關注下載速度。AI 對話傳輸的文字量通常不大，但非常依賴延遲波動、連線維持與重新連線行為。峰值頻寬很高的線路，如果頻繁切換出口、長連線中斷或 DNS 解析路徑不一致，實際體驗仍可能很差。反過來，吞吐量不突出的穩定線路，往往更適合長時間對話、程式碼生成與文件分析。選擇線路時，應把「持續連線是否完整」放在一次性測速之前。

地區判定、出口位址與 DNS 是一條鏈

AI 服務判斷存取地區時，通常不會只讀取介面語言。出口 IP 的註冊地區、網路營運商、DNS 解析位置、瀏覽器時區、帳號歷史登入地與付款資料都可能參與判斷。單一訊號不一定會直接觸發限制，但多個訊號明顯衝突時，可能要求重新驗證、拒絕載入特定功能，或將工作階段交由更嚴格的風險策略處理。因此，穩定使用的重點不是不斷更換地區，而是讓一段工作階段中的網路身分保持一致。

DNS 也會影響最終連線目標。部分服務使用區域化調度，同一網域從不同解析器查詢，可能取得不同入口。如果 DNS 請求經由本地網路，而實際連線透過另一地區的出口，解析結果與連線來源可能不一致。表現上可能是首頁可存取，但某些 API 很慢；也可能在網路切換後仍命中舊快取。遇到這種情況，應先統一系統、瀏覽器與代理用戶端的 DNS 策略，再清除快取並重新建立連線，而不是連續重新整理頁面。

瀏覽器的安全 DNS、系統代理與用戶端的全域或規則模式之間，也可能互相覆蓋。檢查時應一次只改變一個變數：先固定線路，再確認 DNS；接著檢查瀏覽器擴充功能；最後才測試不同工具。若同時更換瀏覽器、節點、帳號與 DNS，即使問題暫時消失，也無法知道真正原因，下次故障仍需從頭開始。

瀏覽器環境也是連線條件的一部分

瀏覽器擴充功能、隱私攔截規則、舊的網站資料與損壞的 Service Worker 都會改變請求。某些擴充功能會重寫請求標頭，某些內容過濾規則會誤攔身分或統計網域，嚴格的 Cookie 設定則可能讓跨網域登入狀態無法儲存。排查網頁版時，可以使用瀏覽器的獨立訪客視窗建立乾淨環境，但不要把它當成長期解決方案；如果乾淨環境正常，應回到常用設定中逐一停用擴充功能、清除目標網站資料，並確認 Cookie 與腳本權限。

企業網路、校園網路與公共網路還可能部署透明代理或內容檢查。它們有時允許一般網頁存取，卻會提前關閉持續時間較長的連線。此時同一帳號在行動網路或另一條固定網路上正常，通常表示問題不在帳號本身。建議保留一套最小測試路徑：乾淨瀏覽器、固定出口、統一 DNS、不載入第三方擴充功能。只有最小路徑能穩定重現，後續比較才有意義。

帳號註冊、登入與地區一致性

註冊階段比日常對話更敏感

帳號建立、首次登入、密碼重設與安全驗證通常處於更嚴格的風控鏈路。日常對話允許短暫重新連線，身分系統卻更在意請求順序、Cookie 連續性與出口是否突然變化。註冊頁面開啟後，應盡量在同一條線路、同一個瀏覽器工作階段中完成操作，不要在提交表單前後反覆切換地區，也不要讓瀏覽器同時啟用彼此衝突的代理擴充功能。若頁面提示暫時無法處理請求，先保留目前環境，檢查身分網域相關請求，而不是連續重複提交。

使用者名稱、登入方式與復原憑證應由使用者自行安全保存。VPNKe 的註冊要求為無需電子郵件地址，使用者名稱加密碼即可註冊；這項規則只適用於 VPNKe 使用者面板，不代表第三方 AI 平台也有相同要求。第三方工具的帳號條件應以其目前頁面與服務條款為準。不要把某個平台過去允許的註冊流程當作長期固定規則，也不要依賴來源不明的共用帳號。

使用第三方統一登入時，實際上會跨越 AI 服務、身分提供者與回呼頁面。只為主站設定規則而遺漏登入網域，可能在授權完成後無法回到原頁面。典型表現包括登入按鈕持續轉圈、授權後回到未登入狀態、同意頁面反覆出現。此時應檢查整個重新導向鏈是否使用同一出口、瀏覽器是否允許必要的跨網站 Cookie，以及回呼請求是否被擴充功能攔截。

保持帳號行為可解釋

風險系統無法理解使用者真實的旅行或換網原因，只能從技術訊號推斷。短時間內跨越多個相距遙遠的出口、在多台裝置同時建立新工作階段、反覆失敗後仍持續高頻嘗試，都會讓行為更難解釋。較穩妥的方法是固定常用地區，優先選擇距離實際位置較近且長期可用的線路。確實需要更換時，先登出重要工作階段，等待舊連線結束，再使用新線路重新登入。

瀏覽器時區、系統時間與出口地區不必機械式地完全相同，但明顯異常的系統時間會破壞憑證驗證、一次性憑證與簽署請求。裝置應啟用可靠的自動時間同步。若登入在某台裝置上持續失敗，而其他裝置正常，應比較系統時間、瀏覽器設定、Cookie 狀態與網路路徑，不要直接判定為帳號遭封鎖。帳號限制通常會有明確提示；網路故障則更常表現為逾時、空白頁、重新導向循環或請求遭取消。

同一個 AI 帳號在網頁版、桌面用戶端與 IDE 外掛中使用時，各端可能儲存獨立權杖。修改密碼、撤銷授權或清理工作階段後，舊權杖可能失效。網頁仍正常而外掛提示未授權，並不矛盾。應在發生錯誤的具體用戶端中重新完成授權，並清除舊憑證。對於工作裝置，憑證應放入系統金鑰儲存或受控環境變數，不要直接寫在專案檔案、終端機歷史記錄或公開儲存庫中。

逐項確認地區可用性

同一品牌下的網頁對話、模型選擇、圖片生成、檔案分析與開發者 API 可能具有不同的地區政策。能開啟產品首頁，不代表帳號具備所有功能；能使用網頁版，也不代表 API 帳號已開通。判斷功能是否可用時，應區分「頁面沒有入口」「帳號沒有權限」「地區暫不提供」「請求受到限流」與「網路尚未完成連線」這些狀態。它們的處理方式完全不同。

介面語言不是地區切換器。修改語言可以改變選單文字，卻通常不會改變伺服器對出口與帳號的判斷。瀏覽器定位權限也不是主要判斷依據，拒絕定位不能取代穩定的網路環境。應把注意力放在帳號通知、服務條款、請求狀態與出口一致性上。若平台明確不向某地區提供功能，應遵守平台規則，不要依賴頻繁切換身分訊號來製造不一致狀態。

長連線與串流輸出排查

回答中斷發生在哪一層

串流輸出通常透過持續回應，將內容片段傳送至瀏覽器。連線建立後，伺服器可能在較長時間內維持請求開啟。家庭路由器、企業閘道、瀏覽器擴充功能、代理用戶端與上游線路中的任何一個環節提前回收閒置連線，都會讓回答停在中途。使用者看到的現象可能只是游標停止閃爍，實際原因卻可能是瀏覽器主動取消、代理重設、伺服器限流或帳號工作階段過期。

定位時先觀察失敗是否具有一致模式。若短回答正常、長回答容易中斷，重點檢查長連線維持與閘道逾時；若每次提交都立即失敗，優先檢查驗證與 API 網域；若生成已完成但頁面沒有更新，可能是前端腳本或瀏覽器擴充功能問題；若重新整理後能在歷史記錄中看到完整答案，表示伺服器可能已完成生成，只是前端接收鏈路中斷。將這些表現分開記錄，比單純更換節點更有效。

瀏覽器開發者工具中的 Network 面板可以提供直接證據。提交一次普通問題後，找到持續時間最長的請求，觀察它是正常完成、遭取消、連線重設，還是回傳明確狀態。不要在包含敏感對話或授權標頭的情況下公開截圖。需要向支援人員描述時，只記錄請求網域、故障階段、狀態類型與是否可重現，隱藏 Cookie、權杖、對話內容與個人資料。

切換線路會讓現有工作階段失去上下文

代理用戶端切換線路時，既有 TCP 連線不會自動遷移到新出口，通常會直接中斷。頁面看似仍停留在原處，但後台的串流連線已經失效。正在生成長文、上傳附件或執行程式碼分析時，不要切換節點、讓裝置休眠或變更網路介面。如果必須換線，應先等待目前任務結束，儲存重要輸出，重新整理頁面後再建立工作階段。

筆記型電腦從有線網路切換至無線網路，或行動裝置在不同存取點之間漫遊，也可能改變底層連線。部分應用程式具備自動重試能力，但重試後的請求可能不再屬於原工作階段，導致重複輸出或遺失上下文。對於重要工作，建議在穩定網路中完成，並將長提示詞、程式碼片段與生成結果儲存到本機編輯器。AI 對話介面適合互動，不應被視為唯一的文件儲存位置。

系統休眠是另一個常見原因。裝置喚醒後，頁面仍然保留，但權杖、WebSocket 或串流請求可能已經失效。若喚醒後首次提交沒有回應，可先重新整理目前頁面；若內容尚未儲存，請先複製輸入框文字再重新整理。連續點擊傳送可能產生重複任務，也可能觸發頻率限制。

附件上傳與對話生成是兩條路徑

檔案上傳通常會先將內容傳送至獨立儲存服務，再把檔案參照交給模型工作階段。上傳成功不代表模型已經讀取，模型開始回答也不代表所有附件都已解析完成。若進度列停滯，應檢查檔案網域是否經由代理、檔案格式是否受支援，以及瀏覽器是否允許必要請求。若上傳完成後提示無法分析，則更可能是檔案內容、帳號能力或平台處理問題。

大檔案對線路連續性的要求更高，但排查仍不應只看頻寬。上傳途中重傳、線路抖動與瀏覽器記憶體壓力都會拖慢過程。可以使用一個不含隱私的小型文字檔案驗證上傳鏈路，再回到實際文件。測試檔案只應用於確認功能，不要上傳金鑰、內部設定、客戶資料或未去識別化的日誌。

圖片生成與圖片上傳也可能使用不同網域。Midjourney 等偏向視覺工作流程的工具，還可能依賴訊息平台或獨立用戶端中的持續事件更新。若命令已提交但看不到進度，應分別確認命令入口、任務佇列與結果資源是否載入，而不是只重新整理結果頁。重新整理過快可能讓使用者誤以為任務未提交，因而產生重複請求。

重試需要保留界線

網路失敗後立即連續重試，會讓伺服器看到一組相似請求，也會增加重複計費或重複任務的風險。網頁版應先確認上一個請求是否已進入歷史記錄；API 用戶端則應區分可安全重試的讀取請求與可能產生新任務的寫入請求。對於圖片、檔案處理與長時間任務，優先使用平台回傳的任務識別碼查詢狀態，不要盲目重新提交。

如果問題只在晚間尖峰時段出現，可在全球節點頁面了解線路類型，再選擇距離較近且路徑穩定的地區。不要只根據某一次開啟速度判斷線路品質。更有價值的記錄包括：故障發生的功能、連線階段、使用平台、出口地區，以及切換到固定備用線路後是否恢復。長期保留這種簡短記錄，有助於辨識是線路時段問題、特定工具問題，還是帳號端限制。

ChatGPT、Claude、Gemini等工具的差異

ChatGPT：區分頁面、工作階段與檔案鏈路

搜尋「ChatGPT 無法開啟」時，實際問題可能發生在不同位置：首頁無法載入、登入回呼失敗、對話提交失敗、串流回答中斷、歷史記錄空白、檔案無法上傳，或某項模型能力無法選取。應先確認是哪個環節。首頁異常時檢查主站與靜態資源；登入異常時檢查身分網域與 Cookie；回答中斷時檢查持續連線；檔案失敗時檢查上傳網域。將所有現象歸為同一個網路故障，容易錯過真正原因。

網頁工作階段儲存了較多本機狀態。清除所有瀏覽器資料雖然可能解決快取問題，也會登出其他網站並遺失本機偏好設定。更合理的做法是只清理目標網站資料，先備份尚未提交的提示詞，再重新登入。若桌面版正常而瀏覽器異常，請比較系統代理與瀏覽器擴充功能；若瀏覽器正常而桌面版異常，請檢查用戶端是否繼承系統代理，以及安全軟體是否單獨限制應用程式網路。

Claude：長上下文更考驗持續連線

Claude 常用於長文件、程式碼庫與連續寫作。任務越長，使用者越容易遇到上傳階段、分析階段與生成階段混在一起的情況。檔案剛上傳完就切換線路，可能導致後續參照失敗；長回覆過程中裝置休眠，則可能只遺失前端串流。排查時應記錄文件是否完成上傳、工作階段是否建立、歷史記錄中是否保留結果。若短對話穩定而長文件異常，優先測試附件鏈路與連線維持，而不是重新註冊帳號。

專案式工作還可能在多個對話之間共用資料。瀏覽器快取異常、切換帳號或工作區權限變更，都會表現為內容遺失。先確認目前登入身分與工作區，再判斷是否為網路問題。網路問題通常不會只隱藏某一份特定資料；權限問題則可能持續影響特定專案。

Gemini：帳號體系與區域調度要一起檢視

Gemini 與帳號服務、區域化 API 及其他產品入口之間可能存在較深的關聯。使用者從搜尋頁、獨立頁面或辦公工具進入時，實際呼叫路徑可能不同。一個入口可用而另一個入口異常，不能直接證明線路失效。應分別記錄入口、登入帳號與功能類型，確認是否屬於相同服務範圍。

使用統一帳號登入時，瀏覽器的多帳號狀態容易造成混淆。頁面右上角顯示的帳號、授權視窗選取的帳號與實際具備權限的帳號可能不同。排查前應關閉多餘工作階段，確認目前身分，再測試網路。若平台顯示清楚的地區或權限說明，應先處理帳號條件，不要把所有提示都解讀為線路故障。

Copilot 與 Cursor：編輯器內還有代理繼承問題

Copilot 和 Cursor 在網頁授權成功後，編輯器程序仍需自行連線至伺服器。瀏覽器使用代理，不代表 IDE 會自動繼承相同設定；終端機能夠存取，也不代表外掛宿主程序使用相同環境變數。常見表現是網頁已顯示授權成功，編輯器仍停留在登入狀態，或聊天面板可用但程式碼補全沒有回應。

檢查時應完全退出並重新啟動編輯器，因為環境變數通常只會在程序啟動時讀取。若從桌面圖示啟動，可能不會繼承終端機中暫時設定的變數；若從終端機啟動，則可能繼承目前 shell。企業裝置還可能透過系統策略限制外掛存取。先確認 IDE 自身的代理設定、系統憑證與外掛日誌，再判斷是否為帳號問題。

Midjourney：命令入口與資源展示分離

Midjourney 的操作鏈路可能同時涉及命令入口、任務狀態與圖片資源。命令能夠傳送，只表示入口連線正常；任務進度不更新，可能是事件連線中斷；縮圖出現但原圖無法開啟，則應檢查資源網域。排查時應依鏈路拆分，不要重複傳送相同任務。涉及付費生成的操作尤其應先確認任務是否已進入佇列。

視覺資源通常比文字回應更依賴穩定下載。若縮圖正常而原始資源失敗，可嘗試在固定線路下重新開啟資源頁面，但不要頻繁跨地區切換。瀏覽器內容攔截擴充功能也可能阻止媒體網域，使用乾淨環境測試仍然適用。

工具差異會隨產品調整而變化，因此不應依賴一份永久不變的網域清單。更可靠的方法是掌握鏈路拆分：介面、身分、API、上傳、資源、事件與本機用戶端。只要知道失敗位於哪一層，即使產品入口變更，排查方法仍然有效。

API 呼叫與網頁版的不同要求

網頁登入狀態不能取代 API 憑證

網頁版通常透過 Cookie 與工作階段權杖維持登入，開發者 API 則使用獨立金鑰、專案權限與計費狀態。網頁對話可用，不代表 API 已經開通；API 請求成功，也不代表網頁帳號具備相同模型與功能。排查時應先確認呼叫的是哪個產品入口，再檢查對應憑證。不要從瀏覽器儲存空間複製工作階段權杖充當 API 金鑰，也不要把個人網頁工作階段嵌入自動化程式。

API 金鑰應由平台官方控制台建立，並存放在環境變數或金鑰管理系統中。程式碼儲存庫、前端 JavaScript、公開日誌、截圖與聊天記錄都不是安全的儲存位置。瀏覽器前端直接呼叫模型 API 會把金鑰暴露給訪客，即使經過壓縮也無法真正隱藏。正式環境應由受控後端接收業務請求，再由後端呼叫模型服務。

金鑰無效、專案無權限、帳號額度不足、請求格式錯誤與網路逾時會回傳不同訊號。用戶端不應將所有異常統一顯示為「連線失敗」。至少應在內部日誌中保留請求階段、回應狀態類別與平台回傳的錯誤類型，同時刪除授權標頭、提示詞敏感內容與使用者資料。結構化日誌比完整封包擷取更適合長期維護。

串流 API 需要正確讀取回應內容

呼叫端如果要求串流輸出，卻等到整個回應結束後才讀取，就會看起來長時間沒有結果。命令列工具、後端框架與反向代理還可能預設緩衝回應，使伺服器已持續傳送的資料要等聚合後才交給應用程式。排查時應先用最小用戶端直接存取 API，確認伺服器串流是否連續，再逐層加入應用程式框架、閘道與日誌中介軟體。

網路中斷後能否重試，取決於請求語意。一般文字生成重新提交可能得到不同結果；工具呼叫、檔案處理與代理任務則可能產生副作用。應用程式應保存平台回傳的請求或任務識別碼，並在支援時查詢原任務狀態。不要在沒有冪等設計的情況下自動無限重試。重試應設定停止條件，並將驗證失敗、權限不足與格式錯誤排除在自動重試之外。

讀取回應時還要處理多位元組文字邊界。若程式將每個網路片段直接視為完整字串解析，中文字元可能被拆開並產生亂碼。正確做法是使用串流解碼器，讓解碼狀態跨片段保留。對於事件串流，應依協定邊界拼接事件，而不是依任意網路分片解析。

最小化請求用於隔離故障

開發環境出現問題時，可以先建立一個不含業務資料的最小請求，驗證 DNS、TLS、代理、驗證與回應讀取。以下 shell 範例不包含真實憑證，端點由環境變數提供。執行前應將變數指向平台官方文件提供的位址，並在受控終端機中設定自己的金鑰。

export HTTPS_PROXY="http://proxy.example.com"
export AI_API_KEY="sk-xxxx"
export AI_API_ENDPOINT="https://api.example.com/models"

curl --proxy "$HTTPS_PROXY" \
  --header "Authorization: Bearer $AI_API_KEY" \
  --header "Accept: application/json" \
  "$AI_API_ENDPOINT"

若最小請求成功而業務應用程式失敗，問題多半出在應用程式設定、相依套件、憑證儲存或閘道層；若最小請求也失敗，再檢查出口、DNS、系統時間與憑證。不要在命令中直接寫入真實金鑰，因為終端機歷史記錄可能長期保存。較穩妥的方式是從目前工作階段的環境變數讀取，並在測試結束後清除變數。

代理位址也不應提交至公開儲存庫。團隊專案可以提供不含真實位址的範例檔案，並透過部署環境注入具體值。程式碼只讀取變數，不猜測使用者網路。對於不需要代理的內部網路服務，應設定明確的排除清單，避免所有請求都被送往外部出口。

逾時、連線池與並行要分開理解

連線逾時表示無法及時建立連線，讀取逾時表示連線已建立但等待資料過久，總任務時限則涵蓋完整呼叫。將它們混成單一值會造成誤判：串流生成可能持續較長時間，但只要持續收到資料，就不應被短讀取逾時提前終止。用戶端應依所用函式庫的語意分別設定，並在日誌中記錄究竟是哪類時限觸發。

連線池重複使用可以減少握手成本，但出口切換後，池中的舊連線可能繼續指向失效路徑。開發時若修改代理或網路，應重新啟動程序或明確清理連線池。長期執行的服務還應驗證閒置連線失效後的恢復能力。一次啟動成功不代表連線池在網路波動後仍能自行修復。

並行限制可能來自帳號，也可能來自應用程式本身。突然提高並行數會放大連線數、請求頻率與重試風暴。看到限流提示時，應降低並行數、遵守平台回傳的等待訊號，並檢查是否存在失控任務。切換線路無法解決帳號層級限流，反而可能讓風控訊號更複雜。

命令列、IDE 與 CI設定方法

從程序環境開始檢查命令列

命令列程式是否使用代理，取決於執行函式庫、環境變數與工具自身設定。有些工具讀取大寫變數，有些讀取小寫變數，有些只接受明確參數。不要假設瀏覽器能存取，就代表終端機也能存取。可以先在同一個 shell 中查看變數是否存在，再執行最小請求。修改變數後，新啟動的子程序通常會繼承，已經執行中的背景程序則不會自動更新。

系統層級代理與 shell 變數同時存在時，實際路徑可能與預期不同。排查時應明確只保留一種來源。若工具支援顯示詳細連線日誌，可以暫時啟用，但輸出前必須檢查是否包含授權標頭、查詢參數或請求本文。完成排查後關閉詳細日誌，避免敏感資訊進入建置記錄。

套件管理器、Git、容器工具與模型 SDK 可能各自維護代理設定。某個命令成功，不能證明其他命令沿用相同路徑。建議為團隊維護一份設定矩陣，記錄每類工具從何處讀取代理、憑證與身分驗證資料，而不是在故障發生時臨時嘗試大量參數。

IDE 外掛執行於獨立程序

現代 IDE 往往將介面、擴充功能宿主、終端機與語言服務拆分為不同程序。內建終端機中的環境變數不一定會傳遞給擴充功能宿主，擴充功能設定也不一定會影響 Git 或除錯器。Copilot、Cursor 或其他 AI 外掛異常時，應先確認具體功能屬於哪個程序：聊天面板、程式碼補全、索引、終端機命令與網頁授權可能各自使用不同路徑。

從終端機啟動 IDE 可用於判斷環境變數繼承問題。如果這樣啟動後外掛恢復，而從桌面入口啟動仍然失敗，就應將設定放到 IDE 支援的正式位置，而不是長期依賴啟動方式。修改設定後完全退出應用程式，確認背景程序也已結束，再重新啟動。只關閉視窗可能不會終止擴充功能宿主。

在自訂憑證環境中，瀏覽器可能信任系統憑證，而使用獨立執行環境的外掛則使用另一套憑證儲存。常見表現是網頁正常、IDE 回報憑證錯誤。應由組織管理員提供受信任憑證與安裝說明，不要透過關閉 TLS 驗證解決。跳過憑證驗證會將驗證資料與程式碼內容暴露給無法驗證的中間連線。

CI 環境需要明確注入

CI 任務執行於隔離執行器中，不會自動繼承開發者電腦的代理、DNS 或憑證。設定應由 CI 平台的金鑰功能注入，儲存庫只保留變數名稱。執行日誌必須遮蔽金鑰，當提取請求來源不受信任時，還要限制金鑰的可見範圍。不要讓外部貢獻程式碼透過列印環境變數取得憑證。

以下範例只呈現變數傳遞結構，不包含真實位址與金鑰。不同 CI 平台的語法有所差異，應依平台文件改寫。關鍵原則是金鑰來自受保護儲存，腳本只引用變數。

env:
  HTTPS_PROXY: ${{ secrets.AI_PROXY_URL }}
  AI_API_KEY: ${{ secrets.AI_API_KEY }}

steps:
  - name: Run AI integration check
    shell: bash
    run: |
      test -n "$AI_API_KEY"
      ./scripts/check-ai-connection.sh

連線檢查腳本應使用不含敏感內容的最小請求，並清楚區分網路、驗證與權限錯誤。不要讓每次建置都執行高成本生成任務，也不要使用真實使用者資料作為測試輸入。若平台支援模擬或健康檢查端點，應優先使用；若不支援，可以驗證帳號允許的輕量讀取操作。

自架執行器還要考慮網路環境的長期變化。執行器所在機房、容器 DNS 與主機代理可能彼此不同。將連線檢查放在任務開頭，可以在業務步驟前及早失敗。失敗資訊應說明「無法建立連線」或「憑證遭拒絕」，不要把所有情況統一寫成測試失敗。

容器與遠端開發存在額外界線

容器內的 localhost 指向容器本身，而不是主機。若代理只監聽主機的回環位址，容器通常無法直接存取。應使用容器平台提供的主機存取方式，或將代理明確繫結至受控介面，並用防火牆限制來源。不要為了方便將代理連接埠暴露到公共網路。

在遠端開發情境中，IDE 介面執行於本機，外掛可能執行於遠端主機。此時網頁授權在本機完成，但模型請求從遠端環境發出。應確認外掛的實際執行位置，將代理與憑證設定在正確的一端。遠端主機若位於不同地區，帳號風險訊號也可能改變，因此應保持環境穩定。

容器映像不應內建金鑰。建置參數、映像層與快取都有可能洩露歷史內容。執行時透過 secret 掛載或環境注入，並確保應用程式錯誤頁面不會回顯變數。映像中可以包含範例變數名稱與連線測試腳本，但實際值只能在部署時提供。

線路選擇與分層排查流程

先依距離與穩定性選擇線路

存取 AI 工具時，優先選擇距離實際位置較近、長期表現穩定且目標服務可用的地區。遠距離線路可能增加往返等待時間，也更容易經過複雜的中間路徑。不要因為某個遠端地區偶爾開啟較快，就將它設為長期預設。穩定出口對帳號行為與長連線都更重要。VPNKe 涵蓋 120+ 個國家 / 150+ 條線路，可在全球節點查看地區與線路類型。

線路類型名稱只能幫助理解路徑設計，不能單獨代表某個時刻的體驗。IEPL 專線、中轉與直連各有適用環境，實際效果還會受到本地電信商、時段與目標服務調度影響。測試時應固定同一裝置、同一工具與同一任務，比較能否持續完成，而不只是比較首頁開啟速度。

建議保留一條常用線路與一條備用線路。出現故障時，先在常用線路重現，記錄具體階段，再切換至備用線路驗證。若兩個出口都在同一環節失敗，更可能是帳號、瀏覽器或平台狀態；若只有某一條線路失敗，才進一步檢查路由與 DNS。不斷隨機換線會破壞這個判斷過程。

規則模式要涵蓋完整服務鏈

規則模式比全域模式更精細，但維護成本也更高。AI 產品增加新的資源網域、身分網域或上傳網域後，舊規則可能只代理主站。出現「頁面能開、無法登入」或「對話正常、檔案失敗」時，應查看失敗請求屬於哪個網域，再更新規則來源。不要只根據產品品牌名稱猜測網域。

全域模式可作為短時間診斷工具：如果全域模式正常而規則模式失敗，問題通常出在規則涵蓋範圍、DNS 分流或應用程式繞過代理。確認後應修正規則，而不是永久擴大不必要的代理範圍。企業內網與本地裝置位址通常仍應直連，避免影響列印、檔案共用與內部服務。

部分應用程式不遵循系統代理，只讀取環境變數或內建設定。此時瀏覽器測試不具代表性。應依應用程式程序檢查實際出口。若工具允許顯示連線資訊，可以在不暴露憑證的前提下確認；否則使用受控的出口查詢方式。VPNKe 另有IP 查詢頁面，可用於確認目前瀏覽器出口，但不能取代對 IDE、終端機或容器程序的個別檢查。

按層級執行故障樹

第一層是本地環境：系統時間是否正確、網路是否可用、瀏覽器是否存在衝突擴充功能、應用程式是否讀取預期代理。第二層是名稱與連線：DNS 是否回傳結果、TLS 是否建立、目標網域是否走正確線路。第三層是身分：Cookie、權杖、專案與帳號狀態是否有效。第四層是業務：模型、附件、任務佇列與功能權限是否可用。只有前一層通過，才繼續檢查後一層。

這種順序可以避免無效操作。例如 DNS 尚未成功時，清理 Cookie 沒有意義；身分權杖已失效時，反覆更換節點也不會恢復；帳號被明確限流時，提高頻寬無法解決。每一步都應有可觀察的結果，而不是憑感覺判斷。

若需要向支援人員提交問題，可以描述使用平台、目標工具、失敗環節、出口地區、線路類型、是否在備用線路重現，以及錯誤文字的去識別化版本。不要提交密碼、訂閱位址、Cookie、API 金鑰或完整請求標頭。VPNKe 支援 Windows / macOS / iOS / Android / Linux，不同平台的代理繼承方式不同，註明平台能大幅縮小範圍。

DNS、IPv6 與快取的交互影響

裝置可能同時取得 IPv4 與 IPv6 結果，而代理用戶端只接管其中一類連線。若瀏覽器優先選擇未被接管的路徑，就會出現部分請求直連。排查時應查看實際連線類型與用戶端能力，不要直接永久關閉系統功能。較合理的做法是讓代理、DNS 與系統路由對兩類位址採用一致策略。

DNS 快取存在於系統、瀏覽器、代理用戶端與本地路由器等多個位置。修改解析設定後，舊結果可能繼續生效。應依層次清理，並重新啟動相關應用程式。只重新整理頁面未必會觸發新的查詢。若多台裝置在同一網路同時異常，可優先檢查路由器或上游 DNS；只有單台裝置異常，則先檢查裝置本地設定。

瀏覽器 Service Worker 也會快取應用程式資源與請求策略。頁面腳本更新後若出現異常，可以清理目標網站資料並重新載入。不要頻繁清除所有瀏覽器資料，局部處理更容易判斷效果，也能減少不必要的帳號登出。

建立可重複的測試記錄

一份有效記錄只需涵蓋環境、動作、結果與變數。環境包括平台、瀏覽器或用戶端、出口地區與連線模式；動作說明開啟頁面、登入、提交文字、上傳附件或呼叫 API；結果記錄成功、逾時、連線重設、權限提示或限流；變數則說明是否更換線路、DNS 或帳號。不要將多次不同測試混成一句「偶爾不行」。

長期使用時，可以參考加速器線路怎麼選，依地區、線路類型與用途建立固定選擇規則。若問題集中在晚間尖峰與影片任務，也可閱讀穩定傳輸與頻寬指標說明，理解吞吐量、位元率與持續傳輸之間的關係。文章中的串流媒體情境與 AI 檔案傳輸並不相同，但區分峰值速度與持續穩定性的思路可以沿用。

帳號封鎖、限流與異常復原

先區分帳號限制與網路故障

使用者常將無法使用一律稱為「帳號遭封鎖」，但實際上可能是工作階段過期、地區功能不可用、請求頻率限制、專案權限不足、付款狀態變更、瀏覽器 Cookie 失效或網路連線中斷。真正的帳號限制通常會在登入頁、控制台或通知中提供較明確的資訊。網路問題更常表現為逾時、連線重設、空白頁面、資源載入失敗，或不同裝置的結果不一致。

判斷時先在不改變出口的情況下重新登入，並查看平台通知與帳號頁面。如果帳號頁面可正常存取，只有特定功能失敗，應檢查功能權限與請求狀態；如果多個功能都在建立連線前失敗，再檢查網路。不要為了繞過不明錯誤而連續建立新帳號，這會增加管理混亂，也可能違反平台規則。

限流通常會有明確的等待或頻率訊號。它可能針對帳號、專案、模型或 API，不一定與網路出口有關。正確處理方式是降低並行數、停止自動重試、等待平台允許再次請求，並檢查程式是否存在迴圈。更換節點不會增加帳號配額，也不能修復錯誤的重試邏輯。

常見風險訊號來自不一致的行為

頻繁跨地區登入、多個自動化任務共用個人憑證、短時間內大量失敗請求、公開洩露 API 金鑰，以及來源不明的瀏覽器擴充功能，都會增加帳號風險。降低風險的核心是讓行為可解釋：固定常用出口，使用官方授權流程，為不同專案管理獨立憑證，及時撤銷洩露的金鑰，並遵守服務條款。

共用帳號不僅帶來權限與隱私問題，也會讓登入地點、裝置狀態與使用頻率難以控制。團隊使用時應選擇平台提供的團隊或專案功能，依成員分配權限。人員離開、裝置遺失或專案結束時，應撤銷相應憑證，而不只是修改前端應用程式中的設定。

瀏覽器擴充功能能夠讀取頁面內容或修改請求。安裝 AI 輔助擴充功能前，應檢查其權限範圍與來源。若擴充功能要求讀取所有網站資料，應了解它可能接觸對話、程式碼與帳號頁面。故障排查時使用乾淨瀏覽器，可以同時排除擴充功能衝突與潛在風險。

金鑰洩露後的處理順序

發現 API 金鑰出現在儲存庫、日誌或截圖中，應先在平台控制台撤銷或輪換，而不只是刪除檔案。版本控制歷史、建置快取與聊天記錄可能仍保留舊值。產生新金鑰後，更新受控環境，並檢查異常呼叫與費用記錄。不要在公開問題單中貼上完整金鑰來驗證其是否有效。

程式碼儲存庫中的金鑰即使很快刪除，也應視為已經洩露。可以增加提交前掃描、儲存庫保護規則與 CI 檢查，降低再次發生的機率。範例設定統一使用類似 sk-xxxx 的假值，文件明確說明真實值透過環境注入。前端專案尤其不能保存伺服器端金鑰，因為任何訪客都能查看下載到瀏覽器的程式碼與網路請求。

若洩露的是網頁登入工作階段，應從帳號安全頁撤銷其他工作階段、修改憑證並檢查已授權應用程式。網路線路無法補救已經洩露的憑證。復原後應確認異常裝置已登出，再重新登入常用裝置。

復原過程不要擴大問題

遇到連續失敗時，最危險的操作是同時更換帳號、裝置、瀏覽器、地區與付款方式。這樣會產生更多不一致訊號，也讓原始原因無法追蹤。應停止自動任務，保存錯誤資訊，固定一個受控環境，從網路、身分、權限到業務功能逐層驗證。若平台要求等待或驗證，應依提示處理。

帳號復原後，不要立即恢復所有並行任務。先用低風險的一般請求確認登入與 API，再逐步啟用外掛、自動化與檔案處理。若某一步再次觸發異常，就能明確問題邊界。自動化系統應具備熔斷機制，在驗證失敗或持續限流時停止，而不是不斷重試。

VPNKe 提供 30 天無理由退款，支援支付寶 / 微信 / USDT，且不限裝置數量。方案為 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量依啟用日每月重設，中途升級差額按剩餘天數折算。另有用完為止、永久不過期的流量包：¥158/300GB、¥358/1000GB、¥658/3000GB。具體選擇可查看方案頁面。這些服務條件與第三方 AI 平台的帳號權限、限流及地區政策彼此獨立。

一套可長期沿用的維護習慣

日常維護應以穩定為核心，而不是頻繁變更。固定常用地區，保留備用線路；確保系統時間與憑證正常；克制使用瀏覽器擴充功能；將 API 金鑰放入受控儲存；分別記錄 CI、IDE、終端機與容器的設定來源；故障時保留去識別化日誌。這樣做不能消除所有平台故障，但能讓問題快速分類。

使用所謂「翻牆軟體」作為寬泛搜尋詞時，使用者往往把帳號、瀏覽器、網路與平台政策混在一起。本頁的核心方法是將它們重新拆開：網路負責建立穩定路徑，帳號負責身分與權限，應用程式負責請求格式與工作階段，平台規則決定功能界線。只有先確認故障屬於哪一層，後續操作才不會互相干擾。

如果只是首次設定 VPNKe，請回到使用教學依主線完成連線；如果已能連線但不知道如何挑選地區，請閱讀線路選擇指南；如果準備在 Windows 上部署用戶端，可參考Windows 用戶端新手教學。本頁適合作為故障發生時的系統索引，而不是每次從頭執行的操作清單。