Shadowrocket設定檔語法攻略：自訂規則與HTTPS解密實作

先理解 .conf 區段與修改原則

Shadowrocket 的設定檔通常以文字區段組織內容。方括號標示區段名稱，例如 [General]、[Rule]、[URL Rewrite] 和 [MITM]；區段內的每一行再依該區段所採用的語法解讀。不要把設定檔、Home 中的伺服器資料與訂閱網址當成同一項目：設定檔負責規則及相關選項，伺服器或訂閱則提供連線所需的資料。

開始修改前，先在 Config 找出目前使用的設定檔，保存一份未修改的副本，並記下檔名與修改時間。若設定檔由自己的服務商提供，或由訂閱更新產生，先確認哪些內容可以自行調整；直接覆寫遠端來源的原檔，可能在重新載入或更新後被替換。較穩妥的做法是保留原始檔，再以副本測試少量變更。

下方的網域、網址和路徑都是語法示意，不提供可用的伺服器或規則來源。不同設定檔可能使用不同策略名稱；例如 PROXY 只是範例標籤，必須與實際設定中的策略相符。若複製範例，請先確認每個區段名稱、分隔符號、策略名稱和欄位是否符合你正在使用的設定檔，不要把片段不加檢查地覆蓋整份檔案。

[General]
# 一般設定示意；請勿將註解或空白值視為完整設定

[Rule]
# 規則依序排列

[URL Rewrite]
# 網址改寫規則

[MITM]
# MITM 主機範圍

自訂規則排序與最終規則

在 [Rule] 中，規則通常由上往下比對，較早符合的規則會影響後續處理。因此，範圍明確的網域規則一般應放在較廣泛的網域或 IP 規則之前；用於處理剩餘流量的 FINAL 則放在規則清單末端。若把範圍很廣的項目放在前面，之後新增的細項可能永遠不會被採用。

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

這段只用來說明規則排列，並不是一份可直接使用的通用規則集。DOMAIN 指定完整網域，DOMAIN-SUFFIX 用於網域後綴比對，IP-CIDR 依 IP 網段比對，GEOIP 依目標 IP 的地理資料進行判斷。範例中的保留用途網段 192.0.2.0/24 不代表實際可連線的目標；no-resolve 也不是全域關閉 DNS，而是此規則不為比對額外觸發網域解析。

檢查規則時，先鎖定一個測試網域，再查看 Data 中對應請求的目標和處理結果。不要只根據頁面是否開啟推測命中哪條規則：網站可能從其他網域載入圖片、登入服務或 API，這些連線不一定使用網址列中的主機名稱。若結果與預期不同，先確認目前啟用的是哪份 Config，再檢查規則順序及策略名稱，最後才考慮改動 DNS 或伺服器。

遠端規則集的引用與更新

遠端規則集可讓設定檔引用另一個規則來源，避免把長清單全部複製到本機。規則來源應由你信任且有權使用的來源提供；不要使用來路不明的網址，也不要把自己的訂閱連結或帶有權杖的私人網址貼到公開討論區。遠端內容一旦變更，實際命中的規則也可能跟著變，因此須把來源、更新狀況及依賴的策略一併納入維護。

以下以 example.com 作為不可直接使用的示意網址，展示常見的規則集引用形式。實際支援的欄位、遠端清單格式及更新選項，請以 Shadowrocket 當前版本的介面與設定說明為準；不要臆測額外參數。引用行的策略名稱必須存在於設定檔或相關策略設定中，且應與你原本的分流設計一致。

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

管理遠端規則時，建議先在 Config 檢查來源網址是否可讀取，再確認規則清單的內容確實符合預期。若更新後某個網站突然改走不同路徑，先比較更新前後的規則內容，並查看 Data 中該網域實際符合的項目。若規則集無法取得，不能假設舊內容一定會保留或一定會自動更新；先檢查網路可達性、來源回應及設定檔狀態，再決定是否暫時回復到備份版本。

• 只引用必要來源：減少重複或重疊的遠端規則，降低同一網域被多份清單以不同策略處理的機會。
• 確認策略可用：遠端規則中指定的 PROXY 或其他名稱，必須與目前設定中的策略一致；否則規則即使載入，也可能無法達成預期路徑。
• 記錄變更時間：更新前先記下設定檔狀態與故障網域，更新後用同一網路、同一目標重新測試。
• 保護私人資料：診斷時不要公開訂閱網址、驗證資訊或包含個人權杖的遠端 URL。

