Shadowrocket
協定與參數參考

協定分層：先釐清連線涉及的四個問題

協定、傳輸、安全與路由各屬不同層面

在 Add Server 中選擇協定類型，代表指定客戶端以何種格式向伺服器提供目標位址、驗證身分並交換資料。傳輸方式則決定資料如何傳送，例如使用 TCP 位元組串流、WebSocket 或以 UDP 為基礎的機制。安全層處理通訊加密與遠端身分驗證；路由層則決定特定請求是否交由這條連線處理。混淆這四個問題，可能導致更換協定卻沒修正錯誤的網域，或修改規則卻仍無法解決驗證失敗。

連線資料至少應包含伺服器位址、連接埠與驗證方式。某些組合還需要傳輸路徑、TLS 伺服器名稱及其他協商參數。伺服器位址是實際連線的目的地，目標網站位址則是使用者想存取的資源，兩者並不相同。連接埠只是入口編號，不能單憑常見連接埠就推定已啟用 TLS。匯入後，先確認類型是否正確，再檢查附加選項；不要因為欄位名稱相似，就把一組資料填到另一種協定中。

評估速度時，應分開看握手、傳輸量與穩定性

開啟短篇網頁時，網域解析、建立連線與安全握手可能比傳送頁面內容更耗時；連續傳輸大型檔案時，壅塞控制、伺服器出口與遠端網站的處理能力則更重要；語音或互動任務更在意抖動、封包遺失與連線恢復。單次延遲測試只能反映其中一部分。測試數值較低，不一定代表下載較快；頻寬較高，也不保證訊號微弱時互動更穩定。比較時必須固定測試目標、網路與大致時段，否則觀察到的變化很可能與協定無關。

評估 iOS 耗電，不能只看加密名稱

耗電來自處理器運算、無線收發、背景喚醒，以及失敗後重複嘗試。現代加密演算法的成本只是其中一項；訊號微弱時的重新傳送、持續探測與頻繁重建連線，往往更值得留意。比較耗電時，應盡量維持螢幕亮度、使用內容與網路訊號一致，並給系統足夠的觀察時間。不能把某次電量下降直接歸因於協定，也不能認為增加保活就一定更穩定；保活可能減少重新連線，卻也會增加閒置時的通訊。

選擇協定時，第一步不是列出速度排名，而是確認伺服器支援哪些類型、目前網路允許哪些連線，以及主要使用情境。現有資料只支援一種類型時，正確匯入並可靠驗證，比尋找另一個協定名稱更重要。若要比較多組現有設定，先保留原始紀錄，每次只變更一個變數，並記錄問題發生於解析、連線、驗證或存取目標的哪個階段。如此得出的結論，日後網路條件改變時才有參考價值。

協定類型是雙方的約定，不是客戶端單方面的偏好。伺服器沒有相應入口時，在 Shadowrocket 中切換類型並不會讓雙方自動相容。

Shadowsocks：共用密鑰與精簡的承載方式

設計背景與必須相符的欄位

Shadowsocks 的基本概念是使用預先共用的憑證建立加密代理通道，再將目標位址與後續資料交由伺服器轉送。它並非以網頁工作階段或完整網路介面為核心，因此基本參數相對集中，常見資料會列出位址、連接埠、密碼與加密方式。欄位少不代表可以省略核對：雙方使用不同的加密方式或憑證，或伺服器入口根本不屬於此協定，都會在建立有效通訊前失敗。

加密方式必須依伺服器資料原樣填寫。不同方式涉及不同的金鑰衍生、資料格式與驗證方式，名稱相近不代表彼此相容。採用認證加密的設定也會驗證資料完整性；密鑰錯誤時，可能在連線後很快中斷，而不會明確顯示密碼錯誤。不要把所有驗證失敗都當成連線不穩。部分較新的協定變體對密鑰格式有特別要求，此時不能直接套用一般密碼的填寫方式，應以該筆資料的欄位定義為準。

分別核對基礎協定與附加傳輸

