Shadowrocket Settings 設定手冊

Chapter 01

Settings 的閱讀順序與可復原基準

先區分連線狀態、路由模式與設定參數

Shadowrocket 的常見問題往往不是單一開關造成，而是 Home 的連線狀態、Global Routing 的目前模式、選取的 Config、伺服器資訊與 Settings 參數共同作用的結果。開始調整前，先在 Home 確認目前選取的伺服器或設定是否符合預期，再記錄 Global Routing 處於 Config、Proxy 或 Direct。Config 表示依照設定檔中的 Rule 逐條比對；Proxy 表示將適用流量交給目前的 Proxy；Direct 表示直接連線。三種模式用途不同，不能把 Direct 下觀察到的結果當成 Config 規則失效，也不能在 Proxy 下判斷某條 DIRECT 規則是否命中。

Settings 適合處理解析、連線觸發、測試方式、日誌記錄、同步與本機連接埠等行為。它不會取代伺服器資訊，也不會自動補上尚未設定的服務。使用本手冊時，預設使用者已持有自己的 Subscribe 位址或伺服器參數，並知道這些資訊應由原提供方維護。Shadowrocket 是在 App Store 購買的一次性付費客戶端；客戶端一次買斷 ≠ 線路方案，購買應用程式本身不包含可用的伺服器資訊。若要核對開發者名 Shadow Launch Technology Limited、應用程式 ID 932747118 與商店入口，可查看下載指南的正版核驗部分。

建立修改前的四項記錄

建議在變更任何設定前寫下四項基準。第一項是網路環境，例如目前使用家用 Wi‑Fi、辦公室 Wi‑Fi 或行動網路；第二項是 Home 中實際選取的伺服器項目；第三項是目前的 Config 名稱與 Global Routing 模式；第四項是可重現的問題現象，例如「只有某個網域無法解析」、「切換到行動網路後不會自動連線」或「Connectivity Test 在某一步停止」。這四項資訊能把模糊的「不能用」拆成可驗證條件，也方便在恢復設定後判斷是否回到原本狀態。

修改時採用單一變數方法：一次只調整一個項目，儲存後關閉並重新建立連線，再執行相同的驗證動作。若同時更換 DNS、Config、伺服器與 On Demand 條件，即使問題暫時消失，也無法確認是哪一項發揮作用；反之，若出現新問題，也很難準確撤銷。對 DNS、IPv6、Proxy 連接埠與 iCloud 同步等可能影響多種情境的項目，單一變數記錄尤其重要。

如何理解預設值與建議值

Settings 中的預設狀態可能隨商店版本、裝置系統與既有設定遷移而變化，因此本手冊不把某個固定數字寫成所有裝置都相同的預設值。查看某個項目時，應分開理解客戶端目前顯示的值、重新安裝後由系統提供的狀態，以及 Config 中明確宣告的參數。Config 中明確寫入的項目通常比單靠介面慣例更容易重現，但前提是語法正確，且清楚該參數作用的範圍。

所謂建議值也不是越複雜越好。穩定使用時，優先保留系統或 Config 已經正常運作的值；只有能描述具體問題時，才加入覆寫設定。DNS 解析失敗才調整 DNS，網路切換觸發不符預期才檢查 On Demand，測試結果與實際存取不一致才重新選擇 Ping 或 Connectivity Test 方法。依照這個順序，可以避免把診斷功能誤當成加速功能，也能減少長期留下卻無人知道用途的設定。

Chapter 02

DNS：解析路徑、取值範圍與失敗定位

DNS 在連線過程中的位置

存取網域時，裝置需要先將網域解析為位址，再建立後續連線。節點延遲能夠回傳，只能表示測試使用的目標與路徑在某個階段可達，不能證明所有網域都已正確解析。因此，「Ping 看起來正常但網頁打不開」時，需要將 DNS 單獨列為檢查對象。Shadowrocket 中的 DNS 行為可能同時受系統網路、Settings、目前 Config 與具體 Rule 影響。判斷問題時，先確認是所有網域失敗、特定後綴失敗，還是只有切換網路後出現快取差異。

