Shadowrocket .conf 設定檔結構解析：General、Rule、Host、URL Rewrite 各段用途

本文速覽

本文適合已在 Shadowrocket 使用自己的訂閱，並準備檢查本機設定檔的使用者。先釐清連線資料與 .conf 的用途，再認識四種段名、規則順序及改寫格式，最後一次只修改一項並驗證結果。範例僅說明語法，不是可直接套用於現有環境的完整設定。

1. .conf 管什麼：先分清設定檔與連線資料

Shadowrocket（小火箭）的 .conf 是文字設定檔，方括號中的段名會決定後續內容由哪類功能讀取。[General] 通常用來設定參數，[Rule] 用來依序排列規則，[Host] 用於本機網域對應，[URL Rewrite] 則描述 URL 比對與處理方式。不同段落的語法不能互換。

Home 中已有的連線資料，與 Config 中選取的設定檔並非同一回事。更新訂閱通常是同步連線項目；編輯本機 .conf 則是調整請求處理方式。訂閱更新不代表目前生效的規則檔也已更換；反過來，匯入 .conf 也不代表已備妥可用的連線資料。

4 種段名

本文檢查 General、Rule、Host、URL Rewrite

1 個兜底規則

FINAL 放在規則末尾，處理未比對到的請求

2 類資料

分別檢查 Home 連線項目與 Config 設定檔

開始編輯前，先在 Config 確認目前選取的檔案，並保留原檔副本。回到 Home 檢查 Global Routing：驗證 [Rule] 時請使用 Config。Proxy 與 Direct 會改變全域分流方式；Scene 則還涉及情境設定。這些狀態不能與 Config 中逐條比對規則的測試結果混為一談。

在 Config 確認選取的檔案，而不只是確認檔案已匯入。
開啟該檔案的編輯入口，確認段名使用半形方括號。
在 Home 確認已有連線項目，再將 Global Routing 設為 Config。
儲存修改後，重新建立測試連線，避免沿用修改前的長連線。

2. [General]：讀取全域參數，不在此處撰寫分流規則

[General] 使用 鍵 = 值 的格式。參數的作用範圍取決於各鍵的定義，並非「放在最上方就能覆蓋所有段落」。例如，DNS 參數會影響解析行為；繞過參數則關係到部分流量是否進入處理流程，兩者都不能取代 [Rule] 中的網域規則。

[General]
dns-server = system
skip-proxy = 127.0.0.1, localhost

此處的 dns-server = system 表示使用系統 DNS 設定，並非指定某一台固定伺服器。127.0.0.1 是本機迴路位址；將它列入 skip-proxy，與讓某個公網網站走 DIRECT 並不相同。這段內容只示範兩種參數寫法，不是通用的網路最佳化方案。

每行只寫一個參數指派，不要把 DOMAIN-SUFFIX 規則接在參數值後面。
清單分隔符號請使用半形逗號，避免中文逗號造成整個項目讀取錯誤。
修改 DNS 前先記下原值；若新設定導致網域解析失敗，先還原原值再排查規則。
只保留來源明確且了解用途的參數，不要堆疊大量重複鍵來嘗試增加效果。

Settings → On Demand 管理的是依條件建立或中斷連線的行為，並非 [General] 的同義入口。排查設定時，若連線自動恢復，也應檢查 On Demand 的觸發條件；不要把自動重新連線誤認為 .conf 未儲存。

3. [Rule]：由上而下比對，FINAL 負責最後兜底

[Rule] 中的規則會依序判斷，通常由類型、比對值及策略組成。對於可完成比對的請求，最先符合的規則會決定策略；並非「網域越長就自動優先」，也不是「最後一行會覆蓋前面所有規則」。較具體的例外應放在較廣泛的規則之前。

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

在上方範例中，api.example.com 會先符合 DOMAIN，並使用 PROXY；www.example.com 則可符合後面的 DOMAIN-SUFFIX，並使用 DIRECT。若將後綴規則移到精確網域規則之前，前者就會先符合，原本為 API 設定的例外也會失效。

關鍵字	比對依據	檢查重點
`DOMAIN`	完整網域	不填寫協定、連接埠或路徑
`DOMAIN-SUFFIX`	網域及其子網域	較具體的例外規則要放在前面
`IP-CIDR`	IPv4 位址範圍	確認位址、遮罩與解析條件
`GEOIP`	目標 IP 的地理位置資料庫	不是依網站顯示語言判斷
`FINAL`	前面沒有符合規則的請求	放在最後，不填寫網域

no-resolve 是 IP 規則的附加選項，表示不為這條 IP 規則額外發起網域解析。這不代表關閉整個 App 的 DNS，也不代表網域請求一定會符合該網段。判斷時須一併確認請求是否已取得目標 IP。

結論：規則未生效時，先檢查模式與最先符合的規則

先將 Home → Global Routing 設為 Config，再檢查目標規則之前是否有更寬泛的規則。確認請求符合哪一行後，再決定是否修改策略；不要先改連線協定或 DNS。

PROXY 與 DIRECT 表示策略，不是協定名稱。PROXY 所使用的連線也必須在現有環境中可用；將 FINAL 改成 PROXY 不會自動建立連線項目。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等連線類型，與 DOMAIN-SUFFIX、IP-CIDR 等比對類型，分屬不同層次。

4. [Host]：指定解析位址，不直接選擇出站策略

