Shadowrocket 設定檔 .conf 結構解析：General、Rule、Host、URL Rewrite 各區段說明

先確認 .conf 的用途與生效位置

Shadowrocket（小火箭）的 .conf 是文字設定檔，以方括號標示區段名稱，各區段只處理相應類別的設定。[General] 通常放置鍵值參數，[Rule] 則以每行一條規則排列；不能將同一種行格式套用到所有區段。副檔名正確，也不代表其中每個參數都有效。

閱讀前，先到 Config 確認目前選取的設定檔，再到 Home → Global Routing 檢查路由模式。若要驗證檔案中的分流規則，應使用 Config；處於 Proxy 或 Direct 時，不能只根據觀察到的連線結果判斷 [Rule] 是否設定正確。使用 Scene 時，也要確認該場景實際套用的設定。

連線資料與分流設定屬於不同層次。更新已有的訂閱，主要影響相應的連線資料；不要因此認定本機 .conf 也已同步修改。遠端設定檔更新時也可能覆蓋本機編輯內容，因此測試前應保留原始檔，並在副本上逐項修改。

General：以鍵值參數控制全域行為

[General] 使用 key = value 格式。先確認鍵名，再檢查值的類型：有些接受布林值，有些則接受位址或清單。不要用全形標點取代等號與逗號，也不要把規則行放進這個區段。以下僅示範兩項獨立設定，不代表任何網路環境都適用這些值。

[General]
dns-server = system
ipv6 = false

dns-server = system 表示使用系統 DNS，但不保證在所有網路環境下都能正常解析。ipv6 = false 是全域 IPv6 相關設定，不是網域分流規則，也不能取代對伺服器 IPv6 連線能力的檢查。遇到問題時，應保留原值作為對照，不要同時更換 DNS、調整 IPv6 又修改規則順序。

Rule：先比對先套用，FINAL 放在最後

[Rule] 的重點不在規則數量，而在排列順序。一般規則行由類型、比對內容與策略組成；FINAL 不需要比對內容。前面的規則一旦符合，後續規則就不會再為同一個請求選擇策略。因此，明確的例外規則應排在較廣泛的條件之前。

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

範例中的 192.0.2.0/24 是文件專用位址範圍，並非可用的服務位址。DIRECT 表示直接連線，PROXY 指向代理連線；若使用自訂策略名稱，必須確認目前的設定檔確實有定義該名稱。名稱相近不代表是同一個策略，也不應直接把協定名稱當成已存在的策略。

Host：修改解析對應，不修改請求網址

[Host] 用於指定網域的本機解析對應，常見格式為 網域 = IP。它處理的是「這個名稱解析到哪個位址」，而不是「流量經由哪條連線路徑」。即使網域被對應到固定位址，請求仍須依照實際生效的路由設定決定如何傳送。

[Host]
lab.example.com = 192.0.2.10

• 鍵填網域：使用 lab.example.com，不要填入包含 https:// 或路徑的完整 URL。
• 值填位址：此處的 192.0.2.10 僅用於說明語法，實際使用時必須換成自己有權使用且能夠連線的位址。
• 不會變更連接埠：若原請求使用 HTTPS 預設連接埠 443，Host 對應本身不會將它改成 8443。
• 不會變更憑證名稱：HTTPS 仍須驗證原網域對應的憑證。對應到另一台伺服器，不代表憑證檢查就會通過。

排查時要區分「網域解析錯誤」與「無法連線到目標位址」。若應用程式直接連線 IP，或透過自己的解析機制取得位址，就不能只憑一條 Host 對應推斷請求一定會使用它。修改後請重新發出請求；必要時先關閉現有連線再測試，避免將舊連線重用的結果誤認為新設定的結果。

URL Rewrite：以正規表示式比對請求網址

[URL Rewrite] 會處理應用程式可識別的 HTTP 請求網址。以下範例使用正規表示式比對明確的 HTTP URL，並以 302 回應重新導向。三個部分以空白分隔：比對運算式、目標位址、動作。格式與 Rule 使用的逗號不同。

[URL Rewrite]
^http://example\.com/guide$ https://example.com/guide 302

1. ^ 限定字串開頭，避免比對到網址中間的相似片段。
2. example\.com 中的反斜線會將句點限定為字面上的句點；正規表示式中的未跳脫句點原本可以比對其他字元。
3. /guide$ 限定路徑結尾。帶有查詢參數的 /guide?from=test 不符合這個完整運算式。
4. 302 表示重新導向動作；用戶端之後是否跟隨重新導向，需依發出請求的應用程式實際情況判斷。

不要將這個範例理解為「任何 HTTPS 網址都能直接改寫」。一般加密通道只會提供連線所需的資訊，並不會自然顯示完整的 HTTPS 路徑。比對 HTTPS 內容涉及 MITM、目標主機範圍、憑證信任與應用程式本身的限制；本例從明文 HTTP 請求開始，不需要擴大解密範圍。

組合四個區段：每次只驗證一項變更

這四個區段不是四項都必須啟用的功能。若只需要網域分流，可以先處理 General 與 Rule；沒有固定解析需求，就不必新增 Host；沒有明確的網址改寫需求，也不必新增 URL Rewrite。保留少量有效設定，比加入大量來源不明的參數更容易判斷問題。

1. 保留基準設定：在 Config 中保留原始設定，記下 Home → Global Routing 目前的選項，以及原本可連線的測試目標。
2. 先修改規則：只新增一條明確的網域規則，儲存並選取修改後的設定檔，再使用 Config 路由模式測試。
3. 再測試解析：只有確實需要固定位址時才加入 Host；記錄目標網域、預期 IP 與連接埠，並區分解析問題與連線失敗。
4. 最後測試改寫：使用明確的 HTTP 路徑驗證正規表示式，不要同時加入 HTTPS 解密設定，以免混入多個變因。
5. 保留測試紀錄：搭配應用程式內可用的請求紀錄，確認網域、符合的規則與實際策略；若測試失敗，只撤銷剛才修改的項目，再重複相同請求。

Settings → On Demand 控制按需連線行為，無法修正規則語法。若手動中斷後又自動連線，應檢查這裡的觸發設定；不要因此認定 .conf 沒有儲存。測試期間保持連線方式一致，才能比較同一條規則修改前後的結果。

常見問題：儲存成功，結果為何仍不如預期？