V2Ray 完整指南
v2rayN 安裝與進階設定

核心觀念：先分清用戶端、核心與伺服器

連線架構由哪些部分組成

圖形用戶端負責儲存伺服器參數、管理訂閱、設定系統代理，並將選取結果交給代理核心。核心負責監聽本機連接埠、判斷路由、建立遠端連線及處理協定。伺服器則提供遠端連線服務，必須使用與用戶端相容的協定和參數。安裝 v2rayN 只代表準備好本機工具，不等於已有可用的遠端服務；訂閱網址也不是軟體下載網址。

常見的連線流程如下：瀏覽器讀取系統代理設定，將要求送至本機監聽連接埠；核心依據目標網域或 IP 位址比對路由，再選擇直連、代理或封鎖。若選擇代理，才會使用目前伺服器的協定建立遠端連線。排查時應沿著這條流程逐段確認，不能只因網頁無法開啟，就直接判定伺服器失效。瀏覽器未使用代理與遠端交握失敗，發生在不同環節。

Project V 是了解這套工具生態的背景；V2Fly 與 Xray 是相關核心家族，v2rayN 等則是提供給使用者操作的圖形用戶端。名稱相近，負責的工作卻不同。閱讀教學時，先確認文章談的是用戶端按鈕、核心設定欄位，還是伺服器部署參數。直接把核心 JSON 當成訂閱網址匯入，或將某款應用的備份交給另一款應用解析，通常都無法得到預期結果。

協定、傳輸與安全設定必須互相吻合

VMess、VLESS 等是代理協定；TCP、WebSocket、gRPC 等是承載通訊的傳輸方式；TLS 與 REALITY 則涉及特定安全設定。完整連線不只取決於協定名稱，還要確認位址、連接埠、使用者識別碼、傳輸路徑及安全參數一致。訂閱提供哪些參數，就先保留哪些設定；不要只因某個選項看起來較新，就單獨替換它。

尤其要分清連線位址與伺服器名稱指示。連線位址決定要求要送往何處；TLS 中的伺服器名稱則用於交握與憑證驗證，兩者在某些部署中可能不同。傳輸使用的 Host、路徑或服務名稱也各有用途，不能把備註名稱填進這些欄位。若伺服器要求特定值，漏填或填錯都可能造成交握失敗；關閉憑證驗證並不能通用地修正位址或名稱錯誤。

設定一個可驗證的最小目標

初次設定時，目標應盡量單純：讓一個確定會遵循系統代理設定的應用程式，透過一組已知設定存取特定目標。暫時不要啟用 TUN、增加複雜路由，也不要同時修改 DNS。先確認基本連線成立，後續的分流設定才有比較基準。否則多項設定一起變動，即使連線偶然恢復，也無從判斷是哪個步驟生效，下次遇到問題仍缺乏依據。

建議記錄目前的用戶端名稱、作業系統、代理入口、使用的協定及一次測試結果。紀錄不必包含訂閱金鑰或完整分享連結，重點是保留可重現的條件。若不熟悉相關術語，可先參閱術語手冊，了解後再調整設定。本章的完成標準是能說明要求如何從應用程式進入核心，以及目前使用直連還是遠端代理，而不是記住所有協定名稱。

選擇用戶端：桌面優先考慮 v2rayN，Android 依核心需求選擇

先確認作業系統與處理器架構

桌面環境可優先選擇 v2rayN，支援 Windows、macOS 與 Linux。下載前先查看系統資訊中的處理器架構，不要只看檔名中的數字猜測。常見的 x64 適用於桌上型 Intel 或 AMD 64 位元環境，arm64 則適用於相應的 ARM 環境。系統架構與應用程式套件不相符時，可能無法安裝，或只能透過相容層執行；後者不適合作為初次設定的預設方式。

