V2Ray 協定與核心指南

用戶端、核心與伺服器各有不同職責

v2rayN、v2rayNG、v2flyNG 是圖形化用戶端，負責儲存訂閱、顯示設定、產生執行參數，並管理系統代理或虛擬網路介面。核心負責建立連線、處理協定、解析網域名稱及執行路由。伺服器則是在連線另一端提供服務的程序。介面中可以選取某個名稱，只代表用戶端知道如何描述它；能否實際使用，還要看目前執行的核心與伺服器設定，不能把介面支援直接當成端對端支援。

選擇時，可以把一條出站連線分成幾個環節：代理協定負責使用者驗證與目標位址的傳遞；傳輸層安排資料如何送達對端；安全層保護連線並驗證身分；路由決定哪些請求使用這條出站連線；入口則負責從本機應用程式接收流量。各層彼此配合，卻不能互相取代。切換路由模式無法修正錯誤密碼，啟用系統代理也不會自動補上缺少的伺服器憑證名稱。

協定名稱只描述連線的一部分

例如，VLESS 可以搭配不同的傳輸與安全設定。兩筆同為 VLESS 的設定，可能一筆使用一般 TLS，另一筆使用 REALITY；所需欄位與伺服器能力也會不同。WebSocket 是傳輸承載方式，不是與 VLESS 同一層級的代理協定。TLS 也不是節點驗證密碼的另一種說法。查看訂閱詳細資料時，應分別記下協定、位址、連接埠、傳輸方式、安全方式與驗證資訊，而不是只記住協定標籤。

用戶端中的「位址」通常是連線伺服器使用的網域名稱或 IP；「伺服器名稱」通常對應 TLS 的 serverName，也常顯示為 SNI；WebSocket 的 Host 與路徑則屬於應用層請求。三者可能相同，也可能依伺服器要求填入不同內容。若一律改成網址列中的網域，看起來雖然整齊，卻可能破壞憑證驗證或反向代理分流。最可靠的依據是設定提供者給的欄位對照，而不是欄位名稱看起來是否相似。

分別驗證「可匯入」與「可連線」

匯入成功只代表用戶端接受輸入格式並建立一筆設定。部分進階欄位可能未被辨識，某些預設值也可能與原始設定不同。要真正建立連線，還需要位址可連通、連接埠開放、驗證資訊相符、安全層參數正確，且目標請求符合路由規則。節點名稱完整、圖示正常，仍可能在握手前失敗。因此，應先檢查詳細參數，再測試單一連線，最後才比較使用體驗。

這種分層方式也能縮小疑難排解範圍：完全沒有請求記錄，先檢查入口與路由；已連上伺服器但驗證失敗，檢查協定憑證；憑證或握手錯誤，檢查安全層與系統時間；只有特定網站無法使用，再檢查 DNS、目標網站與分流。逐層定位比同時切換協定、核心與路由更容易重現問題。常見欄位的簡要定義可搭配術語手冊閱讀，本頁後續章節則會詳述各層的取捨與界線。

VMess：協定內的驗證與資料保護

VMess 隨著 Project V 生態系發展，採用使用者識別碼進行驗證，並由協定本身處理資料保護。相較於只在外層建立安全通道的方案，VMess 在代理協定中承擔更多工作。實際設定時不只要確認 UUID，也要留意實作採用的驗證機制與加密選項。舊設定中的額外識別欄位有其歷史背景，不應照著早期文章任意加上數值。連線至現代伺服器時，應以雙方實作支援的驗證方式為準。

VMess 驗證對時間有要求。裝置時間明顯不準可能造成驗證失敗，但錯誤訊息未必會直接指出「時間錯誤」。疑難排解時，先啟用系統自動校時，再查看驗證記錄，往往比反覆更新訂閱有效。VMess 適合已有穩定部署，且用戶端與伺服器設定明確的環境；不必為了追求另一種協定而遷移原本運作正常的連線。協定歷史悠久與否，不能單獨用來判斷效能，也不能取代對實作維護狀況的評估。

VLESS：把職責交給合適的層

VLESS 採用較精簡的代理協定設計，負責驗證與請求表示，不像 VMess 一樣由協定本身承擔相同的資料加密職責。因此，VLESS 設定中的 encryption 為 none，不代表整條連線必然是明文；實際保護可能來自 TLS 或 REALITY。反過來說，看到 VLESS 名稱也不能直接推定連線已受保護。判斷時必須一併查看安全層，不能孤立解讀下拉選單中的 none。

