Shadowrocket
協定技術參考與參數選擇

選擇協定首先受伺服器限制

協定決定用戶端與伺服器如何建立連線、驗證身分及傳遞資料。它不是可單獨替換的外觀選項：伺服器接受 Shadowsocks 時，用戶端若選成 Trojan，即使位址、連接埠和密碼看起來相同，也無法正確互通。因此，選擇時應先取得完整的伺服器說明，確認協定類型、驗證欄位、傳輸方式及是否啟用 TLS，而不是比較名稱。既有訂閱通常包含這些資訊，手動編輯前應先保留原始資料。

本頁所說的速度，是完整存取一次的結果，涉及裝置至伺服器的路徑、伺服器負載、目標網站回應及用戶端處理成本。協定會影響交握次數、封裝開銷與丟包後的復原方式，卻無法取代可用的網路路徑。不要把單次 Connectivity Test 的結果直接當成網頁載入速度；測試目標可能與實際存取目標不同，短連線測試也難以反映持續傳輸時的壅塞與波動。

分辨協定、傳輸與加密

協定負責約定資料格式與驗證方式，傳輸負責承載位元組或封包，加密層則保護傳輸內容。有些組合使用 TCP，有些使用 UDP；WebSocket 是可選的傳輸組織方式，TLS 則屬於安全層。同一伺服器可能同時包含協定名稱、傳輸名稱和憑證網域，這些欄位描述不同層次。只知道 VLESS 或 VMess，還不足以重建設定，仍須核對對應的傳輸與安全參數。

規則屬於另一條邏輯鏈：先判斷請求應採用哪個策略，再透過選定的伺服器使用相應協定。DOMAIN-SUFFIX 不會改變伺服器的驗證方式，FINAL 也無法修正錯誤的 TLS 名稱。遇到存取失敗時，先確認請求是否套用預期策略，再檢查協定連線是否建立；若混為一談，就可能不斷更改密碼，實際上卻命中 DIRECT，或反覆修改規則，連線仍然驗證失敗。

行動裝置應留意持續耗電，不只看峰值

iPhone 與 iPad 的耗電不只來自加解密運算。無線網路反覆喚醒、訊號微弱時重傳、短時間內重複交握，以及維持背景連線，都可能增加耗電。同一協定在穩定 Wi-Fi 與訊號變動的行動網路上，表現可能不同。比較時應固定裝置、網路、目標工作與測試時間，同時記錄發熱、載入等待和重新連線次數，不要只憑協定名稱排出固定的省電名次。

Shadowrocket 顯示的欄位會隨所選類型與相關選項而變化。本文說明各欄位的用途，不代表所有協定的選用欄位都是必填項；實際設定應以 App 目前介面和伺服器說明為準。編輯頁面沒有顯示的擴充項目，不應硬塞進名稱或密碼。初次使用可依教學完成基本連線，再逐項加入確有需要的傳輸設定，每次只變更一個項目。

閱讀後續章節時，可依照一致的順序檢查：先確認伺服器實際提供的內容，再核對驗證資料，接著檢查傳輸與安全層，最後驗證實際使用情境。若現有資訊只有位址和連接埠，卻缺少協定說明，應先補齊資料。猜測協定或隨意切換安全選項，通常只會帶來新的失敗狀況，無法得出可重現的診斷結論。

設計取捨：集中處理代理資料

Shadowsocks 的設計重點，是以相對簡潔的方式傳送代理流量，將目標位址與應用程式資料放入雙方約定的加密結構。它不像完整網路通道那樣，要求使用者先理解虛擬網段與路由位址；常見的手動設定主要包含伺服器位址、連接埠、加密方法和密碼。簡潔的設計降低了基本設定的理解門檻，但不代表不同加密方法、協定世代或擴充功能彼此相容。