Windows 下載區提供桌面版與經典 WPF 版。桌面版採用跨平台介面架構，WPF 版則延續傳統 Windows 介面；選擇時應考量使用習慣與目標系統的相容性，不要將兩者誤認為不同的代理協定。兩種介面的選單位置、設定目錄與遷移方式可能不同；若已有設定，請先備份，再使用用戶端提供的匯入功能遷移，不要直接覆寫整個程式目錄。

macOS 依 Apple Silicon 與 Intel 提供不同安裝項目，可在系統的「關於這台 Mac」查看晶片或處理器資訊。Linux 則需同時考量架構與發行版的套件格式：Debian、Ubuntu 等通常使用 deb，Fedora 等通常使用 rpm。套件格式代表要交由哪一套套件管理機制安裝，與協定能力無關；不要為了使用某種協定，硬在系統上安裝其他發行版的套件。

兩款 Android 用戶端的選擇範圍

Android 優先推薦 v2rayNG，採用 Xray 核心；v2flyNG 則可作為 V2Fly 核心路線的替代選擇。若伺服器說明明確依賴特定核心實作，應先確認用戶端是否支援相應參數，不要只憑協定名稱判斷相容性。能匯入同一條分享連結，不代表其中每個擴充欄位都已正確套用；匯入後仍應檢查安全設定與傳輸欄位。

Android 安裝項目提供 arm64 與通用版。較新的主流手機通常可選 arm64，但仍應以裝置實際架構為準；無法確認時，可查看系統資訊，或選擇涵蓋較多架構的通用版。比較用戶端時，不要同時啟用兩款應用程式的 VPN 接管：系統通常只允許一個這類連線維持啟用，後啟動的應用程式可能取代前一個，讓測試結果忽好忽壞。

服務參數一致即可，不必強求用戶端設定完全相同

桌面與 Android 裝置之間，最適合共用的是受支援的訂閱網址或單一伺服器分享連結；最不適合直接照搬的則是本機路徑、代理入口與路由設定檔。桌面系統代理、Android VPN 介面與桌面 TUN 雖然都涉及流量入口，但權限機制並不相同。跨裝置同步後，應分別驗證每台裝置的入口、DNS 與分流，不要只憑某一台能連線，就認定全部設定成功。

下載項目集中在下載中心，用戶端差異可接著參閱用戶端比較。本階段只需選定一款主要用戶端及一個安裝項目，暫時保留預設核心。若基本連線正常，也沒有明確的協定相容需求，就不必把切換核心當成例行最佳化。減少變動因素，通常比反覆更換工具更容易建立可查證的設定流程。

安裝準備：先確認程式能啟動，再調整網路權限

安裝前整理目錄、程序與舊設定

安裝前先關閉正在執行的同類代理程式，並確認通知區域或選單列沒有舊的執行個體繼續接管系統代理。若要更新既有的 v2rayN，請先在原用戶端清除系統代理並結束程式，再備份設定。不要在程式執行期間覆寫檔案，也不要混用新舊安裝目錄。這樣可避免「視窗是新版，背景核心卻仍是舊版」這種難以從表面察覺的狀況。

安裝位置應固定，並允許目前使用者依用戶端需求讀寫。長期放在暫存解壓縮資料夾、可移除磁碟或會自動清理的目錄，容易在下次啟動時遺失設定與規則檔。設定究竟位於程式目錄還是使用者資料目錄，應以目前用戶端提供的開啟設定目錄功能或說明為準，不要假設所有安裝方式都相同。備份也應針對實際資料位置，而非只複製桌面捷徑。

初次啟動時，先確認主視窗是否完整顯示、記錄是否持續出現錯誤，以及核心能否正常啟動。此時尚未設定遠端伺服器，無法存取目標並不能證明安裝失敗；但缺少執行環境、檔案遭隔離或設定目錄無法寫入，則屬於本機安裝問題。安全軟體出現提示時，應確認涉及的檔案與操作原因，不建議直接關閉所有防護來排除問題。

依需求逐項授予各平台所需權限