URL Rewrite：網址改寫的範圍與驗證

[URL Rewrite] 用來依設定的模式處理符合條件的網址。它不是一般的流量分流規則，也不會替網站建立新的頁面或修復伺服器端錯誤。改寫目標、模式與狀態碼必須依 Shadowrocket 支援的語法設定；下方使用佔位路徑示範欄位概念，套用前請核對該版本的設定編輯介面及語法說明。

[URL Rewrite]
^https?://example\.com/old-path$ https://example.com/new-path 302

此示意規則的意圖，是將符合舊路徑的網址導向新路徑；302 表示以暫時重新導向的方式處理。正規表示式中的 . 通常有特殊意義，因此網域中的點以反斜線表示；行尾的 $ 用來限制比對範圍。若把條件寫得過寬，可能連同不希望改動的網址一起命中。反之，條件太精確，實際網址中的查詢參數、子路徑或大小寫差異也可能使它不符合。

測試時使用一個可安全重現的網址，先記錄原始完整網址，再逐項檢查協定、主機名稱、路徑、查詢參數及規則排列。每次只調整一個部分，重新載入該頁面並檢查結果；若網址改寫後進入錯誤頁面，立即停用該條規則並還原原值。不要把包含登入權杖、個人識別資料或私密查詢參數的完整網址貼入公開記錄。

MITM：HTTPS 解密與憑證信任

MITM 是 HTTPS 解密功能的一部分，透過本機憑證檢查納入設定範圍的加密連線，讓相容的應用程式流量可供檢視或套用相關規則。這會改變原本的 TLS 信任關係，並可能讓 Shadowrocket 能讀取受檢查連線的內容。只應對自己有權管理、確實需要檢查的主機啟用；避免使用過於寬泛的萬用字元，也不要將銀行、醫療、個人郵件或其他敏感服務納入範圍。

使用前，需在 Shadowrocket 中安裝其 HTTPS 解密所需憑證，並在 iOS 的憑證信任設定中，對應該憑證啟用完整信任。常見系統路徑為 Settings → General → About → Certificate Trust Settings；系統版本或介面語言不同時，項目名稱可能略有差異。僅安裝憑證不一定代表系統已對其完整信任；反過來說，信任憑證也不會自動把所有網域加入 MITM 範圍。

MITM 不能保證每個 App 或每個 HTTPS 連線都可解密。部分應用程式可能使用憑證固定、非標準連線方式或其他驗證機制；遇到此類情況，不應嘗試繞過應用程式的安全檢查。測試前先確認目標應用程式與資料的管理權限，並避免把擷取到的內容、憑證或連線記錄交給未授權的人員。

1. 備份設定檔

   在 Config 保存原始 .conf，確認目前啟用的設定檔名稱，並記錄需要測試的主機與操作時間。

2. 安裝解密憑證

   依 Shadowrocket 的 HTTPS Decryption 相關介面安裝憑證；不要將憑證檔或私密資訊傳給他人。

3. 啟用系統信任

   前往 iOS Settings → General → About → Certificate Trust Settings，確認對應憑證的完整信任狀態。

4. 限制主機範圍

   在 MITM 設定中只加入一個有權檢查且用於測試的主機，避免一開始使用涵蓋範圍過大的萬用字元。

5. 測試並還原

   連線後以該主機進行一次可重現的測試；完成檢查後移除不再需要的主機設定，並視需要停用或移除信任憑證。

載入失敗與連線異常檢查

修改後若設定檔無法載入，不要一次刪除多個區段。先回到最近一次成功的備份，逐項比對區段標題、標點符號、空白、逗號和策略名稱。不同規則類型需要不同欄位；把一種語法誤放在另一個區段，或在規則行中漏掉欄位分隔符號，都可能導致設定無法按預期解析。

若設定檔成功載入，但網頁或應用程式連線異常，先分清是規則分流、網址改寫還是 MITM 所造成。固定同一個目標，暫時停用最近新增的單一規則，再使用相同網路重新測試。若停用後恢復，檢查該規則的比對範圍和所指定策略；若仍異常，還原測試前備份，再查找其他原因。

設定檔維護的核心是可回復、可驗證：先保存原始版本，明確記錄修改位置，再用固定目標確認效果。規則集、URL Rewrite 與 MITM 各自處理不同問題，避免把多種變更一次加入同一輪測試。確認不再需要 HTTPS 檢查時，請縮小或移除主機範圍，並檢查是否仍有不需要的憑證信任設定。