Shadowrocket 設定欄位
與規則完整參考

設定檔結構：先釐清各段落的用途

Shadowrocket 設定檔通常以 .conf 組織內容，方括號中的名稱代表段落，段落下的每一行則代表設定、對應或規則。設定檔不是把所有參數連續堆在一起的清單：相同文字放在不同段落，意義可能完全不同，也可能無法解析。閱讀陌生設定檔時，先找出段落界線，再看個別欄位，比直接搜尋某個網域更容易判斷整份設定檔的用途。

四個常用段落各司其職

[General] 放置一般行為設定，例如 DNS 相關選項；[Rule] 說明流量比對條件及對應策略；[Host] 為指定網域設定 IP 對應；[URL Rewrite] 依照運算式處理符合條件的 URL。這些功能位於不同處理階段，不能互相取代。若要讓網域直連，應先考慮規則，不要為了改變流量去向而任意修改網域解析結果。

從基本片段認識語法

以下片段示範段落、指定設定值與規則三種寫法。等號用於指定設定值，逗號用於分隔規則欄位，兩者不可互換。規則中的 PROXY 是策略，不是伺服器位址；範例未包含你的伺服器資訊，因此僅供參考規則結構。使用前仍須在 App 中準備可用的既有伺服器，並確認目前選取的連線對象。

[General]
dns-server = system

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

逐行閱讀時，先檢查英文逗號與等號，再確認關鍵字、參數數量和策略名稱。中文輸入法產生的全形標點看起來相似，卻不一定會被識別為有效分隔符號。段落名稱應保留原文；行首或行尾多出的不可見字元，以及複製時混入的富文字符號，也可能讓看似正確的規則失效。建議使用純文字編輯，並保留清楚的空行。

完整設定檔與規則片段的差異

本頁多數程式碼區塊只展示相關段落，不應把每個區塊依序拼進同一個檔案。這些片段可能用來說明不同情境，尤其不可將多個 FINAL 當作多層備援規則堆疊。將片段加入現有檔案時，應合併至對應的既有段落，先檢查是否已有同類規則，再決定插入位置，避免重複段落和互相矛盾的策略增加維護難度。

伺服器訂閱和設定檔也不是同一種資料。訂閱通常用來提供或更新伺服器項目，設定檔則用來規定連線行為；擁有其中一項，不代表另一項也已備妥。訂閱應向你的服務商取得，並確認格式符合匯入入口的要求。不確定連結類型時，可先閱讀訂閱匯入方式說明，不要反覆切換設定檔來解決連結格式問題。

本章的檢查目標是弄清楚各段落的用途，而不是先把所有段落填滿。沒有明確需求的功能可以不加入；精簡且容易理解的設定更容易驗證。遇到不熟悉的欄位，先核對 App 內說明和實際結果，不要只因它出現在某份設定檔中，就假定適合目前的裝置和網路。

General：一般設定與 Global Routing

[General] 是設定檔層級的一般設定區，Global Routing 則是執行時選擇路由模式的入口。兩者有關聯，但不在同一層：即使已在文字中寫好規則，仍須確認目前模式是否會套用這些規則。排查「規則明明存在卻沒有生效」時，應先確認模式和目前使用的設定檔，再修改欄位，否則容易在錯誤前提下不斷增加規則。

Config、Proxy、Direct 三種模式

設定檔模式對應 Config，依目前設定檔處理連線；代理模式對應 Proxy，讓通常由 App 接管的連線採取代理路徑；直連模式對應 Direct，讓連線採取直連路徑。這裡說明的是整體選擇，不代表系統中的所有連線都一定經過相同路徑。系統保留行為、既有連線，以及未納入處理範圍的流量，都不能只憑模式名稱判斷。

如果同一個目標在 Proxy 下可存取，在 Config 下卻失敗，可以進一步檢查規則命中、DIRECT 路徑和 DNS 差異，但這還不能直接證明某一條規則有誤。測試前後必須維持相同的伺服器、目標和網路條件。比較完成後，請恢復原本模式，避免把暫時測試狀態當成日常使用狀態，導致後續現象與設定檔內容不一致。

DNS 設定不等於流量策略

