Shadowrocket 協定參考

01 / CONNECTION MODEL

協定層次與參數核對順序

協定類型只是連線鏈路的一環

一次請求從裝置送往目標服務，通常會經過本機路由判斷、伺服器位址解析、底層連線、協定認證與目標轉送。Shadowsocks、VMess、VLESS 等名稱主要說明用戶端與伺服器如何交換代理請求，並不直接代表伺服器距離、出口頻寬或壅塞程度。相同協定的實際表現可能差異很大；反過來說，在相同網路與相近伺服器條件下，不同協定也可能有相似的使用體驗。

理解參數時，應將伺服器位址、認證、傳輸、安全性與路由分開看。伺服器位址決定連線目的地；密碼、UUID 或金鑰用來確認連線身分；TCP、UDP 及其上層封裝決定資料如何傳輸；TLS 負責相關連線的加密與憑證驗證；規則則決定哪些請求使用這條連線。某一層通過，不代表後續各層也正常，因此「測得到延遲」不能取代完整的存取驗證。

依據資料填寫，不要把猜測當成預設值

在 Add Server 選取類型前，先確認現有資料標示的協定。連接埠相同不代表協定相同，使用 TLS 也不代表類型一定是 Trojan。匯入訂閱後，應檢查類型、伺服器與連接埠是否合理，再核對認證欄位與傳輸選項。欄位名稱與排列可能因類型而異，請以目前 App 內顯示為準；若未取得某項參數，不要只憑網路範例填入看似常見的值。

伺服器網域名稱、TLS 的 SNI 與 WebSocket 的 Host 可能相同，也可能因服務部署方式而不同。網域名稱用來尋找連線位址；SNI 用於 TLS 交握時選擇服務，通常也會參與憑證名稱核對；Host 則用於應用層請求分流。修改其中一項不一定會連帶改變另外兩項，不能把它們當成可任意互換的伺服器位址。

分清 UDP 支援與特定應用是否可用

「支援 UDP」至少涉及用戶端協定實作、伺服器轉送權限、中間網路與目標服務四個條件。有些協定會把 UDP 資料封裝在串流連線中，有些直接使用資料報，另一些則視額外擴充功能而定。語音、即時互動或 HTTP/3 的表現，不能只看協定名稱判斷。即使一般網頁正常，也應針對實際使用的 App 個別驗證，避免把網頁可用誤認為所有連線能力都正常。

後續章節所說的「選用」，是指在你已取得且伺服器明確支援的設定中做選擇；並非在用戶端選單切換類型，就能改變伺服器協定。若匯入結果與原始資料不同，應先確認分享連結是否完整、解析後欄位是否保留，再決定重新匯入或向資料提供者確認，避免在錯誤類型上反覆調整。

02 / SHADOWSOCKS

Shadowsocks：加密方式與轉送範圍

以較少的協定層完成代理轉送

Shadowsocks 的基本方式，是在用戶端與伺服器之間建立受加密保護的代理轉送通道，將目標位址與應用程式資料交由伺服器處理。它不是完整的虛擬區域網路協定，也不會自動決定系統中每個請求的路由。Shadowrocket 會在裝置上接收需要處理的流量，再依據 Global Routing 與目前設定，決定是否交由選取的 Shadowsocks 連線；協定本身與本機分流是不同的功能。

較少的封裝層有助於降低部分交握與處理成本，但不能據此保證速度更快。實際傳輸量仍受加密實作、裝置負載、伺服器效能與連線品質限制。若伺服器本身壅塞，改用其他加密方式通常無法解決問題；若連線採用額外傳輸機制，也應將其成本一併納入考量，不能只憑類型名稱推斷實際路徑。

Method 與 Password 必須成對核對

最核心的資訊是伺服器、連接埠、加密方式與密碼。Method 不是可任意選擇的效能等級，而是雙方必須共同使用的演算法與訊息格式。AEAD 方式除了提供機密性，也會驗證資料完整性；不同方式的金鑰長度與衍生方法可能不同。即使 Password 正確，Method 錯誤仍會造成認證或解密失敗，可能表現為連線建立後沒有有效回應，而非明確顯示「密碼錯誤」。

