Shadowrocket 指定網站代理設定：使用規則讓特定網域走 PROXY，其餘直連

本文重點

若只想讓少數網站透過代理，請在 Shadowrocket（小火箭）中選擇 Global Routing → Config，並將目標網域的 PROXY 規則放在前面，最後以 FINAL,DIRECT 收尾。本文以「使用者已有自己的服務商與訂閱」為前提，說明如何整理網域清單、套用設定、驗證連線及排查遺漏；完成後即可使用預設直連、僅指定網域走代理的規則設定。

一、確認分流目標與適用範圍

這種設定會讓「明確列出的網域走代理，其餘請求預設直連」，適合目標範圍較小、網域清單容易維護的情況。如果希望所有未匹配的請求預設走代理，就不適用本文的兜底方式：FINAL,DIRECT 的作用恰好相反，前面規則未匹配的請求會直接連線。

準備工作分為兩部分：Home 中已有可用的連線項目，Config 中也有一份可編輯、可啟用的設定檔。匯入訂閱只會提供連線項目，不代表目標網站已套用相應的分流規則。購買用戶端、取得連線服務與設定規則是不同事項；用戶端買斷 ≠ 連線方案。

連線前提：先在 Home → Connectivity Test 檢查現有項目的基本連線狀況，再選擇這次要使用的項目。測試結果不代表目標網站一定能正常使用。
規則前提：確認可以備份並修改目前的設定檔，避免直接覆寫仍在使用的規則。
適用範圍：本文討論進入 Shadowrocket 並由規則處理的請求；系統流量、排除路由與 DNS 設定仍須分別檢查。
應用程式來源：Shadowrocket 是 Apple 平台上的閉源商業應用程式，唯一取得管道為 App Store，主要供 iPhone / iPad 使用；系統需求請以 App Store 頁面標示為準。

二、Global Routing 必須選擇 Config

在 Home → Global Routing 中選擇 Config，才能依照目前啟用設定檔中的規則決定流量出口。Proxy、Direct 適合用於臨時比對測試，但不能取代「只讓部分網域走代理」的規則設定。如果介面中使用了 Scene，也請先確認該場景實際採用的路由設定；本文驗證時固定使用 Config，以減少條件變動。

Config

建議

依照啟用設定檔中的規則進行比對。搭配目標網域的 PROXY 規則與末尾的 FINAL,DIRECT，即可讓指定網域走代理、其他請求直連。

適用情境：日常分流時明確維護少數目標網域。

Proxy

對進入此路由處理範圍的流量一律使用代理，不會依照本文的網域規則區分目標。切換後網站能否使用，只能用來協助判斷問題是否與分流有關。

適用情境：暫時判斷應從代理連線還是規則比對著手排查。

Direct

對進入此路由處理範圍的流量一律直連。即使設定檔中寫有 PROXY，維持此模式也無法達到本文預期的分流結果。

適用情境：暫時比對目前網路的直連狀況。

先固定模式，再修改規則

每次測試前，確認 Home → Global Routing → Config，並核對目前啟用的設定檔名稱；不要同時切換模式、更換連線項目和修改網域，否則無法判斷是哪個變更影響結果。

三、整理網域清單，再撰寫最精簡的規則

網域規則比對的是主機名稱，不是整段網址。以 https://www.example.com/account 為例，應擷取 www.example.com，不要將 https://、路徑 /account 或查詢參數放進 DOMAIN 規則。以下使用保留的示例網域說明語法，並非可用的連線測試目標。

2 種

本文使用 DOMAIN 與 DOMAIN-SUFFIX 兩種網域比對方式

3 段

網域規則依序填入類型、比對內容及策略，並以英文逗號分隔

1 條

將 FINAL,DIRECT 放在規則末尾，作為統一兜底

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,login.example.net,PROXY
FINAL,DIRECT

以下是用來說明的 [Rule] 內容，並非要求覆寫整份設定檔。第一條會同時比對 example.com 及其子網域，例如 www.example.com、static.example.com；但不會比對 notexample.com。第二條只比對 login.example.net，不會連帶讓 www.example.net 走代理。

請求主機名稱	匹配項目	預期策略
`example.com`	第一條 DOMAIN-SUFFIX	`PROXY`
`img.example.com`	第一條 DOMAIN-SUFFIX	`PROXY`
`login.example.net`	第二條 DOMAIN	`PROXY`
`www.example.net`	末尾 FINAL	`DIRECT`

PROXY 代表使用代理出口，實際連線仍取決於目前選用的代理及設定檔中的策略設定；它不是需要填入的伺服器位址。如果原設定檔使用自訂策略群組，請確認群組名稱及群組內的選擇，不要直接把既有群組名稱改成 PROXY。本文示範的是直接使用 PROXY 策略的最精簡設定。

四、依序修改並啟用設定檔

規則通常由上而下比對，第一條匹配的規則會決定策略。因此，只把新規則加在既有 FINAL 後面不會生效；若放在較早匹配的廣泛規則後面，也可能永遠不會輪到。要維護「僅指定網域走代理」的設定，應檢查整個規則區段，而不是只看新增的兩三行。

保留副本

進入 Config，先保留目前設定檔的副本或匯出備份，並記下目前啟用的設定檔名稱。如果設定檔由遠端內容維護，請先另存一份本機副本再編輯，避免後續更新覆蓋手動修改。
整理規則

在 Config 中開啟待修改設定檔的編輯介面，找到 [Rule]。使用文字編輯時，只修改相應區段；使用規則編輯介面時，請檢查類型、網域與策略。不要重複新增第二個 [Rule] 區段。
設定兜底規則

將目標網域的 PROXY 規則放在可能攔截它們的廣泛規則之前，並在末尾保留 FINAL,DIRECT。檢查原有的其他 PROXY 規則或規則集；如果保留這些項目，就不再是「只有本文列出的網域走代理」。
啟用設定檔