DNS 用於將網域解析為 IP，規則則用來決定如何處理連線。網域解析正確，不代表目標連線一定成功；選擇 PROXY，也不能據此推斷每次 DNS 查詢的處理路徑。DNS 還會受到 App 設定、快取、網路環境和請求方式影響。應將「解析出什麼 IP」與「連線採用什麼策略」分開檢查。

[General]
dns-server = system

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

dns-server = system 表示此設定使用系統 DNS 設定作為來源，不保證目前網路的解析結果一定合適。這適合用來理解語法，並非所有環境都適用的標準答案。若要調整解析方式，先記錄原值，每次只修改一項，並分別驗證目標網域和其他常用網域，避免只解決單一目標，卻影響其他請求。

預設值與明確設定的界線

從設定檔中刪除某個一般欄位，通常代表交由預設機制處理，不一定等同於將欄位設為某個布林值。預設行為也可能受到 App 設定影響，因此不要把「沒有這一行」解讀為「該功能必定關閉」。移植設定檔時，只保留用途明確的欄位即可；對意義不清的選項，先在副本中測試，不要一次複製整組所謂的最佳化參數。

IPv6、DNS 和網路範圍相關設定，會同時影響規則能取得的連線資訊。例如目標可能優先使用 IPv6 位址，但設定檔只寫了 IPv4 網段；這時並非加上一個通用開關就能解釋所有現象。應先查看實際連線位址，再決定要新增 IP 規則、調整解析行為，或維持預設設定。變更 IP 位址類型可能影響其他服務，務必完整重新測試。

On Demand 與設定檔規則分開管理

On Demand 關注何時建立連線，[Rule] 則決定連線開始處理後如何分流。不要把網域規則寫成按需連線的觸發設定，也不要因為系統自動連線，就認定特定規則已命中。先依照 App 內的入口確認 On Demand 條件，再個別驗證設定檔規則，分開記錄兩者結果，排錯時才有清楚界線。

一般欄位的合理目標是讓行為可預測，而不是讓檔案盡可能複雜。確認目前模式為 Config、正在使用預期的設定檔、所選伺服器可用後，再檢查規則細節。若基本連線尚未完成，請返回快速上手指南確認系統授權與連線步驟；本頁後續章節皆以基本連線已可驗證為前提。

網域規則：精確、後綴與關鍵字

網域規則適合描述「哪些主機要使用哪種策略」。通常比不斷追蹤服務位址變化更容易維護，但前提是處理連線時能取得相應的網域資訊。頁面上看到的網址、App 實際連線的主機、登入服務和資源網域可能各不相同，不能只複製瀏覽器網址列中的主網域，就假定已涵蓋一次瀏覽所產生的所有請求。

DOMAIN：只比對完整主機名稱

DOMAIN 用於比對完整網域。以下第一條只指定 api.example.com，不會自動涵蓋其他同層主機。網域欄位不應包含通訊協定、路徑或連接埠；https:// 和 /login 是 URL 的其他部分，直接放進 DOMAIN 欄位無法依頁面路徑分流。若要精確控制某個入口，優先使用這種涵蓋範圍明確的寫法。

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

維護精確規則時，可以為每個例外加上一行簡短註解，說明它與其他主機不同的原因。註解應說明用途或測試結論，不要記錄帳號、權杖或完整的敏感連結。精確規則變多時，先依服務分類整理，再考慮是否真的需要後綴規則；只為少寫幾行而擴大比對範圍，往往會增加意外命中的機率。

DOMAIN-SUFFIX：涵蓋根網域及子網域

DOMAIN-SUFFIX,example.com,PROXY 適用於 example.com 及其子網域，例如 www.example.com 和 api.example.com。它會依照網域後綴邊界比對，不是任意包含字串，因此不能將拼法相似的其他網域視為涵蓋範圍。填寫時通常使用根網域格式，開頭不要加星號，後面也不要接路徑。

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

這個順序表示先處理例外，再處理一般範圍。存取 local.example.com 時，前面的精確規則會先命中；存取其他符合條件的子網域時，才會套用後綴規則。如果把後綴規則放在最前面，後面的精確規則不會因為「更具體」就自動取得優先權。規則不是瀏覽器的樣式選擇器，不會掃描整張清單後再重新挑出最精確的一條。

DOMAIN-KEYWORD：使用前先評估涵蓋範圍

