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

一、先分清 .conf、訂閱與目前連線

.conf 是文字設定檔，方括號中的名稱代表設定段。每個設定段都有自己的語法：[General] 常用鍵值對，[Rule] 使用逗號分隔規則，[Host] 儲存名稱對應，[URL Rewrite] 使用比對運算式、目標位址與動作。不可直接將某一段的寫法複製到另一段。

在 Home 匯入訂閱，主要是取得可用的連線項目；在 Config 選用設定檔，則是決定流量的處理方式。兩者彼此相關，但不是同一項操作。若已有自己的服務商與訂閱，請向服務商取得訂閱連結，並確認連結提供的是連線資訊還是完整設定檔。不要只憑副檔名判斷內容。

要測試 [Rule] 的分流行為，請在 Home → Global Routing 選擇 Config。Proxy 與 Direct 並非驗證該設定段規則的相同環境；Scene 還需檢查目前場景採用的設定。只儲存檔案而未確認目前模式，常會讓人誤以為「規則完全沒有變化」。

二、General：先看全域參數，再檢查 DNS

[General] 管理全域行為，包括 DNS 等設定。閱讀這一段時，先辨識等號左側的鍵，再查看右側的值。欄位名稱、英文標點與布林值都應維持原樣；不要把中文說明寫進值中，也不要以全形逗號取代半形逗號。

[General]
dns-server = system

這裡的 dns-server = system 表示使用系統 DNS。這不代表每條連線都直接連出，也不等於替所有請求指定代理。DNS 處理的是「如何解析名稱」，Rule 處理的是「連線採用哪種策略」；實際解析位置也可能受規則選項、代理協定與其他 DNS 設定影響。

若遇到「連線項目可用，但網域無法開啟」，先查看記錄，判斷是解析失敗，還是取得 IP 後連線失敗。前者應優先檢查 DNS；後者還要檢查命中的策略、目標連接埠與伺服器狀態。HTTPS 常用連接埠為 443，但服務商連線使用的連接埠不一定是 443，兩者不可混為一談。

三、Rule：依序比對，FINAL 放在最後

[Rule] 中的規則會由上而下依序比對，命中後便採用相應策略，不會為了尋找「更精確」的條件而繼續往下比對。因此例外規則應放在較寬泛的規則之前；FINAL 負責處理其餘流量，應放在最後。

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

此處的網域與 192.0.2.0/24 都是說明用範例，不代表任何線路資源。第一條規則拒絕指定主機；第二條規則讓 example.com 及其子網域直接連線。由於精確的拒絕規則在前，存取 blocked.example.com 時不會被後面的網域後綴規則放行。

四、Host：變更名稱解析，不改變 URL

[Host] 用於設定本機名稱對應。以下範例將 lab.example.com 對應至文件專用位址 192.0.2.10。此位址不是可連線的測試服務；使用時應替換為自己有權管理且確實可連線的目標位址。

[Host]
lab.example.com = 192.0.2.10

• 不填通訊協定與路徑：左側是主機名稱，不是 https://lab.example.com/path。
• 不要把連接埠當成 IP：右側的 IP 對應不會將目標連接埠改成其他連接埠。
• 不能取代 Rule：套用名稱對應後，連線仍須依照目前的路由與策略處理。
• 不會略過憑證檢查：透過 HTTPS 存取時，仍會檢查原始請求主機名稱對應的憑證。

若將網域指向某台伺服器後出現憑證錯誤，不能只因 IP 可連線就認定 Host 設定正確。該伺服器還必須正確處理原主機名稱與 TLS。若應用程式自行解析名稱或採用特定連線方式，也不要假設所有請求都會受到相同的本機對應影響；應以實際連線記錄為準。

五、URL Rewrite：比對請求網址並執行指定動作

[URL Rewrite] 處理 URL 比對與改寫，不是「將網域交給哪個連線」的分流表。以下透過 HTTP 轉向 HTTPS 的範例，說明其三個部分：正規表示式、目標位址與動作碼。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

^ 和 $ 分別限制比對的起點與終點，\. 表示字面上的句點，(.*) 擷取後續內容，目標中的 $1 則引用第一組擷取結果。302 代表轉向動作；不要將此處的動作碼誤寫成 Rule 的 PROXY。

排查時先確認原始請求確實是 HTTP，再檢查是否有舊的轉向快取。若瀏覽器因 HSTS 直接使用 HTTPS，HTTP 規則可能根本沒有比對機會。調整 Rule 順序無法解決此情況，因為兩個設定段處理的對象不同。若無法確認改寫行為，應先停用該規則並還原原始存取路徑。

六、編輯後如何套用：儲存、選用並重新建立連線

設定檔出現在 Config 清單中，不代表已經選用；文字儲存成功，也不代表既有的長連線會重新建立。建議先複製目前可正常運作的設定檔作為本機備份，再依照以下方式逐一驗證變更。不同平台的選單呈現可能不同，以下依 Home、Config、Settings 各頁面的用途說明。

1. 確認檔案：在 Config 找到目前選用的檔案，記下名稱，再開啟編輯入口。請勿誤改其他尚未選用的檔案。
2. 一次只修改一處：先修改一條規則或一組鍵值，保留原有設定段名稱與英文標點。檢查是否有重複的 FINAL，或規則是否放錯設定段。
3. 儲存並選用：儲存編輯內容，返回 Config 確認該檔案仍是目前使用的設定檔。若出現語法提示，請先修正，不要繼續將它當成有效設定檔測試。
4. 確認模式：返回 Home → Global Routing，選擇 Config，並確認目前的連線項目可用。
5. 建立新連線：若可接受短暫斷線，請重新連線，再讓測試應用程式重新送出請求。必要時關閉舊頁面或重新啟動測試應用程式，以避免重複使用既有連線。
6. 確認結果：以相同目標重複送出請求，查看命中的規則、策略與錯誤類型。不要只憑「網頁好像變快了」判斷設定是否生效。

遠端設定檔與本機編輯應分開管理。重新下載遠端檔案可能會覆蓋本機修改；更新 Home 中的連線訂閱，也不等於更新 Config 中的規則。若要長期維護自訂規則，請另存副本，並記錄每次修改的欄位與預期結果。訂閱更新後，也要確認設定檔引用的策略名稱仍然存在。

七、常見問題：依據現象找出設定段

維護 .conf 的關鍵在於分清各段職責：General 決定全域參數，Rule 決定策略，Host 提供名稱對應，URL Rewrite 處理符合條件的請求網址。每次只修改一個環節，並保留可還原的副本，才能將設定變更與連線結果對照。