Shadowrocket設定檔怎麼寫？.conf分流規則與進階設定實戰

本文重點

本文適合已能正常使用 Shadowrocket，並想理解或自訂 .conf 設定檔的 iPhone、iPad 使用者。你會看到常見區段的用途、規則先後順序、遠端規則集的基本寫法，以及如何透過請求記錄核對分流結果。範例中的網域與網址僅用來說明格式，不是可直接使用的服務設定；請先備份原檔，再逐項修改。

一、先分清設定檔、訂閱與伺服器資料

Shadowrocket（小火箭）是透過 App Store 取得的 Apple 平台付費用戶端，App ID 為 932747118，開發者為 Shadow Launch Technology Limited。購買用戶端不等於購買連線服務；本文以使用者已有自己的訂閱或伺服器資料為前提，不提供或推薦任何連線服務。

設定檔通常以 .conf 為副檔名，內容由區段標題與設定行組成。Subscribe 用來取得或更新伺服器項目；Config 則用來管理規則及其他設定。兩者可能搭配使用，但不是同一份資料。更新 Subscribe 不會自動代表你目前選用的 Config 已變更，也不應把訂閱網址直接當成設定檔內容。

檔案結構

區段標題: 使用方括號，例如 [Rule]。
設定行: 依區段規定排列欄位，逗號通常用來分隔參數。
註解: 常見寫法以 # 開頭；修改前確認原檔採用的格式。

不要只改副檔名；檔案內容仍須符合 Shadowrocket 可辨識的設定格式。

常見區段

[General]: 一般設定，例如部分流量處理選項。
[Rule]: 依序列出的分流規則。
[Host]: 主機名稱與 IP 位址的對應設定。

可用欄位會依設定格式與 App 支援項目而異；遇到解析錯誤時，先檢查區段與拼字。

二、理解 [Rule] 的匹配順序與兜底策略

在 Global Routing 選擇 Config 時，Shadowrocket 會依設定檔中的規則判斷流量如何處理。判讀時要看規則類型、匹配條件與最後指定的策略，不能只看一行中的網域。通常應把範圍較明確的條件放在較廣泛的條件前面，並將兜底規則放在最後，避免前面的廣泛規則先匹配，導致細節規則沒有機會生效。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,local.example,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX,example.com,PROXY：符合 example.com 及其子網域時使用 PROXY。範例網域只用來說明格式。
DOMAIN,local.example,DIRECT：只匹配指定的完整網域，不等同於匹配所有子網域。
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve：示範 IPv4 網段規則與 no-resolve 參數；此網段是文件示例，不是可用服務位址。
GEOIP,CN,DIRECT：依 IP 地理資料判斷是否符合 CN，不是根據網頁語言或網域文字判斷。
FINAL,PROXY：前面規則都未匹配時使用 PROXY。如果改成 FINAL,DIRECT，未匹配流量的處理結果也會改變。

不要把 PROXY 當成固定指向某一台伺服器的名稱。它必須對應目前設定中可用的策略；若設定使用其他策略名稱，規則中的名稱也須一致。修改規則後，請回到 Home 確認選取的伺服器與 Global Routing 狀態，否則單看 Config 文字不一定能判斷實際出站路徑。

結論：先檢查命中的第一條規則

排查某個網域走錯路由時，先查看它是否已被前面的 DOMAIN 或 DOMAIN-SUFFIX 規則匹配，再檢查末尾的 FINAL；不要一開始就重寫整份規則。

三、遠端規則集如何加入設定檔

遠端規則集讓設定檔引用外部維護的規則內容。其價值在於可更新規則清單，而不是替使用者建立伺服器或自動保證每條規則都正確。遠端地址必須是自己有權使用、且實際提供相容規則格式的網址；網址可存取不代表回應內容一定能被解析。

以下展示常見的 RULE-SET 行形狀。rules.example.net 是文件用途的示例網域，不能當成實際規則服務使用。請以自己已取得的規則來源及 Shadowrocket 當前可接受的格式為準，並確認最後一欄所用策略名稱確實存在。

[Rule]
RULE-SET,https://rules.example.net/sample.list,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

檢查網址：確認連結完整，沒有多出的空格、引號或換行；不要把登入頁面網址誤當成規則檔。
檢查回應：規則來源應提供可讀取的規則內容，而非登入畫面、錯誤頁或空白回應。
檢查策略：PROXY、DIRECT 等策略文字須與設定中的策略相符，拼字或逗號錯誤可能改變解析結果。
檢查更新：更新後查看請求記錄與實際匹配結果；若來源維護者改變格式，既有設定也可能需要調整。

