SETTINGS REFERENCE · 官方手冊

Shadowrocket 設定詳解Settings 參數參考

先確認設定適用範圍，再決定是否修改。依章節查閱參數說明、核對預設狀態的方法、建議值與還原方式。

本頁供系統性查閱，不取代首次連線流程。若尚未完成匯入與連線，請先閱讀使用說明；完成後再回到本頁檢查設定。以下操作均以使用者已有自己的訂閱或伺服器資料為前提。

預設值以目前 App 顯示為準每次只修改一類設定 App Store 正版核對

01 / SCOPE

設定範圍、預設狀態與修改順序

Shadowrocket 的執行結果由多層資訊共同決定：系統網路影響能否連線至伺服器，伺服器項目決定連線參數，Config 決定規則與相關設定，Global Routing 決定目前採用的分流模式，Settings 則提供 App 層級的選項。遇到請求失敗時，不能只憑某個開關的位置判斷原因；應先確認問題發生在哪一層，再前往相應位置檢查。

區分 App 設定、Config 與伺服器參數

Settings 中的選項不等於目前 Config 的全部內容。某些行為也取決於目前使用的 Config、協定功能及系統權限。即使不同位置出現名稱相同或相近的選項，也不能假設它們一定會互相覆蓋。先記下目前的 Config 名稱、伺服器名稱與 Global Routing 選項，再開啟設定詳細資料核對說明；需要比較時，請以目前 App 實際顯示的欄位為準。

伺服器資訊通常包含位址、連接埠、驗證資料及協定專屬欄位。這些是連線端點資料，不應為了改變分流結果而任意修改。Config 中的規則則用來判斷請求應交由哪種策略處理。將伺服器連接埠改成本機 Proxy 連接埠，或將訂閱網址當成 Config 網址使用，都會混淆資料類型；即使 App 允許儲存，也不代表能建立有效連線。

設定頁的名稱與排序可能因目前 App 介面而異。本手冊保留 DNS、On Demand、Ping、Log 等英文原名，但不會把未經確認的初始狀態描述成統一的預設值。已使用過的裝置也可能保留先前修改或同步狀態，因此「目前顯示值」與「首次安裝時的預設值」並不相同。排查時記錄實際值，比憑印象還原所謂的預設設定更可靠。

不知道預設值時，如何選擇建議值

本頁的一般建議是保留已驗證可正常運作的設定，只針對明確問題修改必要欄位。伺服器提供的協定參數，建議逐項與使用者已有資料核對一致；按需連線、同步與本機監聽等選用功能，則建議先確認用途及適用範圍，再決定是否啟用。建議值不是所有使用者都該照抄的一組數字，而是能說明原因並重複驗證的選擇。

設定來源	核對預設狀態	建議處理方式
Settings	以目前 App 顯示為準	先記錄，再逐項修改
Config	檢查目前選取的檔案	保留可還原的副本
Add Server	依項目與協定而定	與現有伺服器資料一致
系統權限	在系統設定中核對	依系統提示確認實際授權

修改前先簡要記錄，至少包括網路類型、能否連線、失敗的目標與現有設定。記錄中不要保存明文密碼或完整訂閱網址。若問題只發生在特定 Wi-Fi 網路，先改用另一個可用網路重新測試；若只有一個目標失敗，先檢查匹配規則。如此可區分整體故障與局部問題，避免用影響所有請求的選項處理單一問題。

建立可還原的操作流程

每次只變更一類變數，並使用相同目標重新測試。例如測試 DNS 時，暫時維持伺服器、路由模式與規則不變；測試伺服器參數時，不要同時更新 Config。每次修改後確認是否成功儲存，必要時先中斷再重新連線，讓新的執行狀態重新建立。若結果變差，先還原剛才記錄的值，不要繼續疊加多項尚未驗證的修改。

備份內容應涵蓋實際需要還原的資料。只儲存 Config，不代表伺服器驗證資料也已備份；保留伺服器項目，也不代表所有規則都已保留。對於可匯出或複製的內容，先確認目前 App 提供的操作方式及輸出範圍，再儲存至自己能掌控的位置。備份檔可能包含敏感資訊，不要為了尋求協助而直接公開；同步功能也不能取代獨立且經過核對的備份。

還原時也應由近到遠依序處理：先復原最近一次修改，再確認是否選取了正確 Config，接著檢查伺服器與本機網路。不要一開始就刪除所有資料。若確實需要重新整理，請先確認備份可以讀取、重要資料齊全，並記下購買帳號對應的 App Store 狀態。設定手冊的目標是讓每次變更都有依據，而不是讓所有選項都呈現某種看似整齊的狀態。