從早期的串流加密方案到具備驗證功能的加密方案，重要差異在於接收端能否檢查資料完整性，而不只是還原內容。AEAD 將加密與驗證結合，用戶端和伺服器必須採用相同的方法與金鑰資料。即使名稱相似也要逐字核對，不能只憑金鑰長度或演算法家族判定相容。設定若要求特定格式的金鑰，更不能沿用其他類型的任意文字密碼。

位址、方法與密碼如何對應

伺服器位址是建立外層連線的入口，可以是網域或 IP；連接埠用來定位該入口上的服務。加密方法決定資料處理格式，密碼或指定格式的金鑰則用來產生驗證與加密所需資料。這些欄位必須一併核對。連接埠正確但方法不符時，底層連線仍可能建立，後續資料卻無法被對端接受；因此，「連得上連接埠」與「協定驗證成功」是兩項不同的證據。

從 Subscribe 匯入後，先在伺服器編輯頁面確認類型確實是 Shadowsocks，再核對方法與密碼是否完整。部分分享資訊經過編碼，複製時遺失結尾字元、混入換行或遭到額外解碼，都可能改變實際內容。如果重新匯入訂閱後恢復正常，但手動編輯的紀錄仍然失敗，應比較欄位差異，不要把手動修改覆蓋到訂閱中的其他伺服器。

擴充參數必須由伺服器明確支援。有些設定會包含外掛程式或額外封裝說明，但這些並非所有 Shadowsocks 連線都需要的預設項目。基本協定可用，不代表任意附加傳輸也可用；反之，伺服器要求擴充功能時，只填基本四個欄位也不夠。遇到未知擴充項目，應先查明名稱、對應選項與必要參數，不能用啟用 TLS 或更換常見連接埠來代替。

TCP 與 UDP 應分別驗證

瀏覽網頁主要驗證相應的應用程式存取路徑，無法據此推斷 UDP 轉送已正常運作。用戶端選項、伺服器設定及中間網路都可能影響 UDP。若使用者的既有服務支援 UDP，應以實際需要 UDP 的工作進行驗證，並檢查記錄中該請求採用的策略。若網頁正常、某類即時服務卻無法使用，應先確認該服務的流量與轉送支援，再判斷是否需要調整協定。

行動裝置上 Shadowsocks 的實際處理成本，與加密實作、資料量和網路條件有關。封裝較少通常有助於降低額外開銷，但訊號微弱時重複傳輸所造成的等待，可能遠高於加密運算的差異。比較兩筆設定時，應使用相同工作觀察持續傳輸量與回應穩定度。單次小封包測試，既無法證明長時間使用速度更快，也無法證明背景使用更省電。

使用者已有服務明確提供完整的 Shadowsocks 設定，且目標工作符合其支援的轉送方式時，就適合選用此協定。若需要憑證身分驗證、特定傳輸或網路層位址管理，應依伺服器實際能力參閱其他章節，不要在 Shadowsocks 紀錄中加入不相符的欄位。設定成功後保留原始資料，日後遇到問題時，優先比較網路環境與紀錄變動。

欄位相似不代表協定相同

VMess 使用自身的協定結構來組織使用者身分驗證與代理資料傳遞，常見設定以 UUID 識別使用者，並包含相應的安全參數。VLESS 的設計則減少協定本身的部分處理，將傳輸安全更多交由外層機制負責。兩者可能使用相似的伺服器位址、UUID 和傳輸欄位，但訊息格式與伺服器端的處理方式不同。不能只把編輯頁面的類型從 VMess 改成 VLESS，就視為完成有效轉換。

了解這項差異，有助於判斷「參數都一樣，為什麼還是連不上」。UUID 只是驗證資料的一部分，並非可通用於所有協定的登入憑證。伺服器必須在相應入口設定相同類型，並接受對應的傳輸與安全層組合。若既有訂閱列出多筆不同類型的紀錄，應將它們視為獨立的連線資料，不要從其中一筆拼湊密碼、連接埠或傳輸欄位到另一筆。

分清入口位址與服務名稱

