Shadowrocket 設定詳解

01 / Scope

設定範圍、預設值與調整基準

先區分 Settings、Config 與伺服器欄位

Shadowrocket 的設定並非所有項目都同時生效的總表。Settings 中的 App 層級選項、Config 中的設定檔，以及伺服器編輯頁中的連線參數，各自處理不同層面的問題。例如 DNS 可能同時涉及設定檔與 App 內選項，而伺服器位址則屬於連線端點。排錯前先確認正在編輯哪一層，否則即使儲存成功，也可能沒有改到實際處理請求的設定。

Home 用來查看目前連線與伺服器選擇，Config 用來管理及選用設定檔，Settings 用來查看 App 設定。本文保留這些介面用語；實際入口排列與可見選項以裝置介面為準。找到同名設定後，先閱讀旁邊的說明、目前值與可選範圍，再進行操作；不要只憑另一部裝置的截圖位置尋找開關。設定檔中沒有的欄位，也不能直接依中文說明自行拼寫。

「預設值」至少有三種情境：新建設定檔的初始內容、App 首次執行時的初始選項，以及匯入訂閱或設定檔後的值，三者並不相同。換機還原後看到的選項可能沿用舊裝置；重新選擇 Config，也可能切換到另一個檔案。本頁建議記錄的是「調整前實際生效的值」，比未經確認的預設值更適合用來還原，也有助判斷問題是否由這次調整造成。

記錄目前狀態，建立可還原的基準

開始前記下目前的 Global Routing、已選伺服器、作用中的設定檔，以及發生問題時使用 Wi-Fi 還是行動網路。伺服器名稱只要方便自己辨識即可，不必公開。接著備份準備調整的設定檔，並註明調整目的，例如「確認指定網域是否採用預期策略」。這份記錄不是 App Log，而是人工保留的測試條件，可避免多輪排錯後忘記原始狀態。

每次只調整一個變數。若同時更換 DNS、伺服器、路由模式與測試方式，即使連線恢復，也無法判斷是哪項調整奏效；下次遇到同類問題仍得從頭測試。完整的一輪應包括調整前測試、單項調整、重新建立連線、以相同目標再次測試、查看記錄，以及保留或撤銷調整。涉及設定檔時，還要確認儲存後已選為目前作用中的設定檔。

「建議值」也必須考量使用情境。裝置目前運作正常時，通常建議保留已驗證的設定；裝置發生故障時，則先回到最精簡、可理解的設定，再逐項恢復功能。提高數值、延長逾時時間或啟用更多選項，不會自然讓連線更穩定。尤其是網路可達性問題，設定只能改變用戶端處理請求的方式，不能取代伺服器端可用性、憑證有效性及目前網路的存取條件。

設定範例中的 example.com 是說明用網域，不代表可連線的服務。PROXY、DIRECT 是策略關鍵字，與介面中 Global Routing 的 Proxy、Direct 在寫法及作用範圍上應加以區分。範例中的保留位址用來說明比對邏輯，不需照抄。若既有設定包含自訂策略，請先確認其定義再決定是否引用，避免使用無法解析的策略名稱。

如果目前連首次連線都尚未完成，請先依入門指南的完整流程操作，不要直接進行複雜的設定調校。若故障已有明確錯誤訊息，可搭配常見問題縮小範圍。本頁接下來會依序說明解析、路由、觸發、測試、觀察、同步與還原；這樣安排是為了將「設定看起來正確」轉化為「實際請求已經驗證」。

02 / DNS

DNS 設定與網域解析流程

DNS 負責什麼？

DNS 會將網域名稱解析為位址，但「解析成功」不等於「連線成功」。請求可能已取得位址，卻在連接伺服器、建立加密工作階段或取得內容時失敗；反過來說，如果 Proxy 伺服器位址使用網域名稱，連線 Proxy 之前也可能必須先完成解析。因此應先區分目標網站解析失敗與 Proxy 伺服器位址解析失敗，兩者發生在不同階段，調整同一項設定未必都能解決。

