1. 安裝前確認：用戶端、核心與系統架構

Clash 初次設定可分成四個環節：用戶端能啟動、設定檔能載入、本機代理連接埠能監聽，以及應用程式流量能進入代理。安裝程式順利開啟，只代表第一個環節完成。建議依序確認，再啟用 TUN、開機啟動等額外功能，排查問題會更容易。

圖形介面用戶端負責訂閱管理、代理群組選擇與系統設定；核心則負責解析設定檔、比對規則及建立對外連線。Clash、Clash.Meta 與 mihomo 並非可任意互換的版本標籤。若訂閱使用 mihomo 擴充欄位或新協定，必須搭配支援的核心；不能只看用戶端名稱判斷相容性。

  • Windows：前往「設定」→「系統」→「系統資訊」，查看「系統類型」。請依裝置架構選擇 x64 或 ARM64 安裝檔，不要只看「Windows 11」就決定。
  • macOS：開啟 Apple 選單 →「關於這台 Mac」；顯示 Apple 晶片的裝置優先選 ARM64，顯示 Intel 處理器的裝置則選 x64。
  • Android：新款裝置通常採用 ARM64，但舊款裝置或特定系統可能不同。先查閱用戶端發布說明，確認最低 Android 版本與支援架構；無法確認時，再考慮使用其提供的通用版安裝檔。

2. 匯入訂閱：下載成功不代表設定已生效

訂閱網址通常含有存取權杖，應視同密碼妥善保管。請只向可信任的服務提供者取得訂閱，不要將完整網址貼到公開截圖、線上轉換網站或問題回報中。訂閱可能回傳完整的 Clash YAML，也可能只提供節點清單；兩者的匯入方式不一定相同。

首次匯入的檢查順序

  1. 在用戶端的設定檔或訂閱頁面新增遠端設定，並貼上完整網址。各用戶端的入口名稱可能不同，請勿將網址填入代理伺服器地址欄位。
  2. 手動執行一次更新，確認是否出現設定檔解析錯誤。若頁面跳回登入畫面、顯示已過期，或回傳一般 HTML，即使下載成功，也不能當作 YAML 使用。
  3. 選取剛匯入的設定檔，並設為目前使用的設定檔。清單中出現訂閱卡片，不代表核心已切換至該設定檔。
  4. 開啟代理群組頁面，確認有可用節點，並手動選取節點或預期使用的策略。即使匯入成功，若仍選取 DIRECT，流量仍可能直接連線。
  5. 將出站模式設為規則模式，並確認規則清單不是空的，且末尾包含預期的預設策略。

若出現「不支援的代理類型」或「未知欄位」，先確認設定檔所需的核心版本。若出現 HTTP 401、403，請檢查權杖與存取權限；若出現 404，則確認網址是否完整或資源是否已移轉。不要用反覆重新安裝用戶端來取代錯誤分類。

分開管理訂閱更新與本機修改

直接編輯遠端訂閱產生的檔案，可能會在下次更新時被覆蓋。若要新增直連網域、調整 DNS 或修改連接埠，建議使用用戶端提供的覆寫、合併或本機擴充功能，並確認最後產生的設定檔。保留原始訂閱與本機修改的分界，日後才能方便復原。

3. 本機連接埠：確認監聽位址與連接埠是否被占用

系統代理必須指向用戶端實際監聽的位址與連接埠。常見範例是 127.0.0.1:7890，但 7890 並非所有用戶端的固定預設值，請以目前設定與執行記錄為準。控制介面連接埠是用來管理核心，不應填入瀏覽器的 HTTP 代理欄位。

以下是 mihomo 的本機入口設定片段，僅用來說明欄位，並非包含節點與規則的完整設定檔。mixed-port 會在同一個連接埠接收 HTTP 與 SOCKS 代理請求；限制為回送位址可避免初次設定時意外對區域網路開放入口。

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

Windows：查詢監聽中的處理程序

netstat -ano | findstr :7890

