Shadowrocket 訂閱與伺服器管理手冊

先區分訂閱、伺服器與 Config

三類對象各自解決不同問題

開始操作前，先分清 Shadowrocket 中經常同時出現的三類對象。伺服器項目是一組可直接建立連線的參數，通常包含協定類型、伺服器位址、連接埠、驗證資訊與傳輸選項。訂閱是一個更新入口，App 讀取後可產生一組伺服器項目；適合維護由同一份既有資料衍生出的多部伺服器。Config 則負責規則、策略與 DNS 等行為，決定請求應符合哪條規則，以及符合後交由 PROXY、DIRECT 或其他策略處理。伺服器能否連線與流量如何分配是兩個層面，不能用更換 Config 取代修正錯誤的連接埠，也不能靠重複重新整理訂閱修復不適用的規則。

在 Home 中看到的伺服器列表，是日常選擇連線目標的位置；Subscribe 用於儲存與更新訂閱；Add Server 用於新增單一伺服器；Config 用於選擇或編輯規則設定；Global Routing 決定目前採用設定、代理或直連模式。iPhone 與 iPad 上的介面排列可能不同，但這些英文名稱代表的功能關係不變。若入口位置與本文略有差異，應依目前 App 內可見的同名項目查找，而不是按螢幕座標機械式點選。

新增前先保留原始資料

無論使用 Subscribe 或 Add Server，都應先保存一份未改寫的原始資料。對於訂閱，至少記錄用途、完整網址與最近一次確認可用的狀態；對於單一伺服器，至少記錄協定名稱、主機、連接埠、驗證欄位、TLS 狀態、傳輸方式與備註。不要只依賴截圖，因為長網址、大小寫、路徑與查詢參數容易在截圖中被截斷。也不要在新增前自行刪除看似多餘的字元：URL 中的斜線、問號、井號與百分號可能具有結構意義，修改後仍能儲存不代表含義未變。

建議先用少量項目完成驗證，再擴展到完整列表。驗證順序為：確認裝置時間與網路正常，新增一部伺服器或一條訂閱，執行連線測試，選擇目標項目，最後檢查 Global Routing 與 Config。這樣出現問題時，變數較少，能判斷錯誤是在原始參數、訂閱解析、伺服器連線還是規則分流層。若尚未核對 App 來源，可先查看App Store 正版核驗說明；Shadowrocket 的開發者為 Shadow Launch Technology Limited，App ID 為 932747118。

Subscribe 新增與更新策略

新增訂閱時先核對網址完整性

在 Shadowrocket 中進入 Subscribe 後新增項目，通常需要填寫訂閱網址，也可依介面提供的欄位設定名稱或更新行為。貼上前先檢查網址頭尾是否含有空格或換行。聊天工具、電子郵件與網頁在複製長文字時，可能一併選取句末標點，也可能只複製螢幕上顯示的省略版本。正確做法是從已保存的原始資料複製完整內容，貼上後將游標移到開頭與結尾核對，不要只憑肉眼查看中間的網域部分。

名稱應描述用途或範圍，而不是寫成「訂閱一」「新訂閱」這類日後難以辨識的文字。名稱只用於本機整理，不會修復網址內容。若重複新增同一網址，更新後可能出現看似相同的伺服器群組，增加選擇與排錯的干擾。因此新增前應先查看 Subscribe 列表，確認是否已有用途、網域與路徑均相同的項目。網址中的驗證參數即使只差一個字元，也應視為不同資料，不宜手動合併猜測。

名稱：工作日常
地址：https://example.com/sub?token=xxxx
更新前檢查：
1. 開頭為 https://
2. 結尾沒有空格、句號或換行
3. token 參數完整
4. 未重複保存同一地址

手動更新、自動更新與失敗保留

訂閱更新的本質，是 App 重新讀取遠端內容，並據此調整該訂閱關聯的伺服器項目。日常維護時，先使用手動更新觀察結果較穩妥：更新後查看伺服器數量是否明顯異常、原有備註是否變更、目前選取的項目是否仍存在，並重新測試準備使用的項目。自動更新適合資料維護已穩定的情況，但不應將更新頻率設得過密。過於頻繁的請求不會提高連線品質，反而可能讓列表在排錯過程中持續變動，使同一問題失去一致的重現條件。

