先判斷問題屬於哪一層
ChatGPT 在 Clash 或 Mihomo 客戶端下打不開，未必代表帳戶被停用，也不一定是訂閱節點完全失效。瀏覽器顯示「連線逾時」、「This site can’t be reached」、「Network error」或頁面一直轉圈時，可能是請求沒有經過代理、目前節點無法存取目標服務、DNS 回應錯誤，或者代理規則只放行了登入頁面，卻沒有涵蓋後續的 API 請求。
排查前應先把現象分類。若所有網站都打不開，優先檢查 Clash 核心、系統代理與本機監聽連接埠；若一般網站正常，只有 ChatGPT 失敗，則重點放在節點出口、網域分流、DNS 解析與瀏覽器狀態；若 ChatGPT 首頁可以顯示，但登入、對話載入或串流回覆失敗，通常是不同網域或長連線請求沒有使用同一個可用節點。
| 現象 | 較可能的原因 | 先檢查的項目 |
|---|---|---|
| 所有網站都無法開啟 | 核心未啟動、連接埠錯誤或系統代理未接管 | 客戶端狀態、mixed-port、系統代理 |
| 一般網站正常，ChatGPT 逾時 | 節點出口、規則或 DNS 不適合目標服務 | 代理日誌、策略組、DNS 模式 |
| 首頁顯示但登入失敗 | 登入相關網域未走代理，或 Cookie、驗證流程被中斷 | 網域規則、瀏覽器 Cookie、節點穩定性 |
| 對話列表載入但回覆卡住 | API 或串流連線使用了不同分流結果 | 請求日誌、API 網域、代理組切換 |
| 只有某一個瀏覽器失敗 | 擴充功能、DoH、Cookie 或瀏覽器代理設定衝突 | 無痕視窗、瀏覽器代理與安全性設定 |
確認客戶端與核心正在工作
開啟 Clash Verge、Clash Verge Rev、Clash for Windows、ClashX 或 Clash for Android，先查看核心是否顯示正在執行。若客戶端只有介面開啟，但 Mihomo 核心已停止，瀏覽器可能仍保留舊的系統代理設定，結果就是所有 HTTPS 請求都連不到本機代理。也要留意更新設定後是否需要按「套用」、「重新載入」或重新啟動核心。
常見本機代理連接埠包括 7890、7897 和 7899，但不能只依照慣例填寫。請以客戶端「設定」→「網路」或「連接埠」頁面顯示的數值為準。Windows 的系統代理位址通常是 127.0.0.1，連接埠則必須與 mixed-port 或 HTTP 代理連接埠完全一致。
確認節點、代理模式與出口連線
ChatGPT 連線測試不應只看節點清單中的延遲數字。延遲測試通常只請求一個簡短網址，無法代表節點能穩定完成 DNS、TLS、登入驗證與長時間串流回覆。某個節點可能測得 80 毫秒，但實際建立 HTTPS 連線時逾時；也可能首頁載入成功，卻在產生回答時因線路丟包而中斷。
先把模式設為「規則」，再到「代理」頁面找到實際承接外部網站流量的策略組。若策略組類型為 select，手動選擇一個節點；若目前是 DIRECT，ChatGPT 請求可能直接離開本地網路。首次排查不建議直接依賴自動選擇，因為自動測速的目標網址與 ChatGPT 實際使用的服務並不相同。
| 設定項目 | 排查時的建議 | 原因 |
|---|---|---|
| 模式 | 先使用「規則」 | 可以觀察網域如何匹配，避免全域代理造成額外變數 |
| 主策略組 | 手動固定一個節點 | 避免請求期間自動換節點或出口 IP |
| 延遲測試 | 只作為初步篩選 | 延遲低不代表 HTTPS、登入與串流一定正常 |
| 全域模式 | 僅用於短時間交叉驗證 | 可判斷是否為規則匹配問題，但不宜長期取代合理分流 |
| TUN 模式 | 在系統代理無法接管時再測試 | 部分應用程式不遵循作業系統代理，需要虛擬網路介面接管 |
驗證出口 IP 是否真的改變
先關閉 Clash 的系統代理，開啟一個可以顯示公網 IP 的網站並記下結果；再重新啟用系統代理，重新整理同一頁。如果 IP 完全沒有變化，表示瀏覽器可能沒有使用 Clash，或者該瀏覽器啟用了獨立的代理、VPN、Secure DNS 或擴充功能。此時先不要繼續修改 ChatGPT 規則，因為請求根本還沒進入代理核心。
接著在 Clash 的日誌頁面開啟適量的記錄等級，例如 info。重新載入 ChatGPT，觀察是否出現目標網域、連線方式與策略組名稱。看到請求進入日誌，只能證明請求抵達本機核心，還不能代表遠端連線成功；需要同時確認日誌中沒有 timeout、connection reset、EOF、TLS 握手失敗或 DNS 解析錯誤。
動手依序修正並驗證
下面的流程適合 Windows、macOS 與 Android 上的大多數圖形化 Clash 客戶端。選單名稱可能略有不同，但每一步都只改一個變數。完成一項後重新測試，這樣才能知道是哪個設定恢復了連線。
- 在「訂閱」或「設定檔」頁面確認目前 Profile 已啟用，手動更新一次設定，等待節點與策略組載入完成。
- 進入「設定」→「網路」或「連接埠」，記下實際的 HTTP、SOCKS5 或
mixed-port數值，不要直接假設為7890。 - 啟用「系統代理」，確認系統代理位址為
127.0.0.1，連接埠與客戶端監聽值一致。 - 進入「代理」頁面，將模式設為「規則」，再在主策略組中固定一個節點。先不要使用自動測速或負載平衡。
- 關閉瀏覽器中可能改寫流量的 VPN、代理切換器與安全性擴充功能，使用無痕視窗開啟 ChatGPT 登入頁面。
- 在 Clash 日誌中觀察重新整理頁面時的請求。若完全沒有相關記錄，檢查瀏覽器是否繞過系統代理；若有記錄但顯示逾時，改測另一個節點。
- 若仍然失敗，暫時將規則模式切換為全域代理作為交叉測試。全域模式能開啟而規則模式不能，通常代表規則、覆寫或域名集合需要修正。
- 完成測試後回到規則模式，清除瀏覽器該網站的 Cookie 與快取，再重新登入。不要在每次測試之間同時更換節點、DNS 與 TUN，否則結果難以比較。
mixed-port: 7890
mode: rule
log-level: info
dns:
enable: true
enhanced-mode: fake-ip上面的片段只用來說明常見欄位，不是可以直接套用的完整設定。不要把示例中的節點、DNS 或策略組名稱直接貼進現有 Profile；訂閱內容通常還包含代理節點、規則集、過濾器與客戶端專用欄位。修改前應先備份原始設定，並使用客戶端內建的設定檢查或重新載入功能驗證 YAML 語法。
檢查 ChatGPT 網域分流與 DNS
規則模式會依照網域、IP、程序或規則集決定流量走代理還是直連。ChatGPT 不只涉及一個首頁網域，登入、帳戶、靜態資源、API 與串流請求也可能由不同主機提供。若只為單一網域設定代理，首頁的部分資源仍可能被分到 DIRECT，因此會出現畫面載入不完整、登入跳回首頁或訊息送出後一直等待。
在日誌中查看實際請求所匹配的規則與策略組，比盲目新增網域更可靠。常見需要觀察的網域包括 chatgpt.com、openai.com 及其相關子網域，但實際請求會隨產品版本、登入流程與地區而變動。不要把所有流量永久設定為全域代理，也不要從不明來源複製過度寬鬆的規則；應以日誌中真正出現的主機為基礎，加入最小範圍的分流規則。
選擇合適的 DNS 模式
DNS 問題常被誤認為節點問題。當本地 DNS 回傳錯誤地址、解析逾時或受到網路環境干擾時，Clash 即使有可用節點，也可能在建立連線前就失敗。Mihomo 常見的增強模式包括 fake-ip 與 redir-host。兩者對應用程式相容性、IP 映射與規則判斷方式不同，不能在沒有驗證的情況下認為某一種模式永遠較好。
| 檢查項目 | 可能現象 | 建議處理 |
|---|---|---|
| DNS 是否啟用 | 日誌出現解析失敗或找不到主機 | 確認 Profile 的 DNS 區段格式正確，重新載入核心 |
fake-ip |
部分應用程式或自訂規則無法正確識別網域 | 檢查 fake-ip 過濾清單，必要時對特定網域使用 redir-host 例外 |
| IPv6 | IPv4 可用但瀏覽器仍間歇性逾時 | 測試暫時停用 IPv6，或確認代理鏈路能正確處理 IPv6 |
| 瀏覽器 DoH | 瀏覽器解析結果與 Clash 日誌不一致 | 暫時關閉瀏覽器獨立 DNS over HTTPS 進行對照 |
| DNS 快取 | 修改設定後仍持續使用舊結果 | 重新啟動瀏覽器與核心，再清除作業系統 DNS 快取 |
如果切換 DNS 模式後症狀改變，應記錄原本模式、修改內容與測試結果，不要長期堆疊多份互相重複的 DNS 設定。尤其是訂閱設定可能已經提供 nameserver、fallback、proxy-server-nameserver 等欄位，本機覆寫時要先理解它們的用途，避免同一請求在多個解析路徑間反覆失敗。
處理瀏覽器、TUN 與安全性因素
若命令列工具與其他瀏覽器可以使用 ChatGPT，只有某一個瀏覽器失敗，優先排查該瀏覽器的獨立設定。Chrome、Edge、Firefox 可能使用不同的代理讀取方式，也可能啟用獨立的安全 DNS、企業政策、Cookie 隔離或擴充功能。先用無痕視窗測試，再逐一停用代理切換、廣告攔截、隱私防護與 VPN 類擴充功能，比直接重裝 Clash 更有效率。
若使用的是 Clash for Android 或桌面客戶端的 TUN 模式，請確認系統已授予 VPN 權限，且沒有另一個 VPN、網路防火牆或安全軟體同時建立虛擬介面。TUN 主要用於接管不遵循系統代理的應用程式，但啟用後也會增加路由、DNS 與 IPv6 的排查變數。建議先用系統代理完成瀏覽器測試，再在確有需要時開啟 TUN。
| 測試方式 | 適合判斷的問題 | 注意事項 |
|---|---|---|
| 無痕視窗 | Cookie、快取或登入狀態是否損壞 | 部分擴充功能在無痕模式仍可能被允許，需另外確認 |
| 另一個瀏覽器 | 是否為單一瀏覽器的代理或 DNS 設定 | 兩個瀏覽器都要確認沒有各自的 VPN 擴充功能 |
| 系統代理 | 一般桌面 HTTPS 流量能否進入 Clash | 不一定能接管不遵循系統代理的應用程式 |
| TUN 模式 | 應用程式是否繞過系統代理 | 需要檢查 VPN 權限、路由、DNS 與其他虛擬介面 |
從日誌判讀最後一個失敗點
日誌中的 dial tcp 通常表示核心正在建立到目標的 TCP 連線；i/o timeout 常見於路徑無回應或節點品質不穩；connection reset by peer 表示連線被其中一端重設；TLS 或憑證錯誤則需要檢查系統時間、攔截式防毒軟體與節點的 HTTPS 行為。若只看到瀏覽器取消請求，不能直接判定遠端封鎖，因為使用者重新整理或頁面切換也會取消連線。
每次測試最好保留三項資料：測試時間、使用的節點名稱與日誌中的錯誤行。不同時段的節點品質可能差異很大，記錄資料可避免把暫時性的線路壅塞誤判成固定設定錯誤。當固定節點能正常開啟 ChatGPT 後，再恢復自動策略並觀察是否再次出現逾時，便能確認問題是否來自策略組的選擇結果。
恢復後建立可維護的設定
ChatGPT 恢復連線後，不建議保留「全域代理加上多個重複規則、關閉所有安全檢查、同時啟用兩個 VPN」這類臨時解法。先把設定整理成可理解的狀態：使用規則模式、保留一個主要策略組、為必要的網域指定清楚的代理策略，並讓其他本地服務維持直連。這樣不只較容易維護，也能降低不必要的延遲與流量。
Profile 更新後可能覆蓋手動修改，因此如果使用訂閱設定，應確認客戶端是否提供「覆寫」、「Merge」或獨立本地規則功能。不要直接改動每次更新都會被重新下載的原始檔案，除非已經確認該檔案是本機專用設定。修改前先匯出備份，並以不同名稱保存「原始訂閱」、「測試版」與「穩定版」，避免測試失敗後無法還原。
- 將節點策略組設定為手動選擇，確認穩定後再啟用自動測速。
- 保留必要的日誌觀察能力，問題排除後再把
log-level調回較低等級。 - 記下實際的本機代理連接埠，例如
127.0.0.1:7890，避免日後更新客戶端後填錯。 - 不要公開包含帳戶權杖的訂閱 URL，也不要把真實節點密碼貼到日誌或截圖中。
- 若節點全部無法連線，先確認訂閱是否過期、更新請求是否成功，以及遠端服務是否正在維護。
- 若只有串流回覆中斷，固定節點測試一段較長的對話，並觀察是否為線路丟包而不是首頁規則問題。
總結來說，最有效的順序是：先確認核心與本機代理正常，再固定節點驗證出口 IP，接著查看 ChatGPT 請求是否命中正確策略，最後才處理 DNS、瀏覽器與 TUN。按照這個順序，可以把「沒有走代理」、「節點不能用」、「規則分錯」和「瀏覽器本身異常」區分開來，不必反覆刪除設定或更換整套客戶端。