先分辨連線問題出在哪一層

Clash 顯示已連線，通常只代表用戶端已載入設定或 mihomo 核心正在執行，不代表瀏覽器的 ChatGPT 請求已經交由代理處理。實際連線還要經過應用程式、系統代理或 TUN、規則比對、策略組與節點等環節；其中任何一處未生效，都可能出現頁面空白、登入反覆跳轉、載入停住或請求逾時。

排查時先固定一個瀏覽器、一個可用節點和一種流量接管方式。暫時停用其他代理用戶端、瀏覽器代理擴充功能，以及不必要的 VPN；不要一開始就切換 Global、修改 DNS、重建訂閱和更換多個節點。每次只改一項並重新發出請求，才能判斷問題是否因此改變。

  • 只有 ChatGPT 失敗：優先檢查該網站命中的規則、策略組及節點出口，再檢查瀏覽器擴充功能、Cookie 與登入狀態。
  • 多個網站都逾時：先確認核心是否正常監聽、本機代理連接埠是否正確，以及節點是否能建立對外連線。
  • 瀏覽器正常，桌面 App 或其他程式失敗：可能是程式沒有讀取系統代理；若使用 TUN，則要確認虛擬網卡與路由確實建立。
  • 首頁能開、登入或對話不能用：這些操作可能會連線至不同網域。要依序檢查連線記錄，不要只測首頁。

檢查代理模式與節點出口

先查看目前使用的是「規則」模式（Rule）還是「全域」模式（Global）。規則模式會依照設定檔中的規則，將每個連線送往直連、代理策略組或拒絕策略；Global 則會將一般流量交給目前指定的全域策略。為了定位問題，可以短暫以 Global 模式測試一次，但測試後應恢復原本模式。這是診斷手段，不是建議長期忽略分流規則。

切換到代理策略組後，確認它最後指向一個具體可用的節點，而不是 DIRECT、REJECT、空群組或另一個尚未選擇出口的策略組。策略組名稱由設定檔作者決定，可能是「節點選擇」、「手動切換」或其他名稱；請從連線記錄查看實際命中的策略與出站節點，不要只依群組名稱推測用途。

測試結果 可能原因 下一步
切到 Global 後恢復 原本規則沒有涵蓋相關網域，或命中直連策略 檢查連線記錄中的網域、規則與策略組
Global 仍逾時，其他網站也失敗 節點、核心出站、網路或本機代理入口異常 固定一個節點，查看核心日誌及連線錯誤
主頁可開，登入或對話失敗 不同網域套用不同規則，或瀏覽器工作階段有問題 查看失敗請求的網域及命中策略
只有一個節點出現逾時 該節點不可用、路徑不穩或出口不適合目前連線 保持其他設定不變，改測另一個節點

延遲測試成功只表示核心能依測試網址完成一次探測，不保證 ChatGPT 使用的網域、登入流程或長時間串流連線也能正常工作。反過來說，單一測試網址逾時，也可能是探測目標不可達，不宜只憑該數值判定整個節點失效。

逐步檢查規則命中

在用戶端開啟連線或請求記錄，重新載入 ChatGPT，並留意失敗項目的主機名稱、命中規則、策略組及出站節點。常見的相關網域可能包含 chatgpt.com、openai.com、oaistatic.com、oaiusercontent.com 及登入流程使用的網域；實際請求會隨服務版本、登入方式和功能變化，不能假設只要代理主網域就足夠。第三方驗證或共用 CDN 網域也可能出現在記錄中，不建議未確認用途就把大量共用網域一律改道。

  1. 開啟記錄：先清楚記下時間，再在瀏覽器重新載入頁面或重試登入，避免把舊連線與新請求混在一起。
  2. 辨認網域：找出逾時、拒絕或重複重試的請求，記下主機名稱；分享截圖前遮蔽帳號、Cookie、權杖及其他個人資料。
  3. 追蹤命中結果：確認它走代理還是直連、命中哪條規則，以及策略組最後選擇哪個節點。若記錄顯示 DIRECT，測試更換節點不會影響這條連線。
  4. 先加最小範圍例外：若確認特定網域被錯誤分流，可在用戶端支援的覆寫或合併設定中加入精確規則，並放在可能先匹配的廣泛規則之前。
  5. 重新載入並複查：套用設定後重新建立連線，確認新請求已命中預期策略。訂閱更新可能覆蓋直接編輯的內容，應使用持久化覆寫功能。

