本文目錄
先按你在 iPhone 上真正要做的事來選
想沿用 Clash 風格設定,可以看 Stash;只需匯入節點和做基礎分流,可以看 Shadowrocket;每天都要偵錯請求、指令碼和模組,再考慮 Surge。
還要比較設定相容、規則編輯、區域網路共享、購買方式和遷移成本。三款應用都能代理,但使用方式並不相同。
明確推薦
| 主要需求 | 優先考慮 | 不適合的情況 |
|---|---|---|
| 沿用 Clash 風格策略群組與規則 | Stash | 只有單節點、完全不維護規則時可能顯得偏重 |
| 匯入常見節點、基礎分流、價格敏感 | Shadowrocket | 需要完整的 Surge 模組工作流或團隊偵錯時不夠統一 |
| 網路偵錯、指令碼、模組、MITM 是日常工作 | Surge | 只想更新訂閱和換節點時成本與學習量過高 |
標示「支援 Clash」,也不代表原設定可以直接匯入
Stash 官方定位是把 Clash Premium 風格能力帶到 Apple 平台,因此已經使用 proxy-groups、rules 和 Rule Provider 的使用者通常更容易延續原來的組織方式。仍要查看實際匯入結果:指令碼、TUN、DNS 和個別 Mihomo 新欄位未必一一對應。
Shadowrocket 是獨立的規則代理工具。官方 App Store 說明列出了網域、CIDR、GeoIP 規則、遠端規則檔案、DNS、指令碼過濾和多級轉發,但它不是 Mihomo 圖形前端。節點匯入成功後,原來的 Clash 策略群組和覆寫不一定還保持同樣結構。
Surge 使用自己的 Profile 與 Module 體系。Module 會以更高優先級覆蓋 Profile,適合維護可審查的本機補丁;只有 Clash 訂閱、又不準備重做規則時,不應因為 Surge 功能多就預設遷移成本最低。
真正拉開差別的是每天要改什麼
把第一次匯入放到一邊,再想想以後最常開啟哪個頁面。這個答案通常比功能清單更能說明哪款應用適合長期使用。
- Stash
- 更適合圍繞 Clash 風格策略群組選擇、覆寫和規則集維護;也覆蓋 iOS、tvOS、macOS 與 visionOS。
- Shadowrocket
- 適合快速新增常見節點與規則,並可在 iPhone、iPad、Mac 和 Apple TV 使用;目前功能與購買地區以 App Store 頁面為準。
- Surge
- 適合查看連線、維護模組、執行指令碼和偵錯 HTTP 流量。官方文件對 Module、MITM 和指令碼有完整體系。


需要給區域網路裝置共享時,先看有沒有明確的代理入口
區域網路共享方式
| 應用 | 可以確認的做法 | 選擇時要注意 |
|---|---|---|
| Stash | 官方文件明確支援 iOS 提供 HTTP 與 SOCKS 代理;開啟「允許區域網路連線」後使用手機區域網路 IP 和 7890 連接埠 | 這是手動代理共享,iPhone 不會因此變成完整透明閘道 |
| Shadowrocket | App Store 說明覆蓋本機流量與多級轉發,但沒有把區域網路共享寫成主要承諾 | 若目前版本設定裡沒有明確的共享監聽入口,不要按第三方舊截圖推斷 |
| Surge | 官方原理文件說明 iOS 可用本機代理服務接管另一台裝置的請求 | 目標裝置仍要手動填寫代理;具體監聽位址與權限以目前 Profile 和版本為準 |
無論使用哪款應用,共享前都要允許 iOS 的「本機網路」權限,並讓兩台裝置處於同一 Wi-Fi 或個人熱點。先用另一台裝置開啟一個測試網頁,再從 iPhone 的請求記錄確認它確實進入預期策略;不用時關閉監聽,公共 Wi-Fi 上不要暴露無認證代理。
指令碼和 MITM 只有明確用途時才開啟
三款工具都可能出現重寫、指令碼或 HTTPS 解密相關能力,但普通訂閱連線並不需要安裝根憑證。MITM 會讓應用在本機重新簽發憑證,部分採用憑證鎖定的 App 還會直接拒絕連線。
準備安裝 Module 或遠端指令碼時,應先讀源檔案,確認它修改的主機、請求標頭和回應內容。Surge 官方文件明確說明 Module 可以覆蓋 Rule、Script、URL Rewrite 與 MITM 設定;這正是它強大的地方,也意味著不應把來源不明的模組當成主題包隨手匯入。
付款前開啟目前 App Store 頁面
價格、上架地區、家庭共享與支援裝置都可能調整。Shadowrocket 目前美國區 App Store 頁面顯示為獨立付費應用,並明確說明不附帶代理服務;Stash 與 Surge 也需要以購買帳號所在地區的商店頁面和官方說明為準。
如果未來還要在 Apple TV、Mac 或家庭成員裝置上使用,先確認同一購買能否下載、設定怎樣同步,以及指令碼和憑證是否會跟著遷移。把這些成本算進去,才是實際價格。
遷移時只搬訂閱、規則和確實需要的設定
決定更換後,不要把舊應用的全部快取和憑證一起搬過去。先讓新應用完成最小連線,再把自己真正維護過的內容逐項補回。
遷移順序
- 儲存原始訂閱位址和目前可用的策略群組名稱
- 列出自己寫過的規則、模組或指令碼,不複製未知快取
- 新應用第一輪只驗證訂閱、固定節點、鎖定螢幕和切網
- 進階規則逐項重建,每加入一項就查看一次連線
- 新應用穩定數日後再刪除舊設定與憑證
