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

Shadowrocket 設定檔 .conf 結構與各區段用途：[General]、[Rule]、[Host]、[URL Rewrite]

逐段解析 Shadowrocket .conf 設定檔：[General] 設定全域參數、[Rule] 決定流量路由、[Host] 設定本機對應、[URL Rewrite] 改寫請求網址，並附上範例與常見錯誤。

本文摘要

.conf 是設定文字檔，不是伺服器訂閱的另一種名稱。本文適合已有自己的訂閱，準備閱讀或修改 Config 的使用者；操作路徑以 iPhone / iPad 介面為例，Mac、Windows、Android、Linux 使用者可依各自版本確認設定入口。閱讀後即可辨別全域參數、分流規則、本機對應與請求改寫，並依序備份、修改單一項目、重新連線及檢查紀錄。

1. 先分清 Config、伺服器與 Global Routing

Shadowrocket（小火箭）的 Home 可查看及選取現有伺服器，Config 則用來管理設定檔。伺服器項目會儲存連線所需的位址、連接埠、協定與驗證資訊；本文介紹的四個區段則描述解析、分流及改寫行為。只匯入包含這四個區段的 .conf，不會憑空建立可用伺服器，也不能取代你已有的訂閱。

編輯前先查看 Home → Global Routing。Proxy、Direct、Config、Scene 並非四種伺服器協定，而是不同的路由模式。要驗證本文的 [Rule]，請先使用 Config；若目前使用 Proxy 或 Direct，就不能以全域連線的結果證明某條規則已經命中。

模式檢查重點與本文的關聯
Proxy全域代理路由不能據此判斷 [Rule] 的分流結果。
Direct全域直連路由此模式下，伺服器是否可用並非直接的驗證目標。
Config目前啟用的設定檔用來驗證本文的規則順序與策略。
Scene情境條件及其相關設定先確認情境實際採用的路由與設定，不要將它視為固定使用 Config。
備份設定選取檔案修改單一項目重新連線檢查紀錄

這個流程表示編輯與驗證的順序，並非網路處理管線。實際連線時，DNS 解析、網域比對與 IP 比對可能互相影響；[URL Rewrite] 也不是所有流量都必經的環節。Settings → On Demand 管理依條件連線的行為，同樣不能取代 Config 中的分流規則。

2. .conf 分段語法與安全編輯順序

區段名稱須單獨占一行，並以英文方括號括住。參數通常使用英文等號，規則欄位通常使用英文逗號；不要在語法中混用中文輸入法的逗號或括號。以下是結構範例，省略未使用的區段不代表設定檔損壞。範例僅說明文字排版，不含伺服器憑證資訊。

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302
  1. 進入 Config，保留目前可正常運作的檔案副本；若檔案來自遠端設定，也請記下原始網址與本機修改內容。
  2. 開啟待修改檔案的編輯入口，確認目前編輯的檔案就是準備啟用的檔案。不同平台的編輯按鈕位置可能不同。
  3. 每次只修改一類內容，例如只調整一條 DOMAIN-SUFFIX；不要同時更換 DNS、新增對應及修改改寫規則。
  4. 儲存後確認該檔案已啟用，返回 Home 檢查 Global Routing 是否為 Config，再重新建立連線並送出新的測試請求。

註解宜單獨占一行，例如以 # 開頭說明規則用途。除非已確認該位置支援行尾註解，否則不要將說明文字直接接在參數值後方。副檔名也應維持為 .conf，避免文字編輯器額外加上 .txt。

3. [General]：全域參數與 DNS 解析

[General] 用來設定適用於整份設定的全域參數。以下的 dns-server = system 表示使用系統 DNS 設定，並非設定一台名為 system 的伺服器。這不保證目前網路的解析結果一定可用；若連線失敗，需分辨是解析失敗、路由錯誤，還是目標服務沒有回應。

[General]
dns-server = system

不要看到別人的參數清單就整段照抄。IPv6、DNS 與略過設定會影響不同層面的行為；例如修改 DNS 無法修正錯誤的伺服器驗證資訊，停用某類位址解析也無法解釋所有逾時問題。先保留目前可正常運作的參數，再針對明確的現象逐項調整。

[General] 檢查項目

區段
[General]
參數
dns-server = system
驗證項目
新請求的網域解析結果與錯誤紀錄

先確認解析成功，再判斷連線路由。

[Rule] 檢查項目

區段
[Rule]
比對項目
DOMAIN-SUFFIX,example.com,PROXY
預設項目
FINAL,DIRECT

規則負責決定策略，不提供伺服器驗證資訊。

檢查時應建立新連線。已建立的長連線可能沿用原本的連線狀態，瀏覽器與系統也可能保留 DNS 快取。只重新整理一次頁面，既不能證明新的 DNS 設定已生效，也不能據此斷定儲存失敗。

4. [Rule]：由上往下比對，FINAL 放在最後

[Rule] 會依序比對；前面的規則命中後，後續規則通常不會再參與該連線的策略選擇。因此，較具體的例外規則應放在範圍較廣的規則之前。以下範例先讓某個精確網域直連，再讓相同網域後綴下的其他請求使用 PROXY。

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

