Shadowrocket 設定檔結構詳解：[General]、[Rule]、[Host]、[URL Rewrite] 各段用途

本文重點

Shadowrocket（小火箭）的設定檔用來整理參數、規則與網址處理邏輯，並不等同伺服器訂閱。本文適合已備妥服務資料、準備閱讀或修改 .conf 檔案的使用者：先辨識四個段落，再於 Config 匯入、編輯並選取設定檔，最後透過 Global Routing 與連線記錄確認結果。

一、先分清設定檔、服務資料與運作模式

.conf 是文字設定檔，段落名稱以方括號括住，各段名稱下方放置對應內容。把規則寫進 [General]，或把 DNS 參數放進 [Rule]，都無法表達原本預期的設定。閱讀檔案時，應先找出段落名稱，再檢查每一行的語法；不要只搜尋某個網域後就直接貼上修改。

4 個段落

本文說明 General、Rule、Host、URL Rewrite

3 個入口

Home 管理連線，Config 管理設定檔，Settings 管理設定

最後 1 行

將 FINAL 放在規則清單最後作為兜底

本文以使用者已有自己的服務供應商與訂閱為前提。Home 中的伺服器資料說明連線目標、連接埠與驗證方式；Config 中的檔案則說明請求如何分流。匯入設定檔不會自動補齊缺少的伺服器資訊，更新伺服器訂閱也不等於更新目前選取的設定檔。

Home：確認已有的伺服器資料、選取連線目標，並查看 Global Routing。
Config：匯入、選取及編輯設定檔；檔案出現在清單中，不代表已經選取。
Settings：調整應用程式設定，例如透過 Settings → On Demand 管理隨選連線條件；On Demand 不能取代分流規則。

二、[General]：以鍵值形式設定全域參數

[General] 使用 鍵 = 值 的格式。此處適合設定 DNS 等全域參數，不要放入 DOMAIN-SUFFIX 規則。排查問題時，先記下原本的值，每次只修改一項；若同時調整 DNS、規則與連線目標，之後就很難判斷是哪個變更影響結果。

[General]
dns-server = system

這段範例會讓 DNS 使用系統提供的解析伺服器。這不是適用於所有網路環境的固定做法：如果目前網路本身有解析問題，保留 system 並不會自動修復問題。若要指定其他解析伺服器，應使用已確認可用的位址，並依照應用程式支援的格式填寫。

檢查參數行

段落名稱: [General]
參數名稱: dns-server
指定值的符號: 英文半形 =
本文範例值: system

先確認參數所在的段落，再核對值的格式與實際網路環境。

檢查規則行

段落名稱: [Rule]
規則類型: DOMAIN-SUFFIX
比對內容: example.com
執行策略: PROXY

規則欄位以英文逗號分隔，不使用參數行的等號格式。

不要為了「設定完整」就把網路上看到的所有參數一併加入。先保留能清楚說明的設定；若要變更 IPv6、逾時等行為，應先確認應用程式內的說明與對應參數的可用值，不要照搬來源不明的數值。

三、[Rule]：由上往下比對，FINAL 放在最後

[Rule] 決定請求採用哪一項策略。規則會依序檢查，符合後便採用對應策略，因此範圍較小的例外通常要放在範圍較大的規則之前。以下範例只用來說明語法；example.com 是示範網域，請依自己的實際目標調整。

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

關鍵字	本例的比對對象	檢查重點
`DOMAIN`	精確比對 login.example.com	這項例外會先於後面的網域後綴規則處理。
`DOMAIN-SUFFIX`	example.com 及其子網域	不要填入 URL 路徑、協定標頭或連接埠。
`IP-CIDR`	192.168.0.0/16 位址範圍	`no-resolve` 可避免只為這條 IP 規則主動觸發網域解析。
`GEOIP`	IP 地理資料庫中歸屬 CN 的位址	依據 IP 資料庫判斷，不是根據網域後綴。
`FINAL`	未符合前面規則的請求	放在最後；之後的規則就沒有正常參與比對的機會。

在本例中，造訪 login.example.com 會先符合第一行並使用 DIRECT；造訪 www.example.com 則會符合第二行並使用 PROXY。若將前兩行對調，登入網域也會先符合後綴規則，第一行原本要表達的例外便會失效。

四、[Host]：網域對應不等於代理規則

[Host] 用來為網域指定本機對應。它回答的是「這個名稱對應到哪個位址」，而 [Rule] 回答的是「這個請求採用哪種策略」。兩者屬於不同層面：新增對應後，仍應檢查相關請求符合了哪一條規則。

[Host]
device.example.com = 192.0.2.10

192.0.2.10 是文件範例位址，不是可連線的真實設備。此處僅示範「網域=位址」的格式，不能直接照抄並期待網頁能開啟。實際使用時，請填入已確認的目標位址，並確認目前網路可以連到該位址。

左側填網域，不要寫 https://，也不要加上 /path。
對應設定不會變更瀏覽器網址列中的網域，也不會自動變更 HTTPS 憑證要求。
若指向錯誤位址，可能會連線失敗或發生憑證不符；不要以停用憑證驗證來掩蓋對應錯誤。
如果應用程式自行採用其他解析方式或重用舊連線，觀察到的結果可能不會立即改變；請搭配新建連線與記錄進行確認。

