Shadowrocket
設定詳解

先判斷選項所屬層級

同一次連線可能同時受到三個層級的設定影響：系統網路決定目前使用 Wi-Fi 或行動網路，以及是否允許建立 VPN；Shadowrocket 的 Settings 管理部分 App 層級的行為；目前啟用的 Config 則提供規則與設定參數。Home 中選取的伺服器也會決定實際使用的連線資訊。因此，Settings 顯示某個設定值，不代表所有請求都會採用該值。排查前先記錄目前網路、伺服器、Global Routing 模式及使用中的設定檔，避免檢查到未啟用檔案中的參數。

進入 Settings 前，先確認要處理的問題。例如，「網域無法開啟」應檢查解析與路由；「切換網路後自動連線」應檢查 On Demand；「更換裝置後清單不同」則應檢查同步。不要只因選項名稱看起來與網路有關，就接連開啟多個開關。選項的顯示位置與適用範圍可能因 App 和系統環境而異；本文保留英文名稱供查找。如果目前介面沒有相應項目，不要改用名稱相似但用途不同的開關。

如何記錄預設值與建議值

本手冊不會將某部裝置目前的設定值視為所有使用者的預設值。全新建立的設定、匯入的檔案，以及還原後的 App 資料，起始狀態可能各不相同。核對預設值時，請分清「App 初始設定」、「目前設定檔明確指定的值」，以及「未明確填寫時的繼承行為」。尤其不要為了查看初始狀態而清除現有資料：這可能造成資料遺失，也無法還原匯入檔案原本包含的參數。較穩妥的做法是先記錄目前狀態，再依個別項目的說明判斷是否需要調整。

建議設定也取決於用途。裝置目前運作穩定時，建議維持現況；臨時診斷時，建議減少變因；只有需要特定解析、自動連線或本機代理存取時，才設定相應選項。記錄時除了數值，也要註明所在頁面、設定檔名稱、修改原因及測試結果。輸入欄位留白不一定代表關閉，也可能表示沿用或自動選擇。只有介面說明或設定語意明確時，才能將空白解讀為特定行為。

每次變更都應完成驗證與還原判斷

修改前先選定一個可重複的測試動作，例如開啟同一個網頁並重新整理一次。修改後使用相同網路、相同伺服器與相同目標重試；必要時中斷連線後重新連線，以排除舊連線持續生效的影響。結果沒有改善，就還原剛才記錄的設定值，不要再疊加第二項變更。網路切換、伺服器切換及規則修改應分開測試，否則即使恢復存取，也無法判斷是哪項變更產生作用。

首次連線時若出現系統的「加入 VPN 設定」提示，應將其視為允許 App 建立相應網路設定的授權步驟，而非匯入訂閱的步驟。拒絕授權與伺服器參數錯誤是不同問題。如果系統項目遭到刪除，請回到正常連線流程重新處理授權，不要試圖修改 DNS 或規則來補救。提示的相關說明請參閱VPN 設定提示說明；購買紀錄問題則請至正版驗證頁面處理。

DNS 設定實際會改變什麼

DNS 會將網域名稱轉換為連線所需的位址，但它不等於代理連線本身。一次存取可能在網域解析前就因伺服器連線失敗而中斷，也可能在解析成功後，於連線至目標時失敗。因此，「網頁無法開啟」不代表問題一定出在 DNS。請先觀察影響範圍：所有網域都失敗、只有某個網域失敗，還是僅在特定網路下失敗。既有連線與快取也可能掩蓋問題，讓同一項設定看起來時好時壞；請透過新的存取紀錄確認情況。

設定中的 dns-server 用於指定相關 DNS 解析來源。範例中的 system 表示使用系統提供的解析來源，可作為基本對照，但不代表所有匯入設定檔的預設值，也不保證適用於每種網路。系統解析來源可能會隨 Wi-Fi、行動網路及網路設定而變動。如果使用者的現有設定已明確指定專用解析方式，請先閱讀原設定說明，了解請求如何送達解析服務，再決定是否替換。

[General]
dns-server = system

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