伺服器位址決定首先連往何處，TLS 的服務名稱用於身分驗證與交握，WebSocket 的 Host 與 Path 則參與相應的應用層請求。這些欄位有時相同，有時會因伺服器部署方式而不同。尤其是位址使用 IP 時，憑證仍可能是簽發給網域；此時應依伺服器說明填入所需名稱，不要直接把憑證名稱改成 IP，也不要把 Path 當成網域的一部分。

WebSocket 的 Path 通常以斜線開頭，而且必須與伺服器接受的路徑一致。字元大小寫、結尾斜線或多餘空格，都可能影響請求是否被接受。Host 也不是備註名稱，填入容易辨識的中文標題不能取代它。手動輸入時可先建立欄位清單，將位址、連接埠、UUID、傳輸、TLS 名稱、Host 與 Path 分行記錄，再逐項對應 App 中可用的選項。

VMess 設定還可能包含安全方式等參數；舊資料中的某些欄位不一定適用於目前的服務。VLESS 的擴充功能與傳輸組合也必須獲得用戶端和伺服器共同支援。不要把舊說明中的預設值照抄到既有設定，更不要在找不到對應選項時自行推測替代項目。優先保留訂閱匯入的完整紀錄；必要時，向自己的服務提供者確認目前應使用哪些欄位。

交握層數會影響短時間工作的體感

使用 TCP、TLS 和 WebSocket 組合時，連線通常需要逐層建立。對資料量少的短時間工作而言，建立連線的等待可能比後續傳輸更明顯；已有連線穩定時，體驗則可能不同。因此，某種組合在持續存取時表現穩定，不代表在頻繁重新連線的行動網路中也同樣適合。比較時應分別觀察首次開啟、連續存取，以及網路切換後的復原情況。

VMess 的驗證機制涉及時間因素，裝置時間明顯不準時可能造成驗證異常。應先檢查系統的日期與時間設定，再核對協定欄位；VLESS 紀錄失敗時，則不應直接套用相同原因。網路切換後，原有連線是否仍可使用，也取決於底層傳輸。TCP 連線通常需要在路徑變動後重新建立，不要因為協定名稱相近，就預期所有組合都能以相同方式復原。

選擇這兩類協定時，應以既有服務的完整組合為單位，而不是只比較 VMess 與 VLESS 兩個名稱。若連線失敗但沒有明確錯誤訊息，可依序確認入口是否可連線、TLS 交握、傳輸請求與身分驗證。每個步驟都應保留判斷依據，避免同時修改多個欄位後偶然恢復，卻無法確認真正原因。

安全層是連線結構的一部分

Trojan 將代理請求與密碼驗證置於 TLS 連線中，並利用成熟的 TLS 機制保護用戶端與伺服器之間的通訊。因此，理解 Trojan 不只要看密碼，也要了解伺服器憑證、服務名稱與交握流程。外層安全連線尚未完成時，應用層驗證通常還無法開始；此時反覆更換密碼，無法解決憑證過期、名稱不符或交握協商失敗等問題。

這裡的 TLS 連線保護的是通往代理伺服器的這一段。若目標網站使用 HTTPS，應用程式與目標網站之間還會有另一條獨立的安全連線；兩者使用的不是同一張憑證，也不應混為一談。伺服器連線成功，但某個網站顯示憑證錯誤時，應先判斷錯誤來自哪個層次。僅因錯誤訊息包含 TLS 就修改 Trojan 伺服器名稱，可能反而破壞原本正確的設定。

入口、SNI 與憑證各有用途

位址告訴用戶端要連往何處，SNI 在交握過程中標示所需服務，憑證則提供驗證服務身分的依據。簡單的部署可能使用同一個網域，不同入口的配置則可能有所差異。正確做法是依伺服器說明對應填寫，並確認憑證涵蓋預期的服務名稱。若入口提供的是 IP，也不能因此斷定憑證必須包含該 IP；應先確認指定的 TLS 名稱。