VLESS 的 flow 是另一個需要留意的欄位。它描述特定的流量處理方式，例如與 Vision 相關的值，但不是所有傳輸方式都能任意搭配。用戶端允許輸入，不代表伺服器會接受；訂閱中缺少此欄位，也不表示應手動補上。若伺服器指定了 flow，應原樣保留並確認核心支援。把精簡理解成「參數少就能隨意組合」是常見誤解；協定本身承擔的職責越少，越需要釐清各層界線。

Trojan：以 TLS 保護的代理連線

Trojan 的典型設計以 TLS 作為外層保護，再於其中進行密碼驗證與代理請求。使用者最常接觸的欄位是伺服器位址、連接埠、密碼與伺服器名稱。密碼驗證與憑證驗證負責不同工作：前者確認是否有使用權限，後者協助確認連線對象是否為預期伺服器。因此，修正密碼無法解決憑證名稱不符，關閉憑證驗證也無法修正密碼錯誤。疑難排解時，必須先確認錯誤發生在哪個階段。

選用 Trojan 時，應檢查憑證鏈、伺服器名稱，以及部署中是否有反向代理。使用網域名稱連線通常較容易維持明確的憑證對應；若位址填的是 IP，仍可能需要另外指定合法的伺服器名稱。某種額外傳輸或多工方式是否可用，應查閱所用核心與伺服器實作的說明，不能把某個用戶端提供的擴充功能視為所有 Trojan 部署的共同能力。原始協定與實作擴充應分開理解。

Shadowsocks：精簡的資料封裝與方法相容性

Shadowsocks 通常直接對代理資料流進行加密封裝，設定中最重要的是位址、連接埠、加密方法與密碼。它沒有必須進行憑證握手的統一前提，因此常用於希望減少外層元件的部署。不過，「Shadowsocks」不代表各種加密方法彼此相容。傳統方法、現代 AEAD 方法與 Shadowsocks 2022 系列各有不同要求，密碼格式與長度限制也可能不同，不能只複製密碼而漏掉方法名稱。

實際選擇仍應回到部署條件：現有的伺服器類型、是否需要 UDP、裝置核心支援哪些方法，以及訂閱能否完整表示參數。不要只憑「輕量」就認定 Shadowsocks 在所有手機上都更省電，也不要因為 VLESS 欄位較少就判定它一定更快。更完整的比較請參閱四種協定的情境比較；此處只保留一個原則：先確保相容性與功能，再於條件相同時比較耗用。

REALITY 是安全機制，不是獨立的代理協定

REALITY 常與 VLESS 一起出現，但兩者並非同一層級的替代選項。VLESS 處理代理請求，REALITY 則負責外層連線的安全握手及相關驗證。常見的用戶端欄位包括伺服器名稱、與伺服器公鑰相關的參數、短識別碼及用戶端指紋。伺服器持有的私鑰不應出現在用戶端訂閱中。不同介面可能使用不同標籤表示公鑰參數，應依目前用戶端與核心文件確認，不能只憑欄位名稱的新舊判斷設定是否正確。

REALITY 握手需要用戶端參數與伺服器設定相互符合。伺服器名稱通常必須符合伺服器允許的範圍；公鑰相關參數必須與伺服器金鑰配對；短識別碼也必須是伺服器接受的值。有些部署允許短識別碼留空，另一些則明確要求指定值，不能一概而論。用戶端指紋用來建構相關握手特徵，不是隨便填一個瀏覽器名稱就能改善連線；有效值與行為取決於核心實作。

TLS：名稱驗證比「連接埠可連通」更重要

一般 TLS 連線需要驗證憑證鏈與憑證名稱。伺服器連接埠可建立 TCP 連線，只代表網路層已連通，不代表對端憑證可信，也不代表代理驗證成功。常見問題包括裝置時間不準、伺服器未傳送完整的中繼憑證、伺服器名稱與憑證不符，或反向代理將請求轉送至錯誤入口。這些問題應在憑證與部署層修正，而不是把略過驗證當成固定設定。

