ChatGPT 用 Clash 打不開怎麼辦？逾時與連線故障排解

B-01先判斷是 ChatGPT 故障,還是 Clash 路徑故障

ChatGPT 打不開時,不要一開始就直接修改 DNS 或重建整份設定檔。先把症狀分層,因為「頁面空白」「登入頁逾時」「可以登入但對話送不出去」「手機 App 正常、瀏覽器不正常」對應的故障位置並不相同。若其他網站也同時無法載入,問題可能在本機網路、Clash 核心或目前使用的節點;若只有 ChatGPT 相關頁面失敗,才需要優先檢查網域規則、TLS 連線與 DNS 解析。

• 只有 ChatGPT 無法使用:先檢查代理策略、相關網域是否被錯誤分到 DIRECT,以及 DNS 是否解析到不可達的位址。
• 所有境外網站都逾時:先查看節點狀態、訂閱是否更新成功、本機監聽埠是否可用,不要先改 ChatGPT 專用規則。
• 網頁能開但訊息送不出去:通常與長連線、TLS、瀏覽器快取或規則在不同網域之間切換有關,需要查看連線日誌。
• 瀏覽器正常但 App 或桌面程式失敗:代表應用程式可能沒有遵守系統代理,或需要 TUN 模式接管流量。
• 偶爾成功、偶爾逾時:常見原因是節點品質不穩、DNS 回應在不同位址間切換,或策略組自動選擇了延遲低但實際不可用的節點。

B-02確認代理模式、監聽埠與實際流量

Clash Verge、Clash Verge Rev、ClashX 或 mihomo 圖形客戶端通常提供系統代理、混合代理與 TUN 等不同接管方式。系統代理主要服務於會讀取作業系統代理設定的程式;混合埠則讓 HTTP 與 SOCKS5 請求共用一個入口;TUN 模式則透過虛擬網卡接管較廣泛的流量。這幾個選項不是單純的「強弱等級」,而是不同的流量入口。ChatGPT 網頁可以載入,不代表所有 App 都會自動走同一條路徑。

1. 在 Clash 客戶端確認核心正在執行,目前模式不是意外切到 DIRECT 或「規則」以外的模式。若使用全域模式能開啟 ChatGPT,切回規則模式後又失敗,問題大多集中在規則或 DNS 分流。
2. 查看設定中的 HTTP、SOCKS 或混合監聽埠。常見的本機位址可能是 127.0.0.1:7890,但實際數值必須以客戶端介面顯示為準,不能直接套用其他裝置的埠號。
3. 確認系統代理開關已啟用,並檢查瀏覽器是否有 Proxy SwitchyOmega、代理切換器或企業政策覆蓋系統設定。若瀏覽器擴充功能另行指定了不存在的埠,Clash 介面上的系統代理狀態即使正常,瀏覽器仍然不會通過它連線。
4. 打開 Clash 的連線或日誌頁面,重新整理 ChatGPT,觀察是否出現相關請求。完全沒有請求紀錄,表示流量沒有進入 Clash;有請求但顯示 DIRECT,應檢查規則;顯示代理策略後仍逾時,才繼續查看節點與 DNS。

可以用命令列先驗證本機混合埠是否真的能代理 HTTPS 請求。以下指令中的埠號請替換成客戶端實際值:

curl -x http://127.0.0.1:7890 https://chatgpt.com -I -m 15

如果回傳 HTTP 狀態碼或至少能完成 TLS 連線,代表本機代理入口與目前選定的節點基本可用;若出現 Connection refused,通常是埠號錯誤、核心未啟動或被防火牆阻擋;若長時間停在連線階段,則要把注意力轉向節點、SNI、DNS 或上層網路限制。

B-03檢查規則分流:避免 ChatGPT 網域被直連

在規則模式下,Clash 會依照 rules 從上到下比對,命中後立即停止繼續判斷。若前面有廣泛的國內直連規則、錯誤的自訂規則集,或把未知網域統一指定為 DIRECT,ChatGPT 相關請求可能被送到不適合的直連路徑。ChatGPT 的網頁、登入、靜態資源與 API 請求不一定只使用一個主網域,因此只加入單一網域規則,未必能涵蓋整個載入流程。

排查時先以連線日誌顯示的實際網域為準,不要憑記憶大量新增規則。可先建立一個短期測試策略組,將明確需要代理的網域交給該組,確認問題是否由分流造成。示意寫法如下:

