先辨認故障發生在哪一段
ChatGPT 無法開啟，不一定代表代理節點失效。瀏覽器可能沒有使用 Clash 的系統代理，規則可能將部分網域送往直連，DNS 解析結果可能與預期不符；也可能是節點出口、瀏覽器資料或服務本身的問題。先記下故障表現與發生時間，並一次只改一項設定，才能判斷是哪個環節造成差異。
先確認同一台裝置上的其他網站能否正常經代理開啟，再分別測試 ChatGPT 首頁和登入流程。如果首頁可載入、登入後卻停住，問題可能涉及登入網域、Cookie、內容封鎖或瀏覽器擴充功能；若首頁也逾時，則應先檢查本機代理入口、規則與節點。單看瀏覽器顯示的「無法連線」不足以區分這些情況。
| 表現 | 優先檢查 | 可用的判斷方式 |
|---|---|---|
| 所有網站都無法經代理連線 | 核心狀態、本機連接埠、節點狀態 | 確認代理程式正在執行，並查看連線記錄是否有本機連線錯誤。 |
| 一般網站正常，ChatGPT 逾時 | 規則命中結果、代理群組與節點 | 在連線記錄中查看相關網域實際使用的策略與出口。 |
| 首頁可開啟，登入或對話卡住 | 登入及資源網域、瀏覽器擴充功能、Cookie | 使用私人瀏覽視窗測試，並觀察失敗請求的網域與錯誤類型。 |
| 只有部分應用程式失敗 | 應用程式是否遵循系統代理、是否需要 TUN | 用明確指定代理的請求與原應用程式做對照。 |
確認系統代理、模式與規則命中
先確認 Clash 或 mihomo 核心正在執行，並記下目前的 HTTP、SOCKS 或混合代理連接埠。127.0.0.1:7890 常見於範例，但不是所有用戶端的固定值，應以目前設定或用戶端狀態頁顯示的連接埠為準。若本機連接埠未監聽，調整規則或更換節點都無法修復瀏覽器連線。
其次檢查目前是否啟用系統代理，以及系統代理指向的位址和連接埠是否與核心一致。Windows 可查看「設定」→「網路和網際網路」→「Proxy」；macOS 可在「系統設定」→「網路」→目前網路服務的詳細資訊中查看代理項目。不同 Clash 用戶端的選單名稱可能不同，應以作業系統實際代理設定與用戶端狀態互相核對。
系統代理只會影響遵循作業系統代理設定的應用程式。若瀏覽器有獨立代理設定、代理擴充功能、啟動參數，或被組織政策管理，可能不會採用系統代理；桌面應用程式也未必自動使用它。確認測試期間沒有另一個 VPN、代理程式或瀏覽器擴充功能同時接管連線。
規則模式下查看策略群組
在規則模式中，連線會依設定檔的 rules 順序，由上而下比對，命中第一條規則後便交由指定策略處理。若較前面的規則已將網域送往 DIRECT，後面的代理規則不會再被檢查。不要只確認「代理選擇」群組已選到節點；還要在連線記錄中核對 ChatGPT 相關請求實際命中的規則與策略。
可先檢查 chatgpt.com、openai.com 及登入或資源載入時實際出現的網域。以下是規則語法示例，代理選擇 必須替換為設定中已存在、且名稱完全一致的代理群組；此片段應合併至原設定，不是可單獨載入的完整設定檔。
rules:
- DOMAIN-SUFFIX,chatgpt.com,代理選擇
- DOMAIN-SUFFIX,openai.com,代理選擇
- DOMAIN-SUFFIX,oaistatic.com,代理選擇
- DOMAIN-SUFFIX,oaiusercontent.com,代理選擇
- MATCH,其他策略服務所需的網域可能隨頁面、登入方式與功能改變，範例不代表所有請求都只會使用這些網域。應以連線記錄中實際出現的目標為準，避免直接把大量不相關網域加入規則。若在規則模式下測試，可先暫時選用明確的代理策略，再查看記錄；測試完成後恢復原有策略設定。
動手測試：從本機連接埠追到遠端回應
以下以本機混合代理連接埠 7890 為例。若你的用戶端使用其他連接埠，請先替換命令中的數字。使用明確指定代理的測試，可以暫時繞過瀏覽器系統代理設定，協助區分「本機代理入口」與「瀏覽器代理設定」問題。
- 確認核心與連接埠。在用戶端查看核心是否正在執行，並確認設定中的 HTTP、SOCKS 或混合連接埠。若核心未啟動或連接埠不符，先修復本機代理入口。
- 使用 curl 指定代理。在終端機或命令提示字元執行以下命令。若系統沒有
curl，可跳過本步，改用用戶端記錄和瀏覽器測試。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://chatgpt.com/收到 HTTP 狀態碼或重新導向回應，通常表示本機代理、節點到測試目標之間至少已完成一次 HTTP(S) 請求；這不等於登入流程一定可用，也不代表所有 ChatGPT 功能都正常。若 curl 無法連接 127.0.0.1:7890，先查核心和連接埠；若已連上本機代理但遠端逾時，則要查看規則、代理群組、節點連線及核心記錄。部分服務可能不接受 HEAD 請求，因此單次錯誤回應不能直接視為整個網站不可用。
- 查看連線記錄。在用戶端開啟連線或日誌頁面，重新載入 ChatGPT，記錄失敗請求的網域、命中規則、策略群組及錯誤訊息。若看不到任何相關連線，可能是瀏覽器未經過該核心，或請求尚未進入代理流程。
- 暫時更換一個可用節點。在同一代理群組內選擇另一個狀態正常的節點，重做相同測試。一次只更換節點，不要同時更改 DNS、TUN 與規則，否則無法判斷改善來自哪一項變更。
- 對照瀏覽器與私人視窗。若 curl 測試有回應而一般瀏覽器失敗，檢查瀏覽器是否使用系統代理、是否安裝代理或隱私擴充功能，並以私人瀏覽視窗排除部分 Cookie 與擴充功能干擾。
- 恢復測試前設定。完成對照後撤銷臨時規則、節點選擇或其他改動，並確認原本的自動選擇群組和規則模式已恢復。
檢查 DNS、Fake-IP 與 TUN 接管範圍
若記錄出現網域解析失敗、連線目標異常，或只有啟用特定 DNS 模式時無法載入，可以檢查核心的 DNS 設定。Clash 用戶端可能採用系統 DNS、核心 DNS 或 Fake-IP 回應；DNS 請求由哪個元件處理，還會受到作業系統、路由規則及用戶端設定影響。不要只因為錯誤訊息含有 DNS 字樣，就直接將所有名稱伺服器改成同一個公開位址。
Fake-IP 模式會以合成位址回應網域查詢，核心再依保存的網域對應資訊處理連線。若裝置上的 DNS 請求繞過核心、應用程式使用自訂 DNS，或 DNS 快取保留舊結果，可能造成網域規則與實際連線資訊不一致。可先重新載入設定或清除瀏覽器 DNS 快取，再重試；不要任意加入大量 fake-ip-filter 項目，因為排除網域後會改變該網域的解析及規則處理路徑。
TUN 模式透過虛擬網路介面接管符合路由條件的流量，適用於不遵循系統代理的部分應用程式，但它不會自動修正錯誤規則或失效節點。若一般瀏覽器在系統代理模式下正常，而特定應用程式沒有連線記錄，可再評估 TUN；啟用前確認用戶端支援該模式，並檢查虛擬介面、路由、權限與核心日誌。
| 項目 | 系統代理 | TUN |
|---|---|---|
| 接管方式 | 向應用程式提供代理位址 | 透過虛擬網路介面及路由處理符合條件的流量 |
| 適合先測試的情況 | 一般瀏覽器未能使用代理，或代理位址與連接埠可能不一致 | 應用程式不遵循系統代理，且用戶端支援 TUN |
| 主要檢查項目 | 系統代理開關、位址、連接埠、瀏覽器獨立設定 | 虛擬介面、路由、權限、DNS 接管與衝突的 VPN |
排查時先以系統代理建立最簡單的可重現路徑，再視需要測試 TUN。若同時啟用多個 VPN、網路過濾器或其他 TUN 型工具，可能發生路由競爭；測試時應避免同時開啟多個接管工具。除非記錄顯示有明確的 DNS 或路由問題，否則不建議為了 ChatGPT 連線直接更換整份 DNS 設定。
依結果縮小範圍並修復
完成前面的對照後，可依結果定位問題。若連明確指定代理的 curl 都無法連到本機連接埠，檢查核心是否啟動、連接埠是否填錯，以及是否有其他程式占用該連接埠。若本機連接埠可連，但核心記錄顯示節點握手失敗或遠端逾時，先在相同群組測試另一個節點，並查看設定是否過期或核心是否載入失敗。
若 curl 有回應，但瀏覽器沒有相關連線記錄，問題通常位於應用程式到 Clash 的入口之間：檢查系統代理開關、瀏覽器自訂代理、擴充功能及啟動參數。若首頁成功、只有登入或對話請求失敗，則檢查連線記錄中實際失敗的登入或資源網域，確認沒有較前面的直連或拒絕規則覆蓋代理規則。
如果錯誤集中在 DNS 查詢，可先重新載入設定、清除相關快取並重試，再根據核心記錄調整 DNS 接管或 Fake-IP 排除項目。若只有開啟 TUN 才出現故障，先關閉 TUN 並恢復原有路由，確認系統代理是否仍可使用；若關閉後恢復正常，進一步檢查虛擬介面與其他 VPN 的衝突。不要把關閉憑證驗證、將代理埠暴露到區域網路或停用整體防火牆當作一般修復步驟。
最後，若多個節點、不同瀏覽器及相同網路環境都呈現相同結果，且本機連線記錄未顯示可修正的規則或 DNS 錯誤，應檢查服務端狀態、帳戶提示與用戶端版本。儲存一份故障時間、錯誤文字、命中規則和節點測試結果，有助於後續比較；分享記錄前請移除訂閱憑證、IP 位址等敏感資訊。