Settings 設定項目參考

01 / Scope

設定範圍與目前值核對

區分 Settings、Config 與系統授權

Settings 並非連線行為的唯一來源。需要核對的內容可分為三層：應用程式層儲存測試方式、記錄及部分通用偏好設定；Config 儲存規則和設定檔中的相關參數；系統層則決定 VPN 設定授權、網路存取條件及 iCloud 是否可用。伺服器項目也有自己的位址、連接埠與協定欄位。遇到問題時，先判斷屬於哪一層，再尋找對應的設定入口。修改 Settings 無法修正伺服器位址的拼字錯誤，切換 Config 也不能取代系統提示中的授權確認。

看似沒有變動的設定，實際請求路徑仍可能不同。例如 Home 選取的伺服器變更、Global Routing 從 Config 切換至 Proxy，或裝置從 Wi-Fi 切換至行動網路，都會改變測試條件。查閱任何章節前，先記錄目前網路、所選伺服器、Global Routing 模式及目前 Config 名稱。這四項是比較結果的基本背景資訊。若沒有記錄，光憑「昨天可以、今天不行」，很難分辨是設定、網路還是遠端狀態發生變化。

預設值、目前值與建議值並不相同

預設值是特定安裝狀態下尚未修改的初始設定；目前值是此刻頁面顯示或設定檔儲存的值；生效值則是實際請求最後採用的設定。還原備份或同步資料後，目前值可能來自舊裝置，不再等同初始預設值。本文對可變項目的建議起點是「保留目前可用的值」，尤其不建議只為了對照手冊而重置整個應用程式。若欄位顯示自動、空白或繼承，也別立刻將它視為關閉；先確認是否代表交由設定檔或系統決定。

建立可還原的修改紀錄

修改前先儲存目前設定的副本，並以私人紀錄註明項目名稱、原值、新值、修改原因及驗證結果。設定副本可能包含伺服器憑證，請勿放在公開筆記中。一次只變更一個變數，例如先改測試方式，不要同時修改 DNS。修改後儲存；如有需要，請在可中斷連線的時段中斷再重新連線，並重新對同一個目標送出請求。若結果沒有改善，就還原原值，不要繼續疊加修改。如此才能保留清楚的因果脈絡。

驗證時要區分「設定已儲存」和「設定已實際套用」。介面能返回上一頁，只代表編輯動作完成，不代表舊連線已重新建立；瀏覽器成功顯示頁面，也可能是因為快取。重要修改應使用新的請求，並在 Log 中核對相應時間。若涉及系統授權，請檢查系統 VPN 狀態，不要只看應用程式開關的顏色。無須為了查詢預設值而刪除應用程式，因為刪除可能同時影響本機設定與紀錄，也無法保證還原先前可用的組合。

若問題只發生在特定目標，優先檢查該目標的規則；若所有目標都失敗，再核對伺服器、網路與 DNS 解析。若不確定購買頁面或應用程式身分，請先查看正版核驗三要素。設定參考不會改變購買適用範圍，也不能取代正確的伺服器資訊。常見症狀的簡要解答集中在問答頁，可先判斷問題類型，再回到本頁逐項查閱。

02 / DNS

DNS 解析與規則的關聯

先區分目標網域與伺服器網域

DNS 會將網域名稱轉換成連線所需的位址。一次代理請求至少可能涉及兩類解析：裝置必須先找到伺服器網域對應的位址，之後也需要在相應路徑上解析目標網域。前者失敗時，代理連線可能根本無法建立；後者失敗時，則可能出現伺服器測試有回應、特定網站卻無法開啟的情況。因此，「更換 DNS」不是處理所有連線錯誤的通用方法；必須先確認是哪個網域解析失敗，以及解析發生在建立連線之前還是之後。

