官方手冊 / Settings 參考
Shadowrocket 設定詳解
依設定來源查閱參數,透過實際請求驗證結果。
首次連線請先閱讀快速入門教學,完成既有訂閱匯入、伺服器選擇與連線驗證。本頁供後續查閱設定意義、確認生效範圍及排除異常,不必依序修改所有選項。
01 / 設定來源
Config 與 Global Routing
先確認目前使用哪個 Config,再判斷某項 Settings 是否生效。Shadowrocket 的實際連線結果並非由單一開關決定:Home 中選取的伺服器提供連線參數,Config 包含規則及相關設定,Global Routing 決定採用哪種路由方式,系統網路則提供基本連線條件。使用者既有的訂閱通常用於維護伺服器項目,與用於分流的設定檔並非同一回事。訂閱更新成功,不代表規則或 DNS 也已同步變更。
先區分設定、代理與直連
Global Routing 的 Config、Proxy、Direct 分別代表設定、代理與直連三種模式。Config 依目前設定中的規則處理請求;Proxy 以代理模式處理流量;Direct 則以直連模式處理流量。這裡描述的是路由意圖,不代表任何請求都必定成功,也不能據此推斷系統中的所有連線都由 App 處理。排查時請記錄目前模式,避免在 Proxy 模式下修改規則,卻誤以為規則未儲存。
| 介面用語 | 主要用途 | 驗證重點 |
|---|---|---|
| Config | 依目前設定分流 | 請求命中的規則與策略 |
| Proxy | 檢查代理路徑 | 選取的伺服器是否能建立連線 |
| Direct | 檢查直連路徑 | 目前網路能否直接連線至目標 |
規則順序比規則數量更重要
規則通常由上而下檢查,最先命中的項目會決定後續策略。DOMAIN-SUFFIX 可匹配網域本身及其子網域;GEOIP 依目標位址的地理資料庫結果匹配;FINAL 則接收先前未命中的請求。若將範圍較廣的規則放在前面,下方較具體的例外規則可能就沒有機會生效。編輯時先找到與目標網域相關的項目,再檢查它上方的規則;不要只確認檔案最後是否有一行看似正確的內容。
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY
上例僅用於說明結構,並非適用於所有網路的完整設定。example.com 是示例網域;PROXY、DIRECT 是策略關鍵字,不可當成伺服器位址填入。網域規則會先檢查示例網域,GEOIP 接著處理相應位址,最後由 FINAL 收尾。實際使用前,請確認既有伺服器可用,並依自己的存取需求檢視每條規則。匹配範圍的詳細說明請參閱DOMAIN-SUFFIX、GEOIP 與 FINAL 的規則寫法。
預設狀態與建議基準
預設值應以目前安裝後的畫面及目前選取的設定為準。匯入設定、還原資料或切換設定,都可能改變觀察到的狀態。日常使用時,建議先了解規則內容,再使用 Config;Proxy 與 Direct 可用於交叉排查,但測試結束後別忘了恢復原本模式。初次建立基準時,請記錄設定名稱、選取的伺服器、Global Routing 與一筆測試請求,之後才能判斷變化來自何處。
儲存檔案與讓設定生效,是兩件需要分別確認的事。修改後先確認內容已確實儲存,再確認該檔案是目前啟用的 Config,接著依 App 介面提示處理連線狀態。既有連線可能仍沿用原本路徑,因此請重新發起測試請求,而非只觀察一直保持開啟的頁面。若結果仍不符,請查看 Log 中的請求記錄,不要立刻重複匯入相同內容。
若出現「伺服器測試正常,但某個網域無法連線」的情況,請先區分伺服器可連線與規則命中。檢查實際請求的完整網域,確認是否涉及子網域、重新導向網域或不同的位址族,再查看命中的策略。若所有請求都失敗,優先檢查連線與伺服器參數;若只有特定類型的請求失敗,再聚焦檢查規則與 DNS。需要重新執行首次連線流程時,請返回快速入門教學,不要同時重設所有設定來掩蓋原因。
02 / 名稱解析
DNS 設定與解析路徑
DNS 的作用是將網域名稱轉換為可連線的位址,它不等同於代理伺服器,也不會直接決定所有請求的路由。排查 DNS 前,請先確認故障現象:網域無法解析、取得位址後連線失敗,以及網頁主文件載入成功但附加資源失敗,分別屬於不同階段。只有第一種情況明確指向名稱解析;其他情況還需要檢查路由、伺服器、目標服務與連線記錄。不要將所有無法開啟的頁面都歸因於 DNS。
先檢查目前 Config 的 DNS 設定
DNS 相關行為可能由目前的 Config 決定,不一定只受 Settings 中某個入口控制。查閱時請先開啟目前設定,確認是否明確指定解析伺服器、網域映射或相關選項,再查看 App 介面顯示的狀態。未明確填寫,不代表所有網路環境都會得到相同結果:系統提供的解析條件會隨 Wi-Fi、行動網路及網路接入狀態而變化。本文不指定適用於所有裝置的固定 DNS 位址。
設定中的 dns-server = system 表示使用系統提供的 DNS,可作為理解設定來源的基準範例,但不代表 App 在所有情況下的出廠預設內容。若既有設定已明確指定解析方式,請先了解原有設計再進行修改。不要只把這一行貼到檔案末尾;它應放在相應的設定區段,也要避免重複定義造成閱讀上的混淆。修改前請保留完整副本,以便逐項還原。
分別判斷解析傳輸與請求路由
一般 DNS 與加密 DNS 的差別在於解析請求的傳輸方式,不能因此保證解析結果一定正確或存取一定成功。使用加密解析時,還需要先連線至解析服務;若解析服務以網域作為入口,其本身的位址探索也可能是前置條件。設定過於複雜時容易形成排查循環:業務網域等待解析,解析服務卻又依賴尚未就緒的路徑。遇到這種情況,請先恢復已驗證過的簡單基準設定。
| 現象 | 優先檢查 | 無法直接推斷 |
|---|---|---|
| 未取得目標位址 | 解析服務及其可連線性 | 伺服器認證資訊錯誤 |
| 已取得位址但連線逾時 | 路由、伺服器與目標連接埠 | 解析結果一定錯誤 |
| 切換網路後出現異常 | 網路接入、快取與位址族 | 必須更換所有設定 |
IPv4、IPv6 與快取的範圍
同一個網域可能回傳 IPv4 與 IPv6 位址。成功解析出其中一種位址,不代表目前網路或選取的伺服器就具備相應的可用路徑。若請求總是在某個位址族失敗,請搭配記錄確認實際連線的位址,再檢查網路條件。不要把停用某個位址族當成通用建議;這可能讓某項測試暫時通過,卻掩蓋原本的路徑問題,也可能影響其他正常運作的請求。
快取可能讓修改後的結果看起來沒有變化,但快取不只存在於 Shadowrocket。系統、瀏覽器、App 及上游解析服務都可能保留結果;已建立的連線也未必會重新解析。驗證時可先關閉原有測試連線,再發起新請求;若 App 提供相關清除功能,請先了解其清除範圍。不要反覆在多個位置清除資料,這不但增加操作量,也會失去可供比較的現場資訊。
建議設定與驗證步驟
若沒有特殊解析需求,建議先保留目前可正常使用的設定中的 DNS 設定。需要調整時,只使用已確認用途與可連線性的解析服務,並且每次只修改一項。依序記錄原設定、目標網域、回傳位址、命中策略與連線結果,再於相同網路下重新測試。若只比較網頁載入速度,卻未確認實際解析是否發生,就無法判斷變化究竟來自 DNS、快取還是目標服務。
App 內部自行完成的解析、保留的歷史連線及不同的網路請求方式,都可能使診斷結果與某個業務 App 的表現不完全一致。較可靠的做法是在相同網路、相同 Global Routing、相同伺服器下,以同一目標連續比較。若 DNS 已回傳合理位址,但存取仍失敗,請前往 Log 與 Proxy 連接埠章節繼續排查,不要一再更換解析位址。常見連線問題也可在常見問題依現象查閱。
03 / 連線觸發
On Demand 按需連線
On Demand 用於依條件觸發 VPN 連線,不是另一種規則分流寫法。它回答的是「何時嘗試建立連線」,Global Routing 與 Config 則決定「連線建立後如何處理請求」。因此,啟用 On Demand 不會自動修正錯誤的伺服器參數,也不會替你選擇合適的規則。設定前請先透過手動連線確認既有伺服器可用,再考慮將已驗證的連線交由條件觸發。
預設狀態以目前設定為準
不要根據其他裝置的截圖推斷 On Demand 的預設狀態。初次安裝、還原系統資料、重新加入 VPN 設定,以及修改 App 內的條件,都可能影響目前看到的狀態。請在 Shadowrocket 中確認開關與條件,再到系統的 VPN 相關設定確認對應項目。若裝置上保留多份 VPN 設定,還要先確認目前操作的確實是 Shadowrocket 使用的設定,避免修改到其他舊記錄。
首次啟用連線功能時,系統可能會要求允許加入 VPN 設定。這是讓系統登錄連線設定的授權步驟,不是購買確認,也不代表伺服器已通過驗證。請閱讀系統提示並確認來源後再操作;若取消授權,請依 App 介面指引返回並重新發起。不了解影響範圍時,不要刪除其他系統設定;受管理裝置也可能有需要管理員處理的限制。
依網路條件設計,不要憑猜測層層堆疊條件
若目前介面提供 Wi-Fi、行動網路或指定網路等條件,請逐項閱讀其觸發說明。辨識出某個 Wi-Fi 名稱,不代表已了解該網路的所有屬性,也不保證連線後立即可以上網。公共網路可能需要先完成接入確認,網路名稱也可能重複。建議先使用簡單且容易理解的條件,再依實際需要增加例外,不要一次設定許多彼此重疊的條件。
測試時至少觀察三個階段:接入網路後是否符合條件、系統是否嘗試連線,以及連線後能否完成目標請求。只看到開關變成開啟,無法證明最後一個階段已成功。請記錄切換前後的網路類型與時間,再查看 App 狀態及 Log;若觸發成功但業務請求失敗,應檢查連線參數與路由,不要繼續修改觸發條件。這樣可避免兩個層次的問題互相掩蓋。
手動中斷與再次觸發
啟用條件觸發後,手動中斷不一定代表之後都會維持中斷。網路條件再次符合時,系統可能重新嘗試連線。若要暫時停止自動行為,請先暫停 On Demand,再處理目前連線,並確認系統顯示的狀態。排查「剛中斷又重新連線」時,先檢查條件是否仍然有效,不要立刻認定開關故障。測試完成後再恢復需要的條件。
| 測試階段 | 操作 | 判斷依據 |
|---|---|---|
| 手動基準 | 暫停條件觸發,手動連線 | 目標請求可正常完成 |
| 條件觸發 | 只啟用一組明確條件 | 系統開始嘗試連線 |
| 切換網路 | 切換至另一個實際網路 | 條件與連線狀態相符 |
休眠、切換網路與異常恢復
裝置休眠、Wi-Fi 與行動網路切換,以及網路短暫中斷,都可能導致現有連線中斷或重新建立。On Demand 無法消除這些基本條件變化,也不能保證連線始終不中斷。切換網路後短暫失敗時,請先等待系統完成網路接入,再查看是否有重新連線的記錄;若網路本身尚未恢復,反覆切換 App 開關通常只會產生更多失敗記錄。
建議設定取決於使用需求。需要自動觸發時,請先確認手動基準穩定,再啟用最低限度的必要條件;需要可控的排錯環境時,則暫時停用條件觸發,確保每次測試只對應一次連線動作。不要把「全部開啟」當成通用建議。省電、背景狀態與連線穩定性之間,也沒有適用於所有裝置的固定設定;評估時應以實際使用記錄為準。
若問題只在自動觸發時發生,請保留一次手動連線成功與一次自動連線失敗的記錄,比較網路條件、選取的伺服器及目前 Config。若兩次條件相同但結果不同,再逐項檢查系統設定與 App 狀態。需要重新完成首次授權及連線驗證時,請依教學流程操作;測試 On Demand 時,不要同時變更 DNS、規則與協定類型。
04 / 可連線性測試
Ping 與 Connectivity Test
Ping 與 Connectivity Test 提供的是特定測試條件下的結果,並非對伺服器品質的完整結論。測試能確認某項探測是否在指定時間內完成,卻不能取代實際業務請求。數值較低,不代表所有頁面都會更快;發生逾時,也不能單憑這點判定伺服器設定失效。請先確認測試方式、測試目標與目前網路,再解讀數值代表的意義。
先確認測試涵蓋哪些階段
不同測試方式涵蓋的連線階段並不相同。基本可連線性探測、連接至指定連接埠的嘗試,以及透過代理存取目標位址,各自依賴的條件都不同。具體測試方式以目前 App 介面為準,不應只憑「Ping」這個名稱推斷它一定使用某種協定。了解探測經過哪些階段,才能判斷成功或失敗能排除哪些可能性,又有哪些無法排除。
例如,成功連線至伺服器連接埠,不代表後續認證、TLS 協商及目標存取也都成功;透過代理成功存取某個測試目標,也只代表該目標當時可連線。伺服器可能允許一種探測、限制另一種,測試目標本身也可能暫時異常。因此,若出現「測試通過但網頁無法開啟」,請查看 Log 中的實際請求,而不是只重複測速。
預設目標、逾時與並行測試
請直接在目前裝置查看預設測試目標、逾時與並行測試設定;還原既有設定後,狀態不一定與初始值相同。若沒有明確問題,建議保留 App 目前的測試設定。需要更換目標時,請選擇自己能說明用途、且可在目前網路條件下驗證的目標;不要使用含登入資訊或私人權杖的位址作為測試入口,也不要用單一業務的存取結果代表所有業務。
逾時指本次測試允許等待的時間,不是為連線分配更多頻寬。設定過短可能把暫時波動判定為失敗,設定過長則會拖慢批次檢查。並行數量過高也可能消耗有限的網路資源,讓多項測試彼此競爭。建議先以少量伺服器和相同測試目標建立基準,再視需要調整;不要為了追求更低數值而反覆切換所有參數。
| 觀察結果 | 可能的意義 | 下一步 |
|---|---|---|
| 單次逾時 | 探測未能在時限內完成 | 在相同條件下重測並查看記錄 |
| 數值明顯波動 | 網路、負載或目標狀態變化 | 降低並行數量,保留多次記錄 |
| 測試成功,業務請求失敗 | 探測未涵蓋業務流程的所有階段 | 檢查實際請求與命中策略 |
分別比較延遲、傳輸量與穩定性
延遲描述單次互動的等待時間,傳輸量關注持續傳輸能力,穩定性則需要觀察一段時間內的失敗與波動。三者彼此相關,卻不能互相取代。頁面載入還包含 DNS、建立連線、加密協商、伺服器處理及資源載入等階段;一次探測只涵蓋其中一部分。選取伺服器時,請考量自己實際需要的存取情境,不要只依某個數值排序。
更有意義的比較方式是控制條件。維持相同裝置、網路、目標與測試方式,分別記錄多次結果及失敗情況。切換 Wi-Fi 與行動網路後,應將結果視為另一組資料,不要直接混在一起比較。測試期間若背景正在同步或大量傳輸,也請在記錄中註明,否則無法判斷波動來自伺服器還是本機資源競爭。
失敗時的分項檢查
所有伺服器都同時失敗時,先確認裝置是否確實連上網路、網路是否仍待接入確認,以及測試目標是否可用。若只有一個項目失敗,再核對該項目的位址、連接埠與協定參數。若既有訂閱剛更新,請確認測試的是更新後目前使用的項目,而非手動保留的舊副本。不同協定所需參數不同,不要為了讓測試通過而隨意改成另一種類型。
建議調整前後各進行一組條件相同的測試,再以實際請求確認結果。若數值改善但業務問題沒有變化,就不應把這項調整視為修復。需要檢查 Trojan 認證與 TLS 欄位時,可閱讀Password、SNI 與 Allow Insecure 參數說明。協定欄位應以既有伺服器資訊為準,測試失敗並不是降低憑證驗證要求的理由。
最後請保留一份可重現的記錄:測試時間、網路類型、項目名稱、測試方式、目標與結果。記錄不必包含密碼或訂閱位址,使用自己看得懂的代稱即可。這類資訊比「有時快、有時慢」更有助於後續排查,也方便在變更設定後判斷是否真的有可重現的改善。
05 / 請求證據
Log 與連線排查
Log 的用途是將連線狀況拆解成可檢查的階段,而不是看到錯誤字樣就立刻更換所有設定。一次失敗可能發生在解析、規則選擇、伺服器連線、認證、TLS 協商或目標回應階段。先找到與實際操作相符的記錄,再確認失敗發生在哪一層,才能判斷應修改 DNS、Config 或伺服器參數。不同介面的記錄詳細程度可能不同,請以目前 App 顯示為準。
預設記錄狀態與啟用範圍
請在目前裝置確認記錄開關、記錄層級與儲存方式,不要把某次安裝時的畫面當成固定預設值。日常使用建議保留足以進行基本檢查的設定;只有在重現問題時才提高詳細程度,並在結束後恢復原狀。更詳細的記錄會增加閱讀量,也可能包含更多請求資訊。啟用記錄不代表能補回所有歷史請求,因此請先安排好測試步驟,再發起目標操作。
有效的問題重現應盡量簡短。先記下目前時間、網路類型、Global Routing、Config 與選取的伺服器,接著只存取一次目標,再立即查看相關記錄。不要同時開啟許多 App 或反覆重新整理大量頁面,以免背景連線淹沒目標請求。若 App 提供篩選或搜尋功能,可依網域、時間或連線資訊縮小範圍,但不要只憑模糊的名稱就認定找到的是同一次連線。
依連線階段閱讀,不要只憑錯誤字樣猜測
先查看請求的網域或位址,再確認採用的策略與伺服器。若命中 DIRECT,但原本預期使用 PROXY,請先回到 Config 檢查規則順序;此時更改伺服器密碼沒有幫助。若策略符合預期,再檢查解析是否完成、是否曾嘗試連線,以及後續是否出現認證或交握錯誤。記錄中沒有某個階段的資訊,不代表該階段一定沒有發生,也可能只是目前的記錄層級未顯示。
| 階段 | 檢查內容 | 優先處理位置 |
|---|---|---|
| 規則選擇 | 網域、位址與命中策略 | Config、Global Routing |
| 基本連線 | 伺服器位址與連接埠可連線性 | 網路與伺服器項目 |
| 認證與交握 | 認證資料、時間、TLS 名稱 | Add Server 中的對應欄位 |
| 目標回應 | 目標是否回傳有效回應 | 目標服務與實際業務請求 |
連線逾時表示等待超過時限,可能是路徑不通、連接埠無法連線或遠端沒有回應,但無法據此判定原因出在哪一方。遇到認證錯誤,請先核對既有伺服器提供的認證資料,並留意複製時的空格與欄位對應。TLS 相關錯誤則應檢查伺服器名稱、憑證及裝置時間等條件;不要把啟用 Allow Insecure 當成通用修復方式,因為這會改變憑證驗證範圍。
Data 與 Log 不能互相取代
Data 中的統計與 Log 中的請求細節用途不同。統計可協助觀察一段時間內的流量變化,但無法單獨說明某個頁面失敗的原因;請求記錄可協助定位階段,卻不一定等同完整的業務流量帳單。也不要將 App 統計直接當作既有服務的計費依據,兩者的統計口徑、時間範圍與計算方式可能不同。排錯時,請優先使用與問題相符的證據。
若前景頁面失敗,卻找不到對應記錄,請先確認是否使用預期的連線方式、是否仍在沿用舊連線,以及是否在請求前啟用記錄。接著確認目標請求的實際網域,因為頁面重新導向或載入資源時可能使用不同名稱。不要只因搜尋不到頁面標題,就斷定請求沒有經過 App;記錄通常依網路連線資訊整理,而非網頁上顯示的標題。
匯出、去識別化與還原
記錄可能包含存取網域、IP 位址、網路名稱與連線識別資訊,匯出前請檢查內容。不要公開訂閱位址、認證欄位及其他可重複使用的連線資訊。即使只截取一小段,也請確認前後文沒有敏感值;保留錯誤階段與欄位結構通常已足以說明問題,不必附上完整設定。本文示例中的 example.com 不能取代對真實記錄進行人工去識別化。
修復後,必須重新執行原先失敗的操作,並確認新記錄中的路徑符合預期。若只是錯誤消失,卻改用了另一項策略或另一台伺服器,應確認這是條件變更,不能直接證明原問題已解決。仍無法定位時,可依常見問題的故障分類繼續縮小範圍;涉及網域拒絕策略時,請參閱REJECT 的作用與範圍,避免將主動拒絕誤判為網路故障。
06 / 監聽與遠端
Proxy 連接埠與協定參數
首先必須區分連接埠的歸屬。Add Server 中的遠端連接埠屬於既有伺服器的連線資訊;本機 Proxy 相關設定中的監聽連接埠,是裝置上的代理入口;業務請求還會連線至目標服務自己的連接埠。即使三者的數值剛好相同,也不是同一項設定。修改本機監聽連接埠無法修正遠端服務連接埠填錯的問題;修改遠端連接埠,也不會讓尚未啟用的本機入口自動變得可用。
依既有伺服器資訊填寫遠端參數
伺服器類型、位址、連接埠與認證欄位必須一併核對。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard、HTTP 與 SOCKS5 的參數結構各不相同,沒有一套通用欄位能直接套用於所有協定。請依使用者既有的伺服器說明選擇類型,再逐項填寫;不清楚的欄位不要憑其他協定的經驗猜測,也不要只因某種類型比較熟悉就更改類型。
連接埠數值只代表連線目標的一部分,不能單獨判定協定類型或 TLS 狀態。即使兩項服務使用相同的常見連接埠,也可能需要完全不同的認證與傳輸方式。涉及 TLS 的設定,還應分別核對伺服器位址與用於名稱驗證的欄位,不能假設兩者永遠相同。欄位說明請參閱Trojan 參數說明,不要靠試填不同密碼來判斷。
| 連接埠歸屬 | 設定來源 | 修改後的影響 |
|---|---|---|
| 遠端伺服器 | 使用者既有的伺服器資訊 | 連線至伺服器的入口 |
| 本機 Proxy | 目前 App 設定與呼叫端設定 | 裝置上可用的代理入口 |
| 目標業務 | 目標服務與存取位址 | 最終請求所連線的服務入口 |
本機監聽的預設值與調整建議
本機 Proxy 功能可用的入口、監聽位址與連接埠,應以目前 App 介面提供的選項為準。本文不指定固定的預設連接埠,也不要求照抄其他裝置的設定。若沒有明確的本機代理呼叫需求,建議保留原設定,不要為排查一般網頁存取而額外啟用監聽。確實需要調整時,請先記錄原值,並確認使用該入口的 App 也已同步更新位址與連接埠。
有效的連接埠還需要搭配監聽位址與協定類型一起判斷。迴路位址通常表示僅供本機存取;區域網路位址則涉及其他網路裝置,擴大監聽範圍會改變可存取範圍。若介面提供區域網路存取相關選項,請在明確了解用途後才啟用,並確認網路環境。不要只為了讓測試通過就擴大範圍,也不要將系統 VPN 設定與區域網路代理共用視為相同機制。
連接埠衝突與連線方式不相符
若呼叫端提示無法連線至本機代理,請先確認 Shadowrocket 中對應入口確實可用,再核對監聽位址、連接埠與協定。HTTP 代理入口與 SOCKS5 入口的使用方式不同,呼叫端必須符合設定;對某個連接埠任意傳送請求,無法驗證所有協定。若懷疑連接埠已被占用,請依目前介面的錯誤提示確認,不要連續更換遠端伺服器。
修改監聽連接埠後,呼叫端原有設定不會自動套用新的數值。瀏覽器、測試工具或其他支援代理設定的 App,可能仍保留舊的連線位址。請先停止舊測試,再更新呼叫端設定並重新建立連線。若同時保留系統層連線與 App 內獨立的代理設定,也要確認測試實際經過哪條路徑,避免重複設定讓結果難以判讀。
分別處理連線參數與安全驗證
設定 VMess 與 VLESS 時,請依既有伺服器資訊核對 UUID、傳輸方式及相關欄位,不要只看名稱;兩者使用的參數並不相同。WireGuard 則須依其金鑰、對端與位址資訊設定,不能視為只需密碼與連接埠的項目。相關概念請參閱VMess 與 VLESS 的差異及協定術語表。這些連結用於說明欄位,不提供連線資源。
建議的排查順序是先確認裝置可連上網路,再核對遠端資訊,接著檢查協定認證與交握,最後才檢查確實參與測試的本機監聽入口。每次調整後,只使用相同目標重新測試,並在 Log 中確認實際路徑。若既有訂閱更新了連接埠或認證資訊,請先確認選取的項目是否已更新,不要混用舊的手動副本與新的訂閱項目。沒有證據時保留預設狀態,比同時修改多個連接埠更容易定位問題。
07 / 狀態入口
Widget 與系統狀態
Widget 是查看狀態或觸發 App 所提供操作的快捷入口,不是獨立的連線引擎。它能顯示及執行哪些內容,取決於目前系統、App 提供的元件與所選的元件樣式。不要依據其他裝置的版面推斷自己的裝置一定有相同按鈕,也不要將元件上顯示的狀態視為目標請求已成功的證明。若要確認連線狀況,請返回 Home 並實際發起請求。
新增前先建立 App 內的基準狀態
建議先在 Shadowrocket 中完成伺服器選擇、確認 Global Routing 並驗證手動連線,再新增 Widget。元件不能取代首次匯入,也無法補齊缺少的認證資訊。首次使用相關操作時,若系統要求進入 App 完成授權,請依提示返回 App 處理。反覆點擊元件無法略過必須在前景完成的步驟,也可能讓多次狀態變化難以分辨。
新增位置與元件尺寸由系統提供的編輯介面決定。選取 Shadowrocket 後,請查看目前可用樣式的說明,再選擇適合檢視的內容。本文不指定固定的預設尺寸或版面,因為這些項目會隨裝置與系統功能而異。新增元件後,先確認靜態資訊是否與 Home 一致,再測試它提供的操作;首次同步顯示尚未完成前,不要就此判定元件失效。
更新延遲不代表連線失敗
元件顯示會受到系統更新機制影響,不一定會在每次連線狀態變更後立即更新。背景狀態、省電條件與系統排程都可能影響更新時間。因此,元件與 App 內狀態短暫不一致時,請先開啟 App 確認,再透過實際請求驗證。刪除後重新新增元件只是介面層的處理方式,不應作為所有連線問題的第一步,也不能取代檢查實際連線記錄。
| 檢視位置 | 適合確認 | 仍需補充確認 |
|---|---|---|
| Widget | 快捷入口與元件顯示 | App 內目前狀態 |
| Home | 選取項目與連線操作 | 實際業務請求結果 |
| 系統 VPN 狀態 | 系統連線設定狀態 | 規則與伺服器可用性 |
| Log | 請求階段與策略資訊 | 使用者實際操作時間 |
與 On Demand 的關係
若 On Demand 正在生效,透過 Widget 中斷連線後,網路條件再次符合時可能會觸發新的連線嘗試。這不是元件另有一套隱藏設定,而是條件觸發仍在運作。若要驗證元件的單次操作,請先暫停 On Demand,再觀察點擊前後的 Home 與系統狀態;測試結束後恢復原有條件。不要同時變更自動觸發與元件版面,否則很難判斷是哪個步驟造成結果改變。
同樣地,切換目前的伺服器或 Config 後,元件顯示的項目可能需要更新才會反映變化。請先以 App 內的選擇為準,再等待或使用系統提供的正常方式更新。若點擊元件後開啟了 App,請在前景確認實際操作結果,不要只看系統頁面是否關閉。快捷入口減少的是操作步驟,不會減少驗證連線所需的條件。
顯示內容與隱私範圍
Widget 可能放在他人看得到的螢幕位置。若元件顯示伺服器名稱或連線狀態,命名時請避免包含私人帳號、用途說明或可重複使用的連線資訊。分享裝置畫面前,也請檢查元件區域,不要只檢查 App 視窗。元件不能取代訂閱憑據的安全保管,也不要把完整訂閱位址寫入項目名稱,方便辨識。
日常使用時,建議只顯示符合需求的最少資訊,並保留 App 內可辨識但不敏感的名稱。若不需要快捷操作,不新增元件也不會影響已設定的手動連線。發生顯示異常時,先記錄 App 內狀態、系統狀態與元件內容之間的差異,再確認系統是否仍保留該元件。只有問題侷限於顯示層時,才進一步考慮重新新增,不要因此重設網路設定。
請區分三種常見現象:元件未更新時,優先確認顯示狀態;元件操作未完成時,檢查是否需要在前景授權;連線確實建立但存取失敗時,返回 DNS、Config 與 Log 排查。依此順序處理,可避免因顯示狀態過期而反覆中斷正常連線。若問題只在切換網路後發生,請搭配On Demand 章節觀察條件變化;若首次連線尚未完成,請先返回教學頁完成主要流程,再處理快捷入口。
08 / 資料還原
iCloud 同步與設定還原
iCloud 相關功能可在 App 支援範圍內同步或還原資料,不代表所有裝置上的所有狀態都會完全一致。請先在目前介面確認可同步的項目、開關與操作說明,再決定是否啟用。伺服器項目、設定檔、系統 VPN 授權、目前網路與連線狀態屬於不同層次;即使某類資料已同步,其他層次仍可能需要在目標裝置上另外確認。
預設狀態與系統前置條件
預設同步狀態以目前 App 與系統設定為準。使用前請確認裝置登入的是預期的 Apple 帳號、系統允許 App 使用相關 iCloud 功能,且目前網路能完成同步。不要因為開關已開啟就認定資料已全部上傳,也不要只因另一台裝置暫時沒有顯示內容,就立刻重複匯入。同步仰賴系統狀態,應搭配查看 App 內記錄與系統介面。
取得 App 與還原設定是兩件不同的事。更換裝置後,請先透過 App Store 取得 Shadowrocket,再處理資料與首次連線授權;系統需求、裝置相容性與購買適用性請以 App Store 頁面標示為準。正版入口的確認方式請參閱正版三項確認,已購項目的還原方式請參閱更換裝置與重新取得說明。本站不會以同步功能推論跨裝置的購買適用性,兩者應分別確認。
先選定基準裝置,再處理多裝置修改
啟用同步前,請先決定哪台裝置保存要保留的完整設定,並儲存一份容易辨識的副本。不要在兩台裝置上同時編輯同一份重要內容,再假設系統一定會依照你的預期合併。若兩端已有不同版本,請先比較檔案與項目,再決定保留哪一份;同步不能取代人工檢視。對用途不明的重複記錄,也不要在確認前批次刪除。
建議使用清楚的名稱區分日常設定、測試副本與還原副本,但不要在名稱中寫入密碼或訂閱權杖。還原到新裝置後,請先核對項目數量、重要欄位與 Config 內容,再選擇目前使用的伺服器與 Global Routing。即使名稱相同,內部欄位仍可能不同;只看清單標題無法確認還原完整,更無法證明伺服器仍可使用。
同步、備份與訂閱更新的差異
同步可能會將修改傳播至其他裝置,因此不能簡單視為永遠保留舊狀態的備份。訂閱更新則用於取得既有訂閱提供的項目資訊,不負責判斷本機手動修改應如何合併。需要長期保留的設定,應使用目前 App 提供的匯出或備份方式另行儲存,並明確確認保管位置與存取權限;刪除任何雲端或本機內容前,請先確認副本確實可讀取。
| 操作 | 主要目的 | 完成後檢查 |
|---|---|---|
| iCloud 同步 | 在支援範圍內傳送資料 | 目標裝置內容與目前選擇 |
| 設定備份 | 保留可還原的副本 | 檔案可讀取性與儲存範圍 |
| Subscribe 更新 | 更新既有訂閱資訊 | 目前項目與手動修改 |
| App Store 還原 | 重新取得已購 App | 帳號與商店購買狀態 |
新裝置驗證與敏感資訊保管
還原後應重新執行最基本的驗證流程:確認裝置已連上網路、檢查選取項目、核對 Config、依系統提示完成 VPN 設定授權,再發起一次實際請求。手動基準正常後再測試 On Demand,App 內狀態正常後再檢查 Widget。如此可區分資料缺漏、授權未完成與伺服器失效,避免因一次連線失敗就認定整個同步流程有問題。
匯出的設定可能包含伺服器位址、密碼、金鑰或訂閱權杖,請視同連線憑據妥善保管。傳送診斷資訊時,只保留必要結構,不要公開完整檔案。本文不會對特定同步項目的加密方式或保留期限作出超出目前介面說明的承諾;若要了解資料處理範圍,請一併閱讀隱私權政策與系統提供的相關說明。刪除前也請確認該操作是否會影響其他裝置。
需要還原時,先暫停會持續產生變動的操作,再還原已確認的副本,接著逐項檢查 DNS、On Demand、測試設定與目前路由模式。不要一開始就選擇「全部還原預設值」,否則會失去判斷故障來源的線索。完成後保留簡短的變更記錄,註明修改項目、原值、新值與驗證結果。下次遇到問題時,從最後一次正常運作的狀態開始排查,比重新試遍所有設定更容易得出明確結論。