密碼必須與伺服器紀錄完全一致，前後空格、換行和字元替換都可能造成驗證失敗。連接埠只用來識別服務入口，使用常見連接埠不代表該服務一定是 Trojan，也不能證明憑證設定正確。若伺服器允許額外的傳輸封裝，還須核對相關欄位；除非伺服器明確要求，否則一般 Trojan 紀錄不應任意加入其他傳輸方式的 Path 或 Host。

部分進階欄位用於協商應用程式協定或變更交握細節，例如 ALPN。這些欄位的作用是讓雙方就後續處理方式達成一致，並非通用的加速開關。使用者沒有相關說明時，應保留匯入紀錄中的設定。將其他地方看到的值複製進來，可能導致外層連線成功，卻連到錯誤服務；也可能使伺服器拒絕繼續處理。診斷時先恢復已知有效的組合，再逐項找出差異。

依原因處理憑證異常

憑證名稱不符時，核對位址與 TLS 名稱是否混淆，並確認伺服器實際提供預期的憑證。若提示有效期限異常，先檢查裝置時間，再確認伺服器憑證是否需要更新。若是信任鏈問題，應由伺服器設定補齊相關憑證鏈，或確認其既定的信任方式。停用憑證驗證會失去身分檢查依據，不應當作恢復連線的常規作法。

在 iOS 上，TLS 的運算與交握成本通常只是整體體驗的一部分。穩定連線承載較多請求時，建立連線的開銷可以分攤；行動網路頻繁中斷時，重複交握則會增加等待與無線活動。不能因此固定將 Trojan 標示為「更耗電」或「更快」。應在相同網路下比較實際工作，並區分首次連線所需時間與連線建立後的傳輸表現。

若使用者的既有服務明確提供 Trojan，且憑證名稱與驗證資料完整，就適合選用。若同一服務提供多個入口，可優先驗證憑證資訊明確且目前網路可連線的紀錄。只有單一目標無法存取時，先檢查規則與 DNS，不要立即重建 TLS 設定；若所有目標都無法存取，且記錄指出交握問題，再依本章的層次逐項核對。DNS 解析問題可繼續閱讀DNS 設定與解析疑難排解。

兩種通用代理如何傳遞請求

HTTP 代理源自集中轉送網頁請求的需求，能以 HTTP 方式接收代理請求；處理需要通道的連線時，常見機制是 CONNECT。SOCKS5 則以較通用的目標位址與連線請求為核心，不依賴使用者正在存取哪一類網頁資源。兩者的設計側重不同，但都必須由伺服器實際支援相應協定，不能只因為有位址和連接埠，就任意選一種嘗試。

HTTP 代理、透過 TLS 連線的 HTTP 代理，以及透過 HTTP 代理存取 HTTPS 網站，是三個不同概念。最後一種情況下，目標網站的 HTTPS 不會自動為用戶端與代理入口之間的所有互動提供相同保護。SOCKS5 本身也不等於加密通道。判斷安全界線時，應確認外層連線是否受到保護，以及業務內容本身是否使用端對端安全協定。

分開核對帳號驗證與傳輸保護

這兩類紀錄常見的欄位包括位址、連接埠、使用者名稱和密碼，但是否啟用驗證及支援哪些方式，應以伺服器設定為準。使用者名稱空白不一定代表服務允許匿名存取，隨意填入字元也不會讓伺服器接受請求。若既有資料只提供需驗證的代理位址，應依協定說明拆分欄位，避免把使用者名稱留在位址欄，或將連接埠誤當成密碼的一部分。

SOCKS5 的使用者名稱與密碼驗證不負責提供完整的資料加密。若使用環境需要保護外層連線，必須確認服務實際提供了相應的安全機制，而不是尋找名稱相似的開關。HTTP 代理也是如此：目標網站的憑證正常，只能證明該目標連線通過相關驗證，不能取代對代理入口身分與傳輸方式的檢查。