rules:
  - DOMAIN-SUFFIX,chatgpt.com,ChatGPT代理
  - DOMAIN-SUFFIX,openai.com,ChatGPT代理
  - DOMAIN-SUFFIX,oaistatic.com,ChatGPT代理
  - MATCH,預設策略

上面的網域與策略名稱只是示意,實際使用時應以目前版本與連線日誌為準,並確認 ChatGPT代理 確實存在於 proxy-groups。如果策略組名稱拼錯、含有不可見空格,或組內沒有可用節點,規則雖然命中,請求仍然會失敗。

B-04動手做一次最小化對照測試

當你已經確認 Clash 有流量,但 ChatGPT 仍然逾時,建議按照以下順序做最小化測試。每次只改一個變數,並在每一步後記錄結果,這樣才能知道是哪個設定真正影響了連線。

1. 固定一個已知可用節點:不要讓自動選擇策略組在測試期間頻繁切換節點。先在節點頁面手動選擇一個能開啟其他境外網站的節點。
2. 切換到全域代理:暫時繞過規則分流,重新開啟 ChatGPT。若全域模式恢復正常,記錄日誌中的網域,再回到規則模式逐項修正;若全域模式仍失敗,問題較可能在節點、DNS 或 TLS。
3. 清除瀏覽器網站資料:刪除 ChatGPT 相關網站的 Cookie、快取與 Service Worker,再使用無痕視窗測試。登入狀態異常、舊版前端資源或損壞的本地儲存資料,都可能表現為空白頁或反覆重新導向。
4. 暫時停用額外代理擴充功能:只保留 Clash 的系統代理或手動代理設定,避免多個代理工具同時接管同一個瀏覽器。
5. 記錄每次結果:分別記下系統代理、TUN、全域模式與規則模式的結果,並保留連線日誌中的策略名稱與錯誤訊息。完成後再恢復最符合日常需求的模式。

B-05DNS、TLS 與 TUN 模式的進一步排查

如果規則已命中代理,但仍然出現「連線逾時」「Network Error」或頁面載入一半停止,下一層通常是 DNS 解析與加密交握。Clash 的 DNS 設定不只負責把網域轉成 IP,還可能配合 fake-ip、redir-host、遠端解析與 TUN 流量接管。不同模式互相搭配不當時,可能出現瀏覽器解析到一個 IP,代理核心卻依另一個結果建立連線的情況。

先在 Clash 的 DNS 日誌或核心日誌中查看相關網域是否解析成功。若解析請求逾時,可以暫時改用一組可正常存取的 DNS,並確認「DNS 請求本身」是否也被錯誤送往直連路徑。不要同時更換 DNS、TUN、規則集與節點,否則即使恢復正常也無法判斷原因。

• fake-ip 模式:檢查 fake-ip 範圍與排除清單,部分本機服務、登入元件或需要真實 IP 的應用程式可能需要加入 fake-ip-filter。
• redir-host 模式:核心會依 DNS 回應取得實際 IP,若本地 DNS 被劫持或回應不穩,可能造成解析到無法連線的位址。
• TUN 模式:確認系統已授予虛擬網卡所需權限,並檢查是否啟用了 DNS hijack。TUN 沒有成功建立時,部分程式可能繞過 Clash,造成同一裝置不同 App 的結果不一致。
• TLS 與系統時間:系統時間、時區錯誤會導致憑證驗證失敗。若日誌出現 certificate、handshake 或 remote error,先校正時間,不要立即關閉 TLS 驗證。

B-06修復後的保留設定與排查結論

完成測試後,建議保留簡潔且可理解的設定。把 ChatGPT 相關規則放在廣泛的 GEOIP、規則集與 MATCH 之前,策略組使用清楚的名稱,並移除為了臨時測試而加入的重複規則。若使用遠端規則集,確認更新週期、快取檔案與 behavior 類型互相符合;規則集下載失敗時,不要假設它仍然包含最新內容。

同時記下三個日後最有用的資訊:目前客戶端使用的核心類型與版本、HTTP/混合監聽埠、以及 ChatGPT 請求在連線日誌中命中的策略。下次遇到相同症狀時,先用這三項資訊與手機熱點做對照,通常可以快速分辨是節點服務端問題、家用網路限制,還是本機設定被其他軟體覆蓋。

如果全部節點都無法代理,先回到訂閱有效性與節點故障排查;如果只有規則模式失敗,優先檢查規則順序與策略組;如果只有特定 App 失敗,則應檢查系統代理支援程度與 TUN 權限。依照這個順序處理,比盲目重裝客戶端或反覆更換 DNS 更容易找到真正原因。