系統 DNS 適合作為基準：如果 Direct 模式下常用網站也無法開啟，應先檢查目前的 Wi‑Fi 或行動網路，而不是立即修改複雜參數。如果 Direct 正常、Proxy 正常但 Config 下部分網域失敗，則應檢查規則命中與 Config 的 DNS 宣告。如果只有一個網域異常，可以比較其主網域、子網域以及直接輸入位址時的結果，避免把目標服務本身故障誤判成全域解析故障。

選擇解析方式時應注意的三個邊界

第一是解析請求從哪裡發出。使用系統提供的解析路徑時，結果通常與目前網路一致；在 Config 中指定 DNS 時，應確認該位址在目前網路環境中可達。第二是回傳結果如何交由規則判斷。DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 直接依網域比對，而 GEOIP、IP-CIDR 與 IP-CIDR6 則需要位址資訊參與判斷。第三是快取何時更新。更改 DNS 後若仍看到舊結果，應中斷目前連線，等待系統網路狀態更新後重新建立連線，再用同一網域重新測試。

日常使用時，建議先使用能穩定運作的系統解析路徑，不要因為偶發現象同時加入多組解析位址。需要在 Config 中指定時，應控制數量並記錄順序，避免首選位址不可達，導致每次查詢都等待逾時。使用加密解析方式時，也要考慮其服務網域本身如何完成初始解析；如果初始路徑遭到阻斷，表面上就會出現「設定更先進但完全無法解析」的結果。排錯時先回到簡單路徑，再逐層增加條件。

Config 中的 DNS 與規則協作

設定檔可以明確記錄 DNS 與 Rule，但不要把不熟悉的範例整段複製到正在運作的 Config。先複製一份設定作為測試副本，再只加入必要項目。規則由上到下比對，越具體的網域規則通常應放在越前面的位置，FINAL 負責承接前面未命中的連線。若 DOMAIN-SUFFIX 已將某個網域交給 PROXY，後續 GEOIP 規則不會再次改寫同一請求的策略。診斷 DNS 時，應同時查看解析是否成功，以及最後命中了哪條規則。

[General]
dns-server = system

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

以上片段用於說明結構與比對順序。example.com 是文件範例網域，不代表實際服務；dns-server = system 表示從系統解析路徑開始建立基準。實際 Config 也可能包含代理群組、遠端規則與其他 General 項目，合併時必須保留原有段落結構，避免重複的節標題或拼字錯誤。儲存後先確認 Config 能正常讀取，再測試規則，而不是在解析失敗時繼續加入更多 DNS 位址。

逐步排查解析失敗

第一步切換到 Direct，測試兩個互不相關的網域。如果都失敗，處理本機網路；如果都成功，進入第二步。第二步切換到 Proxy，保持同一台伺服器不變；若失敗，檢查伺服器連線與協定參數，不要先修改 Rule。第三步切換到 Config，觀察問題是否只在規則模式下出現。第四步開啟 Log，尋找目標網域對應的比對結果，確認是由 DOMAIN-SUFFIX、GEOIP 還是 FINAL 接手。第五步才修改 DNS，並在每次修改後重新建立連線。

如果問題集中在「有時成功、有時失敗」，需要記錄發生時間、網路類型，以及是否剛切換 Wi‑Fi。間歇性失敗常與首選解析位址逾時、切換網路後連線未重建或多個位址的回傳順序變化有關。不要只連續點擊 Ping 下結論，應以實際網域請求、Log 與 Connectivity Test 的綜合結果判斷。更完整的分層案例可繼續閱讀DNS 設定與解析失敗排查。

Chapter 03

On Demand：自動連線條件與網路切換

On Demand 解決什麼問題

On Demand 用於依據網路狀態觸發連線，不是取代 Home 中的手動開關，也不會自動判斷某台伺服器目前是否適合使用。啟用前必須先確認手動連線穩定：在固定網路下選擇明確的伺服器與 Config，手動建立連線並完成存取驗證。若手動連線本身失敗，加入 On Demand 只會讓失敗更頻繁地觸發，甚至讓使用者難以判斷客戶端何時重新連線。

自動連線最常見的用途，是裝置在 Wi‑Fi 與行動網路之間切換後維持預期狀態，或對已知網路採取不同動作。設計條件時應從少量、明確且互不衝突的規則開始。每條條件都要能回答三個問題：它會比對哪類網路、比對後執行什麼動作、沒有比對結果時採用什麼預設行為。不要用多個範圍重疊的條件描述同一網路，否則實際結果會取決於比對順序，後續排錯也會變得困難。

