Shadowrocket
規則與設定參考

Config、Proxy、Direct 的用途

查閱規則前，先檢查 Home 中的 Global Routing。設定模式對應 Config，表示依目前設定檔的分流邏輯處理；代理模式對應 Proxy，主要是將請求交由代理方向處理；直連模式對應 Direct，主要是直接連線。後兩種模式不能取代驗證 Rule 順序的測試環境。某個網域在 Proxy 模式下可以連線，只能表示該測試路徑的代理連線可能正常，不能據此證明 DOMAIN-SUFFIX 寫法正確。

本頁的規則推演以 Global Routing 設為 Config、目標設定檔已啟用且連線已重新建立為前提。若介面中還有 Scene，應先確認目前場景實際採用的設定檔與策略，不要把場景名稱本身當成一條規則。不同裝置的介面配置可能有所差異，核對時以目前介面顯示的選取結果為準；重點是釐清「請求最後採用哪一套處理邏輯」，而不是只記住按鈕的位置。

General 不是另一份 Rule

General 中的選項會影響較基礎的處理環境，例如使用哪個 DNS 來源、是否處理特定 IP 位址族，以及哪些目標會排除在特定處理範圍之外。這些選項不等同於 Rule 中逐條檢查的條件。假如某類請求已被較前面的網路範圍設定排除，在 Rule 尾端繼續新增針對它的規則，可能不會得到預期結果。疑難排解時應一併檢查 General，但不要一次更動所有一般參數。

例如 dns-server = system 表示使用系統 DNS 來源；這不代表所有請求都會直連，也不代表 DNS 一定能解析你要連線的網域。代理方向由策略決定，名稱解析則為後續連線提供 IP，兩者需要分開檢查。若原設定檔包含其他 DNS 選項，應先了解它們之間的關係，不要只為了讓範例看起來一致，就整段取代既有設定。

[General]
dns-server = system

[Rule]
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

在這段範例中，只有完整網域 api.example.com 明確交由 PROXY 處理。在 Config 模式下，可依此檢查首條條件；切換至其他模式後，觀察到的連線方向便不足以證明這兩行的順序。進行對照測試時，先記錄模式，再發出相同請求，最後恢復原本的 Config。否則一次臨時切換就可能讓後續所有規則測試失去共同前提。

連線狀態與舊工作階段

設定儲存後，已建立的長連線可能仍沿用原本的路徑。瀏覽器連線重用、應用程式的背景工作階段及名稱解析快取都會影響觀察結果。測試時應盡量關閉目標 App 的舊工作階段，視需要中斷並重新連線，再發出新請求。不要因為仍在播放的影音連線沒有改變方向，就認定新規則未生效；也不要把顯示本機快取頁面當成成功連線。

Connectivity Test 可協助判斷某部伺服器的基本連線狀況，但它測試的對象與特定服務請求不同。伺服器測試通過後，目標網域仍可能解析失敗，伺服器端也可能拒絕目前的請求。反過來說，服務頁面載入部分內容，也不代表所有相關子網域都採用相同策略。完整的規則驗證應針對具體請求及比對結果進行，而不是只依賴單一測試圖示。

IP-CIDR：依網路前綴比對

IP-CIDR 使用 IP 位址與前綴長度描述 IPv4 位址範圍。192.168.0.0/16 表示以 16 位元網路前綴劃分的位址範圍，不是只比對 URL 字串開頭為 192.168 的頁面。前綴長度越大，範圍通常越小；單一 IPv4 位址可用 /32 表示。編輯前先確認目標是整個網段還是單一主機，勿將子網路遮罩、連接埠號碼與 CIDR 前綴混在同一參數中。

區域網路服務通常需要直接連線至本機 IP，但仍應依自己的實際網路設定例外。將某個私有 IP 範圍交由 DIRECT，不代表跨網段路由已存在，也不會自動略過裝置或路由器的存取控制。如果裝置連上不同 Wi-Fi 後 IP 範圍有所變動，先前的本機例外可能已不再對應同一項服務。公司網路、訪客網路和家用網路也可能使用重疊的 IP，應依目前環境驗證。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
FINAL,PROXY

no-resolve：避免為規則比對發起解析

IP 類規則可使用 no-resolve 參數，表示不為比對這條規則而額外觸發網域解析。這適用於已知目標 IP，或希望避免只為檢查某個 IP 範圍而解析名稱的情況。不要將它解讀為「整個連線都不需要 DNS」，也不能據此斷定後續代理端、App 或其他規則不會進行解析。請求是否已有 IP，以及後續還有哪些條件，都會影響實際行為。

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

此處將明確的網域策略放在前面，再於後方設定本機 IP 例外。如果請求只有網域，含 no-resolve 的 IP 規則不應被視為一定能透過該網域辨識私有 IP；如果請求已帶有目標 IP，則可依 IP 繼續判斷。設定檔維護者應選擇真正需要的行為：是否願意取得解析結果以分類 IP，或優先保留網域路徑；不要機械式地為所有 IP 規則加上相同參數。