若現有資料還包含外掛程式或其他外層承載資訊，請確認 Shadowrocket 的相應選項與伺服器實際設定一致。基礎協定、外層傳輸與入口連接埠共同構成連線條件，少了任何一層都可能導致逾時。尤其在移轉舊紀錄時，不要只複製位址與密碼，卻忽略附加說明。反過來說，資料未提供附加傳輸時，也不要為了讓設定看起來更完整而隨意啟用額外功能；客戶端傳送的格式一旦改變，伺服器就可能無法辨識。

TCP 與 UDP 的可用性也應分別驗證。網頁可以開啟，只表示相關請求路徑可用，不代表依賴 UDP 的任務也能正常運作。伺服器是否接受 UDP、網路是否允許相關流量，以及目前設定是否承載該請求，都可能影響結果。若某類任務失敗，先確認任務使用哪種傳輸方式，再檢查對應連線，不要立即更換密碼。不同協定應使用相同的目標進行測試，才不會把目標網站本身的差異誤算為協定差異。

速度、耗電與故障排查

在網路品質良好、伺服器負載適中的情況下，較精簡的封裝有助於減少額外處理，但實際速度仍由路徑容量與伺服器效能共同決定。某種加密方式在一台裝置上的表現，不能直接代表另一台；硬體加速、實作方式與任務大小都會影響結果。行動裝置使用時，更值得觀察的是連續瀏覽是否順暢、切換網路後能否恢復，以及閒置時是否不斷重新連線，而非只比較單次啟動所需時間。

排查時先確認位址與連接埠是否可連線，再核對加密方式與憑證，最後檢查附加傳輸。若所有目標都無法使用，優先檢查共用入口；若只有特定網站失敗，則檢查規則命中、網域解析與遠端回應。有些失敗不會提供易懂的驗證資訊，因此沒有顯示密碼錯誤，不代表憑證一定正確。可以重新從原始紀錄匯入一份設定作為對照，但不要同時保留大量名稱相同的項目，以免實際選到的不是剛修改的那一筆。

當現有伺服器提供相應入口，且希望參數結構較直接時，可考慮此類型。它不是 TLS 憑證設定的另一種說法，也不代表所有安全機制都與 TLS 相同。判斷遠端身分並管理憑證時，應了解此協定所依賴的信任來源；取得資料後，使用者仍須妥善保管密碼與密鑰。向他人說明故障時，可提供類型、錯誤階段與已隱去敏感內容的欄位結構，不要公開完整驗證資訊。

先核對加密方式，再核對密碼。隨意更換加密名稱通常無法解決相容性問題，反而可能使原本正確的資料無法使用。

VMess：分別檢查身分驗證與外層傳輸

了解協定所負責的工作

VMess 將使用者身分驗證、目標資訊與資料保護納入自己的協定結構，並可搭配不同的外層傳輸。這種設計代表一種取捨：不將所有功能交由外層處理，而是在協定內保留工作階段與驗證機制。對客戶端使用者而言，這表示必須同時了解協定參數與承載參數。只看到 UUID，並不足以還原完整連線；缺少傳輸類型或安全設定時，即使使用者身分正確，也可能完全無法通訊。

UUID 是身分欄位，不是伺服器位址，也不是 TLS 憑證中的名稱。複製時應保留完整格式，避免夾帶空格或不可見字元。部分舊資料可能包含與舊版驗證機制相關的欄位，不要憑經驗自行填入某個數值，應先確認伺服器目前的要求。匯入連結通常比手動拼湊更能保留欄位，但匯入成功只表示客戶端能讀取資料結構，不代表遠端驗證、憑證與傳輸路徑都已通過檢查。

WebSocket、Host 與路徑的不同用途

使用 WebSocket 時，連線需要經過相應的升級程序，路徑與請求中的主機資訊可能會影響伺服器選擇入口。此處的路徑是伺服器約定的入口，不是可任意填寫的網站目錄。路徑大小寫、開頭斜線或附帶查詢內容有差異，都可能使請求送到不處理該協定的位置。伺服器若回傳一般網頁或錯誤頁面，底層連線看似已建立，實際的代理工作階段卻未形成，因此不能把「位址能開啟」當成設定正確的證明。

