Shadowrocket協定手冊

一、協定選型：先釐清四層參數

協定類型必須與伺服器一致

在 Shadowrocket 中選擇協定，不是在一堆名稱中挑選「最快」的選項。伺服器使用哪種協定，用戶端就必須選擇相符的類型；相同的位址與連接埠，通常不能只更改協定名稱就繼續連線。訂閱已提供類型時，應先保留原有設定。手動透過 Add Server 新增時，請先整理伺服器位址、連接埠、驗證資訊，以及對方明確要求的傳輸與加密參數。資料不完整時，回頭確認現有服務的設定說明，比不斷嘗試不同選項更有效。

理解設定時，可將其分成四層：第一層是位址與連接埠，決定連線目的地；第二層是協定與驗證，決定雙方如何確認身分及交換請求；第三層是傳輸方式，決定請求如何承載；第四層是 TLS 等安全設定，決定連線如何驗證身分並保護傳輸。部分協定會整合其中數層，因此並非每個新增頁面都會顯示所有欄位。沒有某個欄位不代表功能有所缺漏，也不應照搬其他類型的欄位。

速度、耗電與安全是不同指標

速度至少包含建立連線、收到第一個回應及持續傳輸三個環節。握手較少可能縮短首次開啟網頁的等待時間；合適的壅塞控制可能改善長時間傳輸；伺服器負載較低，也可能讓原本普通的協定表現得更穩定。耗電則會受到無線訊號、重傳、背景喚醒及維持連線頻率影響。單憑協定名稱無法推斷固定的耗電排序。在訊號較弱的行動網路中，反覆重新連線的額外耗損，有時比不同加密演算法的差異更明顯。

驗證與加密也要分開看。密碼或 UUID 用來識別使用者，並不代表每一段傳輸都已加密；TLS 加密用戶端到伺服器之間的通道，也不代表伺服器到目標網站的所有連線都由該協定負責保護。瀏覽網站時，仍應留意網站本身的安全連線。實用的選型起點，是確認完整連線路徑的設定範圍，而不是尋找一個能概括所有安全特性的名稱。

協定與分流各自處理哪些問題

Global Routing 決定流量是否交由規則選擇處理路徑；協定則決定交給伺服器的連線如何傳輸。Config 模式依目前設定處理；Proxy 模式將適用流量交由所選代理處理；Direct 模式則直接存取。切換這三種模式不會修正錯誤的密碼或連接埠；更換協定也不會自動修正誤寫的 DIRECT 或 REJECT 規則。診斷時，應分別確認「流量是否經過伺服器」以及「經過伺服器後能否正常通訊」。

建議先儲存可重現問題的原始設定，再逐項調整。伺服器名稱可供辨識，但不能證明實際使用的協定；同樣地，地區標籤不等於實際距離或路由。若匯入前後出現名稱相同但內容不同的項目，應比較欄位，而非只看名稱。協定選項的實際呈現方式，以目前 App 內顯示的項目為準；本頁說明欄位用途，不會將任何伺服器組合視為所有使用者都應啟用的預設值。

二、Shadowsocks：精簡轉送與加密方法

設計著重於精簡的代理封裝

Shadowsocks 的設計著重於加密代理轉送，會將目標位址與應用程式資料封裝後交由伺服器處理。它不是完整的裝置組網協定，也不需要替裝置配置一組隧道內網位址。對用戶端使用者而言，核心資訊通常相當精簡：伺服器位址、連接埠、密碼與加密方法。欄位較少可降低手動輸入的複雜度，但不代表任何欄位都能忽略；尤其是加密方法，必須與伺服器實際設定相符。

早期的串流加密方法與後來的 AEAD 方法，在完整性保護與訊息處理上有所不同。AEAD 同時處理資料機密性與完整性驗證，不能因為名稱相近就與舊方法互換。不同世代的協定也可能對金鑰長度、編碼與驗證結構有不同要求。如果資料提供的是指定格式的金鑰，不應自行改成一般短密碼；若用戶端無法識別該組合，應先確認雙方的支援情況，而不是只挑選名稱看起來相近的選項。

Password 與加密方法應一併核對