Windows 日常使用系統代理，通常不需要長期以系統管理員身分執行整個用戶端；需要啟用 TUN 或安裝相關網路元件時，再依介面提示處理權限。如果每次啟動都出現不同連接埠或設定遺失，先檢查是否同時以一般使用者與系統管理員身分執行了兩個執行個體。提升權限可能改變程序所處的環境，不能只因「提升後能開啟」就認定問題已解決。

macOS 出現開發者驗證提示時，可從系統「隱私權與安全性」相關頁面檢查遭阻擋的應用程式，確認來源後再依系統指引處理。不要批次移除不明檔案的安全限制。系統代理與後續網路接管可能需要不同權限；視窗能開啟，不代表網路權限已全部備妥。詳細步驟可參閱macOS 安裝與網路權限說明；不同系統版本的文字可能略有差異。

Linux 優先使用發行版的套件管理器安裝相應的 deb 或 rpm，以便管理相依套件。若出現缺少元件的提示，先查看安裝程式或啟動記錄，不要連續手動複製來源不明的程式庫檔案。圖形工作階段中的系統代理設定未必會套用到所有桌面環境與命令列程式；安裝成功只代表程式能執行，後續仍需分別確認應用程式是否讀取代理設定。

建立第一份安裝基準

用戶端啟動後，先查看本機監聽位址與連接埠。常見的混合監聽連接埠是 10808，但仍應以目前參數設定為準；舊設定或自訂選項可能會改變連接埠。監聽位址用來限制哪些裝置能存取本機入口，個人單機使用通常保留迴路位址；不要只為了排查連線就直接開放給區域網路。若連接埠已被占用，先找出占用中的程序，確認是否為重複執行個體，再決定結束程序或更換連接埠。

本章結束時，保留一份「能啟動且沒有持續本機錯誤」的設定作為起點。暫時關閉 TUN 與自動啟動，待完整連線驗證通過後再開啟。若核心啟動失敗，可參閱從記錄排查核心啟動錯誤，依序檢查連接埠、設定語法、欄位相容性與規則檔。安裝階段不要同時修改遠端參數，避免本機故障與網路故障混在同一份記錄中。

匯入訂閱：分清網址、分享連結與設定備份

先判斷取得的內容屬於哪種格式

訂閱網址通常是可更新的網路網址，用戶端連線後會取得一組伺服器資訊；單一分享連結描述一組伺服器連線；用戶端設定備份則可能包含分組、路由、介面偏好與本機設定。這三種內容要使用不同的匯入入口。取得內容後先確認提供者的說明，避免把管理網頁網址填成訂閱網址，或將完整設定檔貼到單一伺服器連結的欄位。

在 v2rayN 中，先建立訂閱分組，輸入方便辨識的分組名稱，再將網址貼到訂閱 URL 欄位並儲存。名稱只供本機管理使用，無法修正網址內容。貼上後，請檢查前後空格、換行、引號及是否有字元遭通訊軟體替換。網址可能包含授權參數，應視為機密資訊保管；不要將完整網址放進公開截圖、記錄討論或線上轉換服務。

儲存分組後執行更新訂閱，並留意記錄與伺服器清單是否有相應變化。顯示更新完成，只代表用戶端完成某個操作；仍需確認是否確實解析出伺服器，以及傳輸和安全參數是否保留。若清單篩選停留在其他分組，新增內容可能不會顯示；先切換到對應分組或顯示全部，不要只因清單沒有變化就反覆刪除重建。

更新失敗時，分辨是網路問題還是內容問題

若記錄顯示無法解析訂閱網域、連線逾時或憑證錯誤，問題首先出在取得訂閱內容的連線流程。先確認裝置能正常上網且系統時間正確，再判斷更新要求是否需要透過現有代理。初次安裝時若還沒有可用代理，透過代理更新可能形成循環；已有可用設定時，則可依用戶端提供的更新方式選擇連線路徑，不要只憑按鈕名稱猜測實際的對外連線方式。

