Shadowrocket .conf 設定檔結構與用法：General、Rule、Host、URL Rewrite 說明

本文重點

閱讀 .conf 時，先分清基本設定、路由規則、網域映射與請求改寫，再確認目前啟用的檔案和 Global Routing。本文適合已有服務商與訂閱、需要修改本機設定的使用者；範例僅說明語法，不含可用的連線參數。修改後請查看 App 內的連線記錄，確認實際命中的規則。

1. .conf 檔案結構：段落名稱決定內容用途

Shadowrocket（小火箭）的 .conf 是文字設定檔。方括號內是段落名稱，後續內容都屬於該段，直到出現下一個段落名稱為止。[General] 常見的是鍵值設定；[Rule] 則是一行一條比對規則。即使內容正確，放錯段落也無法達到預期效果。

Home 主要用於連線與選擇伺服器，Config 用於管理設定檔，Settings 用於調整 App 設定。訂閱提供的伺服器參數，和 .conf 中決定流量走向的規則是兩回事。匯入或更新伺服器清單，不代表目前使用的設定檔也會一併切換。

4 個段落

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

3 個入口

Home、Config、Settings 各有用途

1 條兜底規則

範例將 FINAL 放在 Rule 段落末尾

以下片段用來辨認檔案結構，並非包含伺服器資訊的完整連線設定。example.com 是範例網域，192.0.2.10 是文件專用範例位址；請勿將它們當成實際參數留在日常設定中。

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

[Host]
example.com = 192.0.2.10

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

同一個檔案包含這些段落，不代表每次請求都會嚴格依照段落順序逐一執行。段落是整理設定的方式；解析、路由與改寫各有不同的處理條件。尤其不能將上述排列理解為「先 Rule、再 Host、最後 URL Rewrite」的固定請求流程。

2. General：基本行為與 DNS 設定

[General] 用來存放基本設定。閱讀這個段落時，請逐項確認鍵名、等號右側的值，以及值清單所使用的分隔符號。不要直接貼上其他設定格式中看似相近的欄位；應以 Shadowrocket 編輯介面能辨識、儲存並實際使用的設定項目為準。

[General]
dns-server = system

此處的 dns-server = system 表示使用系統 DNS。這不代表所有請求都必定使用 DIRECT，也不能用來指定特定網站走 PROXY。DNS 負責解析網域，路由規則負責選擇策略。兩者會影響問題排查結果，但用途不同。

網域無法開啟，但直接連線 IP 有回應：先核對解析結果與 DNS 設定，不要立刻替換整份 Rule。
網域能解析，但出站策略不符：檢查 Global Routing 與實際命中的 Rule，不要只更換 DNS。
切換網路後結果不同：系統 DNS 可能隨目前網路而變，請記下測試時使用的是 Wi-Fi 還是行動網路。
編輯既有檔案：優先修改原有的同名設定，避免重複加入相同鍵名，導致覆寫結果不明。

修改 DNS 與修改路由應分開測試。若一次變更多項 General 設定、Host 映射和 Rule，即使網頁恢復正常，也無法確認是哪項設定生效，日後還更難還原。

3. Rule：由上往下比對，FINAL 放在末尾

[Rule] 用來決定請求採用哪種策略。規則依序比對，第一條符合的規則會決定處理方式；越精確的規則應放在較寬泛的規則之前。FINAL 不帶網域或位址條件，用來接住前面都未命中的流量，因此應放在這個段落的最後。