若協定變體使用固定長度的編碼金鑰，就不能直接把一般短密碼當成金鑰填入。原始資料若包含多個認證部分或特殊格式，應完整保留，不要自行刪除分隔符號。複製時也要留意末尾空格、換行，以及輸入法自動替換的標點；重新手動輸入不一定更準確，應優先從可信的原始資料複製，再逐項比對匯入後的內容。

TCP 正常不代表 UDP 已通過驗證

Shadowsocks 可以承載不同類型的應用程式流量，但 UDP 是否可用仍取決於兩端支援與網路條件。網頁載入成功通常只驗證了部分路徑。若語音連線失敗或即時應用只在特定網路異常，請先確認伺服器允許 UDP 轉送、用戶端相關選項與資料一致，以及目前 Wi-Fi 或行動網路是否能傳送相應資料，而非先更改密碼與加密方式。

UDP 資料報通常不具備與 TCP 相同的可靠傳輸機制，遺失後是否重傳由上層應用決定。因此，測試顯示延遲較低，但通話仍斷斷續續，兩者並不矛盾：延遲只反映成功收到回應的部分請求，無法說明所有資料報都及時抵達。排查時應同時觀察遺失、抖動與連續通話狀況，而不是只看最低延遲數字。

如何在 iPhone 與 iPad 上評估

在現有設定都能正常使用的前提下，Shadowsocks 適合作為結構較直接的比較基準。測試短時間網頁請求時，觀察首次回應與重複瀏覽；測試大型檔案時，觀察穩定傳輸量；測試即時 App 時，留意長時間的抖動。不要將不同地區、不同出口的設定放在一起，再把所有差異都歸因於協定。伺服器位置與負載往往比封裝層數影響更大。

若想降低裝置耗電，應先減少不必要的持續傳輸與反覆失敗重連，再觀察加密處理的影響。長時間保持連線但幾乎沒有流量，與持續高速下載的耗電來源不同。前者較受背景喚醒與網路保活影響，後者還包括無線傳輸、加密運算與裝置溫度變化；只看電池頁面上的單一百分比，不足以判斷協定問題。

03 / VMESS & VLESS

VMess 與 VLESS：認證、傳輸與 TLS

名稱相近，但不能互換類型

VMess 將代理請求認證與資料處理結合在協定中；VLESS 則採用較精簡的請求與身分描述，將連線安全更多交由搭配的安全傳輸層處理。兩者都可能搭配不同承載方式，因此資料中出現 TCP、WebSocket 或 TLS 時，仍須核對具體組合。將 VMess 項目直接改成 VLESS，不會自動轉換認證方式、訊息格式或伺服器設定。

VLESS 本身不提供與 TLS 同等的資料加密保護。看到某項設定使用 VLESS，不能只核對 UUID 就認定安全層已完整。應確認原始資料要求的安全機制及其參數確實啟用；若資料未說明，應先補齊部署資訊，而不是憑猜測關閉憑證驗證。相關擴充功能是否支援，也須以目前用戶端與伺服器的實際能力為準。

UUID、時間與認證資訊

UUID 是這類設定常見的身分欄位，應視為敏感資訊。它不是伺服器網域名稱，也不應與備註名稱混淆。VMess 的認證機制涉及時間條件，裝置時間偏差過大時可能影響認證；因此，若同一份資料在另一台裝置上正常，應檢查自動設定時間是否正常，而不只是重新安裝 App。VLESS 的認證機制不同，不能直接套用 VMess 的每項排查結論。

若匯入資料包含額外的認證或流量控制參數，只填 UUID 可能無法建立連線。部分舊資料中的欄位在目前的組合下可能不適用，不要為了讓表單看起來完整而任意填值。正確做法是對照伺服器提供的連線說明，確認該欄位是否適用於目前協定；若它只屬於另一種傳輸或安全組合，就不應套用。

