Shadowrocket 協定手冊

單靠協定名稱無法完整描述連線

代理連線通常包含目標位址、代理協定、承載傳輸、驗證資訊與安全設定。目標位址指出用戶端要連線至哪台伺服器；代理協定定義如何表示存取目標及確認使用者身分；傳輸負責傳送訊息；安全設定則決定是否使用 TLS、驗證哪些憑證。必須綜合檢視這些層次，才能理解「同樣選擇 VLESS，卻只有其中一條連線可用」的情況：名稱相同，不代表連接埠、傳輸與驗證方式也相同。

TCP 提供有序且可靠的位元組串流；UDP 傳送資料封包，但不直接保證送達。WebSocket 是在既有連線上封裝訊息的方式，並非與 Shadowsocks 同層的代理驗證協定；TLS 負責建立受保護的通道，也不能取代代理帳號。訂閱中若同時出現協定名稱、WebSocket、TLS，應將它們視為一組組合參數，而不是三個互相競爭的選項。實際可選欄位以目前介面和連線資料為準。

分別核對位址、名稱與連接埠

伺服器位址可能是網域名稱，也可能是 IP。連接埠是伺服器實際監聽的入口，不能因為某個協定常用特定連接埠，就直接套用常見數值。使用 TLS 時，連線位址與用於憑證驗證的名稱可能不同：前者用來找到伺服器，後者用來確認連線對象的身分。若資料另列 SNI 或 Server Name，請照原值核對；只將伺服器位址改成 IP，不一定能維持原有的憑證驗證方式。

驗證資訊也有不同形式：密碼、UUID、金鑰組不能互換。UUID 即使看起來像一串隨機字元，也不等於任意密碼；公鑰可提供給需要驗證身分的一方，私鑰則是本機機密。複製時請留意前後空白、換行、大小寫，以及掃描取得的內容是否完整。先確認欄位屬於哪一層，再判斷要聯絡伺服器管理者、檢查系統時間，還是確認憑證名稱，可避免反覆嘗試無關的開關設定。

Global Routing 不會改變伺服器協定

Global Routing 的 Config、Proxy、Direct 分別對應設定檔、代理與直連。Config 依目前設定檔的規則選擇策略；Proxy 會以代理方式處理由用戶端接管的請求；Direct 則用於直連。這裡說明的是路由決策，不會將伺服器轉換成另一種協定。切換到 Proxy 有助於排除「測試請求未使用預期策略」的干擾，但無法修正錯誤密碼、無效憑證，或伺服器未啟用 UDP 轉送等問題。

規則中的 PROXY、DIRECT、REJECT 是策略關鍵字，大小寫寫法與介面中的姿態不同。規則由上往下比對，符合後即停止；FINAL 應放在最後作為後備規則。此處的 example.com 僅為文件範例，不能用來驗證自己的伺服器。實際驗證時，請選擇已知目標，查看連線記錄採用的策略；設定檔中的策略名稱也必須與檔案實際定義相符，不能將範例當成可直接執行的完整設定。

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

此外，網域解析發生在哪一側也會影響診斷。用戶端解析失敗、伺服器解析失敗與代理驗證失敗，都可能呈現類似的載入逾時，但原因位於不同環節。保留原始設定，先確認入口可連線，再確認驗證，最後檢查目標解析與規則。每次只修改一個項目，才能找出現象與原因的關聯。規則順序的完整說明請參閱自訂規則與 FINAL 後備策略文章。

設計目標與演進方向

Shadowsocks 著重將代理請求封裝在加密連線中，以相對精簡的互動傳遞目標位址並轉送資料。它不是完整的網路層通道，通常透過 TCP 連線與 UDP 封包提供代理功能。了解這個範圍很重要：哪些 App 由用戶端接管、網域如何解析、區域網路位址是否直連，仍取決於系統接入方式與 Shadowrocket 設定，不能只憑協定名稱判斷所有流量的路徑。