如何選擇設定值與測試方式

若沒有特殊需求，而且目前設定運作正常，建議保留原有 DNS 設定。需要診斷時，可在副本中改用系統解析作為對照，並維持其他參數不變。若使用加密解析位址，也要考量該解析服務的網域如何解析、連線路徑是否可達，以及憑證驗證是否正常。在輸入欄位填入位址，不代表解析請求必然會依預期路徑送出；同樣地，能連上解析服務，也不代表它回傳的所有位址都能經由目前的對外路徑存取。

不要只根據解析服務的地理位置或名稱判斷是否適用。真正需要確認的是：目前網路能否建立連線、查詢是否收到合理回應，以及回應中的位址是否適合後續使用的路由。有些網站會依解析來源回傳不同位址；更換 DNS 後存取結果改變，不一定代表其中一方有錯。請分開檢查「回傳了什麼位址」與「用戶端接著如何連線至該位址」，必要時搭配 Log 中同一目標的紀錄判斷。

IPv6、快取與網路切換

網域可能同時有 IPv4 與 IPv6 結果。若某條路徑只支援其中一種位址，可能出現部分網站速度緩慢、首次開啟等待較久，或切換網路後恢復等情況。此時不應先刪改所有規則。請確認本機網路實際提供的位址能力、所用伺服器與協定的可達條件，再查看記錄中的目標位址類型。若介面提供相關位址族選項，請記錄原值後逐項測試，不要將停用某種位址族當作所有裝置通用的長期設定。

修改 DNS 後，執行中的 App 可能繼續使用既有連線；系統、App 與遠端服務也可能各自快取結果。因此，儲存設定後立即重新整理一次，無法充分證明新設定是否生效。可以先中斷再重新連線 Shadowrocket，重新存取目標，並透過 Log 確認是否產生新請求。不要為了處理快取而反覆清除所有 App 資料，這會引入額外變因。進行對照測試時，也要避免同時切換 Wi-Fi 與行動網路，否則解析來源與網路路徑都會改變。

如果只有單一網域有問題，先核對拼字、對應規則及命中策略；若所有網域都失敗，再檢查解析服務是否可達；若已取得解析結果但連線失敗，則檢查伺服器、目標連接埠與路由。向他人描述問題時，提供已去識別化的目標網域、測試時間、網路類型及錯誤階段即可，不要公開完整訂閱或存取憑證。更完整的分層流程請參閱開關已開啟卻無法存取的四步檢查。

先確認模式，再檢查規則

Global Routing 決定如何判讀目前的路由行為。Config 會依啟用設定中的規則處理請求；Proxy 會讓流量採用代理模式；Direct 則採用直連模式。這些模式適合用來建立不同的診斷對照，但不能只憑名稱推斷所有系統流量的處理結果：系統保留路徑、設定中的繞過行為，以及未進入連線處理範圍的流量，都須另外考量。檢查特定規則前，先確認目前是否為 Config 模式；否則編輯規則後看不到預期變化，並不能證明規則語法無效。

Settings 中的 App 層級選項與 Config 內的參數可能分別影響連線行為，不能將其中一處顯示的設定值當成全部有效設定。匯入檔案後，請確認目前啟用的是哪個檔案，再查看其中的 [General] 與 [Rule]。只編輯清單中的另一個檔案，不會自動取代目前使用的設定。遇到行為不如預期時，先記錄啟用中的檔案名稱與實際命中的規則，再了解參數含義；這比重新匯入整份檔案更容易保留可用狀態。

General 參數與規則順序

bypass-system 涉及繞過系統流量的行為，skip-proxy 用於列出應略過代理處理的位址範圍。以下私有位址網段可供理解語法，但不要未經檢查就取代現有清單。使用者所在的網路可能還有其他位址範圍，也可能有特定存取需求。DNS、繞過清單與規則屬於不同層面的判斷條件，不能假設某個網域指定了 PROXY 後，所有相關流量就一定不受其他條件影響。

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8
dns-server = system

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

