官方手冊 · 功能與設定

Shadowrocket
代理模式與常用設定

先確認 Global Routing，再檢查伺服器與設定檔。連線開關、路由模式和規則策略各自控制不同環節，不能互相取代。

  • Home
  • Config
  • Data
  • Settings
確認模式檢查規則驗證連線

Global Routing 三種模式

設定檔／代理／直連，對應介面中的 Config／Proxy／Direct。

Global Routing 決定由用戶端處理的連線要透過哪種方式選擇出口。在 Home 開啟 Global Routing，依目前需求選擇 Config、Proxy 或 Direct，再返回 Home 檢查連線狀態。它不是連線開關，也不是伺服器清單：選取 Proxy 不代表隧道已啟用，切換伺服器也不表示模式會隨之改變。

日常需要依不同目標分流時，通常選擇 Config；想暫時排除規則策略的影響，可用 Proxy 作為對照；想觀察直接連線的情況，則可選 Direct。這類對照是排查問題的方法，不是替模式評定優劣。測試結束後，應恢復原先預定使用的模式，避免臨時設定一直保留。

介面選項處理方式適用情境核對重點
Config依照目前啟用設定檔中的規則選擇策略。需要依網域、IP 或地區等條件分流。確認啟用的設定檔及規則順序。
Proxy透過代理路徑處理由用戶端接管的連線。暫時驗證所選伺服器，縮小規則排查範圍。確認伺服器可用且參數完整。
Direct使用直接連線路徑。觀察不經代理伺服器時的連線情況。不等於關閉系統中的 VPN 連線。

Config 模式：先確認啟用的設定檔

Config 既是設定檔管理頁的介面用語，也是 Global Routing 的選項，兩者用途不同。在 Config 頁面儲存檔案，不代表該檔案已成為目前使用的設定檔；還需要確認啟用狀態。規則中的 PROXY 指向代理策略，DIRECT 表示直接連線，REJECT 表示拒絕連線。若設定檔另有定義策略組，也應檢查該組目前選取的目標。

切換模式後重新建立測試連線

既有連線可能仍沿用原本的處理狀態，不能只因同一頁面看起來沒有變化，就認定切換失敗。先記下原模式，切換後重新發出請求，再查看連線記錄與規則命中情況。若同時修改伺服器、DNS 和模式，結果會難以判讀；每次只變更一個條件，較容易核對。

規則類型與策略

規則回答「符合什麼條件」，策略回答「如何處理」。

規則分流會將不同目標導向不同連線路徑。入口是 Config 頁面的目前設定檔；編輯規則後儲存，並確認 Global Routing 使用 Config 模式。規則通常由上而下比對，命中第一條後便採用相應策略，因此較精確的條件通常應放在範圍較廣的條件之前，並將 FINAL 放在末尾作為兜底。不能只因規則已寫入檔案，就認定它一定會被執行。

DOMAIN 比對完整網域名稱，DOMAIN-SUFFIX 比對網域及其子網域，DOMAIN-KEYWORD 依網域中的關鍵字比對。IP-CIDR 與 IP-CIDR6 分別表示 IPv4、IPv6 位址範圍，GEOIP 則依 IP 地理位置資料比對。USER-AGENT 會依據請求中可辨識的 User-Agent 資訊進行比對，並非每種連線都具備這項條件。選擇類型時，應依據實際可觀察到的資訊，而非猜測應用程式名稱。