WebSocket 增加了哪些核對項目

WebSocket 可讓連線承載於相應的應用層工作階段中，常用於既有 HTTP 服務的轉送架構。它會增加路徑、Host 與中間轉送行為等條件。路徑通常必須完全相符，大小寫、結尾斜線或遺漏前綴都可能導致伺服器未將請求交給正確的處理程序。收到 HTTP 回應也不代表代理認證成功，請求可能只是抵達一般網站。

外層使用 TLS 時，會先進行安全交握，之後才建立 WebSocket 並交換代理協定資料。憑證錯誤、路徑錯誤與 UUID 錯誤發生在不同階段，應依所在層次判斷現象。若中間轉送服務會因閒置逾時而關閉長連線，連線可能在閒置一段時間後中斷；這與一開始就無法認證不同，也不能單靠加長密碼解決。

效能取捨與排查順序

增加承載層可能帶來更多交握次數、訊息負擔或中間設備處理，但它也可能是服務部署的必要部分，不能為了減少成本而只在用戶端將其關閉。比較效能時，應使用完整且正確的設定組合。短連線較多的情境更容易受到建立連線成本影響；持續連線則較容易受頻寬、封包遺失與多工行為影響，不能只用一次延遲測試代表兩者。

建議依序檢查位址解析、連接埠、TLS、傳輸路徑、認證與實際目標存取。若所有目標都失敗，先檢查共同的連線層；若只有一個網域失敗，再檢查規則、解析與目標狀態。現有設定在訂閱更新後突然異常，也要確認該項目的傳輸選項是否改變，以及手動修改是否被更新內容覆蓋，不要只憑更新前的記憶核對參數。

04 / TROJAN · HTTP · SOCKS5

Trojan、HTTP 與 SOCKS5：安全界線與代理運作方式

Trojan 仰賴正確的 TLS 連線

Trojan 的設計是在 TLS 連線內承載代理協定，並透過相應認證資訊讓伺服器識別代理請求。理解時，應將外層 TLS 與內層認證分開看。伺服器位址能建立 TCP 連線，只代表連接埠可連通；TLS 交握通過後，仍須確認認證與目標轉送成功。Password、SNI、連接埠及伺服器部署方式都必須正確，不能只填入密碼就期待連線成立。

憑證驗證用來確認連線對象的身分。若出現名稱不符，應檢查資料提供的 SNI、伺服器網域名稱與憑證涵蓋範圍；若提示憑證有效期間有問題，則應檢查裝置時間與伺服器憑證。將略過驗證設為日常預設值，會失去身分核對這一層保護，也可能掩蓋真正的設定問題。應修正名稱、憑證鏈或時間，而不是只讓錯誤提示消失。

HTTP 代理不代表目標網站使用 HTTP

HTTP 代理描述用戶端與代理服務的互動方式。存取一般 HTTP 目標時，代理可以處理相應請求；存取 HTTPS 目標時，通常會使用 CONNECT 方法建立通往目標的通道，再透過該通道建立目標網站的 TLS 工作階段。因此，「HTTP 代理」不表示瀏覽器只能開啟一般 HTTP 網站，也不代表用戶端到代理伺服器這一段一定受到 TLS 保護。

若資料明確提供 HTTPS 代理，用戶端與代理之間也會建立相應的 TLS 連線，須核對其憑證與名稱。使用者名稱與密碼通常用於代理認證，但認證本身並非完整的加密機制。要判斷安全界線，應分別確認「裝置到代理這一段是否加密」以及「App 到目標這一段是否加密」，不能因網頁顯示安全連線，就推定中間每一層都相同。

SOCKS5 提供通用的目標轉送方式

SOCKS5 會透過協商告知代理服務目標位址、連接埠與所需操作，並可使用網域名稱或 IP 位址作為目標。基本 SOCKS5 不內建 TLS 等級的傳輸加密；使用者名稱與密碼認證也不能取代安全通道。它適用於服務部署明確提供此類介面的情境；選用前應了解連線所在網路與額外保護條件，不要只因設定項目較少，就認定它更適合行動裝置。