協定的加密方案持續演進。現代資料中常見的 AEAD 方法會結合機密性與完整性驗證，讓接收端能辨識遭到修改的資料；不同世代的方案也可能採用不同的金鑰格式與封包結構。選擇時應完全依照伺服器提供的 Method，而不是只看名稱相似。用戶端清單中有某種方法，不代表伺服器已啟用；將方法改成另一項，通常會直接造成驗證或解密失敗。

Method、Password 與附加參數

最基本的核對項目是 Address、Port、Method、Password。Method 必須完全一致，Password 則須保留原始字元。部分較新的加密方案要求特定長度的編碼金鑰，不能用隨意輸入的短語取代；除非連線資料明確要求，也不要自行解碼編碼後的金鑰再貼上。若匯入連結包含附加選項，請先完整匯入，再逐項比對手動新增時可見的欄位，以免漏掉伺服器依賴的設定。

部分連線資料還會描述額外的封裝或擴充功能。這些選項並非 Shadowsocks 名稱本身自動包含的能力，也不保證各平台、各用戶端介面的呈現方式都相同。請確認伺服器實際採用的組合，以及 Shadowrocket 目前介面是否支援對應選項。如果資料只寫「Shadowsocks」，卻缺少方法與驗證資訊，就不足以建立連線；應向現有伺服器的管理者確認，而不是猜測常見設定值。

如何理解速度與 iOS 耗電

Shadowsocks 的互動結構相對精簡，但不代表在任何情境下都最快。現代裝置對部分加密演算法提供硬體加速，其他演算法在不同晶片上的效率也各異；封包長度、連線數量與無線訊號同樣會影響實際負載。開啟短篇網頁主要受解析與建立連線的時間影響，持續下載則更取決於連線容量與伺服器負載。若裝置、目標和網路條件不相同，就不能將兩次測速的差異全歸因於加密方法。

UDP 需要另外測試。伺服器可能只開放 TCP、防火牆可能未允許 UDP，或中間網路對 UDP 的處理方式不同。因此網頁可以載入、即時 App 卻異常，並不矛盾。也不要因 UDP 測試失敗就立刻更換密碼：若 TCP 已穩定通過驗證，先確認 UDP 轉送能力、對應連接埠與伺服器策略，通常比反覆修改已驗證的欄位更有效。協定支援封包傳輸，不代表 App 一定會依預期使用該入口。

在 iOS 上，常見耗電因素包括網路延伸處理的資料量、重新建立連線、無線網路品質與背景喚醒。頻繁的短連線可能比少量穩定的長連線更容易增加握手負擔；訊號微弱時的重傳也可能掩蓋加密方式之間的差異。可將 Shadowsocks 視為現有伺服器提供的輕量代理選項來評估，不宜預設固定的省電排名。先保留可用設定並完成穩定性驗證，再比較效能，能減少排錯與測速互相干擾。

VMess 為何包含較多協定內處理

VMess 的設計將使用者驗證、請求資訊與資料保護納入自身的協定架構。用戶端須依照約定組成請求，伺服器才能辨識使用者並轉送目標流量。VMess 可搭配不同承載方式，因此連線資料除了伺服器位址和 UUID，也可能包含安全方式、傳輸類型與 TLS。歷史設定中出現的相容欄位，不代表可以任意增刪；應以伺服器目前實際採用的設定及可用匯入資料為準。

VMess 的驗證過程要求時間同步。若入口可連線，換裝置後卻持續驗證失敗，請檢查系統日期、時間與時區設定，並優先啟用自動設定時間。不要將「能連上連接埠」視為驗證成功：建立網路連線只是第一步，後續協定標頭與驗證仍可能遭伺服器拒絕。重複點選測試無法修正時間偏差，反而容易將驗證錯誤誤判為網路不穩。

VLESS 簡化了什麼，又依賴什麼

VLESS 著重精簡驗證與請求轉送，資料保護則更多交由外部安全機制處理。UUID 仍用於辨識身分，但協定層並未內建通用資料加密；因此不能推論「整條連線一定沒有保護」。外層若正確設定 TLS，傳輸通道仍可受到保護；反之，若外層沒有適當的安全機制，也不能因為選用 VLESS 就假設資料已加密。安全特性必須依完整組合判斷。

