Shadowrocket .conf 設定檔結構：逐段看懂 [General]、[Rule]、[Host]、[URL Rewrite]

本文速覽

適合已在 Shadowrocket（小火箭）設定好自有連線服務，準備閱讀或修改 .conf 的使用者。先了解四個設定段的用途，再逐項檢查參數、規則順序、網域對應與網址改寫，最後在 Config 選用設定檔並確認結果。文中的 example.com 與測試網址僅用於說明語法，並非可用的連線服務。

一、先分清 .conf、連線資訊與運作模式

.conf 是文字設定檔，方括號內的名稱是設定段標題，不是資料夾。每個設定段從標題開始，到下一個設定段標題前結束；空行主要方便閱讀。規則若寫在錯誤的設定段，即使英文單字都拼對，應用程式也不會因此按預期解析。

Home 管理使用者已有的連線項目，Config 管理設定檔，Settings 管理 App 設定。訂閱匯入的連線資訊與目前選用的 .conf 不能畫上等號：更新連線清單不代表已切換設定檔；儲存設定檔也不代表 Global Routing 已改成 Config。

4 個設定段

本文解析 General、Rule、Host、URL Rewrite

確認 2 處

Config 目前選用的檔案，以及 Home → Global Routing

命中 1 條規則

Rule 依序比對，採用第一條符合的規則

Global Routing 中的 Config 代表依目前設定進行分流；Proxy 與 Direct 用來切換整體路由處理方式；Scene 則用於依情境選擇。檢查本文的 Rule 範例時，先確認選的是 Config，避免把模式差異誤判為檔案未儲存。

二、[General]：全域參數採用鍵值語法

[General] 中通常使用 鍵 = 值，與 Rule 的逗號分隔語法不同。這裡的參數決定全域處理方式，例如 DNS 伺服器設定。不要把整段網路參數當成通用最佳化清單直接覆寫：目前網路環境、既有 DNS 設定及規則對解析的需求，都可能影響結果。

[General]
dns-server = system

這段內容僅示範使用系統 DNS 的寫法，不保證適用於所有網路。DNS 解析成功與連線成功是兩個階段：取得目標位址後，仍須經過路由選擇、建立連線及應用層互動。網頁無法開啟時，若只替換 DNS 而不檢查後續階段，容易掩蓋真正問題。

General 的閱讀方式

設定段標題: [General]
參數鍵: dns-server
範例值: system

先確認參數用途，再修改等號右側的值。

Rule 的閱讀方式

設定段標題: [Rule]
比對條件: DOMAIN,example.com
處理策略: PROXY

規則依序填入類型、比對值與策略，不使用等號。

檢查文字時也要留意標點：設定段標題使用半形方括號，參數使用半形等號，規則使用半形逗號。中文逗號、全形空格或從富文字內容複製的引號，都可能讓看起來相似的內容變成不同字串。

三、[Rule]：先寫具體條件，最後設定 FINAL

[Rule] 決定流量採用哪種策略。規則由上而下比對，命中第一條規則後就採用該條策略，不會繼續尋找後面更「精確」的規則。因此，順序也是設定的一部分；若把 FINAL 放在前面，後續規則就沒有機會在兜底規則之前比對。

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

關鍵字	本例的比對對象	結果與注意事項
`DOMAIN`	`api.example.com` 完整網域	先命中 DIRECT，不再採用下一條 PROXY。
`DOMAIN-SUFFIX`	`example.com` 及其子網域	其他符合條件的網域使用 PROXY。
`IP-CIDR`	`192.0.2.0/24` 位址範圍	使用 DIRECT；此位址範圍僅供文件範例使用。
`GEOIP`	位址資料庫分類為 CN 的目標 IP	依 IP 分類，不依網頁語言或網域後綴判斷。
`FINAL`	前面規則都未命中的流量	本例以 DIRECT 作為兜底策略。

no-resolve 表示不為了比對這條 IP 規則而主動進行網域解析，並非關閉整個 App 的 DNS。若請求本身已有目標 IP，仍可依位址範圍判斷。範例中的 GEOIP 沒有加上這個選項，閱讀時不要把單一規則的選項當成整個 Rule 設定段的設定。

PROXY 是一種策略，不會自動建立伺服器資訊。使用時需要有可用的連線項目；DIRECT 表示直接連線，也不保證目前網路一定能連上目標。驗證時應同時檢查命中的策略與實際連線結果。

四、[Host]：指定解析位址，不指定代理策略

[Host] 用於本機網域對應，回答的是「這個名稱對應到哪個位址」，而不是「這個請求走哪條路由」。以下將範例網域對應到文件測試位址；該位址不是提供網頁服務的公開伺服器，不能以連線失敗來判斷語法是否有效。

[Host]
lab.example.com = 192.0.2.10