若要求已成功送出但無法解析，請檢查回應內容是否為登入頁、錯誤頁或其他用戶端格式。有些訂閱轉換服務會重新產生連線資訊，但也可能遺漏特定用戶端欄位。只有確實遇到格式不相容時才考慮轉換，並優先使用來源方提供的相容入口。不要為了解決解析失敗，就把含授權參數的原始訂閱提交給無法確認資料處理方式的服務。

單一分享連結適合用來驗證一組明確設定。可先從剪貼簿匯入，再逐項核對位址、連接埠、協定、使用者識別碼、傳輸與安全設定。QR Code 只是承載同類文字的另一種方式，掃描成功不代表連線參數有效。手動修改由訂閱產生的項目之前，先確認下次更新是否會覆蓋修改；若要長期保留調整，應另建手動分組並記錄原因。

選取目前使用的伺服器並保留復原方式

匯入後，還要將目標伺服器設為目前使用的項目，並確認主視窗狀態及記錄中的設定重新載入結果。清單中有伺服器，不代表核心目前正在使用它。延遲測試、連線測試與瀏覽網頁並不相同：某一種測試通過，只能證明該測試流程正常；實際使用前仍須以目標應用程式驗證。測試失敗時先查看故障環節，不要立刻批次更換所有參數。

日常更新前先保留一份可用設定；更新後先驗證目前使用的項目，再清理舊項目。唯一可用設定尚未備份前，不要執行全部刪除。多台裝置可以共用受支援的訂閱，但須遵守來源方的裝置與連線規範，並分別管理本機路由。遷移方式可參閱多裝置共用訂閱與匯出設定。本階段的完成標準是：有一組參數已確認、已選取，而且能獨立驗證的伺服器設定。

代理模式：先檢查應用程式入口，再判斷對外連線策略

系統代理不是所有網路流量的總開關

v2rayN 的系統代理選項通常包括清除系統代理、自動設定系統代理，以及不變更系統代理。自動設定會將系統代理指向用戶端的本機監聽入口；清除則用來移除相應設定；不變更會保留目前的系統狀態。這些選項處理的是應用程式如何進入代理，不會直接決定特定網域最終要直連還是走代理；後者仍由路由與對外連線設定決定。

系統代理主要影響會主動讀取該設定的應用程式。有些命令列工具使用環境變數，有些應用程式有獨立代理設定，還有些程式會直接建立連線。因此「瀏覽器能用、終端機不能用」不一定是伺服器故障。先確認目標應用程式是否支援系統代理，再決定使用應用程式內的設定、明確指定代理參數或啟用 TUN。還沒釐清入口差異前，不要連續更換遠端伺服器。

瀏覽器擴充功能也可能覆寫系統代理。排查時先暫時停用代理相關擴充功能，確認瀏覽器沒有保留獨立設定，再以系統代理進行對照測試。若某個瀏覽器正常、另一個異常，還要考慮各自的安全 DNS、快取與擴充功能行為。測試環境越單純，越容易確認要求是否進入核心；同時執行多種代理管理工具，可能造成系統設定反覆遭到覆寫。

使用明確指定的代理測試本機監聽

若目前的混合監聽連接埠確認為 10808，可使用以下命令，讓單次 HTTPS 要求明確經過本機 HTTP 代理。目標使用保留作為範例的網域，執行時仍須確保網路可連線。命令輸出的連線流程有助於判斷問題出在本機入口、遠端連線還是目標回應；不要把單次要求的結果解讀為所有應用程式都已成功接管。

curl --proxy http://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

若命令立即顯示無法連線到本機連接埠，先檢查用戶端與核心是否正在執行、連接埠是否一致，以及監聽位址是否允許迴路連線。若已進入代理但交握失敗，再檢查伺服器參數、系統時間與安全設定。若命令能取得目標回應而瀏覽器失敗，優先檢查瀏覽器的代理入口。在某些 Windows 終端機中，可明確使用 curl.exe，避免同名命令對應不同程式而造成參數差異。

