2026-08-21 · 進階設定 · 約 10 分鐘

Shadowrocket .conf 設定檔怎麼看？General、Rule、Host、URL Rewrite 分段解析

解析 Shadowrocket .conf 設定檔結構：[General] 管理 DNS 與全域行為，[Rule] 設定分流規則，[Host] 設定本機映射，[URL Rewrite] 改寫請求，並附上範例片段供對照。

本文重點

本文適合已有連線設定，並需要檢查分流或維護 .conf 的使用者。請先區分 Home 中的連線項目與 Config 中的設定檔，再逐一檢查 General、Rule、Host 和 URL Rewrite。讀完後，你可以判斷某項設定屬於哪個段落、未如預期生效的原因，以及如何在保留原設定的前提下逐項驗證。

一、先區分 .conf、連線項目與目前的執行狀態

Shadowrocket（小火箭）的 .conf 用來組織設定行為，並不等同於連線帳號。Home 中的連線項目會儲存伺服器位址、連接埠及驗證等資訊；Config 中的檔案則負責 DNS、規則、本機映射與請求改寫等設定。只有一段 Rule，並不會自動取得可用的連線服務。

閱讀前，先確認目前使用哪個檔案，以及 Home → Global Routing 的選項。選擇 Config 後，才適合檢查本文所說的 Rule 分流；Proxy 與 Direct 是不同的全域處理模式，不能單憑它們的結果判定某條分流規則是否正確。Scene 用於依情境選擇設定；排查問題時，也要檢查相應情境的設定，不能把它視為另一份固定規則。

4 個段落
本文檢查 General、Rule、Host、URL Rewrite
3 個入口
Home 查看連線、Config 查看檔案、Settings 查看功能設定
1 項變更
每次只修改一項設定，再以相同請求重測

方括號用來標示段落，後續各行都屬於該段，直到出現下一個段落名稱。General 常見格式是鍵值對，Rule 則通常以逗號分隔欄位；不要混用這兩種格式。以下流程是人工排查的順序，並不代表所有網路請求都嚴格依照四個段落的書寫順序執行。

備份原始檔案 確認使用中的設定 修改單一設定 重新建立測試請求 檢查比對結果

二、General：先檢查 DNS，再看其他全域行為

[General] 中的鍵名決定全域選項的意義，不能只看等號右側的值。排查網域無法開啟時，可以先找出 dns-server，再區分是「網域解析失敗」還是「解析成功但連線失敗」。前者需要檢查解析路徑；後者也可能與路由、目標連接埠或既有連線項目的驗證設定有關。

[General]
dns-server = system

此處的 system 表示使用系統提供的 DNS 設定，不是名為 system 的伺服器位址，也不代表請求一定會直接連線。實際解析結果還會受到目前網路、快取及其他 DNS 相關選項影響。如果原始檔案還有其他 DNS 設定，請連同上下文一起閱讀，不要只憑這一行判斷整個解析過程。

  1. 在 Config 中開啟目前使用的檔案，記錄 dns-server 原值，並保留可還原的副本。
  2. 使用同一個測試網域重現問題，並記下目前使用 Wi-Fi 還是行動網路。
  3. 只調整一項 DNS 設定，儲存後確認仍在使用修改後的檔案，再重新建立請求。
  4. 若問題仍在，分別檢查是否取得目標 IP、是否符合預期的 Rule，以及是否成功建立目標連線。

三、Rule：依比對範圍排序，並將 FINAL 留在最後

[Rule] 負責將請求比對至策略。規則通常由上而下判斷，第一條符合條件的有效規則會決定處理方式，因此應將具體規則排在範圍較廣的規則之前。以下是閱讀用範例，其中 example.com 是示例網域，PROXY 需搭配使用者已有的有效連線設定，並非可直接使用的完整設定檔。

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

網域與網段比對

DOMAIN-SUFFIX
example.com,PROXY
IP-CIDR
192.168.0.0/16,DIRECT,no-resolve
no-resolve
不會為了這條 IP 規則主動觸發網域解析

先分清網域條件與 IP 條件，再判斷規則是否可能符合。

區域與預設比對

GEOIP
CN,DIRECT
FINAL
PROXY
Global Routing
測試本文規則時，請選擇 Config

區域判斷依據 IP 資料；FINAL 則處理前面規則都未符合的請求。

DOMAIN-SUFFIX,example.com,PROXY 可比對 example.com 及其子網域，例如 www.example.com，但不會以任意字串包含關係進行比對。若目標網域應採用特定策略，請將這條規則排在 GEOIP 等範圍較廣的判斷之前，避免請求先被其他規則處理。

IP-CIDR 依位址區段比對；範例中的 192.168.0.0/16 表示相應的私有位址範圍。no-resolve 僅影響該條規則的解析行為，不會關閉整個應用程式的 DNS。GEOIP,CN,DIRECT 則依目標 IP 的區域資料判斷，不能視為「所有中文網站都直接連線」。

結論：規則無效時，先檢查 FINAL 的位置

先將 FINAL 留在規則末尾，再確認目標規則排在它之前，並檢查 Global Routing 是否選為 Config。確認這三項後，再修改比對條件，避免將執行模式問題誤判為語法錯誤。

