Shadowrocket
協定類型與參數核對

01 · 選型前先區分四個資訊層次

協定名稱只回答其中一個問題

在 Shadowrocket 中，伺服器項目包含的不只是協定。位址與連接埠決定連線目標；Shadowsocks、VMess、VLESS 等類型決定雙方以何種方式交換代理請求；TCP、WebSocket 等傳輸方式決定資料如何承載；TLS 則涉及加密與憑證驗證。規則和策略屬於另一個層次，決定特定請求是否交由這個項目處理。四個層次都可能影響結果，但彼此不能取代。

因此，相同位址不代表可以任意切換類型。將 VLESS 改成 Trojan，即使連接埠和密碼看起來相近，伺服器也不會因此自動理解新的請求。伺服器必須確實提供相應入口，身分欄位、傳輸方式與安全設定也必須一致。本文所說的「選擇協定」，是從使用者已有且明確支援的項目中選擇，而不是把某個項目的類型名稱改成另一種。

依現有資訊建立核對順序

匯入現有訂閱後，先在 Home 查看項目，再進入編輯頁核對類型與伺服器位址。需要手動新增時，從 Add Server 選擇與伺服器說明一致的類型。不同類型會顯示不同欄位；欄位是否出現、可選值及實際位置，請以目前的 App 介面為準。不要只因某篇說明提到某個欄位，就把它填入名稱相似但用途不同的輸入框。

建議依序核對位址與連接埠、身分憑證、傳輸方式、安全設定，最後才檢查規則。這個順序對應故障發生的層次：位址錯誤時，連線尚未抵達目標；憑證錯誤時，無法通過身分驗證；傳輸方式不一致時，請求無法正確解析；憑證驗證失敗時，安全連線便無法建立。提前修改規則通常無法解決這些問題，還可能讓測試對象變得不明確。

分別確認用戶端、服務與商店資訊

Shadowrocket 是閉源商業 App。本頁著重介紹 iPhone 和 iPad。用戶端一次買斷 ≠ 連線方案：購買的是用戶端使用權，連線則需要使用者已有自己的訂閱或伺服器資訊。本網站不提供、不販售、不推薦節點或訂閱。現有訂閱是否有效、伺服器支援哪些協定，應以該訂閱附帶的說明為準，不能根據用戶端可顯示的類型反推。

iPhone 與 iPad 在 App Store 購買，其餘平台免費。需要購買或核對產品資訊時，請前往正版下載與核驗說明，確認開發者 Shadow Launch Technology Limited、官方圖示及 App ID 932747118。系統需求與購買適用範圍請以 App Store 頁面標示為準。連線失敗與購買狀態是兩類問題；App 能正常開啟，不代表伺服器資訊一定有效。

02 · Shadowsocks：加密方式與憑證配套

從輕量代理的設計目標理解參數

Shadowsocks 的設計初衷，是以相對簡潔的協定承載代理流量，並讓用戶端與伺服器透過共同約定的加密方式與密碼交換資料。它不會將整部裝置直接接入遠端區域網路，也不會自然規定網站請求必須經過代理。Shadowrocket 仍會依據目前的 Global Routing 狀態和設定規則決定請求的去向；協定負責處理的是交由它傳送的流量。

這種分工讓核心欄位相對集中：伺服器位址、連接埠、加密方式和密碼是首先要核對的項目。設定簡潔不代表欄位可以猜測，尤其不能只憑密碼正確就認定身分設定完整。加密方式是協定雙方解讀資料的約定；選錯時，伺服器可能收到連線，卻無法解析內容，表現可能與密碼錯誤相似，通常無法靠重複連線自行恢復。

為什麼要一起檢查 Method 與 Password

現代部署常使用具備驗證功能的加密方式，同時檢查內容是否遭到竄改。不同方式對金鑰長度、衍生方式與資料格式各有要求。填寫時請保留伺服器提供的完整方式名稱，不要把名稱中相似的部分視為同一種方式，也不要把某個項目的密碼複製到另一個項目後，就假定兩者可以互換。不同協定變體的憑證格式也可能不同。

較新的 Shadowsocks 變體可能使用特定編碼和長度的金鑰，而非任意口令。此時，密碼欄位中的字串看起來雖像一般文字，實際上卻是格式受規範的金鑰材料。請勿自行縮短、補齊或重新編碼。若匯入成功但手動重建失敗，先檢查複製時是否漏掉末尾字元、混入換行，或把連結跳脫後的文字誤當成原始憑證。

