Shadowrocket 協定手冊

01 · 協定選擇與連線分層

類型必須與伺服器端一致

選擇協定首先要確認相容性，而不是比較速度排名。同一個伺服器位址可以監聽不同連接埠，每個連接埠背後可能使用不同協定；位址相同，不代表認證和傳輸方式可以互換。在 Add Server 選擇 Type 時，應以現有伺服器說明或訂閱解析結果為準。把 Shadowsocks 改成 Trojan，不會讓原有服務自動支援 TLS；把 VMess 的認證資料填入 VLESS，也無法因此建立連線。如果訂閱內容與文字說明有出入，先確認兩者是否指向同一個入口，再調整欄位。

連線可分成四層來理解：最外層是目前的 Wi-Fi 或行動網路能否連到伺服器；接著是 TCP、UDP 或 QUIC 等承載方式；再來是協定認證、加密與選用的 TLS；最後才是目標請求與規則策略。逾時可能發生在任何一層，不能只憑提示就認定密碼錯誤。例如連接埠無法連線時，流程還沒進入認證；憑證不符時，也未必已送出目標請求。分層檢查能縮小排查範圍，避免同時修改多個無關選項。

在相同條件下比較速度與耗電

連線速度通常包含建立連線所需時間、首次回應時間與持續傳輸量三項指標。瀏覽短網頁時，DNS、交握與首次回應的差異較明顯；傳輸大型檔案則更受連線頻寬、壅塞控制和伺服器負載影響。一次 Connectivity Test 無法代表所有 App 的實際體驗，也不能直接換算成下載速度。比較多個現有入口時，應使用同一部裝置、同一個網路、相同測試目標，並選在相近時段；分別記錄冷啟動與連線建立後的表現。

在 iPhone 與 iPad 上，耗電也不能只看協定名稱。加密運算會使用處理器資源，但無線模組持續運作、封包遺失後重傳、頻繁交握及過於密集的保活，同樣可能占去更多電力。訊號較弱時，重複傳送資料對耗電的影響可能大於演算法本身。測量時應讓螢幕亮度、前景 App 與測試時間維持相近，避免把螢幕或背景同步的耗電算到協定上。低延遲與低耗電不一定能同時達成，應先確認實際使用需求。

如果現有伺服器只提供一種類型，就不需要為了「選擇協定」而改填另一種。正確做法是使用相容的類型，並檢查必填欄位；只有使用者自己的伺服器確實設定了多個入口，比較才有意義。傳輸與安全選項也取決於伺服器的實際設定和目前 App 的支援情況；介面沒有相應選項時，不要把名稱相似的項目當成可互換的替代方案。請保留原始說明，確認目前的用戶端能否完整表達這些參數。

02 · Shadowsocks 的加密與轉送

精簡轉送架構的設計取捨

Shadowsocks 的設計背景，是提供較輕量的加密代理轉送，將目標位址與 App 資料封裝後交由遠端處理。與完整的網路層隧道不同，它著重於代理連線，不要求為裝置配置整套隧道位址。架構較精簡，有利於部署與排錯；但也代表不能只憑「加密代理」四個字，就推斷所有安全特性。實際使用的加密方式、認證強度、UDP 行為和額外傳輸需求，都必須依伺服器設定分別確認。

在 Shadowrocket 手動加入時，先選擇 Shadowsocks，再輸入伺服器位址與連接埠，接著核對 Method 和 Password。Method 是協定相容條件，不是可以任意挑選的效能模式；雙方採用不同方式時，即使密碼相同，也無法正確解析資料。複製 Password 時，請檢查前後空格、換行與大小寫。不要把訂閱備註當成密碼，也不要把分享資訊中編碼後的整段內容直接貼到 Password 欄位。完整分享資訊應使用相應的匯入方式處理。

AEAD、相容性與額外參數

採用 AEAD 的方式會同時提供加密與資料完整性驗證，接收端能偵測資料遭到竄改或無法正確認證的情況。這不同於單純「讓內容無法讀取」，但也不應因此把所有名稱相似的演算法視為相容。不同協定變體可能對金鑰、工作階段與使用者資訊有額外要求。應將伺服器提供的類型、演算法名稱與憑證視為一組，完整保留；若訂閱包含額外欄位，優先查閱原始設定說明，不要為了讓表單通過而刪除欄位。

