Clash 蘋果版疑難排解指南

無法上網：先區分直連與代理連線

建議先暫停代理連線，進行基準測試，而不是馬上重新安裝。關閉用戶端的系統代理與 TUN，再結束用戶端；在 iPhone 上則中斷對應的 VPN。使用瀏覽器開啟平時可直接連線的網站，並檢查同一網路上的另一台裝置。如果兩台裝置都無法上網，優先檢查 Wi-Fi、路由器或電信業者網路；如果只有目前裝置故障，先檢查殘留代理、其他 VPN 與本機 DNS。基準連線恢復前，節點測試結果沒有可靠的比較意義。

建立可重現的本機網路基準

在 macOS 開啟「系統設定 → 網路」，確認目前使用 Wi-Fi 或乙太網路。飯店、機場與校園網路可能需要透過網頁驗證；連上 Wi-Fi 不代表已取得網際網路存取權。暫時中斷 VPN，完成驗證後再恢復代理。系統時間也應正確；時間偏差可能導致 TLS 憑證驗證失敗，症狀通常是多個 HTTPS 網站同時出錯，而非單純 Wi-Fi 斷線。

接著只啟動一個代理用戶端，先不要開啟 TUN。確認已選取設定檔且核心正在執行，再啟用系統代理。多個 App 同時修改系統代理，可能留下指向已結束程序的位址；同時啟用多條隧道，也會讓路由歸屬更難判斷。若必須保留工作用 VPN，測試時請明確記錄其開關狀態，每次測試都要維持一致。

透過明確指定代理，區分本機入口與遠端出口

以下指令分別用來略過代理進行直連，以及指定本機 HTTP 代理，兩者都只會讀取回應標頭。連接埠 7890 僅供示範，請改成用戶端實際顯示的混合連接埠。測試目標可換成已知可連線的網站；指令成功只代表該目標的這條連線可用，不代表所有 App、UDP 或規則都正常。

# macOS：略過代理環境變數，測試直連
curl -I --noproxy '*' --connect-timeout 10 --max-time 20 https://www.apple.com/

# 明確指定用戶端實際監聽的混合連接埠
curl -I --proxy http://127.0.0.1:7890 --noproxy '' \
  --connect-timeout 10 --max-time 20 https://www.apple.com/

如果明確指定代理後立刻出現連線遭拒，問題通常出在本機入口：核心未執行、連接埠填錯或監聽失敗。如果等候一段時間後逾時，請查看用戶端連線記錄，確認流量命中的策略與節點。如果明確代理可用、瀏覽器卻無法連線，請優先排查系統代理失效，不要反覆測試遠端節點。如果直連正常、代理失敗，問題範圍已縮小至設定、規則與遠端連線。

判斷規則、DNS 與隧道問題

暫時將規則模式切換為全域模式，明確選取已知可用的代理節點，再造訪同一個目標。如果全域模式正常、規則模式失敗，請檢查目標網域的比對規則、策略群組選擇與直連出口；測試後請切回規則模式。全域模式只會改變分流策略，不會自動讓未讀取系統代理的 App 改走用戶端，也無法據此證明 TUN 已正常運作。

如果瀏覽器顯示找不到伺服器，請先查看DNS 章節；如果只有開啟 TUN 後才無法連線，請關閉 TUN 再測試，並檢查輔助服務、預設路由與 DNS 劫持是否和其他隧道衝突。此時不要同時手動修改閘道、清除所有網路服務或刪除系統檔案。先回到「系統代理可用」的最小設定，再逐項擴大接管範圍。

節點逾時：區分連線測試失敗與實際連線失敗

節點延遲顯示逾時，不代表節點一定離線。延遲測試通常是經由節點連線至某個測試位址，結果會同時受到測試目標、DNS、節點出口與逾時設定影響。先選取該節點，分別用瀏覽器與明確指定代理造訪兩個不同目標，再檢查連線記錄。若只有測試失敗、實際網頁正常，請檢查測試位址與測試方式；實際連線也失敗時，再檢查伺服器連線與通訊協定參數。

確認故障發生在哪個階段

記錄中的連線遭拒、連線逾時、憑證錯誤與驗證失敗，代表不同問題。連線遭拒通常表示目標位址可連線，但對應連接埠未接受連線；連線逾時可能是網路封包遺失、防火牆或位址無法連線；驗證失敗通常與密碼、使用者識別資訊或伺服器設定有關；憑證錯誤則應檢查時間、伺服器名稱與信任鏈。保留一筆完整錯誤訊息及前後相關記錄，避免只截取畫面上的「失敗」兩字。