明確指定 SOCKS 代理時，也要留意 DNS 解析位置。支援相應參數的 curl 使用 socks5h://127.0.0.1:10808 時，會將網域交由 SOCKS 代理處理；這與先在本機解析再連線的流程不同。此差異可用來排查 DNS 問題，但並非所有程式都支援相同寫法。若應用程式要求分別填寫位址與連接埠，請依介面欄位填寫，不要將完整代理網址貼進位址欄。

分開記錄入口模式與路由模式

「全域」與「規則」常用來描述對外連線策略；系統代理與 TUN 則描述流量入口，兩組概念可以同時存在。即使啟用 TUN，規則仍可能讓部分流量直連；即使只啟用系統代理，也能讓進入核心的要求一律使用代理。判讀設定時，應分別寫清楚「哪些應用程式會進入核心」與「進入後如何連出」，才不會被不同用戶端的模式名稱混淆。

結束程式前清除系統代理，可避免本機監聽已停止，但應用程式仍向舊連接埠送出要求。結束後若網路異常，先檢查系統代理是否殘留，再確認是否有其他程式設定了代理；不要一開始就重設整個網路。基本連線穩定後再設定自動啟動，並確認啟動順序不會讓系統先使用代理、核心卻尚未就緒。快速操作步驟可參閱使用指南中的代理模式說明；本章則用來判斷不同結果背後的原因。

路由分流：規則順序、比對對象與 DNS

從簡單規則開始，建立預期結果

路由的核心功能，是替已進入核心的要求選擇對外連線方式。常見的對外連線標籤包括 direct、proxy 與 block，分別代表直連、代理與封鎖；這些標籤必須對應到實際定義的對外連線設定。規則通常由上往下依序檢查，符合條件後就執行相應處理；範圍過大的規則不可隨意放在前面，否則後續的精細規則可能永遠不會生效。

初次使用時，可先選擇符合需求的路由預設，再查看實際規則，不要立刻匯入大量規則集。常見做法是讓私人位址直連，明確需要直連的網域或位址使用 direct，其餘流量交由預設策略處理。封鎖廣告分類是額外選項，並非連線成功的必要條件；加入封鎖規則後，若登入、圖片或付款頁面異常，應檢查命中記錄，確認是否誤封必要的要求。

以下是 Xray 路由物件片段，用來說明比對順序，並非可單獨啟動的完整設定。此範例假設已定義同名的對外連線設定，並備妥相應的 geosite 與 geoip 資料。最後一條規則在此片段中涵蓋 TCP 與 UDP，作為預設處理方式；實際用戶端可能會透過預設設定或其他機制產生預設對外連線，未了解現有結構前不要直接照抄追加。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

網域規則與位址規則不能直接互換

網域比對需要在路由階段取得目標網域；位址比對則取決於實際目標 IP，或策略允許使用的解析結果。若應用程式直接連線到某個 IP，網域規則可能無法參與判斷。反過來，收到網域要求時，也不是每種網域策略都會立即解析並檢查位址規則。以上範例使用 AsIs，不應預期它會主動解析每個網域的位址，再判斷所屬地區分類。

geosite 與 geoip 是分類資料，不是線上查詢介面；規則能否識別，取決於核心支援、檔案是否存在及資料內容。若錯誤訊息指出找不到分類或無法讀取檔案，先確認規則資料與設定路徑，不要試圖更換遠端伺服器來修復。分類結果也可能與實際服務分布不完全相符；若特定服務有明確需求，優先新增範圍清楚的網域規則，不要假設地區分類永遠準確。

DNS 會影響要求取得的 IP 位址，也可能影響後續路由比對。應用程式自己的加密 DNS、系統解析與核心 DNS 不一定經過相同路徑。修改時先記錄目前的解析方式，一次只變更一處，再觀察解析是否成功、連線目標是否改變，以及路由是否符合預期。公共 DNS 位址不會自動保證可連線，更不能只憑解析成功就認定遠端代理連線正常。