在 Config 中查看目前作用中檔案的 [General]，確認是否包含 dns-server。下例中的 system 表示使用系統提供的解析設定，適合作為理解起點，但不代表所有檔案都會自動包含這一行。實際結果會受目前網路條件影響。若 App 內還有 DNS 相關選項，也應一併記錄；不能只憑檔案中的一行，就判定所有請求都使用相同的解析路徑。

[General]
bypass-system = true
dns-server = system

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

這段範例同時呈現 App 層級處理、解析來源與規則比對，但這幾行設定並非同一回事。bypass-system 是獨立的設定選項，不是通用的「修復 DNS」按鈕；dns-server 指定解析設定；[Rule] 則決定比對到請求後採用的策略。複製任何一行之前，應先確認其位置、重複欄位及既有規則不會互相衝突，並保留其他必要區段。

如何判斷預設值與建議值

DNS 初始值應從目前的設定檔與 App 介面確認。本頁不指定適用所有網路的公用解析位址，也不會將某項解析服務列為固定建議。沒有解析異常的裝置，先保留已驗證的設定；只在特定網路失敗的裝置，先比較該網路與另一種網路的結果。只有當問題指向解析階段時，才需要更改解析來源，並以相同網域重複測試。

若既有設定使用加密解析，應確認解析端點本身是否可連線、是否必須先解析其網域，以及目前路由會如何連接該端點。改用另一種協定不會自動排除前置依賴。故障時先以簡單、可觀察的條件確認基本路徑，再恢復原有解析設計；不要不斷增加端點，以免失敗時無法判斷實際參與請求的是哪個端點。

網域規則與位址規則也會影響觀察結果。DOMAIN-SUFFIX 依網域後綴比對，IP-CIDR 依位址範圍比對，部分位址類判斷可能涉及解析。若同一網域在不同網路解析出不同位址，後續位址規則的結果也可能隨之改變。檢查「為什麼命中這條規則」時，應同時確認請求網域、解析結果與規則順序，而不只查看最後顯示的策略。

快取與區域網路名稱的適用範圍

解析快取可能存在於 App、系統及上游的不同位置。調整 DNS 後，舊結果不一定會立刻全部清除；網頁也可能沿用既有連線。驗證時先儲存設定並重新建立連線，再重新發出請求。若仍需判斷快取的影響，請使用可重複的測試步驟，不要任意清除所有資料。清除範圍越大，就越容易連登入狀態或其他現場資訊一起移除。

區域網路裝置名稱、內部網域與公開網域，不一定使用相同的解析條件。切換至外部解析來源後，內部名稱可能無法取得原有結果。若問題只涉及家用或辦公室網路內的裝置，先確認原網路的解析需求、位址範圍與直連規則。不要以「公開網站可以連線」作為內部名稱設定正確的證據，也不要為了解決一個內部名稱的問題，就全面改變所有請求的路由。

完成調整後，至少驗證一個原本正常的目標、一個原本失敗的目標，以及確實需要的區域網路目標。記錄是否取得位址、是否建立連線，以及是否收到內容。若解析已成功但內容仍無法取得，下一步應檢查路由、伺服器參數或目標服務，而非繼續輪換 DNS。保留這些分階段的結果，後續分析 Log 才有明確脈絡。

03 / Routing & Proxy

Global Routing、規則與 Proxy 連接埠

三種模式不代表三套伺服器參數

Global Routing 決定請求採用哪種整體處理方式。設定對應 Config，代理對應 Proxy，直連對應 Direct。Config 會依作用中設定檔中的規則分配策略；Proxy 會將通常由此路由設定處理的請求交由代理路徑處理；Direct 則採直連。系統流量、排除項目及個別設定仍可能構成例外，因此不要將任何一種模式視為對裝置所有網路行為的絕對描述。