DOMAIN-KEYWORD 會檢查網域是否包含指定關鍵字，涵蓋範圍比固定網域更廣。相同關鍵字可能出現在多個無關網域中，因此只適合確實有共同命名規律，且已了解影響範圍的情境。不要把品牌名稱、短縮寫或常見英文單字當成天然準確的服務界線，否則可能讓無關連線套用相同策略。

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

上方片段只示範關鍵字規則的語法，不建議直接當作日常分流方案。它說明的是以字串為比對依據，而不是網站歸屬、服務類型或頁面內容。若連線記錄已提供穩定的完整主機名稱，優先考慮 DOMAIN 或 DOMAIN-SUFFIX，讓規則含義一目瞭然，也能透過有限測試加以驗證。

為什麼一次瀏覽可能需要多條規則

登入、圖片、API 和媒體資源可能使用不同網域。主頁能開啟但登入失敗時，應查看失敗連線實際使用的主機，不要立刻改用涵蓋範圍模糊的關鍵字。逐一新增明確網域後再試，確認新規則確實改變了對應連線。若發生重新導向，也要確認重新導向後的目標；原始入口命中，不代表最終目標也採用相同策略。

若記錄中只有 IP，沒有可用網域，繼續增加 DOMAIN 規則可能不會有作用。請檢查請求是否直接使用 IP、能否取得網域資訊，以及是否已有 IP 規則先行命中。網域規則用來比對已知主機，不負責探索服務。也可參考常見問題中的分流排查內容交叉確認。

IP 與請求條件：GEOIP、IP-CIDR、USER-AGENT

當目標以 IP 位址呈現，或需要用網段描述存取範圍時，可以使用 IP 規則。它與網域規則的主要差異在於比對對象：網域描述主機名稱，IP 規則描述連線目的位址。同一網域可能解析到多個 IP，同一個 IP 也可能對應多個網域。因此 IP 規則較適合用於明確網段，不適合在缺乏依據時取代所有網域規則。

IP-CIDR：IP 位址與前綴長度

IP-CIDR 使用 IPv4 位址和前綴長度描述網段。斜線後的數字代表網路前綴位數，不是連接埠或連線數量；數值越大，涵蓋範圍越小。單一 IPv4 位址可用 /32 表示。編寫前應確認實際網路範圍，避免把單一裝置位址誤寫成過大的網段，讓其他連線也套用相同策略。

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

這些片段表示常見私有 IP 範圍的直連意圖，但是否需要全部加入，仍取決於裝置所在的網路。規則只會決定 App 處理範圍內的策略，不能保證路由器已允許存取，也無法取代本地網路權限和目標裝置的存取設定。若目標實際位於另一個網路，只設定 DIRECT 不會自動建立通往該網路的路徑。

no-resolve 的用途與限制

no-resolve 是 IP 規則的附加選項，用來避免單為嘗試比對這條規則而觸發網域解析。它不是「關閉 DNS」，也不代表後續連線不需要解析。目標本身已是 IP 時，仍可依網段判斷；若請求只有網域、尚無可用 IP，就不能期待這條規則主動解析後再比對。區域網路 IP 規則常使用此選項，以減少不必要的解析。

若要依某網域解析後的 IP 歸屬分流，加入 no-resolve 前應先了解它可能改變命中條件。排錯時，比較「已有可用 IP 資訊」與「沒有可用 IP 資訊」的請求，比反覆增刪此選項更有幫助。不要將 IP 規則中的這個選項照搬到 DOMAIN 或 FINAL 行，不同規則的欄位要求並不相同。

GEOIP：依據 IP 歸屬資料比對

GEOIP 依據 IP 歸屬資料判斷區域，例如以下的 CN 代表相應的區域代碼。它不會依網站使用的語言、企業所在地或網域後綴判斷。服務採用分散式部署時，解析出的 IP 歸屬可能與使用者直覺不同，資料也可能有所延遲。若需要穩定的例外規則，應在區域規則前設定明確的網域規則，而不是用區域規則判斷服務身分。

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

此範例先為 api.example.com 保留明確策略，再對其他連線嘗試區域比對。若沒有前面的例外，該網域解析到符合區域條件的 IP 時，可能採用 DIRECT。是否符合預期，必須查看實際命中的規則和目的 IP，不能只看網站名稱。也應確認 App 目前可用的相關資料及設定。

