進階設定
預計閱讀 11 分鐘

TUN 模式與系統代理怎麼選：兩種流量接管機制的運作原理比較

透過 Clash 開啟 ChatGPT 時出現連線逾時、畫面載入失敗或速度異常嗎？本指南會檢查系統代理、模式選擇、節點狀態與分流規則，並說明如何更換節點、修正規則，以及在需要時啟用 TUN 模式。

先判斷逾時發生在哪一段

ChatGPT 在 Clash 中顯示「連線逾時」、頁面長時間轉圈，或對話送出後沒有回覆，不一定代表節點完全失效。一次正常請求可能依序經過網域解析、規則比對、本機代理連接埠、遠端節點撥號、TLS 交握，以及服務端 API 回應；其中任一環節延遲過高，都可能在瀏覽器中呈現相同的錯誤。

先不要急著反覆更新訂閱或刪除整份設定。最有效率的做法，是先確認問題範圍：只有 ChatGPT 失敗，還是所有外部網站都失敗；瀏覽器失敗時，命令列是否也失敗；切換節點後，錯誤是否立即消失。這些結果能協助區分規則、DNS、節點品質與本機代理設定。

現象 較可能的原因 優先檢查項目
所有網站都無法開啟 代理核心未啟動、連接埠錯誤或節點失效 核心狀態、本機連接埠、目前節點
一般網站正常，ChatGPT 逾時 ChatGPT 相關網域未命中代理，或節點不適合該服務 規則命中結果、節點切換、DNS
登入頁能開，對話送出失敗 API 或串流回應網域被直連、連線被中途重設 日誌中的目標網域與出站策略
只有 TUN 模式下失敗 DNS 劫持、路由衝突或虛擬網卡優先順序問題 TUN、DNS 模式與其他 VPN
更換節點後短暫恢復又逾時 節點擁塞、出口 IP 品質不穩或策略組頻繁切換 節點延遲、封包遺失與策略組類型

確認本機代理與運作模式

瀏覽器要經由 Clash 連線，首先必須把請求送到核心正在監聽的本機連接埠。常見設定會使用 mixed-port: 7890，也可能分開使用 port: 7890 與 socks-port: 7891。連接埠只是本機應用程式進入核心的入口，不是遠端節點的連接埠；將兩者混淆時，很容易在瀏覽器或系統代理中填入錯誤數值。

在 Clash Verge、Clash Verge Rev 或其他 Mihomo 圖形客戶端中，先確認目前設定檔已啟用，核心狀態顯示正在執行，再檢查「系統代理」是否開啟。Windows 可進入「設定」→「網路和網際網路」→「代理」；macOS 可進入「系統設定」→「網路」→目前網路→「詳細資訊」→「代理伺服器」。確認 HTTP、HTTPS 代理位址是否為 127.0.0.1，連接埠是否與 Clash 設定一致。

如果同時使用公司 VPN、其他代理軟體或安全防護程式，請先暫停其中一項再測試。多個程式同時修改系統代理、DNS 或路由表，可能造成瀏覽器偶爾成功、重新整理後又逾時的間歇性結果。若只需要讓瀏覽器測試 ChatGPT，建議先使用系統代理，不要一開始就啟用 TUN。

系統代理與 TUN 的取捨

系統代理只會接收主動讀取作業系統代理設定的應用程式，優點是權限需求低、變更範圍小，也較容易確認請求是否進入 Clash。TUN 則在 IP 層接管較多流量，能涵蓋不讀取系統代理的程式，但會涉及虛擬網卡、DNS 劫持與路由優先順序。ChatGPT 的網頁版測試通常不需要先啟用 TUN；只有系統代理已確認正常，而特定應用程式仍無法連線時，才值得進一步測試 TUN。

mixed-port: 7890
mode: rule
log-level: info

檢查 ChatGPT 網域是否命中代理

ChatGPT 並不只使用一個網域。登入、網頁介面、靜態資源、API 請求與串流回應可能涉及不同的主機名稱；常見排查對象包括 chatgpt.com、chat.openai.com、openai.com、auth.openai.com 與 oaistatic.com。實際網域會隨服務版本、登入流程與瀏覽器請求變化，因此不要只把首頁網域加入規則後，就認定所有 ChatGPT 流量都已經走代理。

開啟 Clash 的連線或日誌頁面，重新整理 ChatGPT，再送出一則簡短訊息。觀察目標網域最後使用的是哪個策略，尤其注意是否出現 DIRECT、REJECT，或使用了不預期的節點。如果首頁使用代理，但對話相關請求顯示直連，問題通常在規則集內容、規則順序或分流模式，而不是單純更換節點就能永久解決。

rules:
  - DOMAIN-SUFFIX,chatgpt.com,PROXY
  - DOMAIN-SUFFIX,chat.openai.com,PROXY
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-SUFFIX,oaistatic.com,PROXY
  - MATCH,DIRECT

上方只是排錯用的簡化示例，PROXY 必須替換成你設定檔中實際存在的策略組名稱。規則會由上而下比對，前面的規則一旦命中，後面的規則不會再接手。若訂閱已經提供規則集，不建議直接複製大量網路規則覆蓋原設定；先查看現有規則是否已包含相關網域，並確認策略組名稱沒有寫錯。