先定義網路分類，再決定動作

可以將日常環境分為信任的固定 Wi‑Fi、其他 Wi‑Fi 與行動網路三類。這裡的「信任」僅表示使用者熟悉該網路，並願意為它指定獨立動作，不代表對網路安全作出絕對判斷。固定 Wi‑Fi 通常透過網路名稱辨識；其他 Wi‑Fi 作為兜底；行動網路則單獨處理。若裝置經常連線到名稱相同但實際不同的網路，不宜只依賴名稱作複雜決策，應保留手動確認步驟。

動作選擇應以實際需求為中心。若希望進入某類網路後自動建立 Shadowrocket 連線，就為該條件指定連線行為；若希望維持手動控制，則不要為該網路設定強制觸發。設定完成後必須逐一測試各種環境，而不是只確認開關已開啟。測試時先停留在一個網路，記錄 Home 狀態；再切換到第二個網路，等待系統完成網路變更，觀察連線是否重新建立；最後返回第一個網路，確認行為可重現。

條件順序與衝突判斷

範圍具體的條件應排在範圍寬泛的條件之前。例如，針對某個固定 Wi‑Fi 的規則應先於「任意 Wi‑Fi」一類的兜底條件。若寬泛條件先命中，後面的具體條件可能沒有機會生效。修改順序後要重新執行網路切換測試，並檢查 Home 是否顯示預期狀態。遇到反覆連線、連線開關在短時間內多次變化時，優先懷疑條件互相覆蓋、系統網路在兩個接入點之間切換，或目前 Config 無法在新網路完成連線。

On Demand 與系統網路狀態密切相關。裝置剛解鎖、網路訊號較弱或 Wi‑Fi 正在取得位址時，連線建立可能晚於介面變化。此時不要連續手動切換開關，因為手動動作可能與自動觸發重疊。先等待網路狀態穩定，再查看 Log 中是否出現新的連線過程。如果自動觸發後使用了錯誤的伺服器或 Config，應檢查切換前 Home 中實際選取的項目，而不是把問題歸因於 On Demand 條件本身。

建議啟用步驟

第一步關閉 On Demand，在常用 Wi‑Fi 下手動連線，驗證 DNS、規則與存取均正常。第二步保持伺服器與 Config 不變，在行動網路下重複手動驗證。第三步只建立一條最常用的條件，開啟 On Demand 後完成一次往返切換。第四步查看 Log，確認每次網路變化只觸發一次清楚的重新連線。第五步再加入第二類網路條件。只要任一步驟出現異常，就撤回剛加入的條件，不要繼續擴充。

需要暫時排查網路問題時，可以關閉 On Demand，避免自動重新連線干擾對照測試。關閉後仍應檢查 Home 的目前連線狀態，因為停用自動觸發不等於立即改變已建立的連線。完成排錯後，先恢復可運作的手動狀態，再重新開啟 On Demand。這樣可以將「連線本身是否可用」與「自動條件是否正確」分成兩個獨立問題。

Chapter 04

Ping 與 Connectivity Test：如何解讀測試結果

延遲數字不等於完整連線品質

Ping 用於快速觀察目標是否能以指定測試方式回應，以及往返耗時的大致範圍。它適合發現完全無法到達、明顯逾時或同一網路下結果差異較大的項目，但不能單獨證明網頁、影片或其他應用程式流量一定正常。實際連線還涉及 DNS、目標連接埠、協定握手、傳輸參數、規則命中以及目標服務回應。只根據一次延遲排序選擇伺服器，容易把偶發抖動當成穩定差異。

執行 Ping 前應固定測試條件：保持同一網路、相同的 Global Routing 模式與相同測試方式，避免掃描期間切換 Wi‑Fi。至少觀察兩到三輪結果，重點看是否持續逾時、波動是否過大，而不是追求單次最小數字。若所有項目同時變差，優先檢查本機網路；若只有一個項目持續異常，再檢查該伺服器資訊或其網路路徑。測試資料只用於定位，不應用來臆測長期效能。

Connectivity Test 的分層價值

