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

1. .conf 檔案結構：區段名稱決定每一行的解讀方式

Shadowrocket（小火箭）的 .conf 是文字設定檔。方括號中的名稱是設定區段標題，例如 [General]。標題之後的內容都屬於該區段，直到下一個區段標題出現為止。同一行文字放在不同區段中，含義不會自動相同；編輯前請先確認所在位置。

[General] 主要放置全域參數，[Rule] 定義流量比對條件與策略，[Host] 提供本機網域對應，[URL Rewrite] 定義 URL 改寫。這四個區段並不是依序執行的四條分流規則。尤其不要將它們在檔案中的排列順序，視為單次網路請求必定經過的處理順序。

以下範例用於說明檔案結構。example.com 是示例網域；192.0.2.10 是文件專用示例位址，並非實際服務位址。請勿將這些內容直接取代正在使用的設定。以 # 開頭的獨立註解行僅供說明，不會參與規則比對。

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

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

複製設定時請使用半形方括號、逗號與等號。不要將中文說明直接接在規則行末。若要保留可供核對的修改紀錄，可在目標行前新增獨立註解，說明修改目的，而不是一次重新排列所有區段。

2. General：全域參數與 DNS 設定

[General] 常以 鍵 = 值 的格式設定參數。範例中的 dns-server = system 表示使用系統提供的 DNS 伺服器。這不是分流規則，也不表示所有請求都會使用 DIRECT。網域如何取得位址，以及連線最後採用哪種策略，是需要分開檢查的項目。

DNS 查詢通常會使用 53 埠，但不能只憑記錄中的某個埠號判斷整個解析流程。加密 DNS 與一般 DNS 的傳輸方式不同；若原設定已包含明確的 DNS 參數，請先記下原值，再依需求修改。不要只為了排查單一網域，就一次替換所有解析參數。

檔案中的參數與 Settings 裡的開關也不是同一種設定方式。例如 Settings → On Demand 用來處理連線觸發條件，不會將特定網域改為 DIRECT。排查期間請記下 On Demand 原本的狀態，避免手動中斷後又觸發連線，卻誤以為先前的設定修改沒有儲存。

3. Rule：比對對象、順序與 FINAL

[Rule] 中的規則會依序檢查，符合後便採用該規則指定的策略。因此，精確的例外規則通常要放在範圍較廣的比對條件之前。若將例外規則加在 FINAL 後面，不能期待它取代前面的預設結果。

DIRECT 表示直連，PROXY 表示使用代理策略，REJECT 表示拒絕。PROXY 本身不包含伺服器位址、認證資料或連線服務。本文假設使用者已持有自己的服務商與訂閱；使用範例前，仍須確認 Home 中已有可用的連線項目。

no-resolve 可避免僅為符合這條 IP 規則而主動進行網域解析。它不代表停用所有 DNS，也不會讓網域自動取得位址。GEOIP 依據的是 IP 資料庫，不是網頁語言、網域後綴或使用者所在地。

Global Routing 中的 Proxy、Direct、Config、Scene 是不同的路由模式。Config 會依設定規則進行分流；使用 Scene 時，還須確認對應場景的設定。記下目前的模式，是重現規則問題時不可少的步驟。

4. Host：本機網域對應不等於分流策略

[Host] 可透過 網域 = IP 位址 建立本機對應。例如下方這一行會將 lab.example.com 對應至文件中的示例位址。這只處理網域與位址的對應，不會同時指定該請求使用 DIRECT 或 PROXY。

[Host]
lab.example.com = 192.0.2.10

• 左側填寫網域，不要填入 https://、路徑或查詢參數。
• 右側的位址必須來自使用者自行管理或獲准使用的環境；示例位址不能用於實際連線測試。
• 這一行不會設定服務埠號。HTTPS 預設使用 443 埠，其他埠號應由請求 URL 或應用程式的連線設定指定。
• 使用 HTTPS 時，仍會驗證網域與憑證。將網域對應至另一個 IP，不會讓憑證自動符合。

