Shadowrocket .conf 設定檔結構：General、Rule、Host、URL Rewrite 各區段寫法

1. 先分清設定檔、伺服器與執行模式

.conf 是文字設定檔，區段名稱通常單獨占一行，後續項目都屬於該區段，直到出現下一個區段名稱。[General] 常見的是鍵值參數，[Rule] 則是一行一條比對規則。兩種語法不能互換：將 dns-server = system 放進 [Rule]，不會因此變成有效的網域規則。

Home 用來選擇伺服器、控制連線及查看 Global Routing；Config 用來管理與選擇設定檔；Settings 用於應用程式設定。伺服器項目說明「透過哪個出口連線」，設定檔則說明「哪些請求採用哪種策略」。伺服器訂閱更新成功，也不代表 Config 已選取預期的規則檔。

驗證 [Rule] 時，請在 Home → Global Routing 選擇 Config。Proxy、Direct 是全域執行模式，不能用來判斷某條設定規則是否命中；Scene 則依所選場景設定運作，排查時也要確認場景使用的設定。先固定選擇 Config，可減少執行模式變動造成的干擾。

2. [General]：先保留用途明確的全域參數

[General] 使用 鍵 = 值 格式。以下片段可放入測試設定檔：dns-server = system 使用系統提供的 DNS；bypass-system 與 skip-proxy 涉及略過系統及指定位址的行為，不應將它們視為提升連線速度的通用開關。

[General]
dns-server = system
bypass-system = true
skip-proxy = 127.0.0.1, 192.168.0.0/16

127.0.0.1 是迴路位址，192.168.0.0/16 是私有位址範圍。範例只列出這兩個範圍，不代表涵蓋所有本機網路。若區域網路實際使用其他網段，應先確認網路位址與存取目標；不要直接照抄範圍過大的略過設定，再試圖用後續規則補救。

不要在同一區段重複新增相同鍵值來表示「追加」。不同參數對重複項目的處理方式可能不同，整理時應保留一個明確的目標值。修改 DNS 前也應記錄舊值；網域解析失敗與代理交握失敗是兩種不同問題，更換伺服器不會自動修正錯誤的 DNS 設定。

3. [Rule]：具體規則在前，FINAL 放在最後

在 Config 模式下，規則會依排列順序檢查，由第一條符合的項目決定策略。以下範例依序展示精確網域、網域後綴、位址範圍、地區比對與預設規則。example.com 與 example.org 僅用於說明語法；規則中不含任何伺服器位址或訂閱憑證。

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

• DOMAIN 精確比對指定網域，因此此處的 blocked.example.com 會先符合 REJECT，而不是後面的後綴規則。
• DOMAIN-SUFFIX,example.com,PROXY 比對該網域及其子網域，不會依網頁 URL 路徑比對。
• IP-CIDR 依目標 IP 所屬的位址範圍判斷。附加的 no-resolve 表示不為這條 IP 規則主動觸發網域解析，並不代表整個請求完全不需要 DNS。
• GEOIP,CN,DIRECT 依目標 IP 的地區資料判斷，不依網域後綴或營運主體判斷。
• FINAL,PROXY 處理前面都未符合的請求，應保留在規則末尾。

PROXY、DIRECT、REJECT 是策略關鍵字，不是三種協定。PROXY 仍須有可用的代理出口；DIRECT 直接連線至目標；REJECT 拒絕符合條件的請求。若自己的設定使用命名策略群組，應確認規則引用的群組名稱確實存在，不要將範例中的 PROXY 隨意改成未定義的名稱。

4. [Host]：只建立網域與位址的對應

[Host] 常見寫法為 網域 = IP 位址，左側不是完整 URL，右側也不填入路徑或連接埠。以下使用保留測試網域與文件範例位址說明格式，可複製到隔離的測試設定檔中查看，但這些位址不代表可連線的實際服務。

[Host]
portal.example.test = 192.0.2.10
api.example.test = 192.0.2.20

Host 對應會改變位址解析結果，不會自動將請求改為 DIRECT。若要讓自己的測試網域直連，應另外在 [Rule] 的適當位置新增對應策略。即使對應正確，HTTPS 連線仍需要憑證與請求網域相符；Host 項目本身無法解決憑證名稱不符的問題。