SOCKS5 的 UDP 轉送涉及額外協商與資料報路徑，實際是否可用取決於伺服器實作、用戶端設定與網路連通性。TCP 請求正常不代表 UDP 關聯已建立。同樣地，目標網域在哪裡解析也會影響結果：若先在本機將網域轉換成 IP，代理服務收到的可能就不是原始網域；解析差異與網域規則比對都須結合實際連線鏈路理解。

如何依現有環境選用

若組織或自有伺服器已提供固定代理介面，應依其協定填寫，不要自行改用名稱較熟悉的類型。伺服器監聽的連接埠相同，也可能使用不同的交握格式。對於有明確憑證與網域部署的 Trojan 設定，應優先完整核對 TLS；對於 HTTP 或 SOCKS5，則應確認介面的信任界線、認證需求與允許的目標範圍。

實際排查時，若 CONNECT 被拒絕、只有部分連接埠失敗，或認證持續無法通過，也要考慮伺服器存取政策。目標權限限制不等於無線訊號不佳，也不是所有協定都會遇到的問題。記錄錯誤發生的目標類型與階段，有助於區分認證失敗、目標無法連線與請求遭伺服器政策拒絕；沒有證據時不要同時修改所有欄位。

05 / WIREGUARD

WireGuard：金鑰、隧道位址與 IP 路由

從目標代理轉向 IP 隧道

WireGuard 的運作模式與前述幾類目標代理不同：它透過加密隧道承載 IP 封包，雙方依據金鑰與對端資訊建立通訊關係。其設計著重精簡的協定與固定的密碼學組合，不會提供一長串可選演算法讓使用者逐項協商。對 Shadowrocket 使用者而言，參數核對重點會從「代理帳號與目標位址格式」轉為金鑰、Endpoint、隧道位址與可連通網段。

此協定使用 UDP 作為底層傳輸，因此外層 UDP 路徑必須可用。隧道內可以承載不同 App 的 IP 流量，但不代表外部網路允許所有 UDP 通訊。若同一份設定在某個 Wi-Fi 可用，切換到行動網路後卻失敗，應檢查外層路徑與位址解析，而不是先修改隧道內的目標規則。內層 App 的 TCP 正常與外層 UDP 可連通，屬於不同層次的狀況。

Private Key 與 Public Key 的方向不可顛倒

Private Key 是本端身分資訊，必須保密；Public Key 則用來讓對端識別本端。用戶端設定中的對端公鑰應對應伺服器身分，不能隨意複製成本端公鑰。若資料另有提供 Preshared Key，兩端也必須一致。金鑰內容通常採固定編碼格式；複製時遺漏字元或混入空格，或將私鑰放進公開截圖，都會分別造成連線或安全問題。

Endpoint 是發起通訊時使用的外部位址與連接埠，不是隧道內部位址。Address 這類參數則描述本端在隧道中的位址，須符合部署規劃。將 Endpoint 的公開位址填入隧道位址，或在兩端設定互相衝突的內部位址，都可能造成交握後無法正常轉送。填寫時應依欄位用途核對，不要只因為它們看起來都像 IP 位址就混為一談。

Allowed IPs 與本機分流不是同一份清單

在 WireGuard 的運作模式中，Allowed IPs 同時參與對端位址歸屬與送出路徑選擇。它不是遠端網站清單，也不能直接取代 Shadowrocket 的 Rule。本機規則會先決定請求是否進入相應連線；進入 WireGuard 後，隧道位址範圍與伺服器端轉送又會決定資料能否抵達目標。某一側設定的範圍較廣，不代表另一側也會自動允許相同範圍。

