Clash 常見問題

Clash 是代理工具生態系中的專案名稱；mihomo 是相容於 Clash 設定體系並持續擴充功能的核心。圖形化用戶端負責管理訂閱、選擇策略、設定系統代理及顯示記錄，實際連線通常由核心處理。同一用戶端的不同發行版本也可能搭載不同核心，因此不能只憑介面名稱判斷是否支援特定欄位。排查前，先在關於頁面或啟動記錄中確認用戶端名稱、核心名稱與版本，再查閱相應的設定文件；不要將其他核心的設定區段直接混入目前的檔案。

日常使用通常選擇規則模式，連線會依 rules 順序由上而下比對，再交由指定的策略群組、DIRECT 或 REJECT 處理。全域模式會將由用戶端接管的連線交給全域策略，但不代表所有程序都會自動使用代理；接管範圍仍由系統代理或 TUN 決定。直連模式則讓已接管的連線直接存取目標，可用來對照排查。測試時只切換模式，不要同時修改 DNS 和節點；比較同一目標的連線記錄，才能判斷差異來自分流規則還是出口。

用戶端是用來連線與分流的工具，安裝後不會自動取得可用出口。訂閱應來自自行維護的伺服器、所屬組織提供的服務，或已明確授權的服務供應商。公開流傳的免費節點可能很快失效，也可能記錄連線資訊，不適合用於敏感業務。匯入前請確認來源、有效期限與適用的用戶端；本站不提供節點訂閱。訂閱網址通常含有帳戶識別資訊，應視同憑證妥善保管；求助時請遮蔽完整網址、節點密碼和個人資料，不要直接公開設定檔。

系統代理會向作業系統登記 HTTP 或 SOCKS 代理入口，應用程式是否使用該入口，取決於自身的網路實作；部分遊戲、命令列程式和使用自有網路堆疊的應用不會遵循系統代理。TUN 透過虛擬網路介面與路由接管流量，涵蓋範圍通常較廣，但需要相應權限，也要協調 DNS、路由和其他 VPN。建議先用系統代理確認基本連線正常，再依應用需求啟用 TUN。TUN 不是節點加速功能，無法修復出口失效、訂閱過期或伺服器拒絕連線等問題。

先記下更新記錄中的 HTTP 狀態碼與解析錯誤。403 通常代表伺服器拒絕請求，具體原因需向服務供應商確認；請檢查帳戶狀態、訂閱期限及用戶端類型。若解析失敗，請確認網址回傳的是相容的設定檔，而不是登入頁、錯誤頁或一般節點清單。如果用戶端支援選擇透過直連或代理更新，可各測試一次，避免因下載連線無法存取而誤判訂閱失效。保留仍可使用的舊設定，不要反覆刪除重建；回報供應商時，只提交已遮蔽敏感資訊的錯誤內容。

先檢查錯誤行號附近的縮排、冒號和清單項目短橫線。YAML 使用空格縮排，請勿混用定位字元。接著區分語法錯誤與欄位驗證錯誤：前者會導致檔案無法解析；後者通常是策略名稱不存在、節點欄位缺漏，或目前的核心不支援某項功能。檢查 proxy-groups 和 rules 引用的名稱是否完全一致，並確認 MATCH 位於規則末尾。每次只修改一處，儲存後使用用戶端提供的設定檢查功能；含有帳戶資訊的檔案不應上傳至公開的線上解析工具。

先查看記錄，分辨是建立虛擬介面失敗、權限不足還是路由衝突。Windows 用戶端通常需要安裝或啟動服務模式，部分用戶端也支援以系統管理員權限執行；macOS 可能需要授權輔助服務，Linux 則視服務權限及 /dev/net/tun 是否可用而定。請依目前用戶端的說明授予最低限度的必要權限，不要照抄來源不明的指令碼。關閉其他正在接管路由的 VPN 後再試；若介面已建立但仍無法連線，應改查 DNS 和路由，不要一再提高權限。

若需要系統匣、訂閱管理和圖形化策略選擇，建議優先選用圖形化用戶端；伺服器和路由器使用者則可依環境部署 mihomo 核心。先執行 uname -m 確認架構：x86_64 通常對應 AMD64，aarch64 通常對應 ARM64；再依發行版選擇 deb、rpm 或專案實際提供的其他格式。不要只憑處理器品牌判斷安裝套件。安裝完成後，還要確認桌面相依套件、服務權限與設定路徑；核心能啟動不代表系統已接管流量，仍須檢查代理入口或 TUN 路由。