在 Config 模式下，命中結果顯示 DIRECT 可能完全符合設定，不代表伺服器失效。反之，切換至 Proxy 後目標恢復正常，只能表示改變處理路徑對結果有影響，還不能單獨證明某條規則寫錯。應回到 Config，確認目標命中了哪一行、前面是否已有更廣泛的比對，以及策略實際指向何處，再決定是否調整規則。

日常建議使用哪種模式，取決於使用者明確的設定目的。若已有確認過的分流規則，可使用 Config；短時間比較代理路徑時，可暫時切換至 Proxy；確認直連條件時，可暫時使用 Direct。測試結束後應恢復原有模式並重新建立連線。不要為了掩蓋錯誤規則而長期保留臨時測試模式，否則區域網路存取與其他目標的路徑可能一起改變。

規則片段的順序與策略含義

規則通常依由上而下的順序尋找符合項目，具體規則應放在兜底規則之前。下例先處理範例網域與私有位址，最後由 FINAL 處理未命中的請求。此處的 FINAL,PROXY 是刻意選擇 Proxy 作為兜底策略，並非所有使用者都應照抄的預設值。若改成 FINAL,DIRECT，未命中請求的路徑就會不同，影響範圍也遠大於單一網域。

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

不要靠重複新增相同規則來「提高優先順序」。若前面已有一條符合條件的規則，後面相同目標的規則可能根本不會參與判斷。先查看命中記錄，再移動規則或縮小比對範圍，儲存後重新驗證。REJECT 表示拒絕符合條件的請求，不等於修復請求；具體比對範圍請參閱REJECT 規則的順序與限制。

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

伺服器編輯頁中的連接埠，是遠端服務接收連線的位置，必須與使用者已有的伺服器資訊一致。若 Settings 提供本機 Proxy 連接埠，則是裝置上某種本機代理入口的監聽位置。即使兩者恰好顯示相同數字，也不能互相取代。將本機連接埠填入遠端伺服器欄位，或把遠端服務連接埠當成本機監聽設定，都會徹底改變連線目標。

本機連接埠的目前值、協定類型及啟用條件，應以實際介面為準；本頁不指定固定連接埠號碼。連接埠數字有效只是第一步，還要確認是否有服務正在監聽、請求端使用哪種代理協定、監聽範圍是否僅限本機，以及網路是否允許存取。一般 iPhone 或 iPad 使用系統 VPN 設定連線時，不應為了「提升速度」而任意更改本機監聽連接埠。

若確實需要使用本機 Proxy，先保留原始設定，確認請求來自本機還是區域網路中的其他裝置，並選擇 App 實際支援的對應方式。HTTP 與 SOCKS5 用戶端設定不能任意混填；網址路徑也不是連接埠欄位的內容。驗證失敗時，先檢查監聽是否已啟用、協定是否一致，再查看目標請求；不能只憑連接埠數字相同就判定設定完成。

調整路由或連接埠後，應分別驗證一般網路請求與特定本機入口，避免混淆兩種測試結果。若更改連接埠後一般連線沒有變化，可能只是因為一般連線原本就沒有使用該入口。設定應以實際請求路徑為核心：由誰發起、連接到哪裡、透過何種協定進入、命中哪項策略，最後才判斷是否需要更改數值。

04 / On Demand

On Demand 的觸發條件與停止方式

按需觸發不會修復伺服器

On Demand 用來依據設定條件觸發 VPN 連線，處理的是「何時嘗試建立連線」，不能取代伺服器驗證、訂閱更新或路由設定。手動連線已穩定，且作用中的 Config 與伺服器選擇都已確認後，才適合設定自動觸發。否則它可能反覆觸發相同的失敗路徑，讓人以為 App 不斷自行更改設定；實際上只是觸發條件持續成立。

