Shadowrocket .conf 設定檔結構解析：General、Rule、Host、URL Rewrite 段落說明

本文重點

Shadowrocket（小火箭）的 .conf 檔案用來設定連線環境、規則比對、靜態網域對應與 URL 重寫。本文適合已有自己的連線設定，並準備調整流量分流方式的使用者：先辨識四個段落，再用最精簡的範例確認語法，最後在 Config 選取修改後的檔案，並回到 Home 確認實際比對結果。連線參數與分流檔案需要分別檢查；儲存檔案不代表已切換至該檔案。

一、先分清檔案與連線參數

Home、Config、Settings 管理的內容各不相同。Home 用來選取現有連線、查看連線狀態與 Global Routing；Config 管理設定檔及其規則；Settings 提供應用程式設定，例如 Settings → On Demand 的隨選連線條件。排查問題時，先確認要變更的是「何時連線」、「連線至何處」，還是「如何處理特定請求」。

一般的訂閱更新主要維護連線項目，不能直接視為更新目前 .conf 的 Rule 段落。遠端更新設定檔也可能覆蓋本機修改，因此編輯前應先保留本機副本。本文假設使用者已有自己的服務供應商與訂閱，僅說明檔案結構及驗證方式。

段落	主要用途	無法取代的內容
`[General]`	設定 DNS、IPv6 等基本行為	特定網域的分流規則
`[Rule]`	依網域、IP 等條件選擇策略	連線項目的驗證參數
`[Host]`	為指定網域設定靜態位址對應	伺服器端的憑證與網站設定
`[URL Rewrite]`	比對 URL 並執行重新導向等動作	將流量導向 PROXY 的分流規則

方括號中的段落名稱屬於語法，請保留英文原文。常見寫法依序排列為 General、Rule、Host、URL Rewrite，方便閱讀；但這不代表四個段落會依序執行。真正需要特別留意順序的是 Rule 內的規則，而不是將整份檔案視為「從第一段執行到最後一段」的流程。

二、General：基本連線行為

General 常用「鍵 = 值」的格式。修改時請保留半形標點，布林值使用 true 或 false，不要將中文說明直接接在欄位值後面。以下片段僅供理解欄位用途，不是要求所有使用者取代原有設定的通用範本。

[General]
bypass-system = true
dns-server = system
ipv6 = false

General 欄位

bypass-system: true：保留應用程式對系統相關流量的略過處理。
dns-server: system：使用目前網路提供的系統 DNS。
ipv6: false：在設定層級停用 IPv6 支援，但無法替電信業者修復網路。

先記錄原始值；每次只修改一個欄位，再針對同一目標重複測試。

Rule 關鍵字

DOMAIN-SUFFIX: 比對完整網域後綴及其子網域。
IP-CIDR: 比對 IPv4 位址網段。
FINAL: 處理先前規則都未比對到的請求。

General 定義基本行為；Rule 決定請求採用的策略，兩者無法互相取代。

dns-server = system 不保證目前網路的 DNS 一定可用；它只指定解析來源。若發生網域無法存取，但連線測試仍有回應的情況，應先檢查解析結果，而不是只更換 Rule 的最終策略。連線測試能回傳延遲，也不能證明目標網站的 DNS、TLS 與 HTTP 請求都正常。

ipv6 = false 也不是通用的網頁修復開關。IPv4 與 IPv6 的連線能力、代理出口能力及目標位址可能各不相同。若原始檔案已針對所在網路設定 IPv6，請先保留原設定，再針對可重現的失敗目標逐項比較。

三、Rule：比對條件與策略

Rule 常見格式為「類型,比對內容,策略」，各欄位以半形逗號分隔。規則通常由上而下比對，符合後便採用相應策略；FINAL 不需額外比對內容，放在最後以處理其餘請求。以下範例表示：指定網域走 PROXY，文件範例網段與 GEOIP 為 CN 的位址走 DIRECT，其餘也走 DIRECT。

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

