Clash 已連線但無法上網

先建立可重現的測試條件

先暫停自動切換節點，固定使用一個節點、一個測試網址和一種流量接管方式。用戶端顯示「已連線」，通常只代表核心已啟動，或系統代理、虛擬網卡已啟用；不代表瀏覽器流量已進入核心，也不代表遠端節點能完成目標網站的 TLS 交握。

1. 記下目前的設定檔名稱、代理模式、策略組選擇，以及系統代理和 TUN 的啟用狀態。請勿公開完整訂閱連結。
2. 先備份目前設定。之後每次只變更一個選項，測試完成後再決定要保留或還原。
3. 退出其他代理用戶端和 VPN。企業設備上的安全軟體或網路政策，應交由管理員確認，請勿直接停用防護功能。
4. 開啟用戶端的連線清單和記錄頁面，先使用 info 層級。若暫時提高至 debug，請留意記錄可能包含造訪的網域和本機網路資訊。
5. 完全關閉瀏覽器後重新啟動，避免沿用舊連線。所有對照測試都使用同一個網址。

一、確認系統代理指向正確的連接埠

建議先開啟「系統代理」、關閉 TUN，建立瀏覽器測試基準。系統代理主要影響遵循系統代理設定的應用程式，不代表所有程序都會經過代理。遊戲、命令列程式、瀏覽器擴充功能，以及自行設定代理的軟體，可能使用不同的連線路徑。

檢查系統設定與瀏覽器擴充功能

• Windows 11：前往「設定」→「網路和網際網路」→「Proxy」→「手動 Proxy 設定」，確認代理位址和連接埠。自動設定指令碼和手動代理可能同時存在，請確認目前實際生效的設定。
• macOS：前往「系統設定」→「網路」→目前的網路連線→「詳細資訊」→「代理伺服器」，確認網頁代理和安全網頁代理是否指向用戶端實際監聽的位址。
• 瀏覽器：暫時停用控制代理的擴充功能，並檢查是否設有獨立代理設定或略過清單。無痕視窗不一定會停用所有擴充功能。

本機常用位址為 127.0.0.1。連接埠請以目前生效的設定為準，不能假設所有用戶端都使用 7890。以下 YAML 片段僅用來說明欄位用途，並非完整設定，也不需要直接覆寫現有訂閱：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port 可同時接受 HTTP 與 SOCKS 代理連線；只有 socks-port 的連接埠不能直接填作 HTTP 代理。external-controller 常見的 9090 是管理介面的連接埠，不是網頁流量入口。本機瀏覽器故障排除也不需要開啟「允許區域網路連線」。

略過系統設定，直接測試本機代理

以下 Windows 指令會明確指定 HTTP 代理，可用來判斷是「系統設定錯誤」還是「代理連線異常」。如果實際連接埠不是 7890，請先修改指令中的連接埠。macOS 和 Linux 可使用 curl，並將 NUL 替換為 /dev/null。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -o NUL -sS -w "HTTP=%{http_code}\n" https://example.com/

• 明確指定代理後成功，瀏覽器卻失敗：優先檢查系統代理、瀏覽器擴充功能和代理略過設定，不要繼續調整節點。
• 立即顯示無法連線至本機連接埠：先確認核心是否正在執行、連接埠是否填錯，以及監聽程序是否屬於目前使用的用戶端。
• 建立連線後逾時：查看記錄，確認問題發生在節點撥號、DNS 或連線至目標網站的階段；不能只憑逾時就判定連接埠有問題。

收到 HTTP 狀態碼，表示這次請求至少收到了 HTTP 回應；但 403 或 451 仍可能是網站政策限制。若要確認流量是否經過預期的代理，還需查看連線記錄中的出口鏈。

二、檢查連接埠占用與核心啟動狀態

即使系統代理設定已寫入，若核心因設定錯誤而未啟動，瀏覽器仍會把請求送到沒有程序監聽的連接埠。先查看記錄中的啟動錯誤，例如監聽失敗、設定解析失敗或引用了不存在的策略組，再考慮修改連接埠。

在 Windows 檢查監聽程序