請留意本機位址為該連接埠、狀態為 LISTENING 的項目，最右欄是 PID。可在工作管理員的「詳細資料」頁面比對處理程序 ID。若占用連接埠的是另一個代理用戶端，請先正常結束舊用戶端，再啟動目前使用的用戶端；不要直接結束不熟悉的系統處理程序。

macOS：查詢 TCP 監聽狀態

lsof -nP -iTCP:7890 -sTCP:LISTEN

若沒有查到結果，請確認核心是否啟動失敗，或實際使用的連接埠是否不同。改用其他未占用的連接埠後，也必須同步更新系統代理或應用程式代理；只修改設定檔而未更新入口，瀏覽器就會出現連線遭拒。

4. Windows 與 macOS：先確認系統代理

系統代理會將遵循系統代理設定的應用程式請求轉交給本機用戶端，但不代表接管裝置的所有流量。瀏覽器通常適合用來初步測試；遊戲、命令列工具和部分應用程式可能使用獨立的網路設定。

檢查項目 Windows 11 macOS
系統設定入口 設定 → 網路和網際網路 → Proxy 系統設定 → 網路 → 目前連線 → 詳細資訊 → Proxy
首次確認項目 手動代理位址、連接埠，以及是否仍留有設定指令碼 網頁代理、安全網頁代理、SOCKS 代理的啟用狀態與連接埠
本機位址範例 127.0.0.1，連接埠請依實際監聽狀況填寫 127.0.0.1，連接埠請依實際監聽狀況填寫

建議先透過用戶端的系統代理開關套用設定，再到系統頁面確認。若設定的是 HTTP 代理入口，macOS 的網頁代理與安全網頁代理應使用對應的 HTTP 或混合連接埠；SOCKS 代理則使用 SOCKS 或混合連接埠。不要未加確認就將不同協定的入口填成同一個數值。

依功能處理權限提示

  • Windows 服務模式：部分用戶端會透過背景服務執行 TUN 等需要權限的功能。只有確實需要時才安裝服務，並確認系統授權提示中的程式來源。
  • macOS 輔助元件：寫入系統代理或建立虛擬網路介面時，用戶端可能會要求授權。若授權失敗，請檢查元件狀態；不要反覆以管理員身分啟動整個應用程式來掩蓋問題。
  • 系統阻止啟動：先確認下載來源，並查看系統提示的具體原因。不要為了執行單一安裝檔而全面停用系統安全機制。

5. Android：VPN 授權與背景執行

Android 用戶端通常透過系統 VPN 介面接管流量，並非沿用桌面版的系統代理開關。首次點選連線時，系統會顯示 VPN 授權提示；允許後才能建立介面。狀態列出現 VPN 圖示，只代表介面已建立，無法證明節點、DNS 與規則都正常。

  1. 先確認其他 VPN 已中斷連線。同一使用者或工作設定檔中的其他 VPN、防火牆與流量過濾應用程式，可能會與用戶端爭用 VPN 介面。
  2. 檢查應用程式範圍。若已啟用依應用程式分流，請確認瀏覽器包含在接管範圍內，並確認目前使用的是「僅限所選應用程式」或「略過所選應用程式」。
  3. 檢查背景執行限制。可從「設定」→「應用程式」→對應用戶端→電池相關設定著手，允許必要的背景活動。實際選單會因裝置品牌而異；通知權限也應依用戶端需求設定。
  4. 測試鎖定螢幕後是否恢復。連線後鎖定螢幕數分鐘，再解鎖並開啟網頁，觀察用戶端通知、連線狀態與記錄是否持續正常。若只有在前景時可用，請優先檢查省電策略。

初次設定時，請勿同時啟用「一律開啟 VPN」與「封鎖未使用 VPN 的連線」。後者會在 VPN 未連線時封鎖其他網路路徑，讓更新訂閱與排查問題變得更複雜。常見入口為「設定」→「網路和網際網路」→「VPN」→對應連線的設定；部分品牌可能使用不同的選單名稱。