Settings 中與 DNS 相關的選項，必須搭配目前 Config 的內容一起檢視。若正在使用的設定檔指定了 DNS 或相關行為參數，就不能只看單一頁面判斷最後採用的解析方式。預設狀態以目前介面與生效中的設定為準；本文不指定適用於所有網路的公開位址。建議從目前可用的設定開始，保留設定檔明確指定的內容；只有在 Log 顯示解析逾時、回傳異常位址或解析路徑不符預期時，才針對該項排查。

依輸入格式核對，勿混填位址與協定

DNS 欄位可能接受位址、伺服器清單或應用程式支援的特定格式，請以欄位說明及實際可選項目為準。一般位址與含協定的解析位址不能任意互換。輸入前請確認是否需要協定前綴、是否含多餘空格、分隔方式是否正確，以及目前網路能否連至該解析服務。不要直接把網頁網址當成 DNS 位址，也不要看到加密傳輸字樣就認定目前網路一定可用。解析服務本身同樣需要建立網路連線。

若伺服器位址使用網域名稱，也要考慮解析依賴關係。若某個解析端點必須透過尚未建立的代理才能存取，而建立代理又依賴它解析伺服器網域，就可能在啟動階段形成循環依賴。遇到這類問題時，先還原原本的解析設定，確認伺服器網域可在建立連線前取得有效結果，再單獨驗證目標網域的解析路徑。不要直接把某次查到的位址永久填入伺服器項目；遠端位址可能變動，部分協定也依賴正確的名稱驗證。

DNS 與規則比對順序的影響

網域類規則與位址類規則判斷的對象不同。DOMAIN-SUFFIX 可直接比對網域後綴；GEOIP、IP-CIDR 等規則則與位址有關。為判斷位址規則是否符合，處理過程可能需要取得解析結果。若只想讓特定網域使用指定策略，通常應將明確的網域規則放在較廣泛的位址判斷之前，而不是先增加多項 DNS 修改。規則會依序處理；前面的規則已符合時，後續範例不會再為同一請求選擇策略。

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

上述片段僅用於說明規則關係，不是完整連線設定。example.com 與 example.org 是示範網域，PROXY、DIRECT 是策略關鍵字。使用前請確認目前設定檔支援相應策略，並在 Global Routing 的 Config 模式下驗證。此處未指定 DNS 伺服器，因此不能從這幾行推斷解析請求一定會走哪條路徑。若想了解其他比對對象，請參閱規則語法與比對順序說明。

解析問題的驗證與還原

先在相同網路和相同伺服器下，對可穩定重現問題的目標重送請求，記下時間，再查看 Log 是否出現解析逾時、名稱解析失敗或後續連線失敗。若解析成功但連線逾時，應轉而檢查位址可達性；若名稱解析失敗，則繼續核對解析端點與網路條件。修改 DNS 後，舊快取不一定會立即消失；複測時應建立新連線，也不要把快取頁面當成成功證據。若沒有明確改善，請還原原值並保留測試紀錄，不要連續更換多個端點。

03 / On Demand

On Demand 自動連線條件

自動觸發不代表保證連線

On Demand 依據已設定的條件，要求系統建立 VPN 連線。它解決的是「何時嘗試連線」，並非「伺服器是否有效」，也不保證所有應用程式流量都能持續連線。啟用前應先手動完成一次連線，確認 Home 中的預設伺服器、Global Routing 與 Config 均符合預期，再透過 Connectivity Test 和實際目標存取進行驗證。若手動連線尚未成功，自動觸發只會重複同一個失敗過程，讓問題看起來更頻繁，無法修正位址或驗證資訊錯誤。

開關的初始狀態、可選條件及既有規則，以目前介面為準；從舊裝置還原後，尤其要檢查是否沿用了先前的條件。建議先由手動控制開始，連線穩定後再依明確情境啟用自動連線。若需要自動連線，請逐項閱讀條件，確認其適用於網路環境、請求觸發或其他可設定範圍。不要將單一條件名稱解讀為適用所有網路，也不要假設清單後面的項目必定能覆蓋前面的行為。