不能只保留 UUID、切換 Type，就將 VMess 與 VLESS 互相轉換。伺服器必須監聽對應協定，外層傳輸也必須相符。部分連線資料可能包含額外的流控或安全選項，但這些欄位並非適用於所有傳輸組合。如果用戶端未顯示某個項目，請先確認目前選擇的類型、伺服器要求及支援範圍；不要為了讓欄位出現而任意切換協定，導致原本正確的入口失去對應關係。

WebSocket、Host 與 Path 的關係

使用 WebSocket 時，Path 是伺服器用來接收對應請求的路徑，通常須保留開頭斜線及完整字元。Host 是 HTTP 層請求中的主機資訊，SNI 則用於 TLS 交握與憑證選擇；兩者經常相同，但屬於不同層，不能一概視為同一欄位。若伺服器前方設有反向代理，Path 或 Host 不符，可能在代理協定開始驗證前就收到 HTTP 錯誤，因此修改 UUID 無法解決這類問題。

使用網域憑證時，應保持憑證驗證啟用，並確認 Server Name 與憑證涵蓋的名稱相符。遇到憑證錯誤時，先檢查系統時間、名稱拼寫、憑證有效期限與伺服器憑證鏈。略過憑證驗證會降低對連線對象身分的確認能力，不適合作為一般修復方式。若管理者提供 IP 入口及另一個驗證網域，請保留這種分工，不要將所有名稱都換成 IP。

在 iOS 上，不能只從協定標頭大小推論 VMess 與 VLESS 的耗電差異。外層 TLS 交握、WebSocket 封裝、連線重用與伺服器距離都會影響結果；頻繁重新連線時，建立連線的成本可能比穩定傳輸期間的協定差異更明顯。若現有伺服器只提供其中一種，優先正確使用該組合；若兩種都提供，請固定目標與測試條件，比較首次開啟、連續傳輸及切換網路後的恢復情況，而非只看一次的最高速度。

Trojan 將安全通道置於優先位置

Trojan 的典型設計是在 TLS 連線內進行密碼驗證及代理請求傳送，因此憑證驗證是理解連線流程的關鍵。用戶端先連線至伺服器並建立 TLS，再傳送協定驗證資訊。若交握階段已失敗，密碼尚未進入有效驗證流程；若 TLS 正常而驗證失敗，則需核對密碼及伺服器端協定設定。將這兩類錯誤分開處理，能避免在憑證問題上反覆修改密碼。

請一併核對 Address、Port、Password 與 TLS 使用的名稱。SNI 可協助伺服器選擇相應憑證與入口，但不是可任意填寫的裝飾欄位。若連線資料使用網域，請先保留原值完成基本驗證；只有在清楚了解伺服器架構時才調整位址與驗證名稱。Trojan 使用 TLS，不代表任何採用 TLS 的伺服器都能作為此協定入口；伺服器仍須實際提供對應代理服務與驗證帳戶。

HTTP 代理不等於瀏覽 HTTP 網站

HTTP 代理透過 HTTP 語意接收並轉送請求；存取 HTTPS 目標時，通常會使用 CONNECT 建立位元組通道。必須區分兩段連線：用戶端至代理伺服器，以及代理伺服器至目標網站。目標網站使用 HTTPS，不會自動讓第一段成為加密代理連線；只有代理入口本身採用受支援的 TLS 等保護方式，第一段才具備相應安全性。判斷隱私保護範圍時，不能只看瀏覽器網址列的鎖頭圖示。

HTTP 代理可能需要 Username 和 Password，也可能透過伺服器的其他存取控制方式授權。驗證資訊應來自已有的伺服器資料，不要將網站帳號填入代理驗證欄位。若資料提供受 TLS 保護的 HTTP 代理入口，請核對相應類型與憑證名稱；不要將它當成一般 HTTP 連接埠測試後，就判定伺服器故障。HTTP 請求獲得接受，也不代表伺服器允許所有 CONNECT 目標或連接埠。

SOCKS5 的通用性與明確界線