進入實際的 On Demand 選項後，先確認目前是否已啟用、已有什麼條件，以及系統中的 VPN 設定是否仍存在。預設狀態以目前裝置顯示為準；還原舊資料、重新安裝 App 或重新授權後，不能假設狀態仍與初次使用時相同。若系統與 App 顯示的狀態不一致，先回到手動連線測試，確認基本設定有效後，再處理自動觸發規則。

建議設定不是「全部啟用」，而是只保留能清楚說明用途的條件。若 App 提供依網路類型或網路識別資訊處理的選項，應依實際需求逐項設定，不要照抄他人的網路名稱。暫時不需要自動連線時，保留手動控制會更方便觀察。經常切換網路的裝置，則應在每種常用網路下分別驗證觸發行為，不能只測試目前的 Wi-Fi。

將自動連線拆解為可重複的測試

第一步，留在同一網路中手動建立連線，存取已知可用於驗證的目標，並查看實際策略。第二步，先中斷連線，確認正常的停止方式。第三步，依需求設定 On Demand，再透過實際網路狀態變化觀察觸發結果。測試期間不要同時切換伺服器、更新訂閱或更換 Config，否則連線變化可能來自其他操作，無法證明觸發條件本身正確。

觀察時應區分四件事：條件是否成立、系統是否發起連線、連線是否建立，以及建立後請求是否正常。自動觸發已發生但後續連線失敗，排查方向應轉向伺服器與網路；完全沒有發起連線，才需要繼續確認觸發條件與系統設定。狀態列出現 VPN 標示，也只代表某種連線狀態，不足以證明目標內容能如預期傳回。

切換網路時，可能經歷重新取得位址、解析條件變化及舊連線失效。短暫重新連線與持續循環失敗是不同現象。記錄切換前後使用的網路、觸發時間順序及失敗階段，比不斷開關更有幫助。若某網路必須先完成網頁認證，應先正常登入該網路，再觀察 On Demand；用戶端觸發設定不能取代網路本身的認證流程。

為什麼中斷後又出現連線

On Demand 的條件仍成立時，手動中斷一次連線，不一定代表自動觸發機制已停用。若要確實停止自動連線，請先在相關設定中停用 On Demand，再中斷連線並觀察系統狀態。不要立刻刪除所有設定，否則後續很難判斷問題出在觸發規則、系統授權還是伺服器參數。確認已停止後，再依原有記錄恢復必要設定。

若裝置另有 VPN 設定，或網路限制由組織管理，也應確認系統允許的連線方式。不要反覆建立名稱相近的設定，以免無法確認 App 正在使用哪一個。受管理的裝置應遵守裝置管理要求，不能以本頁的一般操作取代相應管理流程。一般個人裝置也應先查看系統實際提示，不要將所有連線失敗都歸咎於 App 選項。

驗證 On Demand 時，也應涵蓋裝置鎖定後的一般使用情境，但不要直接將背景狀態變化解讀為耗電或效能結論。裝置的網路活動、系統策略與其他 App 都可能影響結果。若只進行臨時測試，結束後應還原原設定；若打算長期使用，則在設定或網路條件變更後再次確認，確保自動連線仍符合明確的使用目的。

05 / Ping & Connectivity Test

Ping、Connectivity Test 與結果解讀

先確認測試涵蓋哪一段路徑

在一般使用情境中，Ping 常泛指延遲測試，但實際測試方式可能不同。網路探測、建立傳輸連線，以及透過代理向目標發出請求，涵蓋的路徑並不相同。使用前先查看測試方式與目標設定，不要只憑按鈕名稱推斷它已驗證完整代理連線。測試方法不同，即使目標相同，結果也不應直接排序或比較。

若介面提供 ICMP、TCP 或請求型測試，應分別了解其限制：ICMP 探測不會驗證代理協定認證；TCP 建立連線不一定會驗證加密與 App 請求；請求型測試較接近對特定目標的實際存取，但也會受目標服務與解析影響。App 實際提供哪些方法、欄位與選項，請以目前介面為準，不要為了套用本頁說明而尋找不存在的開關。