若一般網路連線正常，但連線後出現網域名稱解析失敗，再檢查 Android 私人 DNS 與用戶端 DNS 設定。可分別測試自動、指定服務提供者或關閉等狀態，每次只更動一項並記錄結果；不要將關閉私人 DNS 當成所有裝置都必須採用的設定。

6. 流量驗證：逐層確認連接埠與規則

節點延遲測試成功，不代表所有應用程式都已接入代理。延遲測試使用的目標、協定與實際瀏覽的網站可能不同。較可靠的做法是同時查看本機入口、用戶端連線記錄與目標網頁。

桌面版明確指定代理測試

在 Windows 使用以下命令，可避開 PowerShell 中可能存在的同名別名。macOS 可將 curl.exe 改為 curl。請將連接埠改成目前用戶端實際監聽的 HTTP 或混合連接埠。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

此處的 10 秒連線逾時與 20 秒總逾時是排查問題時使用的參數，不是速度測試結果。收到 HTTP 回應，代表這次明確指定代理的請求已完成；但流量仍可能依規則直連。若要確認是否經過所選節點，還需查看連線詳細資料中的規則比對結果與最終出站。

  • 連線遭拒：先檢查本機連接埠、監聽中的處理程序與核心啟動記錄。
  • 沒有連線記錄：確認應用程式是否使用系統代理、獨立代理設定，或遭依應用程式分流規則排除。
  • 命中 DIRECT：檢查目前模式、網域規則與規則順序，不要直接認定節點失效。
  • 代理交握或驗證失敗：確認訂閱狀態、節點憑證、協定支援與裝置時間。
  • 網域名稱解析失敗：檢查 DNS 記錄、上游連線狀況與目前網路；請與 TCP 連接埠無法連線的問題分開排查。

完成基本驗證後再啟用 TUN

若瀏覽器已能透過系統代理正常運作，但特定應用程式不遵循代理設定，再考慮啟用 TUN。TUN 透過虛擬網卡與路由接管符合條件的流量，通常也會涉及 DNS 接管與權限。TUN 的涵蓋範圍仍受路由、排除項目及平台限制，不能簡單理解為「開啟後所有流量都會經過節點」。

啟用後若出現區域網路裝置無法存取、其他 VPN 中斷或網路迴圈，請先關閉 TUN、恢復原本狀態，再檢查路由與排除設定。不要在同一輪測試中同時更換節點、修改 DNS、切換核心與調整 TUN 網路堆疊，否則很難判斷是哪項變更生效。

7. 開機啟動與重新啟動驗收清單

基本連線穩定後，再設定開機啟動。用戶端視窗自動開啟、背景核心執行、系統代理恢復與 VPN 自動連線是不同狀態；勾選一個自動啟動選項，不一定能同時完成這四件事。Android 的應用程式自動啟動與 VPN 自動連線，也可能由不同機制控制。

Windows 可前往「設定」→「應用程式」→「啟動」，確認啟動項目；macOS 可在「系統設定」→「一般」→「登入項目」檢查允許的登入項目與背景項目。若用戶端內建自動啟動管理功能，請避免再手動新增重複的啟動項目，以免多個執行個體爭用同一個連接埠。

  1. 記錄目前設定：記下使用的設定檔名稱、節點策略、代理連接埠及是否啟用 TUN。
  2. 重新啟動裝置：確認用戶端與核心確實執行，並檢查是否出現連接埠占用、授權或設定檔解析錯誤。
  3. 確認流量接管狀態：桌面版檢查系統代理；Android 檢查 VPN 連線與依應用程式分流範圍。
  4. 開啟網頁並檢查：分別開啟預期直連與預期經代理的目標，查看規則比對結果與最終出站，不要只測試單一網頁。
  5. 確認退出後網路恢復：正常關閉代理功能後，確認基本網路仍可使用；保留系統代理與 VPN 設定入口，以便異常結束後復原。