Shadowrocket 設定參考

Settings / 作用範圍

設定範圍、預設值與修改記錄

先區分 App 設定與請求處理

Settings 並非所有網路行為的唯一設定入口。Home 中選取的伺服器決定可供轉送的連線目標，Global Routing 決定依設定檔規則處理，或統一選擇 Proxy、Direct；Config 儲存規則及相關參數，Settings 則包含 App 層級的連線、測試、顯示與維護選項。排錯前應先判斷問題屬於哪一層。網頁連線路徑不如預期時，直接修改測試參數通常無濟於事；Widget 顯示更新不及時，也不能單憑畫面判定規則失效。

每次調整設定時，應同時記錄四件事：所在頁面、目前值、希望改變的行為，以及如何確認修改有效。例如調整 DNS，目標應是特定網域能穩定解析，而不是讓測試數字變小。調整 On Demand，目標應是在符合指定網路條件時依預期連線，而不是讓 App 在背景持續顯示。把目標寫成可重複執行的操作，才能判斷設定是否真正生效，也更容易找出無關的修改。

如何理解預設狀態

「預設」至少有三種含義：首次開啟時顯示的 App 初始值、匯入設定檔後由檔案指定的值，以及系統目前網路提供的值。三者不一定相同。裝置經過資料還原、iCloud 同步或切換設定檔後，畫面上的內容也不宜再稱為出廠狀態。本手冊不推測無法直接從目前裝置確認的預設數值；建議值以保留已驗證的設定、減少額外變數為原則，而不是要求所有裝置使用相同參數。

建立可還原的修改流程

開始修改前，先儲存目前可正常運作的 Config 副本，並記錄選取的伺服器、Global Routing、網路類型及連線開關狀態。只需在自己的記錄中寫明名稱與變更內容，請勿將完整訂閱網址或密碼貼到公開頁面。接著一次只改一項，儲存後依畫面指示重新建立連線，再以相同的實際存取操作驗證。如果同時更換伺服器、修改 DNS 和切換規則，即使恢復正常，也無法判斷是哪一步排除了問題。

「已儲存」和「已套用至新連線」是不同狀態。部分參數會在重新建立通道或提出新請求時生效；既有連線可能繼續沿用先前的路徑。驗證時先停止原本的測試請求，必要時關閉再開啟用戶端連線，然後重新發起存取。請勿在下載、通話或其他持續傳輸期間反覆切換參數，否則中斷本身會混入故障現象，讓 Log 難以對應到特定修改。

建議的基準設定不是整套重設，而是保留目前能說明其用途的設定。沒有明確需求時，測試方法、連接埠、同步範圍和自動連線條件都先維持現狀；遇到問題時，再依本頁相應章節逐項查閱。需要確認 App 來源時，請前往正版驗證說明，核對開發者 Shadow Launch Technology Limited 與 App ID 932747118。購買與安裝問題應透過商店流程處理，不要以修改網路設定取代。

DNS / 網域解析

DNS 設定與解析路徑

DNS 負責將名稱解析為位址

DNS 會將網域名稱轉換為網路位址，與代理連線本身並不相同。一次存取可能先取得位址，再由規則決定連線路徑；也可能涉及代理端處理目標名稱。實際路徑會受到設定與協定影響。因此，伺服器測試有結果但網頁無法開啟，不能直接歸因於 DNS；網域能解析，也不代表目標服務一定可存取。應分別驗證名稱解析、伺服器連線、規則選擇與目標回應，避免以單一結果概括整條連線路徑。

先到 Config 確認目前使用的檔案，檢查其中是否明確設定 DNS，再對照 Settings 中裝置實際提供的相關選項。不要只因某個輸入欄位空白，就認定沒有 DNS 行為：空白可能表示使用其他來源的設定。若檔案中寫有 dns-server，應閱讀該項及相關說明，而不是只修改另一頁顯示的值。若不清楚設定檔的覆寫關係，先複製檔案，再用副本驗證實際生效狀況。

預設來源與建議設定值