Connectivity Test 用來觀察所選測試流程的連線狀況，不保證所有網站、所有協定及整段使用時間都正常。一次測試成功，只能證明當時的測試條件得到成功結果；一次失敗，也可能只是測試目標無法連線，不代表伺服器完全無法使用。建議先使用目前已驗證的測試方式，再確認目標與路徑；只有排錯需要時才更改方法或目標。

測試目標、逾時與預設值

測試目標的初始值、等待時間及其他參數，請先從 Settings 目前頁面確認。本頁不提供統一的逾時秒數，也不建議持續延長逾時時間。等待太短可能將網路波動誤判為失敗；等待太長則會讓真正無法連線的情況更晚結束。合理的數值應有助於在相同條件下比較，並記錄調整前後的結果，而非追求測試清單全部顯示數字。

若測試允許指定目標，應選擇自己有權存取且可穩定用於驗證的位址，並確認格式符合介面要求。網域欄位、完整 URL 欄位與伺服器位址欄位不能混用。不要將帶有登入狀態或私密參數的位址當作公開排錯資料。若測試目標本身會重新導向、要求認證或限制存取，測試結果就包含這些條件，不能簡化為 Proxy 伺服器的純傳輸延遲。

批次測試容易引入另一個變數：同時發出的探測會共用目前網路資源，也可能受到目標端回應策略影響。清單中的結果不是固定不變的伺服器屬性。遇到特定異常目標時，應單獨重複測試並與實際請求對照。不要一邊下載大型檔案，一邊將測試差異歸因於伺服器；也不要用一次排序取代對路由與協定參數的確認。

分別觀察延遲、頻寬與穩定性

回應時間較短，不代表持續傳輸速率較高，也不保證長連線穩定。回應時間著重於一次互動的等待，持續傳輸則還會受到頻寬、壅塞、目標內容服務與協定行為影響。若問題是影片停頓或檔案傳輸中斷，應記錄發生情境與持續時間，並查看相關請求 Log；只反覆執行 Ping，無法完整涵蓋這些問題的成因。

測試失敗但實際存取正常時，先確認測試目標是否有特殊回應條件，並保留正常存取結果作為對照。測試成功但實際存取失敗時，則應確認該服務目標的 DNS、規則命中、連線階段與回傳結果。兩種情況都不應立刻刪除訂閱。先區分「測試流程失敗」與「實際服務流程失敗」，才能判斷該調整的是測試設定還是實際連線設定。

涉及 Hysteria2 等依賴特定傳輸條件的連線時，也要注意 TCP 探測不能取代該傳輸方式的實際驗證。協定的運作條件可參閱Hysteria2 與 QUIC 基礎說明；VMess 與 VLESS 欄位的確認方式請參閱UUID、加密與傳輸方式說明。測試選項無法彌補協定欄位填寫錯誤。

最後應保留能回答具體問題的測試，而不是保留最多的測試。確認問題後，將臨時目標與逾時調整還原為日常已驗證的值，並記錄保留某種測試方法的原因。日後遇到類似現象，可先重現相同條件，再決定是否擴大診斷範圍，避免每次都從不同的測試起點開始。

06 / Log & Data

Log、Data 與分階段故障記錄

從單一請求建立觀察範圍

Log 用來觀察請求與連線過程，Data 用來查看 App 提供的流量等記錄；具體可見內容、保留方式與入口以實際介面為準。流量計數增加，不代表目標頁面已正確載入；出現連線記錄，也不代表內容已成功傳回。Log 的用途是指出故障發生在哪個階段，不是單憑記錄數量判斷 App 是否「正常運作」。