依網路切換建立測試矩陣

自動連線在 Wi-Fi 與行動網路切換、離開某個無線基地台或裝置喚醒後，可能有不同表現。測試前先明確寫下預期結果，例如在指定網路中維持現狀，在其他允許的網路中要求連線。每次只切換一個條件，等待系統完成網路變更，再查看系統 VPN 狀態與應用程式紀錄。切換後短暫中斷連線，不一定代表規則錯誤；應搭配觸發時間和後續狀態判斷。反覆切換網路會讓多種狀態變化交疊，反而難以找出問題。

為什麼關閉後又重新連線

若手動中斷後系統又嘗試建立連線，先檢查 On Demand 是否仍啟用，以及目前條件是否持續成立。手動中斷與自動規則是兩種不同的控制來源；前者不一定會取消後者。若要暫時停止自動行為，應先在應用程式中關閉相關的自動連線設定，再中斷連線並觀察系統狀態。若仍反覆發生，請核對系統目前使用的 VPN 設定，避免將另一份保留設定的行為誤認為目前編輯頁面的結果。

裝置可能儲存多個 VPN 設定描述檔；應用程式頁面顯示的選擇必須與系統目前啟用的設定相符。檢查時不要直接刪除所有設定，先確認名稱、來源及目前狀態。系統授權提示允許應用程式建立相關設定，不代表所有自動連線條件都已設定完成。受機構管理的裝置，其部分網路或 VPN 行為也可能受到系統管理政策限制；應用程式內的開關無法取代這些系統要求，處理時請遵守裝置管理規定。

登入網路與還原策略

需要先開啟網路登入頁面的 Wi-Fi，可能尚未具備完整的存取條件。合法完成網路驗證前，即使自動連線觸發正確，也可能無法連至伺服器。遇到這種情況，可暫時停止自動嘗試，依系統允許的流程完成網路登入，再還原原有條件並重新測試。不要透過不斷修改伺服器協定參數來處理尚未完成網路登入的問題，因為問題發生在代理連線之前；修改協定只會增加新的變數。

建立自動規則後，至少驗證正常進入條件、離開條件及手動暫停三種情況，並保存原有設定。系統狀態、觸發紀錄及實際存取結果應能互相印證。若規則太複雜，先回到最少條件，再逐項加回；每次加回後都進行一次網路切換測試。與自動觸發無關的首次連線步驟，請參閱預設伺服器選擇與 Connectivity Test；排查 On Demand 無須重新執行整套匯入流程。

04 / Ping

Ping 與 Connectivity Test

測試結果僅代表相應的測試路徑

Ping 相關設定會影響清單測試採用的方式、目標或等待條件，實際欄位請以目前介面提供的選項為準。清單中的回應時間不是完整的網路品質評分，也不等同瀏覽網頁所需的全部時間。一次請求還可能包含名稱解析、建立連線、協定交涉、遠端處理及內容傳輸等階段。測試方式不同，涵蓋的階段也不同，因此不能直接比較兩種方法得出的數值，更不能只憑最低數值判斷某台伺服器適合所有用途。

預設測試方式與逾時設定以目前設定為準；同步還原或先前手動修改都可能改變這些項目。建議先保留原有測試參數，選擇一台穩定的既有伺服器建立基準，再修改單一項目觀察差異。若目前介面支援 TCP 或其他連線類測試，結果主要反映相應連線能否在等待時間內建立；若使用需要向目標送出請求的測試方式，測試目標本身是否可用也會影響結果。測試失敗可能是目標失敗，不一定代表伺服器項目無效。

固定目標、網路與時間範圍

比較前應固定測試目標、目前網路、測試方式及伺服器項目，並盡量在相近時間完成。從 Wi-Fi 切換至行動網路後，比較條件已經改變；直接比較白天與高流量時段的結果，也難以判斷設定是否有所改善。可以少量重複測試，觀察結果是否穩定，但不必高頻率連續送出請求。測試本身會產生流量與連線，過度測試可能影響正在使用的連線，也會放大短暫波動，導致錯誤結論。