Password 是敏感的驗證資訊，複製時應留意前後空格、換行與全形字元。加密方法決定如何使用相應的金鑰材料，兩者都必須與伺服器設定相符。輸入後能儲存項目，只代表表單已接受內容，不表示遠端驗證成功。即使延遲測試有結果，網頁仍無法存取，也不能據此認定密碼一定正確：不同測試路徑可能只檢查部分連線流程，應搭配實際請求與 App 內記錄判斷。

部分現有設定也包含額外的傳輸擴充參數。這些參數是伺服器組合的一部分，不是讓一般項目自動加速的開關。不要將其他項目中的 Host、路徑或擴充選項複製到目前項目，也不要在缺乏說明時任意啟用。若匯入的訂閱項目更新後還原原值，通常表示訂閱仍在管理這些欄位；需要比較時，可另存測試項目，避免手動修改後又被更新覆蓋，失去診斷依據。

TCP、UDP 與實際體驗

Shadowsocks 可涉及 TCP 與 UDP 轉送，但兩種流量能否正常通過，也取決於伺服器能力與中間網路條件。網頁文字能載入，不代表依賴 UDP 的應用程式請求也一定正常；反過來說，某個應用程式沒有聲音或長時間等待，也不能立刻歸因於協定本身。先確認現有服務明確支援哪些流量，再檢查用戶端的相關設定。需要驗證時，應挑選實際使用情境中的少量請求，而非持續執行大量流量測試。

在 iPhone 上，精簡封裝可能讓常見短連線的處理路徑較直接，但加密演算法、裝置硬體、伺服器頻寬與網路封包遺失仍會共同影響結果。不能將「結構簡單」解讀為一定較省電。長時間下載時，螢幕狀態與無線連線常會明顯影響電量；待機時，維持連線與背景網路活動可能更重要。比較兩個既有項目時，應盡量使用相同網路、相同內容並選擇相近時段，避免將條件差異誤認為協定差異。

常見的故障排除順序是先核對位址與連接埠，再逐字檢查加密方法與密碼，接著確認額外傳輸參數及 UDP 條件。若只有部分網站無法使用，應轉而檢查規則、DNS 與目標可達性，不要立刻重建項目。若所有請求都失敗，但直接連線網路正常，請記錄失敗時間與錯誤類別，再檢查遠端監聽及驗證狀態。需要區分節點測試與實際網頁體驗時，可參閱延遲測試與實際體驗說明。

三、VMess 與 VLESS：驗證、傳輸與 TLS

欄位相似不代表協定相同

VMess 將使用者驗證與資料傳輸封裝結合，使用 UUID 等資訊識別使用者，並在協定層處理相應的安全機制與資料格式。VLESS 則採用更精簡的協定設計，將安全通道的工作更多交由 TLS 等外層機制負責。兩者都可能出現 UUID、傳輸方式與 TLS 欄位，因此介面看起來相近，但它們並非同一協定的兩種名稱。伺服器設定為其中一種時，用戶端不能只替換類型並沿用所有參數。

設計精簡不代表任何情況下都更快，也不表示可以省略安全設定。VLESS 本身不負責與 VMess 相同的資料加密工作，實際保護程度取決於整體傳輸組合。查看現有服務的說明時，應將協定名稱、傳輸與安全設定視為整體。例如「使用 VLESS」只是設定的一部分，仍須確認連線入口、驗證識別資料、外層安全方式，以及是否有指定的傳輸參數。不能只憑協定名稱推斷這些欄位的預設值。

UUID、時間與歷史參數

UUID 是驗證識別資料，應完整保留格式與字元，不要將它當成可隨意命名的備註。匯入訂閱後，應先檢查協定類型與識別資料是否正確解析，再查看附加選項。VMess 的驗證流程有時間條件，因此裝置時間明顯偏差可能導致握手失敗；可先確認系統日期與時間正常。不要因為看到網路上的舊欄位說明，就替目前項目加入歷史參數，或認定舊組合適用於所有伺服器。