UDP 與額外傳輸設定不能只憑名稱推斷

部分 App 流量會使用 UDP。TCP 網頁能載入，只能表示該項目的相關路徑可用，不能證明 UDP 也可用。還要確認伺服器端是否允許相應轉送、目前網路能否傳送資料，以及用戶端項目的相關設定是否符合既有說明。若把 UDP 故障直接判定為「整個協定不穩定」，就可能忽略伺服器端限制或網路路徑差異。

部分現有項目還包含額外傳輸設定。請逐項確認這些設定的實際用途，不要看到 Shadowsocks 就預設它們不存在。附加層與核心協定是不同的核對對象：核心密碼正確，附加層參數錯誤仍會造成連線失敗；刪除不熟悉的參數，也可能破壞原本完整的入口。先使用訂閱匯入的原始項目，比手動精簡更容易重現問題。

如何在 iPhone 上判斷是否合適

條件相同時，封裝層較少可能降低部分處理負擔，但不代表速度或耗電一定更好。實際體驗還取決於加密實作、裝置處理能力、伺服器負載、封包遺失與往返延遲。短時間的網頁測試主要反映連線建立與小量資料傳輸；持續傳輸檔案則觀察吞吐量。兩種測試可能帶來不同的主觀感受，建議分開記錄。

現有 Shadowsocks 項目若能穩定處理日常請求，無須只因另一種協定名稱較新就更換。若可以連線但特定 App 失敗，先區分網域解析、TCP 與 UDP 路徑，再檢查規則是否讓該 App 使用不同策略。若所有請求都失敗，優先回頭核對位址、連接埠、加密方式和密碼，不要先調整耗電相關設定。

03 · VMess 與 VLESS：身分、傳輸與 TLS

欄位相似不代表協定相同

VMess 將身分驗證與協定本身的資料保護機制結合，常見的身分欄位是 UUID。VLESS 則採用更精簡的身分與請求描述，將更多連線安全交由外部安全層處理。兩者都可以搭配不同傳輸方式，因此編輯頁可能出現相似欄位，但不能透過更換類型互相轉換。使用哪一種，必須與伺服器實際提供的入口一致。

了解這種設計取捨，有助於避免把「欄位較少」直接等同於「更安全」或「更快」。VLESS 本身不提供與 VMess 相同的內容加密機制，部署時須確認外層如何保護連線；VMess 有自己的安全機制，也不代表可以忽略外層傳輸參數。評估項目時，應把協定、傳輸與安全設定視為完整組合，而不是只看名稱。

UUID 是身分資訊，不是顯示名稱

UUID 應逐字保留原值。項目名稱可用來區分地區或用途，改名通常不會影響驗證；UUID 則直接參與身分核驗，任意修改會讓伺服器無法辨識。複製時請留意連字號、前後空格與自動換行。多個項目使用相同 UUID，也不能證明它們的位址、連接埠及其他設定相同；每個項目仍須完整核對。

VMess 的驗證也涉及時間資訊。裝置時間明顯有誤時，可能出現參數看似正確卻無法驗證的情況。請先在系統設定中確認日期與時間合理，再檢查伺服器憑證；不要透過頻繁修改 UUID 來測試。若現有資訊包含其他相容欄位，請依伺服器說明填寫，不要混用不同年代範例中的數值。

WebSocket 的 Host、Path 與 TLS 的 SNI

WebSocket 會在相應連線上承載代理資料，常見核對項目包括 Host 與 Path。Path 必須符合伺服器路由；開頭斜線、大小寫與尾端路徑都可能有影響。Host 用於相關請求的主機資訊，伺服器可能依此將請求交給不同入口。這兩項設定錯誤時，即使目標連接埠能建立連線，後續協定交握仍可能失敗。

SNI 是 TLS 交握時使用的伺服器名稱資訊；憑證驗證則須確認預期名稱與憑證相符。伺服器連線位址、WebSocket Host 與 SNI 在部分部署中相同，在其他部署中則可能不同；不要自動把三個輸入欄位填成同一個值。即使透過 IP 位址建立底層連線，也可能仍須使用伺服器說明提供的網域，才能建立正確的安全連線。

以完整入口組合為單位選型

