Shadowrocket .conf 設定檔結構解析：General、Rule、Host、URL Rewrite 的功能

1. .conf 的段落結構與生效條件

Shadowrocket（小火箭）的 .conf 是依段落編排的文字設定檔。方括號中的名稱是段落標記，例如 [General]；標記後到下一個段落之前的內容，都屬於該段。各段使用不同語法：General 通常採鍵值格式，Rule 是以逗號分隔的規則，Host 是名稱與位址的對應，URL Rewrite 則包含比對運算式、替換目標與動作。

Home 用來選擇連線項目並查看連線狀態，Config 用來管理規則設定檔，Settings 則提供用戶端設定。匯入服務訂閱不代表已啟用某個 .conf；同樣地，選取 .conf 也不會自動取得可用的連線服務。本文只說明設定檔結構，不涉及服務來源。

若要驗證 Rule 的分流結果，請先在 Home 確認 Global Routing 設為 Config。Proxy 與 Direct 是不同的全域路由模式，不能用來證明某條 Config 規則是否命中；使用 Scene 時，也要確認該場景實際選用的路由設定。以下流程是排查順序，不代表四個段落在內部嚴格依序執行。

2. General：全域參數不是分流規則

[General] 用來存放全域參數，例如 DNS 相關設定。常見格式為 參數名稱 = 參數值，不能直接在其中使用 Rule 的逗號分隔語法。以下僅示範使用系統 DNS 的寫法，用來說明鍵值結構，並非要求所有網路環境採用相同的 DNS 方案。

[General]
dns-server = system

dns-server 會影響用戶端的 DNS 處理方式，但不代表指定所有請求都經由某個出口連線。DNS 解析回答「名稱對應哪個位址」，Rule 則決定「請求採用哪種策略」；兩者相關，卻不是同一個開關。應用程式快取、加密 DNS，以及連線是否帶有網域資訊，都可能影響觀察結果；不能只憑網頁能開啟，就判定 DNS 設定已如預期生效。

• 先記下目前 dns-server 的完整值，再進行修改；不要在同一輪同時變更 DNS、規則與連線項目。
• 複製鍵名時保留英文拼法與半形符號，避免將 = 換成全形字元。
• 同一個鍵只保留一筆明確設定，不要依賴重複鍵的覆寫順序來管理設定。
• 不熟悉的參數先維持原樣；其他設定格式中的同名參數，不一定能直接套用。

如果修改後出現大量網域解析失敗，請優先還原剛才變更的 General 參數，再使用相同網路與相同連線項目重新測試。此時擴大 Rule 的比對範圍通常無法修正 DNS 本身的問題，反而會增加排查變因。

3. Rule：首個命中項目決定策略，FINAL 放在末尾

[Rule] 中的規則會由上而下依序檢查。常見格式為 類型,比對條件,策略；FINAL 不需要比對條件，用來處理尚未命中的請求。具體規則應放在較寬泛的規則之前，兜底規則則放在末尾。

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

本例中的 example.com 與 192.0.2.0/24 是文件範例值。第一行會讓該網域及其子網域使用 PROXY；第二行會讓符合範例位址範圍的請求使用 DIRECT。no-resolve 表示不為這條 IP 規則主動觸發網域解析，而不是關閉整個用戶端的 DNS。

DOMAIN-SUFFIX,example.com,PROXY 不會比對 notexample.com，也不是只要包含任意字串就算命中。GEOIP,CN,DIRECT 則依據目標 IP 與資料庫分類，不會按照網頁語言、網域後綴或服務商註冊地判斷。如果請求已先命中上方的網域規則，下方的 GEOIP 就不會再改變該請求的策略。

4. Host：名稱對應不等於代理或重新導向

[Host] 用於本機名稱對應。以下將範例網域對應至文件保留位址，僅用來示範語法。該位址不供實際業務連線使用，不能把此範例當作網路可用性測試目標。

[Host]
lab.example.com = 192.0.2.10

Host 改變的是名稱所對應的位址，不是網址列中的 URL，也不會自動將請求改為 DIRECT。請求採用何種策略，仍須依據目前的路由模式、Rule，以及可用的網域或位址資訊判斷。若同時存在網域規則與位址規則，應透過新請求的記錄確認結果，而非假設完成對應後一定只會依 IP 分流。