若項目中出現 Encryption 等欄位，其意義須依所選協定判讀，不能將某個協定的設定值照搬到另一個協定。用戶端允許填寫某個欄位，不代表遠端接受所有設定值。手動新增前，最好列出「明確提供的欄位」與「資料未提及的欄位」；未提及的項目應保留 App 適用的預設狀態，必要時向現有服務確認。隨意填寫會同時引入多個變數，讓後續問題難以追溯原因。

WebSocket、gRPC 與憑證名稱

WebSocket 是一種傳輸承載方式，常會涉及路徑與請求 Host；gRPC 組合可能涉及服務名稱等參數。路徑通常區分大小寫，開頭斜線、結尾字元與跳脫格式也可能影響比對。伺服器位址用來找到連線入口；Host 用於處理相應請求的目標；SNI 則是在 TLS 握手中提供名稱指示。這些值有時相同，有時不同，應依現有設定填寫；不能因為某個網域可以解析，就把它填入所有名稱欄位。

TLS 驗證需要憑證與使用的伺服器名稱相符，且憑證鏈能正常驗證。遇到憑證錯誤時，不應直接忽略驗證，並將此當作一般解決方式。先確認裝置時間、SNI、位址輸入與憑證有效性，再檢查伺服器端設定。ALPN 用於協商應用層協定，其設定值也必須符合實際傳輸組合；隨意新增名稱不會提升相容性，反而可能使握手結果不符合伺服器要求。

在行動網路中，多一層承載會增加部分封裝與握手工作，但實際影響取決於連線重用、伺服器處理能力與網路品質。頻繁開啟短請求與持續傳輸大型檔案，可能呈現不同結果。故障排除時，先讓單一正確項目穩定連線，再比較現有可用組合；若發生「連線成功但頁面未完整載入」，還需檢查 DNS、規則與目標連線，不應只反覆修改 UUID。

四、Trojan：透過 TLS 通道承載代理請求

由 TLS 提供安全通道

Trojan 的設計重點，是透過 TLS 連線傳送驗證資訊與代理請求，運用成熟的 TLS 機制保護用戶端與伺服器之間的通訊。它與其他同樣使用 TLS 的協定並不通用：TLS 只是外層安全通道，通道內仍須遵循 Trojan 的驗證與請求格式。伺服器開放安全網頁連接埠，不代表該連接埠就能作為 Trojan 入口；用戶端完成 TLS 握手，也不代表後續代理驗證已通過。

常見設定需要位址、連接埠、Password，以及符合伺服器設定的 TLS 名稱資訊。Password 是協定驗證憑證，憑證則用來確認連線伺服器的身分，兩者用途不同。密碼正確但憑證驗證失敗，連線仍可能中止；憑證正確但密碼錯誤，也無法正常轉送。了解這一點後，就能將錯誤分成「安全通道未建立」以及「通道建立後驗證或請求失敗」兩類，不必每次都從頭修改所有欄位。

位址、SNI 與憑證鏈的關係

位址可能是網域，也可能是明確提供的 IP 位址；SNI 是 TLS 握手中的名稱指示，通常應使用伺服器設定要求的名稱。如果連線位址使用 IP，但憑證是簽發給網域的，就更應確認名稱驗證條件。不能將「能連線到這個 IP」理解為「任何 SNI 都能使用」。若同一入口承載多項服務，名稱也可能影響伺服器端的處理路徑；填錯後收到的憑證或回應可能完全不同。

憑證鏈驗證涉及受信任的簽發鏈、有效期限與名稱比對。遇到錯誤時，先確認系統時間，再檢查位址與 SNI 是否含有多餘字元，接著確認遠端憑證狀態。不要將長期關閉驗證當作一般使用建議，因為這會削弱對伺服器身分的確認。若現有服務採用特殊的憑證配置，應先釐清其信任設定與風險範圍，再依相關說明處理；不應從無關項目複製一組驗證開關。

握手耗損與行動裝置表現

TLS 握手會在建立連線時增加協商工作與往返等待，但這並非 Trojan 獨有的耗損，其他使用 TLS 的組合也有類似流程。連線重用、工作階段恢復與網路往返時間都會影響實際體驗。短時間內開啟多個網頁，與長時間維持同一連線，表現可能不同。因此，「使用 TLS 就一定比較慢」或「某個連接埠一定比較省電」都不是可靠結論，仍應在相同網路條件下觀察實際任務。