02 / ROUTING

Global Routing：Config、Proxy 與 Direct

Global Routing 決定目前請求採用哪種整體處理方式。設定、代理、直連分別對應介面中的 Config、Proxy、Direct。日常依規則分流時，建議使用已核對的 Config；Proxy 與 Direct 可用於短時間比對，但不能取代伺服器參數修正，也無法證明所有 App 流量都具有相同的網路條件。

先確認模式，再解讀規則結果

Config 表示依照目前 Config 中的規則處理請求。這要求 Config 本身可用、已選取，且規則所引用的策略能正確解析。只將檔案匯入清單，不代表執行時正在使用該檔案。遇到「規則明明寫了卻沒有效果」時，先確認 Global Routing 是否確實設為 Config，再檢查目前選取的檔案名稱，最後才檢查某一行的拼字與順序。

Proxy 用於整體採用代理方向處理，Direct 則用於整體採用直連方向處理。這裡的「整體」是對路由模式的說明，不代表能絕對保證系統中每一種流量都如此處理。系統本身的連線、特殊網路限制及協定處理仍可能影響觀察結果。測試結束後，應恢復原本的 Config 模式，否則之後查看規則記錄時，可能會把模式差異誤判為規則失效。

介面原名	中文說明	建議用途
Config	設定	依已核對的規則進行日常分流
Proxy	代理	短時間比較代理方向是否可用
Direct	直連	短時間比較本機直連是否可用

目前選取的模式以 App 顯示為準，本手冊不推測新安裝裝置的預設選項。若切換後某個目標恢復連線，只能說明處理方向的變更影響了結果；還需搭配 DNS、規則匹配及伺服器連線繼續分析。不要立即長期將所有請求改為另一種模式，因為這可能同時改變原本正常的本機資源存取、網域解析路徑與連線出口。

依序理解規則匹配

常見規則會由上而下判斷，前面已匹配的規則會影響後續規則是否生效。DOMAIN 用於精確匹配網域，DOMAIN-SUFFIX 用於匹配網域後綴，DOMAIN-KEYWORD 用於匹配網域關鍵字；IP-CIDR 與 IP-CIDR6 則適用於位址範圍。選擇類型時應盡量精確，避免為了匹配單一目標而使用範圍過大的關鍵字，導致不相關請求也套用相同策略。

GEOIP 依據位址歸屬資料進行判斷，不等於辨識使用者所在地，也不保證涵蓋特定網站的所有資源。單一頁面可能同時請求多個網域及不同地區的位址，因此「主頁面走直連」不能推論「所有子資源都走直連」。若前面的規則都未處理，則由 FINAL 作為兜底。檢查最終行為時，也應記錄兜底策略，而非只看最顯眼的前幾行。

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

以上片段用來說明規則順序與策略寫法，並非適用所有情境的完整設定。example.com 僅為教學網域，PROXY 與 DIRECT 均保留規則關鍵字原文。請在現有 Config 的副本中核對相應章節，避免重複新增同名章節，或將片段當成伺服器資料匯入。儲存後重新確認選取的檔案，並透過 Log 檢查目標是否匹配預期規則。

從個別請求回推規則問題

排查時先選擇一個能穩定重現問題的目標，記下操作與時間，再查看對應請求的網域、位址及策略。若 Log 顯示匹配了不符合預期的上游規則，應調整該規則的範圍或順序；若請求始終落到 FINAL，則檢查目標是否與填寫的網域一致。重新導向、圖片資源與 API 網域各不相同，是「頁面網址正確但規則未匹配」的常見原因。

REJECT 表示拒絕匹配的請求，不代表能辨識頁面上的所有內容。將過寬的網域後綴交由 REJECT 處理，可能連登入、圖片或 API 一併封鎖。修改前先記錄原規則，修改後分別測試主要操作，不要只確認頁面能開啟。關於匹配範圍、誤擋與還原方式，請繼續閱讀REJECT 規則的寫法與適用範圍。

建議的還原方式是保留原始檔案，使用副本驗證單一規則，再依據 Log 決定是否合併。規則越多不代表分流就越精確；用途不明的重複規則反而會增加維護成本。測試完成後，重新核對 Global Routing、目前 Config 與選取的伺服器是否仍為預期組合，並將組合記入維護紀錄，作為下次排查的基準。

03 / NAME RESOLUTION

DNS：解析路徑、快取與位址差異

DNS 用來將網域解析為位址。連線失敗可能發生在解析前、解析過程中，也可能發生在取得位址之後；修改 DNS 只會影響其中一部分。建議先沿用目前已驗證正常的設定，並搭配 Config 檢查解析相關設定。預設值及可選方式以目前 App 顯示為準，不要把某個公用解析位址當成適用所有網路的固定答案。