IP-CIDR6：分別處理 IPv6 範圍

IPv6 不會自動納入 IPv4 網段規則。若環境使用 IPv6，就必須將相應的位址族納入測試。IP-CIDR6 的比對值同樣使用 CIDR 格式，但位址採用 IPv6 表示法。以下的 2001:db8::/32 是文件範例網段，適合用來說明格式，不應直接套用至實際服務網段。實際規則應依據你確認擁有或需要處理的目標 IP 範圍設定。

[Rule]
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

同一網域同時回傳 IPv4 與 IPv6 位址時，App 可能優先嘗試其中一種，也可能同時嘗試。因此只觀察一次成功或失敗，很難判斷是哪條 IP 規則參與處理。應分別記錄使用的位址族與目標 IP，再檢查規則涵蓋範圍。如果 IPv6 路徑有問題，先確認網路連線及設定支援狀況，不要將隨意停用某個位址族當成所有問題的通用解法。

GEOIP：依 IP 分類，而非依內容分類

GEOIP,CN,DIRECT 依據目標 IP 的地理位置資料進行判斷。它不會依網頁語言、網站營運者或裝置所在地判斷，也不保證每個 IP 的分類結果都符合使用者預期。內容傳遞網路、共用 IP 和服務遷移，都可能使同一網域在不同網路取得不同 IP；因此不宜將某次符合 GEOIP 的結果推廣至該網站的所有請求。

若服務需要穩定的網域策略，應優先明確設定網域例外，再將 GEOIP 作為較廣泛的 IP 分類條件。排查分類差異時，記錄當時解析到的 IP、測試網路及命中的規則行，避免只說「這個網站應該屬於某地」。也應確認目前使用的地理資料是否適合你的用途；任何分類結果都不能取代對實際目的 IP 與網路可達性的驗證。

DNS 結果與分流結果是兩項不同觀察

DNS 會將網域轉換為連線所需的 IP；Rule 則決定符合條件的請求採用哪種處理策略。兩者會互相影響，但並非同一項設定。網域可能解析成功卻無法連線，也可能在不同路徑上由不同位置完成名稱解析。分析問題時，至少應記錄網域、取得的 IP、命中的規則及最終策略四項資訊。只看到「網域有 IP」不能證明分流正確，只看到 PROXY 也不能證明目標 IP 可連線。

General 中的 DNS 來源會影響解析環境。使用系統來源時，結果可能隨著 Wi-Fi、行動網路及系統網路設定而變化；指定其他來源時，也應確認該來源在目前網路中是否可連線，以及設定檔是否另有解析行為選項。不要為了追求某個測試結果，就在未記錄的情況下同時更換 DNS、伺服器及規則順序。即使恢復連線，也無法判斷真正起作用的是哪項變更。

Host 僅建立明確的名稱與 IP 對應

Host 適合為自己管理的測試服務、固定的內部裝置或暫時性的遷移測試指定 IP。格式通常是網域、等號及 IP；不應填入頁面路徑，也不負責儲存協定密碼。以下設定會將 lab.example.com 指向一個私有 IP，並為該網域指定 DIRECT。兩部分各自表達不同決定：Host 負責 IP 對應，Rule 負責處理方向。

[General]
dns-server = system

[Rule]
DOMAIN,lab.example.com,DIRECT
FINAL,PROXY

[Host]
lab.example.com = 192.168.10.20

只有在你的網路中確實有對應裝置及服務時，該 IP 才有意義。儲存對應並不會建立伺服器，也不會讓裝置自動取得通往另一個區域網路的路由。如果目標服務使用 HTTPS，憑證也必須與存取網域相符；將網域對應到可建立 TCP 連線的 IP，不代表 TLS 驗證一定會通過。遇到憑證錯誤時，應檢查網域、憑證及服務設定，不要把停用驗證當成使用 Host 的一般步驟。

為什麼不應長期固定公用服務的 IP

公用服務常透過 DNS 將連線導向不同區域、負載或位址族。手動固定某個 IP 會略過這項調度；短期可用的 IP 日後可能遷移、停止服務，或不再適合目前網路。共用服務也可能依請求中的網域選擇網站。因此，Host 較適合用於有明確原因、可驗證且可撤銷的對應，不應將疑難排解時取得的 IP 永久寫入所有裝置。

如果確實需要暫時建立對應，應記錄原始網域、原解析結果、替代 IP 及復原方式。測試完成後刪除對應，再檢查一般解析是否恢復。過期的 Host 項目可能讓後續 DNS 調整看似無效，因為該名稱仍被明確指向舊 IP。檢查這類問題時，應先在 Host 搜尋完整網域，而不是只在 General 中更換解析來源。

快取與位址族造成的觀察差異