iPhone 從 Wi-Fi 切換到行動網路後，原有傳輸連線可能需要重新建立。若只出現短暫等待，應先觀察是否能自行恢復，不要立即認定密碼失效；若每次切換網路後都持續失敗，則分別檢查目前網路的可達性、網域解析結果與伺服器入口狀態。重新連線次數過多會增加無線通訊與處理耗損；相較於反覆切換進階欄位，穩定的伺服器設定與合理的連線行為通常更值得優先確認。

Trojan 能否轉送 UDP，也取決於伺服器實作、用戶端相關能力與實際設定，不能只憑類型名稱推斷所有應用程式都能正常運作。網頁可用但某項即時通訊失敗時，應記錄該應用程式涉及的網路條件，再檢查 UDP 與規則路徑。若只有單一目標失敗，可參照開關已開啟但無法上網的排查順序，避免把所有問題都歸因於憑證或協定類型。

適合保留 Trojan 的情況，是使用者已擁有欄位完整、憑證設定正常且實際測試穩定的相應入口。若現有資料只提供密碼，卻未說明所需名稱或傳輸組合，應先補齊資訊；不要為了追求對某種協定的印象，主動將其他可用項目改成 Trojan。選型最終應符合伺服器能力、使用需求與維護成本，而非只看某次連線測試的數字。

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

連線代理與瀏覽網頁並非同一層

HTTP 代理源自常見的應用層請求轉送需求。瀏覽安全網站時，用戶端可透過 CONNECT 請求建立通往目標的通道，再由目標網站本身的 TLS 保護網頁通訊。此處有兩種不同的連線關係：裝置到代理伺服器之間是否加密，以及裝置到目標網站的內容是否受到網站本身安全連線的保護。目標網址使用安全連線，不能反過來證明裝置到代理的所有請求與驗證中繼資料也受到同等保護。

若現有入口明確使用 TLS 保護代理連線，應使用 App 內相符的類型與安全設定，而不是只因目標網站是安全網站就自行啟用。一般 HTTP 代理連接埠與安全代理連接埠可能不同，驗證條件也可能不同。伺服器位址、連接埠、使用者名稱與密碼必須一併核對。發生驗證失敗時，檢查憑證資料與伺服器權限；發生握手失敗時，先確認是否誤將一般入口當成 TLS 入口。

SOCKS5 著重於轉交目標連線

SOCKS5 提供通用的代理協商與目標位址表示方式，不需要理解網頁內容。它可使用不同的驗證方式，也定義了 UDP 相關轉送機制，但協定本身不會自動為所有通訊加密。使用者名稱與密碼用於驗證，不代表已建立安全通道。若現有服務要求額外保護，應依實際部署確認；只看到 Password 輸入欄位，無法判定連線具備何種機密性。

SOCKS5 的 UDP 轉送需要伺服器支援，也需要中間網路能承載相應資料。TCP 連線正常但 UDP 請求失敗，是可能出現的邊界情況。若某項任務依賴即時資料或特殊應用程式流量，請先查看現有服務對 UDP 的明確說明，再觀察實際請求。不應反覆更改連接埠來猜測能力，也不應將某次網頁測試成功描述為「所有流量都已驗證通過」。

網域解析位置會影響結果

代理請求可以包含目標網域，也可能在某個階段已轉換為目標 IP；實際 DNS 路徑還會受到應用程式、Shadowrocket 設定與伺服器處理方式共同影響。因此，不能簡單宣稱某種通用代理永遠只在本機解析，或永遠只在遠端解析。若直接使用 IP 可以存取，使用網域卻失敗，應檢查 DNS 回傳結果、規則比對與代理請求中的位址格式，而不是只重新輸入驗證密碼。