一次更新失敗時，不要立即刪除訂閱或連續反覆點選。先判斷失敗發生在哪一層：如果瀏覽器連一般網頁也不正常，應先恢復目前網路；如果只有該訂閱更新失敗，應核對網址是否被截斷、裝置時間是否正確，以及網址中的驗證內容是否變更；如果更新顯示成功但伺服器列表為空，則需回到原始資料，核對回傳內容是否仍符合 App 可解析的格式。一次失敗不等於本機既有項目全部失效，刪除前應先確認現有項目是否仍可測試與連線。

更新完成後，應將「重新整理成功」與「伺服器可用」分開判斷。重新整理成功只表示 App 已取得並處理資料，不代表每部伺服器都能建立連線；反過來，某部伺服器逾時也不一定表示訂閱網址錯誤。先在 Subscribe 確認更新狀態，再到伺服器列表執行 Connectivity Test，最後在選取項目後進行實際連線驗證。分層檢查可避免將連線故障誤判為訂閱故障。

更新前後的可控變更

訂閱管理的常見難點之一，是更新會覆蓋由該訂閱產生的內容。若直接修改訂閱項目下的伺服器名稱或欄位，下次重新整理後，這些本機修改可能被遠端資料取代。需要長期保留的個人備註，應優先放在獨立記錄中；需要實驗的參數，應複製成單獨的手動新增伺服器後再修改，並在名稱中標示「測試副本」。如此訂閱仍保持原樣，實驗結果也不會被下一次更新打斷。

若更新後出現大量重複項目，先不要逐項刪除。應先判斷是同一訂閱重複新增、多個訂閱包含相同伺服器，還是遠端備註變更導致視覺上相似。前兩種情況應從 Subscribe 層整理，後一種情況則要比較協定、主機、連接埠與驗證欄位。關於重複項目的系統化處理，可繼續閱讀多訂閱整理章節；若頁面提示難以判斷，可在疑難排解中按「訂閱與節點匯入」分類查閱。

Add Server 手動填寫欄位與核對順序

先選擇協定，再對應欄位

Add Server 適用於已持有單一伺服器完整參數，且希望逐項新增或建立獨立測試副本的情況。第一步不是填寫位址，而是選擇正確的協定類型。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 與 Hysteria2 的驗證模型不同；欄位名稱偶爾相似，含義也不能互換。選錯類型後，介面仍可能允許儲存，但連線階段會因握手、驗證或傳輸結構不相符而失敗。

填寫時建議遵循固定順序：協定類型、伺服器位址、連接埠、驗證欄位、TLS 或加密相關選項、傳輸方式、路徑與 Host、備註。每填完一組就回到原始資料逐字核對。伺服器位址可以是網域或 IP 位址，應原樣填寫，不要新增協定前綴，也不要把連接埠重複接在位址欄位中。連接埠只填數字；名稱或備註可以自訂，但不要讓備註取代原始參數記錄。

驗證、TLS 與傳輸欄位不能自行猜測

驗證欄位通常區分大小寫。UUID 中的連字號、密碼中的符號、金鑰中的大小寫都屬於內容本身，不應自動改寫。複製後若連線失敗，可以先刪除欄位，再重新貼上一次，以排除不可見空格。對於 TLS、SNI、Host、Path、Transport 等欄位，應視為一組相互關聯的參數：原始資料明確提供時逐項對應，未提供時不要憑其他伺服器的經驗補值。尤其是 Host 與 SNI，雖然某些設定中內容可能相同，但兩者作用層次不同，不能因字元一致就任意替換。