在 PowerShell 中執行以下指令。第一條會檢查監聽狀態和程序編號；第二條會依照結果中的 OwningProcess 查詢程序。範例編號 1234 請替換為實際值。

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id 1234

macOS 可使用 lsof -nP -iTCP:7890 -sTCP:LISTEN。如果監聽程序屬於另一個用戶端，請先正常退出該程式，再啟動要使用的用戶端。不要只因連接埠衝突，就強制結束不明的系統程序。

• 沒有監聽結果：檢查核心執行狀態、目前生效的設定和連接埠類型，並確認用戶端介面上的開關確實已生效。
• 連接埠遭舊程序占用：退出重複執行的實例，必要時使用工作管理員確認舊程序是否仍在執行。
• 改用其他連接埠後：同步更新系統代理和應用程式內的代理設定，避免用戶端監聽 7891，瀏覽器卻仍連線至 7890。

訂閱檔案和實際執行的設定可能不同。用戶端覆寫、合併設定和圖形介面設定都可能變更監聽連接埠，請以執行中的設定和監聽結果為準。欄位用途請參閱連接埠設定說明。

三、排除 TUN 權限與路由問題

如果系統代理測試正常，但啟用 TUN 後失敗，排查重點應轉向虛擬網卡、路由和 DNS 接管。TUN 會將 IP 流量交由核心處理，可涵蓋部分不遵循系統代理的軟體；但需要核心支援，也需要建立網卡、修改路由等權限。

1. 關閉系統代理，只啟用 TUN，然後重新啟動測試應用程式。這樣能減少兩種流量入口重疊造成的判斷困難。
2. 依照目前用戶端的要求安裝或啟動服務模式，並核准系統權限要求。Windows 通常由背景服務執行需要較高權限的操作；macOS 可能需要授權輔助程式；Linux 通常需要適當的網路管理權限。
3. 查看記錄中是否出現建立虛擬網卡失敗、權限不足或新增路由失敗。開關已開啟但初始化出錯，不能視為流量接管成功。
4. 中斷其他 VPN 後再測試。多張虛擬網卡同時爭用預設路由時，節點連線也可能被錯誤送回隧道，形成迴圈。
5. 如果問題只在電腦從睡眠喚醒或切換 Wi-Fi 後出現，請重新啟動用戶端核心並重新建立 TUN，再確認路由是否已恢復。

不要同時嘗試更換 TUN 協定堆疊、啟用 IPv6、修改 MTU 和切換 DNS。如果只有傳輸大型檔案或部分 HTTPS 網站時會卡住，可先確認基本連線正常，再針對 MTU 排查；這不該是所有「網頁無法開啟」問題的第一步。

四、區分系統 DNS 與核心 DNS

看到 no such host、lookup failed 或網域解析逾時時，先確認是哪一層負責解析。瀏覽器可能使用安全 DNS，系統有自己的解析器，Clash 核心也可能分別解析目標網域和代理節點網域。修改系統 DNS，不一定會改變核心 DNS 的行為。

先查看查詢結果，再清除快取

在 Windows 執行以下指令，可查看系統解析路徑的結果；但這無法證明瀏覽器和核心使用相同的 DNS：

nslookup example.com
ipconfig /flushdns

第二條指令只會清除 Windows DNS 用戶端快取。瀏覽器、核心和上游解析器可能各自保留快取。修改設定後，請依照用戶端支援的方式重新啟動核心，並重新建立瀏覽器連線。

• 節點伺服器使用網域名稱：節點本身也需要先完成解析。如果上游解析必須經由尚未建立的代理，可能會形成啟動依賴，請檢查節點網域的解析路徑。
• 使用 DoH：https:// 格式的 DNS 位址仍需要網路連線正常並通過憑證驗證。請檢查系統時間，以及解析器網域如何完成初始解析。
• 瀏覽器使用安全 DNS：暫時切換至系統解析路徑進行比對。如果問題因此消失，再檢查瀏覽器 DNS 流量的規則，不要長期保留不明設定。
• 只有 IPv6 目標連線失敗：檢查本機 IPv6 連線能力和代理鏈支援情況。可暫時關閉相關 IPv6 選項進行比對，但請記下變更項目，並在測試後再次確認。

Fake-IP 位址不代表 DNS 一定出錯