WebSocket 與 TLS 同時使用時，還須區分連線位址、TLS 伺服器名稱與 HTTP 層的 Host。這三者有時相同，有時則會依部署方式而異。客戶端會先連至某個位址，接著在安全握手中驗證名稱，再透過應用程式層請求進入指定服務。任何一層不相符都可能導致失敗。不要把伺服器管理紀錄中的同一個網域複製到所有欄位；先確認每個欄位的用途，再依原始資料填寫。

時間與驗證錯誤的界線

VMess 的驗證程序包含時間相關檢查，因此裝置時間與實際時間差距過大可能造成連線問題。排查時可檢查系統日期與時間設定，但不要把所有失敗都歸因於時鐘錯誤。TLS 憑證有效期限也受時間影響，不過兩者屬於不同的驗證環節：驗證失敗與憑證失敗可能有相似的外在表現，修正方式卻不同。先查看可取得的錯誤資訊，再判斷應檢查裝置時間、使用者身分或伺服器憑證。

效能方面，額外承載通常會增加一些握手或封裝成本，但並沒有適用於所有網路的固定耗損比例。長時間傳輸時，這些成本可能被攤平；頻繁開啟短連線時，建立工作階段的額外負擔則更容易被察覺。行動裝置也應觀察從 Wi-Fi 切換至行動數據後的恢復狀況。舊工作階段失敗後能否及時重建、伺服器是否仍保留狀態，都會影響實際感受，不能只用靜態延遲數字判斷一整天的使用體驗。

建議依「身分欄位、傳輸方式、入口資訊、安全參數」的順序記錄並核對。若同一伺服器的其他現有項目可用，先比較欄位差異，不要整組重新填寫。若只有啟用特定外層承載的項目失敗，應優先檢查入口路徑與伺服器端對應設定。更換網路後恢復，只能提供排查線索，不能直接證明原網路封鎖了某個協定；解析結果、位址類型與入口可達性都可能因網路而異。

VMess 的 UUID、WebSocket 路徑與 TLS 伺服器名稱各有用途。一個欄位正確，無法抵銷其他層級的錯誤。

VLESS：輕量協定與安全層的組合界線

減少協定負擔，不代表可以省略安全檢查

VLESS 的設計讓身分與目標資訊的傳遞維持精簡，不在基礎協定中負責通用資料加密，因此通常需要搭配合適的安全層使用。此處的「輕量」描述的是協定分工，不是速度保證，也不是忽略伺服器驗證的理由。了解 VLESS 時，應同時確認兩件事：遠端如何驗證使用者身分，以及哪一層負責保護傳輸中的資料。只看到 VLESS 名稱，無法完整判斷連線的安全性。

現有資料中的 UUID、位址與連接埠仍須準確相符，此外也要核對傳輸類型、安全方式及相關附加欄位。不要把 UUID 當成 TLS 的替代品：身分驗證用來確認請求是否具備伺服器認可的憑證，安全握手則涉及工作階段保護與遠端身分，兩者並非同一程序。身分錯誤可能在安全連線建立後才被拒絕；伺服器名稱錯誤則可能更早失敗。依階段區分問題，有助於避免毫無方向地反覆修改。

TLS、REALITY 與 flow 參數

使用 TLS 的資料需要核對伺服器名稱與憑證驗證條件。若現有資料指定 REALITY，必須確認客戶端具備相應功能，且伺服器設定與所需公鑰等參數一致；它不是可套用於任意 TLS 入口的通用選項。不同安全方式所需欄位不可互相替代。缺少重要資訊時，應從自己的原始資料補齊，不要上網尋找一組看似可用的數值，因為這些數值必須與特定伺服器設定相符。

某些組合還包含 flow 等用來限制特定資料處理方式的參數。這個欄位不是自動加速開關，也不應為了追求速度而任意新增。伺服器是否支援、所選傳輸是否適用，以及客戶端實際實作條件，都會影響組合能否運作。最穩妥的做法是保留匯入資料中的原值，手動填寫時則逐項對照。遇到無法辨識的選項，先確認 App 內可用欄位，不要把它填進名稱相近的其他輸入框。