Transport 選擇也必須與原始資料一致。選擇 WebSocket 等傳輸方式後，介面可能出現 Path、Host 等附加欄位；這些欄位只有在對應傳輸方式下才有意義。如果原始資料使用另一種傳輸，照搬其他項目的 Path 不會產生相容效果。編輯舊項目時，先確認協定與 Transport，再檢查附加欄位是否因切換選項而被保留。必要時建立測試副本，從空白狀態重新填寫，可排除舊欄位殘留造成的干擾。

儲存後的最小驗證閉環

完成填寫後先儲存，但不要立刻批量新增其餘項目。回到 Home，找到剛新增的伺服器，執行可用的 Connectivity Test 或延遲測試。測試有回應後，點選該項目使其成為目前伺服器，再檢查 Global Routing。首次驗證建議使用 Config，並確認目前 Config 中存在可理解的規則；若只想排除規則影響，可在明確測試目的後暫時比較 Proxy 與 Direct，但測試結束應恢復預期模式。Global Routing 的三種模式分別是設定、代理、直連，對應介面詞 Config、Proxy、Direct。

測試逾時時，依欄位順序反查，不要一次修改多個選項。先核對位址與連接埠，再核對驗證欄位，接著檢查 TLS、SNI 與 Transport，最後確認裝置時間與目前網路。每次只修改一項並重新測試，才能知道哪項變更真正產生影響。如果參數全部逐字一致仍無法連線，應保留原始項目與測試記錄，避免為了嘗試而覆蓋唯一一份正確資料。協定基礎欄位的進一步說明可參閱Shadowrocket 支援哪些協定。

Scan QR Code、剪貼簿與分享連結

掃描匯入前先確認 QR Code 內容

已有伺服器資訊被編碼為 QR Code 時，可以使用 Scan QR Code 讀取。QR Code 只是文字的另一種承載形式，本身不會提高參數正確性。掃描前應確認 QR Code 屬於目前要匯入的伺服器資料，並避免在公開環境展示含有驗證內容的 QR Code。辨識完成後，不要只因「匯入成功」就直接連線，應開啟新項目檢查協定類型、伺服器位址、連接埠與備註是否符合預期。

若 QR Code 來自另一部個人裝置的螢幕，應適度提高螢幕亮度並保持鏡頭穩定；辨識困難時，優先使用原始分享文字，不要反覆裁切模糊圖片。QR Code 邊緣被截斷、圖片壓縮過度或中央被遮擋，都可能導致無法辨識。無法掃描屬於讀取層問題，不代表其中的伺服器參數無效。讀取成功但測試失敗，則應轉到參數層核對，尤其注意協定類型、驗證內容與 Transport 附加欄位。

剪貼簿匯入要處理空格與多行文字

從剪貼簿匯入適合處理單一分享連結或 App 可辨識的結構化文字。複製時應從方案識別符開始選取至最後一個字元，避免前後混入說明文字。若一段訊息同時包含標題、序號與多條連結，建議逐條複製，不要依賴 App 自行猜測哪一行屬於有效資料。匯入後立即清理剪貼簿也較穩妥，因為分享連結可能包含伺服器位址與驗證資訊。

部分文字工具會自動換行長連結。視覺上的換行不一定是真實換行，但從富文字複製時可能插入空格或換行字元。若出現「可以辨識協定但無法連線」，應將連結貼到可信的本機純文字編輯區檢查結構，再與原始資料對照。不要透過刪除中間字元來試錯；查詢參數與編碼字元遺失後，連結可能仍能被辨識，卻產生不完整的伺服器項目。

分享連結是參數容器，不是長期備份格式

常見分享文字會以前綴表示協定類型，後續部分承載位址、連接埠、驗證與備註。不同協定的結構並不相同，不能將一種協定的連結前綴改成另一種協定來完成轉換。以下僅展示結構辨識方式，內容均為不可用範例。實際操作必須使用自己已持有的完整資料。

ss://[email protected]:443#Example
vmess://ENCODED-DEMO-DATA
vless://[email protected]:443?type=ws&security=tls#Example
trojan://[email protected]:443?security=tls#Example
hysteria2://[email protected]:443?insecure=0#Example