先確認目前選取的是特定節點，還是自動選擇、故障轉移或負載平衡策略群組。策略群組畫面顯示的名稱，不一定是該次連線實際使用的出口。開啟連線詳細資訊，查看目標、命中規則、策略鏈與實際節點；若流量依規則改走直連，節點測試結果與該次連線就不是同一條路徑，不應混為一談。

檢查伺服器網域與通訊協定欄位

訂閱下載正常但所有節點都逾時，應先確認節點伺服器網域能否解析，而不是直接替換所有密碼。伺服器網域的解析可能使用獨立的 proxy-server-nameserver，其路徑未必與一般網站 DNS 相同。如果解析結果包含 IPv6，而目前網路的 IPv6 連線異常，就可能出現某些網路可用、某些網路長時間等待的情況；請對照記錄中的位址類型與錯誤，再調整設定。

單一節點失敗時，請比對訂閱原始欄位，檢查位址、連接埠、傳輸方式、TLS、SNI 與用戶端核心支援情況。不要直接把節點 IP 填入 SNI，也不要為了消除憑證錯誤而啟用略過憑證驗證。使用網域驗證的通訊協定中，連線位址與憑證名稱可能有不同用途；任意替換欄位，可能讓原本的路由問題變成交握錯誤。

# 查詢特定伺服器網域的解析結果
# example.com 是示範網域，排查時請換成節點的實際伺服器網域
dscacheutil -q host -a name example.com

# 僅測試 TCP 連接埠是否可連線，不驗證代理驗證或 UDP
nc -vz -G 5 example.com 443

上述 TCP 測試成功，只代表 TCP 連線建立成功，不能證明代理通訊協定驗證、UDP 轉送或目標網站可連線；對於以 UDP 為基礎的通訊協定，這項測試甚至不能驗證相同的傳輸方式。不要據此判定伺服器完全正常。若指令失敗，也應確認使用的是真正連接埠，並依目前網路是否允許該傳輸類型來判讀。

透過不同網路比對，定位外部限制

維持節點與設定不變，分別透過家用 Wi-Fi 與手機熱點測試。熱點正常、原網路失敗，表示應檢查原網路的存取策略、UDP 限制或路由品質；兩種網路都失敗但其他節點正常，則問題較可能出在該節點或伺服器參數。避免短時間內高速測試大量節點，這可能觸發伺服器限制、增加連線負載，也會影響判斷。

如果目前核心不支援所需通訊協定，請透過下載頁選擇仍在維護且支援該通訊協定的用戶端；Apple 裝置可優先考慮 Clash Plus，再依使用情境比較其他方案。核心名稱與用戶端介面並非同一概念，詳情請參閱Clash、Meta 與 mihomo 核心差異。更換用戶端前請保留原設定；更換後只測試同一節點，避免把選型變更誤當成網路已修復。

訂閱失敗：分別檢查下載、解析與啟用

訂閱故障至少分為三個階段：遠端內容下載失敗、下載內容不是有效設定，以及有效設定未啟用。先確認錯誤屬於哪個階段。HTTP 狀態異常、連線逾時與憑證失敗通常發生在取得階段；YAML 行號、欄位類型與不支援的通訊協定通常屬於解析階段；更新成功但節點沒有變化，則應檢查目前選取的設定檔、覆寫規則與代理提供者快取。反覆刪除訂閱容易失去排查線索，不應當作第一步。

下載階段：網址、權限與更新連線

請向服務提供者重新複製完整訂閱網址，檢查前後空格、換行，以及通訊軟體替換過的符號。帶有查詢參數的網址可能包含存取憑證，切勿貼到公開討論區，也不要交給不明的線上轉換網站。瀏覽器能開啟服務商首頁，不代表訂閱介面授權有效；首頁、登入狀態與訂閱下載介面通常是各自獨立的授權路徑。

狀態碼 401 或 403 通常需要檢查授權、有效期限或存取策略；404 可能表示路徑已變更或網址失效；429 表示請求過於頻繁，應等待一段時間，而不是持續點選更新。如果回應狀態成功，但內文是登入頁、驗證頁面或錯誤說明，仍不能視為 YAML 設定匯入。查看用戶端提供的回應摘要即可，記錄中不要保留完整憑證。