[Host] 用於本機網域對應。以下將一個測試網域指向文件範例位址：左側填寫網域，右側填寫 IP 位址。此處的 192.0.2.10 屬於文件範例位址範圍，不應視為可連線的服務伺服器。

[Host]
demo.example.test = 192.0.2.10

Host 的作用是影響適用的解析結果，並不是填入網域就會自動直連。請求最終使用 DIRECT 或 PROXY，仍須配合 Global Routing、規則及實際出站路徑判斷；若網域交由遠端解析，也不能假設本機對應一定會決定最終目標位址。

Host 對應檢查

段名: [Host]
左側: demo.example.test
右側: 192.0.2.10
處理對象: 網域至位址的本機對應

網域後方不要加路徑，IP 位址中也不要附加連接埠。

Rule 策略檢查

段名: [Rule]
比對類型: DOMAIN
比對值: demo.example.test
策略範例: DIRECT

選擇 DIRECT 只代表採用直連策略，不會替目標提供可用位址。

Host 對應也不會改變 HTTPS 憑證必須符合網域的要求。即使解析到指定 IP，若目標伺服器沒有為該網域提供正確憑證，仍可能發生憑證錯誤。此時應檢查伺服器的網域設定，而不是將憑證錯誤歸因於規則優先順序。

5. [URL Rewrite]：分別檢查正規表示式、目標網址與狀態碼

[URL Rewrite] 常見的重新導向格式為「比對表達式、目標 URL、重新導向狀態碼」，各項以空白分隔。它處理的是 URL，不是單純比對網域；正規表示式中的句點、括號與邊界符號都有語法意義。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

這條規則會比對以 http://example.com/ 開頭的網址，並將捕獲到的後續部分放入目標網址的 $1。例如輸入 http://example.com/docs?a=1 時，預期的重新導向目標為 https://example.com/docs?a=1。這是語法範例，不需要前往外部測試頁面。

^ 錨定字串開頭，避免將無關 URL 中的一段文字誤當成目標。
\. 用來比對字面上的句點；直接寫 . 則會比對任意單一字元。
(.*) 建立捕獲群組，$1 用來引用第一個群組的內容。
302 表示暫時重新導向；除錯時仍須留意瀏覽器既有的快取。

能否處理 HTTPS URL，取決於是否在合法授權範圍內解密加密流量，以及相關設定是否完整。只新增 URL Rewrite 規則，不會自動取得 HTTPS 的路徑或內容。本文以 HTTP 輸入示範格式，不要求新增 HTTPS 解密設定或信任憑證。

6. 儲存後如何驗證：依功能分開測試

設定檔中的段落順序，不等於請求處理的完整執行順序。不能把四個段落由上而下解讀成固定流程。驗證時應先確認選取的檔案與全域模式，再分別檢查解析、規則比對及 URL 行為；每輪只變更一項因素。

備份原始檔案確認選取項目修改單一項目重新建立連線檢查結果

建立基準：保留一份可正常使用的設定，記錄測試網域、網路類型及 Global Routing 狀態。
檢查語法：確認方括號、等號、半形逗號與拼字無誤，並確認規則沒有放錯段落。
驗證規則：在 Config 模式下建立目標請求，並查看 App 提供的連線記錄，確認目標、策略與比對結果；若有記錄，應以記錄為準，不要只憑頁面開啟速度判斷。
驗證對應：使用自己管理且服務設定正確的網域，確認實際目標位址；不要用本文的文件範例位址測試連線。
驗證改寫：使用自己管理的 HTTP 測試入口，檢查目標位址與跳轉次數，避免舊快取掩蓋設定變更。
異常時還原：恢復原設定並重新建立連線。若還原後恢復正常，再單獨加入剛才修改的項目。

遠端設定與本機檔案也應分開管理。若編輯的檔案會被遠端更新覆蓋，請先另存獨立副本，並確認實際選取的是副本。訂閱更新與遠端設定更新應分別檢查，不能只因 Home 的連線項目有變化，就判定本機規則已遭替換。

7. 常見問題：檔案已儲存，為什麼結果仍不如預期？

把 FINAL 放在第一行，後面的規則還會生效嗎？

FINAL 應放在規則末尾，用來處理前面沒有符合的請求；提前放置會使後續規則無法發揮預期作用。請將精確例外移到較廣泛的規則之前，再把 FINAL 留在最後重新測試。

修改 Host 後，為什麼網站仍沒有直連？

Host 不會選擇出站策略。先檢查 Home → Global Routing，再查看 [Rule] 中該網域符合的策略；同時確認解析是否由本機處理，避免將遠端解析結果誤認為本機對應失效。

訂閱剛更新，為什麼 Config 中的規則沒有變？

連線訂閱與設定檔是不同類型的資料。請回到 Config 檢查選取的檔案及其來源；若要更新遠端設定，請操作對應的檔案，不要反覆更新 Home 中的連線訂閱。

儲存後沒有變化，需要刪除原檔嗎？

先不要刪除。確認修改的是目前選取的檔案，儲存後重新建立連線，再以新的請求測試。若連線自動恢復，請檢查 Settings → On Demand 的條件，並確保前後測試條件一致。

完整的排查記錄至少應包含：選取的設定檔、Global Routing 狀態、修改的段名與具體行、測試目標及觀察結果。分享記錄前，請移除訂閱網址、權杖與連線憑證；通常保留相關規則及已去識別化的目標資訊，就足以討論比對邏輯。