ALPN 用於協商應用層協定，不是任意的加速選項。某些傳輸方式仰賴特定協商結果，有些伺服器則會依協商結果選擇處理路徑。手動刪改可能導致握手完成後的請求仍然失敗。若訂閱已提供 ALPN，請先保留原值；若訂閱未提供，也不要照抄其他節點的設定。看似可選的握手欄位，在特定部署中都可能有明確用途。

TCP、WebSocket 與 gRPC 的實際成本

直接以 TCP 承載資料，路徑通常較單純，額外封裝也較少；WebSocket 必須先完成 HTTP 升級，再承載資料，部署時還要配合路徑與 Host；gRPC 通常依賴 HTTP/2，必須設定相符的服務名稱，並取得中間代理支援。這些傳輸方式主要用來處理承載與部署相容，不是「越複雜越先進」的等級表。選擇伺服器實際支援的組合，比挑名稱較新的傳輸方式重要。

經過反向代理時，也要考量代理的閒置逾時、請求大小限制、長連線處理方式與上游協定。瀏覽網頁正常，但長時間工作階段定期中斷，可能是某一層逾時，不一定是代理協定驗證突然失效。WebSocket 路徑少一個字元、gRPC 服務名稱被轉換器移除，都可能讓伺服器回傳一般 HTTP 錯誤。此時應核對路徑與代理記錄，而不是繼續調整本機監聽連接埠。

多工與 UDP 必須從端到端完整評估

多工會嘗試讓多個邏輯連線共用底層連線，以減少重複建立連線的成本；但共用連線也會帶來共同的壅塞與故障影響。若現有傳輸本身已具備多工能力，再額外啟用多工未必有幫助。是否啟用要看核心、協定、伺服器與應用程式特性，不適合設為一律開啟的全域選項。尤其在疑難排解時，先用簡單組合建立基準，再比較啟用多工前後的短請求與持續傳輸表現。

UDP 是否可用，取決於入口、代理協定、核心封裝、伺服器與目標網路是否都支援。本機 SOCKS 入口能接收 UDP，不代表一般 HTTP 代理入口也有相同能力；若應用程式沒有使用該入口，即使協定完整支援也不會生效。語音、遊戲或其他 UDP 應用發生問題時，應逐段確認資料如何進入用戶端、如何由出站連線承載，再檢查伺服器策略，不能只憑「節點支援 UDP」的標籤下結論。

區分探測延遲、首次回應與持續傳輸速度

用戶端中的 TCP 延遲通常著重於連上伺服器連接埠所需的時間；實際請求測試還可能包含安全握手、代理驗證與目標網站回應。兩者測量的對象不同，結果自然不能直接互換。TCP 探測很快的入口，可能因目標路由、DNS 或伺服器負載而無法快速開啟網頁。反過來說，某種探測失敗也可能只是測試目標或探測方式不適用，不足以證明所有業務連線都失敗。

首次回應關注新請求從送出到收到資料的時間；持續傳輸速度則關注連線建立後可傳送多少資料。安全握手與傳輸升級較容易影響前者，鏈路頻寬、壅塞控制與伺服器出口則較容易影響後者。網頁還會同時請求許多小型資源，因此單一大型檔案傳輸順暢，不代表頁面載入一定快。比較協定前，先確認要改善的是新建連線、日常瀏覽還是長時間傳輸，避免指標與目標不一致。

應在相同條件下比較協定成本

協定封裝、驗證與加密確實會耗用運算資源，但通常不是影響體驗的唯一因素。遠端距離、封包遺失、網路切換、伺服器壅塞與目標網站差異，往往比協定標頭多幾個位元組更明顯。嚴謹比較應盡量使用同一裝置、同一網路、同一伺服器地區與相同測試目標。若兩筆訂閱原本就連往不同伺服器，結果只能說明這兩條完整路徑的差異，不能歸因於協定名稱。

硬體能力也會改變結果。不同處理器對加密演算法的硬體加速支援不同，核心實作、系統排程與溫度限制都會影響耗時。筆電接上電源與使用省電模式時的表現未必相同；手機長時間運作後，也可能因溫度控制而降低頻率。缺乏固定裝置與測試條件，就不適合提出普遍適用的資源耗用排名。對一般使用者來說，連線穩定並符合應用需求，通常比追求些微的瞬間差距更重要。

記憶體與耗電往往取決於執行方式

