Shadowrocket 協定參考

協定、傳輸與路由的分工

先辨識設定描述的是哪一層

選擇協定前，先將一條連線拆解成幾個彼此獨立的部分：伺服器位址決定連線目的地，連接埠決定要連到哪個監聽入口，協定決定雙方如何識別要求及驗證身分，傳輸方式決定資料如何承載，路由則決定哪些要求使用這條連線。若混淆這幾個層次，就容易出現「位址和密碼都正確，卻還是無法使用」的情況。檢查時應以完整參數組合為單位，而非只看節點名稱中的協定縮寫。

例如，即使都選擇 VLESS，伺服器仍可能要求不同的傳輸方式、TLS 條件及附加參數。類型名稱一致，只代表雙方嘗試使用同一類要求格式，不表示連線細節也一致。匯入訂閱通常能保留較多欄位，但仍應檢查匯入結果。遇到客戶端無法識別的參數，先確認目前 App 實際提供哪些選項，再向既有伺服器的管理者確認；不要自行把欄位改成看似相近的名稱。

速度與耗電沒有脫離環境的固定排名

協定設計會影響交握次數、資料封裝與重傳行為，但最終速度也取決於伺服器負載、往返時間、封包遺失、無線訊號及目標網站。短網頁較容易顯現交握與解析的耗時；長時間傳輸檔案則較容易受壅塞控制與可用頻寬限制。單次延遲測試只能反映特定條件下的回應時間，不能取代完整的存取測試，更不能據此推論全天候的傳輸量。比較時應盡量維持相同裝置、網路、目標與測試時段。

在 iPhone 和 iPad 上，耗電變化也不只是加密演算法造成的。行動網路訊號微弱、連線頻繁重建、背景持續傳輸、保活過於頻繁，以及長時間開啟詳細記錄，都可能增加耗電量。若某項設定在穩定網路下正常，換網後卻不斷重新連線，應先檢查連線狀態與保活條件，而不是立刻認定是協定本身耗電。電池設定中的統計數據也會受到觀察期間其他 App 活動的影響。

協定參考不能取代伺服器說明

本文說明欄位的用途，但不能根據用途反向猜測有效值。位址應來自使用者已有的資訊，認證內容必須與伺服器一致，傳輸擴充也需要雙方支援。修改前建議記錄原始設定，並保留一份容易辨識的副本供測試。每次只變更一個項目，才能判斷變更與結果是否相關；若同時更換協定、DNS 和規則，即使連線恢復，也很難找出真正原因。

系統要求新增 VPN 設定檔的授權，是允許客戶端建立本機網路處理通道，不會替使用者填入遠端伺服器資訊。系統顯示已連線，也不代表遠端認證、DNS 和目標存取都成功。若卡在授權階段，請先閱讀VPN 設定提示說明；若已連線但無法存取，請依照後續順序逐項排查，避免將系統授權問題誤判為協定選擇問題。

Shadowsocks：精簡結構與加密參數

設計重點在於加密轉送

Shadowsocks 的設計理念是以相對精簡的協定結構轉送 App 流量，並在客戶端與伺服器之間加密及驗證資料。它不是將整個遠端網路直接延伸到裝置上的完整網路層通道。使用者在 Shadowrocket 中看到的系統 VPN 通道，與遠端採用 Shadowsocks 是不同層次：前者負責接入裝置流量，後者負責客戶端與伺服器之間的資料交換。了解這點有助於區分本機路由與遠端協定。

「結構精簡」不表示所有設定都相同。不同加密方法對應不同的資料格式與金鑰要求，附加的傳輸擴充也會改變實際連線方式。一般設定與使用外掛或其他擴充的設定，不能只複製伺服器位址和密碼就互換。手動新增時，應逐項確認目前 App 是否支援伺服器要求的組合；若原始資訊來自訂閱，應先保留完整匯入設定，不要為了讓畫面更簡潔而刪除不明欄位。

密碼與加密方法必須配對檢查