逾時表示測試未能在限定等待時間內完成，不代表位址永久無法連線。等待時間太短，可能排除較慢但可用的路徑；太長則會讓失效項目延遲很久才回報結果。本文不提供通用秒數，建議先使用介面原值，再依實際測試目的調整。若多個項目都逾時，先確認裝置網路與測試目標，不要逐一重寫伺服器欄位。若只有單一項目異常，再核對該項的位址、連接埠、驗證資訊及服務狀態。

分開驗證清單測試與實際連線

清單中有回應，不代表該項目已選為預設伺服器。先在 Home 選取要使用的伺服器，確認選取標記，再檢查 Global Routing 模式。接著建立連線，使用 Connectivity Test，並存取能穩定重現問題的目標。如此可分別確認「項目可供測試」、「目前選取正確」及「連線路徑可用」三件事。若只完成第一項，很容易把未選取的伺服器測試結果誤認為目前連線狀態。

回應正常但實際存取失敗

出現差異時，先確認測試涵蓋哪些階段。若測試只到伺服器連接埠，驗證欄位仍可能錯誤；若測試目標可存取，實際目標可能符合另一條規則。接著檢查 DNS、目標網域的策略，以及 Log 中的錯誤階段。不要只憑回應時間反覆切換伺服器，因為切換會同時改變遠端出口與連線狀態，讓原本的問題消失在新的測試條件中。保留一組可重現問題的條件，通常比蒐集更多測試數值更有用。

VMess、VLESS、Trojan、Hysteria2 等不同協定，即使連接埠可連線，也不代表所有協定參數都相符。有些項目還涉及傳輸層、名稱驗證或其他伺服器端約定，必須與使用者已有的伺服器資訊逐欄核對。協定欄位用途請參閱支援的協定與 Add Server 欄位概覽。本頁只說明測試設定，不依測試數值評價服務供應商，也不據此推薦任何節點。

05 / Log

Log 記錄與故障定位

先記錄時間，再重現一次請求

Log 用於比對連線過程中的事件與錯誤，但不是每一則資訊都代表故障。開始排查時，先記下裝置時間、目前網路、預設伺服器、Global Routing 與目前 Config，再只執行一項明確操作，例如連線後存取某個目標。接著查看時間相近的紀錄，依序檢查名稱解析、建立連線、協定處理及目標存取。若不加區分地翻閱整段記錄，容易把先前嘗試的錯誤與本次成功結果混在一起。

記錄開關、詳細程度與保留方式以目前介面為準；本文不假設所有安裝版本預設都會儲存相同內容。建議平時保留足以進行基本診斷的目前設定，排查時才暫時提高可用的記錄詳細程度，完成後再還原。詳細記錄可能包含更多存取中繼資料，也會增加儲存與閱讀負擔。若介面沒有某種記錄層級或匯出選項，不必尋找同名的隱藏入口，以實際提供的功能為準。

依失敗階段縮小範圍

若 Log 首先出現名稱解析錯誤，先檢查 DNS 與相關網域；若已取得解析結果但連線逾時，檢查位址、連接埠及網路可達性；若建立連線後出現驗證或協定相關錯誤，再核對伺服器欄位。若目標回傳錯誤回應，也要考慮目標服務本身。這不是對所有紀錄進行機械分類，而是減少無關修改的方法。沒有解析問題的證據卻先修改一組協定參數，或驗證失敗時不斷更換 DNS，都容易偏離真正的故障階段。