連結末尾的備註通常用於顯示名稱，經過百分號編碼後可能不易閱讀；這不影響協定主體，但手動改寫時應避免破壞前面的查詢參數。若匯入結果中的備註亂碼，確認連線參數完整後，只修改本機名稱，不要同時改動位址或驗證欄位。對於 VMess 等採用整體編碼的形式，不宜手動拆分後重新拼接；較穩妥的做法是使用原始連結匯入，再在伺服器詳細資料頁核對各欄位。

分享連結適合在受控範圍內，從一部個人裝置轉移到另一部個人裝置，但不適合作為唯一備份。它可能遺漏 App 中的本機備註、排序、Config 與其他管理資訊，也可能因複製不完整而失效。長期保存時，應同時保留原始參數說明、訂閱網址記錄與 Config 檔案，並註明各自用途。若要將單一項目交給另一部個人裝置，產生或顯示 QR Code 時應注意周遭環境，使用後及時關閉顯示頁面。

多訂閱分組、命名與重複項目整理

先按來源邊界管理，再按用途命名

當 Subscribe 中只有一兩項時，預設名稱似乎也能使用；數量增加後，含義不清的名稱會直接影響更新與排錯。建議名稱至少表達用途、裝置情境或資料邊界，例如「日常主組」「臨時測試」「舊設定核對」。不要把伺服器地區、協定與訂閱用途全部塞進一個過長名稱，詳細資訊可保存在獨立記錄中。名稱的目標，是讓你在更新前知道這次操作會影響哪一組伺服器。

整理時應以訂閱作為管理邊界，不要先在混合伺服器列表中逐項移動。先開啟 Subscribe，確認每一項的網址、名稱與最近一次手動更新結果；再回到伺服器列表查看各組產生的項目。若某條訂閱已不再使用，可以先停用其更新行為或記錄狀態，經過一段時間確認後再刪除。直接刪除會讓關聯項目與歷史判斷依據同時消失，不利於區分「確實不再需要」與「暫時更新失敗」。

重複項目需要比較關鍵欄位

顯示名稱相同不一定代表伺服器完全相同。判斷重複時至少比較協定、伺服器位址、連接埠與驗證識別；涉及 TLS 或 Transport 時，還應比較 SNI、Host、Path 與相關選項。只有這些關鍵欄位一致，才可將它們視為連線意義上的重複項。相反地，名稱不同但關鍵欄位一致，可能只是不同訂閱為同一部伺服器設定了不同備註。

發現重複後，先追溯它們分別屬於哪條訂閱。若由同一訂閱重複新增造成，應保留網址正確、更新正常的一項，再移除重複的 Subscribe 記錄；若來自不同訂閱，應依日常維護邊界決定保留方式，而不是盲目刪除所有同址項目。不同訂閱中的同一部伺服器，後續更新時可能走向不同；今天重複不代表未來始終重複。若只是想讓 Home 更易閱讀，可以透過清晰命名、排序與減少失效群組改善，不必為追求零重複而破壞訂閱結構。

建立穩定的整理節奏

多訂閱管理不需要每天重新排序。更實用的節奏是：新增時命名並手動更新，更新後抽查主要項目，出現異常時保留測試記錄，確認失效後再刪除。排序有助於日常選擇，但排序結果不是伺服器品質的永久結論；網路環境、測試目標與時間變化都會改變延遲。若每次測試後都大幅重新排序，反而會讓熟悉的位置不斷變動。

建議保留一份簡短的本機清單，記錄訂閱名稱、用途、是否自動更新、最近一次人工核對結果與關聯 Config。清單不必複製完整驗證資訊，只用於說明管理關係。對於需要實驗的新訂閱，可先放在獨立名稱下，完成更新、抽查與實際連線後再納入日常群組。如此即使實驗資料存在重複或欄位異常，也不會立即打亂穩定列表。

批量整理前應暫時避免同時修改 Config。伺服器列表與規則同時變動後，連線異常很難判斷來自哪一層。先讓訂閱與伺服器項目穩定，再檢查 Global Routing 和 Config；或者先固定伺服器，再單獨測試規則。多訂閱整理的目標不是讓列表看起來最短，而是讓每筆記錄的來源邊界、更新方式與用途都能再次理解。