記憶體不只用於協定處理，也用於連線緩衝、DNS 快取、路由資源與介面清單。匯入大量節點、長期保留詳細記錄或載入大型規則集，可能比更換代理協定更影響記憶體用量。比較時應區分圖形化用戶端與核心程序，觀察穩定運作後的狀態，而非只看啟動瞬間。刪除重複群組、縮短不必要的記錄保留時間，比為了降低單一數字而反覆切換核心更容易判讀。

行動裝置的耗電常與無線模組喚醒有關。頻繁探測、過短的保活間隔、網路不穩時持續重連，以及背景應用不斷送出請求，都可能延長裝置的活躍時間。某種協定即使少一次握手，若在實際網路中不斷斷線，最終反而可能更耗電。應一併觀察閒置、正常瀏覽與網路切換後的表現，不能用一次短時間測試代替全天使用的判斷。

建立可重複的比較紀錄

建議先保留一筆已知可用的設定，固定測試網站與應用程式，分別記錄首次請求、持續傳輸、閒置連線與切換網路後的恢復情況。每一輪只修改一個變數，測試結束後還原基準，再嘗試下一項。不要同時更換協定、伺服器與 DNS，否則即使體驗改善也很難找出原因。節點測速只是輔助工具，並非最後裁判；應以實際工作能否順利完成、錯誤能否重現作為判斷依據。

Project V、V2Fly 與 Xray 的關係

Project V 是理解這套工具生態的背景；V2Ray 曾是其中廣泛使用的核心實作。V2Fly 社群延續 V2Ray 核心的開發與維護；Xray 則以相關程式碼為基礎發展為獨立專案，並依照自身功能方向持續演進。兩者有歷史淵源，也共用不少概念，但並非同一個程式的兩種顯示名稱。閱讀文件時，應確認內容適用於哪種核心，避免把其中一方新增的功能，誤認為另一方也具備的共通特性。

兩者都能處理代理連線、路由與網域解析等工作，但支援的協定擴充、傳輸細節、DNS 行為與設定欄位會逐漸出現差異。REALITY 與 XTLS Vision 是理解 Xray 功能方向時常見的內容；不能因此推定 V2Fly 的同名設定欄位也接受相同參數。反過來說，V2Fly 文件中的某種傳輸方式或特定選項，也應在 Xray 目前的實作中另外確認，不能只憑共同的歷史背景推定完全相容。

三款用戶端的選擇方式

桌面端優先考慮 v2rayN，支援 Windows、macOS、Linux，適合透過圖形介面管理訂閱與檢查出站參數。不同發行版本的介面與內附元件可能不同，選擇前請查看用戶端下載頁的系統與架構說明。Windows 桌面版採用跨平台介面，經典 WPF 版則保留另一套介面操作習慣；這是用戶端介面與發行形式的差異，不能直接等同於某種協定比較快或核心功能較多。

Android 裝置優先考慮使用 Xray 核心的 v2rayNG；若需要確認與 V2Fly 的相容性，再考慮 v2flyNG。兩者介面概念可能相近，但對協定擴充功能的支援範圍並不因此相同。若現有訂閱包含明確依賴 Xray 的參數，應先確認所選用戶端與核心相符，不要匯入後才逐一刪除不認識的欄位。刪除欄位或許能讓設定啟動，卻可能已不符合伺服器要求。

設定語法相似，不代表可以直接移植

核心 JSON 中常見的入站、出站與路由結構具有相似概念，但欄位、預設值與合法組合不一定一致。某段設定能通過剖析器檢查，不代表實際行為符合預期：未知欄位可能遭忽略、預設路由可能不同，DNS 查詢路徑也可能改變。遷移時應先核對協定與安全層，再檢查傳輸，最後處理路由與 DNS。不要一次搬入整份複雜設定，否則發生問題時很難判斷差異來自哪一層。

用戶端通常會把自己的節點模型轉換成核心設定。使用者在介面修改某個項目後，下一次啟動時產生的檔案可能會被重新覆寫。因此，直接修改暫存執行檔通常不是長久之計。若要進階自訂，應使用用戶端明確支援的自訂設定入口，並了解它是否會取代預設路由、是否仍接受訂閱更新。查看執行記錄有助確認實際啟動的核心，但請避免公開記錄中的檔案路徑與設定內容。

更新與遷移應保留回復方式