部分 VLESS 組合還需要 Flow 或特定安全參數。只有伺服器明確要求，且目前用戶端也提供相應選項時，才填寫這些欄位。不要因為另一個可用項目設定了某個值，就把它照抄到所有 VLESS 項目。不同組合的限制各不相同，留白也可能是正確設定；判斷依據始終是目前伺服器入口的設定資訊。

在 iOS 上比較兩者時，先控制傳輸與安全層的差異。某個項目使用直接 TCP，另一個使用多層封裝，測試結果就不能只歸因於 VMess 或 VLESS。若原始訂閱項目可用，但手動設定的項目失敗，請逐項比對 UUID、傳輸、Host、Path、TLS 與 SNI。只有整套組合都一致，比較處理負擔才有實際意義。

04 · Trojan、HTTP 與 SOCKS5：安全界線

Trojan 著重 TLS

Trojan 常見的設計是在 TLS 連線中承載代理請求，再透過密碼等資訊識別使用者。它採用成熟的安全傳輸機制，但用戶端仍須正確設定伺服器位址、連接埠、密碼與驗證名稱。能連上連接埠，只能表示底層路徑存在；密碼正確也無法略過憑證名稱不符的問題。排錯時，應將交握失敗與身分驗證失敗分開處理。

網域、SNI 與憑證之間的關係尤其重要。憑證應涵蓋預期的服務名稱，並處於有效且受信任的狀態。若連線位址與驗證名稱不同，請依伺服器資訊分別填寫。發生憑證錯誤時，先核對裝置時間、名稱與伺服器端憑證鏈；不要把關閉驗證當成一般修復方式，因為這會削弱辨識連線對象的能力。

HTTP 代理不代表所有流量都受到保護

HTTP 代理源自應用層代理需求，可轉送請求，也常透過 CONNECT 為目標建立位元組通道。項目常見欄位包括位址、連接埠、使用者名稱與密碼。這裡須區分兩段連線：裝置到代理伺服器，以及 App 到目標網站。目標網站使用 HTTPS，不代表裝置到代理的身分資訊也受到相同方式保護；外層是否使用 TLS，必須另外確認。

因此，現有說明若標示 HTTP，不要自行假設它等同於使用 TLS 的代理入口；若說明要求安全傳輸，也不要只填寫一般代理欄位。兩端支援方式不同，交握就可能不相符。使用者名稱與密碼是否正確、代理是否允許 CONNECT、是否限制目標連接埠，都可能造成「部分網站可用、部分失敗」的情況。

SOCKS5 提供通用交涉機制，但本身不加密

SOCKS5 透過交涉機制描述目標位址與連線需求，可使用使用者名稱和密碼驗證，也定義了 UDP 相關機制。它本身不會加密所有承載內容。身分驗證與內容保密是不同能力，不能因為項目要求密碼，就認定連線已加密。實際安全界線還取決於網路環境、外部安全層與 App 本身的連線保護。

SOCKS5 項目可以連線，不代表 UDP 一定可用。伺服器可能只允許 TCP，網路也可能無法傳送 UDP 關聯所需的資料。另一個需要釐清的問題是網域解析發生在哪裡：App、用戶端設定與代理請求形式都會影響實際路徑。若網域連線失敗，但直接使用位址測試結果不同，應檢查 DNS 與規則，不要只反覆修改代理密碼。

依現有環境選擇，不按名稱評比安全性

若現有環境只提供某種代理入口，應先確認其傳輸保護與存取權限，再判斷是否符合用途。用戶端的類型選項無法替伺服器增加 TLS，也不能把 HTTP 改成 SOCKS5 來解決驗證失敗。使用由組織管理的既有入口時，也須遵守其存取範圍與裝置使用規則，避免把用途有限的代理誤當成通用通道。

在 iPhone 上，這幾種型別的速度差異常被網路路徑掩蓋。交握次數、連線重用、伺服器回應與無線網路狀態，都可能比協定解析負擔更明顯。正確比較方式是使用相同任務與相近環境，並先確認各項目的安全設定完整。若某個項目只有在略過憑證驗證後才能使用，應修正伺服器資訊，而非把這個結果當成效能優勢。

05 · WireGuard：金鑰、位址與隧道範圍

從網路層隧道理解其差異

WireGuard 的設計目標是以相對精簡的協定與固定的現代密碼組合建立網路層隧道。不同於以代理請求描述目標的協定，它處理的是隧道中的 IP 封包。這項差異會反映在設定欄位上：除了遠端位址，還須了解本機隧道位址、雙方金鑰，以及允許透過對端傳送的位址範圍。一般代理的密碼填寫方式不能直接套用。