評估速度與耗電時，應考量實際條件

協定本身少負擔一些工作，不代表整條連線一定更省電。實際使用仍包含安全握手、外層傳輸、壅塞控制與無線通訊；長連線是否重複使用也會影響成本。持續觀看內容時，穩定傳輸量可能比首次握手更重要；間歇性存取時，喚醒與建立連線的成本則可能更明顯。比較兩組資料時，若伺服器位置、頻寬或安全組合不同，就不能把結果單獨歸因於 VLESS 與其他協定的差異。

遇到「測試有結果，但網站無法開啟」時，應檢查測試目標與實際請求是否走相同路徑。有些測試只確認入口是否可達，或只測試特定目標；網站存取則還需要解析網域、建立新連線並取得多項資源。也要確認 Global Routing 是否設為預期模式，以及目前選用的設定是否使用剛核對過的伺服器。可透過一次受控存取搭配連線紀錄定位問題，不要為了表面上連線成功而關閉所有驗證。

適用情境應以現有資料為起點：伺服器提供完整組合、客戶端能設定所有必要參數，而且你能核對遠端身分，才有條件討論效能取捨。若資料只有零散欄位，先補齊說明比反覆切換安全方式更有效。若要重新匯入訂閱，可參考四種訂閱匯入方式；但匯入本身不會補上伺服器未提供的資訊。

Trojan、HTTP 與 SOCKS5：分清驗證與加密

Trojan 所需的 TLS 條件

Trojan 的常見設計是透過 TLS 連線承載代理協定，在安全通道內完成驗證並傳送目標資訊。它採用成熟的安全層，而非讓每個欄位各自負責加密。對使用者而言，密碼正確只是必要條件之一；伺服器憑證、名稱與入口也必須正確。即使網域憑證有效，若實際連線進入另一個入口，仍無法建立代理工作階段；入口正確但憑證驗證失敗時，也不能單純歸咎於密碼。

伺服器名稱用於安全握手與身分核對，與使用者要造訪的網站名稱無關。憑證必須涵蓋需要驗證的名稱，裝置時間也應在合理範圍內。某些部署還會涉及應用程式層協定協商等選項，應依現有資料填寫，不要隨意新增。遇到憑證錯誤時，先檢查名稱拼字、裝置時間與伺服器端憑證鏈，再聯絡自己的伺服器管理者確認；略過驗證會降低身分檢查的可靠性，不應作為一般修復方式。

HTTP 代理不代表連線自動具備 TLS

HTTP 代理透過相應的請求格式或 CONNECT 方法處理目標存取，常見於使用既有代理閘道的環境，優點是用途明確、部署資料容易辨識。不過，「HTTP 代理」這個名稱本身不保證客戶端與代理之間已加密。若目標網站使用 HTTPS，網站內容可能受到端對端 TLS 保護，但代理仍可能看見目標與連線中繼資料。這與客戶端先透過 TLS 連至代理，是兩個不同的安全界線。

設定時應確認代理入口是否要求安全連線、是否使用使用者名稱與密碼，以及是否允許所需的目標連接埠。部分閘道只允許有限的存取方式，因此某個網頁可用，不代表所有任務都相容。驗證失敗、目標連接埠遭拒與上游無法連線，也都是不同問題。發生錯誤時，保留錯誤階段與狀態資訊，比單純重複測試更有效；不要把網站回傳的登入或拒絕頁面誤認為客戶端協定驗證失敗。

SOCKS5 的協商能力與安全界線

SOCKS5 提供目標位址與驗證方式的協商，也定義不同的請求能力，但基礎協定不負責加密整條連線。使用者名稱與密碼驗證不等於加密通道。若現有閘道要求透過特定安全承載使用，應遵循完整條件；否則就要充分了解接入網路與遠端入口之間的信任關係。選擇類型時應依伺服器實際提供的介面，不要把 HTTP 與 SOCKS5 當成可以互換的名稱。