部分用戶端可指定訂閱更新時採用直連或代理。首次匯入時，目前代理可能尚不可用，形成「需要訂閱才能連線、需要連線才能更新」的循環。在允許的網路環境中，可改用直連更新，或透過已可用的獨立連線取得設定；不要未經判斷就讓更新請求持續經過故障中的節點。變更連線方式後只更新一次，並記錄錯誤是否改變。

解析階段：區分節點字串與完整 YAML

通用 Base64 節點字串、單一通訊協定連結與 Clash YAML 並非相同格式。完整設定可能包含 proxies、proxy-groups、rules 等欄位；節點清單則可能需要以代理提供者方式加入。請先確認匯入入口接受哪種格式，再決定是否轉換。相關結構請參閱訂閱格式與轉換方式，不能只憑副檔名判斷內容類型。

解析錯誤指出行號時，也應一併檢查該行與前一行：缺少冒號、使用定位字元縮排、字串引號未閉合，以及同一層級的清單縮排不一致，都可能導致下一行才出現錯誤。以下是用來理解層級關係的本機結構範例，不包含可連線的代理節點；不要用它覆蓋遠端完整設定，再期待節點自動出現。

mixed-port: 7890
allow-lan: false
mode: rule
proxies: []
proxy-groups:
  - name: 手動選取
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,手動選取

啟用階段：確認設定與覆寫來源

更新成功後，請確認目前畫面使用的確實是剛更新的設定檔。有些用戶端會將下載、儲存與啟用分成不同操作；代理提供者也可能有自己的更新週期。請查看目前策略群組的成員與載入記錄，而不只是訂閱卡片的更新時間。如果節點數量有變、規則卻沒有變，可能是範本或覆寫機制保留了本機規則，不代表遠端更新失敗。

遠端設定通常會在下次更新時被覆蓋；需要長期保留的調整，應放在用戶端支援的覆寫、合併或擴充設定中。排錯時先停用非必要的覆寫並保留原始檔案副本，再載入原始訂閱進行比較。如果原始設定可運作、合併後卻出錯，請逐項恢復覆寫以找出衝突；不要同時修改遠端檔案與本機範本，否則難以確認最後生效的內容。

網速慢：分開測量延遲、傳輸速度與 App 行為

低延遲不代表大型檔案下載一定快，高延遲也不一定代表傳輸速度慢。網頁體驗還會受到 DNS、交握次數、資源數量與目標服務限制影響。排查前先描述症狀：是首次開啟慢、持續下載慢、影片緩衝，還是只有特定 App 變慢。比較時請維持同一裝置、網路、目標與相近時段，避免直接比較不同測速站或不同內容傳遞網路的結果。

建立最精簡的測試矩陣

先關閉代理，造訪可直連的目標，確認本機 Wi-Fi 與寬頻沒有明顯瓶頸。接著固定一個節點，比較明確指定代理與一般瀏覽器連線至同一目標的結果；再只更換節點，重複相同測試。如果所有節點都慢、直連卻正常，請檢查用戶端的流量接管方式與本機負載；如果只有一個節點慢，則應優先檢查節點出口到目標的路線，而不是調整整個系統網路。

也請查看「活動監視器」中的 CPU、記憶體與網路頁面。背景同步、系統更新與雲端硬碟上傳可能占滿上傳頻寬，進而拖慢網頁的確認封包；這不一定會呈現下載頻寬滿載。暫停已確認的大流量工作後再測試即可，不要結束不明的系統程序。診斷記錄也不宜長時間維持最詳細等級；頻繁寫入會增加系統負擔，並累積敏感連線資訊。

辨別 DNS、交握與下載階段

可使用以下指令輸出 DNS、TCP、TLS 與總耗時，作為排查線索。透過 HTTP 代理連線時，部分欄位描述的是連到本機代理的過程；目標網域也可能由代理端解析，因此不能把 time_namelookup 視為完整的遠端 DNS 耗時。請搭配用戶端記錄判斷卡在哪個階段，不要只憑單一數值下結論。

curl --proxy http://127.0.0.1:7890 --noproxy '' \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -sS \
  -w 'dns=%{time_namelookup}\ntcp=%{time_connect}\ntls=%{time_appconnect}\nfirst=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.apple.com/

