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

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

.conf 是設定文字檔，方括號標題用來標示段落，標題下方的內容屬於該段。[General] 主要使用鍵值組，[Rule] 則使用以逗號分隔的規則列；不能將同一種格式套用到所有段落。以 # 開頭的獨立行可作為註解，建議將說明另寫一行，避免註解混入參數值。

Home 主要用來連線、選擇伺服器及查看 Global Routing；Config 用來管理和選擇設定檔；Settings 則是應用程式設定。現有訂閱通常用來更新伺服器清單，伺服器項目已更新，不代表目前的規則檔也已替換。設定檔也可能引用遠端資源，檢查時需進一步確認更新來源。

在 Config 編輯前，先保留原始檔案副本，並記下 Home 目前選取的伺服器及 Global Routing 狀態。檔案成功儲存，不代表已選取使用；選取設定檔，也不代表所有流量一定會依照其中的分流規則處理。排查時應分別確認「檔案內容」、「目前設定檔」與「路由模式」。

[General]：全域參數使用鍵值組

[General] 用來設定會影響整份設定檔行為的參數。以下範例以使用系統 DNS、停用 IPv6 及讓系統流量繞過為例，展示 鍵 = 值 格式。這只是語法示範，並非適用於所有網路的參數組合。

[General]
# 使用系統提供的 DNS
dns-server = system

# 是否啟用 IPv6
ipv6 = false

# 允許系統相關流量繞過
bypass-system = true

• dns-server = system：使用系統提供的 DNS。切換 Wi-Fi 後，系統可用的解析環境可能改變，因此不能據此認定兩個網路的解析結果必然一致。
• ipv6 = false：控制此設定檔的 IPv6 行為，不代表關閉路由器或整部裝置的 IPv6。若連線依賴 IPv6，應先確認伺服器位址和目前網路，再決定是否修改。
• bypass-system = true：涉及系統流量的繞過處理，並非替特定網站指定 DIRECT 的規則；網站分流仍應在 [Rule] 檢查。

同一個鍵不要重複設定多個互相衝突的值。合併兩份設定檔時，先比對現有鍵值，再決定要保留哪一個，不要直接追加整段。DNS 相關故障也要分清「伺服器網域無法解析」和「目標網站網域無法解析」：兩者影響不同的連線環節。

[Rule]：逐行比對，具體條件放前面

[Rule] 決定請求要符合哪個目標策略。常見格式為 規則類型,比對值,策略；FINAL 不需要比對值，直接填入目標策略。規則會依序檢查，請求一旦符合前面的規則，就不會再由後續較寬泛的條件重新分配。

[Rule]
# 比對 example.com 及其子網域
DOMAIN-SUFFIX,example.com,PROXY

# 文件範例用網段，並非實際服務位址
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve

# 依目標 IP 的地區資料庫結果比對
GEOIP,CN,DIRECT

# 未符合前述規則時使用
FINAL,PROXY

PROXY 代表代理策略，仍需要有可用的代理出口；DIRECT 代表直接連線。若使用自訂策略群組，規則末尾必須引用實際存在的名稱，並確認拼字、空格與大小寫。將不存在的群組名稱寫入規則，不會自動建立對應出口。

若要驗證此段，請在 Home → Global Routing 選取 Config，並確認 Config 使用的是剛編輯的檔案。Proxy 是全域代理模式，Direct 是全域直連模式；Scene 會依已設定的場景處理，不能簡單視為 Config 的另一種名稱。若要逐條驗證規則，應先排除全域模式或場景切換造成的干擾。

[Host]：修改網域對應，不等於修改出口

[Host] 用來指定網域對應的位址。以下範例將完整主機名稱對應至文件保留位址，格式為 主機名稱 = IP 位址。此位址並未部署網站，複製後請求失敗是預期結果，不能用來判斷實際伺服器是否可用。

[Host]
# 僅說明格式
portal.example.com = 192.0.2.10
api.example.com = 198.51.100.20

Host 對應不是 HTTP 重新導向，也不是 DOMAIN-SUFFIX 規則。瀏覽器網址列仍會保留原網域，HTTPS 憑證也必須與請求網域相符。若將網域指向未提供該網域憑證的伺服器，即使網路連線成功，也可能出現憑證錯誤；不要以忽略憑證錯誤的方式掩蓋對應問題。

驗證時，使用完整主機名稱發起新請求；現有連線可能繼續沿用舊連線，不能只看網頁是否仍能開啟。若移除對應後恢復正常，請先確認目標位址、服務監聽狀態及憑證，不要繼續新增更寬泛的直連規則。遠端代理是否會再次解析網域也與連線方式有關，不要將本機對應視為能強制控制所有遠端解析。

[URL Rewrite]：符合 URL 後執行改寫動作

[URL Rewrite] 用來比對 URL 並執行動作，不使用 [Rule] 的逗號格式。以下範例將 HTTP 網址暫時重新導向至 HTTPS，動作中的 302 是重新導向狀態碼，不是伺服器連接埠。

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

1. ^ 表示從 URL 開頭開始比對，避免比對範圍意外落在網址中段。
2. example\.com 中的反斜線會讓句點代表一般字元，而不是正規表示式中的任意字元。
3. (.*) 會擷取網域後方的內容，目標中的 $1 則引用這部分內容。
4. url 302 指定 URL 重新導向動作；改寫後產生的新請求仍須正常解析、分流並建立連線。

改寫無法補足伺服器本身不具備的功能。目標網站必須實際支援 HTTPS，且憑證有效。若目標網址再次跳回原網址，可能形成重新導向迴圈。測試時先使用一條精確的網域規則，不要一開始就對所有 HTTP 網址套用寬泛的正規表示式。

儲存後的驗證順序與常見問題

四個段落可以同時存在於同一份檔案，但不應將其理解為機械式執行的四步流程。General 影響全域行為，Rule 負責策略比對，Host 影響網域對應，URL Rewrite 則處理可見的請求 URL。排查故障時應依實際現象拆解，不要認為「最後一段會覆蓋前面所有設定」。

1. 在 Config 儲存副本並選取該檔案，確認沒有誤選其他同名設定檔。
2. 返回 Home，確認伺服器可用，再將 Global Routing 設為 Config，以驗證規則分流。
3. 發起一個新的目標請求，記錄目標網域、預期策略、實際連線結果與錯誤訊息；必要時查看相關請求記錄。
4. 還原剛才單項修改後再測試一次。只有修改與還原都能穩定改變結果時，才繼續合併下一項設定。

設定檔只應保留用途明確且結果可驗證的設定。合併遠端規則前，先檢查其比對範圍、目標策略，以及更新是否會覆蓋本機內容。若要進一步確認語法，可查看規則參考；首次連線步驟請參閱使用教學。