若沒有明確的解析需求，先保留目前可正常運作的 DNS 方案。使用系統提供的解析來源可作為對照，但不代表適用於所有網路，也不表示所有請求都會避開代理。下方片段展示 system 的寫法，只供理解參數位置；其中不含伺服器資訊，也不能取代個人設定檔。修改前請保留原值，並確認目前檔案沒有其他會影響解析路徑的設定。

[General]
dns-server = system

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

不要為了增加「備援」數量，堆疊多個用途不明的解析位址。多個來源可能回傳不同結果，也會帶來逾時與快取差異。選用其他解析方式前，應確認目前的 App 介面或設定語法確實支援相應格式，且該服務可從所在網路連線。涉及加密解析時，應區分傳輸加密、解析服務可連線，以及目標可存取這三項條件；只符合其中一項，不能推斷整體請求一定成功。

依現象定位解析失敗

若只有特定網域無法使用，先檢查拼字、目標是否仍有效，以及相同網域在同一網路上的重複測試結果。若多個無關網域都失敗，再查看 Log 是否出現解析相關錯誤。直接以位址存取只能提供有限線索：許多服務仰賴網域名稱、憑證與請求標頭，因此位址存取失敗不能證明網路不通。對照測試應盡量使用一般網域存取方式，不要把憑證錯誤誤判為 DNS 故障。

若問題只在切換 Wi-Fi 後出現，請記錄切換前後是否需要完成網路登入、系統是否已取得可用連線，以及用戶端是否重新建立通道。有些網路在完成登入前無法正常解析或存取外部目標，此時修改 DNS 可能掩蓋真正的網路入口問題。先確認系統網路基本可用，再驗證 Shadowrocket；若原網路正常、另一網路卻持續失敗，保留這項差異比反覆更換設定更有診斷價值。

快取可能讓修改後的狀況不會立即反映。App、系統、瀏覽器與遠端服務都可能儲存部分結果，因此不要只重新整理一次頁面就下結論。重新建立用戶端連線後，關閉舊測試頁面並建立新請求，觀察同一網域多次測試的結果，同時記錄時間。清除快取請依裝置實際提供的操作進行；不必為了驗證單一網域而刪除所有設定、重新安裝 App 或清除無關資料。

完成排錯後，將保留的 DNS 來源、適用網路與驗證網域寫入自己的設定備註。不要先把某次臨時測試值同步到所有裝置，再確認效果。若想進一步了解 DOMAIN、IP-CIDR 與名稱解析之間的差異，可參閱術語表；開關已開啟但仍無法存取時，可依伺服器、模式、DNS 與規則疑難排解清單檢查整條連線路徑。

Global Routing / Config

Global Routing、規則與設定檔覆寫

模式決定如何套用規則

Global Routing 是判斷流量去向時的第一項檢查。Config 模式依目前的設定檔處理請求；Proxy 模式會以代理模式處理進入用戶端範圍的流量；Direct 模式則以直連模式處理。這裡說明的是用戶端的處理方式，不代表可據此絕對判定裝置上的所有系統流量。測試特定規則前，務必確認目前使用 Config；否則即使檔案設定正確，也可能不是目前行為的判斷依據。

日常需要依網域或位址分流時，建議使用已核對的 Config。Proxy 與 Direct 可協助縮小故障範圍，但不宜把暫時的對照結果直接當成長期方案。切換模式時請記錄原值，測試結束後還原。Direct 下可以存取，只能說明當次直連路徑可用；Proxy 下可以存取，也不代表 Config 中每項策略都正確。模式、規則與伺服器應分別驗證，不能互相取代。

規則順序與最終匹配

規則通常會依序檢查，具體規則應排在範圍較廣的規則之前，最後一項則負責處理尚未匹配的請求。DOMAIN 比對完整網域名稱，DOMAIN-SUFFIX 涵蓋相應的網域後綴範圍，IP-CIDR 與 IP-CIDR6 用於位址區段；GEOIP 依 IP 位址的地理資訊匹配，結果也會受到資料庫與位址歸屬影響。不要把 GEOIP 當成判斷網站內容來源的依據，也不要認為單一網域永遠只會對應固定位址。