Connectivity Test、延遲排序與故障定位

測試結果只反映目前測試條件

Connectivity Test 與伺服器列表中的延遲測試，用於快速判斷目前裝置、目前網路與目前時間能否與目標建立相應測試連線。結果適合篩選明顯逾時的項目，也可輔助排序，但不能代表所有 App 流量的長期表現。測試目標、協定握手、網路壅塞與無線訊號都會影響結果，因此一次較低的數值不等於永久更穩定，一次逾時也不應立即作為刪除依據。

進行批量測試前，先確保裝置沒有處於網路切換狀態。若裝置正從行動網路切換到無線網路，或無線網路剛完成重新連線，批量測試容易出現整組逾時。等待網路穩定後再測，並盡量讓螢幕保持在前景。第一次結果異常時，可以間隔片刻進行第二次測試；若只有少數項目持續逾時，再進入單項參數檢查。

按範圍判斷故障層級

測試結果最有價值的資訊不是單一數字，而是失敗範圍。全部伺服器同時逾時，優先檢查目前網路、系統時間與 Shadowrocket 的連線狀態；同一訂閱下全部逾時，而其他訂閱正常，應檢查該訂閱更新後的共同欄位或資料狀態；只有單一伺服器逾時，則優先核對該項目的位址、連接埠、驗證與傳輸參數。若測試有回應但目標內容無法開啟，應繼續檢查目前選取的伺服器、Global Routing、Config 規則與 DNS，而不是重複編輯訂閱網址。

排序用於選擇，不取代驗證

按延遲排序後，列表會將本次測試回應較快的項目置於前方。排序適合從大量既有伺服器中縮小候選範圍，但連線前仍需確認協定參數與用途。部分項目可能測試回應較快，卻不適合目前 Config 的使用方式；也可能因短暫抖動而在兩次排序中位置變化。建議先按延遲篩出少量候選，再逐一進行實際連線驗證，而不是每次都預設選擇第一項。

對多訂閱列表執行批量測試時，可以分組進行，避免一次出現過多結果而難以觀察。記錄持續逾時的項目後，先檢查它們是否共用同一位址、協定或訂閱；共同特徵往往比單項數值更能說明問題。確認某項長期失效前，應至少在網路穩定時重新測試，並核對最近一次訂閱更新是否成功。刪除是最後一步，不應作為第一次逾時的即時處理。

連線成功但分流結果不符時

如果伺服器測試正常，總開關也已連線，但某個網域的去向與預期不同，問題通常位於規則層。先確認 Global Routing 目前是否為 Config；若處於 Proxy，規則列表不會依 Config 模式決定每個請求；若處於 Direct，伺服器項目不會承擔目前流量。處於 Config 後，檢查規則由上到下的匹配順序，確認更具體的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等規則是否被較早的寬泛規則覆蓋，並檢查 FINAL 的最終去向。

若所有網域都表現異常，還應檢查 Config 是否選中了預期檔案，以及設定中引用的策略名稱是否存在。規則寫著 PROXY，但設定中對應策略沒有可用伺服器時，規則語法正確也無法得到預期結果。連線失敗的完整排查順序可參閱伺服器逾時與連線失敗檢查清單；首次連線的最短驗證流程可參閱首次連線教學。

刪除、備份、復原與裝置移轉

刪除前判斷對象層級

Shadowrocket 中可刪除的對象可能是單一伺服器、整條 Subscribe 記錄或一個 Config，影響範圍各不相同。刪除單一手動新增的伺服器只會影響該筆本機記錄；刪除由訂閱產生的項目後，後續更新可能再次產生；刪除 Subscribe 則會失去該組資料的更新入口；刪除 Config 會影響規則選擇，但不會自動刪除伺服器。執行前先確認目前位於哪個列表，並查看名稱、位址與關聯用途。