Connectivity Test 更適合回答「連線過程停在哪一層」。測試項目可能隨目前介面與網路環境呈現不同內容，但閱讀順序應保持一致：先確認本機網路具備基本連通性，再確認伺服器位址可達，接著觀察協定握手與實際請求是否完成。某一步通過只代表該層成立，後續步驟仍可能失敗。例如伺服器位址可達不代表驗證參數正確，協定握手成功也不代表 DNS 與 Rule 會將目標請求交給預期策略。

測試失敗時記錄最早失敗的階段，不要只記錄最後的紅色結果。最早失敗點更接近原因：如果在解析階段就停止，應轉到 DNS 章節；如果伺服器連線階段逾時，應核對網路可達性與伺服器資訊；如果實際請求失敗而前面階段通過，應檢查 Rule、FINAL、目標服務與協定傳輸參數。修改後重複同一測試，確認失敗點是否後移或消失。

如何減少測試誤差

測試期間關閉會持續產生大量網路請求的前景工作，可讓 Log 更容易閱讀，但不必改變所有系統設定。保持裝置位置與網路接入點不變，先測試一個已知可運作的項目作為對照，再測試目標項目。若使用行動網路，訊號變化會直接影響延遲；若使用 Wi‑Fi，接入點切換與區域網路壅塞也會造成波動。單次逾時後先重複驗證，不要立即修改協定參數。

比較不同伺服器時，應確認測試方式一致。有些測試只驗證 TCP 建立連線，有些可能包含實際請求；如果方法不同，數字不能直接橫向比較。Shadowrocket 目前介面提供哪些 Ping 方式，應以 Settings 中實際項目為準。不熟悉選項含義時，保留預設或目前可運作的方式，不要因數字較小就頻繁切換。排查「速度慢」還要分別考慮本機網路、伺服器、線路時段、協定與目標服務，可參考速度慢分層排查。

從測試結果回到設定項目

如果 Ping 全部逾時但 Direct 存取正常，檢查測試是否透過目前 Proxy、伺服器位址是否可達，以及協定參數是否完整。如果 Ping 正常而 Connectivity Test 在解析階段失敗，依 DNS 路徑排查。如果兩者都正常但 Config 下存取不符預期，查看 Log 中 DOMAIN、GEOIP、IP-CIDR 或 FINAL 的比對結果。如果 Proxy 下正常而 Config 下失敗，問題通常更接近規則或設定，而不是伺服器本身。

完成診斷後，應將臨時測試設定恢復為長期使用所需的狀態。例如為了對照而切到 Direct，結束後要明確恢復 Config；為了觀察詳細過程而提高 Log 記錄範圍，完成後應依實際需求調整；為了測試某台伺服器而變更選取項目，也要確認 Home 最終使用的是預期項目。診斷的結束標準不只是問題暫時消失，還包括設定回到可理解、可重現的狀態。

Chapter 05

Log 與 Data：查看規則命中與流量記錄

Log 應回答哪些問題

Log 的主要用途是還原某次請求經過了哪些判斷，而不是只尋找醒目的錯誤文字。閱讀一筆記錄時，依序注意時間、目標網域或位址、命中的 Rule、最終策略以及錯誤發生階段。對於規則問題，最關鍵的是確認請求是否命中預期的 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、IP-CIDR6 或 FINAL。若記錄顯示命中了更前面的規則，就需要回到 Config 調整順序，而不是反覆切換伺服器。

開始記錄前先清除不相關操作：保留一個測試目標，只執行一次開啟或重新整理，然後立即返回 Log 尋找對應時間段。背景應用程式會產生大量系統請求，不能看到陌生網域就認定異常。應透過時間、目標與重複動作建立對應關係。例如連續兩次存取同一範例網域，Log 中在相近時間出現兩筆相似記錄，才更容易確認哪筆屬於本次測試。

錯誤資訊的分層閱讀

解析相關錯誤通常指向 DNS 位址不可達、網域沒有回傳結果，或切換網路後解析路徑尚未恢復。連線逾時更接近伺服器位址、目標連接埠或網路路徑問題。握手或驗證失敗需要核對使用者既有伺服器資訊中的協定、密碼、UUID、傳輸參數或憑證相關設定是否一致。規則命中與預期不同，則應檢查 Config 的順序與關鍵字。不同層的錯誤不宜採用同一種處理方式。