代理轉送目標時，網域是在本機還是由代理端解析，會影響解析結果與排錯方向。用戶端可能將網域交由代理解析，也可能因設定或請求形式而先取得 IP。遇到以網域存取失敗、以已知位址測試卻正常的情況，應檢查 DNS 路徑與記錄中的目標形式，不要立即歸因於帳號驗證。兩種測試實際上可能經過不同的解析路徑。

不能只憑類型名稱推斷 UDP 支援

SOCKS5 標準包含 UDP 相關機制，但實際使用仍取決於用戶端實作、伺服器能力與網路可連線性。HTTP CONNECT 的常見用途主要是 TCP 通道，不能據此推斷所有 UDP 工作都能透過該入口傳輸。若主要工作包含即時影音或其他 UDP 請求，應明確驗證該筆紀錄的能力，不要只用瀏覽器開啟網頁作為完整驗收。

在 iPhone 或 iPad 上，這些協定的效能仍取決於連線路徑。簡單的入口可能在特定網路中表現直接，也可能因遠端處理、連線數限制或驗證策略而產生等待。協定歷史悠久不代表一定較慢，欄位較少也不代表一定更省電。若頻繁失敗重試，額外的無線活動反而會讓簡單設定造成明顯耗電。

通常適用於使用者已有明確的 HTTP 或 SOCKS5 服務資料，或需要連接既定網路中的代理入口。應先確認信任範圍，再驗證所需工作與解析方式。若目標是保護裝置至遠端入口之間的資料，只選擇這兩種名稱並不足以構成完整方案。無法確認入口安全層時，應補齊服務說明，不要根據瀏覽器網址列的安全標示推斷整條連線都安全。

從代理請求轉向網路封包

WireGuard 著重以精簡的協定結構建立網路層通道，使用公開金鑰識別對端，並透過 UDP 傳送加密封包。它與前面依目標連線組織代理請求的類型不同：設定不只要知道連往何處，還要描述本端使用的通道位址、對端金鑰，以及允許進入相應路徑的位址範圍。若將它當成「另一種只填密碼的伺服器類型」，就容易漏掉重要欄位。

WireGuard 採用固定的現代密碼學組合，減少使用者在演算法選單中選擇的需求。這樣的取捨降低了演算法組合的設定複雜度，卻讓設定正確與否更取決於金鑰、位址與路由關係。協定本身精簡，不代表可以省略網路設定。即使金鑰完全正確，通道位址或允許範圍不符，仍可能出現交握成功但業務無法回傳的情況。

本端私密金鑰與對端公開金鑰不能互換

私密金鑰用來證明本端身分，使用者應妥善保管；公開金鑰則用來識別對端。用戶端紀錄中的對端公開金鑰，必須對應伺服器實際使用的私密金鑰；伺服器也必須能識別與該用戶端對應的公開金鑰。雙方各自隨機填入一組值並不能運作。若設定還使用預先共用金鑰，該值也必須在雙方一致，並與公開金鑰、私密金鑰分開保存，不能互相替代。

Endpoint 描述外層伺服器的位址與連接埠，通道 Address 描述進入通道後的本端位址，兩者屬於不同網路層次。前者可以是可從公網連線的網域，後者可能來自指定的內部網段。將 Endpoint 的 IP 填入通道位址，通常無法得到正確設定。匯入既有資料時，應保留位址後的前綴長度，並區分 IPv4 與 IPv6 欄位，不要只留下看起來像 IP 的部分。

AllowedIPs 將位址範圍與對端關聯，在完整設定中同時涉及路由選擇與允許的來源範圍。Shadowrocket 也有自身的規則策略，因此應理解伺服器端通道設定與用戶端分流是兩層不同的限制。不要只為了「讓所有請求都進去」就擴大所有位址範圍；尤其存取區域網路或多個內部網段時，應依原始網路規劃核對需要涵蓋的目標。

保持連線與 MTU 都是邊界參數