在 Shadowrocket 中使用 WireGuard 時，仍須將項目本身的隧道參數與用戶端的規則決策分開。項目定義如何與對端通訊，Global Routing 和設定則決定哪些請求交由它處理。看到隧道內位址，不代表裝置上的每個請求都已如預期透過隧道；用戶端連線開關已開啟，也不能證明遠端已允許存取所需目標。

Private Key、Public Key 與 Endpoint

Private Key 屬於本機身分資料，應妥善保密；對端的 Public Key 用於識別遠端。兩者不是同一字串的不同顯示名稱，也不能對調。若現有設定還包含 Preshared Key，它就是額外的共用金鑰，雙方必須一致。排查時只需記錄欄位是否存在及是否相符，不要將完整金鑰複製到公開截圖、日誌說明或問題留言中。

Endpoint 指向可連線的遠端位址與連接埠，不等於隧道內部位址。設定中的本機位址則用於隧道內通訊，也不能任意挑選一個私有位址。伺服器端必須識別相應用戶端及其位址關係，重複使用不適合的位址或身分可能造成衝突。新裝置能否沿用同一組資訊，應依使用者現有伺服器的設定規則確認。

Allowed IPs 與路由並非同一張表

Allowed IPs 涉及對端可承載的位址範圍，也與隧道內部的選路和來源限制有關。它與 Shadowrocket 的 DOMAIN-SUFFIX 等規則屬於不同層次。即使外層規則已將某個請求交給 WireGuard，若隧道或遠端未允許相關位址範圍，流量仍可能失敗。反過來說，隧道允許某個範圍，也不代表用戶端必定會將所有相關請求交給它。

存取現有內部資源時，還須檢查遠端轉送、目標回程路徑與名稱解析。隧道交握成功，但目標裝置不知道如何回傳資料，請求仍會逾時。若只有網域連線失敗，但相應內部位址可達，請優先檢查內部 DNS 的可達性與解析設定；若所有內部位址都無法連線，再檢查位址範圍、遠端權限與路由。

MTU 與 Persistent Keepalive 的取捨

MTU 限制單一隧道封包可承載的大小。封裝會增加額外位元組，傳輸路徑本身也可能有限制；設定不當時，可能出現小型請求成功、大量傳輸停滯的情況。不要一遇到卡頓就不斷調低數值，應先確認故障是否與封包大小有關，並保留原值。調整後請以相同目標和傳輸任務重新測試，避免將短暫網路波動誤認為 MTU 調整的效果。

Persistent Keepalive 用於在某些網路位址轉換環境中維持對應關係，但定期傳送封包也會增加無線活動。週期越短不代表越穩定，也不是所有網路都需要。只有在閒置後回程路徑失效，且現有設定允許調整時，才有理由評估此項。在 iPhone 的行動網路環境中，也須將喚醒成本納入觀察，不能只看重新連線是否比較快。

06 · Hysteria2：UDP 路徑與頻寬估算

設計重點在於有損路徑上的傳輸表現

Hysteria2 以 QUIC 建構代理傳輸，而 QUIC 通常運行於 UDP 之上。其關注重點包括如何在有封包遺失和較長往返延遲的路徑上維持傳輸效率。此處的「有損」描述的是網路條件，不代表所有行動網路都有相同特性。是否適合目前環境，應先確認 UDP 路徑可用，再觀察實際任務，而非依協定名稱預先判斷速度。

QUIC 結合安全交握與傳輸機制，並允許多個資料流共用一條連線。不同資料流可減少部分因單一有序位元組流而互相等待的情況，但仍會受到共用鏈路壅塞、無線封包遺失與伺服器資源限制。它無法增加實際頻寬，也不能讓遠端回應變快。網站載入緩慢，仍可能是 DNS、規則或目標網站本身的問題。

先核對驗證與憑證，再檢查效能參數

基本欄位通常包括伺服器位址、連接埠、驗證資訊與 TLS 相關設定。驗證值必須完整使用現有資訊，不能只因其他協定的 UUID 或密碼外觀相似就直接替換。SNI 與憑證驗證仍須正確；QUIC 使用 UDP，不代表可以忽略伺服器身分。憑證錯誤與 UDP 無法連通的表現可能不同，排查時應分別記錄。