有些現有設定還包含額外的傳輸元件、主機名稱或路徑。這些不是 Shadowsocks 通用的必填項目，只有伺服器實際啟用時才需要配合設定。額外元件可能改變外層資料格式，也會增加交握或設定的複雜度；一般入口不應憑空啟用。遇到「匯入成功但連線失敗」時，請檢查匯入是否完整保留這些設定，以及目前的用戶端是否支援該組合。畫面上出現一筆記錄，只代表內容已解析，不代表雙方已完成協定交涉。

TCP、UDP 與 iOS 上的表現

TCP 請求成功，但依賴 UDP 的 App 失敗，是需要另外處理的情況。原因可能是伺服器未啟用 UDP 轉送、網路路徑不允許 UDP，或目前規則未將相關流量交給預期的策略。此時反覆修改 Password 通常沒有幫助。先用一般網頁確認基本 TCP 轉送，再檢查 App 實際使用的流量類型與用戶端記錄。不要因為一次網頁連線成功，就認定所有網路功能都正常；也不要只憑一次失敗，就判定整個協定不適用。

在 iPhone 與 iPad 上，額外層級較少通常有助於降低設定複雜度；但實際傳輸量仍取決於裝置處理所選演算法的效率、伺服器效能與網路封包遺失情況。不同裝置對不同演算法的表現可能各異，不能直接套用另一部裝置的結果。若持續傳輸穩定，但首次連線較慢，應優先檢查 DNS 和建立連線的流程；若只在高負載時降速，再觀察處理器負載與連線限制。變更演算法必須同時獲得伺服器支援，不能只修改用戶端。

建議保留一筆可正常連線的記錄，再複製一份用來測試單一變更。先核對 Address、Port、Method、Password，再檢查確實存在的額外選項，最後驗證 UDP 與規則路徑。訂閱更新後若出現問題，可比較更新前後的類型與關鍵欄位，但不要公開包含憑證的完整記錄。若要了解匯入與更新操作，請前往Subscribe 更新說明；本章只說明協定欄位與判斷順序，不提供伺服器參數來源。

03 · VMess 與 VLESS 的認證和傳輸

區分協定身分與傳輸方式

VMess 與 VLESS 都常以 UUID 作為使用者識別碼，但兩者並非只要更改 Type 就能互換。VMess 將認證與資料保護納入自身的協定設計，部分認證流程也依賴時間範圍，因此系統時間明顯不準時可能會連線失敗。VLESS 的協定結構則較精簡，基礎協定本身不負責載荷加密，通常需要搭配部署中的安全層來保護資料。兩者的取捨在於架構與職責劃分不同，不應簡化成某個名稱必然比較快。

UUID 應從使用者現有的伺服器設定中取得，並完整保留所有字元與分隔符號。隨機產生一組格式正確的 UUID，不代表伺服器會認可這個使用者。即使伺服器位址、連接埠與 UUID 都正確，也還沒完成所有核對：傳輸方式、TLS、Server Name、路徑等仍可能決定能否建立連線。訂閱中若有多個相似入口，不要將一筆記錄的 UUID 與另一筆記錄的路徑拼在一起使用，除非伺服器說明明確指出兩者屬於同一組設定。

TCP、WebSocket 與 gRPC 屬於不同層次

協定決定如何表達認證與目標請求，傳輸方式則決定這些資料如何承載。使用 WebSocket 時，用戶端必須完成相應的交握，Path 和 Host 等參數也必須符合伺服器要求；使用 gRPC 時，則應核對相應的服務名稱與 TLS 設定。一般 TCP 入口不需要憑空填入 WebSocket Path。看到相同的網域，不代表這些傳輸方式共用同一個接入點；反向代理可能依據路徑、主機名稱或服務名稱，將請求轉送至不同後端。

Host、Server Name 與伺服器位址也不能混為一談。伺服器位址決定連線目標；TLS 的 Server Name 用於交握時的名稱指示與憑證比對；WebSocket 的 Host 則屬於應用層請求資訊。某些部署設定會讓三者相同，但那只是設定結果，不代表所有情況都必須如此。依照說明分別填寫，才能區分「已連到正確伺服器，卻進入錯誤後端」與「根本無法連上伺服器」。不要用任意替換名稱的方式掩蓋某一層的錯誤。

