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

逐段解析 .conf 設定檔:General 的 dns-server 與 bypass、Rule 的比對順序、Host 的網域映射,以及 URL Rewrite 語法,附可直接對照的範例片段。

本文速覽

本文適合已能在 Shadowrocket 中匯入並選用 Config,但需要讀懂或檢查 .conf 文字的使用者。重點是辨認四個區段的處理階段、核對規則順序、區分網域映射與 URL 改寫,並用最小範例找出常見語法問題。

先了解 .conf 的分段與處理順序

Shadowrocket(小火箭)的 .conf 檔案不是從第一行執行到最後一行的腳本,而是由多個方括號區段名稱劃分的宣告式設定。區段名稱決定後續行交由哪個處理模組,例如 [General] 儲存一般參數,[Rule] 儲存分流規則。空行通常只供閱讀,行首註解用於說明,不會參與比對。

讀取設定時,先確認區段名稱拼寫,再確認每一行使用的分隔符號,最後檢查同一區段內是否存在順序依賴。區段名稱缺少右方括號、逗號誤用中文標點、策略名稱拼寫錯誤,都可能導致該行失效。編輯後應回到 Config 重新選取設定,並透過實際網域請求驗證,而不只是確認檔案能否匯入。

應用程式發起請求讀取一般項目解析網域比對規則執行策略

四個核心區段並非都在同一階段發揮作用。[Host] 影響特定網域如何取得地址,[Rule] 決定請求採用哪種策略,[URL Rewrite] 則針對可識別的 URL 進行跳轉或拒絕處理。將這些功能混寫在同一區段,即使單行看似正確,也不會產生預期效果。

4 個區段
本文核對 General、Rule、Host、URL Rewrite
3 個欄位
一般 Rule 由類型、值與策略組成
1 次
請求命中第一條適用規則後,便停止繼續比對
2 類
範例改寫結果為 302 跳轉或 reject

結論:先按區段檢查,再按行檢查

遇到「部分規則有效、部分規則無效」時,先確認問題行是否位於正確區段,再檢查英文逗號、欄位數量與排列順序;反覆切換連線開關通常無法修復設定結構錯誤。

[General]:DNS、bypass 與基本行為

[General] 是設定的通用參數區。這裡的項目會影響 DNS 解析、系統繞過行為、區域網路地址處理及其他基本選項。它不是分流規則清單,因此不能把 DOMAIN-SUFFIXFINAL 放在這裡。不同來源的設定可能包含不同項目,核對時應以 Shadowrocket 目前介面能夠匯入與匯出的欄位為準。

dns-server 指定設定使用的 DNS 解析入口。寫成 system 表示採用系統可用的解析設定;填入明確地址時,應先確認該地址在目前網路中可連線。DNS 負責將網域轉換為地址,但本身不決定最後使用 PROXY 還是 DIRECT,策略仍由 Global Routing 與 [Rule] 共同決定。

[General]
bypass-system = true
dns-server = system
ipv6 = false
skip-proxy = 127.0.0.1, localhost, *.local, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

bypass-system 用於控制是否採用系統相關的繞過處理;skip-proxy 則明確列出不應交由代理處理的主機或地址範圍。上例包含回送地址、.local 名稱與三個常見私有地址區段,適合用來說明語法,不代表所有網路都應直接照抄。企業內網、家用儲存設備或印表機可能使用不同網段,修改前應先查看設備目前取得的區域網路地址。

ipv6 = false 是明確關閉此設定中 IPv6 行為的寫法範例,但不應視為通用修復項目。如果目前連線網路、既有服務設定與目標網站都正常支援 IPv6,關閉後反而可能改變解析結果。排查時一次只調整一個項目,並記錄調整前後的 DNS 結果與存取現象。

DNS 核對

欄位
dns-server
系統值
system
常用連接埠
53
驗證對象
網域是否能取得地址

DNS 能解析不代表規則策略正確,還需繼續檢查 Rule。

bypass 核對

總開關
bypass-system
明確清單
skip-proxy
本機名稱
localhost
區域網路後綴
*.local

私有地址範圍應依目前區域網路的實際網段填寫。

[Rule]:由上而下比對與 FINAL 兜底

[Rule] 是最容易受順序影響的區段。Shadowrocket 在 Global Routing 設為 Config 時,會依照設定中的排列由上而下檢查請求;命中第一條適用規則後,就採用該行末尾的策略,不會繼續尋找「更具體」的後續規則。因此,具體網域通常應放在寬泛的後綴或地域規則之前。