DOMAIN-SUFFIX,example.com,PROXY 會比對 example.com 及其子網域，不代表會比對所有包含這段字元的網域。
IP-CIDR 用來比對位址網段。範例中的 192.0.2.0/24 是文件用途的保留位址，不應視為可存取的業務網路。
no-resolve 表示不為這條 IP 規則額外發起網域解析；它並不是停用整份設定檔的 DNS。
GEOIP,CN,DIRECT 依據目標 IP 的地理資料庫分類進行比對，不會根據網頁語言、網域後綴或使用者目前所在位置判斷。
FINAL,DIRECT 會讓未比對到規則的流量直接連線；改成 FINAL,PROXY 則會改變所有未比對請求的去向。

較具體的例外規則通常應放在較廣泛的規則之前。例如，若要讓某個子網域走 DIRECT，而同一主網域的其他請求走 PROXY，應先寫 DOMAIN,static.example.com,DIRECT，再寫 DOMAIN-SUFFIX,example.com,PROXY。若順序相反，子網域可能已先被上方的後綴規則比對到。

四、Host：靜態網域對應

Host 使用「網域 = 位址」的格式，適用於已知固定位址的對應需求。它與 Rule 的用途不同：Host 說明「這個網域解析成哪個位址」，Rule 則說明「這個請求採用什麼策略」。只修改其中一項，不應預期另一項會自動同步變更。

[Host]
lab.example.com = 192.0.2.10

上述網域與位址僅用來說明語法。192.0.2.10 是文件範例位址，不是可用服務。實際填寫時，必須使用自己確認有效的目標位址，並確認目標伺服器能正確接收該網域的請求。

靜態對應不會隨目標網站遷移位址而自動更新；網站更換位址後，可能持續發生連線失敗。
多個網域共用同一個 IP，不代表彼此可以互換；HTTPS 仍需要網域、憑證與伺服器網站設定相符。
網頁通常也會載入圖片、指令碼與 API 網域；只對應主頁網域，不代表所有資源都改用同一個位址。
取消測試對應後，請重新建立相關連線，避免將舊連線仍在使用的結果誤認為新設定無效。

遇到憑證錯誤時，不要透過停用驗證來掩蓋錯誤的對應設定。請先刪除新增的 Host 行，還原原本的解析方式，再確認目標網域的憑證與伺服器位址。對於位址經常變動的公開網站，長期硬編碼位址通常會增加維護成本。

五、URL Rewrite：分開看重寫與分流

URL Rewrite 依據 URL 比對運算式執行指定動作，並不使用 DOMAIN-SUFFIX 這類 Rule 語法。以下片段使用正規表示式比對一個 HTTP 位址，再以 302 重新導向至 HTTPS 位址；此範例僅展示結構，不是可直接部署的業務規則。

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

此處的 ^ 限定從 URL 開頭開始比對，\. 代表句點字元，結尾的 302 是重新導向狀態碼。這個簡單範例會將符合條件的請求重新導向至固定位址，不會保留原請求的路徑與查詢參數；請勿用於需要保留參數的登入、付款或 API 請求。

檢查項目	Rule	URL Rewrite
比對對象	網域、目標 IP 等條件	可供處理的請求 URL
範例結果	採用 DIRECT 或 PROXY	回傳 302，前往另一個 URL
常見錯誤	過於寬泛的規則先行比對	正規表示式範圍過廣、路徑遺失或重新導向迴圈

HTTPS 的完整路徑與查詢參數位於加密請求中，一般分流無法讀取這些內容。若要檢查 HTTPS 請求內容並進行重寫，還需要另外設定 HTTPS 解密、憑證信任及網域範圍管理，無法只新增一行 URL Rewrite 就完成。單純驗證分流時，不必為了這段範例額外設定 HTTPS 解密。

六、儲存後在 Config 套用