四、Host：改變名稱解析，不取代連線策略

[Host] 用於明確指定網域映射。它回答「這個名稱對應哪個位址」，Rule 則回答「這個請求採用什麼策略」，兩者不能互相取代。新增映射不會自動建立 DIRECT 規則，也不會自動提供伺服器程式、可用路由或有效憑證。

[Host]
demo.example.com = 192.0.2.10

此處的 192.0.2.10 是文件中的示例位址，不是可用的測試服務。實際操作時，只為自己有權管理或已明確得知位址的目標設定映射。不要為了讓網頁「看起來能開啟」而任意固定公用網站的 IP；位址變更或分散式部署都可能導致固定映射失效。

五、URL Rewrite：先限定比對範圍，再驗證重新導向

[URL Rewrite] 用來依模式比對請求 URL 並執行相應動作，不負責為網域指定 IP。以下以 HTTP 暫時重新導向說明「比對表示式、替換目標、動作」三個部分；這是語法閱讀範例，不需要將它加入日常使用的設定檔。

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

表示式開頭的 ^ 與結尾的 $ 限定完整比對範圍，\. 代表網域中的字面句點。此範例只會比對 http://example.com/old，不會自動涵蓋 HTTPS、其他子網域或帶有查詢參數的網址。結尾的 302 表示暫時重新導向；用戶端是否接續存取，取決於請求方的處理方式。

  1. 先寫下一個應符合條件的完整 URL，再寫一個不應符合的 URL，例如 http://example.com/older。
  2. 將規則限定在明確的網域與路徑，避免範圍過大的表示式影響登入、付款或 API 請求。
  3. 檢查替換目標是否再次符合原表示式；若符合，可能造成重新導向循環。
  4. 驗證時應查看重新導向狀態與目標網址，不要只看頁面最後是否顯示。

六、匯入與更新：區分連線來源和檔案來源

更新連線訂閱與更新 .conf 是兩回事。本文以使用者已有自己的服務商與訂閱為前提：訂閱可更新 Home 中的連線項目；設定檔則管理 Config 中的規則與其他行為。訂閱更新成功，不代表已換用新的 Rule；遠端設定更新也可能覆蓋先前直接在檔案中進行的本機修改。

  1. 匯入前：在 Home 記下目前選取的項目，在 Config 保留現有檔案的副本，並記錄 Home → Global Routing 的選項。
  2. 檢查內容：先確認文字內容確實包含 [General]、[Rule] 等設定段落，不要只依副檔名判斷。
  3. 使用檔案：在 Config 確認已選取並使用匯入後的檔案；若只儲存檔案而未切換目前使用的設定，測試時仍可能套用舊規則。
  4. 更新後：檢查自訂的 Rule、Host 與 URL Rewrite 是否仍保留，再對同一組目標重新發出請求。

自動連線行為也要另外檢查 Settings → On Demand。On Demand 決定特定條件下是否觸發連線，不會取代 Rule 的目標比對；如果手動中斷後連線又恢復，應先檢查觸發條件，而不是反覆刪除 FINAL。為了排除變因，可以先記下原設定，暫時停用按需觸發，再手動測試連線；完成後請還原設定。

分享設定檔前，應逐行檢查，而不只是檢查 Rule。訂閱網址中的 token、連線驗證資訊，以及憑證私鑰都不應出現在公開片段中。本網站不提供、不販售也不推薦節點或訂閱；文中的網域、位址與規則僅用於說明格式及排查方法。

七、常見問題：依症狀找出相關段落

為什麼修改 Rule 後，連線方式還是沒變？

先到 Config 確認目前使用的是剛修改的檔案，再到 Home → Global Routing 確認已選擇 Config。接著檢查是否有排在前面的規則已經符合條件，並關閉舊連線後重新發出請求；規則修改後，既有連線不一定會重新比對。

新增 Host 後，為什麼 HTTPS 反而出錯？

先檢查映射的 IP 是否正確，以及該伺服器是否提供原網域的 HTTPS 服務。Host 只會改變名稱映射，不會修改憑證。還原原本的映射並重新建立請求以供比較，不要以忽略憑證錯誤來取代原因排查。

遠端設定更新後，自訂規則去哪裡了？

先比較更新後的檔案與備份，確認本機修改是否遭遠端內容覆蓋。將需要維護的規則保存在獨立副本中，確認排序與策略後再使用；未備份前，不要反覆更新同一份手動修改過的遠端檔案。

只要複製四個段落，就能連線嗎？

不行。本文的範例沒有提供伺服器位址、帳號與驗證參數，也沒有建立可用服務。請先使用自己已有且有效的連線設定，再測試分流；若目標無法連線，應分別檢查 DNS、連線項目與規則，不能只靠增加段落來解決。

最終驗收時，應固定測試目標與網路條件：相同網域、相同請求路徑，以及相同的 Wi-Fi 或行動網路，每次只修改一項。能說明「使用哪份設定、符合哪條規則、解析到什麼位址、在哪個步驟連線失敗」，才有助於繼續排查；不要以反覆匯入整份檔案取代檢查。

App Store 正版核對