常見規則以英文逗號分隔。DOMAIN 比對完整網域,DOMAIN-SUFFIX 比對網域後綴,IP-CIDR 比對地址範圍,GEOIP 依地址所屬地域比對,FINAL 處理先前都未命中的請求。策略通常寫成 PROXYDIRECTREJECT

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

上例第一行優先讓 api.example.com 使用 DIRECT。如果將第二行放在第一行之前,完整網域會先被 DOMAIN-SUFFIX,example.com 命中,後面的例外規則便沒有機會執行。no-resolve 用於避免該 IP 規則為了比對而額外觸發網域解析,適合本身只需檢查目標地址的規則。

規則關鍵字 檢查對象 範例 排序重點
DOMAIN 完整網域 api.example.com 通常放在相同後綴規則之前
DOMAIN-SUFFIX 網域及其子網域 example.com 範圍較廣,注意不要覆蓋具體例外
IP-CIDR IPv4 地址範圍 192.168.0.0/16 區域網路範圍通常優先處理
GEOIP 解析後的地址地域 CN 通常位於具體網域與地址規則之後
FINAL 所有未命中的請求 FINAL,PROXY 應放在最後作為兜底

Global Routing 會改變規則是否參與決策。Config 使用目前設定的規則;Proxy 強制採用代理策略;Direct 直接連線;Scene 依已設定的場景條件決定行為。測試單條規則時,應先確認沒有停留在 ProxyDirect,否則修改 [Rule] 後看不到預期差異。

  1. 在 Home 確認已選取需要測試的伺服器設定。
  2. 將 Global Routing 切換至 Config
  3. 在 Config 確認目標 .conf 處於選取狀態。
  4. 將待驗證的具體規則放在寬泛規則之前。
  5. 重新發起請求,檢查命中的策略是否符合預期。
  6. 最後確認 FINAL 位於規則區段末尾。

[Host]:固定網域映射,不等同於分流規則

[Host] 用於將指定網域映射至明確地址,可以理解為設定內的網域解析覆寫。它解決「這個網域應取得哪個地址」的問題,不負責決定請求走 PROXYDIRECT 還是 REJECT。最終策略仍需由 [Rule] 處理。

以下使用文件保留地址示範格式。192.0.2.0/242001:db8::/32 專門用於文件範例,不應視為真實業務地址。實際設定應填入自己管理或確認可用的目標地址。

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20
ipv6.example.com = 2001:db8::10

Host 映射最常見的檢查錯誤是網域層級不一致。例如只寫 example.com,不應預設 api.example.com 一定會取得相同映射。需要涵蓋子網域時,應逐項確認目前設定支援的比對寫法,並透過實際解析結果驗證,不要依靠外觀相似的網域推斷。

現象 優先檢查 原因判斷
網域取得的地址不符合預期 [Host] 是否存在同名映射 固定映射可能覆蓋一般 DNS 結果
主網域有效,子網域沒有變化 是否為子網域單獨建立映射 主網域與子網域是不同名稱
地址正確但策略錯誤 [Rule] 順序與 Global Routing Host 不負責選擇對外連線策略
區域網路名稱無法存取 skip-proxy 與目前網段 問題可能出在 General,而非 Host

Host 的職責

輸入
完整網域
輸出
IPv4 或 IPv6 地址
影響
解析結果
不決定
PROXY / DIRECT

完成地址映射後,請求仍需進入 Rule 判斷策略。

Rule 的職責

輸入
網域或目標地址
檢查
由上而下
輸出
策略
兜底
FINAL

不要用 Host 映射取代分流,也不要用 Rule 取代地址映射。

[URL Rewrite]:跳轉、拒絕與 HTTPS 可見性

[URL Rewrite] 依據 URL 比對表達式改變請求結果。常見用途包括返回 302 跳轉,或使用 reject 阻止符合條件的請求。它處理的是 URL,而 [Rule] 主要依據網域、地址或地域選擇策略,兩者不能互相取代。

表達式中的句點需要跳脫,路徑邊界也應盡量寫清楚。過於寬泛的表達式可能同時命中頁面、介面與靜態資源,導致網頁結構缺失或應用程式請求失敗。開始編寫時應先限定一個測試網域與一條路徑,確認結果後再擴大範圍。

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302
^http://api\.example\.com/private - reject

第一行將精確的舊地址跳轉至新地址,末尾的 302 是暫時跳轉狀態。第二行使用連字符佔據替換目標的位置,並以 reject 作為處理動作。欄位之間使用空格,正則表達式內不應加入中文標點。