這裡設定的是網域與位址的對應，等號左側不能放完整 URL；不要加上 https:// 或路徑。
Host 不負責轉換連接埠。存取 https://lab.example.com/ 時，一般 HTTPS 預設連接埠仍為 443；一般 HTTP 預設連接埠為 80。
HTTPS 仍須驗證憑證。將網域指向另一台伺服器，不會讓該伺服器的憑證自動符合原網域。
完成對應後，仍須配合 Rule 判斷路由。若要讓該網域採用 DIRECT，可在 Rule 中明確加入 DOMAIN,lab.example.com,DIRECT，並放在可能涵蓋該網域的廣泛規則之前。

App 本身的解析快取、已重複使用的連線，以及 App 使用自有加密 DNS 等情況，都可能讓單次測試無法呈現預期變化。修改後先關閉舊頁面，再重新發出請求；必要時重新建立 Shadowrocket 連線。不要在尚未查明快取問題前，連續新增多筆 Host 項目。

五、[URL Rewrite]：改變請求網址，不取代 Rule

[URL Rewrite] 會以正則表達式比對 URL，再依指定動作處理。以下示範將範例網域的 HTTP 請求重新導向至 HTTPS；結尾的 302 是重新導向狀態碼，不是連接埠號碼，也不是代理策略名稱。

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

^ 將比對範圍限制在 URL 開頭；\. 代表網域中的實際句點，避免將任意字元當成句點。
(.*) 擷取斜線後的內容，目標網址中的 $1 則引用第一組擷取結果。
依照這個表示式，http://example.com/docs 對應的重新導向目標為 https://example.com/docs。
重新導向後產生的新請求仍須依路由設定處理。將網址改為 HTTPS，不代表策略也改成 PROXY。

瀏覽器可能因 HSTS 或已快取的重新導向而直接使用 HTTPS，讓範例中的 HTTP 規則沒有比對機會。測試時應區分「用戶端沒有送出 HTTP 請求」與「改寫表示式錯誤」，不要只看網址列最後顯示 HTTPS，就認定規則已執行。

六、在 Config 儲存、選用並驗證

修改檔案的最後一步不是離開編輯器，而是確認儲存的是哪個檔案、目前選用的是哪個檔案，以及連線是否已重新載入。以下從已存在的本機設定檔開始；編輯時每次只修改一個設定段，測試通過後再處理下一項。

保留原始檔案

進入 Config，先匯出或複製要修改的檔案。記下檔名，以免將同名的遠端設定與本機副本混淆。
編輯文字

在 Config 點選目標檔案，進入 Edit Plain Text。依照對應的設定段標題修改內容，檢查半形標點後儲存。
選用設定檔

返回 Config，點選這份檔案並選擇 Use Config，確認目前選用標記指向修改後的檔案，而不只是停留在編輯畫面。
確認運作模式

進入 Home → Global Routing → Config。檢查 Home 中選取的連線項目；若自動連線影響測試，再到 Settings → On Demand 檢查觸發設定。
重新驗證

必要時先中斷連線再重新連線，重新發出目標請求並檢查請求紀錄。以原本可正常存取的目標作為對照，不要把 Connectivity Test 的單次結果當成完整的規則驗證。

分開驗證：路由命中與內容處理

檢查 Rule

將 Global Routing 保持在 Config。
分別測試精確網域，以及後綴相同的其他網域。
核對請求紀錄中的目標、命中規則與策略。

檢查 Host 與改寫

確認請求確實使用預期的解析方式。
檢查目標位址、通訊協定與重新導向回應。
排除舊連線、快取與 HSTS 的影響。

先確認檔案已載入，再確認請求經過相應處理；每次只調整一個變數。

七、修改設定後的常見問題

檔案已儲存，為什麼流量仍全部採用同一策略？

先檢查 Home → Global Routing 是否選擇 Config，再回到 Config 確認目前選用的檔案。接著檢查 Rule 前段是否有涵蓋範圍過大的規則，或 FINAL 是否出現得太早。儲存文字、選用檔案、選擇模式是三個不同動作。

Host 已改成新位址，為什麼 HTTPS 仍出錯？

確認新伺服器是否有監聽 443，以及提供的憑證是否涵蓋原網域。Host 只會改變解析結果，不會改變 URL 中的主機名稱，也不會略過憑證驗證。恢復原本的對應後再測試，可判斷問題是否由這次位址變更造成。

更新訂閱後，Rule 會自動更新成新內容嗎？

不能這麼推斷。Home 的連線訂閱更新與 Config 的遠端檔案更新應分開確認。前者主要更新連線項目，後者才會影響設定文字；使用本機副本時，也要確認目前選用的仍是該副本。

只想讓幾個網站走 PROXY，需要修改四個設定段嗎？

通常只需在 Rule 中加入目標網域的 PROXY 規則，並依需求以 FINAL,DIRECT 作為兜底。不必為了補齊結構而新增 General、Host 或 URL Rewrite。前提是已有可用的連線項目，且 Home → Global Routing 已選擇 Config。

設定檔的檢查順序可以固定為：先確認設定段標題與語法，再檢查規則順序，最後確認運作模式與實際請求。若要繼續排查連線問題，可閱讀故障排除；不確定關鍵字的意思時，可參閱術語手冊。如此便能分開處理文字錯誤、路由選擇與網路連線狀況。