安全選項與效能限制

VMess 的 Security 等欄位屬於自身的協定設定，不能等同於 TLS 開關；VLESS 的部分安全或流量控制擴充，也只適用於特定部署組合。伺服器未標示支援時，不應只憑名稱就勾選擴充選項。匯入後遇到不熟悉的欄位，先核對目前 App 中相應的設定與伺服器要求，並保留原始記錄。刪除看不懂的參數，可能會讓完整設定變得不相容；填入一個「常見值」，也不比保留原始資訊可靠。

增加 TLS 或應用層傳輸通常會增加交握與封裝，但不能直接推論最終速度一定較慢。持續連線可以分攤交握成本，網路中的中間設備也會影響不同傳輸方式的實際表現。短連線密集的情境較容易顯現建立連線的成本；長時間傳輸則更受壅塞和伺服器負載影響。在 iOS 上，反覆失敗並重新連線可能比維持穩定連線更耗電，因此應先修正參數不一致，再考慮減少某個封裝層。

排錯時，先檢查裝置是否使用自動設定日期與時間，再確認位址和連接埠是否可連線；接著依序核對 UUID、協定安全欄位、傳輸方式、TLS、名稱與路徑。如果 TLS 已成功，但請求仍失敗，應轉而檢查認證與後端路由，而不是繼續關閉憑證驗證。若只在訂閱更新後失效，請比對傳輸欄位是否變更；若同一組的所有記錄同時失效，先排查目前網路與共用的網域解析。也可搭配節點逾時與連線失敗筆記所列的檢查順序。

04 · Trojan、HTTP 與 SOCKS5 的適用範圍

Trojan：在 TLS 連線內進行認證

Trojan 的設計是在 TLS 連線內處理代理認證與請求，利用成熟的 TLS 機制保護傳輸。設定時，Password 與 TLS 參數各自負責不同功能：密碼供伺服器識別使用者，憑證與名稱驗證則用於確認安全連線所指向的身分。密碼正確，不代表可以忽略憑證；憑證有效，也不代表帳號一定通過認證。先理解這兩條獨立的檢查流程，才能分別處理「交握失敗」與「認證失敗」。

Server Name 應符合伺服器憑證和部署要求，不要任意填入熟悉的網域。即使伺服器位址使用 IP，伺服器仍可能要求在 TLS 交握時指定網域；此時連線目標與驗證名稱不同，是正常的設定方式，但具體資料必須來自現有伺服器說明。若出現憑證錯誤，請檢查裝置時間、名稱拼字、憑證有效期限與憑證鏈。忽略驗證雖然能隱藏錯誤提示，卻不能證明已連到預期的伺服器，也不應當作長期解決方式。

HTTP：代理請求不等於全程加密

HTTP 代理最初是為轉送應用層請求而設計，連線到 HTTPS 目標時，通常透過 CONNECT 建立通往目標的位元組通道。此處必須區分「目標網站使用 HTTPS」與「裝置到代理入口使用 TLS」：前者保護網站連線，後者則保護通往代理的這一段，兩者不是同一個開關。如果入口本身使用未加密的 HTTP，就不能因為目標網址以 HTTPS 開頭，便推論代理認證資訊與入口中繼資料也受到同等保護。

設定 HTTP 類型的入口時，應核對伺服器位址、連接埠、是否啟用 TLS，以及是否要求 Username 和 Password。不要把網站登入帳號當成代理認證帳號，也不要任意把 URL 中代表路徑的部分填入位址欄。伺服器若只提供一般 HTTP 代理，不要在用戶端開啟 TLS，期待連線自動升級。反過來說，要求 TLS 的入口若使用未加密連線，通常會在初期就失敗。雙方必須以相同方式解讀第一批傳送的位元組。

SOCKS5：彈性轉送，但不提供載荷加密