• 該行不會指定連接埠：存取 https://lab.example.com/ 時預設使用 443；存取 http://lab.example.com/ 時預設使用 80。Host 對應不會將 443 改成其他連接埠。
• 憑證仍須符合名稱：HTTPS 連線仍會驗證憑證中的網域。將名稱指向另一台伺服器，不會讓不相符的憑證自動生效。
• 快取可能影響驗證：既有連線或應用程式內部快取可能持續使用舊結果。儲存後應關閉舊頁面的連線，再發出新請求。
• 並非所有解析都會經過此對應：應用程式自行解析或直接使用 IP 時，可能無法觀察到預期的 Host 效果。

因此，建議先在自己管理的測試網域上驗證 Host，再決定是否保留。若只需要調整出口策略，應修改 Rule；若要將某個網頁位址換成另一個位址，則應檢查 URL Rewrite，而不是一再新增 Host 項目。

5. URL Rewrite：先比對 URL，再執行指定動作

[URL Rewrite] 處理的是可見且符合條件的 URL。以下是將 HTTP 重新導向至 HTTPS 的 302 範例：第一部分是正規表示式，第二部分是替換位址，最後的 302 則是動作。此處刻意使用未加密的 HTTP 作為輸入，以便區分 URL 比對與 HTTPS 加密內容的界線。

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

1. ^ 限定從 URL 開頭開始比對，避免只有相同文字出現在中間時也觸發規則。
2. example\.com 中的反斜線會讓句點表示字面上的句點；未跳脫的 . 在正規表示式中代表更廣泛的含義。
3. (.*) 會擷取網域後斜線之後的內容，$1 則在替換目標中引用第一組擷取結果。
4. 302 表示回傳重新導向；應用程式是否跟隨跳轉，仍取決於其本身的 HTTP 行為。

例如輸入 http://example.com/docs?a=1，依照這條規則組成的目標會是 https://example.com/docs?a=1。這不代表目標網站一定提供對應頁面，也不保證重新導向後的 HTTPS 連線能成功。規則只會改變請求的處理方式；伺服器憑證、路徑與存取權限仍須各自符合要求。

URL Rewrite 也不是按網域分流的替代方式。若要讓整個網域採用某種策略，優先使用 Rule；若要阻止某類請求，應先釐清要在網域層級封鎖，還是在 URL 層級處理，避免將不同層級的語法混用在同一段中。

6. 修改後如何生效：儲存、選取並以新連線驗證

「檔案已成功儲存」和「目前正在使用這個檔案」是兩回事。尤其 Config 中保留多個本機檔案或遠端設定時，編輯副本後可能仍在使用舊設定。遠端設定後續更新也可能覆寫本機修改，因此應先建立容易辨識的本機備份，再進行測試。

1. 記錄基準狀態：記下 Home 目前選取的連線項目、Global Routing 模式，以及 Config 目前選取的檔案。
2. 備份後逐項編輯：在 Config 保留原始檔案副本，每次只修改一個段落中的一項；先在規則行前加上 # 註解以停用測試內容，不要直接刪除整個段落。
3. 儲存並確認啟用項目：返回 Config，確認選取的是修改後的檔案，而不只是開啟過它的編輯頁面。
4. 使用 Config 驗證：返回 Home，確認 Global Routing 設為 Config，並確認所選連線項目本身可用。
5. 建立新連線：關閉舊頁面或舊工作階段後再存取；必要時手動中斷並重新連線，避免測試受到既有連線影響。
6. 記錄結果並還原：確認目標網域、目標位址、命中規則與實際策略。若結果異常，還原剛才修改的項目，再以相同方式重新測試。

也要區分兩種「更新」：Home 中服務訂閱的更新主要會變更連線項目；Config 中遠端設定的更新則可能變更 General、Rule 等文字內容。不要把兩者都稱為「重新整理設定」，就認定效果相同。更新前先確認操作對象，更新後檢查實際內容與選取狀態。

Settings → On Demand 管理的是自動連線條件，不是 Rule 的比對條件。若手動中斷後又自動連線，應先檢查 On Demand 與系統 VPN 設定，不能因此推斷 .conf 未儲存；反過來說，自動連線成功也無法證明新規則已命中。

7. 常見問題：檔案可以匯入，為什麼結果仍不如預期？

判斷 .conf 是否正確，不能只看檔案能否匯入。段落名稱與欄位決定語法是否可讀，目前選取項目與路由模式決定設定是否參與處理，而新請求的實際記錄才能用來驗證行為。依照這個順序檢查，通常能區分「設定寫錯」、「沒有啟用」和「請求不符合條件」。