HTTPS 請求的路徑位於加密內容中,僅憑網域連線不一定能檢查完整 URL。需要查看或改寫 HTTPS 路徑時,必須在 Shadowrocket 中完成使用者明確授權的憑證與解密範圍設定,並只對自己確認的測試網域啟用。未設定相應範圍時,HTTP 範例有效而 HTTPS 範例無效,這屬於加密可見性差異,不一定是正則表達式寫錯。

最小完整設定與匯入後的核對步驟

組合四個區段時,建議先建立一份只包含少量測試行的最小設定。最小設定的價值不是涵蓋所有需求,而是讓每個現象都能對應到一行:DNS 由 General 控制,地址覆寫由 Host 控制,分流由 Rule 控制,URL 動作由 URL Rewrite 控制。

[General]
bypass-system = true
dns-server = system
skip-proxy = 127.0.0.1, localhost, *.local, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

[Host]
test.example.com = 192.0.2.10

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

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

匯入後進入 Config,確認該設定處於選取狀態,再回到 Home 將 Global Routing 設為 Config。如果使用自己既有服務供應商提供的設定訂閱,更新後應重新檢查本機修改是否仍然存在;遠端更新可能以新內容取代舊內容。需要測試 URL 形式時,可使用明顯的範例地址 https://example.com/sub?token=xxxx 理解欄位位置,不應將範例值視為可用服務。

  1. 保留原始 .conf 副本,並為測試檔案使用容易辨認的名稱。
  2. 檢查所有區段名稱是否使用英文方括號,區段名稱後不要附加多餘字元。
  3. 檢查 Rule 行是否使用英文逗號,策略是否位於行末。
  4. 確認具體規則位於寬泛規則之前,FINAL 位於最後。
  5. 確認 Host 中的地址格式正確,網域沒有協定前綴與路徑。
  6. 確認 URL Rewrite 中的正則表達式、替換目標與動作欄位數量完整。
  7. 進入 Home 檢查 Global Routing,接著分別測試解析、分流與改寫。

如果設定無法正常運作,不要同時修改多個區段。先暫時保留 [General] 與一條 FINAL,確認基本連線;接著加入一條 DOMAIN 測試規則,再加入 Host 映射,最後測試 URL Rewrite。分階段恢復可以快速判斷錯誤屬於解析、比對還是改寫。

設定能匯入,但自訂 Rule 沒反應?

先在 Home 檢查 Global Routing 是否為 Config,再確認 Config 中選取的確實是剛編輯的檔案。接著將目標 DOMAIN 規則移到相同網域的 DOMAIN-SUFFIXFINAL 之前。

加入 Host 後,網域仍使用原來的地址?

核對請求使用的是否為完全相同的網域,主網域與子網域應分別檢查。然後重新選取設定並發起新請求,避免用舊連線的結果判斷新映射。

HTTP 改寫有效,HTTPS 改寫無效?

先確認正則表達式本身能比對目標 URL。若路徑位於 HTTPS 加密內容中,還需檢查是否已對該測試網域完成使用者授權的憑證與解密範圍設定。

存取區域網路設備時一直失敗?

查看設備地址是否屬於目前 Wi-Fi 的私有網段,再核對 skip-proxyIP-CIDR 是否包含該範圍,並確認更具體的前置規則沒有先命中其他策略。

更新既有設定後,本機修改不見了?

遠端設定更新可能取代目前內容。修改前保留獨立副本,更新後比較 General、Rule、Host 與 URL Rewrite 四個區段,再將仍需使用的本機規則依正確順序合併。

設定檢查的最終判斷標準

設定正確不能只以「連線開關已開啟」判斷。完整驗證至少包含四項:網域是否取得預期地址、Global Routing 是否處於預期狀態、請求是否命中正確策略、URL Rewrite 是否只影響目標路徑。每一項都應能對應至明確區段與具體設定行。

Shadowrocket 是 Apple 平台的閉源商業應用程式,主要供 iPhone 與 iPad 使用;Mac、Apple TV 與 Apple Vision 的相容性及系統要求以 App Store 頁面標示為準。正版取得入口為 App Store,開發者名稱為 Shadow Launch Technology Limited,應用程式 ID 為 932747118,採一次買斷制。客戶端購買與使用者既有的服務設定屬於不同事項。

結論:以可重現的單一變數測試驗收設定

每次只修改一行,並記錄測試網域、目前 Global Routing、預期策略與實際現象。能穩定重現「哪一行改變了哪個結果」,才表示已正確理解設定結構。

核對正版入口 查看 App Store 取得說明