基本欄位包括伺服器位址、連接埠、密碼與加密方法。加密方法不是「越長越安全」的自由選項，而是雙方必須一致的協定約定。伺服器採用一種方法，客戶端改用另一種方法，即使密碼完全相同也無法正常解密。有些較新的方法要求特定長度與編碼格式的金鑰，此時不能把任意日常用字串視為等效密碼。應保留原始大小寫、符號與編碼，不要手動加入空格或刪除結尾字元。

若訂閱更新後突然失敗，先查看類型和加密方法是否有變，再確認原有設定是否被更新內容覆寫。複製密碼時，聊天工具帶入的換行、格式文字空格或選取範圍遺漏，都可能造成差異。位址與連接埠可連通，只能證明網路入口存在，不能證明密碼正確；有些錯誤會在連線後立即中斷，另一些則會持續等待。因此，錯誤發生的階段比畫面上單一的逾時提示更有助於分析。

分別驗證 TCP 與 UDP

一般網頁存取通常能涵蓋部分 TCP 使用情況，但不能證明 UDP 已可使用。即時音訊與視訊、部分 DNS 查詢及其他 App 可能依賴 UDP，能否轉送還取決於伺服器能力、客戶端設定與路徑條件。若網頁正常但即時 App 失敗，應單獨檢查這條路徑，不要只重複測試網頁速度。反過來說，某個使用 UDP 的 App 正常，也不足以證明所有網域解析與 TCP 要求都符合預期。

在裝置上比較 Shadowsocks 設定時，應優先觀察持續連線是否穩定、短要求是否常需等待，以及切換網路後能否恢復，而不是只看一次大型檔案的傳輸速度。硬體對演算法的加速能力、實際傳輸量與資料量都會影響處理負擔。穩定、參數明確且經過驗證的既有設定，通常比未經確認就追求某個演算法名稱更適合作為基準；效能問題應透過重複測試確認。

遇到「測試有回應但網頁無法載入」，請依序檢查位址解析、認證、UDP、規則比對與目標網站。若只有部分網域異常，可進一步閱讀DNS 疑難排解說明。不要反覆切換加密方法來處理解析問題，也不要把略過某項檢查當成長期解決方案。只有在欄位來源、雙方支援狀況與錯誤階段都確認清楚後，修改才有可解釋性。

VMess 與 VLESS：分別檢查認證和傳輸

欄位相似不代表協定相同

VMess 在協定中包含使用者身分識別、要求組織與資料保護相關機制；VLESS 則採用較精簡的要求與認證結構，基礎協定本身不提供相同的資料加密功能，通常需搭配合適的安全傳輸。兩者可能都使用 UUID，也可能搭配 TLS 或 WebSocket，但這些共同點不代表類型可以直接互換。伺服器提供 VMess 時，客戶端選擇 VLESS 並保留 UUID，仍會造成協定不相符。

了解兩者的設計差異時，應著重於職責分配：有些協定將較多機制放在自身內部，有些則將資料保護交由外層安全通道處理。欄位較少不代表一定更快，欄位較多也不代表一定更可靠。實際連線還會受到傳輸層數、交握路徑、伺服器實作與網路條件影響。選擇時應先確認使用者既有伺服器支援哪些功能，再比較可用組合，而不是先選定一個名稱，再試著讓所有欄位配合它。

UUID 之外，還有一組傳輸約定

手動新增時，先檢查類型、位址、連接埠與 UUID，再確認傳輸方式及安全設定。UUID 是身分識別碼，不是伺服器位址，也不能取代密碼型協定的認證欄位。部分 VMess 設定還涉及額外認證或加密選項，應以原始設定要求為準，不要為了配合舊教學而隨意填入數值。若裝置時間明顯不準，認證或憑證驗證也可能受影響，可先檢查系統日期與時間是否正確。