依服務需求驗證規則，並限制修改範圍

驗證時，分別選擇一個應直連的目標、一個應走代理的目標，以及一項需要存取的區域網路服務，觀察相關記錄與實際結果。網頁成功開啟只代表該要求完成，不能單憑出口查詢頁推斷整個應用程式的所有連線都正常。單一頁面可能會存取多個網域；主文件、靜態資源與登入介面會分別比對規則。局部失敗時，應檢查實際目標，不要無限制放寬整個網站的規則。

自訂規則應註明用途，並放在適當的位置。若要修正某個工作網域，先用明確的網域範圍驗證，再考慮是否需要擴大比對範圍。修改後請儲存、重新載入，並以相同目標重新測試；同時保留先前的規則版本以便復原。若需釐清 DNS、網域比對與對外連線等術語，可先查閱定義。真正的進階能力，是能預測一條規則會影響哪些要求，而不是讓規則清單愈來愈長。

TUN 設定：擴大流量入口，同時檢查路由與權限

先確認是否真的需要 TUN

TUN 透過虛擬網路介面與系統路由接收流量，適用於不讀取系統代理設定的應用程式，或需要統一處理多種網路要求的情況。它改變的是流量進入核心的方式，無法修正錯誤的伺服器參數，也不保證所有協定和目標都能正常通訊。若使用系統代理時基本連線尚未成立，應先完成前面的驗證，避免將遠端連線問題與虛擬網路介面問題混在一起。

啟用前，記錄目前可用的伺服器、路由預設、DNS 設定與區域網路存取情形，並確認知道如何關閉。遠端桌面或遠端維護環境尤其要謹慎，路由變更可能中斷目前的管理連線。第一次測試最好能直接操作裝置，並先保留原有網路環境；不要同時修改無線網路、閘道、訂閱與核心。

啟用時，依用戶端要求授予系統管理員或相應網路權限，並留意是否出現介面建立失敗、路由寫入失敗或權限遭拒。實際作法可能因平台與用戶端能力而異，不要將某一平台的驅動程式步驟照搬到另一平台。介面開關顯示已啟用後，仍須搭配記錄與目標應用程式驗證；開關狀態只代表設定意圖，不保證所有系統操作均已成功。

避免連線迴圈，並確認區域網路例外設定

代理核心本身連往遠端伺服器的連線，不可被錯誤地再次送回同一個入口，否則會形成迴圈。用戶端通常會管理相應的路由或排除機制，但自訂系統路由、其他 VPN 與安全軟體可能造成干擾。若啟用後記錄大量重複、所有連線立即失敗，先關閉 TUN 還原基準，再檢查衝突程式與自訂設定；不要靠反覆重新啟動碰運氣。

區域網路存取應分別測試，包括路由器管理頁、印表機、共用資料夾與開發伺服器。私人位址直連規則有助於指定對外連線方式，但某些系統路由、DNS 與應用程式探索機制也涉及其他路徑，不能只新增一條規則就認定所有區域網路功能都已恢復。先使用明確的區域網路位址測試，再判斷問題出在名稱解析、連線路徑還是服務本身的存取限制。

理解 DNS 接管方式時，應依目前用戶端的實際作法判斷。有些設定會改變系統 DNS 路徑，有些只處理特定要求；若應用程式使用自己的加密解析，行為也可能不同。遇到「位址能連、網域不行」時，優先排查解析；若「網域能解析、連線仍失敗」，再檢查路由與傳輸。不要複製不適用於目前核心的 DNS 設定欄位；名稱相似的欄位，語意也可能不同。

UDP、休眠與其他網路工具應分別測試

應用程式流量進入 TUN，不代表遠端服務必然支援它所需的所有 UDP 功能。語音、即時通訊等情境也會受到伺服器能力、傳輸方式與本機網路條件影響，應以實際服務測試為準。不要因為瀏覽器正常，就將即時應用程式失敗歸咎於用戶端效能。若只有某一類服務異常，先確認它使用的協定、目標與對外連線方式，再判斷是否需要個別設定直連或調整相容性。