如果錯誤只出現一次，之後請求便成功，可以先觀察是否與網路切換或短暫逾時有關；如果每次都在同一階段失敗，則依該階段進行單一變數檢查。不要一次匯出大量日誌後只搜尋「error」，因為前一筆連線動作與下一筆回退策略同樣重要。記錄時間線比孤立的錯誤詞更有價值。

Data 適合觀察什麼

Data 用於查看客戶端記錄的流量概況與連線使用情況。它能幫助發現某個應用程式或網域是否持續產生請求，也能作為調整規則前後的輔助對照，但不能單獨用來判斷計費、網路品質或伺服器狀態。系統統計口徑、連線重用與快取都可能讓 Data 與使用者直觀看到的頁面大小不同，因此應將它視為趨勢資訊，而不是精確帳單。

觀察 Data 時先限定時間範圍與測試動作。例如調整一條 DOMAIN-SUFFIX 規則前，記錄對應目標在現有策略下的表現；調整後重新連線，只執行相同請求，再比較是否由預期策略處理。若背景應用程式持續產生流量，應避免用總量判斷單一目標。排查異常增長時應回到 Log，確認具體網域與策略，而不是只憑 Data 刪除 Config 或伺服器項目。

分享診斷資訊前的整理

向伺服器資訊提供方回報問題時，建議提供問題發生時間、網路類型、協定名稱、Connectivity Test 最早失敗的步驟，以及整理過的 Log 片段。伺服器位址、密碼、UUID、Subscribe 位址中的存取憑據與其他敏感參數，不應出現在公開截圖或公開文字中。可以保留網域後綴、錯誤階段與規則關鍵字，以便說明問題所在層。

整理日誌時不要改寫錯誤含義。若必須遮蓋內容，應統一替換敏感部分，並保留欄位結構與相鄰上下文。例如保留「某目標命中 DOMAIN-SUFFIX 後使用 PROXY，接著連線逾時」的順序，比只提供一張最後失敗的頁面更方便判斷。問題解決後，可以刪除暫時匯出的診斷檔案，並將 Log 記錄範圍恢復到日常所需狀態。

Chapter 06

Widget 與 iCloud 同步：快速操作與設定遷移

Widget 是快速入口，不是獨立連線

Widget 提供從系統介面查看或觸發常用狀態的快速方式，但仍依賴 Shadowrocket 中已存在的伺服器、Config 與連線權限。Widget 顯示異常時，應先開啟 Shadowrocket，確認 Home 能正常載入並可手動連線，再檢查系統是否允許 Widget 更新。若客戶端尚未完成首次連線授權，單獨操作 Widget 不能繞過這個步驟。

設定 Widget 時應只放入高頻且含義明確的動作。若同時放置多個名稱相近的伺服器或 Config，快速操作容易選錯。建議讓項目名稱能反映用途，但不要在名稱中寫入密碼、位址憑據或其他敏感內容。修改 Shadowrocket 內部項目後，如果 Widget 仍顯示舊狀態，可先進入客戶端確認已成功儲存，再讓系統更新 Widget，而不是反覆刪除目前可運作的設定。

Widget 狀態與實際狀態不一致

系統可能為了電量與資源管理而延遲 Widget 更新，因此介面顯示與 Home 的即時狀態可能有短暫差異。判斷連線是否建立，應以開啟 Shadowrocket 後的 Home 狀態與實際請求驗證為主。若點擊 Widget 後沒有預期動作，先檢查裝置是否剛重新啟動、客戶端是否被系統要求重新確認權限、目前網路是否可用，以及 On Demand 是否同時觸發了其他連線行為。

排查順序為：先從 Home 手動完成一次連線；再回到 Widget 執行相同動作；若 Home 成功而 Widget 失敗，移除並重新加入系統中的 Widget；若兩者都失敗，問題不在 Widget，應轉向伺服器資訊、DNS 或網路測試。不要在 Widget 故障時修改 Proxy 連接埠或 Rule，這些項目通常與系統快速入口更新沒有直接關係。

iCloud 同步的作用範圍

iCloud 同步用於在符合條件的 Apple 裝置之間儲存或同步應用程式資料，具體可同步的內容與呈現方式以目前 Shadowrocket 介面為準。它不等於對每項資料進行即時、雙向且無衝突的複製，也不應取代手動備份。啟用前先檢查裝置使用的 iCloud 狀態，再確定哪台裝置上的設定是目前基準。多台裝置同時編輯同名 Config 時，可能出現舊內容覆蓋新內容，或產生難以辨認的副本。

