Shadowrocket
協定類型與參數參考

先確認伺服器提供的協定，再選擇 Type

協定類型必須與伺服器端相符，不能把同一組位址和密碼任意改成另一種協定。在 Home 的伺服器編輯入口或 Add Server 中，Type 決定用戶端如何組織驗證與資料；伺服器必須能解析相同格式，才有機會建立連線。使用者現有的訂閱通常已包含這些設定，匯入後應先保留原值。只有掌握伺服器端的實際設定時，才適合手動重建項目；只憑名稱標示某種協定，無法確認所有參數。

理解一條連線時，應拆成不同層次。位址和 Port 決定連往何處，協定驗證決定對方是否接受請求，傳輸方式決定資料如何承載，TLS 負責相關通道的身分驗證與加密，Global Routing 則決定哪些請求會進入這條路徑。同樣是 VLESS，也可能搭配不同傳輸方式；同樣使用 TLS 的兩條連線，也可能採用不同的驗證機制。排查時若混淆這些層次，就可能改了密碼，實際問題卻是憑證不符。

七種協定不是速度排行榜

協定的歷史背景反映設計目標，不代表在任何網路環境中的固定表現。Shadowsocks 著重精簡的代理轉送，VMess 具備自己的驗證與資料保護設計，VLESS 則將較多保護責任交由外層機制處理，Trojan 透過 TLS 通道承載代理請求。HTTP 與 SOCKS5 是通用代理介面，WireGuard 處理 IP 層隧道，Hysteria2 則採用以 QUIC 為基礎的傳輸。它們解決的問題並不完全相同，不能只按名稱的新舊排序。

速度通常先受伺服器出口、往返時間、網路壅塞與無線訊號影響，其次才是協定處理的額外負擔。開啟網頁可能包含 DNS 查詢、交握與多個短請求；持續下載則較受傳輸量影響，兩者的結果可能相反。使用 iPhone 時還要考量行動網路訊號、低電量狀態及前後台切換，不能把單次測速的最高值當成日常體驗。比較時應固定裝置、網路、伺服器條件與測試目標，只改變一項可控制的變數。

依工作負載評估耗電與相容性

耗電量取決於實際傳輸量、連線維持方式與無線模組的工作時間，不是某種協定永遠具備的特性。頻繁建立 TLS 連線可能增加短時間的額外負擔；持續傳送保活封包可能讓網路更常喚醒；封包遺失後重傳也會增加耗電。長時間觀看影片、少量傳送訊息與待機等情境應分開觀察。裝置溫度升高時，先檢查 Data 中的流量變化與背景工作，不要直接認定是協定實作有問題。

TCP 與 UDP 的支援情況也應分開確認。網頁能開啟，只能證明相關路徑上的請求成功，不能證明語音或其他 UDP 流量也能通過。部分協定支援 UDP，但伺服器、目前的傳輸方式或上游網路未必允許；反過來說，以 UDP 承載的協定也可能轉送應用程式的 TCP 請求。這裡的「應用程式流量類型」和「外層連線類型」是兩個概念，不能只看到 UDP 就推斷所有應用程式的行為。

第一輪選擇只需回答三個問題：伺服器實際提供什麼、目前網路允許什麼、需要承載哪種服務。接著再確認驗證資料是否完整、憑證能否正確驗證，以及連線失敗時是否容易找出原因。如果目前只有一種可用類型，應先正確設定，而不是尋找伺服器端沒有對應的設定。想先了解分享格式，可閱讀分享連結與訂閱連結的差異，再返回相關協定章節。

UUID 看起來相似，不代表連線方式相同

VMess 的設計包含使用者驗證與自身的資料保護機制；VLESS 採用較精簡的身分識別架構，將較多通道保護交由 TLS 等外層方案處理。兩者都可能使用 UUID，但伺服器的處理方式不同，不能只把 Type 從 VMess 改成 VLESS，並保留其他欄位，就當作完成轉換。現有分享資料標示哪一種，就應使用哪一種；只有伺服器同時設定了對應入口，用戶端才能分別建立項目進行比較。

UUID 是身分識別碼，不是伺服器位址，也不是訂閱連結中的任意查詢參數。複製時應檢查是否混入空格、換行或引號，並保留完整內容。VMess 也可能涉及安全選項或舊版相容欄位，這些值應依伺服器資料設定，不要根據舊教學推斷所有伺服器都必須填入同一個數字。VLESS 的驗證較精簡，也不代表可以忽略外層保護；需要 TLS 的入口若關閉 TLS，通常無法如預期建立連線。

傳輸選項應視為一組設定

TCP、WebSocket 等傳輸方式描述代理資料如何承載，並不能取代 VMess 或 VLESS 本身的身分驗證。同一個位址可能有不同入口，其中一個要求 WebSocket，另一個只接受直接的 TCP 連線。選錯傳輸方式時，網路層可能仍顯示連接埠可連線，但後續資料無法正確處理。新增伺服器時，應一併核對傳輸類型與相應的 Host、Path 等參數，避免只修改最上方的單一選項。