先區分解析失敗與連線失敗

若請求未取得可用位址，應檢查解析服務是否可連線、網域是否有效，以及目前網路是否要求先完成登入驗證。若已取得位址但連線仍逾時，原因可能與規則方向、伺服器狀態或目標服務有關。僅憑瀏覽器顯示「無法開啟頁面」無法區分這些情況，需搭配 Log 中相近時間的解析與連線資訊，確認失敗發生在哪個階段。

網域的解析路徑與後續連線路徑彼此相關，但並非同一件事。請求最後使用 PROXY，不代表所有解析步驟必然採用相同的傳輸方向；請求使用 DIRECT，也不能只憑策略名稱推斷解析器來源。實際行為仍取決於目前 Config 與 App 選項。檢查時請分別記錄「由哪裡解析」與「連到哪裡」，避免把兩個問題混成一個模糊的開關判斷。

DNS 設定可能同時涉及 App 選項與 Config 內容。先開啟目前使用的 Config，核對其中與解析相關的項目，再查看 Settings 中可用的 DNS 選項及說明。不要在多個位置同時填入不同值，再憑結果猜測優先順序。若不同來源之間有衝突，請在 Config 副本中逐項簡化、重新連線並測試，直到確認是哪項變更影響結果。

選擇解析方式並驗證快取

一般 DNS 與加密解析方式具有不同的傳輸條件。加密傳輸可以改變解析請求在傳輸路徑上的保護方式，但不會自動讓解析更快、更準確，或保證在目前網路中可連線。若目前 App 允許填寫解析服務，應核對完整格式、協定支援與實際可連線性。建議優先保留運作正常的方式，只有在需求明確且能驗證時才更換。

快取可能讓修改後的結果看起來毫無變化。快取可能存在於 App、系統、瀏覽器或目標服務的處理流程中，因此重新整理一次不一定會重新進行所有解析。測試時可先關閉舊頁面或結束舊連線，再依目前 App 提供的方式處理快取，必要時重新連線。不要只為了清除一次快取就刪除整份 Config，也不要把偶然恢復歸因於尚未驗證的參數修改。

IPv4 與 IPv6 也會影響觀察結果。同一網域可能同時有這兩類位址記錄，而本機網路對兩種連線的支援程度不一定相同。若只有部分目標異常，請查看實際使用的位址類型及失敗階段。建議先確認網路與伺服器是否支援目前路徑，再考慮相關選項；直接停用某個位址族或許能暫時避開問題，但不代表根本原因已解決。

區域網路名稱與登入驗證

存取家用裝置、辦公資源或只存在於特定網路中的名稱時，本機解析環境可能無法取代。將所有網域都交給同一個外部解析路徑，可能讓這些名稱失去原本的解析條件。排查這類問題時，先確認裝置連上正確的區域網路，再比較 Direct 與 Config 的結果，並檢查該資源是否需要特定網域、位址範圍或存取權限。

需要網頁登入驗證的 Wi-Fi 網路，應先完成連線流程，再測試代理連線。若系統尚未取得正常的網路存取能力，修改 DNS 或反覆切換伺服器通常只會增加變數。可先確認系統是否顯示登入頁面，並以已知可用的一般瀏覽動作檢查網路。完成驗證後再恢復原本設定並重新建立連線，避免將驗證前與驗證後的失敗 Log 混在一起。

不要為了確認 DNS 正常而直接用目標位址取代網域進行存取。使用加密連線的網站通常仰賴網域進行憑證驗證與服務選擇，直接存取位址可能產生另一種錯誤。較可靠的方式是先查看解析是否有結果，再保留原網域檢查連線。測試時也應記錄是否發生重新導向，因為後續網域可能採用不同的解析或規則路徑。

DNS 排查的最後一步，是還原成穩定且能說明原因的狀態：保留有效設定，撤銷缺乏證據支持的修改，並重新測試最初失敗的目標與原本正常的本機資源。若問題仍只集中在特定目標，應轉而檢查規則與目標服務；若所有網域都失敗，但既有連線暫時可用，則優先檢查解析鏈路。如此可避免反覆測試同一選項。

04 / CONNECTION LIFECYCLE

On Demand：觸發條件與連線生命週期

On Demand 會依據設定條件觸發連線，不是用來修改節點品質或規則優先順序的選項。建議先完成一次穩定的手動連線，再依實際使用情境設定按需行為。預設狀態、條件類型與具體動作以目前 App 顯示為準。啟用前，應能說明何時需要建立連線、何時應保持中斷，以及網路切換後應如何恢復。

