本文目錄
頁面上的錯誤，決定這次該查哪一層
ChatGPT 或 Claude 打不開時，先把頁面上的原話記下來。一直轉圈、ERR_TIMED_OUT 與 403 Access Denied 不是同一類故障；401、429、5xx 也各自指向認證、頻率限制或伺服器端異常。只寫「不能用」，後面每一步都只能靠猜。
頁面結果先這樣分
| 看到的現象 | 優先判斷 |
|---|---|
| 頁面框架出現，圖示、按鈕或登入元件空白 | 靜態資源網域可能走了不同規則或出口 |
| ERR_CONNECTION_TIMED_OUT / 請求超時 | 網路路徑、節點或長連線失敗 |
| 401 / Unauthorized | 登入狀態、令牌或 API 認證資訊 |
| 403 / Access Denied | 服務策略、帳號狀態或請求被拒絕 |
| 429 / Too Many Requests | 頻率或額度限制，不是節點延遲 |
| 500 / 502 / 503 | 伺服器端或上游臨時異常，先看官方狀態 |
| 回覆寫到一半停止 | 串流連線、節點切換或網路抖動 |
瀏覽器首頁能開啟，只說明主頁面到了。指令碼、圖片和登入元件可能來自其他靜態資源網域，登入跳轉、檔案上傳和模型串流回覆也會產生不同請求。頁面只有外殼時，要在 Connections 中確認這些資源是否和模型請求走同一穩定出口，而不是拿另一個網頁代替測試。
固定一個出口，保留可以比較的失敗現場
建立可復現的測試
在 Proxies 固定一條節點
暫時不要使用 url-test 或 fallback，避免測試過程中出口變化。
保持 Rule 模式
開啟 Connections，準備觀察失敗動作對應的網域與規則。
只重複一個動作
例如按一下登入、傳送同一句短訊息，或上傳同一個小檔案。
儲存頁面狀態和 Clash 結果
記下 HTTP 狀態、連線出口、耗時與日誌錯誤。
如果失敗動作在 Connections 中完全找不到，瀏覽器或桌面應用可能沒有經過目前 Clash。若記錄出現但命中 DIRECT，檢查規則；已經走到固定節點卻 timeout，才值得換節點或網路做對照。
登入頁反覆跳回，重點是會話有沒有建立
登入循環常表現為輸入帳號後又回到登入頁，或者驗證碼完成卻沒有進入對話。此時先在同一瀏覽器的無痕視窗重試，排除過期會話和擴展干擾；不要一上來清掉所有網站資料，那會同時退出其他帳號。
觀察按一下登入後的請求：認證跳轉若沒有進入 Clash，處理瀏覽器代理；請求進入後回傳 401 或 403，則網路已經到達服務，繼續檢查帳號、登入方式和服務提示。頻繁換地區或出口還可能讓一次登入跨越多個會話環境，測試期間應保持固定節點。
登入問題需要留下的資訊
- 發生循環的具體頁面和按鈕
- 無痕視窗是否得到相同結果
- 失敗請求回傳 401、403 還是 timeout
- 登入前後是否一直使用同一固定出口
Access Denied 不是「再加一層代理」就能解決
明確的 403 或 Access Denied 通常說明請求已經到達網站，只是被拒絕。檢查頁面給出的原因、帳號狀態、地區限制、服務支援範圍和目前出口是否符合服務條款；這與 DNS 超時、連接埠沒開屬於不同層。
Global 模式最多用於判斷某條規則是否把請求送錯了出口，不能把伺服器端拒絕變成網路成功。若 Rule 和 Global 都在同一固定節點上回傳同一個 403，應停止調整 Clash，轉而處理帳號或服務政策。
短網頁正常、長回覆中斷，要測試連線持續性
模型回覆是持續回傳的資料流。節點能完成一次延遲探測，並不代表它能穩定維持幾十秒的連線。用一條稍長但可重複的提問測試，觀察中斷時 Connections 的結束原因；同時關閉自動切換，避免回覆中途被換到另一個出口。
同一固定節點在家庭網路和手機熱點上各試一次。若只在其中一個網路中斷，重點檢查這個網路和 DNS；若兩個網路都在相近位置中斷，換另一條協議或節點對照。不要用一次成功就下結論，至少重複兩三次相同請求。
回覆中斷時出現 timeout
比較另一固定節點與另一網路，找出是節點出口還是本機網路。
中斷瞬間策略群組自動換節點
疑難排解期間改用 select 固定出口，穩定後再調健康檢查。
頁面提示 429
查看帳號額度與頻率說明，繼續測速不會消除限制。
所有使用者同時收到 5xx
查看服務官方狀態，等上游恢復後重新測試。
網頁能用、桌面端或 API 不行，要看處理程式是否讀取系統代理
瀏覽器通常遵循 Windows 或 macOS 系統代理，終端中的 curl、SDK 和部分桌面應用則可能使用自己的網路設定。執行同一個 API 請求時，Connections 沒有任何記錄，說明請求還沒進入 Clash，換節點沒有意義。
命令列工具可以按自身文件設定 HTTP_PROXY、HTTPS_PROXY；需要統一接管多個不讀取系統代理的應用時，再考慮 TUN。API 回傳 401 代表請求已經到伺服器端，應該核對 API key 和請求格式，而不是繼續擴大代理範圍。
CLASH_PORT=7890
export HTTP_PROXY="http://127.0.0.1:${CLASH_PORT}"
export HTTPS_PROXY="http://127.0.0.1:${CLASH_PORT}"
export NO_PROXY="localhost,127.0.0.1,::1"
curl -I https://example.com$CLASH_PORT = 7890
$env:HTTP_PROXY = "http://127.0.0.1:$CLASH_PORT"
$env:HTTPS_PROXY = "http://127.0.0.1:$CLASH_PORT"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe -I https://example.com用一條短訊息確認請求能完整結束
回到固定節點和 Rule 模式，完成一次登入並傳送一條短訊息。Connections 裡應能看到這次操作涉及的請求，頁面不再回傳原來的錯誤，回覆也能完整結束。
若仍失敗，就按現象繼續處理：沒有連線記錄就檢查接管方式，顯示 DIRECT 就檢查規則，出現 timeout 就比較節點和網路，回傳 401、403 或 429 則按伺服器端結果檢查。
一條短訊息能完整回傳以後，再恢復 url-test 或 fallback。若自動組恢復後問題重現，這次就有明確的對照：帳號和規則沒有變化，變化的是出口選擇。