[Rule] · 語法範例
[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

以上網域僅用於說明語法，並非建議直接啟用的完整設定。第一條只處理 example.com，第二條涵蓋 example.org 及其子網域，IP-CIDR 範例涵蓋相應的私有位址範圍，FINAL 則接手處理前面未命中的連線。若將 FINAL 移到前面，後續規則便沒有比對機會。

PROXY / DIRECT
分別使用代理策略與直接連線。PROXY 的最終出口仍須配合目前選取的伺服器或策略組確認。
REJECT
拒絕符合條件的連線。範圍過廣可能影響正常請求，應先確認目標，也不應宣稱它能處理所有頁面內容。

規則未如預期生效時，先查看目前模式，再確認啟用的設定檔，最後檢查前面的規則是否已命中。網域規則與 IP 規則使用的比對資訊不同，DNS 解析結果也可能影響後者。若要了解各類型的適用範圍、設定檔區段結構及更多寫法，請繼續閱讀規則手冊，不要只靠重複新增同類規則來代替問題定位。

訂閱與伺服器管理

先區分伺服器資訊與設定檔，再選擇匯入方式。

伺服器項目會儲存連線所需的位址、連接埠、協定與驗證資訊；訂閱用於集中匯入或更新這些項目；設定檔則儲存規則及其他連線設定。三者彼此相關，但並非同一項目。已有訂閱時，使用 App 中的 Subscribe 入口；若只有單一伺服器參數，可從 Home 的 Add Server 手動新增項目。匯入後務必返回清單核對內容，不能只因「看見名稱」就認定已成功連線。

Add Server：依現有參數填寫

開啟 Add Server 後，先選擇與伺服器相符的協定，再填寫位址、連接埠及驗證欄位。Shadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2 等協定的欄位各不相同，不能將一組參數直接套用於其他協定。若原始資訊包含 TLS、伺服器名稱或傳輸方式，也應逐項核對；顯示名稱只是方便辨識的標籤，不能取代實際連線位址。

透過 Scan QR Code 或剪貼簿匯入現有分享資訊後，也應開啟項目查看重要欄位。掃描 QR Code 只是輸入方式，不會驗證遠端是否在線。QR Code 圖片、分享連結，以及包含驗證資訊的頁面都應妥善保管；排查問題時，只提供必要的欄位名稱與現象，不要公開完整內容。

Subscribe：匯入後保留更新關係

使用自己已有的訂閱網址時，請確認網址完整、存取權限正常，且回傳內容符合 App 支援的格式。訂閱更新通常會重新讀取遠端清單，因此不宜完全仰賴訂閱產生的項目來保留長期需要的本機修改。更新前記下目前的選取項目，更新後確認項目是否有變化，再確認所選伺服器仍在清單中。

若更新後清單變空，先檢查訂閱是否仍有效、當時的網路能否讀取網址，以及是否誤將一般網頁網址當成訂閱。不要反覆刪除所有設定來嘗試復原。Config 頁面管理的規則檔也應另外確認啟用狀態；訂閱更新成功不代表規則設定檔已切換。完整匯入步驟請參閱入門教學。

On Demand 按需連線

自動觸發連線，不會取代路由規則。

On Demand 會依據設定條件，要求系統建立 VPN 連線，適合希望減少手動操作的使用方式。它處理的是「何時連線」，Global Routing 處理的是「連線後如何選路」。請在 Settings 中檢查 On Demand 相關設定，先閱讀目前條件，再啟用所需功能；網路條件或 Wi-Fi 相關規則的具體選項，以 App 目前顯示為準。

初次設定時，先確認手動連線運作正常，再啟用 On Demand。測試可分兩個階段：先在預期會觸發的網路環境中觀察是否連線，再切換至不應觸發的環境確認結果。如此可區分觸發條件設定錯誤與伺服器本身無法使用，避免混淆兩類問題。

需要暫停連線時，也應檢查 On Demand 是否仍會觸發重新連線。只關閉 Home 的開關後又看到連線恢復，不一定代表開關失效，也可能是系統再次符合按需條件。若同一裝置保留多份 VPN 設定，也應確認系統目前使用的設定，避免將其他設定的狀態誤認為 Shadowrocket 的結果。

Data 流量統計

用來查看用戶端記錄的流量，不可取代帳單。

Data 用於查看用戶端記錄的流量。進入 Data 後，先確認頁面顯示的統計範圍、時間區間與單位，再解讀上傳、下載等數值。這裡的上傳與下載代表流量方向，不是伺服器品質評分；某段時間數據偏少，可能只是沒有發出新的請求，不能直接判定連線異常。

若要比較某項操作帶來的變化，可先記下目前數值，執行一項明確操作，再返回 Data 查看增量。若頁面提供重設功能，應先確認會清除哪些記錄，必要時自行保存需要的統計結果。排查問題時，不要一邊頻繁重設，一邊又試圖回頭查看同一時段的變化。

用戶端統計、系統行動網路用量，以及使用者既有服務的計量方式可能不同，涉及的連線範圍、協定額外負載與統計週期也未必相同。因此 Data 較適合用來觀察使用趨勢；若涉及行動網路計費或遠端用量，應分別查看對應來源。僅憑流量增加，不能證明某條規則已如預期命中，仍須配合連線記錄檢查出口。

Settings 常用設定

依照具體需求調整，並記下每次修改的原因與原始值。

DNS：檢查解析路徑

DNS 會將網域名稱轉換為連線所需的位址。相關行為須配合 Settings 中的 DNS 設定及目前設定檔一併核對，不能只看單一輸入欄位。修改前記錄目前的解析設定，確認是否由正在使用的設定檔指定，再依現有網路環境調整。若可連線至某個 IP 位址，但無法透過網域存取，DNS 是需要檢查的環節之一；但這仍不足以證明所有故障都源自 DNS。

不要任意加入多個來源不明的解析位址。修改後重新建立測試連線，並以相同目標核對結果；同時確認 IPv4、IPv6 相關行為是否符合預期。調整 DNS 可能影響網域解析結果及後續 IP 規則比對，因此排查規則時應記下解析設定，避免測試條件不斷改變。

Test Method：統一測試方式

Test Method 決定連線測試採用的方式。在 Settings 查看此項設定後，再從 Home 執行 Connectivity Test。比較多個伺服器時，應使用相同方法，否則兩次結果可能反映不同類型的測試過程。測試耗時只能表示當下使用該方法時的回應情況，不能直接等同於網頁開啟速度或持續傳輸能力。

某個項目測試失敗時，先確認測試方法使用的目標在目前環境中是否可存取，再檢查伺服器位址、連接埠與驗證資訊。若只有特定 App 存取異常，應對照實際目標的連線記錄，不要只憑清單中的單次測試結果反覆更換設定。

Today Widget：確認快速操作的對象

Today Widget 是系統提供的快速資訊顯示與操作入口。可在 Settings 查看相關設定，並透過系統允許的元件入口新增或檢查顯示內容。實際呈現方式取決於系統與 App 目前支援的功能，不應假設不同裝置上的位置完全相同。

使用快速操作後，返回 Home 確認實際連線狀態、所選伺服器及 Global Routing。元件只是操作入口，並非另一份獨立設定；若狀態尚未更新，應綜合參考 App 內狀態與系統 VPN 狀態，不要連續快速切換，以免誤判。

iCloud 同步：先確認範圍再同步

iCloud 相關選項會在 App 支援的範圍內同步內容。先確認裝置已登入自己的 Apple 帳號，且系統已允許使用相應的 iCloud 功能，再查看 Settings 實際提供的同步範圍。不要預設所有連線記錄、統計資料或敏感欄位都會同步，也不要將 App 購買記錄與設定同步視為同一件事。

在另一部裝置修改前，先核對兩端內容與同步狀態，必要時保留可還原的設定檔副本。若內容不一致，優先確認網路、帳號及同步權限，再判斷要保留哪一份內容。從 App Store 還原已購買的 App，不代表設定檔與伺服器資訊必然也已還原。

Diagnostics 與連線排查

依據現象定位問題環節，再選擇所需的診斷資訊。

Diagnostics 可協助檢查連線問題。在 Settings 中尋找 Diagnostics 相關入口，並依目前頁面提供的工具執行檢查。解讀診斷結果時，須一併考量發生時間、網路環境、Global Routing 模式及具體目標；單一錯誤訊息通常不足以說明全部原因，也不能據此任意修改進階設定。

  1. 記錄現象。區分無法建立連線、連線後所有目標都失敗、只有特定網域失敗，以及訂閱更新失敗。這些問題發生在不同環節。
  2. 核對基本資訊。檢查目前伺服器、驗證參數、啟用的設定檔與路由模式，確認裝置網路本身正常，再執行 Connectivity Test。
  3. 縮小變因。保持伺服器不變，比較 Config 與 Proxy 的結果；若差異明顯，再檢查規則、策略組與 DNS，測試後恢復原模式。
  4. 重新測試並記錄。一次只修改一項設定，重新建立連線並記錄變化。若未改善，請恢復原值，避免累積多項臨時修改。

診斷內容可能包含存取網域、伺服器位址或驗證相關資訊。儲存或分享前，應先檢查並遮蔽敏感內容，只保留有助於說明問題的錯誤類型、時間與操作步驟。完整訂閱網址不適合作為公開排查資料；需要說明格式時，請以 example.com 等範例網域取代實際位址。

設定核對與常見問題

離開設定頁前，確認目前狀態符合預期。

完整核對應涵蓋四項：Home 的連線狀態、Global Routing 目前選項、實際選取的伺服器，以及 Config 中啟用的設定檔。使用 On Demand 時，還要檢查觸發條件。記下這些資訊，之後遇到異常才有穩定的比對基準，不必每次都從頭修改所有選項。

已選擇 Config，為什麼仍然透過代理連線？

Config 表示依規則處理，不代表所有連線都會直接存取。請檢查命中的規則是否使用 PROXY，或是否最後套用 FINAL,PROXY；同時確認啟用的是預期的設定檔，而不只是檔案已儲存在清單中。

切換為 Direct 後，需要關閉連線開關嗎？

Direct 與關閉連線是兩種不同操作。前者會改變處理路徑，後者會停止目前連線。若要完全暫停用戶端連線，還須檢查 On Demand 是否會再次觸發，並確認系統實際的 VPN 狀態。

Connectivity Test 通過，是否代表所有 App 都能正常存取？

不能據此推論。測試只涵蓋所選 Test Method 對應的流程，實際存取還涉及目標網站、DNS、規則與遠端回應。請重新發出實際請求，並檢查該連線的處理路徑。

伺服器訂閱更新後，規則也會跟著變更嗎？

應依匯入內容分別核對。伺服器清單與規則設定檔用途不同，更新伺服器訂閱不代表規則檔也已更新或啟用。先檢查更新後的清單，再到 Config 確認目前檔案與規則。

初次使用時應先調整哪些設定？

先匯入已有的伺服器或訂閱，核對連線參數，再確認 Global Routing 並手動連線。完成基本連線驗證後，再設定規則與 On Demand。詳細操作順序請參閱入門教學，進階規則語法請參閱規則手冊。