SOCKS5 定義了目標位址表示法、認證交涉與轉送請求等機制，可表示網域或 IP 目標，部分部署也支援 UDP。它本身不提供通用的載荷加密保護；使用 Username 與 Password 認證，也不等於建立了加密通道。選擇這種類型時，應先確認現有網路環境提供哪些保護，以及入口是否另有安全封裝。不能因為「設定了密碼」就認定「資料已加密」，也不能將 App 目標本身的安全性套用到所有傳輸內容。

SOCKS5 的 UDP 功能需要伺服器、網路路徑與用戶端共同配合。伺服器允許建立 TCP 連線，不代表也支援 UDP 轉送；網域是在本機還是遠端解析，則取決於實際請求形式與用戶端的 DNS 設定。若網域連線失敗，但同一目標的 IP 位址可連線，應先檢查解析路徑；若一般網頁正常，只有即時 App 異常，再檢查 UDP 與規則。證據不足時，不要將所有差異都歸因於認證方式。

在 iPhone 與 iPad 上比較這三類協定時，仍應以現有入口為前提。Trojan 的 TLS 交握、HTTP 的連線重複使用、SOCKS5 的轉送路徑都可能影響首次回應，但持續傳輸速度主要由實際連線決定。若情境需要明確的傳輸保護，先查明入口使用的安全層，不要只看協定標籤；若特定 App 需要 UDP，先驗證端到端是否支援。使用者若只有一組可用參數，正確填寫比切換到不相容的類型更重要。

05 · WireGuard 的金鑰、位址與 MTU

網路層隧道與代理入口的差異

WireGuard 的設計以精簡的網路層隧道為核心，使用公私鑰識別對端，並透過 UDP 傳送受保護的資料。與主要轉送 App 連線的代理協定不同，它還涉及隧道內的位址與路由範圍。因此，設定不能只理解成「伺服器加密碼」：裝置端需要自己的金鑰身分，對端也必須登記相應的公開金鑰，雙方還要確認哪些位址應經由隧道傳送。認證成功與目標可達之間，還需要檢查位址配置和路由規劃。

PrivateKey 是目前端點的私密金鑰，應保留在可信任的本機設定中；對端設定中的 PublicKey 通常是遠端的公開金鑰，不是將本機私密金鑰複製過去。本機私密金鑰所對應的公開金鑰必須獲得遠端允許；遠端公開金鑰則用於確認連線對象。若雙方公開金鑰填反，或伺服器未登記本機身分，即使位址和連接埠正確，也無法建立有效工作階段。選用的 PresharedKey 是額外的共享資料，只有雙方明確設定時才填入，不能憑空只在一端產生一組值。

Address、Endpoint 與路由範圍

Address 是分配給本端、位於隧道內的位址，通常會帶有前綴長度；Endpoint 則是遠端在外層網路中可連線的位址與連接埠。兩者所處層次不同，不能把公網伺服器位址直接當成隧道內位址。若現有設定包含 IPv4 與 IPv6 的 Address，應分別保留各自的前綴。任意更換隧道位址，可能與其他端點衝突，或超出遠端允許的範圍，造成看似已完成交握，實際資料卻無法依預期返回。

在 WireGuard 架構中，AllowedIPs 同時關聯允許的隧道位址範圍與對端選擇；用戶端的實際呈現方式請以介面為準。在 Shadowrocket 中，還須區分端點內部的路由範圍與 App 整體的規則策略：前者決定隧道如何處理位址，後者則決定哪些請求會交由此策略處理。遠端允許較大的位址範圍，不代表裝置的所有請求都已進入隧道。請先確認規則已選中該請求，再檢查隧道內的回程與目標路由。

MTU、DNS 與保活的連帶影響

MTU 表示相應介面可承載的封包大小上限。隧道封裝會增加額外負擔；如果網路路徑無法正確處理較大的封包，可能會出現小型請求成功、大型回應卡住的情況。此時可適度降低 MTU 作為有記錄的測試，但不要把某個數值當成適用所有網路的標準答案。請先記下原始值，每次只調整一個級距，再以相同目標重新測試；數值過低會增加封包數量與處理成本。如果問題根源是 DNS 或目標路由，調整 MTU 通常無法解決。

