設定分層:協定名稱不等於完整連線方案
先區分代理協定、傳輸方式與安全層
用戶端中的一筆伺服器設定,至少涉及三個問題:用什麼協定表示目標位址與身分、透過什麼傳輸方式承載資料,以及如何建立安全連線。VMess、VLESS、Trojan、Shadowsocks 主要處理第一個問題;TCP、WebSocket、gRPC 等屬於第二個問題;TLS 與 REALITY 則是安全連線相關選項。介面可能將這些欄位放在同一個編輯表單中,但它們並非可以互相替換的同類選項。只知道伺服器使用 VLESS,還不足以還原連線設定。
例如,兩筆設定都標示為 VLESS,其中一筆使用 TCP 與 REALITY,另一筆使用 WebSocket 與 TLS;兩者的握手流程、必填欄位和伺服器接入方式都不同。把第一筆設定的公鑰複製到第二筆,或把第二筆的路徑填入第一筆,通常無法解決問題。較可靠的記錄方式是分別寫明協定、傳輸方式和安全層,再另外記下位址、連接埠與驗證資訊。即使用戶端介面名稱有所變動,也能依據欄位含義進行檢查。
區分伺服器位址與握手名稱
伺服器位址決定連線最初要前往何處,可以是網域名稱,也可以是 IP 位址。TLS 中的伺服器名稱通常以 SNI 欄位表示,用於握手及憑證身分驗證;它不必與位址欄中的字串完全相同,但必須符合伺服器端的部署設定。WebSocket 的 Host 則屬於 HTTP 要求標頭,路徑用來指定接入端點。這些欄位有時會填入相同網域,因此容易被誤認為重複項目。排除問題時應分別核對,不要只修改位址欄,就以為其他名稱也會自動同步。
本機入口、系統代理與路由則屬於另一組設定。本機入口負責接收應用程式的連線;系統代理只是讓部分應用程式將要求交給這個入口;路由才決定流量進入核心後要走哪個出站。如果應用程式沒有使用系統代理,修改協定加密方式也不會讓流量自動進入核心;如果路由規則命中直連,更換伺服器也不會改變這條連線的出站方式。Android 的 VPN 接管機制與桌面系統代理不同,因此應比較兩者的作用範圍,而不是照搬所有開關設定。
| 設定層級 | 常見欄位 | 主要檢查項目 |
|---|---|---|
| 身分與目標表示 | 協定、UUID、密碼 | 雙方驗證與協定實作 |
| 傳輸承載 | TCP、WebSocket、gRPC | 接入方式、路徑、服務名稱 |
| 安全連線 | TLS、REALITY、SNI | 憑證或公鑰及握手參數 |
| 本機流量處理 | 入站、路由、DNS | 應用程式接入與出站選擇 |
只做必要變更,保留排查線索
匯入後先保留原始設定,再逐項調整本機行為。位址、驗證、傳輸與安全參數應以伺服器提供的資訊為準;本機連接埠、應用程式範圍和記錄檔等級則可依裝置需求設定。一次同時更換協定、DNS 和路由,會讓成功或失敗都難以判讀。建議複製設定作為對照,每次只變更一個項目,並記錄錯誤發生在啟動、握手或存取階段。欄位簡要說明請參閱術語表;首次匯入的完整操作仍以入門指南為主。
VMess:驗證、時間與加密方式
設計背景與連線成本
VMess 是 Project V 生態系早期的重要代理協定,將身分驗證、要求描述與資料保護納入協定設計。它不是替一般 TCP 連線加上名稱,而是要求用戶端與伺服器依照一致格式處理要求。選用 VMess 的優點是生態系成熟、支援多種傳輸組合;需要留意的是協定本身的加密與外層安全連線之間的關係。遇到舊設定時,也要分清歷史驗證方式與目前的實作,不能把所有 VMess 連結都當成相同格式。
VMess 的速度不能只看有沒有加密。一次存取包含本機解析、傳輸連線、驗證與遠端轉送;如果外層再加上 TLS,也會增加相應的握手作業。現代處理器對常見加密演算法的硬體支援程度不一;小型要求可能主要受往返時間影響,長時間下載則較容易顯現持續傳輸量的限制。因此,若發現 VMess 比另一條連線慢,應先確認兩者的線路、伺服器負載與傳輸方式相同,再討論協定處理成本。
UUID、加密與 alterId 的適用範圍
編輯 VMess 設定時,UUID 是身分資訊,不是節點備註,也不是用戶端自行產生後就能直接使用的隨機字串。加密方式必須受雙方實作支援;用戶端提供的自動選擇功能,通常是依執行環境挑選合適的演算法,不會自動修正驗證錯誤。不要為了降低負載而隨意選擇不提供資料加密的模式。外層 TLS 與協定本身的保護各有不同用途,是否採用特定組合應依明確的部署設計決定,不能把「少一層」當成通用最佳化原則。
舊版教學常會提到 alterId。它與歷史相容機制有關,現代 VMess AEAD 設定通常使用零值,用戶端也可能已隱藏此欄位。若訂閱仍帶有非零值,不要只把數字改成零就認定已完成遷移,因為伺服器端必須支援相應的驗證方式。正確做法是先確認服務提供者的設定要求,再檢查目前的核心是否能處理該格式。舊參數若長期保留,可能造成匯入成功但連線失敗;介面沒有顯示語法錯誤,也不代表雙方驗證方式一致。
系統時間與傳輸欄位的檢查順序
VMess 驗證會用到時間,因此系統時間明顯錯誤可能導致要求遭到拒絕。排查時先開啟系統自動校時,確認日期與實際時間,不要只檢查介面顯示的時區;時區顯示不同不一定代表系統時鐘錯誤。接著核對 UUID、連接埠,以及伺服器是否仍接受目前的設定。確認驗證資訊正確後,再檢查 WebSocket 路徑、Host 或其他傳輸欄位。如此可避免把驗證問題誤判為線路不通。
透過 VMess 連結匯入時,也要留意連結中的欄位如何對應至用戶端編輯頁。部分舊版連結會以舊欄位表示傳輸名稱、TLS 開關與主機名稱,匯入工具也可能依自身規則補上預設值。建議檢查匯入後的實際設定,特別是位址、SNI、路徑和加密方式,不要只看清單中的協定標籤。如果同一筆設定在另一台裝置上可以使用,應比較欄位與核心記錄,而不是反覆刪除後重新貼上同一條連結。
VLESS 與 REALITY:分開看輕量協定和安全握手
VLESS 簡化協定本身的職責
VLESS 的設計取捨是簡化協定本身的驗證與要求處理,不像 VMess 一樣在基礎協定中提供同類型的資料加密機制。常見設定中的 encryption 為 none,表示這一層的處理方式,不代表整條連線必然以明文傳輸。是否具備安全保護,還要看外層使用 TLS 或 REALITY,以及相關驗證是否正確啟用。這種分層方式便於組合,但使用者也應避免將單一欄位的含義套用到整條連線。
因此,不能把 VLESS 簡化成「少了加密,所以一定更快」。減少部分協定處理只是成本之一;TLS 或 REALITY 仍需執行握手與資料保護,傳輸封裝也可能成為主要負擔。VLESS 是否適合目前的裝置,取決於伺服器提供的組合、核心實作與網路狀況。選擇桌面用戶端時,先確認 v2rayN 使用的核心支援完整參數;Android 則要確認用戶端核心與設定類型相符,不能只因為能辨識 UUID,就推斷所有功能都可用。
REALITY 不是獨立的代理協定
REALITY 是 Xray 生態系中的安全連線方案,常與 VLESS 搭配使用。用戶端通常需要伺服器公鑰、伺服器名稱、shortId 及相應的指紋設定;這些資訊會共同參與握手,不能直接從一般 TLS 設定推導。它與憑證網域驗證的設定方式不同,但不代表可以忽略身分驗證。用戶端只應保存連線所需的公開參數;伺服器私鑰不應出現在訂閱、螢幕截圖或用戶端輸入欄位中。
公鑰看起來像一串可複製的文字,但內容必須與伺服器金鑰相符;shortId 則必須符合伺服器允許的值與格式。伺服器名稱也必須符合部署要求,不能隨意填入一個可存取的網域。指紋選項用於相關握手行為,是相容性參數,不是地區選擇或速度等級。若匯入工具漏掉其中一項,設定可能仍會出現在清單中,卻在握手階段失敗。應逐項與原始參數核對,而不是關閉驗證來規避錯誤。
flow 與傳輸方式不能任意組合
VLESS 中的 flow 用來描述特定流控方案,例如 XTLS Vision 相關值。它不是通用的加速按鈕,也不適用於所有傳輸組合。伺服器要求使用 Vision 時,用戶端必須支援該方案,並採用相容的傳輸方式與安全層;若伺服器未設定相應 flow,自行加入反而可能導致連線失敗。網頁教學截取的一段參數只適用於原本完整的組合,不能脫離上下文複製到 WebSocket 或其他不同的接入方式中。
實際檢查可依照「協定與 UUID—傳輸方式—安全層—公鑰及名稱—shortId—flow」的順序進行。先在編輯頁確認欄位沒有被預設值取代,再查看核心記錄,判斷是參數解析失敗還是遠端握手失敗。前者通常表示實作不支援或欄位格式錯誤;後者則要繼續核對伺服器要求與網路連線狀況。如果更新訂閱後突然失敗,應保留舊設定以比較欄位差異,避免將所有問題都歸因於公鑰變更。
Trojan 與 Shadowsocks:TLS 依賴與加密方法
Trojan 以 TLS 建立安全連線
Trojan 的典型連線會先建立 TLS,再進行協定驗證與資料轉送。對用戶端使用者而言,重要欄位包括伺服器位址、連接埠、密碼與伺服器名稱。它的設定表面上比某些組合簡短,但 TLS 仍有明確的身分驗證要求。憑證名稱不符、憑證鏈異常或系統時間錯誤,都可能在檢查密碼之前中斷連線。因此,Trojan 連線失敗時,不要一開始就反覆更換密碼,應先確認記錄停在哪個階段。
若位址使用 IP,而憑證是簽發給網域名稱,通常需要依照伺服器端說明填入正確的伺服器名稱。SNI 用於在握手中表示名稱,憑證驗證則用來確認對方身分;兩者相關,但不是同一個開關。啟用略過憑證驗證會削弱身分確認,不應作為一般修復方式。若伺服器採用特殊信任方案,應依照明確的信任設定處理;一般公開憑證部署則應優先修正時間、名稱或憑證鏈,並保留正常驗證流程。
Shadowsocks 的方法名稱是協定條件
Shadowsocks 常簡稱為 SS,設計上著重精簡的代理轉送與加密處理。用戶端需要伺服器位址、連接埠、密碼和加密方法。方法名稱不是可由用戶端自行選擇的效能設定,而是雙方必須一致的協定條件。即使密碼正確,只要方法不符仍會連線失敗。舊版設定與較新的協定變體,可能使用不同的金鑰要求,因此不能把所有標示為 SS 的設定都當成只要交換密碼便能互通的相同格式。
傳統 AEAD 方法與 Shadowsocks 2022 系列在金鑰處理等方面有所不同。後者使用的方法名稱和編碼金鑰要求,應由伺服器端或訂閱提供,不適合直接填入任意短密碼。是否支援特定方法,取決於目前執行的核心,而不只是用戶端介面是否列出 Shadowsocks。若匯入時顯示方法未知,應先核對拼寫與核心支援情況;將方法改成另一個熟悉的名稱,不會讓伺服器自動改用新演算法。
傳輸組合與 UDP 需求
Trojan 或 SS 在不同部署中可能搭配額外的傳輸參數,但不能假設一般分享連結都能完整表達各種擴充設定。特別是 SS 連結中的附加參數,匯入工具未必全都支援。請先確認服務提供者要求的組合能否由目前使用的三款用戶端及其核心表示,再決定是否採用。如果匯入後擴充參數消失,應視為相容性問題,而不是繼續用缺少欄位的設定測試線路速度。
若有語音、遊戲或其他資料報需求,還應另外驗證 UDP 路徑。協定具備 UDP 能力,不代表本機入口、用戶端接管方式、伺服器轉送與目標網路都允許資料報通過。TCP 網頁存取成功,只能證明相應要求的連線路徑可用。測試時應使用確實依賴 UDP 的應用程式並觀察記錄,分辨應用程式未進入核心、伺服器未轉送,或目標沒有回應。不要因為某個網頁能開啟,就把 UDP 問題歸咎於應用程式本身。
| 協定 | 優先核對項目 | 常見誤解 |
|---|---|---|
| Trojan | TLS 名稱、憑證、密碼 | 用略過驗證取代修正名稱 |
| Shadowsocks | 方法、密碼或金鑰格式 | 自行更換方法以求加速 |
速度、資源與耗電:區分握手和持續傳輸
連線快和下載快是兩回事
開啟簡短網頁主要受解析、建立連線、握手與等待第一個位元組影響;持續下載則更多取決於線路容量、壅塞控制、伺服器出口與裝置處理能力。某種協定減少握手作業,可能改善短連線體驗,卻不一定提升長連線的傳輸量。反過來說,下載表現良好的線路,也可能因解析或握手等待而讓網頁載入變慢。因此比較協定時,至少應分開記錄連線成功率、首次回應時間與穩定傳輸表現,不能只用一個延遲數字概括所有體驗。
TCP、WebSocket 與 gRPC 帶來不同的封裝方式與連線管理行為,但實際影響取決於實作與部署。WebSocket 會增加 HTTP 升級與訊框處理,gRPC 則仰賴相應的 HTTP/2 行為與伺服器支援;採用這些方式通常是為了配合接入架構,而不是要在所有線路上降低延遲。封包遺失、壅塞與中間設備的處理方式也會影響結果。若橫向測試沒有控制線路與伺服器條件,只能評估該組連線,不能據此排出固定的協定速度名次。
CPU、記憶體與連線複用的限制
加密演算法能否使用處理器指令、核心緩衝策略、作用中的連線數與記錄輸出量,都會影響資源使用情況。桌面裝置在低負載時,協定間的差異可能被瀏覽器與系統工作掩蓋;小型裝置在長時間高傳輸量下,則較容易遇到溫度限制。觀察資源使用時,應同時查看實際傳輸量與持續時間:相同的 CPU 百分比,對應的資料量可能截然不同。不要把用戶端介面程序的資源使用量當成核心的全部消耗,兩者有時是不同程序。
連線複用嘗試讓多個邏輯要求共用較少的底層連線,可能減少重複建立連線的成本;但在壅塞、長短要求混合或實作不相容時,也可能增加等待時間。它不是適用於所有協定的整體最佳化方式。先保留預設設定,只有在確實有大量短連線且伺服器支援時,再進行對照測試;若啟用後出現間歇性停頓,應恢復為獨立連線的基準設定。若路由、DNS 和傳輸方式同時變動,就不能把結果全歸功於連線複用開關。
Android 耗電主要受喚醒與重新連線影響
行動裝置耗電除了加密作業,也會受到無線網路維持活躍、背景喚醒、保活頻率與失敗後重新連線影響。看似較省運算的協定,如果經常斷線並重新建立安全連線,最後可能反而更耗電。切換行動網路與 Wi-Fi 時,重建連線也會增加額外成本。評估 v2rayNG 或 v2flyNG 時,應在訊號強度、螢幕使用時間與應用程式負載相近的情況下觀察,不宜把單次背景耗電排名直接當成某種協定固定的耗電特性。
VpnService 負責接管 Android 流量,不代表核心已成功連線。省電限制可能在鎖定螢幕後中斷背景處理,表現為喚醒螢幕後恢復;個別應用程式設定也可能讓部分應用程式完全不經過核心。先檢查系統背景限制與流量接管範圍,再考慮更換協定。相關操作請參閱v2rayNG 權限、省電與個別應用程式設定。測速方式的差異請參閱延遲測試原理,不要以 ICMP 結果取代實際代理要求。
V2Fly 與 Xray:系列關係及設定相容性
圖形用戶端與核心的分工
Project V 是理解這組工具的生態背景;V2Fly 延續 V2Ray 相關開發,Xray 則從相關程式碼基礎分支發展,形成自己的功能方向。兩者共享部分概念與設定習慣,但不能簡單視為改名關係。圖形用戶端負責管理設定、訂閱、本機流量接管與記錄顯示;核心則負責實際連線、路由與協定處理。介面能建立某類伺服器設定,只代表用戶端提供相應的編輯功能,最後仍須由正在執行的核心處理。
桌面用戶端首推 v2rayN,因為它的設定管理與多平台使用方式適合統一查閱及維護;不過,實際協定能力仍須依所選核心確認。Android 的 v2rayNG 主要採用 Xray 功能,v2flyNG 則可作為 V2Fly 路線的替代選擇。選擇時應先確認伺服器需要的協定與擴充功能,再考量介面使用習慣。不要因為同一份訂閱能在兩款軟體中顯示,就認定每一筆設定的執行結果都相同。
欄位相同,不代表能完整互換
兩種核心都可能具有入站、出站、路由與 DNS 等頂層概念,也可能支援同名協定,但擴充欄位、預設行為與特定傳輸方式的支援情況仍有差異。Xray 系列的 REALITY、XTLS Vision 相關功能,不能只因 JSON 外觀相近,就推斷 V2Fly 能原樣執行。反向遷移時,也要檢查 V2Fly 專屬設定與用戶端產生設定的方式。最穩妥的遷移方式是依欄位含義逐項處理,而不是整份複製檔案文字。
自訂設定與圖形編輯頁也可能採用不同的生命週期。用戶端通常會將介面儲存的資訊產生為執行設定,啟動時也可能覆寫暫存檔;直接修改產生的檔案,下次連線時未必會保留。若要長期使用自訂設定,應透過用戶端明確提供的自訂設定入口,並確認系統代理、路由或 DNS 功能仍由哪些介面控制。否則可能發生檔案中寫入一組規則,執行時卻載入另一組規則的情況,進而影響排查方向。
閱讀最小設定片段
以下是 Xray 風格的路由物件片段,只用來展示欄位層級,並非可直接啟動的完整設定。domainStrategy 表示路由判斷時處理網域名稱的策略;規則會依序比對,outboundTag 必須對應已定義的出站標籤。它不能建立伺服器,也不會自動設定系統代理。將片段套用至既有設定前,應先確認目前核心支援相關欄位,以及用戶端是否會再次產生路由內容,避免把有效規則貼到錯誤位置。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "direct"
}
]
}
}
更新核心時,也要一併考量用戶端產生設定的能力。更新可能新增協定欄位或改變相容性處理,但不會替伺服器補上缺少的參數。遇到啟動錯誤時,先查看最早出現的解析錯誤,確認執行的是預期核心,再檢查產生的設定欄位。若更新前可用、更新後卻失敗,應保留可還原的設定副本,並以最小設定重現問題。開放原始碼有助於程式碼審查與維護,但不代表不同實作自然相容;用戶端差異請參閱橫向評測。
訂閱與分享連結:匯入成功不代表欄位完整
網址、內容格式與連線設定是三回事
訂閱網址通常用來取得一組伺服器設定,單筆分享連結則直接表示一筆設定。兩者用途不同:訂閱之後可以更新,分享連結通常只是當下參數的快照。訂閱使用一般網頁網址,不代表內容就是網頁,也不保證任何用戶端都能解析。伺服器可能回傳連結清單、編碼文字或特定設定格式;用戶端必須具備相應的匯入功能,才能將內容轉換成可編輯的伺服器紀錄。
訂閱下載成功,只能證明已取得回應。如果回傳的是登入頁面、錯誤提示或不相容內容,清單仍可能是空的。應先分辨是要求失敗還是解析失敗,再決定是否調整網路路徑。部分用戶端允許選擇訂閱更新要走直連,還是透過現有代理;如果目前設定已失效,強制經由代理更新可能形成依賴循環。調整前先確認更新設定與可用連線,不要一邊切換路由,一邊反覆要求同一網址卻不查看錯誤訊息。
不同連結格式容易遺失的欄位
VMess 分享連結常見編碼後的結構化內容;VLESS 與 Trojan 連結通常透過位址部分和查詢參數表示設定;SS 則有不同的編碼格式。名稱、路徑與服務名稱若含特殊字元,必須遵循相應的轉義規則。聊天軟體換行、複製時漏掉尾端內容或重複編碼,都可能改變參數。匯入工具有時會容許部分錯誤,但不代表匯入後的設定仍與原始內容相同,因此必須檢查關鍵欄位。
VLESS 的 flow、REALITY 的公鑰與 shortId、TLS 的伺服器名稱、WebSocket 的 Host 與路徑,都是需要優先核對的欄位。如果格式轉換只保留協定、位址與驗證資訊,可能會遺失影響握手的擴充資訊。不要只比對節點備註是否相同;備註只是標籤,不會參與連線。匯入流程的詳細差異請參閱分享連結與訂閱網址的差異,並搭配本頁的參數說明操作。
訂閱更新與本機修改應分開管理
訂閱管理通常以群組為單位更新伺服器紀錄,哪些本機修改會被保留則取決於用戶端的行為。直接修改訂閱產生的紀錄中的連接埠、名稱或傳輸參數,下次更新時可能被覆寫。若需長期保留以供對照,可以複製成一筆本機紀錄並註明用途,但也必須自行同步伺服器端的變更。路由規則和個別應用程式範圍通常屬於本機策略,不要假設訂閱更新會替它們修正;每次變更都應確認修改的是哪個層級。
跨用戶端遷移時,優先重新匯入原始訂閱,再檢查擴充欄位;不要把某個用戶端的完整設定檔直接當成通用訂閱。桌面系統代理連接埠、Android 個別應用程式清單與本機 DNS 選擇都與裝置環境有關,遷移後需要重新設定。測試至少應涵蓋一次實際網頁要求與所需的 UDP 應用程式,再確認更新流程可以重複執行。首次連線成功只能驗證目前這筆紀錄,不能證明下次訂閱變更後仍能正確對應。
使用情境與故障檢查:先確認條件,再比較表現
依據伺服器與裝置選擇候選組合
已有可用服務時,首選是保留伺服器明確支援且已驗證的組合,而不是為了更換協定而更換。桌面使用 v2rayN 時,先確認系統架構與安裝方式,再核對所選核心。Android 若需要 REALITY 或 Vision 等 Xray 相關功能,應優先檢查 v2rayNG 的相應設定;已有 V2Fly 設定且功能需求相符時,可考慮 v2flyNG。所有安裝入口都集中在下載中心;協定參考不能取代系統與架構的選擇。
若經常開啟簡短網頁,應留意連線建立、解析與等待第一個位元組的時間;長時間傳輸時,則要觀察持續傳輸量、封包遺失與裝置溫度;背景訊息應用程式更重視流量接管範圍、連線恢復與系統背景限制。若同時有多種需求,不必追求一組參數滿足所有目標。先建立穩定的基準,再針對特定應用程式調整路由或個別應用程式範圍,通常比同時更換協定與傳輸方式更容易得到可判讀的結果。
將故障定位到連線階段
核心無法啟動時,先檢查設定解析、連接埠占用與功能支援;此時測試遠端速度沒有意義。核心可以啟動但無法建立連線時,核對位址、連接埠、系統時間與傳輸參數。已建立連線但安全握手失敗時,接著檢查伺服器名稱、憑證、公鑰、shortId 或驗證資訊。如果記錄顯示要求已轉送,但目標沒有回應,就要檢查伺服器出口、目標連線狀況與 DNS 結果,不能再把所有問題都歸咎於用戶端匯入步驟。
網頁正常但部分應用程式異常時,先確認這些應用程式是否有進入代理,再檢查路由與 UDP 需求。桌面部分應用程式不使用系統代理;Android 也可能因個別應用程式排除設定而直連。流量進入核心後,也可能被規則分配至 direct 或 block,因此必須一併檢查規則順序與出站標籤。DNS 回傳結果也會影響依 IP 判斷的規則;調整網域策略前應先了解其作用範圍,避免將解析選擇與協定驗證混為一談。
速度慢與連線逾時應分開排查
連線逾時時,應優先解決「能否建立連線」:依序檢查系統時間、訂閱有效性、連接埠、傳輸方式與核心記錄;速度慢則應在連線可用的前提下,比較節點負載、線路與本機設定。各自的檢查清單請參閱節點逾時排查清單與速度慢的分層診斷。兩種問題可能同時發生,但不宜反覆下載測速來診斷驗證失敗,也不能以一次連線成功就否定持續壅塞。
最後保存一份可追溯的紀錄:用戶端名稱、實際使用的核心、協定與傳輸組合、錯誤階段,以及最近一次設定變更。紀錄中不需包含存取憑證。恢復穩定後,將暫時調高的詳細記錄等級調回日常設定,並清除重複的測試紀錄,避免日後誤選。下次遇到類似問題時,先與基準設定比較,再逐項變更;一般疑問可前往常見問題,需要重新執行匯入與驗證流程時,請回到入門指南。選擇依據始終是完整組合與實際需求,而不是協定標籤本身。