連線中斷也可能只是網路切換或手動中斷所致。閱讀紀錄時，請比對記錄時間與操作時間，確認是否發生在從 Wi-Fi 切換至行動網路、啟用 On Demand 或切換伺服器之後。每次相同操作都出現相似錯誤，才有較強的重現依據。偶爾出現一次且隨後恢復的紀錄，可先保留觀察，不必立即重置設定。若問題無法穩定重現，應記錄發生條件，而非用大量無關修改掩蓋現象。

核對規則符合情況，別混淆目標與策略

使用 Config 模式時，若 Log 提供策略或比對資訊，應核對實際目標是否符合預期策略。網域規則應放在可能先符合目標的廣泛規則之前，FINAL 則放在兜底位置。應用程式顯示的目標網域、實際連線位址與策略名稱是不同欄位，不能只看到熟悉的網域就認定請求使用了代理。若使用 Proxy 或 Direct 模式，應先了解目前模式的作用，再判斷規則是否「沒有生效」。

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

在這段範例中，example.com 本身先符合 DOMAIN 並使用 DIRECT；其子網域則可能符合後面的 DOMAIN-SUFFIX。這呈現的是具體條件優先時的結果，不代表出現兩條相關規則就一定互相衝突。修改時只調整需要變更的規則，並以相同目標重新驗證。若交換兩行順序，根網域可能會先符合後綴規則。只確認規則「存在」並不足夠，還要核對順序與實際請求名稱。

儲存與分享前，先處理敏感內容

Log 可能包含伺服器位址、目標網域、區域網路資訊、訂閱連結或驗證相關內容。公開求助前，應刪除完整訂閱網址及其查詢參數、驗證資訊、可識別個人的資料及不必要的存取紀錄。只遮住伺服器顯示名稱未必足夠，因為實際位址可能出現在後續行。最好只保留最小重現片段：時間範圍、錯誤階段、已遮蔽的相關欄位及已採取的操作，而不是傳送整份長期記錄。

不要為了整理 Log 而先刪除仍有價值的證據。可以先在私人位置保存必要片段，再依應用程式目前提供的方式清理紀錄。清理 Log 不等於清理設定，還原設定也不一定會還原 Log，兩者應分開管理。若 Log 為空，先確認記錄功能是否啟用、是否查看正確範圍，以及請求是否確實經過目前連線；沒有紀錄本身不能證明請求成功或失敗。常見錯誤的快速分類可從問答頁的故障排查分類開始。

06 / Widget

Widget 與系統狀態核對

便捷入口不能取代完整設定頁面

Widget 是系統提供的便捷資訊顯示或操作入口，可用樣式與功能以裝置系統及應用程式目前提供的元件為準。它適合查看有限狀態或執行支援的操作，不能取代 Home、Config 與 Settings 的完整核對。尤其剛匯入設定、切換預設伺服器或調整 On Demand 後，應先回到應用程式確認實際選擇，再使用 Widget。不能只憑元件上的文字，就推斷目前設定、策略與伺服器都已正確切換。

元件是否顯示、放置位置及採用尺寸由系統管理；應用程式內的相關偏好設定則可能影響元件可讀取或呈現的內容。請分別檢查這兩類設定。預設顯示方式以目前加入的元件及其設定為準，沒有適用於所有裝置的通用配置建議。建議先使用資訊最少且容易辨認的現有元件，只有確有需要時才增加其他入口，避免多個名稱相近的項目導致誤選舊項目或誤判狀態。

狀態延遲與連線狀態不同步

系統元件的更新時間由系統排程，不保證與應用程式頁面每秒同步。應用程式內已中斷連線，但元件仍顯示上一個狀態，或剛連線時尚未更新，都需要進一步核對。遇到差異時，請開啟 Shadowrocket 查看目前連線，並比對系統 VPN 狀態與一次實際請求，不要連續點擊元件試圖強制更新。反覆觸發連線與中斷，會產生新的狀態變化，讓原本只是顯示延遲的問題變成真正的連線中斷。