先建立手動連線基準

先暫時不依賴自動觸發，在 Home 中確認選取的伺服器、Global Routing 與目前 Config，再手動啟用連線。若系統提示新增 VPN 設定，請核對來源並依系統流程確認。完成授權只代表系統允許建立相應連線，不代表伺服器資料正確，也不代表目標網站可連線；仍需實際存取並檢查 Log。

手動連線尚不穩定時，On Demand 只會自動重複不穩定的流程。應先解決驗證失敗、解析失敗或路由問題，再設定觸發條件。否則看到連線反覆建立與中斷，很容易誤以為按需功能本身故障。檢查順序應為網路可用、伺服器資料一致、手動連線正常、規則結果正確，最後再確認自動化條件是否如預期執行。

不要只靠系統狀態列圖示判斷連線品質。圖示或 App 開關可以提示連線狀態，但無法說明每個請求是否成功。驗證時應分別檢查連線是否建立、明確目標是否可用、Log 是否出現新請求，以及實際策略是否正確。分開記錄這些結果，才能區分「未觸發連線」與「已連線但存取失敗」。

條件設定與手動中斷的關係

若目前介面提供依網路類型或網路條件設定動作的選項，請逐項閱讀條件說明，並只填入自己確實會使用的網路。Wi-Fi 名稱相似不代表屬於相同的可信任環境，不能只憑名稱判斷安全性。建議先從少量、明確且容易重新測試的條件開始，不要一次新增大量重疊條件；條件間的匹配關係則以目前 App 顯示及實際測試為準。

手動中斷後又自動連線，通常需要回到 On Demand 檢查是否仍有有效觸發條件。只關閉一次連線開關，不一定代表已撤銷自動化規則。若要持續保持中斷，應先處理相關按需條件，再確認連線狀態。測試後還原日常設定時，也應同時核對條件與開關，避免只記得還原其中一項而留下非預期行為。

切換網路可能使既有連線中斷並重新建立。傳輸中的工作不一定能在新網路上繼續，因此短暫失敗不代表規則失效。可等網路恢復正常存取後再送出新請求，接著查看 Log 時間軸。若每次切換後都持續失敗，先手動重新建立連線，比較自動恢復與手動恢復的差異，再縮小排查範圍。

鎖定螢幕、背景執行與系統限制

App 未停留在前景，不代表連線一定停止；介面仍開啟，也不代表系統網路狀態始終不變。鎖定螢幕、網路變化與系統資源管理都可能影響觀察結果。建議依據可重複的具體情境測試，例如鎖定螢幕後重新開啟同一目標，並記錄是否需要重新連線。不要從單次背景執行的現象推論所有裝置都會有相同的固定行為。

耗電應綜合使用時間、傳輸量、訊號狀況與重新連線頻率判斷。持續傳輸、訊號較弱及頻繁重連都可能改變裝置耗電，不能只看 On Demand 是否啟用就下結論。比較時應盡量維持網路、伺服器與使用工作一致，並觀察較完整的使用過程；短時間切換多項設定後看到的電量變化，通常不足以找出原因。

若連線與其他系統網路設定互相影響，應先在系統設定中查看目前實際啟用的連線及管理限制。受管理的裝置可能有組織設定的限制，不應任意刪除設定來處理。建議在自己能掌控的範圍內進行比較測試，並保留原有設定紀錄；不熟悉的系統設定應先確認用途，再決定是否調整，以免影響原本必要的網路存取。

完成按需設定後，至少驗證三種狀態：正常啟動時可連線、網路變更後的行為符合預期，以及需要中斷時能維持預期狀態。任何一項不符預期，都應先簡化條件，而不是繼續新增補償規則。若只在固定時段使用，手動連線也能提供明確的操作方式；自動化的價值在於減少重複操作，而非增加難以解釋的狀態。

05 / DIAGNOSTICS

Ping、Connectivity Test 與 Log

Ping 與 Connectivity Test 用於觀察特定測試條件下的可達性，Log 則記錄實際執行過程。測試結果不能保證持續可用，也不是實際傳輸速度的直接測量。建議將測試結果作為排查線索：先確認測試對象與方式，再搭配實際存取及 Log 分析。測試方式、目標與預設選項以目前 App 顯示為準。

理解測試對象，不要只看數字

測試可能檢查伺服器連接埠是否可連線，也可能檢查經由代理存取特定目標的完整流程，兩種結果不能直接比較。前者成功，後續仍可能在驗證或目標連線階段失敗；後者失敗，也可能只是測試目標暫時無法連線。操作前請查看目前測試方式及其說明，不要把所有標示為延遲的數值都當成同一網路層級的往返時間。