IP-CIDR6 與 USER-AGENT 的適用範圍

IP-CIDR6 用於 IPv6 網段。以下位址屬於文件範例範圍，只示範前綴寫法，不可作為真實服務位址使用。IPv4 規則不會自動涵蓋 IPv6 目標；若某條連線實際使用 IPv6，應依實際需求處理，不能因 IPv4 規則未命中就認定整份規則清單失效。

[Rule]
IP-CIDR6,2001:db8::/32,PROXY
USER-AGENT,ExampleClient*,PROXY
FINAL,DIRECT

USER-AGENT 依賴請求中可觀察到的 User-Agent 資訊，並可用萬用字元形式描述字串。範例中的 ExampleClient 僅為示範值，不代表任何實際 App。它不是依裝置上安裝的 App 名稱比對，也不等同於程序比對；如果請求沒有相應資訊、資訊無法查看，或用戶端更改了識別字串，規則就無法涵蓋預期對象。

尤其是加密連線，不要假設一般分流機制能讀取其中的 HTTP 請求標頭。不要為了讓 USER-AGENT 規則生效，就盲目擴大解密範圍。本頁的基本分流範例不需要增加這類處理。通常應優先使用可明確觀察並驗證的網域或 IP 條件，將 USER-AGENT 視為有適用前提的補充方式，而非通用的服務識別方法。

策略與優先順序：先命中的規則先決定

規則左側描述條件，右側描述命中後採用的策略。PROXY、DIRECT、REJECT 是最常見的策略關鍵字，分別代表代理、直連和拒絕。規則命中不代表一定能存取目標：命中只表示已選定處理方式，之後仍可能因伺服器無法使用、目標拒絕或網路狀況而失敗。應分別確認「策略選擇正確」和「策略路徑可用」。

PROXY 與 DIRECT 都需要可用的連線路徑

PROXY 會依目前選取的代理設定處理連線，不會在缺少伺服器資訊時自動補上可用連線。若選取的伺服器無法使用，即使規則正確，連線仍會失敗。DIRECT 則取決於裝置目前的網路能否連上目標，並非比代理更高階的修復方式。兩種路徑都應針對相同目標進行實際連線測試，不能只憑規則文字判斷速度或穩定性。

REJECT 用來明確拒絕符合條件的請求，表示管理者的設定意圖，不是連線失敗後的備援策略。將範圍廣泛的網域設為 REJECT 前，應先確認其中是否包含登入、驗證和資源 API；否則可能出現主頁能開啟、部分功能卻持續失敗的情況。排查這類問題時，優先查看拒絕記錄，不要先修改伺服器參數。

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

具體規則應放在涵蓋範圍較廣的規則前面

規則通常依清單由上而下比對，第一條命中的規則就會採用對應策略，不會等所有條件都檢查完才選擇「最精確的一條」。上方順序先處理兩個例外，再將後綴規則套用於 example.com 的其他範圍。若將後綴規則移到第一行，兩個例外就會先被它涵蓋。閱讀設定檔時，應像追蹤執行流程一樣逐行判斷，而不是只確認某條規則是否存在。

優先順序取決於規則所在位置，不是關鍵字本身。DOMAIN 不會天然優先於 DOMAIN-SUFFIX，網域規則也不會天然優先於 IP 規則。為了方便維護，可以依「明確例外、服務範圍、網路範圍、最終策略」安排規則；這只是一種整理方式，不代表 App 會自動排序。匯入後應檢查實際清單，確認規則順序符合預期。

FINAL 是兜底規則，不是自動故障轉移

FINAL 不需要填寫網域或 IP 條件，通常放在規則清單末尾，用來指定前面規則都未命中時採用的方向。它不是「前一條連線失敗後再執行」的指令。若某條規則已命中 PROXY，但代理連線失敗，不要期待下一行的 DIRECT 會自動接手。條件比對與連線路徑故障是兩回事，混為一談容易設計出錯誤的備援方式。

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

這個片段表示只有明確指定的範圍使用 PROXY，其餘流量使用 DIRECT。若將最後一行改成 FINAL,PROXY，未命中前面規則的流量就會使用代理路徑。兩種寫法都能清楚表達意圖，沒有一種能適用所有需求。選擇時應列出哪些服務需要設定明確例外；修改最終策略後，也要重新測試原本沒有專屬規則的目標，不能只測試已寫入規則的網域。