企業或自有網路中的代理也可能限制目標連接埠、目標位址或請求方法。驗證成功只是取得相應存取權限的一個步驟，不代表可以存取任意目標。HTTP CONNECT 遭拒絕時，可能是目標連接埠不在允許範圍內；SOCKS5 請求遭拒，也可能是遠端政策限制或目標無法連線。應依錯誤發生階段區分責任：入口無法連線、驗證失敗、目標遭拒、目標連線建立失敗，各自有不同的檢查方向。

在 iPhone 上，這兩類入口適用於現有環境本來就提供相應代理的情況。它們的欄位較常見，但不一定比其他協定更快或更省電。若遠端限制較多，App 可能不斷重試，反而增加等待與通訊耗損。驗證時，先使用權限範圍內的一個實際目標，再檢查需要使用的應用程式類型。不要為了統一項目外觀，將現有加密協定轉換為 HTTP 或 SOCKS5；協定類型不同，伺服器端必須提供相應入口才能運作。

六、WireGuard：金鑰、隧道位址與路由範圍

從代理連線轉為網路層隧道

WireGuard 是為網路層隧道而設計，使用固定的現代密碼學組合，並以公鑰識別對等端身分。相較於處理單一代理請求的協定，它更著重對等端、隧道位址與可承載的網路範圍。因此，設定中除了入口位址，也可能包含本機私鑰、對端公鑰、隧道內位址與路由相關資訊。欄位看起來較多，不代表每項都需要使用者自行決定；通常應依現有伺服器提供的完整設定逐一核對。

WireGuard 主要透過 UDP 傳輸。網路允許一般網頁瀏覽，不代表也允許連線至指定入口的 UDP 通訊；同樣地，某個連接埠的 TCP 探測結果，也不能證明相同編號的 UDP 入口可用。若隧道始終沒有有效握手，應先確認位址、連接埠、網路條件與對端金鑰，而不是將問題歸因於網站規則。伺服器入口能否收到請求，與隧道內能否存取某個目標，是前後兩個不同階段。

Private Key、Public Key 與位址各有用途

Private Key 是本機敏感的身分資料，不應傳送到公開討論區，也不能用對端公鑰取代。Public Key 用於識別對等端，伺服器也必須知道允許連線之用戶端的公鑰。若設定包含預共享金鑰，應依雙方約定填入相同內容，而不是臨時產生一組只在本機使用的值。金鑰格式符合表單要求，只代表編碼可能有效，不表示伺服器已替這個身分設定存取權限。

隧道內位址與連線入口位址不同。入口位址讓裝置透過目前網路找到伺服器；隧道內位址則用於隧道建立後的網路通訊。將伺服器公網位址填入本機隧道位址欄位，通常無法得到正確結果。DNS 位址也應確認是否只能在隧道內存取：若設定要求使用內部解析器，而隧道尚未建立，網域存取失敗可能只是後續症狀，不應先將所有 DNS 項目改成其他值。

Allowed IPs、MTU 與持續連線

Allowed IPs 用來定義與對等端關聯的位址範圍及路由選擇，並非一般所說的網站白名單。範圍太小可能使預期流量未進入相應路徑；範圍太大則可能影響原本應走其他路徑的連線。在 Shadowrocket 中，還需搭配目前的 Global Routing 與設定的實際處理方式理解結果，不要將伺服器端的位址範圍說明，等同於 App 內每一條分流規則。修改前，先釐清需要存取的是內部資源還是一般網際網路目標。

MTU 會影響單一網路封包可承載的大小。封裝後可用空間會變小，部分路徑上的分片或路徑探索異常，可能導致小型請求正常，但大型頁面或長時間傳輸停滯。較低的 MTU 有時能協助定位問題，但設定過低也會增加封包數量與處理耗損，不能一律套用某個「最佳數值」。應以現有設定為基準，一次只做小幅調整，並記錄是否確實改善同一個可重現的請求。

持續連線機制有助於維持某些網路設備中的對應關係，但定期傳送資料也會增加通訊與喚醒耗損。在行動網路中，不應為了「穩定」就一味縮短間隔；若目前連線已穩定，沒有必要盲目增加背景通訊。比較耗電情況時，也要排除 On Demand 條件造成的重複連線行為。WireGuard 簡潔的協定設計有助於控制實作複雜度，但裝置實際耗電仍取決於網路、傳輸量與維持連線的頻率。