SOCKS5 透過協商指定驗證方式與目標位址，是一種通用代理協定。它可表示網域或 IP 目標，也定義了 UDP 相關機制，但基礎協定本身不提供通用傳輸加密。使用者名稱與密碼用於驗證，不代表後續資料會自動透過加密通道傳送。若使用情境要求用戶端至伺服器的連線受到保護，需依實際外層機制與可信任的網路環境判斷，不能把「有密碼」當成「全程加密」。

SOCKS5 的 UDP 能否使用，取決於用戶端、伺服器與中間網路是否都符合條件。伺服器可能只實作 TCP 轉送，UDP 關聯回傳的位址也可能受網路可達性影響。網域解析由哪一側執行，同樣須依請求形式與用戶端設定判斷。使用 IP 成功、網域卻失敗時，先檢查解析路徑；TCP 成功、即時 App 卻失敗時，再檢查 UDP，不要把所有問題都歸因於帳戶錯誤。

應依現有入口選擇這三種協定。辦公室網路已有 HTTP 代理，就依其驗證方式與存取範圍設定；實驗環境或區域網路已有 SOCKS5 服務，就確認其保護界線；若已有 Trojan 資料，則保留完整 TLS 參數。不要因名稱聽起來較複雜就更換類型。在 iOS 上，代理請求模式、交握頻率與網路品質，通常比單一協定標籤更能解釋載入速度與耗電差異。

它與應用層代理有何不同

WireGuard 會為 IP 封包建立加密通道，以精簡的協定結構及固定的現代密碼套件降低設定複雜度。與主要轉送連線請求的代理協定不同，它須描述本機介面位址、對端身分，以及哪些位址範圍屬於對端。因此 WireGuard 資料通常不只是伺服器位址和密碼，還包含本機私鑰、對端公鑰、通道位址及路由相關內容。了解這些關係，比逐一記住欄位名稱更有幫助。

WireGuard 使用 UDP 作為外層承載，因此目前網路能否穩定傳送 UDP 是基本條件。在某些環境中，網頁能正常直連，不代表 UDP 通道入口也可連線。端點網域解析、連接埠開放與伺服器回程路由都必須正常。完成協定交握後，還須確認目標流量路由正確，且伺服器允許相應轉送。因此「顯示已交握」和「所有目標都能存取」是兩個不同結論。

PrivateKey、PublicKey 與位址歸屬

PrivateKey 是本機機密；PublicKey 則用來讓對端辨識本機身分。伺服器公鑰不是用戶端公鑰，兩側欄位不可對調。若資料另提供預共享金鑰，它是另一項雙方必須一致的參數，不能取代公私鑰成為通用密碼。請勿在討論截圖或故障記錄中公開私鑰；匯入資料即使沒有常見的 Password 欄位，也可能包含足以直接建立連線的敏感身分資訊。

Address 表示通道介面中的本機位址，不是伺服器公網位址，也不是任意可用的區域網路位址。它通常由伺服器管理者分配，並與對端設定相關。Endpoint 才是可從外部連線至伺服器的端點。將 Address 改成伺服器 IP，會混淆通道內部與外部網路；自行複製另一台裝置的介面位址與身分，也可能造成位址衝突或改變對端歸屬。請依照現有伺服器分配給目前裝置的資料設定。

AllowedIPs、MTU 與保持連線

AllowedIPs 用於判斷哪些目的位址應交由該對端處理，也用於接收資料時檢查位址歸屬。它不是依網域排列的網站規則；是否能與 Shadowrocket 的策略路由搭配運作，須依目前匯入方式與介面功能判斷。若資料只涵蓋特定網段，不應自行改成所有位址範圍來「提高相容性」，否則可能改變存取範圍。若無法存取某個內網，請一併核對通道位址、對端範圍與伺服器回程路由。

MTU 決定通道介面可承載的封包大小上限。外層封裝會占用空間，而路徑對分片或大型 UDP 封包的處理方式可能不同，因此可能出現小型請求正常、大型回應停滯的情況。排查時先確認是否只有大型傳輸異常，再依伺服器建議調整；任意較小的數值都不是通用解法。降低 MTU 會增加傳送相同資料量所需的封包數，調整過度也會增加額外負擔。請記錄每次修改後的具體變化。