測試耗時較短不代表下載速度較快。實際速度還會受到本機訊號、可用頻寬、伺服器負載、傳輸協定與目標服務限制影響。建議在相同網路、相同測試方式及相近時間內進行有限次比較，觀察結果是否穩定。不要只憑一次最快結果作為長期選擇依據，也不要因單次逾時就刪除項目；先確認相同現象能否重複發生。

測試前先確認選取了正確的伺服器項目，尤其是備註相似或項目重複時。訂閱更新可能改變項目清單，因此舊備註不能取代目前的參數核對。若清單中的測試成功，但實際啟用連線失敗，請記錄兩個操作的時間與對象，並檢查是否使用相同項目、相同路由模式及相同網路，而不是直接認定測試功能不準確。

用 Log 串連一次失敗請求

閱讀 Log 時，應以一次可重複的操作為單位，而不是檢視整頁資訊。先記下時間，再送出一個明確請求，接著查找相近時間的網域、位址、規則與錯誤資訊。實際提供哪些欄位，以目前 App 顯示為準。若 Log 很長，應減少測試動作；不要同時開啟多個頁面，否則背景請求與子資源會讓關鍵事件難以對應。

先確認失敗發生在哪個階段：網域是否解析、是否找到處理策略、是否連上伺服器、驗證是否通過，以及目標是否有回應。錯誤文字應保留原樣，不要把所有逾時都解讀成同一原因。逾時可能發生在不同層級，連線遭拒與驗證失敗也需要不同處理；應依據相鄰事件與具體對象判斷，而非只截取最後一行。

觀察到的現象	不能直接推論	下一步檢查
測試耗時較短	實際傳輸一定較快	維持條件一致，驗證實際工作
解析沒有結果	伺服器一定無法使用	先檢查 DNS 與本機網路
規則匹配正確	後續連線一定成功	繼續檢查連線與驗證階段
只有一個目標失敗	所有設定都已失效	檢查目標網域、規則與回應

Log 中出現位址或網域，不代表相關內容已成功傳輸。這可能只是解析、連線嘗試或規則匹配的紀錄。同樣地，沒看到預期的 Log，也不一定代表 App 沒有處理請求；可能是篩選條件、紀錄範圍，或請求根本未送出。建議先確認 Log 檢視畫面的篩選狀態，再透過一次新的明確存取操作，確認紀錄是否更新。

僅保留必要的診斷資料

尋求協助前，請移除密碼、驗證權杖、完整訂閱網址及可能辨識個人使用習慣的紀錄。伺服器位址、備註與存取網域也可能暴露敏感資訊，應只保留問題所需的最少內容。可以描述「同一網路下手動連線失敗，驗證階段出現錯誤」，並附上經過處理的少量相關記錄；不必公開整份 Config 與完整 Log，尤其不要直接傳送訂閱原文。

詳細紀錄可能增加儲存空間使用量與診斷雜訊，建議只在需要時依目前介面提供的方式啟用，排查完成後再恢復原狀。Log 層級與初始狀態以 App 顯示為準，不要為了追求「資訊越多越好」而長期保留所有細節。清除前先保留解決問題所需的片段，清除後再重新測試，以免把舊錯誤誤認為新的故障。

速度變慢時，依序檢查本機網路、協定參數、連線狀態與伺服器負載。每一層只替換一個條件，並記錄實際工作的變化。更完整的比較順序請參閱連線後速度變慢的分層排查。測試結果只能反映當下條件，不能據此推論未來的穩定性，也不應用來評價或推薦任何連線服務。

診斷結束後，應清楚記錄解決問題所需的條件：修改了哪個項目、原值為何、使用哪個目標驗證，以及是否在第二種網路重新測試。無效的修改應撤銷，臨時切換的 Global Routing 也應恢復。如此下次遇到相似現象時，就能從已知基準開始，而不必再進行一輪沒有紀錄的隨機調整；Log 的作用是減少變數，而非增加操作次數。

06 / CONFIGURATION DATA

Subscribe、Add Server 與 Config 的資料界線

Subscribe 用於管理使用者已有的訂閱資料，Add Server 用於新增伺服器項目，Config 則用於管理設定檔。三者彼此相關，但不能互相取代。建議先確認取得的資料屬於哪種類型，再選擇相應入口；不要只因內容看起來像網址，就使用相同的匯入方式。預設欄位與匯入選項以目前 App 顯示為準，伺服器參數則以使用者已有資料為準。

分別核對訂閱更新與執行中的設定