這類方案適用於使用者已有明確的對等端與網路範圍設定，尤其是存取自有網路資源的情況。故障排除時先確認握手，再測試隧道內位址，最後檢查網域與應用程式請求；若順序顛倒，可能把路由或解析問題誤判為金鑰錯誤。恢復設定時，請保留原始設定副本；不要為了修復單一目標就直接擴大所有位址範圍，也不要公開包含私鑰的截圖或完整設定。

七、Hysteria2：QUIC、頻寬與弱網取捨

為不穩定的網路連線而設計的傳輸方式

Hysteria2 以 QUIC 建構代理傳輸，設計上著重於高延遲、封包遺失等條件下的資料傳遞。QUIC 通常運作於 UDP 之上，並整合安全連線與多路資料流機制。應區分兩件事：協定針對某些網路問題進行設計，不代表在所有網路中都更快；用戶端提供此類型，也不代表目前網路一定允許連線至相應的 UDP 入口。選用前必須先確認現有伺服器提供的確實是 Hysteria2，而非名稱相近的其他入口。

以 QUIC 為基礎的承載方式，可避免某些將多個邏輯資料流簡單疊加在同一可靠位元組流上的問題，但資料仍共用底層路徑與可用頻寬。嚴重封包遺失、伺服器負載過高或網路對 UDP 的處理不佳時，體驗仍可能下降。不能將多路機制理解為「封包遺失不影響速度」，也不能直接把一次大型檔案測試的結果套用到小型請求、即時通訊或背景同步等不同任務。

驗證與 TLS 仍須逐項確認

常見設定包含入口位址、連接埠、驗證資訊與 TLS 名稱相關設定。驗證欄位用於確認使用者；TLS 則負責安全通道與身分驗證，兩者的分工同樣需要分別理解。發生驗證錯誤時，先核對現有服務提供的驗證內容；發生憑證或名稱錯誤時，檢查 SNI、系統時間與遠端憑證。不要因為協定使用 QUIC，就認為可以略過憑證驗證或任意選擇名稱。

部分現有設定會要求特定的混淆參數或連接埠相關設定，這些都是雙方配合的條件。若只在用戶端啟用，而伺服器端未採用相同設定，可能無法正常通訊。匯入後應先保留訂閱解析出的組合；手動新增則依明確說明填寫。若資料未提及某項擴充設定，就不要為了追求更複雜的設定而自行加入。介面提供進階選項代表可供設定，不表示所有使用者都必須啟用。

頻寬欄位不代表實測速度

某些設定模式會使用上行、下行頻寬資訊來調整傳送行為。填入的數值應依據欄位說明、實際網路條件與現有服務要求判讀，而不是照抄行動網路圖示所暗示的理論速率。填入更大的數值不會憑空增加連線容量；估計過高，可能讓連線更容易壅塞或丟包，影響網頁回應及其他應用程式。估計過低，則可能限制原本可用的吞吐量，應透過可重現的任務逐步觀察。

也要留意單位。位元速率與位元組速率不同，寬頻標示速率也不能直接與 App 顯示的下載速度逐字比較。若現有設定使用自動調整方式，不應只為了「最佳化」就改成手動輸入頻寬。若確實需要手動設定，也應考量上行能力：下載仍會產生確認與控制資訊；上行被其他應用程式占滿時，下行表現也可能變差。測試期間盡量暫停無關的大量傳輸工作，避免錯誤歸因。

在 iPhone 上，訊號微弱時追求高吞吐量，可能伴隨更多無線活動、處理工作與重傳；裝置發熱或電量變化不能只歸因於協定名稱。短時間測試也可能受到螢幕亮度、充電狀態與背景工作影響。若主要需求是日常瀏覽網頁與傳送訊息，應優先比較回應是否穩定及切換網路後的恢復情況，而非只追求單次峰值；若主要需求是持續傳輸，則還要觀察長時間速率、目標伺服器限制與耗電情況。