建議採用「主裝置修改、其他裝置核對」的順序。先在主裝置完成 Config 變更並驗證可用，記錄設定名稱與關鍵 Rule；等待同步後，在另一台裝置開啟 Shadowrocket，確認伺服器項目、Config 內容與 Global Routing 是否符合預期。若沒有更新，不要立刻在第二台裝置重新編輯同名項目，因為這可能形成新的衝突。先檢查 iCloud 狀態、網路與客戶端是否已完成載入。

匯入、同步與 Subscribe 更新的差異

Import from Cloud JSON 是一次性的匯入動作，iCloud 同步是裝置間的資料同步機制，Subscribe 更新則根據使用者既有的 Subscribe 位址重新整理對應項目。三者不要混為一談。匯入 JSON 後取得的是匯入當下的資料副本；後續是否變化取決於使用者如何維護。Subscribe 更新通常會依來源重新產生相關項目，手動修改的欄位是否保留應以實際結果為準。iCloud 則可能將本機變更帶到其他裝置。

執行任何批次變更前，先保留可運作的 Config，並記錄目前選取的伺服器。更新後不要立即刪除舊項目，應先檢查新項目的協定、位址、連接埠與名稱是否完整，再執行 Ping 或 Connectivity Test，最後透過 Config 驗證 Rule。發現重複項目時，先辨識來源，再決定保留哪一份；只憑名稱相同就批次刪除，可能誤刪仍被 Config 引用的項目。

跨裝置使用核對清單

在 iPhone 與 iPad 之間遷移後，至少核對五項：Home 目前的伺服器、Global Routing 模式、Config 是否存在且能開啟、On Demand 是否符合該裝置的網路環境、Widget 是否指向有效項目。裝置用途不同，On Demand 條件未必應完全相同。例如經常移動的 iPhone 與長期連接固定 Wi‑Fi 的 iPad，可以共用基礎 Config，但分別維護自動連線條件。

Mac、Apple TV 與 Apple Vision 的相容性資訊可在同一個 App Store 產品頁查看，具體系統需求以 App Store 頁面標示為準。即使資料能夠同步，也應在每台裝置上分別確認網路權限、可用介面項目與實際連線結果。同步完成只表示資料可能已抵達，不代表連線環境也完全一致。

Chapter 07

Proxy 連接埠：本機監聽、區域網路存取與衝突檢查

Proxy 連接埠代表什麼

Settings 中的 Proxy 連接埠用於讓本機應用程式透過指定的 HTTP 或 SOCKS5 入口，將連線交給 Shadowrocket。連接埠是裝置上的本機監聽編號，不是遠端伺服器連接埠，也不是協定設定中的服務端連接埠。兩者數字即使偶然相同，含義仍然不同。修改 Proxy 連接埠不會修復伺服器密碼、UUID 或傳輸參數錯誤，也不會改變 Config 中 Rule 的比對順序。

日常只使用系統連線開關時，通常不需要頻繁調整本機 Proxy 連接埠。只有某個應用程式明確支援手動填寫 HTTP 或 SOCKS5 Proxy，或需要進行本機除錯時，才應注意這些值。填寫時以 Shadowrocket 目前 Settings 顯示的位址與連接埠為準，不要套用其他裝置上的數字。連接埠取值應在合法範圍內，並避免與裝置上其他正在監聽的服務衝突。

本機位址與區域網路位址的差異

本機應用程式連線到本地 Proxy 時，通常使用回送位址或 Settings 顯示的本機入口。回送位址只指向目前裝置，其他裝置不能將自己的回送位址當成這台 iPhone 或 iPad。若需要讓區域網路中的另一台受控裝置存取，必須確認 Shadowrocket 是否開啟相應的區域網路監聽能力、系統是否授予區域網路存取權限，並使用提供服務的裝置在目前區域網路中的實際位址。

區域網路存取會擴大監聽範圍，應只在確有需要、網路環境可控且了解存取方的情況下啟用。完成除錯後恢復原本狀態。公共 Wi‑Fi 或無法確認同網路裝置的環境，不適合作為長期共用入口。即使開啟監聽，另一台裝置也必須與提供服務的裝置處於可達網路；網路隔離、訪客網路與路由器策略都可能阻止連線。