如果 TLS 很快，但等待伺服器首位元組的時間很長，值得進一步檢查目標伺服器回應與出口路徑；如果連線階段反覆重試，則應考慮封包遺失、位址類型與節點連線狀況。單一小型請求不能代表持續傳輸速度，測速檔案也可能受到伺服器限速。不要為了取得更漂亮的數字而頻繁同時下載，這會消耗訂閱流量，也可能觸發目標服務的限制。

排查 UDP、MTU 與處理器架構差異

影片、視訊會議與遊戲可能使用 UDP 或 QUIC，一般瀏覽器 HTTPS 測試並未涵蓋這些連線路徑。請確認 App 流量是否進入 TUN、節點是否支援所需轉送，以及目前網路是否限制 UDP。如果 App 提供支援的傳輸回退選項，可暫時切換比較；不應把關閉所有 UDP 當成通用最佳化，因為這會改變 App 行為，甚至導致通話無法建立。

MTU 不相符可能造成小型請求成功、大量傳輸停頓，但它並非所有網速問題的解答。只有在切換網路、記錄與傳輸現象都支持此判斷時，才在支援該設定的 TUN 設定中小幅調整，記下原始數值並逐次測試。Apple 晶片 Mac 應優先使用 arm64 版本，以減少轉譯因素；不過更換架構不會提升遠端線路容量。選型差異請參閱用戶端評測。

最後應整理出可重現的結論，例如「同一目標透過手機熱點正常，家用網路則持續停頓」，而非「所有節點都不快」。前者能引導你檢查路由器、網路策略或連線路徑；後者仍混合了節點、目標與時間等多項因素。調整完成後，請恢復一般記錄等級，再以實際使用的 App 驗證，不要只用單次測速作為結案標準。

DNS 問題：檢查解析鏈、fake-ip 與洩漏範圍

排查 DNS 時，先回答三個問題：由誰發起查詢、查詢交給哪個解析器，以及結果由誰用來建立連線。系統 DNS、瀏覽器安全 DNS、用戶端內建 DNS 與節點伺服器網域解析，可能同時存在。網頁無法開啟不一定是解析失敗；DNS 測試頁顯示某個地區，也不一定代表查詢繞過了預期路徑。請先確認目標網域能否解析，再比對用戶端連線記錄與實際出口。

區分系統解析與用戶端解析

macOS 可使用 scutil --dns 查看解析器及其適用範圍。輸出可能包含預設、介面限定與 VPN 提供的解析器，不能只看第一項就判斷所有網域的解析路徑。公司內網網域可能依賴分域解析，任意將所有 DNS 改為公共解析器會導致內部資源無法存取。如果瀏覽器啟用了獨立的安全 DNS，也可能不走相同的系統解析路徑。

# 查看 macOS 目前的解析器及適用範圍
scutil --dns

# 透過系統介面查詢示範網域
dscacheutil -q host -a name www.apple.com

# 僅在修改設定後需要清除舊快取時執行
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

清除快取只能移除舊結果，無法修復錯誤的上游解析器或路由。dig 等工具適合查詢指定解析器，但預設行為不一定等同於 macOS App 使用的完整系統解析鏈。如果命令列與瀏覽器結果不同，請先確認查詢路徑與快取，不要直接認定其中一種工具失效。使用加密 DNS 時，也要確認解析器網域本身有可用的引導解析路徑。

了解 fake-ip 的接管條件

mihomo 的 fake-ip 模式可回傳對應位址給 App，再由核心將連線關聯至網域。這些位址不是目標伺服器的真實位址，看到它們本身不代表 DNS 遭到污染。關鍵在於後續連線是否仍由同一個核心接管；如果 App 快取了對應位址，但用戶端已結束，或系統 DNS 指向用戶端、監聽服務卻已停止，就可能出現中斷代理後仍無法上網的情況。

# mihomo DNS 片段範例；不是完整的訂閱設定
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

此範例只監聽本機迴送位址，而且選用的上游解析器必須能從目前網路連線。一般系統 DNS 設定通常無法直接填入 1053 這類自訂連接埠；只啟用這項監聽，不會自動讓所有系統查詢都進入該服務。還需要透過用戶端提供的 DNS 接管、TUN 劫持或其他明確設定串接起來。圖形介面用戶端也可能覆寫相關欄位，請以實際載入的設定與啟動記錄為準。

依症狀選擇修復方式