PersistentKeepalive 可協助部分網路維持位址轉換映射，但持續傳送封包也可能延長無線網路的活動時間。在 iOS 上，應依伺服器要求及實際閒置斷線情況決定是否使用，不要一味縮短間隔。WireGuard 的運算效率不等於整台裝置一定更省電：通道流量、保持連線、訊號強弱與網路切換都會影響結果。適合需要明確網路層位址與網段存取的既有環境，前提是使用者持有完整且相符的對端設定。

從承載方式看設計取捨

Hysteria2 以 QUIC 建立代理傳輸，著重於延遲與封包遺失情況下的資料傳送。QUIC 在 UDP 上實作連線管理、可靠傳輸與壅塞控制等機制，因此「外層使用 UDP」不代表應用資料完全沒有可靠性處理。不過，它仍需要可用的 UDP 路徑；若網路持續丟棄相關封包，協定內部機制也無法憑空建立連線。選擇前先確認這項前提，比反覆修改頻寬參數更重要。

QUIC 的串流機制可減少部分跨串流阻塞，但無法消除無線訊號微弱、共用出口壅塞或伺服器容量不足造成的限制。單一連線的實際表現也會受到用戶端實作、目標回應與路徑變化影響。Hysteria2 與其他世代協定名稱相似，不代表連線資料可以直接共用；Type、驗證方式與附加參數都必須符合實際伺服器。成功匯入只代表資料可解析，仍須完成交握與存取驗證。

驗證、TLS 與選用封裝

基本核對項目包括 Address、Port、驗證資訊與 TLS 名稱。驗證字串由現有伺服器提供，可能含有必須完整保留的分隔字元；不要只複製看起來像密碼的部分。TLS 憑證鏈、有效期限與名稱仍須正常驗證。若用戶端顯示憑證問題，先檢查系統時間和名稱設定，再核對伺服器憑證；不要持續關閉驗證來掩蓋設定錯誤，否則將無法可靠確認連線對象。

連線資料可能另含選用的混淆相關設定。這與使用者驗證、TLS 憑證屬於不同層次，雙方設定必須相容；多填一個伺服器未要求的欄位，也可能讓伺服器無法辨識封包。未提供的選項請保留預設值，有明確提供的項目則逐一核對。若只有特定網路連線失敗，使用同一份資料切換網路測試，比在條件不明時同時修改驗證、混淆與頻寬，更容易找出原因。

為什麼不能任意調高頻寬值

部分設定允許填寫上傳與下載頻寬，供相應壅塞控制模式估算速率或協商上限。實際效果取決於用戶端與伺服器設定，並非輸入越大就能獲得越高吞吐量。填入遠高於實際可用容量的數值，可能造成佇列累積、封包遺失，或與其他流量競爭；填得過低則可能限制可用吞吐量。請先確認單位，分清 bit 與 byte，再依目前連線容量和伺服器建議設定合理數值，不要照抄別人的測速截圖。

行動網路容量會隨訊號、位置與基地台負載改變，固定的估算值不一定適用所有時段。若從穩定 Wi-Fi 切換到行動網路後明顯不穩，應先比較網路本身的可用容量，再判斷頻寬設定是否過於積極。使用預設或協商模式時，也須實際觀察短請求與持續傳輸，不能只因參數較少就認定一定較好。每次效能調整都應記錄明確現象、單一變更及復原方式。

在 iOS 上，較積極的資料傳送、封包遺失復原與持續大量流量，可能增加無線活動時間與裝置發熱。即使單次下載較快，也不代表全天使用一定更省電；反過來說，更快完成相同工作也可能減少總活動時間，仍須實測。請同時比較任務耗時、失敗率，以及相近使用時間內的電量變化，不要以單一現象下結論。測試時關閉無關的大量流量工作，避免將背景下載的影響歸到協定上。