連接埠衝突的表現與處理

連接埠衝突可能表現為監聽無法啟動、應用程式連線立即遭拒，或填入正確位址後仍無法存取。排查時先恢復 Shadowrocket 原有連接埠並重新連線；若原值可用而新值不可用，表示新連接埠可能已被佔用或填寫不一致。修改後需要同步更新所有使用該本機 Proxy 的應用程式，舊設定不會自動跟隨。不要一次同時修改 HTTP 與 SOCKS5 兩個連接埠，否則難以確認是哪一個發生衝突。

確認協定類型同樣重要。應用程式要求 HTTP Proxy 時，應填寫 HTTP 對應入口；要求 SOCKS5 時，應填寫 SOCKS5 對應入口。將類型與連接埠交叉填寫，可能導致連線建立失敗或請求行為異常。若應用程式支援驗證欄位，而 Shadowrocket 目前的本機入口不要求相同方式，應依客戶端實際設定填寫，不要自行加入遠端伺服器憑據。

區域網路除錯的最小步驟

先在提供服務的裝置上確認 Shadowrocket 手動連線正常。然後只開啟必要的區域網路存取設定，記錄目前網路位址與對應 Proxy 連接埠。在同一受控網路中的另一台裝置上填入該位址、連接埠與正確的 HTTP 或 SOCKS5 類型，只存取一個測試目標。若失敗，依序檢查兩台裝置是否確實處於同一網路、系統區域網路權限、路由器是否隔離裝置，以及連接埠是否填寫一致。

如果另一台裝置能連線到連接埠但目標請求失敗，應回到 Shadowrocket 的 Log 查看請求是否抵達、命中了哪條 Rule、使用了哪種策略。如果 Log 中完全沒有對應時間的請求，問題更接近區域網路路徑或填寫錯誤；如果請求出現但後續逾時，則依 DNS、伺服器或規則繼續排查。測試結束後關閉不再需要的區域網路監聽，並刪除另一台裝置中的臨時 Proxy 設定。

什麼時候不應修改 Proxy 連接埠

當問題是 Subscribe 無法更新、伺服器 Ping 逾時、某個 DOMAIN-SUFFIX 命中錯誤、On Demand 不觸發或 DNS 解析失敗時，本機 Proxy 連接埠通常不是首要檢查項目。連接埠設定只影響透過該入口連線的應用程式，不會統一修復所有網路問題。先確認故障情境是否真的使用本機 HTTP 或 SOCKS5 入口，再決定是否調整。

若只是希望在 iPhone 或 iPad 上正常使用 Shadowrocket，應優先完成 Home 連線、Global Routing、Config 與實際存取驗證。Proxy 連接埠屬於有明確手動代理需求時的延伸設定。保留目前可運作的值通常比嘗試隨機數字更穩妥；必須修改時記錄原值，並在驗證結束後決定是否長期保留。

Chapter 08

Config 維護：規則順序、備份與完整排錯流程

Config 的職責範圍

Config 用於組織 General 設定、Rule、代理群組與其他連線行為。它決定請求如何分類並交給 PROXY、DIRECT 或 REJECT，但不會自動修正錯誤的伺服器資訊。維護 Config 時，應將「伺服器是否可連線」與「規則是否依預期選擇策略」分開驗證：先在 Proxy 模式下確認目前伺服器可用，再回到 Config 模式檢查 Rule。若 Proxy 已失敗，繼續調整 DOMAIN-SUFFIX 或 GEOIP 沒有診斷價值。

規則依照由上到下的順序比對。DOMAIN 適合精確網域，DOMAIN-SUFFIX 涵蓋指定後綴及其子網域，DOMAIN-KEYWORD 依網域中的關鍵字比對，USER-AGENT 依請求特徵比對，GEOIP 依位址歸屬判斷，IP-CIDR 與 IP-CIDR6 依位址範圍比對。範圍越寬的規則越容易提前攔截請求，因此通常應將明確、具體的規則放在寬泛規則之前，並讓 FINAL 位於規則末尾負責兜底。

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