DNS 設定用來決定網域應解析為哪個位址，不會自動修正錯誤的隧道路由。如果解析伺服器位於隧道內，必須先確保通往它的路徑可用，否則可能出現「網域連線失敗，但部分 IP 可連線」的情況。保活則是在需要時維持 NAT 對應，不是提升頻寬的選項。保活過於頻繁，會讓行動裝置更常喚醒無線模組；間隔過長，閒置後的首次請求又可能需要等待路徑重新建立。設定應以網路環境與伺服器建議為準。

檢查 WireGuard 時，可分開判斷交握、收發計數與實際請求。有交握表示當時至少能與對端身分及外層路徑正常配合，不代表隧道內的目標已可連線；若傳送計數增加、接收計數沒有增加，應繼續檢查遠端路由、允許的位址與回程。Wi-Fi 切換到行動網路後，連線短暫恢復也不能立即歸因於金鑰。欄位關係與調整範圍詳見WireGuard 設定參數筆記；操作前請先備份目前可用的設定。

06 · Hysteria2 的 QUIC 與頻寬參數

以 UDP 承載的連線架構

Hysteria2 以 QUIC 建構代理傳輸。QUIC 在 UDP 之上實作安全交握、連線管理與可靠資料流，因此「外層使用 UDP」不代表內部所有資料都以不可靠方式傳送。其設計取捨之一，是在同一套傳輸架構內處理連線與壅塞。在部分封包遺失或延遲變化的環境中，表現可能不同於以 TCP 承載的傳輸；但最終結果仍受連線策略、伺服器頻寬與實作設定影響，不能只憑名稱保證速度。

使用 Hysteria2 的前提是使用者現有的伺服器確實提供此協定。不能直接沿用其他類型的位址與密碼，也不能假設名稱相似的不同世代協定可以互換。先核對 Type、伺服器位址與 UDP 連接埠，再確認認證資料和 TLS 參數。部分部署還包含額外的混淆設定，只有伺服器實際啟用時才需要配合。漏掉這些欄位，可能讓資料在進入正常交握前就遭到丟棄，表現為持續逾時，卻沒有明確的認證錯誤。

UDP 路徑比網頁連線狀態更關鍵

目前的 Wi-Fi 能開啟一般網頁，不代表它允許連線到目標連接埠的 UDP。有些網路對 UDP 的限制與 TCP 不同，部分路徑也會以不同方式處理持續的 UDP 流量。如果 Hysteria2 在一個網路逾時，但同一組參數在另一個網路可用，應先比較外層 UDP 的可達性，而不是立即更換密碼。測試時必須使用同一筆記錄，避免把網路與參數變動混在一起，以免無法判斷真正造成影響的因素。

此處的 TLS 同樣需要正確的名稱與憑證驗證。Address 決定資料要送往何處；Server Name 則關係到交握時的名稱指示與身分確認。如果伺服器憑證只涵蓋網域，使用 IP 連線時也可能需要提供相應名稱；具體值必須依據現有設定確認。裝置日期明顯錯誤、網域指向錯誤入口或憑證鏈不完整，都可能造成交握問題。QUIC 不會自動略過這些安全條件，關閉驗證也無法證明其他參數正確。

頻寬設定不是加速開關

頻寬相關欄位應依目前的實作、伺服器設定與使用者實際網路來理解。某些壅塞控制模式會參考頻寬資訊決定傳送方式；填入明顯超出可用連線能力的數值，可能增加排隊、封包遺失與重傳，反而降低互動回應速度。不要把訂閱備註中的宣傳速度直接當成準確參數，也不要只依家用網路的標示頻寬來填寫行動網路環境。單位同樣重要：位元每秒與位元組每秒不可混用；上傳與下載方向也應依欄位說明逐項確認。

如果持續下載速度很快，但瀏覽網頁時反而反應遲緩，原因可能是壅塞時排隊時間過長，不一定是 DNS 太慢。可以先停止大量傳輸，再重新測試短請求，觀察差異是否消失；接著依現有伺服器建議檢查頻寬與壅塞設定。耗電方面，較高的傳輸量會增加無線模組與處理器的負載；連線品質不佳時反覆傳送，也會提高耗電。比較時應觀察完成相同工作的總時間與總耗電，而不只是瞬間電量變化或單一的最高速度數值。

