先判斷問題在哪一段：連線、規則還是服務本身
ChatGPT 經 Clash 無法開啟，不一定代表節點故障。一次連線至少涉及應用程式是否把流量送進 Clash、規則是否選到預期的出站策略、節點能否連上遠端服務，以及 DNS 是否能正確解析。若只看瀏覽器顯示的「連線逾時」，很難分辨是哪一段失敗；建議先記下使用的用戶端、核心、作業系統、出站模式與錯誤發生時間，再依序檢查。
先用同一個瀏覽器開啟其他需要代理的網站。如果其他網站也無法連線，優先檢查代理核心、節點和本機入口；如果只有 ChatGPT 異常，再檢查規則命中、相關網域是否走代理，以及瀏覽器的 DNS 或擴充功能。若 ChatGPT 網頁能開啟，但登入、對話或圖片載入失敗，可能是不同請求使用了不同網域，不能只依據首頁是否載入就判斷所有連線正常。
| 觀察到的現象 | 優先檢查 | 可用的判斷方式 |
|---|---|---|
| 所有代理網站都逾時 | 核心、代理群組、節點連線 | 查看用戶端連線記錄，確認其他網站是否也失敗 |
| 其他網站正常，ChatGPT 失敗 | 規則命中、服務相關網域、DNS | 在連線記錄中搜尋目標網域與使用的策略 |
| 網頁可開，登入或對話卡住 | 登入請求、靜態資源、瀏覽器設定 | 重新載入頁面，觀察是否有特定請求持續逾時 |
| 只有某個應用程式無法連線 | 應用程式是否遵循系統代理 | 用瀏覽器交叉測試，必要時再考慮 TUN |
確認代理模式與規則命中結果
日常使用通常以規則模式為主，但「已開啟規則模式」不表示 ChatGPT 流量一定使用代理。規則可能把相關網域送往 DIRECT，也可能命中拒絕策略、尚未選好節點的代理群組，或在更前面的規則中被其他條件接走。請在 Clash Verge、Clash Verge Rev、Mihomo 相關用戶端或其他客戶端的連線頁面，搜尋 ChatGPT 請求實際命中的規則與出站策略。
常見的服務網域可能包括 chatgpt.com、openai.com、auth.openai.com、oaistatic.com 與 oaiusercontent.com；實際請求網域會隨服務功能調整，也可能使用其他主機名稱。這些名稱只適合作為檢查起點，不是永久完整清單。若記錄顯示登入、介面資源或附件請求命中了直連規則，再針對確切網域處理，不要不加判斷地把整份規則表改成全域代理。
規則順序與代理群組
Clash 規則一般由上而下比對，先命中便採用該條規則指定的策略。自訂網域規則應放在會涵蓋它的廣泛規則與 MATCH 之前，並確認策略名稱和設定中的代理群組完全一致。以下是示意片段；「代理選擇」必須替換成現有且已選取可用節點的群組名稱，不能直接當作完整設定檔使用。
rules:
- DOMAIN-SUFFIX,chatgpt.com,代理選擇
- DOMAIN-SUFFIX,openai.com,代理選擇
- DOMAIN-SUFFIX,oaistatic.com,代理選擇
- DOMAIN-SUFFIX,oaiusercontent.com,代理選擇
- MATCH,原有預設策略請勿直接把上述片段附加在 MATCH 後面，因為放在兜底規則之後的項目不會被檢查。若自訂規則重複、規則提供者自動更新，或訂閱更新會重寫設定，也要確認最後生效的規則內容。建議先備份，再透過用戶端的覆寫或合併功能修改；直接編輯暫存產生的訂閱檔案，更新後可能消失。
動手排查：用同一組條件逐項測試
以下流程一次只改一個變數，能避免切換模式、換節點、改 DNS 後仍不知道哪項設定影響結果。測試前先記下原本設定；每次變更後重新載入頁面或重啟應用程式，讓舊連線與快取不致干擾判斷。
- 確認核心正在執行：查看用戶端狀態或記錄，確認設定檔成功載入、核心沒有持續重啟，也沒有 YAML 解析錯誤。介面顯示已啟動，不等於目前設定檔內的節點與規則都可用。
- 確認代理群組選擇：在代理頁面找到規則所指向的群組，確認已選擇一個可連線節點，而非
DIRECT、空群組或已失效的節點。若群組為自動測速類型，查看目前節點是否確實有回應。 - 確認流量進入核心：先用瀏覽器測試，並在連線記錄中找出剛產生的 ChatGPT 請求。若沒有記錄，檢查系統代理是否啟用、位址和連接埠是否與核心監聽設定相符；也確認瀏覽器或作業系統沒有被另一個代理程式接管。
- 確認規則和出站結果：對照記錄中的網域與命中策略。若命中
DIRECT，檢查該條規則及其上方的廣泛規則；若已命中代理群組，則確認群組最後選到的節點，而不是只看規則名稱。 - 短暫改用全域模式交叉測試：讓已進入核心的流量暫時交由
GLOBAL策略處理，並在全域群組中選擇可用代理節點。若這時可連線，問題較可能在規則順序或規則指向；若仍逾時，應轉查節點、DNS、本機入口或服務狀態。測試後請還原規則模式。 - 一次更換一個節點：使用同一裝置、相同模式與相同瀏覽器，只替換節點後重試。若只有特定節點失敗，可能是該節點出口、路由或連線品質問題；不要同時改規則和 DNS，否則無法辨認原因。
- 最後測試 DNS：先確認連線記錄中的網域能否解析，並留意是否有 DNS 逾時、錯誤回應或不一致的解析結果。測試期間暫時關閉瀏覽器自訂的安全 DNS，讓瀏覽器採用一致的系統解析路徑；完成後依原需求恢復設定。
部分服務會使用長連線或額外的資源網域，因此首頁載入成功與完整功能正常並非同一件事。若只有送出訊息或載入附件時失敗，請在該操作發生後立即查看新增的連線記錄，針對實際失敗的網域確認規則和節點，避免一律擴大成所有流量全域代理。
DNS、節點與逾時：依錯誤表現縮小範圍
DNS 負責把網域名稱解析成 IP，代理節點則負責建立通往服務的出站連線。DNS 查詢失敗時，應用程式可能尚未建立對 ChatGPT 的連線；節點連線失敗時，則可能已看到域名請求，但出站連線無法完成。兩者都可能顯示逾時，應以核心記錄及連線記錄為準。
- 解析錯誤或 DNS 逾時：確認目前 DNS 設定可用、核心的 DNS 模組正常，並檢查瀏覽器是否使用自訂 DoH。若採用
fake-ip，不要只因為解析結果看似特殊就判定故障；需配合核心記錄與實際連線路徑確認。 - 連線被拒絕或節點不可用：檢查節點地址、連接埠、協定參數與代理群組選擇。若多個節點同時失敗，再確認本機網路、防火牆或上游網路是否阻擋連線。
- 代理握手或 TLS 相關錯誤：核對節點的傳輸方式、TLS 參數、服務名稱及核心相容性。能成功解析設定檔，不代表握手所需欄位都正確。
- 只有特定功能逾時：確認相關資源網域是否被其他規則分流，並比較同一節點下不同功能的連線記錄。若只改 DNS 後短暫正常，還需檢查瀏覽器快取與規則命中，不能直接推定 DNS 是唯一原因。
不要把任意公共 DNS 位址直接寫入設定來「修復」所有連線問題。DNS 伺服器是否可達、是否符合當地網路環境，以及核心採用的解析模式，都會影響結果；修改前先備份，並一次只調整一處。若變更後狀況更差，還原設定比連續疊加多組 DNS、fake-ip 和 TUN 參數更容易定位問題。
何時改用 TUN，何時應更換節點
若瀏覽器透過系統代理已能正常開啟 ChatGPT，通常不需要為了單一網站啟用 TUN。TUN 的用途是透過虛擬網卡和系統路由接管符合條件的 IP 流量，適合不遵循系統代理的應用程式；它不會自動修復規則錯誤、失效節點或 DNS 問題，也不代表所有連線都會走代理。規則仍可能把流量指向 DIRECT。
只有在連線記錄顯示目標應用程式的請求沒有進入核心，而且該應用程式無法設定 HTTP 或 SOCKS 代理時，才值得考慮啟用 TUN。桌面系統可能需要管理員或系統擴充權限；Android 則需授予 VPN 權限。啟用前先確認核心支援 TUN、沒有其他 VPN 同時接管，並留意區域網路、虛擬網卡及路由設定的衝突。測試完成後，若不需要接管其他應用程式，可關閉 TUN 並確認系統網路設定已恢復。
更換節點適用於規則已命中正確代理群組、其他設定保持不變，但特定節點持續逾時的情況。逐一測試少數不同節點，記錄成功與失敗結果；若同一網路下只有某個節點失敗，應先排查該節點或其出口，而非重寫整份規則。如果所有節點與多種接入方式都失敗，則回頭檢查服務狀態、帳戶、DNS 和本機網路，避免無限切換節點。
排查完成後，還原用於測試的全域模式、臨時 DNS 或 TUN 設定，並保留最後確認有效的規則修改。若仍無法定位，提供用戶端與核心版本、作業系統、發生時間、脫敏後的錯誤訊息及相關連線記錄，通常比提供完整訂閱更有助於分析；分享前請刪除節點地址、密碼、令牌和帳戶資訊。