在 Fake-IP 模式下，解析結果可能落在設定的合成位址範圍內，常見設定會使用 198.18.0.1/16。核心會保存網域名稱與合成位址的對應，再處理後續連線。看到 198.18.x.x 不代表網域解析錯誤，也不能只靠 ping 結果判斷網頁代理是否正常。

真正需要確認的是：取得合成位址的流量是否繼續經過同一個核心，以及位址對應是否仍然有效。如果應用程式取得 Fake-IP 後繞過 TUN 直接連線，就可能無法存取。區域網路裝置探索、印表機或依賴真實位址的應用程式，可依需求設定 fake-ip-filter，不要將所有網域都加入排除清單。基本概念請參閱位址與 GeoIP 說明及術語手冊。

五、透過連線記錄確認規則出口

如果請求已進入核心，接著查看連線清單中的目標網域、符合的規則、策略組和最終節點。Rule 模式會依規則順序比對，通常由第一條符合的規則決定出口；代理組名稱即使是「自動選擇」，也不代表目前選到的節點一定可用。

短暫比對 Rule 與 Global 模式

1. 保持目前節點不變，在 Rule 模式下開啟目標網站，記下符合的規則和出口。
2. 暫時切換至 Global，並在 GLOBAL 策略組中明確選取同一個節點，再重新建立連線。
3. 若 Global 可存取、Rule 無法存取，請檢查 Rule 是否將目標流量導向 DIRECT、REJECT 或其他失效的策略組。
4. 測試後請切回 Rule。Global 是用來定位問題的工具，不是適用於所有流量的永久修復方式。

修改規則時要留意優先順序。將新的網域規則放在兜底 MATCH 之後，通常不會生效，因為請求已被前面的規則接手。需要保留的修改，應放在用戶端支援的覆寫或規則合併位置；直接修改遠端訂閱產生的檔案，可能在下次更新時被覆寫。規則比對方式請參閱規則分流教學。

六、確認節點與目標網站狀態

延遲測試通過，只能證明某次探測在指定逾時時間內完成，不代表目標網站一定可用。例如清單顯示 180 ms，實際頁面卻在 20 秒 後逾時，兩者並不矛盾：探測位址、連線協定、出口限制和目標服務可能都不同。這些數值僅供判讀示範，並非節點實測結果。

• 所有節點都失敗：確認訂閱是否到期、帳戶流量是否用盡、目前設定是否已啟用，以及服務端是否發布維護公告。
• 只有一個節點失敗：切換至同一訂閱中的其他節點，再造訪相同目標。切換節點時不要同時修改 DNS，否則無法判斷是哪項變更解決了問題。
• 只有一個網站無法開啟：檢查目標網站狀態和地區限制。如果節點可存取其他 HTTPS 網站，就不應直接歸因於本機連接埠。
• 出現驗證或交握錯誤：確認訂閱是否已更新、節點憑證是否有效，以及核心是否支援該協定和參數。
• 出現憑證錯誤：先校正系統日期、時區並檢查憑證環境。請勿關閉憑證驗證來掩蓋問題。

切換 Wi-Fi 和手機熱點是很有用的對照測試：使用相同用戶端、相同節點和相同網址，若只有目前的網路失敗，就應進一步檢查該網路的存取限制、UDP 支援或 DNS 路徑。熱點會使用行動數據，測試前請留意流量費用。

依據現象決定下一步

問題仍未解決時，提供最精簡的診斷記錄

向維護者回報時，請提供作業系統、用戶端版本、核心版本、故障時間、代理模式、接管方式和重現步驟。附上故障發生前後約 30 秒 的必要記錄，並說明「明確指定代理是否成功」、「關閉 TUN 後是否恢復」及「Global 模式是否可存取」。這些資訊比一張顯示「已連線」的截圖更有助於定位問題。

傳送前請刪除訂閱權杖、節點密碼、控制介面金鑰和不必要的個人瀏覽記錄。排查完成後，請還原暫時變更、關閉除錯記錄，並確認系統代理指向目前仍在執行的用戶端。其他常見錯誤請參閱疑難排解；訂閱匯入和啟用設定的步驟請參閱訂閱匯入教學。