若遠端規則集無法更新，先不要同時改 DNS、代理參數與規則順序。記下更新時間、畫面提示和當時的網路類型，再確認網址是否有效、服務端是否可讀取，以及是否存在連線限制。完整訂閱網址和含有驗證資訊的設定內容應視為敏感資料，不要公開貼出。

四、在 Config 中修改並逐項驗證

動手前，請先記下目前使用的 Config 名稱、規則數量，以及一個可重現的測試網域。保留原始設定檔副本，測試時一次只改一類內容：先確認檔案能載入，再確認指定網域的規則，最後才考慮調整其他區段。這樣若結果改變，較容易找出是哪項編輯造成影響。

確認目前檔案

前往 Config，確認目前選用的設定檔名稱。若同時有多份設定，先辨認哪一份實際生效，不要只編輯清單中未啟用的檔案。
備份原始內容

將原始 .conf 保存在安全位置，並記下修改前的關鍵規則。若設定檔由遠端管理，先確認本機編輯會不會在下一次更新時被覆蓋。
修改一條規則

在 [Rule] 中調整一條明確的測試規則，確認欄位順序、逗號與策略名稱。不要刪除原本的 FINAL，除非已明確決定新的兜底行為。
重新載入設定

儲存後返回 Config，重新選取或載入該設定檔，留意 App 顯示的解析提示。若出現錯誤，先還原剛才變更的行，再檢查拼字、區段標題與分隔符號。
核對請求結果

在 Home 開啟連線並使用一個明確的測試網域，檢查請求記錄中顯示的目標與策略。記錄測試時間、網路類型和結果；若頁面無法載入，也要分辨是規則選錯還是遠端連線失敗。

請求記錄可協助確認某個請求是否出現、使用了什麼處理結果，但不能單獨證明遠端內容正確或帳戶服務正常。測試時不要公開包含網域、IP、時間或其他識別資訊的完整記錄；向服務商或管理者詢問時，只提供必要且已遮蔽敏感欄位的片段。

五、[Host] 與 MitM 的使用界線

[Host] 可用來描述主機名稱與 IP 的對應，但它不是用來修改所有流量路由的替代規則。若加入主機對應，必須確認網域拼寫、IP 位址及作用範圍正確；錯誤對應可能令指定服務連到錯誤位址。修改前先記錄原值，完成後以該主機的實際請求驗證，不要只憑其他網站仍可開啟就判斷無誤。

MitM 會涉及 HTTPS 流量檢視與憑證信任，風險高於一般分流規則。只有在明確了解用途、信任設定來源且確有需要時才啟用。安裝或信任憑證前，應核對憑證用途與來源；不需要時移除相關設定並撤銷系統中的信任。不要把憑證、私鑰、帳密或完整設定檔傳給不可信任的人，也不要將忽略憑證錯誤當成日常修復方式。

限定範圍：只為確有需要的網域設定，不要使用過度寬泛的主機範圍。
保護憑證：私鑰與憑證檔案具有安全敏感性，避免透過公開連結或一般討論區傳送。
完成後清理：測試結束後，檢查相關設定是否仍有必要；不再使用時移除不必要的憑證與信任。
遇到異常即停用測試：若網站出現憑證警告、登入狀態異常或內容與預期不同，先停止測試並還原設定。

常見問題

改了 .conf，為什麼路由結果沒有變？

先到 Config 確認編輯的是目前載入的檔案，再確認 Home → Global Routing 是否選擇 Config。之後用請求記錄核對測試網域是否真的命中預期規則。

遠端規則網址能開啟，為什麼更新還是失敗？

瀏覽器能載入網址，不代表回應是可解析的規則內容。確認回應不是登入頁或錯誤頁，並檢查 RULE-SET 行的逗號、網址與策略名稱。

可以把 MitM 憑證匯出後傳給別人嗎？

不要公開傳送含私鑰的憑證資料。先確認使用目的與信任範圍；若只是測試，測試完成後應檢查並移除不再需要的憑證設定。

設定檔出現解析錯誤，該先檢查什麼？

先還原最近一次修改，再逐行檢查區段標題、英文關鍵字、逗號和策略拼寫。確認原檔可載入後，一次重新加入一項變更。