開始排錯前先記錄各項條件與時間順序：目前網路、Global Routing、作用中的 Config、所選伺服器，以及準備存取的目標。接著只發出一個或少量容易辨識的請求。不要同時開啟多個 App 不斷重新整理，否則 Log 會混入系統活動、背景請求與重試。只查看最新的一行，也可能將不相關請求的失敗誤認為正在排查的服務故障。

若有 Log 詳細程度或保存相關選項，預設值以目前裝置顯示為準。建議先使用足以看清問題的最低記錄程度，確有需要時再暫時提高；排錯結束後恢復日常設定。記錄越詳細，通常需要處理的資訊越多，也可能占用更多儲存空間或處理資源；不應把長期保留最詳細記錄當作提升連線品質的方法。

依請求階段閱讀記錄

先確認請求目標是否正確，再確認是否完成解析、命中哪項規則與策略，接著確認連線到的伺服器及後續結果。不同 Log 格式未必會逐項顯示這些欄位，但閱讀順序可以一致。若缺少某階段的資訊，就應承認目前證據不足，回到相應測試補充資料，不要只憑一條概括性錯誤推斷整段連線路徑。

例如「連線逾時」可能發生在不同端點；應確認逾時的是 Proxy 伺服器、解析端點還是目標服務。「認證失敗」則應優先檢查使用者持有資訊中的認證欄位，以及是否選取了預期的伺服器。遇到憑證相關提示，應確認位址、名稱與伺服器設定，不要為了消除錯誤訊息而盲目放寬驗證。隱藏錯誤訊息不等於正確修復連線。

Log 中的 DIRECT、PROXY、REJECT 應搭配命中規則解讀。看到 DIRECT 時，先確認這是否符合使用者的分流目的；看到 REJECT 時，檢查前面的規則是否範圍過廣。不要將所有不符合預期的請求一律改成 PROXY，因為問題也可能出在網域錯誤、目標服務狀態或 App 本身的認證流程。

Data 計數與隱私範圍

查看 Data 統計時，先確認統計範圍與時間範圍。連線持續時間、累計流量與單一請求耗時是不同指標；重新連線、清除資料或切換介面後，也應重新確認顯示方式。不能將 App 中某項計數直接視為電信業者帳單，也不能只憑上傳量增加就判定發生異常。應先區分正常背景通訊、重試與正在執行的測試。

Log 可能包含網域、位址、伺服器識別資訊與請求內容；匯出的檔案還可能附帶更多脈絡。分享前應移除密碼、訂閱連結、權杖、個人位址及可能連結到身分的資訊。UUID 即使看起來只是隨機字元，也可能是連線憑證，不應原樣貼到公開問答中。保留必要的錯誤類別、先後順序與去識別化欄位，通常比提供完整資料更適合討論。

清除 Log 前，先保留少量與問題直接相關的片段，尤其是調整前後的對照。不要每次失敗後立刻清空所有記錄，再靠記憶描述問題。需要重新收集資料時，可以明確設定新的起點，然後只重現一次。若故障很難穩定重現，記錄觸發條件與最後一次正常的條件，比不斷累積沒有標記的大量 Log 更容易得出結論。

若記錄顯示基本連線已成功，但只有特定服務失敗，應檢查該服務的規則與回應條件；若記錄在連上伺服器之前就中止，則應回頭檢查 DNS 與網路。將結果整理成「條件、操作、現象、證據、還原結果」五項，可直接對應本頁各章，也方便搭配常見問題分類排查進一步縮小範圍。

07 / Widget & iCloud

Widget、iCloud 同步與設定備份

Widget 是快捷入口，不是獨立的連線設定

Widget 提供快捷入口或狀態顯示；可新增的類型、互動方式與顯示內容，取決於 App 及系統目前支援的功能。它不會構成另一套伺服器參數，也不應作為背景連線是否成功的唯一依據。若 Widget 顯示的狀態與 Home 中看到的不同，先開啟 App 確認連線，再檢查系統是否已更新顯示；不要直接更改 DNS 或伺服器連接埠。