系統省電、裝置鎖定、背景排程及網路變動，都可能影響資訊更新時間。本文不保證固定更新間隔，也不建議只為了讓元件文字立即更新而長期變更系統電源策略。若元件持續顯示異常，先確認應用程式能否正常開啟並讀取目前狀態，再檢查是否需要重新選取元件的設定項目。若系統提供移除及重新加入功能，可記下原本配置後再試；這項操作只針對元件顯示，不應連帶刪除應用程式或重置連線設定。

區分所選伺服器與目前連線的伺服器

切換當下，Home 中的選擇、已建立的連線及 Widget 顯示的項目，可能各自處於不同階段。選取某個項目不代表舊連線已依新項目重新建立；元件顯示某個名稱，也不代表該項目目前可用。切換後應依應用程式目前的行為確認是否需要重新連線，再執行 Connectivity Test。若測試失敗，請回到 Ping、DNS 與 Log 章節排查，不要把問題全歸因於 Widget 的顯示設定。

若有多個名稱相近的伺服器項目，建議在個人管理範圍內使用容易辨認的名稱，但不要在名稱中加入密碼、完整訂閱網址或其他敏感資訊。Widget 可能會在他人看得到的位置顯示項目名稱，鎖定畫面上的顯示尤其應依個人隱私需求選擇。名稱只供辨識；修改名稱無法修正協定參數，也不會改變伺服器的實際能力。測試與設定核對仍必須針對實際欄位進行。

與 On Demand 搭配時的操作範圍

透過 Widget 中斷連線後，若 On Demand 條件仍成立，系統可能再次嘗試連線。此時應檢查自動觸發來源，不要認定元件按鈕沒有作用。若要暫時停止連線，請進入應用程式確認自動條件，再中斷連線；準備恢復時，先確認原有伺服器與設定仍正確，再恢復相關條件。元件是操作入口，自動規則則是另一層控制；應在同一條驗證流程中理解兩者，不能只觀察最後一次點擊。

若點擊元件後開啟應用程式，而非直接完成預期操作，請以目前系統允許的互動方式為準；某些操作可能需要解鎖裝置、進入應用程式或完成系統確認。不要認定所有操作都會在背景靜默執行。首次 VPN 授權仍須在系統提示中明確確認。Widget 適合用於已驗證成功的日常操作；首次設定與故障排查應在應用程式完整頁面進行，才能查看必要欄位與錯誤資訊。

iPhone 與 iPad 的元件擺放方式及可用位置可能不同；系統需求與適用性以 App Store 頁面標示為準。若要從頭建立清楚的連線流程，請返回使用教學；若只是顯示延遲，不必重新匯入既有訂閱，也不必為了更新畫面而反覆修改 DNS 或 Proxy 連接埠。

07 / iCloud

iCloud 同步與設定還原

分別處理應用程式購買、設定同步與系統授權

iCloud 同步可在應用程式支援的範圍內儲存或交換資料，不能與 App Store 已購項目紀錄視為同一功能。已購紀錄回答「能否重新取得應用程式」；同步回答「哪些應用程式資料可在裝置間還原」；系統 VPN 授權則回答「此裝置是否允許建立相關設定」。即使使用相同的帳號系統，這三者仍有不同的入口與狀態。換機後應用程式已安裝，不代表所有伺服器、規則與連線授權都已完成還原。

同步開關、可同步的資料類型及目前狀態，以應用程式與系統介面為準。本文不假設 Config、伺服器項目、所有 Settings、Log 與系統授權會完整地一併複製。建議先在來源裝置確認哪些內容納入同步，再於目標裝置逐項檢查實際出現的項目。若介面提供獨立的資料選項，請按需啟用，不要為了「全部一致」而盲目開啟所有選項。目標裝置上的系統 VPN 授權仍須另外核對。

啟用前確認帳號、儲存空間與獨立備份