若沒有明確的對應需求，可以不填寫此段落。若為了定位問題暫時新增一行，驗證完成後應刪除或還原原值，避免遠端服務位址變更後仍被舊對應固定。

五、[URL Rewrite]：依網址模式改寫請求

[URL Rewrite] 用來描述 URL 比對與改寫，不負責選擇代理策略。常見寫法包含比對運算式、目標網址與處理方式。以下以 HTTP 網址跳轉為例，示範比對字串開頭、跳脫網域中的句點，以及使用 302 傳回暫時重新導向的語法。

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

依目標選擇段落，不要混用兩種規則

需要變更連線策略

使用 [Rule]。
例如，讓 example.com 使用 PROXY。
透過連線記錄確認符合的規則與策略。

需要變更請求網址

使用 [URL Rewrite]。
例如，將符合條件的 HTTP 網址重新導向 HTTPS。
確認比對運算式、目標網址及是否形成重新導向迴圈。

「採用哪條連線路徑」與「請求哪個網址」是兩回事，應分別驗證。

範例中的 ^ 限定字串開頭，\. 用來比對字面上的句點。運算式範圍過寬，可能影響無關的網址；若目標網址又符合原本的規則，還可能形成重新導向迴圈。HTTPS 請求受到加密保護，不能假設只要加入一條規則，就一定能讀取並改寫其中的路徑；是否需要額外設定，取決於具體的處理方式。本文不介紹 HTTPS 解密設定。

六、在 Config 匯入、編輯與啟用設定檔

先保留目前可用的檔案，再匯入或編輯副本。遠端設定網址應來自使用者自行確認的來源，回傳內容應是設定文字，而非登入頁面或網頁說明。含有權杖的網址屬於敏感資料，不應出現在公開截圖或求助紀錄中。

保留原始檔

進入 Config，記下目前選取的檔案名稱，並保留原始文字副本。後續測試若失敗，請用原始檔還原，不要在狀態不明的檔案上繼續疊加修改。
匯入檔案

在 Config 點選右上角的「+」，填入自己已有的設定 URL，再點選 Download 取得設定。匯入後，請核對清單中的檔案與實際內容，不要把伺服器訂閱網址誤當成 .conf 網址。
編輯文字

在 Config 開啟目標檔案右側的資訊按鈕，進入 Edit Plain Text。先確認段落名稱，再逐行編輯；若介面使用本地化標籤，請以目前畫面上對應的編輯入口為準。
選取設定檔

儲存後返回 Config，點選目標檔案並確認選取標記。返回 Home → Global Routing，選擇 Config；只儲存文字不會自動將其他模式切換為 Config。
重新驗證

確認 Home 中已有的連線目標可用，重新建立連線後，測試一個目標網域與一個非目標網域。查看連線記錄中的目標、策略與符合的規則，必要時還原原始檔進行比對。

更新遠端設定可能會覆蓋本機修改。需要持續保留的規則應另存副本，並在更新後比較各段內容。若設定檔含有伺服器資料、驗證資訊或專用網址，分享前也應逐項清除，而不只是遮住檔案名稱。

七、透過 Global Routing 與記錄確認是否生效

「已匯入」與「正在依照檔案分流」並非同一種狀態。針對本文的 [Rule] 範例，請先確認 Global Routing 設為 Config。其他模式各有用途，不能將暫時切換模式後的結果，直接當作規則檔案已生效的證據。

Config

建議

依目前設定檔中的規則決定策略。本文範例中的網域例外、後綴比對與 FINAL 兜底，都應在此模式下驗證。

適用情境：閱讀、修改及驗證本文的分流規則。

Proxy

將可代理的流量統一交由代理路徑處理，用來檢查已有的連線目標是否可用；不適合用來驗證本文逐條列出的分流規則。

適用情境：暫時排除規則因素，排查代理連線。

Direct

使用直連路徑，可作為網路對照。切換至此模式後若存取結果有所變化，不代表原設定中的網域規則有誤。

適用情境：檢查目前網路是否可直連。

Scene

依據已設定的場景條件決定路由行為。排查時也要確認場景條件與實際採用的模式，避免只檢查設定檔。

適用情境：已明確設定並了解場景切換條件。

測試應以可觀察到的結果為依據，而不只是確認連線開關是否已開啟。瀏覽器快取、舊連線及應用程式本身的請求方式都可能影響判斷；修改後請發出新請求，並參考連線記錄進行確認。下表列出的是排查方向，不保證適用於所有應用程式的存取行為。

觀察到的狀況	優先檢查項目	下一步
規則已儲存，但策略沒有變化	目前檔案是否已選取、Global Routing 是否設為 Config	確認選取狀態後重新連線，再查看新請求的記錄。
只有特定網域無法連線	較前面的 DOMAIN、DOMAIN-SUFFIX 或 REJECT 規則	依檔案中的順序，找出第一條符合的規則。
網域解析到舊位址	Host 對應、DNS 快取與既有連線	還原對應設定，並以新連線進行比對。
網址反覆跳轉	URL Rewrite 的比對範圍與目標網址	先移除該條改寫規則，再逐條恢復並驗證。
更新後自訂規則消失	是否更新了同名的遠端設定	還原本機副本，並比較更新前後的文字內容。

完成檢查後，應能說明目前使用哪個檔案、請求符合哪條規則，以及採用該策略的原因。能回答這三點後，再繼續新增複雜規則；若不需要對應或改寫，保留相關段落空白或不新增即可。