對於暫時逾時的項目，建議先標記或記錄，不要立即刪除。對於準備移除的訂閱，應先保存完整網址與用途說明，再確認其他訂閱沒有依賴同一管理安排。對於準備刪除的 Config，應先檢查目前是否正在使用，以及是否存在本機修改。刪除完成後若發現判斷錯誤，只有在保留原始資料的前提下才能準確復原；依靠記憶重新填寫長網址或複雜規則，容易產生新的錯誤。

備份應涵蓋四類資料

完整的管理備份至少包含四類內容：訂閱網址記錄、手動新增的伺服器參數、Config 檔案，以及用於說明這些資料關係的簡短清單。只保存訂閱網址無法涵蓋獨立新增的項目，只匯出 Config 也不會自動包含全部伺服器驗證資訊。備份前應清點 Home、Subscribe、Config 與 Settings 中與移轉相關的可見項目，依對象分別處理。

若目前 App 介面提供 Data、Import from Cloud JSON 或相應的匯入匯出入口，應先閱讀介面提示，確認其處理的資料範圍。不要將「能夠匯入某種 JSON」理解為所有設定都會自動復原。完成匯出後，應在不覆蓋現有資料的前提下檢查檔案是否產生、名稱是否易於辨識，並記錄匯出時的用途。備份檔案與訂閱網址都可能包含敏感內容，應放在受控的個人儲存位置。

更換裝置時依序復原

在新 iPhone 或 iPad 上復原時，應先透過 App Store 的已購記錄取得 Shadowrocket，再逐層復原資料。購買與已購復原方式可查看換機與復原購買說明。系統需求一律以 App Store 頁面標示為準。App 準備完成後，先匯入一個 Config 或保留預設狀態，再復原一條訂閱並手動更新，接著測試一部伺服器。確認基本鏈路正常後，再加入其餘訂閱與手動新增的項目。

不要在首次開啟後一次匯入全部資料，並立即覆蓋現有內容。分批復原可讓錯誤維持在較小範圍：訂閱無法更新時，只需檢查該訂閱；伺服器無法測試時，只需核對該項參數；分流不符時，再檢查 Config。若使用 Import from Cloud JSON，匯入完成後也應逐項抽查，不能只查看項目數量。名稱、排序與目前選取狀態可能與舊裝置不同，這些差異不一定代表參數遺失。

復原完成後進行三輪檢查。第一輪檢查 Subscribe 是否可以手動更新；第二輪檢查主要伺服器的 Connectivity Test 與實際連線；第三輪檢查 Global Routing 為 Config 時，常用網域是否依規則進入預期策略。接著再檢查 On Demand 等自動連線行為，避免在基本連線尚未確認時引入額外變數。舊裝置上的資料應保留到新裝置完成穩定驗證後，再依個人資料管理計畫處理。

建立可復原，而不只是可收藏的記錄

有效備份的判斷標準不是「檔案存在」，而是能說明如何復原。為每份 Config 寫明用途，為每條 Subscribe 記錄寫明對應名稱，為手動新增的伺服器保存欄位清單，並記錄復原後的驗證步驟。若只收藏一個沒有說明的長連結，數月後很難判斷它應放入 Subscribe，還是作為單一伺服器匯入，也難以確認是否仍屬於目前使用範圍。

設定完成重要調整後，應重新保存副本，但不必用大量相近檔案覆蓋儲存空間。可保留「目前穩定」「修改前」「實驗中」三類狀態，並避免在檔名中放入驗證內容。實驗成功後，將確認過的版本設為目前穩定；實驗失敗則回到修改前副本。這種版本區分是個人資料管理方式，不依賴 App 顯示的版本，也不會因介面調整而失去意義。

Config、Global Routing 與規則分流

理解三種 Global Routing 模式

伺服器管理最終需要與流量策略配合。Global Routing 中的設定、代理、直連分別對應 Config、Proxy、Direct。Config 依目前設定檔中的規則逐條判斷；Proxy 將請求統一交給目前的代理策略；Direct 讓請求直接連線。日常使用規則分流時應選擇 Config。Proxy 與 Direct 更適合用於有明確目的的對照測試，例如判斷異常是否來自規則層；測試結束後應恢復預期模式。