逐條推演，檢查規則衝突

手動推演某個目標時，先列出實際網域和 IP，再從第一條規則開始逐一確認「目前資訊是否符合條件」。找到第一條命中規則就停止，並記錄策略及所在位置。如果推演結果和實際記錄不同，再檢查目前使用的設定檔、DNS 結果、既有連線，以及取得的目標資訊是否一致。這種方法有助於分別處理寬泛規則遮蔽、例外設定錯誤和兜底規則缺漏。

不要用重複規則表示優先順序，也不要靠多個 FINAL 猜測執行結果。刪除重複項前，先確認它們是否使用不同策略或附加選項；合併後只保留一份容易理解的順序。設定完成的標準是能說明常用目標「為什麼命中這一行」，而不是規則數量變多。若策略正確但連線仍失敗，下一步應檢查連線，不要繼續堆疊條件相同的規則。

Host 與 URL Rewrite：位址對應和 URL 處理

[Host] 和 [URL Rewrite] 常與規則檔案一同出現，但它們不是分流規則的不同寫法。Host 會變更指定網域的解析對應，URL Rewrite 會處理符合運算式的 URL，Rule 則決定連線策略。先釐清你要改變的是「網域對應的 IP」、「請求的 URL」還是「連線去向」，再選擇適當段落，避免同時修改多處而無法判斷結果。

Host 對應需要真實有效的目標 IP

以下 Host 範例將完整主機名稱指向文件範例 IP。該 IP 僅用於示範格式，不能直接用來存取真實服務。實際使用時，只有在你掌握目標 IP、確認服務接受相應主機名稱，且能維護 IP 變動時，才適合設定固定對應。共用部署、負載平衡和服務遷移，都可能讓長期固定的 IP 失效。

[Host]
api.example.com = 192.0.2.10

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

Host 行本身沒有指定 DIRECT 或 PROXY。範例中的連線策略由 Rule 段落決定，不能把對應成功當成策略正確。即使網域已解析至指定 IP，目標端仍須正確提供對應服務，憑證也應符合存取時使用的主機名稱。遇到憑證或主機名稱錯誤時，應還原對應並確認目標，不要降低驗證要求來掩蓋 IP 選擇問題。

如果某個網域原本可以存取，設定固定對應後反而失敗，先刪除或還原該 Host 設定，再以相同條件重試。服務 IP 可能已變更，網路也可能回傳不同的可連線 IP。排錯時記錄設定固定對應前後的結果，才能判斷問題是否由對應方式造成。對於無法持續維護的網域，保留正常解析通常比手動固定 IP 更容易維持一致。

URL Rewrite 的三個部分

URL Rewrite 通常包含比對運算式、替換目標和處理動作。以下示範將指定範例網域的 HTTP URL 重新導向至 HTTPS：運算式從網址開頭比對，括號會擷取路徑，替換部分透過 $1 引用擷取內容，末尾的 302 表示重新導向動作。這只是獨立的語法範例，不代表所有網站都應加入相同規則。

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

運算式中的點號必須跳脫，才會代表網域中的字面點號；在正規表示式中，未跳脫的點通常有更廣泛的意義。開頭的 ^ 限定從 URL 起始位置比對，降低誤中其他相似網址的機率。編寫後應同時測試應命中和不應命中的請求，不能只確認一個成功範例。

重新導向不等於切換代理策略

重新導向會讓用戶端發出新的請求，新目標仍須依適用規則處理。這不代表原連線改用 PROXY，也無法修復伺服器密碼或通訊協定參數錯誤。如果替換後主機有所變更，也應分別檢查原始主機和目標主機的規則。重新導向迴圈通常是規則互相指回，或伺服器端重新導向與本機處理互相衝突所致；應先停用相關 Rewrite，縮小問題範圍。

URL 能否處理，也取決於通訊協定、請求資訊是否可見，以及相關功能設定。不能從一般 HTTP 範例推論可讀取任意 HTTPS 路徑。加密連線的路徑和請求標頭不會自然暴露給一般分流處理，本頁不要求啟用額外的解密功能。若只想依主機分流，優先使用網域規則，讓處理範圍符合實際需求。