PersistentKeepalive 用於在有需要時維持中間設備上的映射，有助於某些閒置後仍需由對端聯繫的情境。它不是間隔越短就越可靠的通用開關：間隔較短代表定期傳送更多封包，在行動網路中可能增加無線活動。是否需要及採用何種數值，應由網路條件與既有設定決定。若只在主動存取時偶爾重新連線，應先確認實際的閒置與映射情況。

MTU 描述單次承載資料的大小上限。通道增加封裝後，可用空間會有所變化；若路徑無法正確處理較大的封包，可能出現小型請求成功、大型頁面或檔案卻停滯的情況。不能只憑這種現象就判定是 MTU 錯誤，也應排除丟包與目標回應問題。確實需要調整時，先保留原值，在相同網路與目標上逐次驗證，不要同時修改 DNS、規則和金鑰。

在 iOS 上，WireGuard 的 UDP 傳輸與端點更新機制可適應部分網路變化，但無法保證所有切換網路的過程都不中斷。如果目前網路限制 UDP，或映射、路由及回傳路徑有問題，仍會影響使用。適合選用的前提是已有完整且可用的通道資料，尤其是需要存取指定內部網段的情況；不要只因協定設計精簡，就推斷它必定速度更快或更省電。

為路徑波動而設計的思路

Hysteria2 以 QUIC 組織傳輸，使用 UDP 作為底層承載，並結合相應的驗證與壅塞控制機制來處理代理流量。它的設計著眼於高延遲、丟包與吞吐量波動等路徑條件，但不代表在任何網路上都能保證效能。首先必須確認目前網路允許所需的 UDP 通訊；若外層封包無法正常抵達伺服器，調整頻寬或驗證欄位也無法解決問題。

QUIC 支援在同一條連線中組織多個串流，可在某些情境減少不同串流因丟包而造成的傳遞阻塞。不過，所有串流仍共用實際路徑容量，壅塞與無線訊號限制也不會消失。Hysteria2 還需要將應用程式流量封裝進自身的協定結構，因此不能把某項 QUIC 特性直接等同於所有工作都一定更快。觀察結果應包含實際工作完成時間，而不只是瞬間傳輸峰值。

分別填寫驗證、TLS 與額外參數

基本設定需要伺服器位址、連接埠、驗證資訊，以及服務要求的 TLS 設定。驗證內容必須依既有資料正確填入，不能因為它是一段文字，就與其他協定的密碼混用。憑證名稱的判斷方式與前文相同：入口位址不一定等於 TLS 服務名稱，應確認伺服器憑證涵蓋預期身分，並保留驗證功能。

部分服務還提供額外的混淆設定，其類型與密碼必須在雙方一致。這是不同於使用者驗證的欄位，不能把兩組密碼合併，也不能只在用戶端啟用後就期待伺服器自動識別。若訂閱中沒有這項設定，就不應把它當成必要的效能選項。遇到無法辨識的擴充功能，應先確認目前 App 是否支援相應設定，再決定是否使用該筆連線資料。

頻寬參數常被誤解為解除限速的按鈕。在相關模式中，這些參數可能參與傳送策略或壅塞控制；填入的數值應反映合理的路徑能力，而不是預期的最高速度。估值過高時，傳送可能超出實際承載能力，造成排隊、丟包或其他工作回應變慢；估值過低則可能限制吞吐量。是否需要填寫及使用何種單位，應依 App 介面和伺服器說明逐項確認。

速度與互動延遲應一併觀察

在同一裝置上，大型檔案傳輸速度提高時，其他頁面的點擊回應反而可能變慢，通常與排隊及頻寬競爭有關。評估 Hysteria2 時，應同時觀察持續下載與輕量請求，不要只保留速度最快的一次結果。若調整參數後峰值提高，頁面卻更容易停頓，應還原設定，再比較較保守的參數是否更適合目前網路。

行動網路的訊號變化會影響可用速率，固定的頻寬估值很難一直準確。在 Wi-Fi 測得的數值不宜直接套用到行動網路，也不能用一段閒置時的測試代表全天狀況。頻繁重試、長時間高吞吐量與無線活動都可能造成裝置發熱和耗電。需要長時間背景連線時，應依實際使用週期觀察，不要只憑單次高速測試結果決定長期設定。