遇到連線逾時，先檢查目前網路能否連線至該 UDP 入口，再確認位址、連接埠與驗證資訊；若連線後只有部分內容卡住，再檢查頻寬估計、路徑封包大小、DNS 與規則。網路切換可能改變實際路徑條件，即使底層機制具備相關能力，也不能保證所有現有請求都不會中斷。請記錄問題發生在建立連線、切換網路還是長時間傳輸階段，再依具體症狀決定下一步，而不是持續調高頻寬數值。

八、依情境選擇，並以分層方式驗證

先依現有條件縮小選項範圍

若使用者只有一個完整可用的入口，實際任務是正確匯入與驗證，而非重新比較所有協定。若現有服務提供多種組合，可先排除目前網路無法承載的類型，再比較實際使用情境。經常在 Wi-Fi 與行動網路間切換時，重點觀察恢復時間與失敗次數；存取自有網路資源時，重點檢查位址範圍、DNS 與權限；大量短請求情境則留意連線建立與首次回應，持續傳輸情境則關注穩定吞吐量。

測試時盡量使用相同裝置、相同網路與相同目標內容，分別觀察首次連線、再次存取及一段時間後的表現。一次只更換一個項目或一項參數，不要同時改動協定、DNS 與 Global Routing。Connectivity Test 可用於初步判斷入口狀態，但測試數值不等於完整網頁載入時間，也無法代表所有目標。詳細說明請見延遲、地區與協定類型的取捨。

使用最少規則確認流量走向

目前 Global Routing 設為 Config 時，規則順序會影響請求的最終走向。以下是語法說明，並非可直接取代現有設定的完整方案；其中 example.com 僅供示例，PROXY 所指的實際策略應與目前設定相符。規則通常依序比對，FINAL 負責處理未符合前面規則的流量。即使伺服器參數完全正確，若目標先符合 DIRECT 或 REJECT，實際行為仍可能與預期不同。

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

DOMAIN-SUFFIX 依網域後綴比對，IP-CIDR 使用位址範圍，GEOIP 則依據相應的 IP 地理位置資料庫判斷，而非依網站使用的語言判斷。DNS 結果、目標是否以網域形式出現，以及前置規則，都可能影響最後符合的規則。不要將示例中的地區規則視為每個人都應採用的設定。測試協定前，先確認目標應走哪條路徑，再查看記錄中的實際處理方式，避免測到直連後誤以為是在比較兩種協定。

從入口到目標逐層排查

第一層檢查裝置目前的網路是否正常，再確認入口網域、位址與連接埠；第二層確認協定、驗證與傳輸欄位；第三層檢查 TLS 名稱、憑證與時間條件；第四層確認 Global Routing、規則與 DNS；最後檢查目標本身及遠端存取權限。若只在某個網路中失敗，優先比較該網路的可達性與傳輸條件；若所有網路都失敗，則應優先檢查入口狀態與共用設定，而不是分別修改裝置上的每一項設定。

訂閱更新後項目消失或欄位變更時，先判斷問題發生於匯入解析階段，還是既有項目的連線階段。清單空白並非加密方法選錯的典型跡象，也不應透過修改 TLS 選項來解決。可參閱訂閱匯入失敗或清單空白的自我檢查方式，確認連結完整性、現有服務狀態與更新時間。訂閱網址可能包含敏感憑證，分享問題時請勿原樣公開。

保留可還原的設定與有效記錄

每次測試只需記錄網路類型、協定組合、變更欄位與結果，不必公開完整驗證資料。請勿將私鑰、密碼、UUID 或完整訂閱網址放入截圖；也應確認錯誤訊息是否含有敏感內容。無效的變更應及時還原，避免留下多項重疊設定。需要了解操作流程時，請閱讀快速入門教學；需要依問題查找資訊時，請閱讀常見問題；介面用語與關鍵字可在術語表繼續查閱。

最終選擇標準是：符合現有伺服器設定、目前網路可穩定承載、所需應用程式流量能正確處理，且參數易於維護。不要為了單次測試領先而犧牲憑證驗證，也不要將更複雜的組合視為必然升級。先建立可重現、可還原的正確基準，再針對具體瓶頸調整，才能分辨協定設計的取捨與網路環境造成的差異。