新增 Widget 前，先確認可在 App 內正常連線與中斷連線；接著使用系統的新增與編輯流程，選擇 Shadowrocket 提供的相應項目。若有可選內容，依實際需求選擇即可，不必新增所有類型。介面的預設顯示項目以目前可見內容為準；本頁不固定 Widget 的尺寸、版面或按鈕數量，以免將系統差異誤認為設定遺漏。

從 Widget 發起操作後，應回到 Home 或查看實際存取結果來確認狀態。裝置鎖定、系統重新整理與 App 狀態都可能影響顯示時間，因此「卡片上的文字沒有變」與「連線沒有建立」必須分開驗證。若 App 內操作正常但入口未更新，先檢查 Widget 本身及系統顯示條件；若 App 內操作也失敗，則依前文的網路與 Log 流程排查。

iCloud 同步不等於獨立備份

在帳戶與系統條件符合時，iCloud 同步可同步 App 支援的資料，但不能只憑名稱推測同步內容。請先查看實際設定中包含哪些項目、是否已啟用，以及兩部裝置是否使用符合要求的 iCloud 帳戶。用於 App Store 購買的帳戶與系統中的 iCloud 帳戶可能不是同一種帳戶；能重新取得 App，不代表設定資料也已同步。

建議先在資料完整的裝置上確認基準，再處理另一部裝置。不要在兩端同時大量編輯同名設定，否則很難判斷最後看到的內容來自哪一端。尤其是某部裝置暫時離線時，重新連上網路後應再次確認同步結果。同步完成與否，應以檔案內容、伺服器資訊及實際連線為準，而非只看某個同步選項是否已啟用。

同步會傳播變更，因此不能將它視為不會改變的歷史副本。誤刪或誤改的內容，也可能透過同步影響其他裝置。大幅調整規則前，應另外備份目前設定檔，並在自己可控的位置標明用途。備份檔應便於辨識，但不要將密碼或完整訂閱連結寫入檔名；檔案本身也應視為敏感設定妥善管理，不要任意上傳至公開位置。

匯出內容與移轉後的重新驗證

匯出設定檔時，應開啟副本確認實際包含哪些區段，不要假設單一檔案涵蓋所有 Settings、所有伺服器及系統授權。訂閱內容、手動新增的伺服器與本機規則，可能位於不同的儲存範圍；實際內容以 App 匯出結果為準。換機前最好同時保留原始訂閱資訊、必要的伺服器參數與本機規則副本，並明確記錄每份資料的還原用途。

還原後先檢查檔案是否完整，再確認作用中的 Config、Global Routing 與目前伺服器。系統 VPN 授權屬於系統層級流程，必須依新裝置提示完成，文字設定無法取代。接著先測試手動連線，再驗證 On Demand 與 Widget。依照這個順序，可以將資料還原問題與自動觸發問題分開，避免所有功能一併還原後只看到籠統的失敗結果。

若舊裝置可正常使用而新裝置不行，先保持舊裝置設定不變，作為對照。逐項比較兩部裝置的網路、作用中設定檔、認證欄位與同步結果，找出差異後再調整新裝置。不要先清空舊裝置來「強制同步」，因為這會移除最有價值的正常基準。若涉及 App 取得帳戶問題，請參閱已購項目還原說明，並與設定移轉分開處理。

更多資料整理方式與操作順序請參閱iCloud 同步、設定匯出與換機移轉；已購項目的帳戶確認方式請參閱換機重裝後的已購項目說明。釐清這些用途，能避免將同步故障誤當成購買問題，也可減少不必要的重複編輯。

08 / Verification & Recovery

設定驗證、故障分支與還原流程

依影響範圍選擇排查起點