[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

範例中的網域與文件專用位址區段僅用於說明語法，不是實際伺服器，也不構成通用分流建議。PROXY 需要已有可用的代理連線，DIRECT 表示直接連線，FINAL 則用來指定其餘請求的處理方向。若將最終規則改為 DIRECT，未匹配的請求就會改走不同路徑。因此閱讀設定檔時，不只要找出包含目標網域的規則，也應檢查更前面的規則與最終規則，確認請求實際符合哪一項。

選對檔案比檔名更重要

匯入設定檔不代表已經啟用；編輯某個檔案，也不代表目前連線正在讀取該副本。每次驗證前都要回到 Config 確認選取的檔案，再檢查儲存結果。檔名相近時，可在個人備註中註明用途，例如日常基準與暫時測試，不要只靠清單位置記憶。檔案包含多個段落時，只修改目標段落並保留原有伺服器及其他必要參數，避免複製片段時意外遺失前後設定。

使用者已有的訂閱與設定檔也不能混為一談。訂閱更新可能會改變伺服器清單，但規則是否變更，仍須查看匯入內容與實際操作。訂閱中若不再有某台伺服器，目前的選取項目可能需要重新確認；這不代表 DNS 必須重新填寫。更新前後比對可用伺服器、選取項目與目前 Config，比直接重建所有資料更容易找出原因。任何含有憑證的連結都應留在自己的裝置中，不要作為公開排錯資料。

若發生「同一網域有時走不同路徑」，請檢查是否涉及多個相關網域、不同位址家族、沿用舊連線或資源請求重新導向。網頁本身及其中的圖片、影片、介面請求不一定使用同一個網域。應在 Log 找出實際失敗的請求，再調整相應範圍；只為網頁主網域新增規則，不一定涵蓋所有資源。修改 DOMAIN-SUFFIX 時尤其要留意涵蓋範圍，避免為了解決單一目標而改變大量無關請求。

On Demand / 連線觸發

On Demand 與連線狀態

自動觸發不保證連線持續可用

On Demand 依已儲存的條件觸發 VPN 連線，實際行為也取決於系統網路狀態與裝置允許的操作。它不是伺服器健康狀態檢查，也無法修正密碼錯誤、位址無法連線或 DNS 解析失敗。手動連線尚未穩定前，建議先不要新增自動觸發條件；完成伺服器與規則驗證後再啟用。否則自動連線嘗試會與人工排錯交錯，讓「何時開始連線」和「為何連線失敗」難以區分。

首次新增 VPN 設定時，系統會顯示授權提示。只有在確認正在執行 Shadowrocket 的連線操作時，才依系統提示完成授權；提示內容與身分驗證方式以裝置實際顯示為準。既有 VPN 設定也可能受裝置管理政策或其他連線狀態影響。若無法授權或狀態立即恢復，先查看系統提示，不要反覆刪除 App 資料。若系統層級不允許建立通道，修改規則文字無法解決授權問題。

條件、初始狀態與建議設定

進入裝置上的 On Demand 頁面，先記錄目前是否啟用，以及已有的網路條件。不同介面提供的條件與顯示方式可能不同，本頁不假設所有裝置都有相同選項，也不把資料還原後的狀態一概視為預設關閉。建議從一個容易明確驗證的條件開始，不要一次新增多組互相重疊的條件。若要依 Wi-Fi 環境區別處理，請準確核對網路名稱，並留意名稱相同的網路不一定是同一個實際環境。

驗證自動觸發時，先停止持續傳輸，記下起始網路與開關狀態，再切換一次網路，等待系統完成連線程序後提出實際請求。每次測試只變更一個條件，分別記錄 Wi-Fi、行動網路及裝置鎖定前後的狀況。不要把剛切換網路時的短暫中斷當成持續故障，也不要只看狀態圖示；網路切換、通道重建與 App 建立新連線之間可能有時間差。

關閉後又重新連線的處理方式

若手動關閉後很快又出現連線，先檢查 On Demand 是否仍啟用，並確認目前環境是否符合觸發條件。需要暫時停止時，應先處理自動觸發設定，再關閉連線並觀察狀況。反覆點按 Home 開關卻不確認條件，可能造成關閉後再次觸發的循環。若關閉自動觸發後仍有異常，請記錄系統 VPN 狀態與操作時間，再檢查其他可能影響連線的系統設定。

Wi-Fi 登入頁面也是常見的例外情況。有些網路必須先依系統提示完成登入，之後才能正常存取。若自動觸發在網路尚未就緒時開始連線，可能會持續等待或無法存取。處理順序應為確認該網路的正常連線要求、完成系統登入、驗證基本連線，再檢查 On Demand。不要在尚未成功連線的網路上反覆更換伺服器，誤將網路接入問題當成用戶端設定問題。

裝置鎖定後，App 未顯示在前景不代表 VPN 一定停止；同樣地，Widget 留有連線文字也不代表目前請求已成功。相關網路元件由系統排程，不能只憑前景畫面推斷背景狀況。判斷時應在重新使用裝置後再次發起請求，並對照實際狀態與 Log。頻繁開啟 App、關閉 App 或連續切換開關，會改變原本要觀察的條件，反而不利於判斷自動連線是否穩定。

最後保留的條件應能用一句話清楚說明：在什麼網路狀態下，希望何時連線。若有多個例外，請逐項驗證並記錄，不必追求條件數量。更換裝置或還原資料後，應重新完整測試，因為舊條件仍存在，不代表新裝置的網路環境相同。基本授權與首次連線步驟可回到教學頁確認；本頁說明的是完成這些操作後的設定界線。

Ping / Connectivity Test

Ping、測試方法與結果解讀

測試涵蓋哪一段，結論就只適用於哪一段

Ping 與 Connectivity Test 可提供連線線索，但測試方法不同，涵蓋的連線路徑也不同。有些測試著重於伺服器位址是否可達，有些會嘗試建立傳輸連線，有些則會透過代理存取測試目標。解讀結果前，先查看裝置上實際選用的測試方式與目標。清單中出現耗時數值，不代表目標網頁、完整規則路徑與所有協定功能都已驗證；沒有結果，也可能只是遠端網路不回應該測試方式。

基礎網路探測、連接埠連線及透過代理發出的請求，並非相同操作。伺服器可能不回應某種探測，卻仍能正常接受代理連線；也可能很快接受連接埠連線，卻在驗證或後續轉送階段失敗。因此「數值很小，網頁卻打不開」並不矛盾。解讀測試結果時，應確認是否使用實際代理協定、是否完成身分驗證，以及測試目標是否就是發生問題的服務，避免把局部成功擴大解讀為整體正常。

預設方法與建議參數

Ping 頁面的初始方法、逾時時間與目標，以本機目前顯示為準；還原設定或改變使用習慣後，不應假設所有裝置都相同。建議先保留已知的測試方法，使用同一目標進行前後比較。逾時時間太短可能將正常波動記為失敗，太長則會延長等待時間，無法讓失敗的連線恢復正常。若沒有證據顯示等待門檻不合適，就不必先調整數值，更不必一次修改所有測試項目。

測試目標應穩定、明確，並適合驗證目前問題。若 App 提供自訂目標，先確認填寫格式符合介面要求，不要隨意加入憑證，也不要使用必須登入才能存取的頁面。目標本身發生重新導向、流量限制、維護或憑證問題，都可能影響結果。更換測試目標時，請保留舊目標作為對照，並明確記錄這是測試條件的變更，不能將新舊數值直接當成伺服器效能排名。

建立可重複的測試組合

準備一組簡單的驗證操作：在固定網路下測試目前伺服器，使用相同的 Global Routing 與 Config 存取目標，再檢查失敗請求的 Log。重複測試數次，記錄問題是持續發生、偶爾發生，還是只在特定操作後出現。避免同時啟動大量測試，尤其是在網路較弱或伺服器可用連線數有限的環境；測試本身也會耗用連線資源，密集並行可能產生與日常單次存取不同的狀況。

若伺服器測試正常但網頁無法存取，請依序檢查目標網域解析、規則命中、身分驗證與遠端回應。若測試失敗但網頁正常，先確認測試方法是否適用，不要立即刪除可用伺服器。若只有特定伺服器持續失敗，請核對使用者既有服務提供的位址、連接埠、協定參數與有效狀態；這些資訊應由原有來源確認，不能靠反覆調高逾時時間猜出正確值。

對於使用 TLS 的連線，還要區分伺服器位址與用來驗證憑證的名稱。合法設定中，兩者可能不同，實際要求以使用者已有的伺服器資訊為準。憑證驗證失敗時，不應把降低驗證要求當作一般處理方式；請先檢查裝置時間、名稱填寫、憑證鏈與伺服器狀態。連接埠能建立連線，只能證明前面的傳輸階段有回應，不代表加密交涉與後續請求已完成。

測試結束後，還原暫時修改的目標與方法，並將保留的參數寫入修改記錄。若問題只出現在某種網路，至少保留兩組相同條件下的結果，再進入 Log 章節定位問題階段。需要核對協定欄位名稱時，可參閱功能與設定說明和術語表；這些頁面說明概念，本節則著重於測試證據能支持的結論範圍。

Log / Data

Log、請求記錄與排錯依據

依單次請求查看 Log

Log 用於將問題對應到處理階段，不是要求使用者逐行解讀所有記錄。開始排錯前，先記下目前時間、網路、伺服器、Global Routing 與 Config，再執行一次明確會失敗的操作。接著只查看相近時間的相關記錄，找出網域、連線目標、規則與錯誤訊息之間的關聯。一次網頁存取可能產生許多資源請求，最早出現的失敗未必就是導致整個頁面無法使用的關鍵請求。

先確認請求是否進入用戶端，再查看是否取得解析結果、選用哪項策略、是否建立連線，以及遠端是否回傳回應。若記錄中找不到目標，不應直接斷言規則正常；可能是請求未重新發出、被 App 快取、走了不同的系統路徑，或目前記錄方式未涵蓋該資訊。應重新建立明確的新請求，再確認 Log 範圍。逐階段排除問題，比只搜尋特定錯誤詞更可靠。

記錄範圍與預設狀態

Log 可顯示的內容與詳細程度，以裝置提供的選項及目前狀態為準。有些細節只有啟用相應記錄後才會出現，啟用前的請求不會因此補上。建議日常保留足以進行基本觀察的記錄方式，只在重現問題的短時間內提高詳細程度。更多 Log 可能增加儲存與處理負擔，也會包含更多存取細節；完成診斷後應還原原設定，並依實際需求清理不再使用的記錄。

Log 中的錯誤通常是某個階段的結果，不一定是最終原因。例如逾時可能來自位址無法連線、伺服器未回應、遠端目標等待或網路切換，不能只憑一個詞判定原因。應串起錯誤發生前後的記錄，再對照實際操作時間。若修改一項設定後錯誤階段有所變化，也應記下來：從解析失敗變成連線失敗，代表請求往前推進了一步，但還不能稱為整體恢復。

Data 與連線狀態的界線

Data 中的流量或相關統計，可協助確認一段時間內是否有資料活動，但不等於目標服務已成功回應。累計值可能包含其他背景請求，也可能保留先前連線的資料。應先了解目前頁面統計的時間範圍，再進行短時間比較；若不清楚統計範圍，不要用累計變化推斷特定規則是否命中。需要精確定位目標時，仍應以相應請求記錄與可重複的存取結果為主要依據。

若問題間歇出現，先保持設定不變，讓重現條件清楚。記錄問題是否與切換網路、裝置鎖定、訂閱更新或持續傳輸有關，再於相同條件下進行有限次測試。每次失敗都改動不同設定，記錄就無法比較。保留穩定的基準設定，以及只修改單一項目的副本，可避免後續排錯時忘記原始狀態，也方便確認恢復是否取決於某項暫時設定。

整理記錄時，請保護訂閱網址、伺服器憑證、個人網域與裝置資訊。只擷取必要的時間範圍，保留錯誤類型、規則關鍵字與處理階段，並移除驗證資料及可識別個人的資訊。不要一併公開完整設定檔與 Log，也不要以為隱藏密碼欄位就移除了所有敏感資訊：訂閱網址的查詢參數、連線位址及某些名稱都可能連結到個人服務，應逐項檢查。

確認問題已排除後，依原本條件再測試一次，並還原暫時提高的記錄詳細程度。不要把刪除所有歷史 Log 當成一般修復步驟；清理只能改變可見記錄與空間使用量，無法自動修正伺服器參數或規則。完整處理順序可搭配閱讀連線後無法存取的疑難排解文章，先依現象定位階段，再決定要調整哪一項。

Widget / iCloud

Widget、iCloud 同步與裝置還原

Widget 是操作入口，不是完整的診斷頁面

Widget 可在系統提供的位置查看狀態或執行快速操作，實際可用內容以裝置提供的元件為準。元件更新由系統排程，顯示時間不一定與剛發生的網路變化同步。元件與 Home 顯示不一致時，先開啟 App 確認目前伺服器、連線狀態與實際請求，再觀察元件更新。不要為了修正顯示延遲而重寫設定，也不要只憑元件文字判斷連線仍然成功或已停止。

新增元件時，透過系統的元件編輯流程選取 Shadowrocket，並確認目前元件提供哪些設定項目。若元件允許選擇相關內容，請確認指向的項目仍存在且適用。還原資料、調整名稱或刪除舊項目後，可能需要重新檢查原本的選取項目。建議先使用用途明確的簡單顯示方式，避免同時放置多個意義相近的入口，以免尚未確認狀態就連續觸發連線操作。

同步內容與購買資格分開處理

iCloud 同步用於處理 App 支援同步的資料，與 App Store 購買記錄不同，也不代表目前的 VPN 工作階段可以直接在裝置間轉移。購買 App、同步設定與授權建立連線，是三個獨立流程。新裝置能從已購項目取得 App，不代表所有設定都已同步；即使看到設定檔，也仍須確認本機網路授權、伺服器選擇與規則正確，再開始驗證連線。

預設同步狀態與可同步範圍，請以本機 Settings 顯示為準。啟用前先確認系統 iCloud 已登入且相關存取權限正常，並儲存一份可用的本機設定檔。不要在兩台裝置上同時大幅修改同一份內容，之後才等待同步。同步不是保存無限歷史版本的備份工具，不能假設所有舊值都能找回；重要的設定變更應在自己的安全儲存空間另留可還原副本，並妥善保護其中的憑證。

同步延遲與衝突的處理

發現另一台裝置未顯示變更時，先確認兩端網路可用、iCloud 相關權限正常，以及 App 內的同步狀態。接著等待一段合理時間再檢查內容，不要連續匯入、覆寫與刪除來「催促」同步。若兩端內容已不同，請先分別保留副本，再決定要以哪一份作為基準。是否自動合併、覆寫或保留衝突內容，應以實際介面結果為準；本手冊不預設固定的衝突處理方式。

不同裝置可能需要不同的網路策略。iPhone 的行動網路情境與 iPad 常用的 Wi-Fi 環境不同，On Demand 條件、測試目標的可達性與本機連接埠用途也可能各異。因此同步後應重新檢查與環境相關的項目，不能只因檔名相同就略過驗證。先使用相同 Config 建立最基本的可用連線，再逐項恢復自動觸發與元件入口，可避免誤把同步成功當成所有設定都適用。

更換裝置或重新安裝時，先透過原購買帳號的 App Store 已購項目取得 App；重新取得方式與通用購買適用性，請以 App Store 頁面標示為準。接著確認支援的資料是否已還原、伺服器與訂閱內容是否仍有效，最後依系統提示完成本機連線授權。詳細流程請參閱已購項目還原說明與在新 iPhone 還原 Shadowrocket，不必把購買問題與同步問題混在同一個步驟處理。

在 iPad 上，畫面可能因橫向顯示或分割畫面而改變位置；請依 Home、Config、Settings 等介面名稱定位，不要依賴固定的螢幕座標操作。可參閱iPad 購買與介面說明。完成還原後，重新確認 Widget 指向與 On Demand 條件，確保快速入口對應到實際保留的資料。

Proxy / 連接埠與還原

Proxy 連接埠、參數界線與還原檢查

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

提到「連接埠」時，應先確認是指哪一端。Add Server 中的伺服器連接埠由使用者已有的服務資訊決定，填寫後用於連線至遠端；若 Settings 提供本機 Proxy 監聽項目，則是供本機或允許的來源發出代理請求。兩者用途不同，不能為了解決遠端連線失敗而任意更換本機連接埠，也不能將本機連接埠填入伺服器資訊。修改前應一併核對位址、連接埠與協定，確認調整的是正確層級。

本機 HTTP 或 SOCKS5 連線方式與遠端伺服器協定也不是同一概念。連線端使用的方式應符合本機實際提供的服務；遠端仍依已儲存的伺服器參數運作。單純讓某個連接埠處於監聽狀態，不代表 DNS、規則與遠端轉送都已通過驗證。若沒有 App 或裝置需要明確連接本機 Proxy，建議保留目前狀態，不必為了一般 VPN 連線主動設定額外的監聽用途。

預設連接埠與存取範圍

實際連接埠數值、監聽範圍與驗證選項，請以裝置上的 Settings 為準；本手冊不指定適用於所有安裝狀態的固定值。調整前先記錄原值，並確認預期使用者是否已設定該連接埠。連接埠變更後，相關使用者也需同步修改；只改其中一端，可能會遭拒絕連線或持續等待。遇到衝突時應先確認衝突來源，不要連續嘗試一串數字，卻不記錄最後保留的值。

僅供本機使用與允許區域網路來源存取，兩者風險不同。擴大監聽範圍前，應確認目前網路是否可信、是否提供並正確使用驗證，以及哪些來源能連到該連接埠。不要為了方便一次測試，就長期保留超出需求的存取範圍。區域網路請求能否抵達，也取決於網路隔離與系統狀態；在 App 中開啟相關選項，不代表所有裝置都能存取，也不表示應繼續擴大權限。

Settings 無法補足協定參數

Shadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2 等協定各有對應欄位，應以使用者已有服務提供的資訊為準。位址、連接埠、驗證資訊、傳輸方式與加密相關參數不一致時，調整 Ping、Widget 或 Log 詳細程度都無法補上缺漏欄位。匯入後仍應核對協定類型與必要參數，尤其是手動輸入的內容；不要只憑另一條可用連線的欄位結構，推斷目前協定也採用相同設定。

伺服器若提供網域名稱，網域可能會隨位址變更而繼續指向有效服務；任意改成某次解析出的位址，可能破壞名稱驗證或後續更新。涉及 TLS 名稱、傳輸路徑等欄位時，應保留既有資訊中的明確要求，不要因連接埠測試有回應就刪除相關參數。每次只修正一項已確認的輸入錯誤，再進行實際連線測試，並保留修改前後的錯誤階段以供比較。

還原至最後一個已驗證狀態

排錯後仍未恢復時，依修改記錄的相反順序逐項還原：先還原暫時修改的連接埠與測試項目，再還原 DNS，重新選取原有 Config 與伺服器，最後確認 On Demand。不要一次清除所有資料，否則會同時遺失可用基準與故障依據。還原後重新建立連線，使用相同目標測試；若原設定也出現問題，再檢查網路與既有服務狀態，不要繼續假設所有變化都來自用戶端設定。

需要重新確認購買與系統需求時，請參閱App Store 取得說明。Shadowrocket 是付費商業用戶端，用戶端一次性買斷 ≠ 線路方案；既有服務是否有效，應與用戶端購買分開確認。Settings 的目標不是把所有項目都改過，而是每個保留值都有明確用途、每項自動行為都能說明原因，並且發生問題時能還原至最後一個已驗證可用的狀態。