若採用 WebSocket，路徑與要求標頭中的 Host 是獨立參數。路徑通常需要保留開頭斜線及大小寫；不能把網域填入路徑欄，也不能把整個網頁網址當成 Host。使用 TLS 時，SNI 會參與伺服器名稱協商與憑證驗證。連線位址、Host 和 SNI 可能因部署方式而不同，但必須由現有設定明確指定。不要只為了讓欄位「看起來一致」就將三者改成相同值。

找出失敗發生的階段

入口逾時，首先應檢查位址、連接埠或路徑的可達性；TLS 錯誤應先確認名稱、憑證鏈與裝置時間；交握後立即中斷，則需繼續檢查身分與協定欄位。若伺服器前方還有轉送入口，錯誤也可能發生在入口與後端之間。此時客戶端反覆修改 UUID，無法解決入口路徑不相符的問題。記錄測試時間、網路類型與錯誤摘要，通常比連續修改多個欄位更容易找出原因。

在 iOS 上，多層傳輸可能增加第一個要求的等待時間，也可能因重複使用連線而減少後續交握，兩種影響都需依實際負載判斷。不能把「啟用連線重用」當成通用加速開關：多個要求共用同一條底層連線時，封包遺失或連線故障可能同時影響多個要求。若目前設定提供相關選項，應先確認伺服器端支援，再以相同網頁與持續傳輸分別驗證，不要只憑單次測速結果作決定。

既有訂閱能正常匯入時，建議先以匯入結果建立基準，再逐項了解欄位用途。遇到不明的流量參數、安全擴充或傳輸類型，不要省略後直接連線，也不要假設客戶端一定支援。保留原始資訊，確認 App 內實際提供的選項，再決定是否向伺服器管理者詢問。完成協定檢查後，仍需依入門指南驗證 Global Routing 與實際要求；認證成功不代表分流正確。

Trojan：TLS 身分與密碼認證

安全通道與代理要求各有職責

Trojan 的基礎設計將代理要求承載於 TLS 連線中，透過成熟的安全通道保護傳輸，再以協定內的認證資訊識別使用者。理解時可分兩步：先與伺服器建立可信任的 TLS 連線，再由伺服器驗證代理要求與使用者身分。第一步成功不代表第二步也一定成功，因此「憑證正常」與「密碼正確」是兩項獨立檢查。若將兩者當成同一個開關，排查時就會失去方向。

伺服器位址可以是網域，也可以依現有部署使用其他明確入口，但 TLS 驗證所依據的名稱仍須正確。SNI 用來告訴伺服器客戶端要求哪個名稱，憑證則必須能證明該名稱的身分。若連線位址與憑證名稱不同，應依既有設定填入相應欄位，而不是刪除 SNI 來試圖略過問題。位址用來找到入口，名稱用來驗證身分，兩者用途不同，不能互相取代。

檢查憑證時，不要只看是否過期

憑證問題也可能來自名稱不符、憑證鏈不完整、裝置時間異常或伺服器設定錯誤。只查看有效期限，無法判斷整個驗證流程是否正常。遇到相關錯誤時，先檢查裝置時間，再確認填入的伺服器名稱符合設定要求，最後請伺服器管理者檢查憑證部署。關閉憑證驗證會改變信任邊界，無法證明伺服器身分，也不應用來修復密碼、路由或解析錯誤。

密碼應完整保留原始字元，尤其要留意複製時帶入的換行與空格。顯示名稱可以自行修改，但不能因名稱變更就猜測調整密碼、連接埠和協定類型。若 TLS 已建立但認證失敗，應先檢查密碼與伺服器實際提供的協定類型。基礎 Trojan 與帶有額外傳輸擴充的設定並非只差一個備註；使用擴充時仍需雙方支援，並填寫相應路徑或其他約定。

應搭配連線重用觀察交握成本

首次連線通常需要建立網路連線並完成 TLS 交握，遠距離、高封包遺失率或網路切換都會拉長等待時間。後續要求是否重複使用底層連線，取決於實際實作與設定，不能只看協定名稱就推斷。比較時可分別觀察首次開啟網頁、連續瀏覽與持續傳輸。如果只有第一次較慢、後續正常，優先分析解析與交握；若持續傳輸也不斷停頓，則繼續檢查路徑品質與伺服器負載。

