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

本文重點

修改 .conf 時，先依用途區分各段，再確認 Config 中實際啟用的檔案。General 放通用參數，Rule 決定連線策略，Host 定義靜態名稱對應，URL Rewrite 處理符合條件的 URL。本文適合已有伺服器資料、需要閱讀或維護設定檔的使用者；範例僅示範語法，不含可用伺服器，也不能取代現有設定檔的備份。

1. 先看設定檔結構：段落名稱不是執行步驟

Shadowrocket（小火箭）的 .conf 是文字設定檔。方括號中的名稱用來劃分設定段，例如 [General]；後續各行都屬於這一段，直到出現下一個段落名稱。不同段落採用不同語法：通用參數和靜態對應通常使用等號，Rule 則以逗號分隔關鍵字、比對條件與策略。

以下僅涵蓋本文介紹的四個段落，不代表完整設定檔只能有這四段。閱讀既有檔案時，應保留不熟悉的其他段落，不要為了配合範例而刪除。檔案中各段的排列順序也不代表網路請求的時間順序；不能將「Host 寫在 Rule 後面」解讀為一定先分流、再進行名稱解析。

4 個段落

本文涵蓋 General、Rule、Host、URL Rewrite

3 個逗號

IP-CIDR 範例含 no-resolve 時的欄位分隔數量

1 條 FINAL

本文 Rule 範例最後的預設策略

[General]
dns-server = system

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

[Host]
lab.example.test = 192.0.2.10

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

example.com、example.test 和 192.0.2.0/24 在此僅供文件示範使用。其中，靜態對應所指向的位址不是可供實際連線的伺服器。請勿將整份範例直接取代日常使用的設定檔；較妥當的做法是在副本中逐段驗證格式。

2. General：通用參數不等於分流規則

[General] 用來保存通用設定。本文只使用一個容易核對的參數：dns-server = system。等號左側是參數名稱，右側是值；system 表示使用系統 DNS。不要將它寫進 [Rule]，也不要套用 Rule 的逗號分隔格式。

[General]
dns-server = system

[General]：宣告後續內容屬於通用設定段。
dns-server：指定此處設定的 DNS 參數。
system：使用目前系統提供的 DNS，而非在範例中指定固定的解析器位址。

DNS 用於解析名稱，不能取代伺服器連線，也無法單獨決定連線要走 PROXY 或 DIRECT。例如，網域名稱已解析出 IP 位址，伺服器連線仍可能失敗；反過來，伺服器延遲測試有結果，也不代表目前的 DNS 一定能解析目標網域。排查時應分別記錄解析結果與連線結果。

3. Rule：由上而下比對，FINAL 放在最後

[Rule] 是分流規則段。在 Home → Global Routing 選擇 Config 後，應依目前啟用的設定檔核對比對結果。Proxy 是統一代理模式，Direct 是統一直連模式；這兩種模式都無法用來驗證剛修改的逐條分流規則。使用 Scene 時，則需先確認所選場景及其條件，不應預設它等同於 Config。

比對條件

DOMAIN-SUFFIX: example.com,PROXY
IP-CIDR: 192.0.2.0/24,DIRECT,no-resolve
GEOIP: CN,DIRECT

三行分別依網域後綴、IP 網段和 IP 地理位置條件進行比對。

策略與預設處理

PROXY: 交由代理策略處理，仍須有可用的代理連線。
DIRECT: 直接連線至目標，不經代理伺服器轉送。
FINAL: 前面的規則都未比對成功時，使用指定策略，例如 FINAL,PROXY。

REJECT 用來拒絕符合條件的連線，不能誤寫成直連策略。

DOMAIN-SUFFIX,example.com,PROXY：比對 example.com 及其子網域，例如 www.example.com。這不代表會模糊比對任何包含這段文字的網域名稱。
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve：比對指定的 IPv4 網段。no-resolve 表示不為判斷這條 IP 規則而主動觸發網域解析；它並非關閉整個應用程式的 DNS。
GEOIP,CN,DIRECT：依據 IP 地理位置資料比對 CN。此處判斷的是 IP 資料，不是網域後綴或伺服器資料中的地區標籤。
FINAL,PROXY：將前面未比對成功的連線交由 PROXY 處理。這條規則只有策略欄位，沒有網域或網段條件。

連線符合前面的規則後，後續規則就不會再為它重新選擇策略。因此，範圍較小的例外規則應放在涵蓋範圍較大的規則之前，FINAL 則應放在最後。已經符合前一條規則的連線，不會因為你在檔案底部新增例外規則而改變結果。

結論：先確認模式，再調整順序

規則看似正確卻沒有預期效果時，先確認 Home → Global Routing 設為 Config，再檢查目前使用的檔案及第一條可能符合的規則；不要先反覆新增相同網域的規則。

4. Host：靜態名稱對應不負責選擇策略

[Host] 會將指定主機名稱對應到指定位址，適用於已確認目標位址的情況。它回答的是「這個名稱應對應哪個位址」，而不是「這次連線應使用哪個連線出口」。即使位址來自 Host，仍須依目前的路由模式及相關規則判斷如何處理連線。

[Host]
lab.example.test = 192.0.2.10

lab.example.test 是完整主機名稱。此處沒有宣告使用萬用字元對應其子網域。
使用 = 分隔主機名稱與位址，不要改用 Rule 所用的逗號。
192.0.2.10 是文件中的示範位址。實際使用時，必須換成已確認的目標位址。