在連線面板中找到實際請求，核對目標網域、目標 IP、命中的規則和最終出口，不要只看瀏覽器網址列。規則會依序比對，較寬泛的 DOMAIN-KEYWORD、GEOIP，或提早出現的 MATCH，都可能優先於後面的精確規則。若連線只顯示 IP，網域規則也可能受到 DNS 對應或嗅探結果影響。可暫時新增精確的網域規則，並將其放在相關的寬泛規則前，再關閉舊連線並重新發出請求。確認命中後再整理長期規則，不要直接切換全域模式來取代分流檢查。

直接編輯由訂閱產生的設定檔，可能會在下次更新時被遠端內容覆蓋。若要長期保留規則、DNS 或策略調整，應使用目前用戶端支援的覆寫、合併或設定指令碼機制，並先確認它處理的是完整設定檔還是局部片段。特別留意陣列可能會被取代，而非附加項目；規則插入的位置也會影響比對結果。修改前先備份原設定，更新後檢查最終生效的設定，而不只是編輯器中的內容。不要原樣複製其他用戶端的覆寫語法，各用戶端的合併方式並不相同。

先分清楚登入後啟動用戶端、背景服務隨系統啟動，以及啟動後恢復系統代理；這三項不一定由同一個開關控制。桌面使用者可先在用戶端啟用開機啟動，再確認代理設定是否保留；使用 TUN 時，也要檢查必要服務能否自動啟動。重新開機後，查看程序、目前的設定和一筆實際連線記錄，不要只看系統匣圖示判斷是否成功。Linux 的 systemd 服務也應檢查執行使用者與設定路徑。若啟動時網路尚未就緒，導致訂閱更新失敗，可在連線後手動更新確認。

先讓電腦與裝置連上彼此可通訊的區域網路，在用戶端啟用允許區域網路連線，並檢查 allow-lan、bind-address 和實際監聽連接埠。裝置端的代理位址應填入電腦的區域網路 IP，不能填 127.0.0.1；連接埠則填入目前設定中的 HTTP 或 mixed-port。若仍無法連線，請檢查防火牆的輸入規則、訪客網路隔離，以及電腦位址是否已變更。只在可信任的網路中開放監聽，視需要設定 authentication，並限制可連線的來源。不要將代理連接埠直接公開至網際網路，也不要為了排查而整體關閉防火牆。

先關閉代理，確認本機基本網路是否能正常連線，再檢查訂閱是否過期、節點位址能否解析，以及系統時間是否正確。延遲測試失敗只代表該次測試請求未完成，不能單獨證明節點完全無法使用；應搭配實際網頁請求與核心記錄判斷。若只有某個節點失敗，可切換至其他已知可用的出口；若全部失敗，則優先檢查 DNS、網路限制、驗證資訊及其他 VPN 衝突。在不同網路環境分別測試有助於定位問題，但每次只變更一個條件，並保留錯誤發生時的記錄。

先確認核心正在執行，且監聽連接埠與系統登記的值一致，再查看連線面板是否出現該應用程式的請求。瀏覽器可能使用獨立的代理擴充功能或自己的設定；命令列工具也可能只讀取 HTTP_PROXY、HTTPS_PROXY 等環境變數。變數名稱中有 HTTPS，不代表入口必須使用 HTTPS 協定。檢查代理略過清單、舊代理軟體和應用程式層級的設定，調整後重新啟動目標程式。若應用程式不遵循系統代理，可設定專用代理入口，或在基本連線正常後使用 TUN，並再次確認流量接管範圍。

部分 AppContainer 應用程式受到回環隔離限制，無法直接連線至本機代理入口。先確認一般瀏覽器能使用同一個代理，再使用用戶端提供的 UWP 回環工具，只為實際需要的應用程式設定豁免；該工具可能需要系統管理員權限。也可以在系統管理員終端機執行 CheckNetIsolation LoopbackExempt -s，查看現有豁免，但不要一次為所有應用程式開放。設定豁免後，請完全結束並重新啟動目標應用程式。若仍無法使用，繼續檢查系統代理、應用程式錯誤碼和連線記錄；回環豁免無法修復訂閱或節點故障。

先關閉 TUN，保留系統代理作為對照，再查看虛擬介面、預設路由、DNS 監聽位址和 dns-hijack 是否確實生效。若網域無法開啟但 IP 可連線，應優先檢查 DNS 解析路徑；瀏覽器安全 DNS、系統加密 DNS 或其他 VPN 都可能繞過預期路徑。fake-ip 模式需要網域對應與路由相互配合，不能只切換 enhanced-mode。修正後關閉舊連線並重新解析，再搭配連線記錄和 DNS 檢測重新測試。檢測頁面顯示的 DNS 服務位置只能作為線索，不能單憑所在地判斷是否洩漏。