規則通常依序比對，前面已命中的條件會影響後續是否繼續判斷。範例先處理 example.com 及其子網域，再處理指定網段，最後以 FINAL 作為後援規則。DOMAIN 適用於完整網域；DOMAIN-SUFFIX 用於網域後綴；DOMAIN-KEYWORD 涵蓋範圍較廣，使用時要避免意外比對。IP-CIDR 與 IP-CIDR6 則用於位址範圍，不要將網域文字直接填入位址規則。

如何判斷變更是否生效

建議從最精簡的規則集建立對照，不要一開始就匯入較長的規則清單。只讓指定網站使用代理時，可以採用上述 DOMAIN-SUFFIX 與 FINAL,DIRECT；如有其他後援需求，再依自己的使用情境調整。策略名稱必須在目前設定中有效，不可任意填入未定義的名稱。修改後確認設定已儲存並啟用，再建立新請求檢查命中結果；如果實際命中前面的其他規則，先調整順序，不要重複新增相同網域。

規則判斷也受限於請求中可識別的資訊。若某次連線只有目標位址可用，依網域設定的預期結果未必能直接重現；同一網頁也可能連線至多個網域，若頁面主體可見但圖片載入失敗，通常需要逐一檢查相關連線。不要用單次載入結果概括所有規則是否正確。可以先選定一個目標網域，核對其請求、命中項目與策略，再擴大測試範圍。若只想讓部分網站使用代理，另請參閱DOMAIN-SUFFIX 與 FINAL 設定說明。

區分「何時連線」與「如何分流」

On Demand 會依設定條件交由系統觸發連線，著重於何時建立或維持連線；Config 中的規則則決定進入處理範圍的請求採用哪種策略。兩者功能不同。啟用 On Demand 不會自動補齊伺服器資訊，也不會將所有網站改用同一種路由。若使用者現有的伺服器無法連線，應先在手動連線狀態下排除問題，再設定自動觸發；否則系統反覆嘗試只會讓故障更難判斷。

核對 On Demand 目前的設定值時，既要查看 App 內是否已啟用，也要確認系統 VPN 設定的狀態與相關條件。既有設定、還原的資料或先前的操作都可能影響目前狀況，因此本頁不會將開啟或關閉指定為所有裝置的出廠值。初次建立連線或正在排查問題時，建議先保留容易掌控的手動連線流程；手動連線穩定且目標網路條件明確後，再依實際需求設定 On Demand 規則。

依網路條件逐項測試

如果目前介面提供 Wi-Fi、行動網路或網路識別資訊等條件，請先確認各條件的適用範圍。網路名稱相同不代表網路環境完全相同；公共網路也可能要求先完成網頁登入。不要只因看到熟悉的 Wi-Fi 名稱，就認定自動連線一定成功。設定完成後，應分別測試從行動網路切換至 Wi-Fi、從 Wi-Fi 切回行動網路，以及短暫斷網後恢復等情況，並記錄系統狀態與 App 狀態是否一致。

測試宜從簡單條件開始：先使用一項明確的網路條件，確認連線觸發符合預期，再增加例外條件。若同時設定多項條件，應查看目前介面對順序、比對方式與動作的說明，不要依清單位置猜測優先順序。適用範圍過大的條件可能會遮蔽後續例外。每新增一項，至少測試一次應觸發的情境，以及一次不應觸發的情境，才能確認適用範圍，而不只是證明開關能夠開啟。

網路變更時，現有連線可能中斷並重新建立。某個 App 的舊連線失敗，不一定代表 On Demand 沒有運作；也可能是新連線已恢復，但舊工作階段無法繼續。請重新發起一次存取，再核對 VPN 狀態。另一方面，系統顯示 VPN 已連線，也不能證明所選伺服器能存取目標。自動觸發、建立通道與存取目標是連續但彼此獨立的環節，檢查時應分別記錄，避免將後兩個環節的故障誤判為觸發條件問題。

停止連線與還原方式