編輯完成後，必須同時確認「檔案已成功儲存」及「目前正在使用這個檔案」。清單中看得到檔案，只代表檔案存在；若 Home 的 Global Routing 仍設為 Proxy 或 Direct，也不能用存取結果證明 Rule 已依預期執行。以下流程適用於小幅修改既有檔案。

保留原始檔案

進入 Config，記下目前選取的檔案，並先保留一份本機副本。若檔案來自遠端更新，請使用獨立副本進行測試，避免下次更新時被覆蓋。
編輯副本

在 Config 開啟副本的編輯畫面，只修改一個目標段落。檢查方括號、半形逗號、等號及策略名稱；儲存後重新開啟，確認內容無誤。
選取設定檔

返回 Config 檔案清單，選取修改後的檔案，確認選取標記對應的是副本，而不是原始檔案或名稱相近的其他遠端檔案。
切換模式

前往 Home → Global Routing → Config，確認 Home 目前選取的連線項目。必要時重新連線，讓後續請求使用新設定。
驗證請求

先使用 Home → Connectivity Test 檢查連線，再重新瀏覽同一個目標，並在連線記錄中確認網域、比對到的規則與策略；若失敗，請還原原始檔案後重新測試。

Config

建議

依目前選取的設定檔處理分流。驗證 Rule 順序、DOMAIN-SUFFIX 與 FINAL 時，應先確認目前使用的是這個模式。

適用情境：驗證本文的設定修改及日常規則分流。

Proxy

由應用程式處理且未被略過的流量都採用代理，而不是依 Rule 的一般分流結果逐條選擇。系統略過等基本行為仍須另外考量。

適用情境：暫時對照連線是否可用，區分代理故障與分流錯誤。

Direct

採用直連模式。此時目標能開啟，只能表示目前的直連路徑可用，不能證明 PROXY 項目或指定的代理規則運作正常。

適用情境：比較同一目標的直連結果，協助判斷故障範圍。

若目前使用 Scene，應先檢查該 Scene 實際關聯的設定檔與策略，不要只憑檔案名稱推斷生效範圍。為減少變數，首次確認本文規則時可先使用明確的 Config 模式。On Demand 管理的是自動連線條件，不會決定特定網域比對到哪一條 Rule。

七、常見問題與復原檢查

修改 FINAL 後，網站還是走原本的路徑？

先確認 Home → Global Routing 是否設為 Config，再檢查 Config 中選取的檔案。FINAL 只會處理前面的規則都未比對到的請求；如果已有 DOMAIN-SUFFIX 或 GEOIP 規則比對到該請求，修改 FINAL 不會改變其結果。重新建立連線後再查看記錄。

儲存時提示格式錯誤，該先檢查哪裡？

優先確認段落名稱是否包含完整方括號、Rule 是否使用半形逗號，以及 General 與 Host 是否使用等號。暫時移除本次新增的片段，確認舊內容可以儲存後，再逐行加回；不要一次混入多個來源的大段設定。

為什麼更新後手動撰寫的規則不見了？

先確認更新的是 Home 中的訂閱項目，還是 Config 中的遠端檔案。遠端檔案更新可能會取代檔案內容。請從保留的本機副本還原規則，再逐項合併需要的新內容，避免將連線項目更新誤當成規則備份。

有延遲，但網頁打不開，需要重寫整份檔案嗎？

不必立刻重寫。先撤銷這次新增的 Host 與 URL Rewrite，再檢查 DNS 解析、實際比對到的策略及目標連線結果。Connectivity Test 回傳延遲只涵蓋測試所用的連線路徑，不能取代實際瀏覽網頁；也可參考疑難手冊繼續排查。

一份可靠的修改紀錄至少應包含原始檔案名稱、修改欄位、測試網域、Global Routing 模式與實際結果。保留這五項，下次發生異常時就能直接復原並重現問題，而不是同時修改 DNS、規則與連線項目，最後無從判斷原因。如需補充概念，可查看術語手冊；遇到連線故障時，可依照連線問題排查繼續檢查。