靜態位址可能因目標服務調整而失效，尤其是採用動態調度的服務。發生問題時，先在設定檔副本中移除這筆對應並重新連線，比較是否恢復，不要繼續增加更多 Host 項目。

5. URL Rewrite：改寫 URL，不負責選擇代理

[URL Rewrite] 用來改寫符合條件的 URL。它與 Rule 的差異在於：Rule 選擇連線策略，URL Rewrite 則處理請求 URL。不要將網域分流規則原封不動放進這個段落，也不要用重寫規則取代代理伺服器參數。

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

欄位	範例	說明
比對運算式	`^http://example\.com/`	比對以指定 HTTP 位址開頭的 URL；點號前的反斜線用來比對字面上的點號。
目標 URL	`https://example.com/`	本例使用固定的目標位址，不示範路徑擷取與回填。
動作	`302`	回傳暫時重新導向，讓用戶端依目標 URL 發出後續要求。

這一行刻意只比對明文 HTTP。原始 URL 若包含路徑或查詢參數，本例也不會自動保留，因為目標欄位沒有引用擷取群組。若要保留路徑，應先確認正規表示式的擷取範圍，再逐項驗證結果，避免登入回呼或查詢參數在重新導向後遺失。

不要直接將本例延伸為「所有 HTTPS 位址都能依路徑改寫」。HTTPS 內部 URL 的可見性涉及 MITM 等額外條件，並受應用程式行為及憑證機制影響。本文不要求啟用 MITM，也不涉及安裝憑證；範例僅用於說明這個段落的欄位結構。

先用一個明確的測試 URL 確認是否符合條件，不要一開始就使用涵蓋所有網域的運算式。
目標 URL 不應再次符合相同的重新導向條件，以免形成循環。
瀏覽器可能會自動升級 HTTP 或使用快取；若未觀察到重新導向，應先確認實際送出的要求位址。

6. 在 Config 套用設定：儲存檔案、選取檔案、重新建立連線

完成編輯不代表目前的連線已套用新設定。Config 中可能同時有多個本機檔案與遠端設定，必須確認實際選取的是哪一份。若檔名相似，可先替測試副本取個容易辨識的名稱，並保留原檔以便還原。

備份原始檔修改副本儲存並選取確認模式重新驗證

進入 Config，記下目前啟用的檔名，並保留原始檔副本。開啟待修改檔案的編輯畫面後，確認段落名稱及準備調整的行。
一次只修改一個段落中的少量內容。儲存後返回 Config，確認編輯結果確實保留，再選取準備測試的設定檔。
返回 Home → Global Routing，選擇 Config。若使用 Scene，先確認場景選擇結果，再決定是否暫時切換至 Config 進行隔離驗證。
確認 Home 中已選取可用的伺服器。PROXY 只是策略名稱，不會自動產生伺服器位址、連接埠或驗證資料。
若可接受短暫中斷網路，請關閉再開啟連線開關，然後重新送出目標要求。既有的長連線可能繼續沿用，不要只查看修改前已開啟的頁面。
搭配要求記錄核對目標網域、目標 IP 和策略結果。若實際行為不符，還原原始設定後重複相同測試，確認差異是否由這次修改造成。

也要區分伺服器訂閱與 .conf 設定檔：前者通常用來維護伺服器資料，後者則用來維護規則及通用設定。更新伺服器訂閱不代表已切換 Config 中啟用的檔案；重新取得遠端設定，也可能覆蓋你直接寫入該檔案的修改。長期維護前，應先確認哪份來自遠端，哪份是自己的本機副本。

結論：以可還原的單項變更驗證設定

每次記錄「修改了哪一行、啟用了哪個檔案、測試了哪個要求」。只有當同一個要求在修改前後出現可解釋的差異，才將這項變更保留在日常設定中。

7. 常見問題：依症狀找出相關設定段

修改了 Rule，為什麼所有網站仍然走同一種連線方式？

先前往 Home → Global Routing 確認是否選擇 Config，再到 Config 確認啟用的檔案。若結果仍相同，檢查 Rule 前段是否有涵蓋範圍過大的規則，以及 FINAL 是否出現得太早。請用新送出的要求驗證，不要只重新整理既有的長連線。

在 Host 中填入位址，為什麼 HTTPS 仍然出錯？

確認該位址是否確實提供目標主機名稱的服務，並檢查憑證是否適用於這個網域。Host 只會變更名稱對應。先在副本中移除該行進行比較，不要透過放寬憑證驗證來掩蓋位址填錯的問題。

URL Rewrite 已儲存成功，卻沒有看到重新導向？

確認實際要求是否以範例中的 HTTP 位址開頭，再檢查正規表示式中的反斜線、空格分隔及末尾動作。若瀏覽器在送出要求前已升級為 HTTPS，這條只比對 HTTP 的規則便不符合條件。

更新後手動修改的規則不見了，該檢查哪裡？

先在 Config 確認目前選取的檔案，再檢查是否重新取得了遠端設定。比對事先保留的本機副本，只移入確認需要的修改。不要將伺服器訂閱更新和設定檔更新視為同一項操作。

繼續調整前，可參閱規則參考核對關鍵字，或查看設定說明，分辨路由模式與其他功能。Settings → On Demand 用來管理隨選連線條件，不能取代 Config 檔案選擇，也不會改變 Rule 每一行的格式。