啟用 On Demand 後，手動關閉連線可能很快又被符合條件的系統行為觸發。這不代表按鈕失效。若要暫時停止，應先暫停相關自動連線條件，再中斷目前連線，並確認系統是否仍有其他有效的自動觸發設定。實際入口請以目前系統與 App 顯示為準。不要為了暫時中斷而反覆刪除並重新加入所有 VPN 項目，否則授權、條件與連線問題會混在一起。

使用必須先完成網路驗證的 Wi-Fi 時，應先確認本機網路已可正常使用，再啟用自動連線。否則，解析、驗證頁面與遠端連線可能同時等待，看起來像所有網路都失效。排查時可暫時改用手動連線，完成網路驗證後再測試；這是為了確認網路準備階段，不是建議永久關閉 On Demand。公司或學校管理的裝置也應遵守裝置管理政策，不要任意刪除系統設定來規避管理要求。

最後保留的設定應能用一句話說明，例如「符合已驗證的網路條件時觸發連線，診斷時暫停」。若無法清楚說明每項條件的用途，應優先減少條件數量。每次變更後記錄觸發結果、所選伺服器及是否需要重新授權；結果不符預期時，還原至上一組已驗證的設定。自動連線只是減少重複操作，不保證連線品質；伺服器是否可用、訂閱是否有效，以及目前設定是否正確，仍需由使用者自行核對。常見情況也可參閱常見問題。

Ping 不等於實際連線速度

介面中的 Ping 常用來概括連線測試，但實際測量方式可能不同。請先查看目前採用的測試方式，不要把所有結果都當成同一種往返時間。探測伺服器位址、連線至指定連接埠，以及透過代理存取指定 URL，驗證的是不同環節。伺服器能回應探測，不代表協定驗證一定成功；連接埠能建立連線，也不代表 App 層級參數、憑證或目標存取都正確。

數值低不代表下載速度一定快。短時間測試主要觀察建立連線及取得回應的過程；持續傳輸還會受到本機網路、伺服器負載、線路狀態與目標網站等因素影響。單次測試失敗也不代表伺服器完全無法使用，可能只是目前路徑不支援該測試方式。閱讀結果時，至少應記錄測試方式、目標、網路類型與測試時間四項資訊。缺少這些條件，只比較清單中的兩個數字，容易將不同測量對象誤認為相同的品質指標。

如何選擇測試方式與 URL

Settings 中相關測試選項的目前設定值，請以本機顯示為準，不要將其他使用者分享的截圖當成統一預設值。如果現有測試結果穩定且符合實際用途，可以保留；需要診斷時，選擇符合問題階段的測試方式。檢查伺服器連接埠時觀察連線層；檢查經由代理的存取時，再使用相應的 URL 測試。可選方式請以目前介面為準，不要為了追求較小的顯示數值而不斷切換方式，否則歷史結果將失去可比性。

若測試允許輸入 URL，目標應穩定、經使用者確認可存取，且符合該測試預期的回應形式。重新導向、登入頁面、憑證異常或存取頻率限制，都可能造成測試失敗，但一般瀏覽的結果可能不同。教學中的 example.com 僅用於說明格式，不代表它是可長期使用的測速服務。也不要將含有私人存取參數的網址填入可能顯示於記錄中的測試欄位，以免分享診斷資料時洩漏資訊。

建立可比較的測試紀錄

建議先固定一部伺服器與一個測試目標，在同一網路下少量重複測試，觀察是否持續失敗，以及結果是否大幅波動。不要以單次異常值作為結論，也不必在短時間內密集測試所有伺服器。如果測試功能顯示逾時門檻，請將其視為等待上限，而非網路品質目標；縮短門檻只會讓較慢的回應提早被判定為失敗，不會加快實際連線。延長等待時間也無法修正錯誤的位址、連接埠或協定憑證。

若清單測試正常，但實際網頁無法開啟，先確認網頁請求是否使用同一部伺服器、是否由 Config 指派至不同策略，以及是否包含其他無法載入的資源網域。反之，測試失敗但實際存取正常時，應檢查測試目標與方式，不要立即替換所有設定。Connectivity Test 的結果也應依其測試對象解讀。測試工具可作為定位問題環節的證據，但不能取代實際存取驗證，也不能以單一成功狀態證明所有 App 都能正常運作。