從休眠喚醒、切換網路或重新連上無線網路後，請再次確認 TUN 是否恢復、系統 DNS 是否可用。與企業 VPN 或其他虛擬網路工具並用時，雙方可能都會改寫路由，啟用順序也可能影響結果。確認發生衝突後，應選擇清楚的流量接管方案，不要不斷增加排除項目。本章的完成標準是：目標應用程式可正常使用、區域網路行為符合預期，而且關閉 TUN 後能回到原本可用的狀態。

日常維護：以備份、更新與記錄建立完整流程

分開管理設定備份與訂閱更新

訂閱更新只負責向來源重新取得伺服器資訊，不能取代用戶端的完整備份。路由規則、DNS、代理入口、分組偏好與手動項目，可能不包含在訂閱中。建議在基本連線穩定後、完成重要規則修改後，以及升級前，分別保留備份，並註明系統、用戶端類型與用途。備份目錄不宜直接公開同步，裡面可能包含訂閱授權資訊、連線識別資料及其他敏感設定。

還原前先確認目標用戶端支援該備份格式，再選擇性還原必要內容。不同平台的本機檔案路徑、權限與監聽設定不能直接照搬。若只要遷移伺服器，優先使用訂閱或受支援的分享連結；若要還原完整用戶端狀態，還需額外驗證路由與 DNS。顯示還原成功只代表檔案已讀取，實際連線及結束程式後網路是否恢復仍需重新測試。

自動更新訂閱可減少手動操作，但更新失敗時不應立刻清空現有可用項目。先檢查錯誤原因與目前使用的設定是否仍存在，再決定重試或聯絡來源方確認。手動修改過的訂閱項目尤其要留意是否會遭覆寫。若有特殊參數需要長期保留，記錄具體修改內容及原因，比只留一張介面截圖更方便日後遷移與查核。

升級時只變更必要項目

升級用戶端前先結束程式並備份，閱讀與目標功能相關的變更說明，尤其留意設定格式、路由資料與權限需求。不要在同一次操作中同時升級用戶端、切換核心、更換訂閱並重寫 DNS。更新後若出現異常，變動因素越少越容易定位。確認復原方式後再替換舊環境，避免新環境無法使用、舊設定也無法還原。

升級後使用固定的一組目標進行驗證：透過系統代理連線的瀏覽器、明確指定代理的要求、必要的區域網路服務，以及確實使用 TUN 的應用程式。測試項目應與升級前一致，不要只確認介面能否開啟。若只有新增功能失敗，可暫時停用該功能並保留基本連線；若基本流程也失敗，則應對照記錄檢查設定相容性與本機執行環境。

確認系統運作穩定後再設定開機自動啟動，並分清啟動圖形用戶端、啟動核心及自動設定系統代理是三件不同的事。Linux 桌面自動啟動依賴使用者工作階段，相關步驟可參閱deb／rpm 部署與自動啟動說明。不要為了開機啟動，就將整套圖形應用程式放進不適合的高權限服務；權限範圍與執行工作階段不相符，往往會增加設定目錄與網路狀態的差異。

保留記錄前後文，分享前移除敏感資訊

閱讀記錄時，先找出故障發生時間附近第一筆相關錯誤，再查看此前的啟動、設定重新載入或連線記錄。後續重複出現的錯誤，可能只是同一個根本原因造成的結果。連線遭拒、逾時、憑證失敗與未知欄位分別指向不同問題，不能一律歸因於網路不佳。排查時應記下剛才執行的操作、目標應用程式，以及系統代理和 TUN 各自的狀態。

暫時提高記錄詳細程度有助於定位；確認問題後應恢復日常等級，避免大量無關內容掩蓋重點。對外分享前，請移除訂閱網址、使用者識別資料、完整伺服器資訊與個人瀏覽隱私，只保留錯誤類型和必要前後文。記錄中的時間也應與系統時間一致。維護流程形成閉環的標準是：每次修改都有備份、測試與結果紀錄；若失敗，能依明確步驟復原，而不是只記得某次重新啟動後連線就恢復了。