訂閱通常用於取得及更新一組伺服器項目，但不能因此假設其中一定包含完整的分流規則。匯入後先檢查實際結果：項目數量是否改變、備註是否符合預期，以及是否出現解析錯誤。接著分別確認 Config 中使用的檔案與 Global Routing。清單中有伺服器，只能代表已有連線資料，不代表規則已完成設定。

訂閱網址通常含有可辨識使用者的參數，應像密碼一樣妥善保存。複製時避免混入空格、換行或說明文字，貼上後也不要把完整網址放進備註。若更新失敗，先確認網址仍有效，再依目前網路環境檢查存取結果；不要為了測試而將網址提交至不明網頁。若不清楚更新機制或內容含義，請核對使用者現有服務資料中的說明。

更新前記下目前使用的項目，更新後檢查是否仍指向預期伺服器。項目可能新增、刪除或更名，原先的選取狀態也可能因此改變。建議保留能辨識項目的備註，但不要把密碼寫進名稱。遇到重複項目時，先核對來源與實際參數，再決定是否清理；名稱相同並不能證明是同一個連線端點。

Add Server 參數不能憑經驗猜測

手動新增時，位址、連接埠與驗證資訊必須符合現有資料。Shadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2 等協定的欄位各不相同，不能把某個協定的填寫方式直接套用至另一個協定。建議依目前選取的協定逐項檢查必填欄位，保留欄位英文原名，並對照資料確認其意義；若缺少參數，應先補齊資料，而非隨機嘗試。

傳輸方式、加密連線相關欄位與憑證名稱都可能影響交握結果。伺服器位址可連線，不代表這些欄位一定正確。不要為了避開錯誤而任意關閉憑證驗證，也不要把所有存取失敗都歸因於密碼。應先記錄原始錯誤，再確認網域、時間、驗證資料與協定要求是否一致。安全驗證失敗時，應找出原因，而非只求開關顯示已連線。

透過 QR Code 匯入後也需要檢查結果。Scan QR Code 可減少手動輸入，但不能取代參數核對；來源可信也不代表資料目前仍有效。匯入後檢查協定、位址、連接埠與備註，並確認沒有誤選其他項目，再嘗試連線。如果內容不是目前入口支援的資料類型，就應停止重複掃描，先確認它是伺服器資料、訂閱網址或其他設定內容。

Config 的編輯、選取與還原

編輯 Config 前先保留副本，並在副本中進行局部修改。一份設定可能包含通用設定、規則與其他章節，不要為了加入幾行規則就刪除原有內容。儲存後查看 App 是否提示格式問題，再確認執行時已選取這份檔案。檔案在清單中的位置、最近編輯時間或顯示名稱，都不能單獨證明目前正在使用；應以實際選取狀態為準。

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

範例只呈現規則語法，其中私有位址範圍也僅用於說明依位址匹配的方式。實際區域網路可能使用其他範圍，不能照抄後就認為已涵蓋所有本機資源。DOMAIN 與 DOMAIN-SUFFIX 的匹配範圍不同，FINAL 應視為兜底規則。建議先針對一個明確目標驗證，再擴大規則範圍；修改後也要檢查預期目標及相鄰功能，避免造成誤擋。

遠端 Config 更新可能帶來規則變更，因此本機編輯與遠端更新之間應明確分工。更新前確認哪些內容需要保留，更新後檢查重要規則是否仍然存在。不要將持續更新的來源與大量未記錄的本機修改混在一起，否則難以判斷變更來自何處。重要修改應記錄用途與驗證方式，並保留可還原至上一個可用狀態的副本。

同時使用多個訂閱時，建議依來源用途建立清楚的備註，先整理再清理。刪除訂閱及其產生項目的實際影響，以目前 App 的操作提示為準；確認前不要連續批次操作。更詳細的整理順序請參閱多個訂閱的分組、排序與重複項目處理。本手冊僅說明如何管理已有資料，不提供、不販售也不推薦節點或訂閱。

本章最後應確認三種資料各自歸位：Subscribe 能更新已有項目，Add Server 中的參數與資料一致，Config 已選取且能產生預期的規則結果。若其中一層失敗，先處理該層問題，不要反覆重新匯入所有內容。若要從頭完成主要操作流程，請返回快速使用說明，依照匯入、選取、連線與驗證的順序操作。

07 / CONTINUITY

Widget 是方便查看或觸發操作的系統入口，iCloud 相關功能則用於延續目前 App 支援範圍內的資料。兩者都不能取代主畫面中的實際狀態核對，也不能證明連線已成功。建議先在主 App 中完成驗證，再新增快速入口或設定同步流程。可用功能、同步範圍與預設狀態以目前 App 及系統顯示為準，不要假設所有資料都會同步。