PROXY 與 DIRECT 是策略關鍵字，不是協定名稱。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 描述的是伺服器連線方式，不能隨意填在規則結尾當作策略。若使用自訂策略名稱，必須確認它在設定中有對應定義，且拼字完全一致。

結論：先驗證精確網域，再擴大範圍

在副本中為自己管理的測試網域新增一條 DOMAIN 規則，放在 FINAL 前方；重新連線後檢查新請求的比對紀錄。確認結果正確後，再改用 DOMAIN-SUFFIX。這樣可分開排查「語法錯誤」與「比對範圍過廣」。

5. [Host]：網域對應不等於路由策略

[Host] 用來設定本機網域對應。左側填寫網域，右側填寫要使用的位址；不要連同瀏覽器網址列中的協定、連接埠與路徑一起貼上。對應會改變目標位址的解析結果，不會自動讓該連線改走 DIRECT，也不會替目標網站修復憑證。

[Host]
lab.example.com = 192.0.2.10
api.example.com = 192.0.2.20
寫法或現象問題處理方式
https://lab.example.com/path將 URL 當成網域鍵值。左側只保留 lab.example.com。
192.0.2.10:443在 IP 對應值中加上連接埠。對應欄只填位址；HTTPS 的 443 連接埠屬於連線目標資訊。
設定對應後出現憑證錯誤該位址上的服務不一定持有該網域的有效憑證。檢查伺服器憑證與網域，不要用忽略憑證錯誤的方式掩蓋對應問題。
連線仍經過代理位址對應並未指定 DIRECT。返回 [Rule]，確認該網域或目標位址命中的策略。

例如，將自己管理的測試網域指向內部伺服器後，還需確認目前網路或所選代理能否連到該位址。若服務只能從本機網路存取，應另外檢查相應的直連規則。對應正確、位址可達、連接埠開放及憑證有效是四項獨立條件，不能只驗證其中一項。

6. [URL Rewrite]：正規表示式比對與重新導向

[URL Rewrite] 用來處理請求網址，不是伺服器訂閱更新工具。以下規則只比對 example.com 的純文字 HTTP 網址，保留路徑後以 302 重新導向至 HTTPS 網址。它改變的是請求網址的處理方式，不是在 [Rule] 中選擇 PROXY 或 DIRECT。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302
  1. ^ 限定從網址開頭比對，$ 限定比對至結尾，降低意外涵蓋其他網址的機會。
  2. example\.com 中的句點已跳脫，代表字面上的句點；在正規表示式中，未跳脫的句點通常代表任意單一字元。
  3. (.*) 會擷取斜線後的內容，替換網址中的 $1 則引用這組內容。
  4. 302 是重新導向狀態碼，不是連接埠；不要將它改成伺服器使用的 443。

測試網址應指向自己管理的服務，例如檢查一個包含路徑與查詢參數的 HTTP 請求，觀察重新導向的 Location 是否保留預期內容。瀏覽器的 HTTPS 自動升級或 HSTS 可能讓請求根本未以 HTTP 送出，因此「瀏覽器最後開啟 HTTPS」不能單獨證明規則已生效。

常見錯誤包括比對範圍過廣、替換目標再次命中原規則，以及將規則寫入 [Rule] 區段。若發生反覆跳轉，先停用新增的改寫規則，還原原始請求，再縮小正規表示式範圍；不要同時新增多條重新導向規則來補救同一個循環。

7. 儲存後沒有生效：依檔案、模式與比對條件排查

排查時，先確認「目前使用哪個檔案」，再確認「請求是否符合測試條件」。伺服器訂閱更新與遠端設定更新並非同一回事：前者主要影響現有伺服器項目，後者則可能取代設定文字。若曾修改遠端設定的本機副本，更新前應先備份，避免將更新覆寫的結果誤認為編輯器未儲存。

已儲存規則，為什麼所有網站還是使用同一種策略？

先到 Config 確認剛儲存的檔案已啟用，再到 Home → Global Routing 選擇 Config。接著檢查 FINAL 是否放在最後，關閉舊的測試連線後送出新請求，並查看實際比對紀錄。

新增 [Host] 後，為什麼網頁還是無法開啟？

先逐字比對對應值與自己伺服器的實際位址，再確認目前網路能否連到目標位址及連接埠。若是 HTTPS 的 443 連接埠，也要檢查網站憑證；文中的 192.0.2.10 僅供語法示範，不能當作實際服務位址。

更新訂閱後，為什麼沒有出現新規則？

返回 Home 檢查伺服器清單，再到 Config 查看規則檔案。更新伺服器訂閱不等於更新設定檔；若要修改 [Rule]，應編輯目前啟用的設定檔，而不是將規則貼到伺服器位址欄位。

修改設定後，斷線又自動連上了？

前往 Settings → On Demand 檢查目前的條件。手動比對測試時，可先暫停相關的自動連線條件；驗證完成後再還原原設定。On Demand 控制連線觸發時機，不會替你調整 [Rule] 順序。

若仍無法找出原因，請還原備份設定，並維持相同伺服器、相同網路及相同測試目標。備份可用而修改版失敗時，再逐項加入差異；兩份都失敗時，應優先檢查伺服器連線與目標服務，而不是繼續擴大規則範圍。提供診斷資料給他人前，請移除訂閱網址中的權杖、驗證資訊及其他個人資料。

下載 Shadowrocket