進階學習：依照問題學習協定與排查方法

先建立分層排查順序

進階不代表開啟更多選項，而是能將現象歸類到正確層次。建議固定檢查順序：本機網路是否正常、應用程式是否進入代理、核心是否啟動、伺服器參數是否相符、DNS 是否正常、路由是否符合預期，最後才檢查目標服務本身。每個步驟都應尋找能支持或排除判斷的觀察結果，不要以未經驗證的猜測跳過中間環節。

例如瀏覽器無法開啟頁面，可先用明確指定代理的要求進行對照。若本機連接埠無法連線，回頭檢查程序與監聽設定；若連接埠可連線但遠端交握失敗，核對協定、安全參數與系統時間；若代理要求成功而瀏覽器失敗，檢查擴充功能、獨立代理設定與解析方式。如此一來，同一個「無法連線」現象就能拆分為不同問題，不必每次都重新安裝用戶端。

單一目標失敗時，也應與多個已知可用的目標比較。若所有目標都失敗，應優先檢查共用入口或遠端連線；若只有某個網域失敗，則著重檢查解析、路由、目標服務與存取要求。不要將單一頁面的地區提示、帳號狀態或服務限制，誤判為底層代理協定故障。建立連線成功與服務允許存取，是兩個不同層面的結果。

依實際需求學習協定與核心

學習 VLESS、VMess 等協定時，先掌握伺服器與用戶端必須一致的欄位，再了解傳輸層與安全層如何組合。協定名稱本身不能決定速度、穩定性或適用情境；實際部署方式與網路路徑同樣重要。某組設定在一種網路環境可用，不代表換到另一種環境仍有相同結果，因此應保留實際設定條件，而非只記下協定名稱。

切換核心前，先確認目前的伺服器設定、自訂路由與 DNS 欄位是否受目標核心支援。用戶端介面可以簡化常用操作，但不保證所有進階欄位都完全相容。先用最精簡的設定確認基本連線，再逐項恢復自訂內容。若錯誤訊息指出未知欄位，應依照對應核心的設定語意修正，不要反覆改變欄位大小寫或直接刪除報錯行。

編輯 JSON 時，先檢查括號、逗號、字串引號與陣列結構。JSON 不接受任意註解，最後一個項目後也不能多出逗號。語法通過後還需檢查語意：對外連線標籤是否確實存在、規則參照的資料能否讀取，以及監聽連接埠是否衝突。格式正確只是第一關，能成功啟動只是第二關；實際要求符合預期才算完成。

將專項最佳化轉化為可重複的實驗

研究 DNS、UDP 或特定服務相容性時，每次只設定一個要釐清的問題，例如「這個應用程式是否略過系統代理」或「這個網域是否符合直連規則」。先記錄原始結果，再只修改最相關的設定，並對同一目標重複驗證。不要一次匯入多項所謂的最佳化設定，否則結果改善時無從判斷原因，變差時也難以找出最小復原範圍。

解讀測試資料時也要了解其限制。連線測試只能反映相應測試方式的結果，不能取代長時間的實際使用；單次回應較快，也不代表之後每次要求都有相同表現。家用、行動與公司網路可能採用不同的 DNS、代理或路由策略，跨網路比較時必須註明條件。不要為了追求單一數值，破壞已符合實際工作需求的穩定設定。

最後整理一份個人操作紀錄：如何啟動與結束、目前使用的入口和連接埠、哪些目標需要直連、備份放在哪裡，以及遇到問題時先查看哪段記錄。若不熟悉主介面位置，可參閱v2rayN 主視窗功能速覽；需要重新建立基本連線流程時，請回到使用指南。完整指南的目標，是建立一套能說明、驗證並復原的設定，而不是同時啟用所有進階功能。