就 iPhone 耗電而言，TLS 加密並非唯一因素。若 App 不斷建立短連線，或連線失敗後持續重試，無線模組與系統網路處理都可能增加運作時間。應在相同網路和相近資料量下比較，並區分螢幕開啟、背景等待與實際傳輸。不要把長時間播放影片後的耗電量，直接拿來與幾分鐘瀏覽靜態網頁比較；使用負載不同，無法得出有效結論。

網頁出現憑證警告時，還需判斷警告來自哪一層：是客戶端連線伺服器時回報 TLS 失敗，還是瀏覽器存取目標網站時發生憑證問題。前者應檢查目前連線參數；後者也可能與目標網站、裝置時間或其他網路設定有關。不要只看到「憑證」兩字就修改 Trojan 密碼。記錄錯誤出現的位置與時間，通常能快速區分這兩類問題。

適合保留 Trojan 的情況，是既有伺服器提供完整且可驗證的 TLS 設定、認證欄位明確，而且實際存取穩定。使用 TLS 不代表它自動優於其他方案，也不能保證每種網路路徑都能正常運作。如果既有設定原本正常，最近才出現名稱或憑證錯誤，應優先檢查部署變更，而不是立刻更換協定；購買與 App 更新問題則請另行參閱疑難排解。

HTTP 與 SOCKS5：通用代理的適用範圍

兩種通用介面，解決不同問題

HTTP 代理最初是為了轉送 HTTP 要求而設計，常見的 CONNECT 方法則可建立通往指定目標的位元組通道。SOCKS5 是用途較廣的代理協商協定，定義目標位址、連線命令與選用的認證流程，不要求上層內容一定是網頁。兩者常作為既有網路環境中的標準介面，但「通用」指的是介面用途，不代表所有實作都支援所有命令、認證方式或 App 流量。

HTTP 代理中的目標網站 HTTPS，與客戶端到代理伺服器之間是否加密，是兩個不同問題。透過 CONNECT 存取 HTTPS 網站時，網站連線可以保有自身的 TLS 保護，但代理連線本身仍須依實際類型判斷。SOCKS5 基礎協定也不會自動提供資料加密，使用者名稱與密碼認證不等於加密通道。因此，不能只因網頁網址顯示安全標示，就認為代理這一段的所有中繼資料都受到相同保護。

分別確認認證方式與目標解析

新增既有 HTTP 或 SOCKS5 資訊時，先檢查伺服器位址、連接埠、是否要求認證，以及目前 App 支援的相應方式。有些入口不使用帳號密碼，有些則必須同時填入使用者名稱與密碼，不能長期以留白試探。若既有說明指定使用受 TLS 保護的代理入口，也應確認客戶端選擇的類型與安全選項相符，不能把一般 HTTP 欄位當成所有安全代理形式的統稱。

由哪一端解析網域會影響存取結果與錯誤判斷。SOCKS5 可以表示網域目標，但實際要求是否將網域交由遠端處理，仍與客戶端解析及路由處理有關。HTTP CONNECT 的目標也可能以主機名稱或位址表示。若遠端能解析而裝置本機解析失敗，切換解析位置可能改變結果，但應先了解目前設定，再進行驗證。不能只因協定支援網域，就斷定所有要求一定由遠端解析。

網頁可用不代表完整服務都可用

一般 HTTP CONNECT 通常以 TCP 為主，不能據此推論 UDP App 可用。SOCKS5 定義了 UDP 相關機制，但不少部署只開放 TCP，或因網路條件而限制 UDP 回程。若聊天文字正常但通話失敗，應依該服務使用的傳輸方式繼續檢查。反覆更換網頁測試目標只能驗證網頁存取，無法補足缺少的 UDP 能力，也不能證明 App 的所有要求都經過同一條路徑。