關鍵字	語法範例	檢查要點
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,PROXY`	比對該網域及其子網域，不是比對任意包含該字串的內容。
`IP-CIDR`	`IP-CIDR,192.0.2.0/24,DIRECT,no-resolve`	依 IPv4 網段比對；no-resolve 可避免為這條規則主動進行網域解析。
`GEOIP`	`GEOIP,CN,DIRECT`	依 IP 地理資料庫分類判斷，不是依網頁語言判斷。
`FINAL`	`FINAL,PROXY`	不附加其他比對條件，作為最後的兜底規則。

PROXY 與 DIRECT 是策略，不是協定名稱。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等連線類型的參數，應在對應的伺服器設定中核對；不能用 FINAL,Trojan 取代策略。若使用自訂策略名稱，也要確認該名稱確實存在且可用。

[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,PROXY

依照這個順序，api.example.com 會先命中 DOMAIN，採用 DIRECT；www.example.com 則會命中後面的 DOMAIN-SUFFIX，採用 PROXY。若將 DOMAIN-SUFFIX 移到前面，前面的精確例外就沒有機會生效。測試時請造訪完整的目標主機名稱，不能用同一網站的其他子網域代替。

結論：先找出命中規則，再修改兜底設定

目標流量若已命中前面的 DOMAIN 或 DOMAIN-SUFFIX，修改 FINAL 不會改變其策略。請先在連線記錄中找出命中的規則，再調整對應規則的位置或內容。

4. Host 與 URL Rewrite：位址映射不等於改寫請求

[Host] 可為指定網域設定位址映射；[URL Rewrite] 則依請求 URL 的比對運算式進行改寫或重新導向。前者處理「這個名稱對應哪個位址」，後者處理「符合條件的 URL 如何變更」。兩者都不能取代 Rule 中的路由策略。

Host 映射

段落名稱: [Host]
左側: example.com
右側: 192.0.2.10
寫法: example.com = 192.0.2.10

範例位址僅供理解語法，實際映射內容須由使用者確認。

URL Rewrite 重新導向

段落名稱: [URL Rewrite]
比對運算式: ^http://example\.com/
目標位址: https://example.com/
動作: 302，暫時重新導向

運算式、目標位址與動作之間以空格分隔。

Host 不會將瀏覽器網址列中的網域轉成 IP，也不會讓目標伺服器自動接受該網域。對 HTTPS 而言，憑證名稱仍須符合造訪的主機名稱；若將網域映射到名稱不符的伺服器，可能會遇到憑證錯誤或網站回應異常。請修正映射，不要把停用憑證驗證當成一般解法。

URL Rewrite 範例中的 ^ 表示從開頭比對，\. 表示網域中的字面句點，302 表示讓用戶端轉向目標 URL。此範例只示範將 HTTP URL 重新導向至 HTTPS 位址，不保證保留任意路徑與查詢參數；若要保留這些內容，必須明確設計擷取群組與替換運算式。

先用單一測試 URL 驗證運算式，不要直接使用可比對所有網域的寬泛寫法。
HTTP 範例不需要解密 HTTPS 內容；若規則需要讀取 HTTPS 路徑或內容，通常還需要另外設定 HTTPS 解密條件與信任設定。
加入 Host 後無法正常瀏覽，請先撤回該筆映射；加入 URL Rewrite 後不斷跳轉，請先檢查目標 URL 是否再次觸發同一條規則。

5. Config 編輯流程：備份、儲存、啟用、驗證

在 Config 編輯檔案前，先確認目前實際啟用的是哪一份設定。檔案出現在清單中、文字已儲存，以及設定檔已選取並啟用，是三種不同狀態。只修改未啟用的檔案，不會讓目前連線立即採用新規則。

保留原稿編輯副本儲存並啟用確認模式建立新請求核對記錄

保留原檔：在 Config 確認原檔名稱，並透過檔案操作保留副本或匯出原稿。若檔案來自遠端設定網址，請先保留可還原的本機版本，以免後續更新覆蓋手動修改。
進入編輯：從目標設定檔的檔案操作進入文字編輯功能。保留段落名稱，依需要修改其中一項；不同版本的介面配置可能不同，入口也可能位於檔案操作選單中，請以目前畫面為準。
檢查語法並儲存：Rule 欄位之間使用英文逗號，General 與 Host 的鍵值使用等號，URL Rewrite 的欄位則以空格分隔。請避免誤將中文逗號、全形方括號或說明文字加入參數。
選取設定檔：返回 Config 清單，確認編輯後的檔案已啟用；接著前往 Home 檢查目前的伺服器與連線狀態。
核對 Global Routing：測試 Rule 時請使用 Config。Proxy 與 Direct 是整體路由模式，不能只憑兩者的連線結果判斷某一條 Rule 是否有效；若使用 Scene，也要確認場景實際採用的設定與策略。
建立新連線：儲存後重新送出測試請求，必要時先中斷再連線。既有連線與快取可能保留舊狀態，請以新的連線記錄比對目標網域、命中規則與最終策略。

Settings → On Demand 用來設定自動連線條件，不會決定 Rule 的排列順序。排查「修改後又自動連線」時，請檢查這個入口；排查「特定網域採用錯誤策略」時，則應回到 Global Routing 與目前使用的設定檔。將自動連線問題與分流問題分開，才能準確找出需要修改的範圍。

6. 常見問題：設定未生效、更新遭覆蓋與還原

以下問題都應交叉核對目前使用的檔案、目前模式，以及新請求的記錄。瀏覽器顯示「可以開啟」只代表這次連線成功，不能單獨證明某條規則已執行，也不能證明使用的是預期伺服器。

已儲存 Rule，為什麼流量還是採用原本的策略？

先在 Config 確認選取的是剛編輯的檔案，再檢查 Home → Global Routing 是否設為 Config。查看新請求的連線記錄；若已命中前面的規則，請修改該規則或調整順序，不要繼續在 FINAL 後面新增規則。

更新訂閱後，手動編寫的 .conf 也會一起更新嗎？

伺服器訂閱更新與遠端設定更新是不同操作。請先確認更新的是 Home 中的伺服器清單，還是 Config 中的遠端檔案。重新取得遠端設定時，本機內容可能遭到取代；重要修改請先保留副本，並在更新後逐項比對。

加入 Host 後出現憑證錯誤，該修改哪裡？

先撤回新增的映射，再使用新連線測試。確認映射位址確實對應原本的主機名稱，並核對伺服器憑證。不要為了保留錯誤映射而停用憑證驗證；Host 只能改變位址對應關係，不能改變憑證涵蓋的名稱。

設定出錯後如何還原，又不影響既有訂閱？

在 Config 重新選取備份檔，恢復測試前的 Global Routing，再重新建立連線驗證。不要先刪除 Home 中既有的伺服器或訂閱。確認舊設定恢復正常後，請在副本中每次只加入一項修改，逐步找出出錯的規則。

最後依序檢查：先確認檔案已啟用，再確認路由模式，接著查看命中結果，最後才處理 DNS、Host 或改寫條件。設定檔的用途，是讓行為有跡可循、修改後可還原，而不是把越多欄位塞進同一份檔案越好。