更新用戶端與更新核心要解決的問題不同。前者可能改變介面、訂閱剖析與參數產生方式；後者可能改變協定實作或執行行為。升級後若發生問題，應記下實際變更的項目，不要一概歸咎於「新版本不好用」。先用少量設定驗證基本連線、常用應用程式與網路切換，再還原完整規則。沒有明確需求時，不必為了測試擴充功能而同時更換所有元件。

保留回復方式不代表要一直使用舊實作，而是為了比對變更提供參考。更新前可以匯出必要設定並記下重要介面選項，之後對照啟動記錄與實際請求。若介面顯示的核心類型與預期不符，先修正用戶端設定；若只有特定擴充功能失敗，再核對該功能的文件。將生態系關係、用戶端能力與實際執行的核心分開看，通常就能避免多數「設定相同，為何結果不同」的誤判。

訂閱網址、分享連結與執行設定

訂閱網址用來取得一組設定，單一節點分享連結用來表示一條連線，核心執行設定則描述程序的運作方式。三者並非同一種檔案。訂閱回應可能是多行連結、經過 Base64 編碼，或採用特定用戶端格式。在瀏覽器中開啟網址，只能確認伺服器有回傳內容；如果收到的是登入頁面、提示文字或錯誤頁面，用戶端仍會回報格式錯誤。因此，更新失敗時應分開檢查連線問題與回應格式問題。

常見分享格式包括 vmess、vless、trojan 與 ss 等 URI 方案。VMess 分享連結常見經編碼的 JSON 資料；VLESS 與 Trojan 分享連結常將連線參數放在查詢部分；Shadowsocks 則有不同的憑證編碼格式。分享連結中的參數是格式約定的一部分，不是任意備註。同一協定透過不同分享格式傳遞時，欄位名稱可能變動，或無法完整表示所有設定；不能只看開頭幾個字母判斷是否完全相容。

匯入時哪些內容容易遺失

進階安全參數、flow、ALPN、用戶端指紋、WebSocket Host 與路徑、gRPC 服務名稱，以及部分 UDP 封裝選項，都需要特別檢查。有些訂閱格式只能表示基本連線，無法完整攜帶核心支援的所有功能。轉換器若不認得某個欄位，可能會直接省略；用戶端若不支援，也可能只保留備註與基本位址。看似成功匯入的設定，實際上可能已不等同於原始設定。

編碼處理也會影響結果。查詢參數中的特殊字元通常必須正確進行百分比編碼，連結備註與驗證資訊也可能採用不同編碼規則。複製時漏掉結尾、在連結中間插入換行，或重複解碼編碼內容，都可能改變剖析結果。不要為了讓連結「看起來好讀」而手動替換符號。若確實需要調整，請先在用戶端詳細資料頁核對每個欄位，不要只比較分享文字的外觀。

訂閱更新失敗時的檢查順序

先確認網址完整，尤其是包含查詢參數的連結是否遭截斷；再檢查是否需要登入、訂閱是否已失效，以及裝置能否連線至訂閱服務。若記錄顯示網路逾時，請確認取得訂閱時使用直連，還是透過目前的代理。有些用戶端提供不同的更新路徑；若目前代理無法使用，卻依賴它更新訂閱，就會形成循環。應選擇目前環境可連通的路徑，而不是反覆按下同一個按鈕，期待結果有所不同。

若請求成功但剖析失敗，請確認回應確實是目標用戶端支援的訂閱內容，而不是網頁。不要隨意將完整訂閱上傳至不熟悉的轉換服務，因為網址與回傳資料可能包含帳戶憑證。直接詢問設定提供者正確格式，通常更有效率。需要回報問題時，可提供錯誤類型、用戶端名稱、所選核心與已去識別化的欄位結構，不必公開完整訂閱連結，也不應在公開討論中貼出驗證資訊。

群組管理與更新覆寫的界線

訂閱節點通常會在更新時重新產生，手動修改可能遭到覆寫。需要長期保留的測試設定，建議複製到獨立的本機群組，並清楚標示用途。不過，群組備註並非安全隔離機制，只是方便整理設定。刪除群組前，應確認其中是否混有手動維護的節點，避免連同訂閱資料與個人測試設定一起刪除。定期整理重複項目，也有助減少誤選舊入口的機會。