最後進行本機網路對照時，只切換 Wi-Fi 與行動網路，不要同時變更伺服器、協定與 DNS。若結果隨本機網路而改變，再檢查網路限制與位址可達條件；若在不同網路下表現一致，再繼續核對伺服器參數與遠端路徑。測試結束後，還原原本需要的 Global Routing 模式，並停止不必要的批次探測。若遇到持續性的速度問題，可進一步閱讀網路、協定與線路速度檢查；不要將延遲數值當成頻寬測量結果。

如何取得有用的 Log

Log 的價值不在於內容越多越好，而在於能否對應至一次明確操作。開始排查前，先記錄目前網路、伺服器、Global Routing 與啟用中的設定；接著依目前介面的記錄功能啟用所需項目，發起一次失敗的存取，並立即查看對應時間附近的內容。若介面提供不同記錄範圍，選擇足以觀察問題的範圍即可。長時間累積的混合記錄含有大量無關連線，反而不容易判斷哪個錯誤與剛才的操作有關。

記錄開關與範圍的初始狀態，請以目前裝置顯示為準。日常建議保留符合實際需求的設定；問題重現期間可暫時擴大記錄範圍，結束後再還原原值。長時間開啟詳細記錄並不能提升連線品質，只會增加可供查看的資訊。若要清除舊記錄，先確認是否仍需要保留診斷證據；較穩妥的方式是先儲存已移除敏感資訊的相關片段，再建立一段明確時限的新測試，而不是一邊清除、一邊反覆操作。

依請求階段閱讀，不要只搜尋錯誤字詞

閱讀時可依「目標識別、規則命中、位址解析、遠端連線、協定交握、資料傳輸」的順序尋找線索。實際記錄未必完整呈現每個階段，也未必嚴格依此順序排列，因此只能根據已有證據判斷。出現逾時時，先確認是哪個對象逾時：解析服務、代理伺服器，還是目標網站。三者的處理方向不同，不要看到相同的錯誤字詞就一律修改 DNS 或更換所有伺服器資訊。

若記錄顯示請求命中 DIRECT，應先從規則與本機直連路徑檢查；若命中預期的代理策略，再檢查伺服器連線及協定參數。驗證失敗時，核對使用者現有資訊中的密碼、識別碼或相關參數；憑證錯誤則應檢查目標名稱、時間與憑證條件，不要將停用驗證當作通用修正方式。若沒有出現預期請求，先確認記錄範圍、是否建立了新連線，以及該請求是否進入目前的處理範圍；不要因此直接判定 App 沒有執行。

如何使用 Data 中的數值

Data 較適合觀察累計變化，而非證明單次連線是否成功。查看上傳、下載與累計值前，先確認目前畫面依據哪個對象統計，以及統計的起始時間。若目前介面提供依伺服器或 App 查看，應分別理解其分組依據。某部伺服器已有歷史數值，不代表它剛才仍在使用；某個 App 沒有新增數值，也可能與連線重用、統計更新或處理範圍有關，應搭配 Log 與實際操作判斷。

Data 與系統流量統計不完全相同是可能發生的，因為統計期間、流量歸屬、連線開銷與涵蓋範圍可能不同。進行比較前，先統一觀察時段，並記錄操作前後的增量，不要比較起始時間不同的總數。若可清除統計數值，請注意這只會變更相應的統計紀錄，不會修復連線；清除前先保存基準資料，否則會失去判斷依據。若要區分伺服器與 App 檢視方式，請參閱Data 頁面的流量數值說明。

分享診斷資料前先移除敏感資訊

記錄與設定可能包含訂閱網址、伺服器資訊、驗證參數及存取目標。分享前應逐項檢查，不要只遮住一處密碼：完整 URL 的查詢字串、QR Code 內容、請求標頭、設定註解及截圖邊緣都可能含有敏感資訊。通常只需提供問題發生時間、已移除敏感資訊的錯誤片段、目前模式與重現步驟。保留能辨識問題階段的上下文即可，不必公開完整設定來證明問題存在。完成診斷後，也應依自己的資料管理方式處理暫存匯出檔案。