啟用同步或排查同步問題前，先確認系統 iCloud 已登入、應用程式符合相應使用條件，並檢查儲存空間與網路是否可用。預設狀態以目前裝置為準；舊裝置已啟用，不代表新裝置一定會採用相同狀態。對仍在使用的設定，應先儲存一份獨立副本，並妥善保護其中的憑證。同步不是歷史版本庫，也不保證能找回每一次誤改；若錯誤設定同步到其他裝置，仍需可靠的原始副本才能還原。

來源裝置與目標裝置同時編輯相同內容，可能導致名稱重複、內容不一致或覆寫選擇。處理前先暫停雙向編輯，選定一台儲存完整可用內容的裝置作為核對基準，再比較另一台的實際資料。不要在兩台裝置上連續刪除並重建同名設定，因為這些操作本身也可能進入同步流程。若應用程式顯示衝突或選擇提示，請先確認保留範圍及要保留的版本，再執行操作。

訂閱更新不等於 iCloud 同步

Subscribe 更新會從使用者已有的訂閱網址重新讀取資料；iCloud 同步則是在裝置間交換資料。前者受訂閱網址、驗證資訊及格式影響；後者受帳號、系統權限與同步狀態影響。新裝置出現某個項目，不代表該訂閱網址目前仍能更新；來源裝置能更新，也不保證目標裝置已收到最新清單。排查時先確認問題出在「取得遠端資料」還是「裝置間傳遞資料」，不要交替操作這兩種流程。

若目標裝置已取得訂閱項目，但更新失敗，應核對訂閱網址是否完整、是否已過期，以及目前網路能否存取，不要反覆關閉 iCloud。若來源裝置已更新而目標裝置清單仍舊，請檢查同步範圍與狀態。手動更新入口及失敗情況的排查方式，請參閱訂閱手動更新與自動更新排查。任何含有存取憑證的訂閱網址都應視為私人資訊，不要寫入公開的同步排查紀錄。

還原後逐項驗證，不要整份照搬結論

還原完成後，先檢查 Home 清單、預設伺服器選擇、Global Routing、目前 Config 及 DNS 相關設定；再確認 On Demand 是否符合新裝置的使用情境。即使兩台裝置的資料相同，也可能連接不同網路，並受到不同系統權限與路由條件影響。因此，來源裝置能存取某個目標，不能作為目標裝置已成功還原的唯一證據。目標裝置仍應獨立完成手動連線、Connectivity Test 及一次實際存取。

需要重新取得應用程式時，請透過 App Store 已購項目或正版產品頁處理，步驟請參閱換機與已購項目還原說明。購買適用性、系統需求與共享範圍，以 App Store 頁面標示為準。還原應用程式購買項目不包含使用者自行管理的線路服務，也不代表憑證會永久有效。若還原後缺少某項資料，先保留目前狀態，再檢查同步範圍與獨立副本，不要以反覆重新安裝取代有順序的檢查。

準備登出帳號、停用同步或清除雲端資料前，先確認操作影響的是本機、雲端還是其他裝置，並儲存需要保留的內容。不要把「停止同步」直接理解成「刪除所有副本」，也不要因為「本機還有資料」就認定「雲端一定已備份成功」。以介面提示與實際核對結果為準，可大幅降低還原過程中誤刪資料的風險。

08 / Proxy

Proxy 連接埠與最後驗證

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

Add Server 中的伺服器連接埠由使用者已有的伺服器資訊決定，用於連接遠端服務；Settings 中與 Proxy 相關的本機連接埠，則是裝置提供本機代理入口時使用的監聽參數。兩者即使都是數字，也不是相同欄位。修改本機連接埠不會改變遠端服務連接埠，也無法修正錯誤的伺服器位址。排查前先確認目前看到的是伺服器編輯頁面，還是應用程式的本機 Proxy 設定，避免在錯誤位置反覆嘗試不同數值。