如果只有區域網路裝置名稱、印表機或公司網域無法連線，應檢查本機裝置探索、分域解析與 fake-ip 過濾策略，不要將所有網域都設為直連。只將已確認不相容的網域加入用戶端支援的過濾清單，並保留內部 DNS 路徑。如果節點網域也無法解析，請先修復節點的引導解析；不能依賴尚未連線成功的節點，去解析它自己的伺服器位址。

如果代理連線正常，但外部檢測顯示非預期的解析器，請先關閉瀏覽器的獨立 DNS 做一次比較，再查看 TUN DNS 接管範圍、IPv6 與略過規則。DNS 查詢走直連、而服務連線走代理，是兩項獨立設定；是否符合需求應依實際隱私範圍判斷。特定檢測網站只涵蓋其設計的查詢方式，不能據此保證所有 App 的 DNS 查詢都已接管。

修復後至少測試一般網域、先前無法連線的網域，以及必要的內網網域；再中斷並重新連線一次，確認系統解析器已正確復原。長期使用時應採用一套易於理解的 DNS 方案，避免系統、瀏覽器、路由器與用戶端同時設定彼此依賴的轉送鏈。需要修改 TUN 接管方式時，請參閱macOS TUN 授權說明，確認實際運作方式。

系統代理無效：確認設定、監聽與 App 連線方式

macOS 系統代理是供 App 讀取的網路設定，並非強制轉送所有裝置流量。瀏覽器可能會遵循系統代理，但命令列、遊戲或採用獨立網路堆疊的 App 不一定會使用。先用明確指定代理確認用戶端入口可用，再檢查系統設定是否套用到目前的網路服務；如果入口正常、特定 App 仍走直連，請檢查該 App 的代理方式，必要時再考慮使用 TUN，不要反覆切換系統代理開關。

確認設定已套用至目前的網路服務

開啟「系統設定 → 網路 → 目前的網路服務 → 詳細資訊 → 代理」，檢查網頁代理與安全網頁代理的主機和連接埠。不同 macOS 版本的介面文字可能略有差異，但務必檢查目前正在連線的服務；Wi-Fi 的代理設定不會自動套用至乙太網路。切換擴充基座、熱點或網路位置後，舊服務可能仍保留設定，但目前流量已改走其他服務。

# 查看目前代理設定摘要
scutil --proxy

# 列出網路服務，方便比對系統設定中的名稱
networksetup -listallnetworkservices

# 查看本機示範連接埠是否正在監聽 TCP
lsof -nP -iTCP:7890 -sTCP:LISTEN

輸出中的 HTTP、HTTPS、SOCKS 與自動代理設定可能各自啟用。手動代理與 PAC 同時存在時，應確認 App 實際採用哪種設定，不要假設手動設定一定會覆蓋自動設定。由組織管理的裝置也可能受到描述檔限制；此時應遵循組織的網路規範，不宜強行移除管理設定。用戶端無法寫入代理設定時，記錄內容通常比開關外觀更能指出權限問題。

檢查監聽位址與混合連接埠

監聽主機通常使用 127.0.0.1，連接埠則應採用用戶端實際設定。不要將遠端節點伺服器連接埠填入系統代理，也不要與控制介面連接埠混用。如果連接埠已被其他程序占用，核心可能無法啟動，或系統代理可能指向錯誤的 App；請根據監聽指令顯示的程序名稱確認歸屬，再透過對應 App 正常結束程序，不要直接強制關閉不明程序。

以下最簡片段用來說明本機代理入口，不包含遠端節點。mixed-port 同時接受 HTTP 與 SOCKS 代理通訊協定；它不等於 DNS 連接埠，也不代表外部網站應直接連到這個連接埠。如果圖形介面用戶端提供獨立的連接埠設定，請先在該處調整，避免產生的設定與手動編輯互相覆蓋。

mixed-port: 7890
allow-lan: false
mode: rule

處理 App 自訂代理與終端機環境

終端機程式可能讀取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY 等環境變數，也可能只接受自身的參數。檢查時不要將含密碼的變數值貼到公開記錄。暫時使用命令列參數進行診斷較合適，因為影響範圍明確；確認有效後，再依工具文件設定持續代理。請注意，HTTPS_PROXY 對應的代理入口仍可能使用 http://127.0.0.1:7890。

瀏覽器擴充功能、App 內建代理與系統代理可能互相覆蓋。先停用擴充功能代理，再開啟新視窗測試；必要時完全結束 App 後重新開啟，避免沿用舊連線。連線建立後才切換規則或節點，不一定會立即改變既有連線的出口。排查時應建立新連線，並透過連線記錄確認，不要只重新整理長時間保持連線的頁面。

