ChatGPT 用 Clash 連不上？逾時與無法載入的排解方法

先判斷：是節點、規則還是 DNS 問題

透過 Clash 開啟 ChatGPT 時，常見症狀包括頁面一直轉圈、顯示連線逾時、登入頁載入不完整、對話可以打開但訊息送不出去，或瀏覽器顯示「無法連線到此網站」。這些現象看起來相似，實際原因可能完全不同。若首頁、搜尋引擎與其他網站都能正常開啟，只有 ChatGPT 失敗，優先檢查規則與節點；若所有境外網站都逾時，則應先確認代理通道本身。

ChatGPT 不是只有一個網域。登入、主頁、對話介面、靜態資源與 API 請求可能分別使用 chatgpt.com、openai.com、auth.openai.com 及其子網域。只把其中一個網域送入代理，常會出現主頁能開啟、登入失敗，或頁面框架載入後內容空白的情況。瀏覽器的快取、擴充功能、系統時間錯誤，以及 DNS 回傳錯誤位址，也可能造成相同表現。

先切換代理模式與節點

排查時不要一開始就修改大量 YAML 參數。先在 Clash 用戶端確認設定檔已經成功載入，代理頁面能看到節點，並且目前選中的策略組不是「DIRECT」或已失效的節點。若使用 Clash Verge、Clash Verge Rev 或其他 mihomo 用戶端，通常可以在代理頁面找到 GLOBAL、Rule 與 DIRECT 三種模式；不同介面的名稱可能略有差異，但測試邏輯相同。

• 先用 GLOBAL 測試。選擇一個延遲較低、最近測試成功的節點，讓所有進入 Clash 的請求暫時經過同一個出口。這一步是為了排除規則誤判，不代表日常一定要使用全域模式。
• 確認系統代理已開啟。僅切換到 GLOBAL 不等於瀏覽器一定會使用 Clash。Windows、macOS 需要開啟「系統代理」；若瀏覽器或應用程式自行設定了其他 HTTP、SOCKS5 代理，也要先停用。
• 更換至少兩個節點。同一服務商的節點可能共用出口或線路，建議分別測試不同地區與不同協定的節點。若只有單一節點失敗，通常是該出口被限制、過載或 TLS 連線品質不佳。
• 檢查時間與憑證。系統日期、時間或時區偏差太大，可能導致 HTTPS 憑證驗證失敗。先開啟系統自動校時，再重新啟動 Clash 與瀏覽器。

如果 GLOBAL 模式下 ChatGPT 可以正常載入，而 Rule 模式下失敗，問題幾乎可以縮小到規則或 DNS。若 GLOBAL 模式也逾時，請先查看節點延遲測試、錯誤日誌與其他網站的連線結果，不要急著新增規則。

檢查規則：讓相關網域走同一個代理策略

Rule 模式依照 rules 從上到下比對，第一條命中後就停止。若設定檔前面存在把 openai.com、chatgpt.com 或相關網域送往 DIRECT 的規則，後面新增的代理規則不會生效。最簡單的測試方式，是在 Clash 的連線頁面重新整理 ChatGPT，觀察新出現的請求網域與最終策略。

在 mihomo 設定中，可以先用明確的網域後綴規則做驗證。下面的 PROXY 只是示例策略組名稱，必須替換成你設定檔中實際存在的策略組；如果策略組叫做「節點選擇」或其他名稱，直接填寫該名稱即可。

rules:
  - DOMAIN-SUFFIX,chatgpt.com,PROXY
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-SUFFIX,auth.openai.com,PROXY
  - MATCH,PROXY

DOMAIN-SUFFIX 會同時涵蓋主網域與其子網域，比單獨寫 DOMAIN,chatgpt.com 更適合這種由多個子網域提供服務的網站。新增規則後要儲存設定檔，並在用戶端重新載入或切換一次設定檔；只修改檔案而沒有讓核心重新載入，實際連線仍會使用舊規則。

1. 打開 Clash 的連線或日誌頁面，清除舊記錄或重新啟動瀏覽器。
2. 重新載入 ChatGPT，記下失敗請求涉及的網域名稱。
3. 確認這些網域的策略顯示為代理策略，而不是 DIRECT、REJECT 或空白。
4. 若網域沒有命中預期規則，查看它是否被更前面的規則集、GEOIP 規則或程序規則提前攔截。
5. 確認最後的 MATCH 只放在規則清單末尾，避免它截斷後續的精確規則。

動手排查：逐步確認 DNS、TUN 與瀏覽器