行動網路切換後，QUIC 的連線識別與路徑機制不代表所有 App 工作階段都一定能維持。能否恢復還取決於用戶端處理方式、遠端狀態、NAT 對應與 App 本身的逾時設定。驗證時應記錄切換前後的連線結果，不要只看圖示是否仍顯示已連線。如果只有此類型在某個網路失敗，而其他現有入口可用，請保留這項對照結果；若所有類型都失敗，應優先檢查基本網路、解析與整體路由，不要只針對 QUIC 設定排查。

07 · 參數欄位與分層排錯

保留原始資料，再檢查匯入結果

匯入訂閱或分享資訊後，應分別確認「解析成功」與「連線可用」。前者只表示用戶端識別了資料格式；後者則需要網路、認證、安全層與轉送功能共同正常運作。先確認 Type 是否符合來源，再檢查位址、連接埠及重要憑證，最後檢查傳輸擴充。若發現欄位缺漏，不要立刻填入常見值，應回到使用者現有的設定核對。遇到不支援的組合時，修改顯示名稱或重複匯入都無法創造相容性。

最常見的混淆，是把幾種不同的「名稱」當成同一項。備註只供本機辨識；Address 決定實際連線目標；Server Name 用於 TLS；Host 可能影響應用層入口；Path 或服務名稱則指向特定傳輸後端。這些值在同一個入口中可能相同，也可能不同。排錯記錄應分別寫明各自用途，而不只是寫「網域正確」。如果伺服器有多個後端，即使已透過同一個位址建立 TCP 連線，名稱或路徑錯誤仍可能讓請求進入錯誤的服務。

依故障範圍縮小問題

如果只有單筆記錄失敗，優先檢查該記錄特有的位址、憑證與傳輸參數；如果同一組記錄都失敗，檢查它們共用的網域、認證來源與伺服器狀態；如果所有記錄只在一個網路失敗，換用另一個已知可用的網路進行比較。如果所有網路都失敗，還應檢查目前的 Config、裝置時間與系統連線狀態。依照這些分支逐步排查，比反覆點選測試更有效，因為每一步都能判斷問題來自單一入口、共用設定或裝置環境。

逾時表示在等待期限內沒有取得所需結果，不能直接判定密碼錯誤；連線遭拒可能表示目標連接埠沒有相應的監聽服務，也可能是路徑設備所致；憑證錯誤指向 TLS 身分驗證；認證錯誤則應回頭檢查協定憑證。仍須依上下文解讀具體提示，不要把所有英文錯誤都歸為同一類。檢視記錄時，保留錯誤發生前的階段資訊；對外說明只需提供類型、網路條件與已隱去敏感資訊的錯誤內容，不要公開完整憑證。

區分測試成功與實際使用正常

Connectivity Test 的結果取決於測試方式與目標，不能證明每個網站、每個 UDP App 或每條規則都正常。如果測試成功但無法瀏覽，應檢查實際網域的 DNS、命中的策略與目標回應；如果只有某個 App 失敗，請確認它是否連線到不同網域或使用不同傳輸方式。即使「連線開關已開啟」，也只代表系統隧道已啟用，不能取代目標請求的驗證。至少應對一個已知目標送出實際請求，再判斷設定是否可用。

排查 DNS 時，特別要留意相依關係：如果伺服器位址本身是網域，通常必須先取得有效解析，才能建立連線；目標網站的解析則可能受到目前 Config 影響。若將解析服務設在只有透過隧道才能連線的位置，卻沒有可用的初始解析路徑，就可能形成循環相依。先確認伺服器網域能正確解析，再檢查目標網域與請求策略。不要一次更換所有 DNS 選項，具體操作請參閱DNS 設定教學。

最後建立一筆精簡的重測記錄：目前網路、協定類型、實際測試目標、錯誤階段，以及這次唯一修改的欄位。每次修改後都以相同目標重測，確認結果後再決定保留或還原。訂閱整體取得失敗與單一入口認證失敗是不同流程；前者應檢查訂閱網址是否有效及取得結果，詳見訂閱失敗檢查。完成參數檢查後，如果仍只有特定請求異常，請進入下一章檢查規則與連線觸發。

08 · Global Routing、規則與 On Demand

協定可用後，再確認策略選擇