如果 App 確實不支援系統代理，可使用用戶端提供的 TUN 接管流量，但應先確認輔助服務已安裝且授權正常，並排除其他隧道衝突。不同用戶端可能使用輔助服務或系統提供的網路機制，不能一律要求安裝相同擴充功能。結束用戶端後，請檢查代理設定是否已復原；若網路中斷，先關閉殘留代理，再依本章重新檢查入口，不要將復原措施變成永久停用安全功能。

用戶端閃退：區分介面結束、核心停止與系統攔截

視窗消失、核心停止與系統拒絕啟動是三種不同問題。介面結束後核心可能仍在執行；核心閃退時介面也可能繼續顯示舊狀態。先記錄發生時機：啟動時立即結束、匯入設定後結束、開啟 TUN 後結束，還是睡眠喚醒後失效。不要立刻刪除整個資料目錄；設定、記錄與當機報告是判斷觸發條件的重要資料，重新安裝 App 也未必能清除這些狀態。

確認處理器架構、下載來源與系統提示

Apple 晶片 Mac 優先選擇 arm64 或 Apple Silicon 版本；Intel Mac 則選擇 x86_64 版本，可在「關於本機」確認晶片類型。Universal 版本可能同時包含兩種架構，請依 App 說明為準。透過macOS 下載入口重新選擇安裝檔，避免在多個舊版本之間交替啟動。選擇用戶端時可優先考慮 Clash Plus，其他方案則應比較系統需求與維護狀態。

系統提示 App 已損毀、開發者無法驗證或權限受限時，請先確認下載來源與用戶端發布說明，不要直接執行停用系統安全機制的指令。企業裝置也可能受 App 執行政策限制。安裝檔架構不符、系統版本不支援與安全機制攔截，都可能導致無法啟動，但處理方式各不相同；請保留原始提示內容，不要一概稱為「閃退」。

先收集線索，再以最小設定啟動

在 macOS「主控台」檢視當機報告，或透過用戶端的記錄入口匯出故障時間附近的內容。確認報告對應的是圖形介面、mihomo 程序還是輔助服務。記下觸發步驟與最近的變更，例如新增覆寫、切換核心、修改 DNS 或啟用 TUN。記錄可能含有網域、伺服器與訂閱資訊，分享前請逐項去識別化；不要打包傳送整個使用者目錄。

保留設定副本後，先關閉自動啟動、自動連線與 TUN，以最小設定啟動，再逐步恢復訂閱與覆寫。如果最小設定正常、原設定卻導致 App 結束，請縮小範圍找出特定欄位或規則；如果尚未載入設定就結束，應優先檢查 App 本身、執行環境與系統報告。若用戶端提供安全模式或復原設定入口，請先使用官方支援的方式，不要猜測資料目錄名稱。

檢查輔助服務與資源異常

只有開啟 TUN 才會故障時，請檢查輔助服務是否屬於目前安裝的用戶端、升級後是否需要修復，以及其他 VPN 是否占用了路由。一般使用者不應手動替換系統擴充檔案，也不應降低系統啟動安全等級。請使用用戶端提供的安裝、修復或移除服務功能；若介面要求的權限與發布說明不符，應先暫停並確認來源，不要持續授權重試。

長時間使用後才結束，也應觀察記憶體壓力、記錄檔大小與連線數量的變化。大量規則提供者頻繁更新、異常重新連線或持續寫入詳細記錄，都可能增加系統負載。先排除診斷以外的因素：恢復一般記錄等級、暫停非必要更新，再以相同工作負載重現問題。不要清除所有規則或關閉憑證驗證來掩蓋故障，否則即使介面不再結束，也會失去原有的安全與分流界線。

Clash for Windows 與 ClashX Meta 已屬封存選項；遇到新系統相容性問題時，應優先評估仍在維護的替代用戶端，不要將舊設定原封不動地覆蓋到新 App。不同用戶端的設定合併、輔助服務與儲存方式可能不同。先匯入最精簡可用的訂閱，再遷移規則與偏好設定，才能將原設定問題與新用戶端的相容性問題分開判斷。