如何核對 Widget 顯示狀態

Widget 提供方便查看或操作的入口；可用樣式與行為依目前系統及 App 提供的元件而定。系統可能限制背景更新，因此元件顯示的狀態不一定會與剛發生的變化同步更新。若元件仍顯示舊狀態，先開啟 Shadowrocket 的 Home，核對實際連線與所選伺服器，再透過新的存取確認。不要只憑元件文字判斷連線已建立，也不要因元件更新較慢就修改協定、規則或 DNS。

新增或調整 Widget 後，先確認元件是否關聯至預期內容，再分別測試從 App 內變更狀態、透過系統元件操作，以及裝置重新解鎖後的顯示情況。若某項操作需要開啟 App 或由系統確認，請依目前介面完成。系統授權、On Demand 條件與伺服器實際可用性仍然適用；Widget 入口無法略過這些步驟。建議只保留自己能說明用途的元件，避免多個入口顯示不同時間的狀態而造成誤判。

iCloud 同步不等於連線同步

iCloud 同步涉及可同步資料的儲存與傳送，不代表兩部裝置會同時建立連線，也不代表兩部裝置的系統授權、目前網路與暫時狀態完全相同。實際同步範圍請以 Shadowrocket 目前提供的選項為準，不要將「清單中已出現」直接解讀為「所有設定均已複製」。核對時應分別檢查伺服器清單、設定檔、所選項目及 App 層級設定，尤其要在目標裝置確認實際啟用的 Config。

同步相關開關的預設狀態請在本機核對。需要在多部裝置間管理現有資料時，先確認系統已登入預期的個人帳號、iCloud 功能可用，並查看 Shadowrocket 的相關同步選項；不需要跨裝置使用時，可維持目前設定。啟用同步前建議保留本機副本，因為同步不等於保證保留固定版本的備份。誤刪、覆寫或衝突處理結果可能同步至另一部裝置，不要將另一部裝置永遠視為獨立的復原來源。

如何處理同步延遲與衝突

兩部裝置的清單不一致時，先核對帳號與同步範圍，再確認兩端網路正常，並等待系統完成同步。不要立刻在兩部裝置上同時編輯同一份設定，也不要反覆關閉、開啟同步來強制更新，否則會增加判斷難度。選定一部裝置作為本次編輯來源，記錄其內容，再到另一部裝置確認是否出現相應變更。若目前介面提供明確的匯入、匯出或復原入口，請先確認其作用是合併還是取代，再進行操作。

處理衝突時，只比較設定檔名稱並不足夠；同名檔案內的規則可能已不同。請查看重要參數、規則順序及使用者自行記錄的修改說明。保留兩份副本進行比較，比直接覆寫更容易還原。同步完成後，在目標裝置重新核對所選伺服器、Global Routing、VPN 授權及 On Demand，並獨立進行一次存取測試。來源裝置正常只能證明來源裝置當下可用，不能取代目標裝置的實際測試。

使用者現有的訂閱與本機設定也應分開理解。同步訂閱項目，不代表此刻已重新取得訂閱內容；遠端訂閱更新與 iCloud 資料同步是不同流程。若項目存在但清單內容仍是舊的，應檢查該訂閱的更新結果，而非只等待系統同步。訂閱網址含有存取憑證，應視為敏感資料管理；不要為了比較兩端內容而將完整網址張貼至公開討論區。本頁僅說明既有資料的管理方式，不涉及任何服務的提供或推薦。

更換裝置時，分開核對購買資格與資料

App Store 的購買資格、App 資料還原與網路連線授權是不同事項。已購 App 可以重新取得，不代表所有本機設定都一定會還原；設定已還原，也不代表新裝置已完成首次 VPN 授權。更換裝置時，依序核對「取得 App、檢查資料、選擇設定、完成授權、驗證存取」。購買與重新安裝流程請參閱已購項目還原說明。如果舊裝置仍可使用，請在確認新裝置運作正常前保留舊裝置資料，避免遷移期間失去唯一可還原的副本。