儲存後返回 Config，選擇剛修改的設定檔，並確認目前的啟用標記。只儲存檔案不代表它已成為目前使用中的設定檔。接著前往 Home → Global Routing → Config。
重新驗證

確認 Home 中選取的代理項目可用，再重新建立連線並送出新請求。不要只重新整理仍維持連線的頁面；必要時先關閉舊頁面再重新開啟，避免連線重用影響判斷。

五、同時驗證目標網域與非目標網域

驗收時應確認「匹配了哪條規則」，而不只是「網頁能不能開啟」。網頁能開啟，可能是直連成功，也可能是代理成功；網頁無法開啟，則可能與 DNS、目標服務、代理連線或缺少相依網域有關。Connectivity Test 用來檢查連線項目，不能取代逐一核對請求規則。

目標請求：選擇實際需要走代理的主機名稱，送出新請求，並在連線紀錄中核對請求網域、匹配規則與出口策略；預期結果為相應的網域規則及 PROXY。
比對請求：選擇一個不在清單內、目前網路可直連的主機名稱，預期應匹配 FINAL 並使用 DIRECT。兩種情況都符合預期，才能確認預設策略與例外規則均已生效。
相依請求：分別測試首頁、登入、圖片載入及實際功能。同一個頁面可能同時向多個網域發出請求，首頁正常不代表登入與資源載入也都正常。
環境紀錄：記下使用 Wi-Fi 或行動網路、啟用的設定檔名稱，以及發生問題的具體主機名稱。每次只修改一項，再重複相同操作，方便比較結果。

如果頁面文字正常顯示，但圖片空白，請先查出圖片請求實際使用的主機名稱。例如，正文來自 www.example.com，圖片卻來自 img.example.net，第一條後綴規則就不會涵蓋後者。確認該主機也需要走代理後，才新增一條 DOMAIN,img.example.net,PROXY，並將它放在 FINAL 之前。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,login.example.net,PROXY
DOMAIN,img.example.net,PROXY
FINAL,DIRECT

不要只因一次資源載入失敗，就直接擴大到 DOMAIN-KEYWORD 或大範圍 IP 規則。共用基礎設施上的網域與位址可能服務多個網站，規則範圍越廣，「只代理指定網站」的界線就越難維持。

六、常見問題與檢查方式

規則已設定，為什麼指定網站仍然直連？

先確認 Home → Global Routing 是否選為 Config，再到 Config 核對啟用的設定檔。接著檢查規則順序：較早出現的 DIRECT、規則集或 FINAL 都可能先匹配。最後核對連線紀錄中的實際主機名稱，確認它與填入的網域一致，而非轉址後的另一個網域。

為什麼其他網站也走代理？

先確認 Global Routing 是否停留在 Proxy。若已選擇 Config，請檢查原設定檔是否仍保留其他 PROXY 規則、範圍較廣的 DOMAIN-KEYWORD 或引用的規則集，並確認末尾不是 FINAL,PROXY。後綴規則會涵蓋所有相符的子網域；若要縮小範圍，請改用 DOMAIN。

可以只讓特定網頁路徑走代理嗎？

本文使用的 DOMAIN 與 DOMAIN-SUFFIX 無法區分同一主機名稱下的 /video 與 /account，也不會因連接埠不同而自動成為不同的網域規則。HTTPS 常用的連接埠是 443，但在規則內容後加上 :443 並不能取代正確的主機名稱。若只想區分子站，請先確認它們是否使用不同的主機名稱。

使用 IP 位址連線，為什麼沒有匹配網域規則？

直接向 IP 位址發出請求時，不能假設一定會匹配網域規則。如果確實需要代理固定的 IPv4 位址，可依需求使用例如 IP-CIDR,192.0.2.10/32,PROXY,no-resolve 的規則，並將它放在 FINAL 前；此處的位址是文件示例位址。不要把網站暫時解析出的整個位址範圍都納入代理，以免共用位址與解析結果變動擴大影響範圍。

更新訂閱後，規則也會一併變更嗎？

更新連線訂閱與修改 Config 中的規則設定是不同操作。更新後，先確認目前選用的代理仍然有效，再核對啟用的設定檔是否有變更。如果單獨更新的是遠端設定檔，則應檢查本機修改是否已被覆蓋。不要只因連線清單更新成功，就認定規則仍然正確。

七、維護清單與還原原始設定

後續維護應以「實際請求的主機名稱」為單位。發現某項功能無法使用時，先記下失敗的網域，再判斷是否應將它加入代理清單；不需要代理的統計、資源或其他請求，不必為了讓紀錄看起來整齊而一併加入。規則越精確，就越容易說明每次出口的選擇。

新增網站：先判斷只需要涵蓋某個主機名稱，還是整個網域及其子網域，再選用 DOMAIN 或 DOMAIN-SUFFIX。
移除網站：一併檢查其獨立的資源網域與登入網域，刪除不再需要的規則，並保留末尾的 FINAL,DIRECT。
連線異常：先確認目前使用的連線項目及 Connectivity Test 結果，再檢查匹配規則；不要把連線無法使用誤判為網域語法錯誤。
還原修改：在 Config 中重新啟用先前保留的設定檔，確認 Home → Global Routing → Config，再建立新連線進行測試。如果連線會自動觸發，可前往 Settings → On Demand 檢查觸發條件，避免將連線行為與規則出口混為一談。

最終驗收只看兩項：清單內的實際請求匹配預期的 PROXY 規則，清單外的比對請求匹配 FINAL,DIRECT。保留設定檔副本、驗證紀錄與清楚的網域範圍，比反覆切換全域模式更利於長期維護。