協定決定如何連線到遠端；Global Routing 則決定請求採用哪種處理方式，兩者不能互相取代。Config 會依目前設定中的規則選擇策略；確認用途後，可暫時使用 Proxy 縮小規則變因；Direct 則代表直接連線。排錯時應先記下目前的連線模式，再確認請求實際走向，避免在 Direct 模式下測試遠端協定後得到錯誤結論。測試結束後請還原原本的 Config，否則臨時調整會影響後續比較，也可能改變區域網路的存取行為。

規則通常依順序比對，較具體的條件應放在適當位置；若前面的規則都未符合，則由 FINAL 作為後備處理。DOMAIN-SUFFIX 比對網域後綴，IP-CIDR 比對位址範圍，GEOIP 則依據相應的地理資料判斷位址；三者的判斷對象不同，不能只因目標網站名稱相似就互相替換。PROXY、DIRECT、REJECT 代表不同的處理結果；規則指向的策略名稱也必須能在目前設定中正確解析。實際結果應搭配請求記錄確認，不能只依清單中的位置推斷。

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

這段 .conf 範例只展示規則語法與順序，不是完整設定檔。example.com 是說明用的網域；私有位址範圍的 DIRECT 代表直接連線；GEOIP 的結果取決於相應資料；最後由 FINAL 處理未符合的請求。套用至自己的 Config 前，應確認現有策略、DNS 與區域網路範圍；不要直接用範例覆蓋整份設定。也不要把範例中的地區規則當成適用所有人的建議，更不要以為更換規則就能修正錯誤的 Password 或 TLS 名稱。

On Demand 只負責何時觸發連線

On Demand 會依網路或其他已設定條件觸發系統連線行為，但不會決定每個請求最後使用哪種協定。設定 Wi-Fi、Cellular 與網域條件時，需依目前介面與規則功能調整；有些條件影響是否建立連線，有些判斷也與解析環境有關。設定前先確認手動連線已穩定，再加入觸發條件。若手動連線本身就失敗，自動觸發只會重複同一個問題，也會讓故障現象更難判斷。

依 Wi-Fi 條件設定時，應核對 SSID 的實際字串，留意名稱相似但並非同一個網路的情況；設定行動網路條件時，則應分別測試從 Wi-Fi 切換至行動網路，以及切回 Wi-Fi 的行為。多個條件並存時，請檢查優先順序與後備動作，避免範圍過廣的條件先符合，導致後續的特定條件無法執行。手動關閉後又自動重新連線，可能是條件再次符合，不一定是開關故障。請先檢查 On Demand 規則，再判斷系統連線狀態。

依使用情境驗證，而非按名稱排名

日常瀏覽應留意首次回應、解析穩定度與閒置後恢復；持續傳輸應關注有效傳輸量、排隊與重傳；依賴 UDP 的 App 應先確認端到端轉送能力；存取隧道內資源則更應檢查 WireGuard 位址與路由。若有多個相容入口，依這些需求分別測試，比宣稱某個協定「全面更快」更有參考價值。同一協定在不同伺服器上的差異，可能比不同協定名稱之間的差異更大；比較時應說明哪些變因無法控制。

驗證耗電時也應貼近實際使用情境：讓兩組現有設定完成相近的資料量並使用相近時間，分別觀察穩定的前景使用與閒置狀態。背景同步、訊號強度與螢幕使用時間都會影響結果，應一併記錄。若閒置時耗電明顯增加，請檢查是否頻繁失敗重連、保活過於密集，或 On Demand 條件反覆切換；若只在持續傳輸時增加，則結合傳輸量與處理器負載判斷。不要只根據一次系統耗電統計，就推論出固定的協定耗電排名。

最後應確認三項結果：記錄中的 Type 與伺服器端一致、實際請求符合預期策略，以及網路切換後的連線行為符合 On Demand 設定。確認完成後先儲存可用設定，再逐項加入自動化條件。按需連線的具體情境可接著參閱Wi-Fi 與 Cellular 觸發規則筆記；若要重新了解加入、連線與驗證的完整流程，請回到使用教學。協定手冊用於說明差異與定位限制；設定值仍應以使用者現有的伺服器資訊為準。