系統、App、瀏覽器及連線處理流程的不同位置都可能存在解析快取。儲存設定後立即重新整理頁面，有時仍會使用先前取得的 IP 或既有連線。比較建立對應前後的結果時，應建立新的請求工作階段，必要時重新連線，並觀察實際目標 IP。不要只根據頁面是否再次顯示來判斷快取是否已清除；頁面內容本身也可能來自本機資料。

另一項常見差異是 IPv4 與 IPv6 並存。只對應一個 IPv4 位址、只測試一種位址族，可能無法解釋 App 的所有連線行為。應查看 App 的實際存取記錄，確認最後選用的 IP，再檢查 IP-CIDR 與 IP-CIDR6 是否涵蓋相應範圍。對於直接連線至 IP 的請求，Host 網域對應通常不是疑難排解的切入點，因為此時沒有需要轉換的名稱。

建立精簡且可復原的驗證流程

先複製目前可正常使用的設定檔，選擇一個你有權測試的目標網域，寫下預期策略，再新增一條完整網域規則。確認它位於相關廣泛條件與 FINAL 之前，儲存並啟用此副本，將 Global Routing 設為 Config。接著建立新連線，觀察目標網域、目的 IP、命中條件及採用策略。只有上述觀察結果符合預期，才逐步擴大規則範圍或合併至日常設定檔。

不要直接用一份很長的新設定檔取代正在使用的環境，再從大量異常中反推原因。對遠端設定檔，保留原始來源與本機差異；對會更新的訂閱，區分伺服器資料變更與規則檔變更。更新後若出現異常，先確認實際更新了哪個項目。伺服器位址或驗證資訊變更，與 DOMAIN 拼寫錯誤是不同問題，不能靠調整同一項規則解決。

1. 記錄目前網路、Config 名稱、Global Routing 及測試目標，並保留原始副本。
2. 一次只修改一條規則或一項參數，檢查所屬區段及前後規則的覆蓋關係。
3. 儲存後確認目前啟用的是修改後的檔案，並重新建立測試工作階段。
4. 對照記錄中的網域、IP、規則與策略；必要時以 Direct、Proxy 建立比較基準。
5. 恢復 Config 並記錄結果；若未達預期，撤銷此次變更，再檢查下一項。

依觀察到的現象縮小範圍

若完全沒有看到預期規則的命中記錄，先檢查模式、設定檔選擇，以及請求是否確實在目前工作階段中送出；接著確認網域是否誤填成 URL、前方是否已有廣泛條件，或請求是否直接連線至 IP。如果已命中 PROXY 但仍無法連線，應轉而檢查所選伺服器、協定參數、DNS 及目標服務，而不是繼續新增相同網域規則。應將規則命中與連線成功分別記錄。

協定疑難排解也應與規則問題分開處理。例如 Trojan 的位址、連接埠、密碼及 SNI 屬於連線參數，可參閱Trojan 參數填寫要點；Hysteria2 與網路 UDP 條件的關係可參閱Hysteria2 與 QUIC 說明。即使分流規則命中，協定參數錯誤也無法替它補上驗證資訊。

分享診斷資訊前，先清除敏感內容

足以說明問題的精簡記錄通常包含規則片段、使用的模式、目標網域及失敗階段，不需要提供整份訂閱。分享前請移除訂閱連結中的權杖、伺服器密碼、身分識別資訊及私人網路資訊；截圖也要檢查網址列、QR Code 與通知區域。以 example.com 等教學網域替換時，應註明哪些內容已替換，同時保留規則順序與語法結構，否則他人無法判斷覆蓋關係。

以實際用途為單位維護規則。移除不再使用的 Host、整理重複網域、確認 FINAL 仍位於末尾，並為重要服務保留幾個測試輸入。切換網路後，重新檢查區域網路 IP 與位址族；不要把在家用 Wi-Fi 上的一次驗證當成所有情況的保證。規則越多不代表範圍越精確；能說明每條例外的目的、輸入及復原方式，才便於長期維護。

用戶端取得方式與使用前提

Shadowrocket 是閉源商業應用。iPhone / iPad 版在 App Store 售價 $2.99，為一次性付費；Mac（Apple 晶片與 Intel）、Windows、Android、Linux 版免費。用戶端一次買斷不等於線路方案。本網站不提供、不銷售也不推薦節點或訂閱；本手冊僅說明如何使用你已有的資訊。iPhone / iPad 系統需求請以 App Store 頁面標示為準；各平台取得方式與系統允許安裝的說明，請參閱全平台下載頁；其他平台的安裝檔請透過本站 /dl/ 取得。

若要重新檢查連線權限及 Home 頁面，可回到快速上手流程；取得、已購項目還原及安裝的常見問題，請參閱下載常見問題。處理規則問題時，請先儲存目前狀態，再以可重現的最小變更進行測試；若測試結果無法解釋，便撤銷變更並繼續縮小範圍，不要將臨時修補永久留在設定檔中。