使用前提是既有服務明確提供 Hysteria2，且目前網路能穩定傳輸其 UDP 流量。若所在網路不符合條件，應改在既有服務提供的其他可用紀錄中驗證，不要一味提高頻寬數值。選擇結論應表述為「在這個網路與工作情境下較合適」，而不是把單次體驗推廣成協定的固定排名。

依必要能力篩選，不替名稱排名

實際選擇時應先列出工作需求：既有服務支援哪些類型、目前網路是否能正常使用 TCP 與 UDP、是否需要存取內部網段，以及主要工作是短時間瀏覽頁面、持續傳輸還是即時互動。完整資料與穩定連線能力比協定知名度更重要。只有一筆有效設定時，先確認它能正常運作；有多筆紀錄時，再以一致條件比較，不必為了追求某個名稱重新拼湊參數。

日常瀏覽網頁可先使用欄位完整、交握穩定的既有紀錄，重點觀察第一個頁面與連續瀏覽的回應。需要存取指定的內部網路位址時，應核對 WireGuard 等既有通道資料中的位址與路由。需要 UDP 工作時，應確認協定、伺服器與路徑都支援。持續傳輸則要同時觀察吞吐量、其他請求的等待時間與裝置發熱，不要把單次峰值當成整體結論。

先確認 Global Routing，再調整協定

Global Routing 的三種設定模式為 Config、Proxy 和 Direct。Config 依目前設定的規則選擇策略；Proxy 會以代理模式處理相關流量；Direct 則採用直連。使用 Proxy 有助於比較部分規則的影響，但不足以作為完整診斷結論，仍須配合記錄確認實際請求。測試結束後應恢復日常使用的模式，避免將臨時排錯設定當成長期規則。

以下片段只示範規則語法與排列順序，不是完整設定，也不包含伺服器資訊。規則由上而下比對，FINAL 放在最後，用來承接先前未命中的請求。範例中的 PROXY 仍須在實際設定中對應可用策略。設定區段請參閱.conf 結構說明；命中順序請參閱自訂規則與 FINAL。

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

每次只驗證一個故障層次

完全無法連線時，先確認目前網路是否可用，再核對伺服器位址、連接埠與協定類型；接著查看錯誤是否指向 TLS、驗證或逾時。連線已建立但網頁無法開啟時，檢查 DNS 與目標請求採用的策略。只有部分服務異常時，檢查該服務是否需要 UDP、是否使用不同目標，以及大型封包或並行工作是否引發問題。不要同時更換 DNS、停用驗證、修改規則並重建伺服器。

建立簡短的測試紀錄，記下網路類型、選用紀錄、Global Routing 模式、目標工作與錯誤階段即可。切換 Wi-Fi 與行動網路時，保持其他設定不變；比較協定時，也盡量固定目標與工作內容。觀察耗電應涵蓋足夠長的正常使用時間，並留意螢幕亮度、背景工作與訊號強弱。短時間內的電量百分比變化，不足以證明某種協定天生更耗電。

整理記錄或截圖前，請刪除訂閱網址、驗證密碼、私密金鑰及可還原設定的內容。只保留相關時段、目標類型與錯誤描述，避免外傳整份設定。訂閱更新後若出現差異，先比較類型、位址、傳輸與驗證欄位，不要立即覆蓋所有本機設定。App 購買項目的復原屬於另一項流程，請參閱已購項目復原說明，不必透過重建協定紀錄處理。

最後將結論整理成可重複執行的步驟：確認一筆有效紀錄、保留原始資料、恢復日常規則，再驗證實際工作。若仍有異常，可閱讀已連線卻無法上網的檢查順序或常見問題；若要重新操作一次匯入流程，請返回快速入門教學。協定選擇至此形成完整流程：資料正確、路徑可連線、策略符合預期，且工作驗證通過。