動手操作：用最小範圍重現問題

完成基本確認後，建議按照固定順序做一次乾淨測試。測試期間不要同時播放影片、同步雲端檔案或開啟大量分頁，避免高併發連線掩蓋真正原因。每完成一項就記錄結果，這比一次修改十個選項更容易找到有效變更。

  1. 在客戶端確認設定檔已載入、核心正在執行，記下目前混合連接埠，例如 7890。
  2. 只開啟一個瀏覽器視窗，關閉 ChatGPT 分頁後重新啟動瀏覽器，排除舊有連線與快取狀態。
  3. 先選定一個延遲較低且近期可用的節點，不要使用正在頻繁切換的 url-test 或負載平衡組。
  4. 開啟 Clash 連線日誌，再造訪 ChatGPT，觀察登入頁與靜態資源是否分別命中預期策略。
  5. 送出只有一句話的測試訊息，記錄是否在 10～20 秒內出現回覆，以及日誌最後停在哪個網域。
  6. 先關閉系統代理再測一次，再重新開啟；如果系統代理失敗而 TUN 成功，表示應用程式代理設定或系統代理寫入可能有問題。
  7. 更換另一個節點重複測試。若只有特定節點逾時，保留規則不動，優先將問題歸類為節點或出口品質。

可以使用瀏覽器開發者工具的「Network」面板輔助觀察，但不要把 Cookie、Authorization 標頭或帳號資訊分享給他人。若需要擷取日誌，保留時間、目標網域、規則名稱、策略組與錯誤類型即可，敏感憑證應先刪除。

處理 DNS 與 TLS 連線問題

規則命中代理後仍逾時，下一個重點是 DNS。若網域由本地網路、公共 DNS 或代理核心以不一致的方式解析，可能出現解析到不可達位址、解析結果被污染，或瀏覽器取得的 IP 與代理出口不匹配。特別是在 TUN、Fake-IP、Redir-Host 多種模式並存時，DNS 行為會受到核心設定與客戶端實作影響。

先確認設定檔是否存在重複的 dns: 區塊、無效的上游伺服器或與其他 VPN 衝突的 DNS 劫持設定。排錯期間可以先使用較簡單的 DNS 配置，確認系統代理模式下的網頁請求；不要在尚未證明節點正常前，同時更換 DNS、TUN 模式與全部規則集。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback:
    - https://1.0.0.1/dns-query

以上範例不代表所有網路環境都應照抄。部分網路會封鎖特定 DoH 位址，部分舊核心也不支援同樣的欄位；請先確認目前使用的是 Mihomo 及其支援的設定格式。若日誌明確出現 dial tcp、i/o timeout、context deadline exceeded，可分別理解為建立連線失敗、等待網路 I/O 超時，或整體請求超過期限，但仍需結合目標網域與使用的節點判斷。

TLS 錯誤則不一定是 DNS 問題。系統時間錯誤、節點中途重設連線、代理鏈路不穩定，或某些網路攔截 HTTPS，都可能使 TLS 交握失敗。先確認作業系統日期與時區正確，再測試另一個節點；不要為了繞過錯誤而關閉 TLS 驗證，這會降低連線安全性，也可能讓帳號與對話資料暴露。

節點與策略組的穩定性排查

如果規則已正確命中、DNS 沒有明顯錯誤，而 ChatGPT 仍不穩定，應把注意力放到節點本身。延遲低不等於適合長時間 API 或串流回應；節點可能在健康檢查時只回應小型測試請求，實際傳輸時卻有封包遺失、頻寬不足或連線被重設。可以分別觀察延遲、抖動、成功率與持續連線時間。

測試結果 判斷方向 建議處理
延遲 60ms，但請求經常中斷 封包遺失或長連線品質差 更換節點，觀察串流回應是否恢復
多個節點都無法連線 規則、DNS、本機代理或網路環境問題 回到系統代理與日誌，勿只更新節點
只有某地區節點失敗 出口路由或該地區 IP 品質問題 改用其他地區節點，暫時停用該組
策略組不斷自動切換 探測容差過小或節點品質接近 調高 tolerance，或先固定單一節點

使用 url-test 時，不要只依一次測速結果選擇節點。若兩個節點的測試結果分別為 72ms 與 78ms，但前者抖動很大，ChatGPT 的實際體驗可能反而較差。排錯時先手動固定一個節點，等連線穩定後再恢復自動策略，這樣可以避免策略組在測試過程中改變變數。

避免反覆逾時的長期設定

完成排錯後，將設定恢復成容易維護的狀態。日常可使用 log-level: info，只在重現問題時暫時使用 debug；為 ChatGPT 相關網域保留清楚、集中且不重複的規則；策略組不要放入大量長期失效的節點；TUN 只在確實需要接管非系統代理應用程式時開啟。

若以上步驟都無法解決，請整理客戶端與 Mihomo 核心版本、作業系統、代理模式、設定檔中與 DNS 和規則相關的部分，以及去除敏感資訊後的完整錯誤時間線。單獨提供「ChatGPT 不能用」通常不足以判斷原因；包含目標網域、命中規則、策略組、節點與錯誤類型的資料，才有助於進一步定位。

下載Clash