若要存取你已有的遠端內部網路，應核對目標網段、回程路由，以及伺服器是否允許轉送。若本機 Wi-Fi 與遠端網路使用相同私有網段，也可能發生位址重疊：相同目標看起來既像本機裝置，也像遠端裝置。此時須配合網路規劃與規則處理，不能只靠更換 DNS 解決所有衝突。修改前應先確認該位址屬於哪一側。

Keepalive、MTU 與行動網路

Keepalive 可協助維持網路設備上的對應狀態，適用於確實需要外部主動連入或維持映射的部署，但較頻繁的保活會增加背景網路活動。不要將任意較短的間隔當成通用最佳化方式。行動網路切換後，外部位址與映射可能改變；即使協定具備相應的對端更新機制，仍須確保目前網路允許有效資料抵達，並讓系統有時間恢復連線路徑。

MTU 描述可承載的封包大小。封裝會占用額外空間；若路徑允許的大小不足，可能出現小型請求正常、大型回應停滯的情況。處理時應先排除伺服器與目標問題，再依實際路徑謹慎調整並保留原值。並非所有逾時都與 MTU 有關，盲目調得太小會增加封包數量與處理負擔，也不保證速度改善。應以可重現的目標驗證調整結果。

06 / HYSTERIA2

Hysteria2：QUIC、頻寬參數與封包遺失環境

以 QUIC 為基礎的連線方式

Hysteria2 採用以 QUIC 為基礎的傳輸設計。QUIC 在 UDP 之上提供安全連線、串流管理與可靠傳輸等機制，可在同一連線架構中管理多條串流。相較於將所有資料放進單一有序位元組串流，不同串流在傳輸層的交付可以較為獨立；但它們仍共用連線頻寬、壅塞回饋與裝置資源，不能理解成每條串流都有獨立的網路容量。

這種設計常用於討論往返延遲較高或有封包遺失的路徑，但不能推論「有封包遺失就一定更快」。封包遺失可能來自壅塞、無線訊號、網路設備限制或路徑變化。合理的傳送方式必須適應這些條件；若外層 UDP 無法穩定傳輸，上層協定也無法憑空恢復連通性。協定本身的能力與目前網路允許的通訊條件必須同時具備。

仍須核對認證、TLS 與服務名稱

Hysteria2 的連線資料通常包含伺服器、連接埠、認證資訊及 TLS 相關設定。認證通過與憑證驗證是不同工作：前者讓伺服器確認用戶端權限，後者讓用戶端核對伺服器身分。Server、SNI 與憑證名稱是否一致，應依部署資料確認；不能因底層採用 QUIC 就省略憑證檢查，或把任意名稱都當成可用值。

若部署使用額外混淆設定，應核對雙方的類型與相應參數。它不是認證密碼的別名，也不是填入任意字串就會生效的效能開關。Hysteria2 不應與其他協定或不同協定世代只因名稱相近，就混用參數。匯入後若出現無法解釋的空白欄位，應回到原始資料確認其意義，不要逐項複製其他類型的欄位。

頻寬數值不代表保證可達的速度

有些設定會提供上傳與下載頻寬參數，用於相應的傳送控制或頻寬協商。這些參數代表執行條件或控制輸入，不是購買權益，也不是裝置可直接取得的傳輸量保證。尤其要留意單位差異：位元速率與位元組速率並不相同。介面顯示與資料單位不一致時，應先換算，再依欄位規定填寫，避免數量級錯誤影響運作。

填入遠高於實際可用容量的頻寬，不會增加實體連線能力。相反地，過於積極的傳送可能造成佇列累積，讓其他 App 等待更久或增加封包遺失，也可能導致速度明顯波動。填得過低則可能限制可用傳輸量。是否需要明確填入，以及參數在目前組合下如何生效，應以雙方實作與部署說明為準，不建議把其他人的數值當成固定建議值。

評估行動裝置上的額外負擔