這兩種協定的處理架構可能較直接，但是否省電、是否更快，仍取決於加密層、連線時間、網路品質與伺服器實作。協定欄位較少，不會自動減少行動網路活動；若認證不斷失敗、入口頻繁中斷，實際體驗反而可能更差。在 iOS 上應觀察連線重試、目標存取與背景行為，而非只以「標準協定」作為效能判斷依據。

使用者既有的辦公或測試環境明確提供這類入口時，可依其能力範圍使用；若需要傳輸敏感資料，也應確認目標 App 本身的加密與代理鏈路保護。遇到認證遭拒時先檢查帳號欄位；連線建立後目標仍無法存取，則繼續檢查解析與遠端存取權限。不要任意切換協定類型來解決權限問題，也不要在求助記錄中公開帳號密碼。操作入口請參閱首次新增與連線步驟。

WireGuard：網路層通道與金鑰關係

從要求轉送轉向位址與對端

WireGuard 是加密網路層通道，採用固定的現代密碼套件與公鑰身分模型，設計上盡量減少協定選項及交握複雜度。與主要描述特定目標連線的代理協定相比，它更著重本機通道位址、對端身分、端點與可達網段之間的關係。在 Shadowrocket 中使用時，仍需由客戶端安排裝置流量與該連線的關係，不能直接假設其他環境中的完整路由行為在此同樣適用。

設定看似欄位不多，但每個欄位都有明確用途。端點位址用來在實際網路中找到對端，通道位址用來描述通道內的本機身分，公鑰用來識別對端，私密金鑰則用於證明本端身分。端點位址與通道位址通常不是同一類位址，不能互換填寫。若將伺服器的公網位址填入本機通道位址欄，即使連接埠正確，也會造成位址與路由關係錯誤。

依所屬端辨認金鑰

本端私密金鑰必須保密，對端公鑰用來確認連線對象，兩者不是可任意互換的欄位。若設定包含預先共用金鑰，它是額外的金鑰資料，雙方必須一致，不能用對端公鑰取代。匯入後若交握失敗，應先檢查金鑰所屬端與端點，再確認網路可達性。重新產生本端金鑰會改變身分；若伺服器仍只接受舊公鑰，單方面更換客戶端金鑰就無法恢復原有連線。

在 WireGuard 中，Allowed IPs 會參與對端位址範圍與加密路由關係，不只是備註，也不能簡單視為裝置上最終生效的全部分流規則。Shadowrocket 的 Global Routing 與 Config 也會影響流量如何進入所選連線。若通道交握正常，但部分位址無法連線，應一併檢查通道位址範圍、遠端轉送條件與客戶端路由，不能只看最後一條規則就斷定遠端一定可達。

分別檢查交握、MTU 與保活

WireGuard 使用 UDP，能瀏覽一般網頁不代表端點所需的 UDP 路徑暢通。若一直無法完成交握，應先檢查端點網域、連接埠、金鑰與路徑條件。若已完成交握、小量資料正常，但大型頁面或上傳卡住，則可繼續檢查 MTU。通道封裝會占用額外空間，若路徑無法妥善處理報文大小限制，可能會出現部分要求成功、較大傳輸停滯的情況。

MTU 不宜直接照抄他人裝置上的固定數值。應先記錄目前數值，再於可控條件下逐步驗證，並觀察網頁、上傳與持續傳輸是否同時改善。降低 MTU 可能避開分片問題，但也會增加傳輸相同資料量所需的報文數量，並非越小越好。只有症狀與報文大小相關，且調整後能重複改善，才有理由保留變更；身分錯誤無法靠 MTU 修復。

Persistent Keepalive 這類保活設定可用來維持某些網路設備上的對應關係，但傳送間隔會影響背景網路活動。只有在既有環境確實有需要時才設定，不要為了「更穩定」而一律採用很短的間隔。Wi-Fi 與行動網路切換後，對端能否及時取得新的網路位置，也需要實際驗證。在 iPhone 上，持續保活、訊號微弱與頻繁切換對耗電的影響，可能比協定運算本身更明顯。