當規則看起來正確，仍然出現逾時或頁面載入不完整，就要確認 DNS 解析與流量接管是否一致。以下流程適合 Windows、macOS 與 Linux；安卓用戶端可用內建日誌、VPN 狀態與 DNS 設定完成相同概念的檢查。

1. 先在 Clash 中切換到 GLOBAL，選擇一個已測試成功的節點，開啟系統代理，然後重新載入 ChatGPT。
2. 在瀏覽器開發者工具的 Network 頁面查看失敗請求，或在 Clash 連線頁面確認相關網域是否出現，以及它實際使用的策略。
3. 在終端機執行 nslookup chatgpt.com；macOS 與 Linux 也可以執行 dig chatgpt.com，比較查詢是否逾時、回傳錯誤位址或完全沒有回應。
4. 若用戶端支援 TUN，暫時開啟 TUN 並授予系統要求的權限。mihomo 常見設定如下，實際欄位仍要以核心版本與用戶端支援情況為準。
5. 重新啟動 Clash，清除瀏覽器對 ChatGPT 的網站資料後再測試。若此時恢復，逐一停用瀏覽器擴充功能，找出是否有攔截器、代理切換器或隱私防護造成衝突。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

dns-hijack 的作用是把發往 53 埠的 DNS 查詢導入 Clash；auto-route 讓 TUN 建立系統路由；ipv6: false 則是排查階段常用的保守設定，用來避免 IPv6 流量未被完整接管而直連。這不是所有環境的永久最佳值：如果你的網路、節點與用戶端都能正確處理 IPv6，之後可以重新開啟並單獨測試。

若啟用 fake-ip 後只有 ChatGPT 仍然異常，可暫時把 enhanced-mode 改為 redir-host 作為對照。兩種模式切換後都要重新載入設定與清理連線；若 redir-host 正常而 fake-ip 失敗，應檢查 fake-ip 過濾清單、網域嗅探與用戶端核心版本，而不是直接判定節點無效。

登入、驗證與瀏覽器快取的處理方式

ChatGPT 的登入流程通常比單純開啟網頁更複雜，可能包含重新導向、Cookie、跨網域驗證與長時間維持的連線。若主頁可以載入但登入按鈕沒有反應，先確認瀏覽器沒有封鎖第三方 Cookie、JavaScript 或彈出視窗；同時檢查是否使用了隱私模式、腳本阻擋器、廣告攔截器或瀏覽器內建的安全 DNS。

• 使用無痕視窗測試一次。若無痕模式正常，通常是既有 Cookie、快取或擴充功能造成問題。
• 只清除 ChatGPT、OpenAI 與登入相關站點的網站資料，不必一開始清除整個瀏覽器的所有密碼與紀錄。
• 檢查瀏覽器是否啟用獨立的 DoH。它可能繞過系統 DNS 與 Clash 的 DNS 模組，排查時可暫時改為使用系統解析器。
• 不要在短時間內反覆切換不同國家或地區的節點登入。出口頻繁變更可能觸發額外驗證，也會讓 Cookie 與工作階段看起來不穩定。
• 如果只在某一個帳號或某一台裝置失敗，先用另一個瀏覽器做對照；不要把帳號驗證問題誤判為 Clash 核心故障。

對於桌面應用程式或命令列工具，系統代理不一定會自動生效。這類程式可能需要手動填入 Clash 的混合連接埠，例如設定檔中的 mixed-port: 7890，代理位址則是 127.0.0.1。若應用程式支援 SOCKS5，應確認它使用的是對應的 SOCKS 埠，而不是把 HTTP 埠與 SOCKS 埠混用。

最後確認：建立可重複的排查順序

完成修改後，建議按照固定順序再次測試，而不是同時打開多個代理工具。先關閉其他 VPN、代理擴充功能與系統層級的網路加速工具，只保留一個 Clash 實例；接著確認設定檔、節點、代理模式與系統代理狀態，最後才測試 DNS、TUN 與瀏覽器。每次只改一個變數，才能知道哪項設定真正解決問題。

如果多個節點、不同瀏覽器與 GLOBAL 模式都無法連線，而其他使用者也同時回報相同服務異常，可能是服務端維護、區域網路限制或出口受到臨時調整。此時保留 Clash 日誌中的錯誤類型、發生時間、使用的節點地區與測試結果，再向服務商確認，比反覆修改規則更有效。確認恢復後，再把代理模式切回 Rule，並移除只為測試而加入的寬泛規則。