維護時為每筆對應設定註明撤除條件

完善的維護記錄不只說明新增原因，也應寫明何時刪除。例如，暫時測試某個服務 IP，測試結束後就恢復正常解析；因應某次遷移新增重新導向，則應在入口統一後重新評估。沒有撤除條件的暫時項目，容易成為長期故障來源。修改檔案前，先搜尋其他段落中是否也出現相同網域，避免一處還原後，另一處仍在改變請求。

連線結果與預期不符時，依序列出原始 URL、對應 IP、改寫後的 URL 和最後命中的策略。四項中任何一項與假設不同，就先處理該層。這樣能區分 IP 過期、運算式涵蓋過廣、目標重新導向和策略選擇錯誤，而不是把所有異常都歸咎於規則失效。進階功能應建立在最小設定已驗證的基礎上。

設定檔匯入與維護：保留來源、選取狀態與還原方式

管理設定檔的重點不在於儲存了多少檔案，而是能確認目前生效的內容、了解哪些部分會在更新時被覆寫，並能還原至已驗證的狀態。既有訂閱應向你的服務商取得；匯入前先確認連結提供的是伺服器清單、完整設定檔，還是其他資料。不同入口所需的內容可能不同；連結能在瀏覽器開啟，不代表格式符合目前入口的解析要求。

匯入前先確認資料類型

伺服器訂閱更新後，可能改變伺服器名稱、項目數量和參數；規則設定檔更新後，則可能改變策略和順序。兩者應分開記錄。若只是想新增既有伺服器，不要為了讓匯入成功而取代整份已驗證的設定檔；如果匯入的是完整設定檔，先檢查其中是否包含 General、Host、Rewrite 等額外設定，並了解這些設定是否會改變現有網路行為。

在 Config 中管理檔案時，匯入完成後還須確認選取的是預期設定檔。檔案出現在清單中，不代表它正在生效；編輯了副本，也不代表執行時已切換至該副本。建議使用用途明確的檔名區分日常設定與測試設定，並記錄目前選取狀態。匯入方式依 App 內顯示操作，初次使用可參閱使用說明。

將每次變更縮小到可驗證的範圍

例如只想讓本地服務直連，可以先新增一條精確的網域規則，而不是同時替換 DNS、新增 IP 網段、修改 FINAL 並加入 Rewrite。每增加一個變數，就多一個需要說明的環節。保留副本後，只修改相關段落，以相同目標重新測試，再確認其他常用目標未受影響。確認有效後，再決定是否擴大規則範圍。

# 本次僅新增 local.example.com 的直連例外
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

註解應清楚寫出「這次修改了什麼」和「如何驗證」，不要只寫含糊的最佳化、修復或加速。檔名、註解和測試記錄也不應包含真實訂閱權杖。訂閱連結通常包含存取憑證，分享給他人協助排錯前，應移除完整查詢參數及敏感伺服器資訊。保留必要的語法結構即可，不必公開真實憑證來說明規則問題。

遠端更新與本機修改應分開處理

再次更新遠端設定檔時，本機修改可能會被取代，實際情況取決於管理方式。更新前先記錄自訂項目及所在位置，更新後比對規則順序、最終策略和額外段落。不要只因檔名相同就假設內容沒有變動，也不要發現規則消失後立刻重複匯入多份檔案。先確認更新對象和目前生效的選取項目，再還原必要的自訂內容。

伺服器項目名稱變更也值得確認。若其他設定內容引用了某個名稱，更新後名稱不一致可能導致引用失效。即使本頁主要使用內建策略，也應確認伺服器選取仍指向預期對象。匯入和更新完成後，分別驗證伺服器連線、Config 模式和規則命中，避免將伺服器更新問題誤判為規則語法問題。

還原設定檔不等於還原購買或帳號狀態

設定檔用於管理網路行為，不負責還原 App Store 購買項目。Shadowrocket 是 Apple 平台的付費 App，唯一取得管道是 App Store；購買與已購項目還原方式請參閱已購項目還原說明。系統需求以 App Store 頁面標示為準。用戶端一次買斷 ≠ 連線服務方案；購買 App 不會自動為設定檔提供伺服器，仍須使用你已有的服務資訊。