範例展示關鍵字與順序，不應直接覆蓋使用者現有的 Config。範例位址僅供文件使用，實際維護時要依自己的目標與服務資訊編寫。請注意 DOMAIN-SUFFIX,example.com,PROXY 位於範圍更寬的 DOMAIN-KEYWORD,example,DIRECT 之前，因此對應後綴會先使用 PROXY。若調換順序，關鍵字規則可能提前命中並改變結果。這也是查看 Log 時必須記錄「命中了哪一條」的原因。

Config、Subscribe 與手動項目的關係

使用者既有的 Subscribe 負責提供相應伺服器項目，Config 負責描述規則與策略，兩者可以互相關聯但不是同一份內容。更新 Subscribe 後，項目名稱、順序或可用性可能改變；如果 Config 引用了特定名稱，應確認該引用仍然存在。手動加入的 Add Server 項目則取決於使用者輸入的協定參數。不論來源為何，更新後都要先核對協定、位址、連接埠與必要欄位，再進行測試。

不建議直接在唯一可運作的 Config 上進行大範圍重寫。先複製測試副本，在副本中一次修改一組相關規則，並保留原檔作為回退。若設定來自使用者信任且自行選擇的來源，應記錄更新時間與本機修改位置，避免下次更新覆蓋手動修改後無法辨認。本網站只說明 Shadowrocket 的匯入與維護方法，不提供伺服器資訊或 Subscribe 內容。

從最小設定逐步恢復

當複雜 Config 出現難以定位的問題時，可以複製一份測試設定，只保留必要的 General、少量明確規則與 FINAL。先驗證一條 DOMAIN 規則，再加入 DOMAIN-SUFFIX，接著加入 GEOIP 或位址範圍規則。每增加一組就重新連線並查看 Log。這樣能夠識別是哪一組規則、哪個遠端資源或哪個 General 設定引入問題，而不是在數百條規則中隨機移動位置。

若最小設定正常而原設定失敗，比較兩者的 DNS、Rule 順序、代理群組引用與重複段落。若最小設定也失敗，則回到 Proxy 模式驗證伺服器，再到 Direct 驗證本機網路。完整流程應始終從環境到連線、從連線到設定、從設定到單一目標，不能倒過來只盯著最後頁面。

完整故障排查順序

1. 確認本機網路：在 Direct 下存取多個互不相關的目標，判斷 Wi‑Fi 或行動網路是否具備基本連通性。
2. 確認伺服器：切換到 Proxy，固定一台伺服器，使用 Ping、Connectivity Test 與實際請求交叉驗證。
3. 確認 Config：切回 Config，查看目標請求命中的 Rule 與最終策略。
4. 確認 DNS：若網域無法解析，使用系統路徑建立基準，再檢查 Config 中的覆寫設定。
5. 確認自動觸發：手動連線穩定後，再啟用 On Demand 並執行網路切換測試。
6. 確認延伸功能：最後核對 Widget、iCloud 同步與 Proxy 連接埠，不讓輔助功能干擾主要診斷流程。

如果完成上述步驟仍無法判斷，可在FAQ中依「規則與故障排查」尋找具體症狀。回報問題時提供最小重現條件、失敗階段與處理過的 Log，不要公開伺服器憑據。首次使用者建議回到快速上手教學，重新確認 Add Server、Subscribe、Global Routing 與連線驗證主線；本手冊用於解釋設定細節，不取代首次操作順序。

維護後的收尾檢查

每次完成較大調整後，檢查 Home 目前的伺服器、Global Routing、Config、On Demand、DNS、Widget 與本機 Proxy 連接埠，確認臨時測試值已恢復。為 Config 保留一份已驗證副本，並用清楚名稱區分正式設定與測試設定。更新 Subscribe 或透過 Import from Cloud JSON 匯入資料後，重新核對引用關係，不要預設舊名稱一定維持不變。

Shadowrocket 的應用程式更新由 App Store 提供。iPhone、iPad 以及商店相容性欄中列出的其他 Apple 裝置，其系統需求均以 App Store 頁面標示為準。需要重新核對購買、恢復已購內容或裝置說明時，使用本網站的App Store 下載指南進入產品頁。設定維護的目標，是讓每項參數都能說明用途、能夠重現，並在出現問題時可以回退，而不是長期累積無法解釋的開關與規則。