本機監聽連接埠的預設數值、是否啟用及允許的存取範圍，以目前介面為準。若不需要本機代理連線，建議保留現有狀態，不要為一般連線額外開啟監聽。確有需求時，先記錄位址、連接埠、協定類型及存取範圍，再設定呼叫端。連接埠是連線入口的一部分，必須搭配監聽位址與協定一起理解；單一連接埠數字無法完整說明連線方式，也無法判斷其他裝置是否應能存取。

監聽位址與存取範圍的安全界線

僅供本機存取的位址與可供區域網路存取的位址，暴露範圍不同。擴大監聽範圍前，應確認實際需求、所在網路是否可信，以及應用程式是否提供存取控制。不要只為了讓另一台裝置連線，就直接將監聽範圍擴大到所有可達網路。若只供本機使用，應採用目前功能允許的最小存取範圍。共用網路上的其他裝置可能不受使用者控制，因此管理本機代理入口時，應以實際用途為準，而非只追求「連得上」。

設定呼叫端時，位址應指向提供監聽的裝置，而不是遠端伺服器網域；連接埠應與本機監聽值相同，協定類型也必須相符。裝置切換網路後，區域網路位址可能變動；舊位址失效不一定代表 Shadowrocket 故障。排查時先確認兩端位於預期網路、監聽仍已啟用且位址沒有變動，再核對連接埠與協定。未確認這些基本條件前，不要修改 DNS、規則或伺服器驗證欄位。

連接埠衝突與連線遭拒的檢查順序

連線立即遭拒、持續等待及連線建立後協定失敗，是不同現象。遭拒時先核對監聽是否啟動、位址與連接埠是否正確；持續等待時檢查網路可達性及存取範圍；建立連線後才失敗，則檢查呼叫端選用的協定與驗證要求。連接埠衝突也可能導致監聽無法正常啟動，但不能只憑一次逾時就認定發生衝突。請查看應用程式是否提供相關提示，並搭配 Log 核對，不要隨機更換大量連接埠試錯。

需要變更本機連接埠時，請在可中斷連線的時段操作；修改後儲存，並同步更新所有呼叫端。舊連線可能不會自動切換至新連接埠，請重新建立測試連線。選擇數值前，確認欄位允許的範圍及是否已供其他本機用途使用；本文不指定任何通用的必填連接埠。若修改沒有改善，請還原原本的監聽設定及呼叫端設定，避免一端已修改、另一端未修改而造成設定不一致。

Proxy 入口仍須核對路由與設定

本機入口可以接收請求，不代表後續策略一定正確。還要核對 Global Routing、所選伺服器及目前 Config。以下是獨立的規則片段，只用於說明策略選擇，不包含監聽設定或伺服器憑證。它不能單獨取代完整設定，也不應覆蓋使用者既有訂閱中的協定欄位。將本機連接埠排查與規則排查分開，才能判斷請求是未進入應用程式，還是進入後走了不符預期的路徑。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

範例中的網域與位址區段用於說明語法。DOMAIN-SUFFIX 比對網域後綴，DOMAIN-KEYWORD 比對網域中的關鍵字，IP-CIDR 對應位址範圍，FINAL 則作為最後的策略。REJECT 會阻擋符合條件的請求，因此新增前應評估適用範圍，避免將範圍過廣的關鍵字用於重要服務。Global Routing 處於 Config 模式時，才適合用這類規則順序解釋一般分流結果；其他模式應依其自身含義驗證。

以完整驗證流程完成修改

最後驗證分為入口與出口兩部分：先確認呼叫端能連至正確的本機監聽，再確認應用程式選取了預期策略並成功存取目標。若入口可用但出口失敗，請回到 Ping、DNS 與 Log 章節；若入口無法使用，先檢查位址、連接埠與存取範圍。完成後記錄成功條件、原值與新值，關閉僅為排查而啟用的額外記錄，並還原需要的 On Demand 狀態。設定手冊的目的不是增加更多開關，而是讓每項修改都有明確用途與可驗證的結果。