新增伺服器或匯入既有訂閱
手動填寫單一伺服器
開啟 Shadowrocket 後先停留在 Home。在下方找到 SERVER 分組，點選 Add Server 進入新增頁面。第一項通常是 Type，必須與既有伺服器資料標示的協定一致，例如 Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 或 Hysteria2。協定只是欄位結構的入口，不能僅憑連接埠或伺服器名稱推斷。
選定 Type 後，依照原始資料逐項填寫 Host、Port、Password、Method 以及該協定實際要求的其他欄位。Host 應填寫主機名稱或 IP 位址，不要附加說明文字；Port 只填寫連接埠值；Password、UUID、Method、TLS 等內容須保持原有大小寫與字元順序。若資料未提供某個欄位，不要任意補值，應先確認該 Type 是否確實需要。
Type: Shadowsocks
Host: example.com
Port: 443
Password: your-password
Method: 以既有資料為準上方內容僅用於說明欄位位置，不是一組可連線的資訊。填寫完成後使用頁面上的儲存操作返回 Home。新項目應出現在 SERVER 分組中；點選該項目，使其成為目前選取的伺服器。此時先不要急著修改 Global Routing，先確認名稱、Type、Host 與 Port 都與原始資料一致。
透過 Subscribe 匯入既有訂閱
如果已有完整訂閱連結，可在伺服器或訂閱管理入口選擇 Subscribe。將連結完整貼到對應網址欄，視需要填寫方便辨識的名稱，然後儲存並執行更新。範例形式可以寫成：
https://example.com/sub?token=xxxx範例網域與參數僅用於展示連結結構。實際操作必須使用使用者自己已有的完整網址。貼上後重點檢查三處：開頭是否包含正確的 https://，網址中間是否因換行產生空格，結尾參數是否被聊天工具截斷。更新成功後，Home 的 SERVER 分組會出現訂閱回傳的項目；更新失敗時先保留原連結，不要連續建立多個同名 Subscribe 項目。
訂閱是批次維護伺服器資訊的一種方式。日後服務提供方更新內容時，應在原有 Subscribe 項目上執行更新，而不是反覆貼上並產生重複清單。手動修改由訂閱產生的項目，也可能在下次更新時被訂閱內容覆蓋。若要保留個別調整的伺服器，應先確認該項目是否由訂閱管理，再決定修改方式。
選擇設定、代理或直連模式
回到 Home，點選 Global Routing。中文說明中通常將三種模式寫作設定（Config）、代理（Proxy）、直連（Direct）。它們決定流量進入 Shadowrocket 後採用的處理方式，不等同於伺服器是否可用。
設定（Config）：依規則逐條判斷
Config 適合日常規則分流。請求會依照目前設定檔中 Rule 的排列順序由上到下比對，命中第一條適用規則後採用對應策略。常見關鍵字包括 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、IP-CIDR6 與 USER-AGENT；處理結果通常是 PROXY、DIRECT 或 REJECT。實際結果取決於設定檔本身，而不是關鍵字名稱。
進入 Config 後，先確認目前選取的設定檔，再查看 Rule。較具體的網域或位址規則通常放在前面，範圍較廣的規則放在後面，最後由 FINAL 處理此前未命中的請求。如果寬泛規則過早出現，後續較具體的項目就沒有比對機會。
代理（Proxy）：統一交由目前伺服器處理
Proxy 用於將進入 Shadowrocket 的流量統一交由目前選取的伺服器處理。適合進行短時間對照測試：如果 Config 下某個目標無法如預期存取，而 Proxy 下可以，問題較可能位於規則比對、策略名稱或 Config 選擇；如果 Proxy 下同樣失敗，則應優先檢查伺服器資料、連通性、DNS 或本地網路。
直連（Direct）：不交由代理伺服器處理
Direct 讓流量直接使用目前網路。同樣適合用於對照判斷。例如某個目標在 Direct 下正常、Proxy 下失敗，應回頭檢查伺服器連通性與伺服器參數；若 Direct 下也異常，問題可能來自目前 Wi-Fi、行動網路、DNS 或目標本身。Direct 是排錯模式，不代表已驗證伺服器。
初次設定時，建議先使用 Proxy 進行一次伺服器連通性基準測試，再回到 Config 檢查分流結果。不要把 Global Routing 的切換當成永久解決方案：Proxy 能存取而 Config 不能時，應找出具體規則命中的差異；Config 能正常運作後，才算完成規則層設定。
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY這段規則僅展示依序比對的寫法。第一條會優先處理指定網域後綴，區域網路位址由 IP-CIDR 直連，未命中的請求最後進入 FINAL。實際設定應依使用者自己的使用目標整理。關於規則優先順序、DNS 與複雜問題的系統化說明，可繼續閱讀故障排查文件。
開啟連線開關並確認狀態
連線前回到 Home，由上到下快速核對一次：SERVER 分組中已選取目標伺服器，Global Routing 顯示預期模式，目前 Config 與規則也已確認。接著開啟頂端連線開關。首次建立連線時，系統會顯示 VPN 設定授權提示；依系統流程確認後，Shadowrocket 才能建立本機網路通道。
開關開啟後，Home 頂端狀態應由 Not Connected 變為 Connected。狀態變化表示本機通道已建立，但不能單獨證明遠端伺服器可用，也不能證明每個請求都命中預期規則。因此看到 Connected 後，還要繼續進行 Connectivity Test 與實際請求驗證。
如果狀態短暫變化後立即回到 Not Connected，不要連續快速點按開關。先等待幾秒，再檢查目前伺服器是否已選取、欄位是否完整，以及系統是否允許建立 VPN 設定。若系統中有其他網路狀態正在切換，也應等 Wi-Fi 或行動網路穩定後再試。
先建立單一且可重複的測試條件
首次測試時，不要同時開啟 On Demand、頻繁切換 Config 或連續更換多個伺服器。建議固定一個網路、一台伺服器與一種 Global Routing 模式，完成一次完整驗證後再變更下一項。如此可將「開關無法維持」、「伺服器逾時」與「規則命中不符」分開處理。
在 iPad 上，Home 可能因橫向顯示或分欄而改變項目排列，但操作邏輯相同：選擇伺服器、查看 Global Routing、開啟連線，再進行驗證。Mac、Apple TV 與 Apple Vision 的相容情況可在同一個 App Store 產品頁查看，系統需求以 App Store 頁面標示為準；本頁步驟以 iPhone 與 iPad 為主。
驗證伺服器連通性與規則命中
驗證應分為兩層：第一層檢查選取的伺服器能否建立有效連線，第二層檢查實際請求是否依照 Global Routing 與 Config 規則處理。只看開關狀態會漏掉遠端逾時，只看單次網頁結果又難以區分快取、DNS 與規則的影響。
執行 Connectivity Test
在 Home 點選 Connectivity Test，對目前伺服器執行連通性測試。若測試能夠完成，表示伺服器資料與目前網路至少具備基本通訊條件；若出現 timeout 或持續沒有結果，先回到 Add Server 核對 Type、Host、Port、Password、Method 及協定所需欄位。由 Subscribe 產生的項目則先更新原 Subscribe，再重新選取伺服器測試。
Connectivity Test 的結果只能作為連通性線索。它不能取代規則驗證，也不能說明所有目標都採用相同路徑。測試通過後，應保留目前設定，進行一次容易辨識的實際存取，再查看請求記錄。
在 Data 或連線記錄中確認結果
開啟 Data 或應用程式內可查看連線記錄的區域，清除畫面後重新存取一次目標。找到新產生的請求，核對網域、目標位址、策略與規則資訊。在 Config 模式下，重點查看它是否命中預期的 DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR 或 FINAL，以及最終結果是 PROXY、DIRECT 還是 REJECT。
如果請求命中了錯誤規則，先檢查順序，不要先修改伺服器。規則會依由上到下的順序處理，先命中的項目會結束本次判斷。例如，範圍較大的 DOMAIN-SUFFIX 規則若位於具體 DOMAIN 規則之前，後者可能永遠不會被使用。調整後應儲存 Config，回到 Home 確認該 Config 仍處於選取狀態，再重新產生一次請求。
使用三種模式進行最小對照
- Direct 基準：短時間切換為 Direct，確認目前本地網路是否能完成基本存取。
- Proxy 基準：切換為 Proxy，確認目前選取的伺服器能否處理存取。
- Config 驗證：切回 Config，在 Data 中核對具體請求的規則與策略結果。
若 Direct 正常、Proxy 失敗，應優先檢查伺服器資料與 Connectivity Test；若 Proxy 正常、Config 失敗，應優先檢查目前設定檔、Rule 順序及策略引用；若三種模式都失敗，應先檢查本地網路、DNS 與目標狀態。每輪對照都使用同一台伺服器與同一個目標，避免引入新的變數。
依層級檢查常見問題
排錯時依照「輸入資料—伺服器連通—本機連線—Global Routing—Config 規則—DNS 與網路」的順序進行。一次只修改一層，並在修改後重複相同測試。若同時更換伺服器、修改規則與調整 DNS，即使恢復正常，也無法判斷真正原因。
Subscribe 更新失敗
先確認連結完整、沒有空格或換行，開頭協定與原始網址一致，結尾參數沒有遺漏。接著暫時關閉 Shadowrocket 連線，使用目前網路確認該網址可以正常請求，再回到原有 Subscribe 項目執行更新。不要透過建立多個同名項目來掩蓋問題；重複項目會增加後續選取錯誤的機率。
Connectivity Test 逾時
手動新增的伺服器應逐項核對 Type、Host、Port、Password、Method、TLS 及協定要求的附加欄位。由 Subscribe 產生的伺服器先更新訂閱，再重新選取目標項目。接著在 Wi-Fi 與行動網路之間進行一次單一變數對照；若只有某個網路失敗，繼續檢查該網路的 DNS、認證頁面或連線限制。
顯示 Connected 但無法存取
先切換 Direct 建立本地網路基準，再使用 Proxy 檢查伺服器基準。如果 Direct 可用而 Proxy 不可用，回頭檢查伺服器與 Connectivity Test；如果 Proxy 可用而 Config 不可用，檢查目前 Config、Rule 順序、策略名稱與 FINAL。若狀態顯示 Connected，但 Data 中沒有新請求，應確認系統 VPN 狀態是否對應 Shadowrocket，並查看 On Demand 是否改變了連線觸發條件。
只有部分目標結果不符合預期
這類問題通常位於規則層。先在 Data 中找到對應請求的實際網域或 IP，再檢查它實際命中的第一條規則。不要只根據瀏覽器網址列猜測，因為一個頁面可能同時請求多個網域。針對具體網域可使用 DOMAIN 或 DOMAIN-SUFFIX；針對關鍵字範圍應謹慎使用 DOMAIN-KEYWORD；位址範圍可使用 IP-CIDR 或 IP-CIDR6。新增規則後儲存 Config，並重新產生請求驗證。
DNS 解析異常
若 Connectivity Test 可以完成，但網域存取失敗而直接使用位址時表現不同，應檢查 DNS。先恢復到可追溯來源的 DNS 設定，避免同時疊加多種解析方式。接著分別在 Direct、Proxy 與 Config 下重複相同網域測試，並觀察 Data 中是否出現解析後的連線。複雜的 Hosts、URL Rewrite 或 HTTPS Decryption 設定也可能改變結果，排查時可先確認它們是否與目前問題有關。
On Demand 導致狀態反覆變化
On Demand 會依據網路條件觸發連線或中斷。初次設定與故障定位期間，建議先關閉 On Demand，手動完成一次穩定連線；基本流程驗證通過後，再回到 Settings 設定觸發條件。若剛切換 Wi-Fi、離開某個網路或喚醒裝置後狀態發生變化，也應同時查看 On Demand 條件，而不是只重複點按 Home 開關。
修改後仍無法判斷原因
使用 Settings 中的 Diagnostics 與相關測試項目收集現象，記錄目前網路、伺服器名稱、Global Routing、Config、Connectivity Test 結果與具體失敗時間。分享診斷資訊前，應檢查其中是否包含個人連線資料。更完整的無法上網、伺服器逾時、訂閱失敗、速度慢、DNS、耗電及 iPad 專項流程，可前往Shadowrocket 故障排查大全逐章處理。
儲存可重現的正常設定
完成驗證後，將 Global Routing 恢復為日常需要的模式。使用 Config 時，確認選取的設定檔名稱清楚，Rule 順序能夠解釋實際請求；使用 Subscribe 時，保留一個主要更新入口，清理測試期間產生的重複項目。伺服器名稱可依用途整理，但不要修改由協定決定的關鍵欄位。
建議記錄一組最小正常狀態：目前伺服器、Global Routing 模式、Config 名稱、一次成功的 Connectivity Test 結果，以及 Data 中一條符合預期的規則命中。日後發生異常時，先與這組狀態對照，比從頭修改所有設定更容易定位。
更換裝置或從 App Store 重新恢復 Shadowrocket 後，應用程式購買記錄與伺服器資料是兩類不同內容。已購項目可依 App Store 流程恢復，訂閱與 Config 則應依使用者自己的備份方式重新匯入。系統需求、相容範圍與購買顯示均以 App Store 頁面標示為準。
下一步：依症狀繼續排查
若基本設定已完成，但仍遇到無法上網、逾時、規則錯誤、DNS 或耗電問題，可進入長篇文件依症狀逐項檢查。