發生問題時，先確認「所有目標都失敗，還是只有部分目標失敗」。所有目標都失敗時，先確認裝置的基本網路連線、系統 VPN 設定、目前伺服器及認證條件；只有部分目標失敗時，優先檢查相關網域的解析、規則命中及目標回應。這個判斷比先決定「要改 DNS 還是連接埠」更重要，因為它會決定接下來應收集哪類資訊。

接著確認問題是首次出現、調整後出現，還是切換網路後出現。首次連線失敗時，核對既有伺服器資訊與協定欄位；調整後失敗時，優先撤銷最近一次調整；切換網路後失敗時，保持設定不變，單獨檢查新網路的接入與解析條件。不要將這三種情境混進同一套隨機調整流程，否則很容易丟失已明確的因果線索。

若原本可以連線，只是在調整 Settings 後發生異常，最有效的做法通常不是繼續疊加設定，而是回到記錄的基準。先停用臨時 On Demand 條件，還原原有 Global Routing，重新選取原作用中的 Config，再使用原伺服器手動連線。每完成一步都記錄結果，避免一次還原所有項目後只知道「現在正常」，卻無法判斷故障原因。

如何安全地使用設定片段進行比對

下例用來說明方便閱讀的局部設定組織方式：[General] 放置相關基本選項，[Rule] 放置依序排列的規則。這不是建議用來覆蓋既有檔案的內容，也不包含連線伺服器所需的全部資訊。實際編輯時，應在副本中找到相應區段，避免重複建立同名欄位；尤其不要因貼上片段而刪除原本必要的策略或其他設定。

[General]
dns-server = system

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

驗證規則時，選擇一個確實與新增規則相關的請求，再確認命中結果。範例網域只用來說明語法，不能以其內容結果判斷自己的服務是否可用。若新規則沒有命中，先檢查作用中的檔案與前面的規則；若已命中但連線失敗，則繼續檢查策略所使用的連線路徑。規則語法正確、策略命中與最終取得內容，是三項不同的驗證結果。

最小限度還原與長期保留原則

所謂最小限度還原，是先建立一條可說明且可重複成功的手動連線路徑，而非刪除所有資料。保留既有有效的伺服器資訊，使用明確的路由模式與作用中檔案，暫時減少自動觸發及非必要的測試選項。若此時仍失敗，就依 Log 繼續定位；若已成功，再每次恢復一項功能，並在每次恢復後以相同目標驗證。

每項打算長期保留的設定，都應能回答三個問題：它解決什麼具體需求、如何確認已生效，以及失效時如何撤銷。若無法回答，先保留原值通常更合適。尤其是 DNS 端點、本機 Proxy 監聽與自動連線條件，這些設定會增加需要維護的條件，不應只因別人使用就加到自己的裝置上。

還原過程中，不要把重新取得 App 當成第一步。App 由 App Store 提供，重新安裝涉及已購項目取得、設定資料與系統授權等多個層面，也可能移除排錯所需的現場資訊。只有在明確知道要解決的問題、已保存必要資料並了解還原步驟時，才考慮這麼做。正版開發者名稱為 Shadow Launch Technology Limited，App ID 為 932747118，確認方式請參閱正版三項確認方式。

若需要整理問題以便進一步排查，請保留一段簡潔記錄：使用什麼網路、採用哪種 Global Routing 與作用中 Config、進行了哪項操作、出現什麼現象、Log 停在哪個階段，以及撤銷調整後是否恢復。不要公開真實訂閱或認證欄位。這類記錄能區分用戶端設定、使用者既有伺服器條件與目標服務問題，比「全部照做還是不行」更有助於診斷。

排錯完成後，移除臨時測試目標、將日常 Log 詳細程度還原，確認 On Demand 與 Widget 的行為符合需求，並備份最終設定。之後若更新既有訂閱或更換網路，只需重新測試受影響的部分。需要重新完成整套連線流程時，請回到入門指南；需要依具體症狀查找排查方向時，請前往常見問題，不必重新調整本頁所有設定。