SOCKS5 的網域處理與 UDP 能力，還會受到請求格式、客戶端行為及伺服器實作影響。協定定義了某項能力，不代表目前入口一定開放該功能。尤其在即時通訊情境中，應實際測試任務所用的流量，不要只憑網頁瀏覽成功就下結論。網域在哪一端解析，也不能單靠協定名稱判斷，還須核對客戶端 DNS 設定與請求路徑；否則排查遠端連線時，可能忽略本機解析問題。

評估速度與耗電時，應比較實際承載，而非只看名稱。安全握手、連線重用與閘道回應時間會影響短請求；持續傳輸則受入口容量與網路品質限制。若只是存取現有 HTTP 或 SOCKS5 閘道，依其介面填寫，通常比額外套用不受支援的組合更可靠。對身分驗證有明確要求時，先確認安全界線，再討論少一次握手能帶來多少效益；不可用些微的啟動差異取代必要的身分檢查。

WireGuard：從目標代理轉為網路層隧道

設計模型決定參數的含義

WireGuard 用於網路層隧道，透過公鑰身分與加密資料報傳送 IP 流量。它與只指定特定目標連線的代理協定採用不同模型，因此參數包含介面位址、對端公鑰、端點與允許的位址範圍。它採用較固定的密碼學組合來降低協商複雜度，但演算法選擇簡單，不代表網路設定也簡單。使用者仍須了解位址如何分配、哪些目的地會交由對端處理，以及回程流量如何抵達裝置。

私鑰用於證明本端身分，公鑰用於辨識對應的一方，填寫時不可顛倒。端點是實際聯絡對端的位址與連接埠；介面位址則是在隧道內使用的位址，兩者不可混淆。若要求預共享密鑰，雙方設定也必須一致。匯入後，不要任意在不同裝置間複製整組身分與內部位址，因為伺服器可能將其對應至固定對端；重複使用可能造成工作階段競爭或回程路徑異常。

AllowedIPs、路由與 MTU

AllowedIPs 會參與對端位址關聯與流量選擇，不能簡單視為網站允許清單。在客戶端整合環境中，也要與 App 的路由策略一併理解：其中一層決定請求是否進入相應連線，另一層則限制隧道內哪些位址與對端相關。設定範圍過窄，可能使需要存取的位址沒有可用路徑；範圍過寬則可能偏離原本的存取規劃。應保留伺服器資料中的網路規劃，不要憑經驗擴大至所有位址範圍。

MTU 表示介面可傳輸的封包大小上限。外層封裝會占用空間；若底層路徑無法順利處理較大的封包，可能出現小型請求正常、大型回應停住的情況。但這只是可能原因之一，網頁載入不完整時不應立刻調整 MTU。先排除目標服務、DNS 與封包遺失問題，再以可重複的測試小幅調整並記錄原值；盲目調得過小，也會增加分段與處理成本。

網路切換與保活並非同一回事

WireGuard 的設計可在通過驗證的資料交換中識別對端位址變更，這對行動網路有其意義；但實際恢復仍取決於接入網路、位址轉換狀態與伺服器可達性。手機從 Wi-Fi 切換至行動數據時，舊的對應可能失效，必須重新建立可用路徑。這不代表每次切換都能不中斷，也不應只憑一次切換失敗就判定密鑰錯誤。先觀察固定網路下是否穩定，再檢查切換後的恢復狀況。

PersistentKeepalive 用於定期通訊，協助維持某些位址轉換對應，不是加速開關。閒置時持續傳送會增加無線活動；完全不啟用保活，則可能使特定網路環境中的連入恢復變慢。是否需要啟用及採用何種間隔，應依自己的伺服器資料與網路條件判斷。若有資料流量時 App 運作正常，只有長時間閒置後的首次請求失敗，才值得檢查位址轉換與保活；不要對所有設定一律啟用。

評估效能優勢時，必須納入實際任務條件。固定的加密設計與精簡的資料路徑，有助於讓成本更容易預測，但 UDP 可達性、路徑封包遺失與伺服器轉送能力仍可能成為瓶頸。只測一次大型檔案傳輸，無法說明背景閒置時是否省電。行動裝置應同時觀察連續作業、短時間待機與多次網路切換，並避免在同一次測試期間修改多個隧道參數，否則難以判斷改善原因。