修改 Host 後若仍連到舊位址，請先關閉原本的網頁，再發出新請求。瀏覽器快取、應用程式快取與既有連線都可能影響觀察結果。請在請求記錄中核對目標網域與位址，不要只憑頁面是否改變來判斷。

部分應用程式會使用自己的解析方式，或直接連線至預設 IP，因此不一定會如預期套用這項對應。此時應先確認應用程式實際請求的是網域還是 IP。尚未確認解析問題前，不要一味新增涵蓋範圍更廣的 Rule 來補救。

5. URL Rewrite：依 URL 模式改寫，而非依網域分流

[URL Rewrite] 與 [Rule] 的欄位結構不同。以下範例包含比對運算式、目標 URL 與 302，代表 HTTP 重新導向：符合指定舊網址時，讓用戶端轉往新網址。這不是 PROXY 策略，也不能用來設定伺服器連線參數。

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

1. ^ 用來限定字串開頭，避免同時符合其他位置含有相似文字的 URL。
2. \. 表示網域中的句點字元；正規表示式中的句點若未跳脫，則代表較廣泛的比對範圍。
3. /old$ 限定路徑與字串結尾，因此含有額外查詢參數的 URL 不會符合這個精確運算式。
4. https://example.com/new 是重新導向目標；後續存取仍須正常解析、分流並建立連線。
5. 302 表示暫時重新導向。測試時請檢查整個重新導向鏈，不要只看網址列最後顯示的內容。

本例刻意比對明文 HTTP URL。HTTPS 的路徑與查詢參數位於加密請求中，不能直接將此範例視為可改寫任意 HTTPS 頁面。若要讀取 HTTPS 請求內容並進行改寫，還需要符合額外的 MITM 條件並完成信任設定，單靠新增一行 URL Rewrite 無法達成。本文不將啟用這些條件列為入門編輯步驟。

為避免重新導向循環，目標 URL 不應再次符合同一條規則。第一次測試請選擇單一且可控的網址，保留精確的比對範圍；確認結果後，再評估是否需要擴大範圍。不要一開始就使用比對所有網域的正規表示式。

6. 在 Config 頁面匯入與編輯：每次只驗證一項變更

Home 主要用於連線與路由模式，Config 用於管理設定檔，Settings 則用於應用程式設定。已有連線項目或訂閱，不代表已選取某個 .conf；匯入檔案也不等於已將它設為目前使用的設定。編輯完成後，請回到 Config 確認選取狀態。

1. 保留原始檔。編輯前先儲存目前可用的設定副本，並記下檔名、Global Routing 模式，以及這次要修改的具體行。
2. 準備匯入內容。匯入自己持有的 .conf 檔案，或使用自己信任的設定 URL。遠端文字可能變更 DNS、分流與改寫行為，匯入前請先閱讀內容。
3. 開啟 Config。透過新增入口選擇要匯入的檔案或 URL。匯入後確認檔名，並檢查內容是否包含預期的區段標題。
4. 進入編輯模式。透過該設定檔的操作入口開啟文字編輯，一次修改一個參數或一條規則，然後儲存。編輯入口的實際呈現方式以目前介面為準。
5. 確認已選取。在 Config 中選取儲存後的檔案，再前往 Home → Global Routing 確認模式為 Config。測試前，視需要重新建立連線。
6. 重現請求。重新存取同一個目標，檢查請求記錄中的符合規則、策略與目標位址。若失敗，先還原剛修改的項目，再重新測試。

遠端設定更新與連線項目的訂閱更新是兩種不同操作。前者可能取代 .conf 的內容；後者主要更新既有訂閱中的連線項目。若將個人修改直接寫入會被遠端更新覆蓋的檔案，下次更新時可能會遺失。請保留獨立副本，並在更新前後比較重要區段。

判斷設定是否生效，必須一併確認「已儲存的檔案」、「目前選取的檔案」、「Global Routing 模式」與「重新發出的請求」。只看到儲存成功，無法證明請求已依新規則處理。

7. 編輯設定檔常見問題