跨用戶端遷移時，先用單一設定往返核對，再匯入整份訂閱。重點不是節點數量是否相同，而是關鍵參數是否完整保留。若基本參數一致但功能不同，請回到核心相容性章節檢查擴充支援；若連線正常但分流不同，則檢查用戶端本機路由，因為訂閱通常不包含完整路由策略。訂閱提供連線資料，本機用戶端仍會決定如何使用這些資料。

桌面辦公：先確保應用程式使用相同入口

桌面環境建議先用 v2rayN 建立簡單且可驗證的設定。瀏覽器、終端機與辦公軟體未必使用相同的代理入口：有些應用會讀取系統代理，有些使用自己的設定，另一些則需要個別設定。某個瀏覽器能連線，不代表所有程式的流量都已進入核心。應先確認應用程式實際採用的路徑，再討論協定差異。系統代理適用於遵循系統設定的應用程式，不能直接視為接管裝置的所有流量。

日常辦公通常包含大量短請求、持續中的會議連線與背景同步。相較於只追求單次測速，更應重視長連線穩定性、DNS 一致性與規則是否易於理解。現有運作正常的 TLS 或 REALITY 設定，可以先保留預設參數；需要 UDP 的應用程式則應逐段確認支援情況。不要只為了讓所有請求看起來都「走同一條路」就貿然啟用複雜模式，先確認應用需求，再決定入口與路由範圍。

手機通勤：留意網路切換與閒置後恢復

Android 裝置優先使用 v2rayNG，並依照 Xray 支援的協定組合核對參數。手機在無線區域網路與行動網路之間切換時，來源位址與底層連線可能改變，既有連線通常需要恢復或重新建立。恢復速度不只與協定有關，也會受到用戶端網路監聽、系統背景限制、伺服器逾時與應用程式重試機制影響。測試時應實際切換網路並開啟常用應用程式，不要只在固定網路下確認一次連線成功。

省電設定應依實際狀況調整。若系統停止用戶端，離開前景介面後連線可能中斷；若完全不限制所有背景活動，也可能增加不必要的執行時間。可以先檢查系統是否對用戶端施加過強的背景限制，再觀察閒置時是否持續重連或頻繁探測。只保留必要的背景執行條件，不要把高頻測速當成維持連線的方法。真正需要的是工作期間可靠，閒置期間盡量減少額外喚醒。

弱網路：先減少變數，再考慮更換協定

弱網路常見的限制包括封包遺失、延遲抖動與間歇性斷線。更換代理協定不會自動修復底層鏈路。可以先選擇路徑較穩定、傳輸層次較單純的設定，避免疑難排解時同時疊加多種多工與額外轉送。若新請求常常失敗，但已建立的連線相對穩定，應優先檢查握手與重連；若持續傳輸時出現停頓，則應檢查壅塞與封包遺失。兩種狀況需要不同的觀察方式，不能一概解讀為「協定不適合弱網路」。

多工在短請求較多時可能減少重複建立連線，但共用底層連線若受阻，多個邏輯請求也可能同時受影響。先關閉選用的多工功能建立基準，再依任務逐項比較，比直接套用「弱網路一定要開」的建議更穩妥。若使用依賴 HTTP/2 的傳輸方式，也要確認沿途代理能穩定維持長連線。複雜部署有適用情境，但不應成為排除網路不穩時額外增加的變數。

持續傳輸與即時應用應分開驗證

檔案傳輸較重視持續傳輸速度、連線穩定性與伺服器出口；即時語音則更在意延遲抖動、封包遺失與 UDP 鏈路。下載速度快，不代表通話品質一定好；網頁延遲低，也不能保證大型傳輸不會觸發溫度控制或頻寬限制。對長時間執行的工作，應觀察一段實際使用流程，並留意裝置溫度、錯誤記錄與斷線恢復情況。測試情境越接近日常使用，結論越有參考價值。

若需要特定的 V2Fly 相容性，可用 v2flyNG 在獨立設定中驗證，但不應把它當成修復所有連線問題的通用替代方案。若伺服器參數明確依賴 Xray，切換到另一個核心反而可能引發新問題。用戶端、協定與伺服器應彼此相符：先確認伺服器能提供什麼，再選擇能完整支援參數的用戶端，最後比較日常工作表現，而不是先憑偏好挑選名稱。

將選擇結論寫成條件，而非排行榜

