先分清故障發生在哪一層
ChatGPT 網頁開不起來、登入畫面一直轉圈，或訊息送出後逾時，不一定代表代理節點故障。請先記下實際症狀：是整個網頁無法開啟、登入或驗證卡住、對話頁面載入不完整，還是只有送出訊息後沒有回應。不同階段可能涉及不同網域、DNS 查詢、瀏覽器工作階段或代理路由，直接更換節點往往無法找出真正原因。
Clash 客戶端負責管理設定與系統代理，核心則依設定建立連線、解析 DNS 並執行規則。系統代理通常只影響有讀取系統代理設定的應用程式；TUN 則透過虛擬網路介面接管符合條件的流量。瀏覽器能透過代理開啟其他網站，不足以證明 ChatGPT 的所有請求都使用同一條路徑；反過來，ChatGPT 連不上也不能直接證明整個核心已停止工作。
- 只有 ChatGPT 異常：優先檢查相關流量命中的規則、代理群組和目標服務回應。
- 多個網站都無法透過代理開啟：確認核心是否運作、代理連接埠是否正確，以及目前節點是否可用。
- 只有部分應用程式異常：確認該應用程式是否使用系統代理；若沒有，再檢查 TUN 或應用程式自身的代理設定。
- 網頁能開、登入或對話失敗：留意是否有額外的驗證、API 或靜態資源請求失敗，並查看瀏覽器與 Clash 的連線記錄。
確認規則是否命中正確的代理策略
在規則模式下，流量會依設定中的規則順序比對，命中後使用指定的策略。若 ChatGPT 網域被較前面的規則送往 DIRECT、拒絕策略或無效的策略組，即使代理節點本身正常，頁面仍可能逾時。只在代理頁面切換節點，不代表已修正路由；連線可能根本沒有走到你正在切換的群組。
打開客戶端的「連線」或「Connections」頁面，在 ChatGPT 網頁重新整理一次，再觀察新建立的連線。不同客戶端介面名稱可能不同，應查看連線目的網域、命中的規則、規則類型、策略組及最後使用的節點。若頁面載入時有多條相關連線，逐條查看，不要只檢查一筆看起來像首頁的請求。
- 規則顯示
DIRECT：確認是否有較前面的網域規則將請求送往直連。可暫時在規則模式下選擇適當的代理策略測試，但不要因此永久加入不必要的廣泛規則。 - 規則命中代理群組，但沒有出口節點：檢查群組內是否有可用節點、是否選到空群組，以及自動測速或故障轉移群組是否正在更新。
- 規則命中預期策略且有節點：繼續檢查該節點的連線記錄、DNS 結果和目標服務回應；不要只以節點列表中的延遲值判定 ChatGPT 可用。
- 看不到相關連線：請確認流量是否進入目前執行的核心。瀏覽器可能使用獨立代理設定，或其流量未被系統代理與 TUN 接管。
如果使用自訂 YAML，網域規則應放在較廣泛的兜底規則之前，並使用目前設定中真實存在的策略組名稱。例如，若策略組名稱是 PROXY，規則的策略欄位才可指定 PROXY；不能照抄其他設定檔中的名稱。維護網域清單時也要注意，服務可能使用不同網域載入登入、靜態資源或 API。不要假設只加入一個網域就涵蓋所有請求，更不要把未知連線一律改成直連。
動手測試連線與查看記錄
以下步驟適合在桌面系統進行。先選一個平常使用、確認有效的代理節點，並暫停其他大型下載；每次只改一個條件。範例中的 127.0.0.1:7890 是常見本機 HTTP 代理位址，但各客戶端的連接埠可能不同。請先到客戶端設定頁確認 HTTP 或混合代理的實際連接埠；SOCKS 連接埠不可直接當成 HTTP 代理使用。
- 確認客戶端已啟動核心，且目前選用的策略組有實際可用的節點。若核心記錄出現連接埠已被占用、設定載入失敗或節點交握錯誤，先處理該錯誤。
- 開啟連線記錄，再重新載入 ChatGPT 網頁。記下逾時時出現的網域、規則、策略和錯誤類型；如果記錄中沒有相關請求，先不要改 DNS 規則。
- 在終端機透過已確認的 HTTP 代理請求網站首頁，觀察是否能建立 TLS 連線並收到 HTTP 回應。收到錯誤狀態碼仍可能代表網路已到達伺服器，不等於登入或服務功能正常。
- 改用另一個已知可用的節點，保持其他設定不變，再重複相同測試。若只有某個節點失敗，問題較可能在節點或該節點通往目標的路徑。
- 完成測試後恢復原本的節點與設定，並比較連線記錄。若更改了規則或 TUN，測試結束後先確認是否需要保留，再清除臨時變更。
curl -I --connect-timeout 10 --max-time 25 \
--proxy http://127.0.0.1:7890 https://chatgpt.com/此命令會要求目標傳回標頭，連線等待上限為 10 秒，整體請求上限為 25 秒。若回報無法連線到代理，先檢查本機代理位址、連接埠、客戶端是否正在監聽，以及該連接埠是否為 HTTP 代理。若代理可連線但目標連線逾時，再查看核心記錄中的 DNS、TLS 或節點錯誤。若回應 403、404 或其他 HTTP 狀態碼，代表測試請求已收到某種回應，但不能僅憑狀態碼判斷帳戶或 ChatGPT 頁面可正常使用。
Windows 可在 PowerShell 使用 curl.exe 執行相同類型的測試；請先確認 PowerShell 中的 curl 是否為命令別名，避免與系統的 curl.exe 混淆。不要把包含訂閱網址或憑證的命令貼到公開討論區，也不要為了排查而加入略過 TLS 憑證驗證的參數。
排查 DNS 解析與連線階段
DNS 負責將網域解析為 IP 位址，但「網頁開不起來」不一定是 DNS 問題。若記錄明確顯示解析失敗，例如查詢逾時或回傳錯誤，才優先檢查 DNS 設定；若已取得 IP，接下來的 TCP 連線、TLS 交握、代理出口或服務回應仍可能失敗。不要看到逾時就立刻把上游 DNS 改成任意公共伺服器，這可能改變解析路徑，卻沒有修復實際的連線問題。
- 沒有解析結果：確認核心是否啟用 DNS、目前上游 DNS 是否可用，以及系統或瀏覽器是否仍使用另一套 DNS 路徑。
- 解析出 IP，但連線逾時：檢查規則是否命中代理、節點是否能建立連線，以及 UDP 或 TCP 流量是否受到本機網路限制。
- TLS 或憑證錯誤：確認系統日期時間正確，檢查核心記錄中的握手訊息；不要以關閉憑證驗證作為常規修復方式。
- 只有部分頁面元件失敗：查看失敗連線的目的網域，確認登入、靜態資源與 API 請求是否採用不同的分流結果。
使用 Fake-IP 的設定時，DNS 可能回傳由核心管理的映射位址，並由連線中的網域資訊協助規則比對。若作業系統快取、瀏覽器安全 DNS、其他 DNS 軟體與 Clash 同時參與解析，實際結果可能和預期不同。請先在客戶端確認 DNS 模式及相關記錄，再進行短暫的對照測試；不要同時更改上游伺服器、Fake-IP 網段、TUN 路由和瀏覽器安全 DNS，否則難以判斷哪項變更有影響。
可以先完全關閉並重新開啟瀏覽器，或清除該瀏覽器的 DNS 快取，再測試一次。這與清除作業系統 DNS 快取不是同一操作，且重新啟動瀏覽器可能會中斷尚未儲存的工作。若只有一個裝置出問題，可先用另一個瀏覽器或另一台裝置在相同網路與節點下比較；若多台裝置同時失敗，則應一併考慮路由器、上游 DNS 和節點出口。
判斷系統代理與 TUN 是否接管流量
系統代理適合會讀取作業系統代理設定的瀏覽器及應用程式，但某些程式、子程序或瀏覽器設定可能忽略它。TUN 透過虛擬介面和路由規則處理更多系統流量，卻需要額外權限，也可能與其他 VPN、網路過濾器、虛擬網卡或安全軟體衝突。兩種方式的涵蓋範圍不同，不能把開啟 TUN 當成所有逾時問題的通用解法。
先確認瀏覽器是否手動指定代理。如果瀏覽器的代理設定與 Clash 系統代理不同，連線可能走錯入口；若瀏覽器啟用自己的安全 DNS，DNS 路徑也可能和核心設定不同。請記錄這些選項目前的狀態，再逐項比較，不要同時重設瀏覽器與客戶端設定。
- 系統代理模式下連線記錄沒有流量：確認作業系統代理狀態、瀏覽器代理設定及客戶端 HTTP／混合連接埠是否一致。
- 一般網站可用，特定應用程式沒有記錄：該程式可能不遵循系統代理；可在確認支援後使用應用程式代理設定，或評估 TUN。
- 開啟 TUN 後多個應用程式失去網路：檢查 TUN 權限、虛擬介面、路由與 DNS 設定，也要留意其他 VPN 是否同時運作。
- 只有 TUN 模式下 ChatGPT 異常：暫時回到原本可用的模式進行對照，查看 TUN 連線記錄與 DNS 設定是否有差異。
在 Clash Verge、Clash Verge Rev 或其他圖形客戶端中，TUN 的位置與命名會依版本和核心而異；請以目前介面顯示的核心狀態和記錄為準。更改 TUN 權限或路由前先保存原設定，並避免同時啟用多個 VPN。若停用 TUN 後恢復正常，仍須進一步確認是路由、DNS、權限或軟體衝突，而不是直接認定 TUN 本身不能使用。
用交叉測試找出節點或服務端問題
當規則已命中預期策略、DNS 有解析結果，而且流量確實經過代理，下一步是固定條件比較。測試時使用同一台裝置、同一個瀏覽器和同一個網路，每次只更換節點或接入網路其中之一。節點清單的延遲通常是對指定測試網址測得的回應時間，不是 ChatGPT 的端到端延遲，也不代表此節點一定能穩定連上目標服務。
- 更換一個代理節點：原節點逾時、另一節點正常，應優先檢查原節點負載、出口路徑或服務狀態；可記下錯誤時間並向服務提供者確認。
- 用手機熱點比較：同一裝置和節點在熱點正常、原 Wi-Fi 異常，問題可能與原網路、路由器或 DNS 路徑有關。熱點的訊號品質和行動網路政策也會影響結果。
- 更換瀏覽器或裝置：只有單一瀏覽器異常時，檢查其代理、安全 DNS、擴充功能、Cookie 和網站資料；不要先清除所有裝置的設定。
- 比對其他網站與服務：若只有 ChatGPT 相關請求失敗，記錄目標網域與錯誤階段；若多個不同服務都失敗，則回頭檢查節點、核心與本機網路。
完成比對後，將設定恢復到每次測試前的狀態，並整理一份不含敏感資料的診斷摘要：客戶端與核心版本、系統與網路類型、發生時間、規則命中結果、DNS 是否成功、錯誤發生在連線或 TLS 階段，以及更換節點或網路後的差異。若需要向服務提供者或客戶端維護者詢問，先遮蔽訂閱網址、節點地址中可能識別帳戶的部分、密碼、UUID、Cookie 與授權標頭。
最後，將臨時測試措施撤回：恢復原本的系統代理或 TUN 狀態，移除只為診斷加入的規則，並重新確認核心正常載入。比起一次改動多個設定，保留測試紀錄、逐項排除，通常更容易找出 ChatGPT 連線逾時究竟來自規則、DNS、流量接管方式、節點，還是服務端暫時狀態。