不要公開私鑰，也不要把完整隧道資料當成一般截圖分享。排錯紀錄只保留欄位名稱、隱去內容後的位址範圍與失敗階段。

較適合已有完整隧道規劃，且能明確管理內部位址與對端身分的情境。若取得的資料只有一般代理位址與密碼，不要嘗試將其轉成 WireGuard 設定。反過來說，即使已成功握手，也只代表部分條件成立；仍須驗證目標位址路由、DNS 與伺服器回程路徑，才能確認實際存取完整可用。

Hysteria2：QUIC 承載與頻寬設定的取捨

先確認 UDP 與安全握手條件

Hysteria2 採用以 QUIC 為基礎的承載方式；QUIC 運作於 UDP 之上，並結合安全握手與串流管理。這種設計在不穩定的連線上提供了不同於傳統 TCP 組合的取捨，但無法消除無線訊號差、路徑壅塞或伺服器容量不足的問題。能否連上 UDP 入口，是進一步比較速度的前提。若目前網路無法妥善處理相關資料報，改用此協定不一定能改善使用體驗。

通常須核對的資料包括位址、連接埠、驗證方式、安全名稱，以及可能存在的其他附加條件。Hysteria2 與名稱相近的舊版協定不能只因標籤相同就視為相容，匯入後應確認實際類型。即使入口連接埠看起來與常見網頁服務相同，也不能推定傳輸方式相同。排查時要分清測試的是 TCP 可達性，還是真正透過 UDP 進行握手；前者成功不能取代後者，也不能以網頁是否能開啟來證明該入口可用。

頻寬欄位是設定參數，不是測速結果

部分設定包含上行與下行頻寬等參數，應依客戶端使用的模式與伺服器限制來理解。這些數值可能影響傳送或壅塞控制策略，不代表填入越大的數值就能取得相應容量。實際容量仍受接入網路、共用鏈路、伺服器與目標限制。若把預期值誤當成可持續的實際容量，可能增加排隊、封包遺失與重新傳送，最後導致下載看似順暢，互動請求卻更慢。

上傳與下載應分別考量，尤其是上行容量較小的接入網路。大量上傳占滿上行後，其他連線的確認或控制資料也可能排隊，進而影響整體體驗。遇到這種情況，先減少並行工作，觀察閒置與負載狀態的差異，再核對頻寬設定。不要同時更換伺服器、提高多個頻寬數值並變更目標檔案；即使結果有所改善，也無法判斷真正有效的是哪一項修改。

評估弱網表現時，應同時觀察傳輸量與抖動

在有封包遺失或延遲波動的連線上，QUIC 的串流管理與連線機制可能呈現不同的恢復特性，但「適合弱網」仍須視條件驗證。連續下載能否維持傳輸量，與短請求能否即時回應，是不同的指標。測試時可先進行輕量互動，再加入穩定的連續任務，觀察同時使用是否明顯增加等待時間。只有接近實際用途的測試，才有助於判斷這組設定是否適合目前網路。

耗電影響也需要謹慎判斷。資料報重新傳送、持續傳輸、加密運算與無線模組運作時間，都會影響耗電。更快完成相同任務可能縮短運作時間，但高強度傳輸或頻繁失敗也可能增加耗電。不能因底層使用 UDP 就認定一定省電，也不能只因裝置發熱就歸咎於協定。應盡量控制螢幕、媒體解碼、背景同步與訊號變化，並以足夠長且可重複的使用過程進行觀察。

若握手失敗，先核對位址、連接埠與 UDP 可達性，再檢查驗證方式與安全名稱。若已建立連線，傳輸後卻變得不穩定，應檢查頻寬參數、並行數量與接入網路容量變化；若只有特定網站失敗，則回頭檢查 DNS 與規則路徑。有些資料還包含專用混淆參數，只有伺服器要求且提供相符資訊時才應填寫；這些參數無法修正錯誤驗證或憑證的問題。

比較 Hysteria2 時，重點在目前連線下的實際任務表現。頻寬欄位填得更大、測試項目回應更快，都不能單獨證明持續存取更穩定。