WebSocket 的 Path 是伺服器接收請求的路徑，通常必須完全相符，包括開頭的斜線與大小寫；它不是任意的網站目錄。Host 是相關請求中的主機資訊，SNI 則參與 TLS 交握，兩者有時相同，但用途不同。Address 可以指向實際連線入口，Host 與 SNI 則可能是設定要求的名稱；看到三者不同時，不要擅自改成相同值。應依現有資料分別確認，不要用其中一個值覆蓋其他欄位。

TLS 憑證驗證用來確認連線對象的身分，不能以「連得上」為由關閉驗證。憑證網域與預期名稱不符、憑證鏈不完整或裝置時間明顯錯誤，都可能造成交握失敗。應先檢查 SNI、憑證與時間，而不是略過驗證。若入口需要其他交握機制或特定參數組合，也應完整保留匯入結果；介面出現某個選項，不代表所有伺服器都支援該選項。

比較效能時，也要把傳輸額外負擔納入考量

額外封裝與交握會增加第一個請求的處理量，但是否感受得到，取決於連線重複使用、往返時間與服務模式。連續請求重複使用既有連線時，初次建立連線的成本可能被分攤；反覆建立短連線時，交握時間則更明顯。在穩定網路下比較下載速度，也不能直接推論訊號較弱時的表現。iPhone 的日常使用包含背景恢復與網路切換，應至少涵蓋這些過程，再判斷哪種組合較適合目前環境。

遇到「伺服器測試有結果，網頁卻打不開」時，應區分連接埠可達與完整請求成功。先確認 Global Routing 會將目標導向該項目，再檢查 UUID 和 Type，接著核對 TLS 與傳輸欄位。若瀏覽器出現憑證相關錯誤，也要判斷錯誤來自代理入口還是最終網站，兩者使用的不是同一張憑證。記錄具體錯誤和發生階段，比只記下「無法連線」更容易找出需要修改的欄位。

如果手邊有多種協定入口可選，應優先選擇參數完整且能正確驗證憑證的一組，再比較實際使用體驗；不要因為 VLESS 架構較精簡就斷定一定比較省電，也不要因為 VMess 有自己的保護機制就忽略外層設定。想快速辨識協定名稱，可先閱讀支援的協定快速總覽；本章則用來處理欄位之間的依存關係與失敗狀況。

傳送 IP 封包，而非只指定代理目標

WireGuard 著重精簡的 IP 層加密隧道，使用公開金鑰識別對端，並透過 UDP 傳送資料。它不同於提交目標位址的應用程式代理協定；用戶端與伺服器端還必須知道如何分配隧道內部位址，以及如何將目標流量交給正確的對端。在 Shadowrocket 中使用時，外層仍受到應用程式整體接管與路由機制影響，不能把隧道參數的意義完全等同於 Global Routing 模式。

金鑰關係是排查的起點。用戶端 Private Key 必須保密，對應的公開金鑰需在伺服器端登記；用戶端填入的 Peer Public Key 應是伺服器對端的公開金鑰。兩者位置顛倒、複製不完整或仍使用舊公開金鑰，都可能導致交握無法完成。若資料還包含預共享金鑰，兩端也必須一致。不要把伺服器公開金鑰填入用戶端私密金鑰欄位，更不要為了修復連線，把實際使用的私密金鑰放進回報截圖或公開紀錄。

Endpoint、Address 與 Allowed IPs 不可混為一談

Endpoint 是外部網路中連往伺服器的位置，通常由網域名稱或 IP 與 UDP 連接埠組成。Address 是隧道內部使用的位址，不是裝置目前 Wi-Fi 的區域網路位址，也不是伺服器的公開位址。現有設定提供什麼位址與前綴，就應依要求保留；任意換成「看起來沒人用」的私人位址，可能與伺服器路由或位址配置衝突。交握成功只代表金鑰與入口大致可用，不代表內部位址正確。

Allowed IPs 表示對端關聯的目標位址範圍，也會參與相關路由判斷；它不是應用程式層級的網域規則。若範圍設定不完整，交握可能正常，但服務流量不會進入預期的對端；範圍過大，也不能據此推斷 Shadowrocket 的所有請求都會略過 Config 的選擇。應分別核對伺服器項目的隧道設定與應用程式層級策略，並實際測試目標。使用 IPv6 時，還要確認隧道位址、目標範圍與伺服器轉送能力都支援 IPv6。

DNS 是另一項獨立設定。隧道內可以存取某個 IP，卻無法開啟網域時，問題可能出在 DNS 伺服器無法連線，而非 WireGuard 加密。現有設定中的 DNS 位址可能只能透過隧道存取，此時路徑與規則必須允許相關請求。排查時可先區分 IP 位址存取與網域存取，再檢查 DNS 結果；不要用修改金鑰的方式處理解析失敗，也不要因為交握成功就排除路由問題。

依路徑調整 MTU 與保活設定