1. 先確認服務實際監聽的位址與連接埠，例如自己的測試服務是否監聽 443。
2. Host 左側只填網域，不要填 https://，也不要填 :443。
3. 在 Rule 中確認此網域採用的策略，避免只檢查解析結果。
4. 若目標位址已變更，請更新或移除舊的對應，再重新送出請求；既有連線與應用程式快取可能會影響立即重測的結果。

遠端代理也可能參與目標網域解析，實際情況取決於對外連線方式與連線處理。因此，排查時應同時查看請求目標、所選策略與實際連線結果，不能只憑本機的一次 DNS 查詢，就認定整條連線路徑使用了同一個位址。

5. [URL Rewrite]：分清表達式、目標與動作

[URL Rewrite] 處理的是 URL，而不是選擇代理出口。以下範例會將示例網域的 HTTP 請求重新導向至 HTTPS：比對表達式、目標位址與 302 動作之間以空格分隔；$1 引用表達式中的第一個擷取群組，保留主機名稱後的內容。

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

例如輸入 http://example.com/docs?a=1，規則目標為 https://example.com/docs?a=1。反斜線會將網域中的句點視為字面字元，開頭的 ^ 則限定比對起點。使用 302 表示回傳重新導向，後續 HTTPS 請求仍須經過連線與分流處理。

• 先以單一且明確的網域進行測試，不要直接撰寫涵蓋所有網站的寬泛表達式。
• 此範例只比對 HTTP，目標則是 HTTPS，因此目標不會再次符合同一條規則。
• 若改寫涉及路徑，請逐項核對斜線、擷取群組與查詢參數，避免目標位址組合錯誤。
• 既有的 HTTPS 請求不會因新增這條規則就暴露完整路徑；處理加密請求內容涉及其他條件，本文範例不需要設定 MITM。

不要為了網域分流而新增 URL Rewrite。若只想讓 example.com 使用 PROXY，請回到 [Rule] 撰寫 DOMAIN-SUFFIX；若只想固定自己的測試網域解析位址，請使用 [Host]。各區段職責越單純，發生問題時越容易還原。

6. 儲存、啟用與驗證：每次只修改一個區段

編輯前，先在 Config 保留目前可用設定的副本，並記下 Home 中選取的伺服器與 Global Routing。伺服器訂閱與遠端 .conf 設定檔是兩種不同的更新對象：前者通常更新伺服器項目，後者則更新設定檔內容。若直接編輯遠端設定檔所對應的內容，後續更新可能會覆蓋本機修改，因此應先建立獨立的本機副本進行測試。

1. 建立基準：在 Home 選擇現有且可用的伺服器，開啟連線，再使用 Connectivity Test 檢查基本連線。此測試無法取代對特定網站或規則的驗證。
2. 編輯副本：在 Config 開啟準備測試的設定檔，找到對應區段，只修改一個參數或一條規則，儲存後返回設定檔列表。
3. 確認啟用：在 Config 選取該檔案，再前往 Home → Global Routing 選擇 Config；必要時重新連線，讓新設定套用於本次驗證。
4. 重現請求：使用相同網域、協定與路徑送出新請求。修改 Host 或 URL Rewrite 後，尤其不要依據舊頁面的快取內容判斷結果。
5. 比對結果：查看連線記錄中的目標與策略；若結果不符，先還原這一項修改，再比較修改前後的差異。

例如，測試 DOMAIN-SUFFIX 時固定存取同一個子網域；測試 Host 時固定目標服務與連接埠；測試 URL Rewrite 時明確輸入 http://，不要使用瀏覽器自動補成 HTTPS 的網址。分別記錄「請求根本沒有送出」、「請求符合錯誤策略」與「出口連線失敗」，比同時更換 DNS、規則與伺服器更有助於診斷。

7. 常見問題：設定看似正確，卻沒有生效

完整語法請參閱規則手冊。實際設定中應保留用途明確的參數，並分開管理網域分流、位址對應與 URL 改寫；每次修改都記錄目標、預期策略與回復用的檔案，方便日後更新時檢查。