1. 先確認設定檔與核心已啟動
Clash 用戶端視窗能開啟，不代表代理核心已在執行。首次設定時，請分別確認四件事：設定檔載入成功、本機連接埠正在監聽、出站策略可用，以及目標應用程式確實將連線交給代理。依序檢查，就能避免把連接埠問題誤認為訂閱失效。
本文以桌面版常見的 HTTP/SOCKS 混合連接埠 7890 為範例，這並非所有用戶端的固定預設值。ClashX、Clash Verge Rev 與其他使用 mihomo 核心的用戶端，設定位置及覆寫方式可能不同；請以目前用戶端顯示的有效設定與啟動記錄為準。
- 前往用戶端的「設定」或「Profiles」，確認已選取一份設定檔，而不只是完成訂閱下載。
- 前往「代理」或「Proxies」，確認有可選取的代理節點與策略群組。只有
DIRECT並不能證明代理訂閱已生效。 - 開啟「記錄」或「Logs」，查看設定解析結果、監聽位址，以及是否有啟動失敗或連接埠繫結失敗的訊息。
- 記下目前使用的核心類型、混合連接埠、執行模式與系統代理狀態。之後每次只調整一項。
2. 混合連接埠：確認監聽位址與占用程序
mixed-port 可讓 HTTP 代理與 SOCKS 代理共用一個本機連接埠。瀏覽器的手動 HTTP 代理可指向此連接埠，支援 SOCKS5 的程式也能使用。這裡的「混合」不代表會自動接管所有系統流量，也不表示本機所有應用程式都會使用代理。
以下是設定欄位的最小範例，用來說明各項用途，並非可直接連線的完整訂閱。既有設定中不要重複加入同名的頂層鍵；若用戶端透過覆寫產生設定，請在相應的覆寫位置修改，而非編輯會在訂閱更新時被取代的快取檔案。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info若只在本機使用，請先維持 allow-lan: false。查看記錄中的監聽位址是否為本機回送位址，例如 127.0.0.1:7890。實際繫結情況也會受到用戶端與核心設定影響，請勿只憑單一開關推斷監聽範圍。
Windows：用處理程序 ID 確認連接埠歸屬
在 PowerShell 中執行以下命令。第一個命令會找出正在監聽 TCP 7890 的處理程序 ID，第二個命令可將 ID 對應至處理程序名稱；請先將範例 ID 1234 替換成實際數值再執行。
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 1234若連接埠由另一款代理工具占用，請先正常退出該工具，或替目前用戶端改用其他未占用的連接埠。請勿直接結束不熟悉的系統處理程序。若改用 7891，系統代理、瀏覽器個別設定及命令列測試也都必須同步修改。
macOS 與 Linux：檢查監聽狀態，不要只看視窗
# macOS：顯示正在監聽 TCP 7890 的處理程序
lsof -nP -iTCP:7890 -sTCP:LISTEN
# Linux：顯示正在監聽 TCP 7890 的通訊端
ss -ltnp 'sport = :7890'部分處理程序資訊需要相應權限才能顯示。若查不到監聽資訊，而記錄顯示 address already in use，請檢查實際發生衝突的連接埠；若記錄顯示設定解析失敗，請先回到設定檔找出錯誤。網頁無法開啟時反覆切換節點，無法解決核心尚未開始監聽的問題。
3. 出站模式：分別確認規則、全域與直連
模式決定「進入核心的連線要如何選擇出站」，系統代理則決定「應用程式是否將連線送進核心」。兩者是獨立的設定。即使選擇全域模式，不遵循系統代理、也未由 TUN 接管的應用程式仍可能直接連線。
| 模式 | 實際作用 | 首次排查用途 |
|---|---|---|
| 規則 / rule | 依規則順序比對，採用第一條符合的策略 | 日常使用；檢查目標網域符合哪條規則 |
| 全域 / global | 進入核心的連線使用全域策略所選的出站方式 | 暫時排除規則分流差異，仍須檢查全域群組的選擇 |
| 直連 / direct | 進入核心的連線直接連線，不經代理 | 比較本機網路路徑，不適合用來驗證代理節點 |
- 先使用規則模式，並在實際命中的策略群組中選定一個明確節點，暫時減少自動選擇造成的變數。
- 開啟目標網站，同時查看「連線」頁面的網域、命中規則與出站鏈。若看到
DIRECT，請先確認這是否符合規則設計。 - 若要排除規則的影響，可暫時切換至全域模式，並確認全域策略未選擇直連。測試完成後請恢復規則模式。
節點延遲測試成功，只能表示該次探測條件下有可用回應，不代表所有網站、UDP 或應用程式通訊協定都能使用。若只有特定網站無法連線，應根據該連線的記錄排查，不能只看延遲數值就判定整份訂閱失效。
4. 桌面系統代理：同時確認開關與實際位址
系統代理通常會提供 HTTP 代理位址給支援這項設定的應用程式，並非全域網路通道。首次測試可先關閉 TUN，只驗證系統代理的連線路徑；若同時啟用瀏覽器代理擴充功能、另一款 VPN 與 TUN，連線路徑會更難判斷。
Windows 11
開啟「設定」→「網路和網際網路」→「Proxy」，查看「使用 Proxy 伺服器」。用戶端啟用系統代理後，請確認位址與連接埠對應有效的監聽服務，例如 127.0.0.1 和 7890。若同時啟用「使用設定指令碼」，也要確認 PAC 指令碼是否參與代理選擇，避免將指令碼的結果誤當成手動代理的結果。
部分應用程式使用個別代理設定或 WinHTTP 設定，不一定會遵循這裡的設定。命令 netsh winhttp show proxy 顯示的是 WinHTTP 代理，並非 Windows 設定頁面中目前使用者代理的完整映像；兩者不同時，請勿因此就盲目執行重設。
macOS
在較新的 macOS 中，前往「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「代理伺服器」。確認網頁代理（HTTP）、安全網頁代理（HTTPS），以及有需要時的 SOCKS 代理設定是否正確。ClashX 選單列中的系統代理選項，也應與目前網路服務的設定一併核對。
可使用 scutil --proxy 查看目前的代理資訊。HTTP 與 HTTPS 代理都指向混合連接埠是常見設定；此處的 HTTPS 代理設定通常仍透過 HTTP CONNECT 建立通道，不需要將本機代理位址寫成 https://127.0.0.1:7890。
Linux 桌面環境
以 GNOME 為例，前往「設定」→「網路」→「網路代理」，選擇手動模式，並確認 HTTP、HTTPS、SOCKS 的位址與連接埠。其他桌面環境的設定位置可能不同，而且並非所有程式都會讀取桌面代理設定。終端機中的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 也可能另外影響命令列程式。
5. Android、iOS 與 TUN：確認流量接管範圍
行動裝置通常透過系統 VPN 介面接管流量，不能直接套用桌面端「開啟系統 HTTP 代理」的檢查方式。Android 用戶端首次連線時通常會要求建立 VPN 連線；iOS 用戶端則可能要求加入 VPN 設定。請確認要求來自剛安裝且正在操作的用戶端，再授予權限。
- Android：確認 VPN 服務已啟動，再查看是否啟用分應用程式代理、排除特定應用程式或僅代理指定應用程式。若應用程式被排除，即使用戶端顯示已連線，也不會如預期透過該代理路徑連線。
- iOS：前往「設定」→「一般」→「VPN 與裝置管理」→「VPN」，確認目前的連線。具體的策略群組、規則與記錄仍需回到用戶端查看。
- 桌面 TUN：通常需要服務模式、管理員權限或相應的系統授權。請以用戶端記錄確認虛擬介面是否建立成功、路由是否已設定，不要只看開關顏色。
- 其他 VPN：行動作業系統通常會限制一般 VPN 服務同時執行。工作設定檔、企業管理與依應用程式設定的 VPN 可能另有規則，切換前請先確認裝置管理要求。
TUN 接管 IP 流量後，仍須考慮路由、DNS 與應用程式排除設定。使用 Fake-IP 時，DNS 請求必須進入適當的解析路徑，虛擬位址相關流量也需要回到核心處理。請勿為了修復單一應用程式，就一次修改系統 DNS、Fake-IP、路由規則與 MTU。
若系統代理可用但 TUN 無法使用，請優先檢查權限、虛擬介面、路由衝突與 DNS；若 TUN 可用但瀏覽器的手動代理失敗，請優先檢查本機監聽狀態與瀏覽器設定。分層比較比同時重新安裝所有元件更有效。
6. 設定防火牆：區分本機存取與區域網路共用
在本機瀏覽器存取 127.0.0.1:7890，與透過區域網路讓手機使用電腦的代理，是兩種不同情境。前者通常不需要為了「修復代理」而額外開放對外的連入連接埠；後者則需要用戶端允許區域網路連線、監聽位址設定正確，並由防火牆允許可信任的網段存取。
- 先只在電腦本機完成測試，維持區域網路共用關閉，以排除網路隔離與連入規則的影響。
- 確實需要共用時，請確認手機與電腦位於可互相存取的同一個網路，再使用電腦的區域網路位址。手機上的
127.0.0.1指向手機本身，不是電腦。 - 在 Windows「Windows 安全性」→「防火牆與網路保護」→「允許應用程式通過防火牆」中確認應用程式設定。只針對實際需要的可信任網路允許存取，不要連公用網路也一併開放。
- 若 Linux 啟用了 UFW 或其他防火牆，請依可信任的來源位址與特定連接埠設定規則。請勿將關閉整個防火牆當作長期解決方案。
安全性軟體也可能封鎖核心程序的對外連線或 TUN 驅動程式操作。請核對封鎖記錄中的執行檔路徑與時間，再決定是否授權。開放連接埠不代表節點可用，也不代表網域解析正常，仍須回到連線記錄確認。
7. 透過一次明確的請求完成驗證
瀏覽器可能重複使用連線、讀取快取或使用擴充功能代理。若要先驗證本機 HTTP 代理入口，可在終端機執行以下命令。範例會連線至公開的文件範例網域，不代表任何代理節點的實際表現。
# Windows PowerShell：明確呼叫 curl.exe
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com--noproxy "" 可避免既有的略過清單讓本次請求繞過代理。連線逾時設為 10 秒，總耗時上限設為 20 秒，方便固定測試條件。收到回應標頭表示這次請求路徑有收到回應；仍須在用戶端確認使用的是代理節點還是直連。只看到 200 Connection established，還不能證明後續 TLS 連線與目標 HTTP 回應都已完成。
| 狀況 | 優先檢查 | 下一步 |
|---|---|---|
| 連線至本機連接埠遭拒 | 核心未啟動、位址或連接埠錯誤 | 檢查監聽程序與啟動記錄 |
| 用戶端收到連線，但出站逾時 | 所選節點、節點伺服器解析、網路路徑 | 固定使用同一節點，再重試相同目標 |
| 命令列成功，瀏覽器失敗 | 瀏覽器個別代理、擴充功能、快取與系統代理 | 確認瀏覽器實際使用的代理來源 |
| 瀏覽器可用，部分應用程式失敗 | 應用程式不遵循系統代理、UDP 或分應用程式設定 | 檢查應用程式設定，再單獨測試 TUN |
保留可重現的檢查記錄
最後記下用戶端與核心版本、作業系統版本、連接埠、模式、策略群組選擇，以及測試時間。需要進一步尋求協助時，提供測試時間附近的錯誤行，比提交整份記錄更容易找出問題。公開截圖前，請隱藏訂閱網址、權杖、節點憑證與個人網路資訊。
- 設定檔已成功載入，本機混合連接埠有明確的監聽程序。
- 在規則模式下，能確認目標連線命中的規則與出站策略。
- 已確認系統代理或 VPN/TUN 的流量接管方式，沒有將兩者混為同一個開關。
- 防火牆授權範圍符合實際需求，退出用戶端後也不會留下失效的代理設定。
完成這四項檢查後，再逐步啟用自動選擇、區域網路共用或更複雜的 TUN 設定。若需補充安裝與訂閱操作，可參閱首次設定教學；相關術語可在術語表中查閱。