以下片段只示範規則形式，不是完整設定檔，也不含可連線的節點或策略組。請先確認 PROXY 是目前設定中存在的策略組名稱，再依記錄確認有必要時才採用；不要直接覆蓋整份訂閱。

rules:
  - DOMAIN-SUFFIX,chatgpt.com,PROXY
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-SUFFIX,oaistatic.com,PROXY
  - DOMAIN-SUFFIX,oaiusercontent.com,PROXY
  # 保留訂閱原有規則
  - MATCH,PROXY

動手測試本機代理與瀏覽器

以下用本機 HTTP 混合連接埠 7890 示範。這只是常見範例，不是所有 Clash 用戶端的固定值；先到用戶端設定或生效中的 mihomo 設定確認 mixed-port、port 或其他實際入口。不要把控制介面連接埠當成流量代理連接埠。

  1. 確認核心狀態：查看用戶端是否已啟用設定檔，並在核心日誌確認監聽連接埠及設定載入結果。若核心啟動失敗，先處理 YAML 解析或連接埠占用錯誤。
  2. 明確指定代理測試：在終端機執行下列命令。Windows PowerShell 使用 curl.exe，避免部分環境將 curl 對應為其他命令。
# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 25 -I https://chatgpt.com/

# Windows PowerShell
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 `
  --connect-timeout 10 --max-time 25 -I https://chatgpt.com/
  • 連線遭拒：優先核對埠號、核心是否監聽，以及本機是否有其他程式占用該連接埠。
  • 連上本機代理後仍逾時：查看連線記錄中使用的規則、節點與核心錯誤；只看到請求到達本機，不代表遠端連線成功。
  • 收到 HTTP 回應：代表這次請求取得了回應，但仍需確認規則沒有選用 DIRECT。HTTP 狀態碼也不等於 ChatGPT 帳號或完整功能正常。

如果命令測試成功、瀏覽器仍無法使用，暫時停用會管理代理的擴充功能，確認瀏覽器沒有使用另一個手動代理或 PAC 設定，再完全結束並重新開啟瀏覽器。Firefox 可檢查「設定」→「一般」→「網路設定」中的代理方式；Chrome、Edge 通常會沿用作業系統代理，但擴充功能或裝置管理政策可能另有設定。清除 Cookie 前先確認帳號恢復方式，避免因重新登入造成不必要的帳號驗證問題。

系統代理與 TUN 模式分開排查

系統代理會將代理位址寫入作業系統設定，通常適合先測試桌面瀏覽器。只有會讀取系統代理設定的應用程式才會採用；有些桌面 App、終端機工具或自帶網路堆疊的程式可能不會使用。若 ChatGPT 網頁在瀏覽器中能開啟，但其他程式無法連線，不能只依系統代理開關推斷那些程式也已走代理。

TUN 會建立虛擬網卡並透過路由接收 IP 流量，適用於需要接管未讀取系統代理之應用程式的情況。TUN 接管後，請求仍會依規則分流；符合 DIRECT 的連線仍可能直連。它也可能受系統權限、其他 VPN、防火牆、路由排除項目或 DNS 設定影響。若只想排查瀏覽器，先停用 TUN、單獨測試系統代理，再反向測試，可避免兩種接管方式互相干擾。

  • 使用系統代理時：核對作業系統代理位址是否指向正確的本機連接埠，並確認瀏覽器沒有獨立代理、PAC 或擴充功能規則。
  • 使用 TUN 時：確認用戶端要求的權限或服務已完成，TUN 介面與路由已建立，且沒有其他 VPN 把流量改送至不同出口。
  • 兩種方式都失敗時：回到核心記錄和明確指定代理測試，檢查節點及策略組，不要同時修改 DNS、規則與路由。
  • 瀏覽器只在部分頁面失敗時：找出那些頁面的實際請求網域，確認規則命中與出口一致；首頁載入不代表登入、靜態資源及對話請求都使用同一條連線。

若更換節點後只有特定節點持續逾時，先回到同一套接管方式與同一條規則，再比較另一個節點；不要只看節點名稱或單次延遲值。若所有節點都失敗，應檢查核心錯誤、上游網路與帳號服務狀態。完成排查後，移除臨時測試規則、恢復原本模式，並確認訂閱更新不會意外覆蓋必要設定。