封裝會占用額外空間，MTU 用於限制相關封包的大小。設定過大時，某些路徑可能發生大型請求卡住、部分網頁載入不完整或持續傳輸異常，但小型請求仍可成功；設定過小則可能降低有效傳輸效率。只有在有證據顯示問題與封包大小有關時，才適合謹慎調整。每次修改前都應保留原值，並比較相同工作；不要從其他網路照搬某個數值，當成所有裝置的固定答案。

Persistent Keepalive 用於在有需要時維持網路映射，但不是提高傳輸量的加速開關。行動網路或某些路由環境可能需要定期活動以維持回傳路徑；保活頻率過高則會增加無線模組喚醒次數。應依現有網路是否發生閒置後無法恢復的情況來判斷，不要預設將間隔設得很短。iPhone 螢幕關閉及切換網路後的表現，也應與前台持續下載分開觀察。

WireGuard 適用於已具備完整隧道資料，且需要明確 IP 層存取範圍的情境。架構精簡並不代表不需要伺服器轉送、防火牆與位址規劃。若只有 Endpoint 和一組公開金鑰，通常不足以重建完整設定；應向現有設定來源確認缺少的資料。回報問題時可記錄錯誤階段、網路類型與目標範圍，但金鑰及內部存取資料應留在受控環境中。

匯入成功只代表內容已被識別

Shadowrocket 接受訂閱或分享連結，不代表伺服器目前可用，也不代表所有欄位都符合現有入口。匯入後應先檢查 Type、Address、Port、身分欄位與傳輸設定，再選擇伺服器進行驗證。使用現有訂閱時，應從自己的設定來源取得更新資訊，並留意更新可能覆蓋手動修改。若要長期保留本機調整，應先確認哪些內容由訂閱管理，避免下次更新時誤以為是應用程式自行更改設定。

分享連結與 Subscribe 訂閱用途不同。前者通常描述單一項目，後者可能回傳多個項目並持續更新；兩者也可能使用不同編碼或格式。QR Code 只是另一種承載內容的方式，並不會讓錯誤參數變正確。使用 Scan QR Code 匯入後，仍須核對匯入結果，尤其是含特殊字元的驗證資訊、路徑與額外參數。訂閱網址本身也可能包含存取憑證，應避免出現在公開截圖、紀錄或可分享的問題描述中。

先用模式確認路徑，再用規則決定細部走向

Global Routing 中的 Config、Proxy、Direct 分別代表依設定、代理與直連。Config 依目前啟用的設定規則處理請求；Proxy 主要讓請求走代理路徑；Direct 則用於直連。這三種模式決定請求的去向，不會改變伺服器協定內部的驗證方式。排查特定伺服器時，可先使用明確的代理模式驗證，再回到 Config 檢查分流；測試結束後，應恢復適合日常用途的模式。

規則通常依順序比對，前面的明確條件可能先於後面的廣泛條件生效。DOMAIN-SUFFIX 用於比對網域後綴，IP-CIDR 用於比對 IPv4 位址範圍，FINAL 表示前面的規則都未命中時採用的最終策略。規則可以決定走 PROXY 或 DIRECT，卻無法修復錯誤的 Password、UUID 或憑證。若某網域直連正常、使用 Config 時失敗，應先確認命中的策略，再判斷問題出在代理入口還是目標服務。

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

以上只是用於說明比對順序的 .conf 片段，不是完整的日常設定。example.com 是教學用網域，私人網路範圍僅用來展示位址規則；GEOIP 的結果則取決於使用的資料與實際目標位址。應將片段放在正確的 [Rule] 區段中理解，不要貼到 Add Server 的驗證欄位。更完整的區段關係請參閱設定檔 General、Rule、Host 與 URL Rewrite 說明。

DNS 與 On Demand 不屬於協定驗證

DNS 決定網域名稱如何解析，規則決定請求如何傳送；兩者可能互相影響，但都不等同伺服器的 Type。某個網域回傳多個位址時，各位址的可達性可能不同；只修改代理協定名稱無法解決解析錯誤。IPv6 也應分開考量：裝置取得 IPv6 位址，不代表現有伺服器能轉送所有 IPv6 目標。應觀察實際位址類型與請求路徑，再判斷要調整的是 DNS、路由還是伺服器能力。

On Demand 控制符合條件時如何觸發連線，不會把 VMess 轉換成 VLESS，也不能取代 Config 中的規則。若啟用後在網路變動時自動連線，應先檢查觸發條件；若已建立連線但只有部分目標失敗，則應回頭檢查規則、DNS 與協定欄位。分開記錄「何時連線」和「連線後如何分流」，可避免為了修復某個網站而反覆更改自動連線設定。

手動修改前應保留可還原的設定，並確認其中沒有需要公開的敏感資料。應用程式的 Data 可協助確認是否有流量；若有連線紀錄，也能輔助判斷策略與錯誤階段，但流量增加不代表請求最終成功。建議依序檢查欄位是否完整、協定是否相符、外層是否可連線、驗證是否通過、規則是否命中，以及目標是否有回應。每一步有明確結果後再進入下一步，不要同時修改多個層次的設定。