適用情境應描述為「現有伺服器提供 Hysteria2、目前網路可使用 UDP，且有必要評估封包遺失時的表現」，而不是無條件取代所有 TCP 方案。若同一伺服器的其他入口正常，只有這個入口在某個網路環境失敗，先檢查該路徑如何處理 UDP；若所有網路都失敗，再回頭檢查伺服器監聽、驗證與憑證。依條件縮小問題範圍，通常比不斷提高頻寬更有效。

將「快」拆解成可觀察的流程

開啟網頁包含網域解析、建立連線、代理交握、目標交握及內容傳輸。首次載入緩慢，可能是前幾個步驟耗時；大型檔案下載緩慢，則可能受持續吞吐量限制。Connectivity Test 的結果只代表該測試方式與目標的表現，不代表所有 App 的整體速度，也不一定等於底層網路的往返延遲。比較協定時，先說明測試要回答的問題，再決定記錄哪些現象。

公平比較時，應盡可能固定裝置、網路、伺服器所在地區、目標服務與測試時段。同名伺服器也可能經過不同出口，負載會隨時間變動；連續測試時裝置升溫，也可能影響後續結果。可交替測試兩種可用設定，並重複進行短請求與持續傳輸，不要先把一種設定測到裝置發熱後才測另一種。若結果差距不大，請保留波動範圍，不必勉強歸納出某種協定永遠領先。

耗電不只取決於加密運算

iOS 上的代理運作通常涉及網路延伸、封包處理及系統無線連線管理。密碼運算會消耗資源，但螢幕、行動網路訊號、重傳、背景工作與保持連線也可能占有重要比例。系統電池頁面顯示的是整體結果，無法直接分離出單一協定每次運算的耗能。若使用代理期間同時看影片、下載或長時間開啟螢幕，就不能將整段電量變化全算成 Shadowrocket 的協定負載。

應分開觀察閒置與使用中的情況。閒置測試著重是否頻繁喚醒、重新連線或傳送保持封包；使用中測試則觀察相同工作需要多久、是否發熱及重試失敗。On Demand 會依條件觸發連線，不是降低協定負擔的按鈕。若設定導致切換網路時不斷重新建立連線，實際體驗可能比持續連線更差。先確認是否需要自動連線，再檢查觸發條件是否符合日常網路環境，避免為了省電反而增加切換。

TCP、UDP 與網路切換的實際影響

TCP 在封包遺失時須恢復有序位元組串流，連線品質不佳可能拉長等待時間；以 UDP 為承載的上層協定也需要自行處理復原與壅塞管理，並非天然不會等待。即時 App 更在意持續抖動與封包送達，網頁則更看重短時間內完成交易。一次大型檔案吞吐量測試不能代表通話或互動體驗；同樣地，某個即時 App 異常也不能直接證明代理的 TCP 轉送有問題。請選擇符合實際用途的工作進行測試。

在 Wi-Fi 與行動網路間切換會改變外部位址、可用頻寬與路徑 MTU，既有連線可能中斷。即使某種承載方式支援遷移，整體恢復仍取決於用戶端實作、伺服器與目標 App。測試時請分別記錄「切換後的新請求能否成功」與「原有請求能否繼續」，不要混為同一項指標。對需要持續互動的情境而言，恢復情況是否可預期，通常比瞬間最高速度更重要。

也要確認路由是否一致。一個設定將大部分請求直連，另一個設定卻把相同請求送往遠端，測得的耗電與速度差異就不只是協定造成。使用 Config 測試時，請維持相同的規則與策略；必要時可短暫使用 Proxy 進行控制測試，結束後再恢復原本的姿態。Data 的伺服器統計可協助確認流量是否經過預期入口，但計數不代表成功率，也無法單獨證明所有網域規則都已生效。

詳細讀數說明請參閱Data 流量統計文章。記錄測試時，請註明工作、網路、路由姿態及是否切換過連線，同時遮蔽帳戶資料。可供查證的結論應是「在這些條件下，此設定完成這項工作時較穩定」，而不是「這種協定永遠比較快」。若兩種方案表現接近，欄位完整、容易維護且復原步驟清楚，往往比繼續追求微小差異更實用。