兩種連接埠不可混為一談

Add Server 中的連接埠屬於使用者現有的伺服器連線資訊，必須符合遠端實際監聽的協定與連接埠；若 Settings 提供本機 Proxy 連接埠，則屬於本機代理服務的監聽參數，供適用情境中的用戶端請求連線。修改本機連接埠不會變更遠端伺服器設定，也無法修正遠端連接埠填寫錯誤。檢查時先釐清「誰連線到誰」：是 Shadowrocket 連線至伺服器，還是同一部裝置上的請求端連線至本機代理入口。

本機 Proxy 相關選項的名稱、可用協定與存取範圍，請以目前介面說明為準。本頁不提供通用預設連接埠，因裝置狀態、既有設定與功能狀態都可能不同。若沒有明確使用本機代理入口的需求，建議維持目前設定，不必為了一般 VPN 連線而隨意啟用額外的監聽服務。確有需求時，應記錄監聽位址、連接埠、協定，以及是否允許其他裝置存取，並確認接入端使用的協定與入口相符。

監聽位址決定可存取的對象

僅供本機使用與允許區域網路存取，適用範圍不同。若位址為迴圈位址，通常僅供本機存取；若監聽範圍擴及網路介面，網路中的其他裝置可能也能嘗試連線。不能只因兩端連接埠號碼相同，就認定能夠互通。還要檢查裝置是否位於可互相通訊的網路、網路是否隔離用戶端、目前位址是否變更，以及系統與 App 是否允許相關連線。存取範圍應以目前功能的實際說明與測試結果為準。

擴大存取範圍前，應確認確有需要，並採用目前功能提供的存取控制措施。不要把擴大監聽範圍當成本機連線失敗時的第一個修正步驟。對不熟悉的網路，應優先縮小可存取範圍，避免無關裝置使用代理入口。不再需要時，請關閉監聽或存取選項，並確認請求端已移除舊設定。否則，即使 App 狀態已變更，仍指向舊位址的請求端可能持續失敗，讓問題看起來像整個網路異常。

如何區分衝突與無法連線

同一監聽位址上的同一連接埠，通常不能任由多個服務重複使用。若介面或記錄顯示繫結失敗，先確認是否有衝突，以及連接埠值是否符合輸入要求，不要繼續調整遠端協定。若服務已開始監聽，但請求端仍無法存取，則檢查位址、網路路徑與協定選擇。HTTP 與 SOCKS5 的接入方式不同；請求端選錯協定時，可能出現連線已建立但請求無法完成的情況，不能只憑連接埠可連線就判定設定正確。

排查本機入口時，先在最小存取範圍內測試，再依需求擴大範圍。維持遠端伺服器與 Global Routing 不變，一次只修改一項本機參數，並同步更新請求端的對應設定。若更改連接埠卻未更新請求端，測試失敗代表兩端資訊不一致，不表示新連接埠不能使用。測試紀錄至少應包含監聽範圍、兩端連接埠、接入協定與錯誤階段；涉及網路位址時可移除敏感資訊，但不要刪除足以區分本機與遠端角色的上下文。

將所有變更還原至可復原狀態

診斷完成後，依記錄逐項收尾：還原不再需要的測試模式、關閉臨時擴大的記錄範圍與監聽，確認 On Demand 條件仍符合需求，檢查目前啟用的 Config，並重新存取一個已知目標。不要以「還原所有設定」取代逐項還原，除非已確認其影響範圍並保留完整副本。有效的診斷應減少不確定因素，而不是留下更多無法說明的開關。

若仍無法定位問題，請整理目前網路、所選伺服器、模式、設定檔名稱、重現步驟及已移除敏感資訊的記錄，再依伺服器、解析、規則與系統授權的層級逐步檢查。新發生的問題優先檢查最近一次變更；若沒有變更卻突然失敗，則核對本機網路與現有服務狀態。若需重新依完整操作流程檢查，請回到使用教學；若要依特定症狀尋找答案，請前往常見問題。保留足以重現問題的最小現場，比繼續疊加未經測試的參數更容易判斷。