QUIC 的加密、封包管理與復原機制都會占用資源；外層 UDP 在訊號微弱或受限的網路中反覆重試，也可能增加無線活動與耗電。高傳輸量期間發熱較明顯，不應只歸因於某個協定名稱，也可能與螢幕、目標 App 及持續資料傳輸有關。比較時應盡量保持工作內容、亮度、裝置溫度與測試時間一致，避免將環境差異誤認為協定差異。

若現有 Hysteria2 設定在一個網路持續失敗、換到另一個網路卻穩定成功，應優先比較網路條件，並記錄是否連交握都無法完成。若交握正常但長時間負載不穩，再檢查頻寬參數、伺服器資源與路徑封包遺失。若只有特定 App 異常，先確認其請求是否確實經過該連線，以及目標服務是否正常；不要根據單一現象推斷整個協定都無法使用。

07 / IOS & IPADOS

iPhone 與 iPad：速度、耗電與網路切換

將速度拆分為三個可觀察部分

第一部分是建立連線所需時間，包括位址解析、連至底層伺服器與安全交握；第二部分是目標首次回應，包括伺服器連往目標所需的時間；第三部分是持續傳輸量，取決於頻寬、封包遺失、壅塞控制與兩端處理能力。日常瀏覽網頁可能較受前兩項影響，大型檔案則較受第三項影響。單一延遲數字無法同時代表這三項，也不能直接換算成影片、通話或互動體驗。

Connectivity Test 的結果應依目前測試方式解讀。不同方式可能只檢查伺服器是否可連線，也可能嘗試透過代理存取目標。不清楚測量對象時，不要將數字視為完整的業務往返時間。地區名稱也只是一則備註，不能取代實際路徑測量。關於測試意義與地區判斷，可接著閱讀延遲、地區與協定類型的關係。

耗電來自整段運作流程

連線運作涉及 App 產生流量、系統處理網路、協定加密、無線收發與必要的背景維護。高傳輸量時，處理與無線傳輸成本都會增加；閒置時，保活、自動檢查與失敗重連則可能更值得留意。電池統計顯示的比例也會受到其他 App 使用量影響，不能直接將不同使用日的百分比當成協定效率結論。

合理的比較方式是先讓裝置回到相近溫度，保持網路、螢幕亮度與工作內容相同，執行相近時間，再記錄電量變化、傳輸量與連線失敗情況。若一次測試時正在充電，另一次則處於低耗電模式，或背景正在大量同步資料，結果就難以解讀。應多留意是否有持續異常活動，而不是追求幾分鐘內極小的百分比差異。

Global Routing 會改變測試前提

Global Routing 中的 Config、Proxy、Direct 分別代表設定、代理與直連模式。使用 Config 時，規則可能會讓某個目標直接連線；以 Proxy 進行對照時，仍須了解用戶端處理系統與特殊流量的範圍；使用 Direct 則無法驗證遠端代理是否可用。比較前應確認同一個目標走的是相同類型的路徑，否則測到的是路由差異，而不是協定差異。

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

以上是規則順序範例：目標網域屬於 example.com 時使用 PROXY，指定私有網段使用 DIRECT，其餘交由 FINAL 處理。範例未提供連線伺服器，無法單獨建立連線。規則會依順序比對，前面的條件會影響後續規則是否有機會生效；修改規則前應確認目前啟用的 Config，必要時參閱設定檔分段說明。

切換網路後為什麼需要重新觀察

從 Wi-Fi 切換到行動網路時，本機位址、預設路由、DNS 與網路設備映射都可能改變。舊連線即使仍顯示為已啟用，也可能需要重新建立傳輸路徑。QUIC 或 WireGuard 的相關機制可以處理部分路徑變化，但能否順利恢復仍取決於雙方實作與目前網路，無法保證所有工作階段都能持續不中斷。先等待路徑穩定，再用新請求驗證，比連續快速切換更容易判斷。

On Demand 控制的是符合條件時觸發連線的行為，無法修復錯誤密碼、失效憑證或無法連線的伺服器。若切換網路後反覆連線，應分開觀察自動觸發與協定重試，並確認是否同時發生規則變更或網路尚未完成連線。Settings 中的相關設定說明請參閱功能與設定，避免為了解決暫時斷線而改動所有自動連線條件。