適用前提是使用者已有完整且彼此相符的對端設定，並清楚需要存取的位址範圍。驗證順序應從交握、通道內位址，再到網域與實際服務，不能把一次交握成功當成全部完成。若網域連線失敗但直接使用位址正常，應轉查 DNS；若只有特定網段失敗，則檢查路由與遠端轉送；若休眠後恢復異常，再觀察對應關係與保活。分層檢查比同時更換金鑰與路由更容易得出結論。

Hysteria2：QUIC、頻寬提示與路徑條件

以 UDP 為基礎的傳輸取捨

Hysteria2 以 QUIC 組織傳輸，運用其安全交握與多串流能力，並針對高延遲、封包遺失等網路條件採用相應的傳輸設計。它的目標不是讓所有網路都達到相同速度，而是在特定路徑上採用不同於傳統 TCP 承載的控制方式。QUIC 使用 UDP，因此網路入口與中間路徑如何處理 UDP，會直接影響連線能否建立。一般網頁可用，不能作為此類路徑已經暢通的證明。

了解多串流時，需區分各串流的傳輸獨立性與共享資源。某個串流的資料等待，不一定會像單一有序位元組流那樣阻塞其他串流的傳送，但所有串流仍共用底層路徑、壅塞控制與可用頻寬。無線訊號變差或入口受限時，多串流不會創造額外容量。若許多要求同時變慢，應先觀察整條路徑，而不是認為每個目標網站都同時故障。

分別檢查認證、TLS 與附加參數

基本檢查順序為協定類型、伺服器位址、連接埠、認證資訊與 TLS 名稱。Hysteria2 不能與名稱相近的其他協定形式直接互換，客戶端類型必須符合既有伺服器。認證欄位應完整保留原始格式，並分別確認 SNI 與憑證要求。若既有設定包含額外處理選項，只有在目前 App 確實提供相應功能、且伺服器使用相同設定時才填入，不要依欄位名稱猜測數值。

頻寬相關欄位尤其容易被誤認為測速結果。在適用的壅塞控制方式下，這些欄位可作為傳送行為的參考或限制條件，不代表客戶端保證達到填入的數值。上傳與下載也可能使用不同單位或填寫方式，應以目前欄位說明和既有設定為準。填入很高的數值無法突破接入頻寬與路徑容量，反而可能造成排隊、封包遺失或干擾其他服務。

效能測試須同時觀察互動與傳輸量

持續下載速度很快，不代表瀏覽網頁、語音通話與背景同步都會更順暢。傳輸期間應觀察其他要求的回應，確認是否出現明顯排隊。不要只挑一次最佳結果，也不要拿不同目標、不同網路的數據來比較協定。先建立保守且可重複的基準，再檢查調整頻寬相關參數後，傳輸量與互動是否同時改善，或只有其中一項發生變化。

在 iOS 裝置上，QUIC 處理、較高資料傳輸量與持續無線活動都可能增加耗電，但不能只因使用 UDP 就斷定耗電量固定。同一時間下載更多資料，通常會使裝置更熱；若比較的目標資料量不同，不能據此證明協定效率較低。應分別比較傳輸相同資料量所需時間，以及相同使用時間內的背景活動，並一併考量訊號與螢幕狀態。

若 Wi-Fi 正常，但行動網路始終無法連線，應優先確認兩種網路對 UDP 的實際支援狀況，不要先改動認證資訊。若只有切換網路後短暫異常，觀察重新連線是否恢復；若持續失敗，再檢查記錄中的失敗階段。有些錯誤可能來自路徑報文大小、伺服器資源或入口限制，需向既有伺服器管理者確認。客戶端畫面上的單一逾時訊息，無法獨立指出是哪一層拒絕要求。