規則依由上到下的首次匹配處理

Config 中的規則通常依書寫順序處理。請求符合某條規則後，就執行該條指定的策略，不再繼續尋找後面的規則。因此更具體的規則應放在更寬泛的規則之前。例如單一 DOMAIN 規則應位於涵蓋範圍更大的 DOMAIN-SUFFIX 之前，區域網路 IP-CIDR 規則應位於 FINAL 之前。FINAL 負責接住前面未匹配的請求，通常放在規則列表末尾。

DOMAIN 精確匹配完整網域；DOMAIN-SUFFIX 依網域後綴匹配；DOMAIN-KEYWORD 依網域中的關鍵字匹配，範圍通常更廣；GEOIP 依目標 IP 的地理資料庫結果判斷；IP-CIDR 與 IP-CIDR6 分別用於位址網段；USER-AGENT 依請求識別匹配。規則右側的 PROXY、DIRECT 或 REJECT 是處理策略，不是伺服器協定名稱。PROXY 需要能解析到可用策略或伺服器，DIRECT 表示直接連線，REJECT 表示拒絕請求。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,apple.com,DIRECT
DOMAIN-KEYWORD,media,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fe80::/10,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

範例展示的是語法關係，不代表適合所有網路環境。實際 Config 應依自己的使用目標與既有設定核對。修改前先複製一份原始檔案，修改後每次只調整少量規則。若同時移動大量規則、改寫策略名稱並更換 DNS，出現異常時幾乎無法定位。可以先增加一條具體 DOMAIN 規則驗證匹配，再逐步擴展到 DOMAIN-SUFFIX 或其他範圍更大的類型。

伺服器名稱、策略名稱與規則目標要相互對應

規則末尾寫入 PROXY，不代表任意伺服器都會自動可用。Config 中的策略名稱需要與實際存在的策略結構對應，策略內部還要能選到有效伺服器。若訂閱更新後某些伺服器名稱變更，手動引用特定名稱的策略可能需要重新檢查。較穩定的做法是讓規則指向清楚的策略名稱，再由策略管理伺服器選擇，而不是在大量規則中分散寫入特定伺服器名稱。

遇到「Connectivity Test 正常但規則不生效」時，依以下順序檢查：Global Routing 是否為 Config；目前選取的 Config 是否正確；目標網域是否被較早的規則匹配；規則末尾的策略名稱是否存在；該策略內是否有可用伺服器；FINAL 是否過早出現。可以暫時增加一條範圍很小的 DOMAIN 規則進行驗證，確認後再決定是否擴展。排查期間不要同時重新整理所有訂閱，避免伺服器列表變動干擾規則測試。

Config 的修改、匯入與回退

修改 Config 前應保留原始副本，並為測試副本設定易於辨識的名稱。匯入新的設定檔後，先檢查分區名稱、規則段與 FINAL，再選擇少量已知網域進行測試。不要只因檔案能夠匯入，就認為所有策略引用都有效；語法可讀取與策略可執行是兩項不同檢查。若 App 提示某個策略名稱無法解析，應回到設定內容確認拼寫與對應群組。

規則除錯應保留回退路徑。每次修改前記錄目前穩定副本，修改一組規則後立即測試，並寫明修改目的。若結果不符，復原上一份穩定副本，而不是繼續疊加臨時規則。對於來源不同的 Config，不建議直接將兩個完整檔案首尾拼接，因為相同分區、同名策略、重複 FINAL 與不同 DNS 設定可能互相覆蓋。需要合併時，應逐段理解後處理，並在每個階段驗證。

完成伺服器與 Config 管理後，日常維護可以收斂為固定流程：依需要更新 Subscribe，抽查主要伺服器，保持清晰命名，使用 Config 模式連線，出現異常時按網路、訂閱、伺服器、規則四層定位，重要調整前保存副本。只想查看首次連線步驟時，返回Shadowrocket 使用教學；需要集中查看問題分類時，進入疑難排解。