更換裝置前，應分別儲存需要保留的設定檔與伺服器資訊，並確認敏感資料的存放位置。系統備份、App 內匯入和 App Store 已購項目還原各有不同用途，不能互相取代。重新安裝後能開啟 App，不代表原有規則、訂閱和選取狀態都已還原。依序檢查這些項目，比一次匯入所有舊檔案更容易避免混亂。

訂閱更新失敗或清單為空時，先檢查連結格式、有效性及服務商端狀態，不要透過重寫 Rule 段落來處理解析問題。可參考訂閱更新失敗或伺服器清單為空的自查步驟。維護完成後，保留最近一次已驗證的副本，並清除不再使用的測試檔案，降低日後誤選舊設定檔的機率。

驗證與排錯：從現象追查實際命中規則

驗證規則時，應建立一條能清楚說明的證據鏈：目前使用哪個設定檔、處於哪種 Global Routing 模式、請求的實際目標是什麼、命中哪條規則、最後採用什麼策略，以及連線在哪個環節失敗。只說「網路連不上」不足以判斷問題。先將現象縮小至單一目標和單次測試，再依處理層逐一核對，通常比反覆替換整份設定檔更有效。

第一步：固定測試條件

先記錄目前網路、所選伺服器和設定檔名稱，並選擇一個可重複存取的目標。測試期間盡量維持條件不變，不要同時切換網路、伺服器和規則。App 可能會沿用舊連線；修改設定後，既有連線不一定立即重新比對。必要時結束相關請求並重新發出，再查看新的連線記錄。不要把舊連線結果當成新規則的執行結果。

可使用以下片段建立最小測試案例，但應在副本中測試，並將範例網域換成你確實掌握的目標。這個片段用來減少規則數量，讓命中結果更容易解釋，不是適用於所有日常流量的通用方案。若最小測試正常，再分組還原原設定；若還原某一組後再次出現異常，就集中檢查該組的涵蓋範圍、順序和附加設定。

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

第二步：釐清測試工具的用途

Connectivity Test 可協助觀察伺服器在特定測試方式下是否可連線，但不能取代對每個目標的實際存取測試。某項測試成功，不代表所有通訊協定、連接埠和遠端服務都可用；測試失敗時，也要結合測試方法和實際請求判斷。應同時查看目標存取結果和連線記錄，不要把單一測試數值當成整套規則正確的證明。

第三步：依症狀檢查對應層

解析失敗時，先確認網域拼法、DNS 設定和 Host 對應；連線逾時時，檢查實際目的 IP、策略路徑及目標服務；出現明確拒絕時，確認是 REJECT 規則造成，還是目標回覆拒絕。App 傳回的業務錯誤不一定是網路錯誤；目標服務的登入狀態、請求權限和 API 條件也可能導致失敗。應先依據證據判斷，不要貿然修改網路設定。

如果頁面只有部分資源載入失敗，請逐一確認失敗請求使用的主機和策略，不要立刻將所有流量改成同一個方向。若同一網域在不同網路中的結果不同，請記錄解析結果和 IP 位址類型，再確認是否受到 IP 歸屬規則影響。若問題只在更新後出現，先比對更新前後的設定檔內容和伺服器選取，找出變更之處，再考慮新增修正規則。

第四步：將還原設定也納入測試

還原至已驗證的設定檔後，重複相同請求。若問題消失，表示這次設定變更值得優先檢查；若問題仍存在，就繼續檢查網路、伺服器和目標本身。還原不是直接判定設定檔無效，而是控制變因的實驗。每次測試只保留一項差異，並記錄預期和實際結果，後續修改才有依據，而不是因為一次偶然成功就繼續疊加設定。

回報問題時，提供介面模式、目標類型、規則片段、預期策略和實際命中結果即可。請移除完整訂閱連結、密碼、權杖與個人 IP，連線記錄中無關的網域也應刪除。保留第一條命中規則附近的必要上下文，比只截取單行規則更有幫助，因為順序問題通常來自前方涵蓋範圍較廣的規則，而非該行本身。

需要複習首次匯入、授權和連線流程時，請返回使用說明；需要集中查找簡短問答時，請前往常見問題；購買與正版資訊則請參閱App Store 正版驗證。本頁的查閱順序是先確認設定檔結構，再確認條件和順序，最後以實際連線驗證，不以規則數量取代可解釋性。