選擇順序：先看支援情況，再考慮效能偏好

如果你只有一份現有訂閱，第一步是完整匯入並核對類型，不必先決定偏好哪一種協定。伺服器未開放的類型，用戶端無法憑空啟用。需要手動填寫時，先備齊入口、驗證、傳輸、安全與附加欄位，再到 Add Server 選擇相符類型。訂閱與手動新增入口的差異，請參閱Subscribe、掃描 QR Code 與手動匯入說明；日常使用流程仍以使用教學為主。

如果同一個現有環境提供多種完整入口，可依工作需求篩選：一般網頁先看短請求的穩定性；持續下載則觀察吞吐量與發熱；即時 App 要確認 UDP 能力及抖動情況；存取指定內網時，則核對是否需要 WireGuard 的通道位址與網段設定。協定名稱只能提供設計線索，不能取代端對端測試。維護設定時也要考慮憑證更新、金鑰管理與設定更新，選擇自己能確保資料正確的組合，而不是欄位最多的組合。

先建立最精簡可用設定，再恢復分流

保留原始連線，另複製一份進行測試。先確認系統網路正常，再驗證入口位址與連接埠，接著檢查驗證與 TLS，最後存取已知目標。若要排除規則干擾，可暫時使用 Global Routing 的 Proxy 姿態；測試結束後，請恢復預期設定。連線穩定後再啟用 Config，核對目前設定檔、規則順序與 FINAL。不要同時調整 DNS、協定、傳輸與策略，否則即使恢復設定，也難以判斷是哪個步驟產生影響。

遇到「只有某個網站失敗」時，先確認該目標本來是否可存取，再查看它符合哪條規則、採用哪種策略，以及網域解析是否正常。「所有目標都失敗」時，優先檢查入口與驗證；「小型請求正常、大型回應停滯」時，留意路徑、MTU 與傳輸；「切換網路後失敗」時，檢查新網路的可達性與連線重建。依現象分流縮小範圍，比將所有故障都歸因於協定不合適更有效。

訂閱更新、敏感資料與取得方式

Subscribe 更新後可能變更位址、連接埠或項目清單，手動修改的內容也可能被新的訂閱資料覆蓋。若出現「之前可用，更新後卻失敗」，請比較變更項目，確認目前使用的是否仍是預期項目，不要立刻修改所有全域設定。向現有伺服器管理者回報時，可提供協定類型、錯誤階段、接入網路及是否能重現；訂閱連結、UUID、密碼、私鑰及含驗證資訊的 QR Code 都應遮蔽，避免在記錄中公開完整存取權限。

若問題實際發生在用戶端下載或首次開啟階段，請先查看安裝與開啟說明，不要把安裝問題混入協定測試。Mac 須區分 Apple 晶片與 Intel；首次開啟遭到阻擋時，請確認來源後到系統「隱私權與安全性」處理。Windows 的 SmartScreen、Android 的安裝權限及 Linux 的執行權限，也請依下載頁的對應說明處理。其他平台的安裝檔由本站 /dl 提供，請勿在協定資料中尋找替代安裝網址。

iPhone / iPad 使用者請在 App Store 產品頁確認開發者 Shadow Launch Technology Limited、官方圖示與 App ID 932747118；系統需求以 App Store 頁面標示為準。取得方式分兩種：iPhone / iPad 版在 App Store 一次性付費 $2.99；Mac / Windows / Android / Linux 版免費。購買用戶端不包含伺服器連線資料；取得用戶端與匯入現有訂閱是兩件獨立的事，連線失敗也不應靠重複購買用戶端處理。

最後保留一份已驗證的設定，並記下適用的網路與用途。之後每次只調整一個變因，確認存取、規則與恢復情況後再繼續。若問題仍未解決，請回到本頁相應的協定章節核對欄位，再參閱下載與安裝常見問題，區分取得問題與連線問題。選擇協定的標準不在名稱新舊，而在於伺服器支援、參數相符、驗證結果明確，並能在日常網路環境中穩定重現。