嘗試使用的前提，是使用者已有相應伺服器資料與完整安全參數，且接入環境允許相關 UDP 通訊。若這些條件無法確認，先使用現有且已驗證的連線完成基準測試。保留一份可還原的原始資料，再逐一受控修改參數，通常比反覆重新匯入後憑印象比較更可靠。

DNS、規則與情境選擇：讓結論成為可重複驗證的步驟

網域解析決定後續連線的起點

DNS 會將網域轉換為可連線的位址，既影響目標存取，也可能影響代理伺服器本身的連線。兩者應分開檢查：目標網站解析失敗，不一定代表伺服器入口無法連線；若伺服器位址使用網域，入口解析錯誤則可能使所有請求失敗。設定加密 DNS 也不代表後續網站請求一定經由代理；解析通道與存取通道仍各自受設定與路由條件影響。應依實際路徑排查，不要只憑 DNS 名稱判斷結果。

DNS 也涉及引導依賴：若解析伺服器本身使用網域，就需要可用的初始解析或連線路徑。設定不當可能形成依賴循環，表現為啟動後所有網域都無法使用。不要一次更換所有解析設定；先保留目前可運作的基準，再確認所選設定如何處理伺服器網域與目標網域。IPv4 與 IPv6 的解析結果也可能走不同路徑；部分目標逾時時，應觀察位址類型與實際可達性，不要只因取得解析結果就停止排查。

Global Routing 決定流量是否進入所選連線

Config 模式會依目前設定的規則選擇策略；Proxy 模式會讓適用流量使用代理路徑；Direct 模式則直接連線。路由選擇不會改變伺服器要求的驗證與安全參數，也無法修正錯誤憑證。比較協定前，應確認兩次測試都採用預期路徑，否則一次直連、一次代理的結果並無可比性。Scene 也涉及情境設定，不要與這三種基本模式混為一談。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

上方片段僅說明規則語法：範例網域使用 PROXY，符合相應位址歸屬條件的請求使用 DIRECT，其餘則由 FINAL 處理。這不是完整設定，不能取代現有伺服器資料。規則通常會依設定的比對順序產生結果，因此範圍較廣的規則若放置位置不當，可能使更具體的規則無法命中。若只想讓指定網站使用代理，可參閱DOMAIN-SUFFIX 與 FINAL,DIRECT 的設定方式，並在 Config 模式下確認實際命中的規則。

依使用情境安排選擇順序

日常瀏覽優先留意啟動等待、解析穩定性與網路切換後的恢復；持續傳輸則關注可維持的傳輸量、並行時的排隊與伺服器容量；即時互動要考量抖動、封包遺失與任務所需的 UDP 支援；長時間行動使用則應觀察閒置通訊與耗電。已有 HTTP 或 SOCKS5 閘道時，先符合其介面與安全條件；已有 WireGuard 網路規劃時，先確認位址與回程路由正確；其他協定也應從完整相符的設定開始，而非先依名稱排名。

建議建立簡單的測試紀錄，記下接入網路、目標任務、使用項目、Global Routing、是否切換網路及失敗階段。先在穩定環境完成短請求與連續任務，再於可控條件下切換網路。每次只修改一個欄位，失敗後還原原值。Connectivity Test 可協助找出問題線索，但不代表所有 App 的使用體驗；完整操作可參考連線驗證步驟，常見問題則可參閱新手十問。

保留資料與排查證據的界線

訂閱更新可能會變更伺服器項目與部分參數，修改前應先分清哪些資料來自訂閱、哪些屬於本機設定。手動修正的欄位若在更新後被覆寫，應檢查資料管理方式，不要以為協定會自動變更。向自己的服務商回報時，說明首次失敗的階段、是否只影響特定目標，以及切換網路後的結果；並隱去密碼、UUID、私鑰與完整訂閱網址。可重複驗證的現象，比只有「無法連線」的截圖更有助於定位。

選擇結論應以條件句表達：在這組現有資料、這個接入網路與這類任務下，某個組合較合適。網路或伺服器條件改變後，應重新驗證，不要永久沿用單次測試的排名。