有用的結論應該像是「這台裝置在目前網路下使用這組參數，能穩定完成會議與同步」，而不是「某種協定永遠最快」。條件包括裝置、核心、入口、傳輸方式、安全方式與伺服器路徑。記錄這些條件，日後網路改變或元件更新時才能重新驗證。若幾組設定都能滿足需求，優先保留結構清楚、參數來源可靠且容易還原的方案，降低長期維護成本。

先建立最精簡的可用基準

選擇一筆參數完整的設定，使用用戶端預設或已明確記錄的路由，先測試一般網頁請求。第一次連線時，不要同時匯入複雜自訂規則、調整 DNS、啟用多工並切換核心。開啟記錄，確認核心成功啟動，再確認實際請求已進入核心。若啟動就失敗，測速沒有意義；應先處理設定語法、連接埠占用或不支援的選項，直到程序能穩定執行。

本機監聽位址也必須明確。以下是一段可用於 Xray 完整設定中 inbounds 部分的最小入口範例，用來說明欄位關係，並非包含遠端伺服器的完整設定。SOCKS 入口只監聽本機迴路位址，不對區域網路開放。連接埠必須與應用程式填寫的一致；若用戶端已使用該連接埠，就不能再啟動另一個程序重複占用。日常圖形化設定應優先在用戶端介面修改對應項目。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ]
}

依照失敗階段逐步縮小範圍

完全沒有請求記錄時，先確認應用程式是否使用本機入口，以及路由是否將請求設為直連。出現連線逾時，請核對伺服器位址、連接埠、目前網路與伺服器監聽狀態；若連線立即遭拒，通常表示目標連接埠未接受連線，但仍應搭配記錄判斷。進入握手後才失敗，接著檢查 TLS 伺服器名稱、憑證、REALITY 參數與系統時間。驗證失敗則檢查 UUID、密碼或加密方法，不要混在一起處理不同類型的錯誤。

若已連上伺服器，但只有部分網域無法使用，應分辨是目標網站、DNS 結果還是路由規則命中問題。直連 DNS 與代理 DNS 的使用位置，可能讓同一個網域得到不同結果；DNS 查詢是否經過代理，也會依核心策略而異。不能只更換某個公共解析位址就認定問題已解決。若要進一步了解解析路徑，請參閱v2rayN DNS 檢測與設定實作指南，再依實際請求驗證。

利用記錄確認路徑，避免公開敏感資訊

記錄中應優先查看時間順序、入口來源、命中的出站連線與錯誤類型。單筆警告不一定代表整條連線失敗，有時只是某個背景請求遭目標拒絕；反過來說，介面顯示正在執行也不代表實際流量正常。可以先暫停其他應用程式的活動，送出一筆明確的測試請求，再依時間找到相應記錄。暫時提高記錄詳細程度有助於定位問題，但完成後應恢復一般等級，避免長期產生大量記錄。

分享記錄前，應移除訂閱網址、驗證資訊、私人網域及可連結至帳戶的參數。回報問題時，只需保留用戶端名稱、核心類型、入口方式、協定與安全層組合，以及錯誤前後必要的內容。不要直接公開整份執行設定，也不要把完整訂閱當成一般測試網址。去識別化不是刪除所有技術資訊，而是保留結構與錯誤原因，同時移除可直接用來連線的憑證。

複測通過後再還原複雜設定

精簡設定正常後，再逐項還原規則、DNS、自訂入口與多工功能；每次變更都重複相同請求。若還原某個項目後問題再次出現，就針對該項繼續檢查，不要重新從所有協定中隨機挑選。自訂路由尤其要注意順序：較寬泛的規則若先命中，後面的精確規則可能永遠不會生效。語法說明請參閱路由比對與優先順序說明，但修改時仍應一次只變更一個變數。

最終驗收至少涵蓋一般瀏覽、實際工作應用程式、閒置後恢復與網路切換。若需要 UDP，請另外驗證對應應用程式；若要在多台裝置上使用，應分別檢查各裝置的入口，不要把一台裝置成功當成全部都正常。完成驗證後，保存一份可還原的設定，並記下重要選擇依據。日後發生異常時，先比對環境與參數變化，再決定是否更新或遷移。安裝與匯入步驟請參閱快速入門教學；安裝檔與平台選擇則統一至用戶端下載頁進行。