如果仍能穩定重現問題，請整理系統與處理器架構、用戶端名稱、觸發步驟、最小設定及已去識別化的記錄，透過專案或 App 的公開支援管道回報。不要捏造版本資訊，也不要以「最新版」取代介面顯示的實際版本。問題排除後再開啟自動連線，並測試一次正常結束與重新啟動，確認沒有留下失效的系統代理或無法使用的背景服務。

行動裝置專項：iPhone、iPad 與 Android 網路切換

行動裝置排查時，先確認系統 VPN 狀態與 App 內的連線狀態是否一致，再檢查目前使用 Wi-Fi 或行動數據。iOS 代理 App 透過系統允許的網路延伸機制運作，不能照搬 macOS 的輔助服務與終端機指令。iPhone 與 iPad 可優先選擇 Clash Plus，商店與官網入口請見iOS 用戶端；設定格式、可用規則與功能開關，則應以 App 實際支援情況為準。

iOS 顯示已連線，但無法上網

先在 App 內中斷連線，再前往「設定 → 一般 → VPN 與裝置管理」，確認是否有其他 VPN 正在連線。可以同時安裝多個 App 的設定檔，但同一時間啟用的隧道與隨選連線策略可能互相影響。暫時停用其他 App 的自動連線後再測試；不要刪除組織安裝的設定檔。首次連線時若尚未完成新增系統 VPN 的授權，App 顯示準備就緒也不代表系統隧道已建立。

如果只有行動網路無法連線，請檢查「設定 → 行動服務」中該 App 的數據使用權限，以及目前資費方案與系統數據模式；如果只有特定 Wi-Fi 無法連線，請先中斷 VPN，完成入口網站驗證。切換網路後，舊連線可能仍綁定原本的介面；重新連線用戶端並建立新請求，通常比反覆重新整理舊頁面更能確認是否復原。記錄切換前後的結果，避免同時更換節點而影響比較。

iOS 的背景運作機制與桌面系統不同；App 不在前景，不代表網路延伸一定停止，也不能把 App 卡片從多工畫面移除，當成可靠的服務重新啟動方式。請使用 App 內的連線開關，並在系統設定中確認實際狀態。裝置過熱或耗電異常時，請檢查是否持續重新連線、頻繁更新設定，或有其他大量傳輸的 App；不要只因狀態列顯示 VPN，就判定問題出在代理本身。

區域網路、隱私功能與分流界線

無法連線至印表機、電視或區域網路服務時，請檢查相關 App 的「區域網路」權限與用戶端的區域網路略過規則。透過 IP 位址存取與透過裝置名稱探索，可能使用不同機制；前者成功不代表多點傳送探索也正常。請分別測試並保留必要的本機解析與路由；不要為了修復一台裝置，就把所有私有網路流量都強制送往遠端出口。

iCloud 私密轉送與「限制 IP 位址追蹤」等系統隱私功能，可能改變部分流量的路徑，但不等同於通用代理隧道。懷疑發生衝突時，可先記錄原本狀態，再暫時關閉相關選項進行比較；測試後請恢復原設定，不要將它們視為所有連線故障的原因。排查重點仍是 App 請求是否進入目前的用戶端、命中哪條規則，以及目標使用哪個出口。

Android 與跨裝置設定差異

Android 可依下載頁順序選擇 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard。背景連線中斷時，請檢查系統電池管理、背景數據權限與 App 本身的 VPN 設定；不同廠牌的設定路徑可能不同。也請記錄私人 DNS、其他 VPN 與一律啟用 VPN 的策略。如果只有鎖定螢幕後才故障，應優先重現背景執行限制，不要先修改所有節點通訊協定。

Mac、iPhone 與 iPad 共用訂閱，不代表所有執行參數也應共用。桌面版的監聽連接埠、控制介面、檔案路徑與輔助服務欄位，不應直接照搬到手機。建議共用節點與必要規則，平台專屬的執行選項則留在各用戶端本機；同步設計請參閱Apple 裝置設定同步方案。匯入後務必檢查實際載入結果，不能只因訂閱名稱相同就認定運作方式一致。

仍無法解決時，請先建立一份最小重現記錄：裝置系統、目前網路、用戶端、選取的策略、失敗目標與大約時間，再附上已去識別化的錯誤摘要。不要急著重置所有網路設定，這會清除其他連線設定，增加復原成本。如需重新檢查安裝與連線流程，請返回快速入門；如果只有特定網域或節點異常，請繼續查看本頁對應章節，不必從頭重新安裝所有裝置。