若現有伺服器要求額外的 Obfuscation 方式或密碼，用戶端與伺服器必須設定一致。這是符合入口設定的一部分，不是隨意啟用就能改善效能的按鈕。沒有明確設定時不要自行新增；現有設定包含此項時也不要任意刪除。連接埠範圍或切換連接埠，同樣需要遠端明確支援；只修改單一數值不會自動建立新的可用入口。

頻寬欄位代表估算值，不是速度保證

部分傳輸模式會使用使用者填寫的上行、下行頻寬資訊來控制傳送。這些數值應從用戶端視角理解方向，並仔細核對單位。填入更大的數字不會增加實體鏈路容量，反而可能使傳送速率與實際路徑不符，造成排隊、封包遺失與波動。數值太小則可能限制有效利用率，須依目前模式判斷。

不同網路的可用頻寬會變動，家中 Wi-Fi 的結果不能直接代表行動網路。測試前請先使用現有設定提供的基準，不要同時修改上行、下行及其他傳輸參數。若目前介面或伺服器採用自動估算方式，應依該方式的說明處理，不要照搬另一種模式的必填要求。了解參數意義比追求更大的數字重要。

辨識 UDP 路徑受限的情況

若一般網頁在不經過該項目時可以正常使用，而 Hysteria2 一直無法完成連線，可能需要檢查目前網路對 UDP 的支援、伺服器連接埠及遠端運作狀態。但單憑逾時不能立即斷定是 UDP 受限，也可能是位址解析、驗證或安全設定錯誤。可以在另一個可信任的網路環境中，使用同一個原始項目重新測試，以縮小路徑因素的範圍。

若連線已建立，但持續傳輸明顯波動，先觀察是否有無線訊號變化、上行頻寬用盡或裝置過熱。較積極的傳送方式在特定路徑上可能提升吞吐量，也可能增加重傳、無線活動與耗電。對行動裝置而言，應同時記錄每項任務的完成時間與耗電；只看到短暫的峰值，無法判斷它是否適合長時間使用。

07 · 在 iOS 上分開觀察速度與耗電

把「快」拆解為三項可觀察結果

首次開啟頁面的等待時間、持續傳輸的吞吐量，以及長連線的穩定性，是三項不同指標。等待時間包含 DNS、底層連線建立、協定交握、安全交握與目標回應；持續吞吐量較受瓶頸頻寬、壅塞控制與伺服器負載影響；長連線則可能受到網路切換、閒置逾時與背景狀態影響。不能用單一延遲數字概括這三者。

Connectivity Test 的結果取決於使用的測試方式與目標，適合用來判斷特定可達性或相對變化，不等同於實際 App 的完整連線路徑。測試成功但頁面仍無法載入時，還需要檢查 DNS、規則與目標請求。如何解讀測試結果，請參閱延遲測試與實際載入體驗說明，避免只憑最低數字判斷是否可用。

比較協定時應控制哪些變因

盡可能使用相同裝置、相同網路、相近時段與相同目標進行比較。若兩個項目位於不同遠端位置、使用不同線路或負載差異明顯，結果首先反映的是兩條完整路徑，而非單純的協定差異。若現有條件無法控制，可以記錄實際體驗，但結論應描述為「這個項目在目前網路下的表現」，不要推論成某種協定始終較快。

每輪只改變一項因素，並分別觀察短請求與持續任務。首輪結果可能受到快取、交握與無線狀態影響；重複測試時應保留間隔。持續以滿載頻寬測試會改變裝置溫度與網路壅塞，反過來影響結果。若測試期間切換 Wi-Fi、進入訊號較弱的區域或發生其他大量傳輸，應將該輪視為不同條件，不可直接合併比較。

耗電來自資料量，也來自無線活動

加密與封裝需要處理時間，但行動裝置的耗電還會受到訊號強度、無線喚醒、重傳、螢幕與背景工作的影響。某種協定處理負擔較低，不代表實際總耗電一定較少。如果連線頻繁失敗並重試，或維持連線的封包讓無線模組持續運作，額外耗電可能超過協定演算法本身的差異。應觀察整項任務完成後的整體結果。

觀察耗電時，先區分持續播放影片、主動傳輸與閒置維持連線。持續任務可比較完成相同工作所需的時間與電量變化；閒置情境則應留意是否有不必要的定時測試、保活與重新連線。系統電池用量統計提供的是一段時間內的活動線索，不是嚴謹的協定耗電實驗。短時間內百分比沒有變化，也不能證明沒有額外耗電。