適合繼續使用的條件是：既有伺服器明確支援 Hysteria2、目前 App 能完整設定所需參數，而且在目標網路中重複測試後確實穩定。它不是必須取代所有現有設定的選項。若既有 TCP 承載方案已符合需求，而目前網路的 UDP 表現不穩定，保留經過驗證的設定會更實用。選擇結果應隨使用情境改變，而非只看某個協定名稱的新舊。

依情境選擇與分層驗證

先符合設定條件，再比較使用體驗

實際選擇應從使用者已有資訊開始：確認伺服器支援的協定、必填參數與目標服務，再檢查目前網路是否具備所需的 TCP 或 UDP 條件。一般網頁、長時間傳輸、即時 App 與遠端網段存取，對交握、傳輸量、抖動與路由的要求各不相同。沒有單一指標能涵蓋所有服務。先排除欄位不完整或路徑條件不符的組合，再比較剩餘設定，比逐一嘗試所有類型更有效率。

日常瀏覽網頁可優先保留穩定、參數明確且首次開啟回應時間可接受的既有設定；即時服務還應單獨驗證 UDP、抖動與連續性；存取遠端網段則需確認位址範圍及回程路徑。若多種設定都可用，應以相同裝置、網路與目標重複觀察，不要同時修改 DNS、規則與傳輸方式。測試結果只適用於相應情境，不宜延伸成某協定在所有裝置上都適用的結論。

Global Routing 決定要求的路徑

即使協定正確，也可能因規則而走錯路徑。Config 依目前規則決定處理方式；Proxy 可暫時縮小規則因素的影響；Direct 則用來觀察一般網路。切換模式只是診斷方式，不會自動修復問題。若 Proxy 正常、Config 失敗，應優先檢查規則、策略名稱與 DNS，而不是重新填寫密碼。比較完成後，請恢復原本需要的模式，避免暫時測試設定長期影響其他服務。

以下是 Shadowrocket 設定中的簡短規則片段，示範網域、位址與最終規則的排列順序，並非完整設定。規則通常由上而下比對，FINAL 應放在前面的規則之後。此處的 PROXY 與 DIRECT 代表策略，不可將伺服器密碼填在策略欄位；使用命名策略時，也要確認目前設定確實定義了對應名稱。

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

DOMAIN-SUFFIX 用來比對網域後綴，IP-CIDR 用來比對位址範圍，GEOIP 依位址所屬地區資料判斷，FINAL 則接手處理前面未比對到的要求。這些不是協定參數，也不會改變遠端認證。網域規則還需要要求處理流程保留相應的網域資訊；若只看到目標位址，判斷條件可能不同。檢視時應一併考量規則位置、解析結果與要求類型，詳細說明請參閱規則寫法與比對邏輯。

依固定順序縮小問題範圍

第一步確認 App 已取得系統授權，並選取預期連線；第二步確認入口位址能否解析及存取；第三步檢查協定認證與 TLS 是否完成；第四步驗證 DNS；第五步檢查規則與策略；最後再檢查目標 App 本身。若錯誤發生在前一層，先處理該層，不要繼續大量修改後續欄位。Connectivity Test 的結果應與實際網頁、上傳及所需服務一併判斷，單項測試成功不代表所有路徑都正常。

記錄時保留網路類型、Global Routing、所選連線、失敗階段及問題是否可重現，不要記錄可公開識別的認證資訊。長時間傳輸卡住時，應補查 MTU、封包遺失與伺服器狀態；延遲正常但網域解析失敗，可改查DNS 疑難排解；系統連線開關異常則請參閱疑難排解。每次只修改一項，若失敗就還原基準，避免疊加多項未經確認的變更。

最終應留下的是一份能清楚說明的設定，而不只是偶然連線成功的狀態。分開記錄有效參數與適用情境；更新既有訂閱後，重新檢查重要欄位；網路條件改變時，依相同順序再次確認。日常操作可返回入門指南；App Store 購買、已購項目還原與裝置相容性，另請參閱下載與正版驗證頁面，無須在排查協定問題時同時處理購買事宜。