分別驗證 Widget 顯示與實際連線

新增 Widget 時，請使用系統提供的小工具管理流程，查看目前裝置實際可選的 Shadowrocket 小工具及尺寸。小工具類型與互動方式以系統介面為準，不要根據其他裝置的版面推測。新增後先在主 App 確認連線狀態及選取的項目，再查看 Widget 顯示是否一致。若 Widget 沒有立即更新，先回到 App 檢查實際狀態，不要連續點擊以免多次切換連線。

系統可能會控制 Widget 的更新時機，因此顯示內容不一定每一刻都與主 App 完全同步。若 Widget 顯示異常，但主 App 可以正常連線，應先將問題限縮在顯示與更新層面檢查。建議透過一次明確的連線或中斷操作進行比較，並留出系統更新顯示所需的時間；反覆更換伺服器或刪除 Config，通常無法直接解決 Widget 本身的更新問題。

鎖定螢幕或桌面上顯示的備註可能洩露使用資訊。命名伺服器與 Config 時，應兼顧辨識與隱私，不要將完整位址、驗證資料或訂閱網址寫在容易顯示的位置。共用裝置也應考慮其他使用者是否能看見或觸發操作。建議使用可區分用途但不含敏感憑據的簡短名稱，並在新增 Widget 後檢查實際顯示內容，而不只查看 App 清單。

啟用 iCloud 同步前先確認資料範圍

啟用同步前，先檢查系統帳號、iCloud 可用狀態，以及目前 App 提供的相關選項。同步範圍需要逐項確認，不能把「已啟用 iCloud」理解成伺服器、Config、Log、連線狀態與所有偏好都已完整保存。建議先用一項不含敏感資料且容易辨識的修改驗證同步，再決定是否依賴同步整理多部裝置；預設狀態以目前 App 顯示為準。

同步是延續資料狀態的方式，不是歷史備份庫。一次誤刪或錯誤修改也可能影響其他裝置，因此重要內容仍應保留獨立副本。副本應註明用途與包含範圍，並存放在自己能掌控的位置。不要只因第二部裝置看得到檔名，就認定所有內容都已成功同步；應開啟並核對重要項目，再確認是否能用於實際連線。

多部裝置同時編輯，容易讓資料來源變得不清楚。建議先指定一部裝置完成整理，等其他裝置出現預期結果後再繼續操作。若出現同名副本或內容差異，應先分別保留，再比較重要欄位，不要立即刪除其中一份。比較時應著重規則順序、伺服器參數與備註對應關係，而非只看檔名；名稱相同不代表內容一致。

區分匯入檔案與持續同步

Import from Cloud JSON 應依目前 App 提供的入口與提示理解。從檔案匯入一次內容，不代表已建立持續同步；檔案成功讀取，也不代表所有欄位都適用於目前裝置。操作前先確認檔案類型與來源，完成後檢查實際新增或變更的內容。不要只憑副檔名猜測其中一定包含伺服器項目，更不要將來源不明的資料直接覆寫到可用的 Config。

系統網路授權通常需要在每部裝置上分別確認，不能因另一部裝置已允許連線，就推斷目前裝置也已完成授權。新裝置首次連線時，應依系統提示確認，並重新驗證本機網路、伺服器與規則。App 購買適用範圍及相容性以 App Store 頁面標示為準；同步內容可見與裝置符合執行條件，也需要分別確認。

若同步遲遲沒有結果，先檢查兩部裝置的系統帳號與網路狀態，再查看 App 內的相關選項，最後才判斷是否需要重新匯入。尚未保留副本前，不要關閉並清除雲端資料，也不要反覆開關同步碰運氣。每次只變更一個環節，並記錄另一部裝置實際出現的變化，才能判斷問題屬於傳輸延遲、同步範圍差異或內容衝突。

設定完成後，應將 Widget 與同步視為輔助入口，而非唯一控制介面。日常遇到異常時，仍應回到主 App 確認連線、Global Routing、目前 Config 與伺服器選項。定期檢查備份是否可讀、可見備註中是否包含敏感資訊，以及不再使用的副本是否需要整理。如此既能保有操作便利，也能維持清楚且可核對的裝置狀態。

08 / LOCAL LISTENING & REVIEW

Proxy 連接埠、本機監聽與設定複核

Proxy 相關連接埠描述的是特定代理服務的監聽位置，不能與遠端伺服器連接埠混為一談。是否提供 HTTP、SOCKS5 或其他本機監聽選項，以及其預設值與生效條件，均以目前 App 顯示為準。若沒有明確需求，建議保留現有設定，不要猜測固定連接埠，也不要為了改善速度而任意修改監聽參數。