On Demand 與連線重用的界線

On Demand 會依網路條件控制連線觸發，不會讓伺服器協定自動適應錯誤參數。先透過手動連線建立穩定基準，再新增觸發條件，才能區分協定連線失敗與自動觸發未發生。設定條件時可參閱On Demand 網路條件說明，測試時也要記錄網路變化與連線狀態。

連線重用可以減少反覆交握，但也可能使多個請求共用同一連線的壅塞或故障狀態。是否啟用，應遵循現有伺服器的支援範圍與目前介面說明。少數請求卡住時，不能只因「重用通常比較快」就排除其影響；應保留原始項目，在相同任務中進行單一變因對照，並確認結果能否重現。

08 · 依情境選型，再按層次排錯

依用途篩選現有項目

日常瀏覽首先需要短請求穩定、名稱解析正常且安全設定完整；現有可用項目就是合理起點。持續傳輸應觀察穩定吞吐量與裝置溫度，而非只看首次測試。存取現有內部網路時，WireGuard 的位址範圍與回程路徑可能是關鍵；若路徑存在封包遺失，也可評估現有的 Hysteria2 項目，但前提是 UDP 可用。以上是檢查方向，不是協定優劣排名。

若現有資訊只提供一種協定，先正確設定這一種即可，不必為了比較而尋找其他入口。若同時提供多種完整項目，請先保存各自的原始設定，再依實際用途分別測試。不要把一個項目的 TLS、另一個項目的 Path 和第三個項目的憑證拼在一起；混合設定造成的失敗，無法用來判斷任何一種協定是否合適。

先確認 Global Routing 的測試模式

設定模式 Config 會依設定檔規則選擇策略；代理模式 Proxy 會將相應流量交由代理路徑處理；直連模式 Direct 則依直連路徑處理。切換模式會改變測試流量的去向，因此每輪都必須記錄目前選項。Proxy 仍受項目與請求能力的限制，無法修正錯誤憑證；Direct 可作為路徑對照，但不代表所有請求都一定成功。

確認協定項目正常後，再回到 Config 檢查規則順序。以下是用於說明比對邏輯的 .conf 片段，不是通用設定；PROXY 策略必須能在實際設定中正確解析。規則通常依順序比對，FINAL 用於處理前面規則都未比對到的請求。網域規則與 IP 規則依賴不同資訊，DNS 解析也可能影響最後的比對結果。

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

這個範例會將 example.com 及其子網域交由 PROXY，並將指定的私有位址範圍與 GEOIP 比對到的位址交由 DIRECT。這不代表所有環境都應採用相同策略；GEOIP 判斷也取決於位址與所用資料。若要了解區段名稱與設定範圍，請繼續閱讀.conf 各區段用途說明，不要以更改協定取代修正規則比對錯誤。

依故障發生位置縮小排查範圍

完全無法連線時，先核對目前網路、位址解析、連接埠與伺服器狀態，再檢查身分欄位。若有明確的憑證問題，請檢查時間、SNI、名稱與憑證鏈；若建立連線後才失敗，則繼續檢查傳輸入口、目標存取權限與轉送能力。只有部分網域異常時，優先核對 DNS、規則比對結果與目標狀態，不要立刻重建所有項目。

若網頁正常但某類即時 App 失敗，分別確認 TCP 與 UDP；若小型請求正常但大量傳輸停滯，觀察 MTU、重傳與壅塞；若閒置後失效，檢查映射逾時與保活需求；若只在切換網路後發生，記錄切換前後的位址與連線恢復情況。每次只修改相關設定，使用相同任務重新測試，確認成功後再恢復其他自動化條件。

記錄排查結果，但不要洩露憑證

實用的排錯紀錄應包含協定類型、傳輸方式、網路條件、失敗階段、目前 Global Routing 模式，以及可重現的目標現象。Password、UUID、Private Key 與完整訂閱位址不應放入公開紀錄。App 日誌或截圖可能包含這些資訊，分享前應逐項檢查，不要只遮住項目名稱；名稱通常不是最敏感的欄位。

最後應保留的結論是「哪個完整項目適合哪種任務，以及在哪種網路下測試成立」，而不是抽象的速度排名。首次操作請回到教學主線，常見狀況可查閱常見問題，購買與復原 App 則請查看App Store 核驗說明。將購買、匯入、協定連線與規則比對分開處理，下次排錯才能從已確認的層次接續，而不必重新猜測。