最後還要區分 IPv4 與 IPv6 路徑。同一網域可能會回傳不同位址類型，切換網路後使用的位址也可能改變。若只有部分目標失敗，應檢查解析結果、伺服器出口與相應路由條件，而不是立刻停用某一種位址類型。DNS 只能改變名稱解析階段，無法自動修復憑證、協定認證、伺服器權限或目標服務本身的故障。

08 / SELECTION & DIAGNOSTICS

依情境選用與分層排查

先確認可用條件，再比較使用體驗

選用的第一步不是替協定排名，而是確認現有伺服器支援哪些協定。只有一份有效設定時，應先確保設定正確；若有多份設定，先排除認證不完整、安全層不明確或不符合網路條件的選項，再比較剩餘設定在常用工作上的表現。協定名稱無法彌補伺服器無法連線、出口壅塞或路由錯誤，用戶端也無法讓伺服器支援尚未部署的協定。

以固定工作建立可重複的比較

選擇兩三個實際使用的目標，分別測試短請求、持續傳輸，以及有需要時的即時工作。每輪測試保持相同網路、裝置與相近時段，確認目標採用相同路徑後，再更換現有設定。記錄典型表現與失敗次數，不要只保留最好的一次結果。若設定使用的地區與伺服器不同，應明確說明這是在比較整體連線體驗，不能宣稱只驗證了協定效能。

若特別在意耗電，應在連線穩定可用的前提下，比較閒置維護與實際傳輸兩種狀態。經常失敗重連的設定，即使偶爾速度很快，也可能不適合長時間使用。若重視互動體驗，更應觀察負載期間的回應變化；若要存取遠端網段，則應優先確認位址規劃與權限。不同工作的評估重點不同，沒有適用於所有網路、裝置與目標的固定協定順序。

發生故障後，依四個層次縮小範圍

第一層檢查本機網路：裝置是否已連上 Wi-Fi、一般直連目標是否正常，以及網路切換是否完成。第二層檢查伺服器連線：Server 的解析結果、Port，以及所需的 TCP 或 UDP 路徑是否可連通。此時不要急著修改 UUID，因為認證資訊無法修復位址錯誤。若只在一個網路失敗，先保留設定不變，改用另一個網路進行比較。

第三層檢查安全性與認證：TLS 名稱、憑證、裝置時間，以及 Password、UUID 或金鑰是否完整。若記錄能區分交握與認證階段，應依發生位置處理，不要把所有錯誤都歸類為「連線逾時」。第四層檢查實際轉送：Global Routing、目前的 Config、目標 DNS、伺服器權限、UDP 條件與回程路由。交握成功但目標無法使用時，問題通常已不在最初的伺服器連接埠。

更新、還原與問題記錄

Subscribe 更新可能會改變伺服器欄位或項目內容，手動修改不一定會永久保留。更新前後出現差異時，應比較實際欄位，而非只看備註名稱。不要將訂閱網址直接貼到公開討論中，其中可能包含存取憑證。排查記錄只需保留協定類型、網路、失敗階段、目標類型與已遮蔽的錯誤資訊；私鑰與完整認證內容不是公開診斷所需資料。

若修改後沒有改善，應還原原值，再驗證其他可能原因。需要進一步求助時，提供「使用什麼網路、存取什麼目標、何時失敗、已排除哪些項目」，比貼上大量未整理的截圖更有效。第一次匯入遇到問題，可回到入門指南的完整操作流程；購買、重新安裝與還原已購項目請參閱下載指南，不要將商店取得問題與協定連線問題混在同一個排查流程中。

最後應保留一份已驗證可用的基準設定，並清楚了解其協定、認證方式、安全層與路由模式。了解這些界線，比記住某組參數更能應對環境變化：設定必須與伺服器一致，測試必須符合實際工作，結論也必須限於實際觀察到的網路條件。