區分遠端連接埠與本機監聽連接埠

Add Server 中的連接埠通常用於連線至使用者已有的遠端伺服器，必須與伺服器資料一致。本機 Proxy 連接埠則讓符合條件的請求連至本機提供的代理入口。兩者位於不同位置，修改本機連接埠不會改變遠端服務的監聽連接埠，也不會自動修正遠端驗證錯誤。排查前先確認正在編輯哪種連接埠，並一併記錄相應位址。

代理入口需要由位址、連接埠與協定共同構成，只知道連接埠數字不足以建立連線。使用 HTTP 連線至僅支援 SOCKS5 的入口，或將遠端位址與本機監聽連接埠混在一起，都可能導致連線失敗。建議嚴格依照目前 App 顯示的功能與實際需求進行設定，不要把網頁上常見的數字當成預設值，也不要以連接埠號碼大小判斷效能。

監聽位址會決定哪些來源可能存取入口。僅供本機使用的位址與供區域網路使用的位址，適用範圍不同；若目前介面提供相關選項，請先閱讀說明再決定。擴大開放範圍可能讓同一網路中的其他裝置嘗試連線，因此必須確認存取界線與驗證能力。若沒有明確的跨裝置需求，建議維持最低必要範圍，並在測試結束後取消臨時開放。

判斷生效條件、衝突與可達性

本機監聽能否使用，可能取決於 App 連線狀態、目前啟用的功能及系統網路條件。先確認 App 確實處於預期的執行狀態，再從需要使用代理的裝置檢查位址與協定。設定頁已儲存連接埠，不代表任何時候都在監聽；本機可用，也不代表其他裝置一定能連線。這兩種測試使用的是不同存取路徑。

若出現連接埠已占用或無法繫結的提示，先保存原始錯誤，並確認是否有其他服務使用相同的監聽位置。連接埠位於有效數字範圍內，不代表每個值都適合目前用途；系統限制與既有服務也可能影響繫結。建議依明確需求選擇可用值，修改後重新確認是否已儲存並生效，不要連續隨機輸入數字來掩蓋衝突原因。

區域網路存取也取決於裝置是否位於彼此可通訊的網路、Wi-Fi 是否隔離裝置，以及位址是否變動。訪客網路可能允許存取網際網路，卻不允許裝置彼此直接通訊。排查時先確認基本的網路互通，再檢查 Proxy 入口；不要把所有失敗都歸咎於 Shadowrocket。在共用網路環境中應保持謹慎，臨時測試完成後及時恢復原本的存取範圍。

檢查項目	預設值處理方式	建議值原則
遠端伺服器連接埠	以現有伺服器資料為準	與遠端實際服務一致
本機 Proxy 連接埠	以目前 App 顯示為準	符合用途且沒有監聽衝突
監聽位址	以目前 App 顯示為準	採用最低必要存取範圍
入口協定	核對目前可用功能	與使用端設定一致

修改後完整複核與還原方式

修改連接埠後，應逐層驗證：入口是否可連線、協定是否匹配、請求是否進入 App、路由是否符合預期，以及目標是否有回應。前一層成功不代表下一層也成功。例如請求已進入 App 但目標逾時，就應繼續檢查伺服器連線與規則；若入口完全無法連線，則先處理監聽狀態與網路範圍，不必立刻更換遠端伺服器。

所有 Settings 修改都可使用同一份複核清單：記錄原值、說明修改目的、一次只改一個變數、使用固定目標測試、檢查 Log、驗證原本正常的功能，保留有效修改並撤銷其他變更。沒有明確改善的修改，應優先還原原值。設定項目保持精簡且容易說明，通常比累積大量「可能有用」的開關更便於長期維護。

App 更新後不必機械式重做所有設定，但應核對常用選項與重要流程是否仍符合預期。更新由 App Store 管理，具體變更以商店頁面及 App 內顯示為準，不要根據舊截圖猜測新介面。先測試日常連線、Config 選取及必要的按需行為；若發現差異，保留原有資料並逐項核對，不要立刻清除一切重新開始。

最後將維護紀錄整理成可重現的狀態說明：使用哪種網路、哪份 Config、哪個伺服器項目、採用何種 Global Routing，以及曾調整哪些 Settings。紀錄不必包含實際憑據，但應足以讓自己再次建立相同環境。遇到尚未解決的問題，請返回相應章節繼續排查；首次操作流程請參閱使用說明，購買與裝置需求請參閱下載頁，讓各頁面各自負責清楚的查閱任務。