// ALL PLATFORM REFERENCE

v2rayN 全平台安裝與設定完整指南

涵蓋 Windows、macOS、Linux 與 Android 的下載安裝、訂閱匯入、系統代理、TUN、路由分流與日誌排查。本文依系統拆分步驟，適合長期查閱。

四大平台 v2rayN / v2rayNG / v2flyNG 訂閱 · 路由 · TUN 更新於 2026-08-15
選擇用戶端安裝套件 先看快速入門

使用指南保留最精簡的操作主線，適合首次連線。本頁進一步說明平台差異、參數意義、模式界線與排錯順序。已完成基本設定的使用者，可直接從目錄進入對應章節。

// CONTENT MAP

章節目錄

// 01 · PREPARE

通用準備工作與設定界線

安裝用戶端前，先確認平台、處理器架構、訂閱來源與接管範圍。多數安裝失敗不是用戶端本身異常，而是選錯安裝套件架構、舊程序仍占用連接埠、系統時間偏差，或訂閱參數與伺服器端不一致。準備階段固定這些變數，後續四大平台的操作會更清楚。

用戶端與平台對應關係

桌面端統一使用 v2rayN，支援 Windows、macOS 與 Linux，提供訂閱分組、伺服器清單、系統代理、TUN、路由規則與日誌檢視等圖形化入口。Android 首選 v2rayNG，使用 Xray 核心；需要 v2fly 核心時可選擇 v2flyNG。兩款 Android 用戶端的介面配置與設定匯入方式相近，但核心能力、部分實驗選項與設定相容範圍可能不同，不能將同一份進階設定直接視為完全等價。

安裝套件架構必須與裝置處理器相符。Windows 常見裝置選擇 x64；macOS 需先判斷 Apple Silicon 或 Intel；Linux 除處理器架構外，還要依發行版選擇 deb 或 rpm；近年的 Android 主流手機通常使用 arm64，無法確認時再選擇通用版。本網站的安裝套件頁面已依平台與架構分開入口，下載時不必自行從檔名清單猜測。

平台 首選用戶端 安裝套件判斷 主要接管方式
Windows v2rayN x64 桌面版或經典 WPF 版 系統代理、TUN
macOS v2rayN Apple Silicon arm64 或 Intel x64 系統代理、TUN
Linux v2rayN deb / rpm 與 x64 / arm64 桌面代理、環境變數、TUN
Android v2rayNG arm64 或通用版 系統 VPN 介面

訂閱、單一節點與本機設定

訂閱網址是一份可更新的遠端節點清單。用戶端儲存網址後，會依訂閱分組取得伺服器名稱、協定、連接埠與傳輸參數。單一節點連結適合臨時匯入或驗證一組參數；本機 JSON 設定則適合精細路由、多個出站與複雜 DNS 策略。三種方式解決的問題不同。日常使用建議優先保留訂閱分組，避免每次更新後重複手動輸入；需要測試進階規則時，可將現有設定複製到獨立分組，避免測試修改覆蓋穩定設定。

訂閱網址通常包含存取憑證，應依帳號資訊妥善管理。不要將完整網址貼到公開日誌、截圖或線上轉換頁面。需要進行 V2Ray 訂閱轉換時，應先確認轉換服務來源與輸出格式，並檢查轉換後是否保留 protocol、security、network、flow、SNI 與公鑰等關鍵欄位。轉換只會改變用戶端可讀取的表示形式，不會自動修正伺服器端與用戶端之間的參數差異。

連線前的環境檢查

首先校準系統日期、時間與時區。TLS 與 REALITY 交握依賴時間窗口，明顯偏差可能表現為節點持續逾時。其次關閉舊用戶端，確認本機代理連接埠未被其他程序占用。再次檢查安全軟體與系統防火牆是否允許用戶端及核心建立本機監聽與外部連線。最後準備可正常存取的訂閱網址，並確認帳號狀態、流量與有效期限。能顯示節點名稱，只代表訂閱內容已被讀取，不代表節點目前一定能連線。

連線驗證應分成三層：核心是否成功啟動、本機代理連接埠是否監聽、應用程式流量是否進入代理。只看網頁能否開啟，很難判斷問題位於哪一層。日誌顯示啟動完成但瀏覽器沒有流量，通常要檢查系統代理或瀏覽器獨立代理；本機連接埠未出現，則先處理設定解析、連接埠衝突或核心檔案權限；交握階段失敗，再回頭檢查伺服器參數與本機時間。

更新與備份原則

更新用戶端前，先匯出或備份訂閱分組、自訂路由、DNS 規則與本機設定。桌面端也應記錄目前的系統代理模式與本機監聽連接埠。跨越較大介面世代更新時，舊設定通常可以遷移，但欄位預設值可能改變，建議首次啟動後逐頁檢查核心設定。Android 更新前確認訂閱網址仍可取得，避免只依賴應用程式內已展開的暫存節點清單。

本手冊後續章節都採用相同的驗證順序：安裝完成後先啟動用戶端，再匯入訂閱並更新分組，選擇節點啟動核心，接著決定系統代理或 TUN，最後檢查日誌與實際流量。固定順序可避免同時變更多個變數。若只需十分鐘完成首次設定，可前往v2rayN 使用指南；需要逐項理解設定意義，則繼續閱讀對應平台章節。

// 02 · WINDOWS

Windows：v2rayN 安裝、訂閱與系統接管

Windows 是 v2rayN 功能最完整的平台。安裝時需在桌面版與經典 WPF 版之間選擇，連線後再依應用程式範圍決定使用系統代理或 TUN。兩者介面實作不同，但訂閱、節點、路由與核心日誌的基本概念一致。

選擇桌面版或經典 WPF 版

桌面版採用新一代跨平台介面，適合希望在不同桌面系統間維持相近操作結構的使用者。經典 WPF 版沿用成熟的 Windows 介面配置，適合已熟悉傳統伺服器清單、系統匣選單與設定入口的使用者。兩者不必同時執行。若要進行比較測試，應確保前一個用戶端已退出，並檢查是否已恢復系統代理，否則第二個用戶端啟動後可能接管同一組連接埠，造成日誌與實際流量來源混淆。

從Windows 安裝入口取得對應安裝套件後，依安裝精靈完成部署。首次啟動若出現網路存取或防火牆確認，應允許用戶端在目前使用的網路類型中通訊。安裝目錄與使用者設定目錄需具備正常讀寫權限。企業管理裝置可能限制代理設定、虛擬網卡或驅動程式安裝，這類限制需由裝置原則處理，反覆重新安裝用戶端無法繞過系統層級原則。

匯入訂閱並整理分組

進入訂閱分組管理，新增名稱清楚的分組，將訂閱網址填入對應欄位並儲存，接著更新目前分組。更新成功後，伺服器清單會出現節點；若分組存在但清單為空，先開啟日誌查看 HTTP 狀態、解析錯誤或格式提示。不要在短時間內連續快速點擊更新，因為部分訂閱服務會限制請求頻率。更新前後節點數量變化屬於伺服器端清單調整，用戶端不會憑空建立節點。

伺服器清單建議保留名稱、位址、連接埠、協定、傳輸、安全層與訂閱分組等關鍵欄位。選擇節點時，不要只依賴名稱中的地區或線路描述，應先進行一次實際連線並觀察交握日誌。延遲測試只能反映該測試方式下的網路可達性，無法涵蓋目標應用程式的所有存取路徑。確認穩定節點後，將其設為活動伺服器，再啟動系統代理或 TUN。

手動匯入單一節點時，可以從剪貼簿讀取標準分享連結，也可以在伺服器編輯視窗逐項填寫。編輯 REALITY 節點尤其要注意 serverName、fingerprint、publicKey、shortId 與 flow。若分享連結匯入後仍無法連線，應逐項比對欄位與伺服器端提供的資訊，而不是隨意切換安全選項。

系統代理模式的使用範圍

系統代理適合遵循 Windows 代理設定的瀏覽器與桌面應用程式。啟用後，v2rayN 會將系統代理指向本機監聽位址與連接埠，應用程式再透過用戶端轉送。通常應先維持「自動設定系統代理」或同等狀態，再開啟瀏覽器驗證。若某個程式忽略系統代理，需在程式內指定 HTTP 或 SOCKS 位址，或改用 TUN。

系統代理的路由模式決定哪些目標進入代理。全域模式方便短時間驗證節點是否正常，但不適合作為複雜分流的最終設定；規則模式會依網域、IP、geosite 與 geoip 規則選擇直連、代理或阻斷。修改模式後應重新發起連線，既有長連線可能繼續沿用舊路徑。退出用戶端前恢復系統代理是良好習慣，尤其適用於經常切換網路或從睡眠喚醒的裝置。

TUN 模式與權限

TUN 透過虛擬網路介面接管更廣泛的流量，適合不讀取系統代理的應用程式、命令列工具與需要統一分流的情境。首次啟用通常需要管理員權限，並可能觸發虛擬網卡或網路元件安裝。啟用前退出其他同類網路工具，避免多個虛擬介面同時修改預設路由。啟用後應檢查 TUN 狀態、DNS 監聽與路由日誌，確認流量確實進入目前的核心。

TUN 不代表所有連線都會自動可用。區域網路存取、虛擬機網路、開發容器、遠端桌面與企業內網可能依賴特定路由。若啟用後無法存取本地裝置，應將私有位址區段設為直連，並檢查嚴格路由、自動路由與 DNS 劫持設定。關閉 TUN 後網路未立即恢復時，可先完全退出用戶端，再停用並重新啟用目前的網路介面卡；不要在尚未定位問題時同時重設所有網路設定。

日誌、系統匣與啟動行為

v2rayN 的主日誌用於觀察設定產生、核心啟動、本機連接埠與錯誤資訊。排查時先清除舊日誌，再重現一次問題，避免將上一個節點的錯誤誤認為目前結果。常見重點包括連接埠占用、設定欄位無法解析、DNS 請求失敗、連線逾時與交握中斷。若日誌顯示核心正常啟動，下一步應檢查系統代理與路由；若核心反覆退出，則回頭檢查設定檔與權限。

系統匣選單通常用於快速切換系統代理、目前伺服器與退出程式。關閉主視窗不一定代表程序已退出，因此更換版本或排查連接埠時，應從系統匣明確退出。設定開機啟動前，先確認預設節點、訂閱更新行為與接管模式符合預期。經常切換家庭、辦公室與行動熱點的可攜式裝置，建議保留手動確認接管模式的步驟，避免登入系統後直接沿用不適合目前網路的路由。

// 03 · MACOS

macOS：晶片選擇、權限與代理設定

macOS 版 v2rayN 與其他桌面版共用主要功能，但安裝套件必須與處理器架構一致，首次執行還會涉及應用程式確認、網路設定與 TUN 權限。先處理系統層級許可，再判斷節點與協定問題，可以減少無效的重新安裝。

確認處理器並完成安裝

開啟系統資訊或「關於這台 Mac」查看晶片名稱。顯示 Apple 晶片時選擇 arm64 安裝套件，顯示 Intel 處理器時選擇 x64 安裝套件。架構錯誤可能導致應用程式無法啟動，或透過相容性轉譯執行但行為不穩定。從macOS 安裝入口下載對應 DMG，開啟後依視窗提示將應用程式放入「應用程式」目錄，再從該目錄啟動。

首次執行時，系統可能要求確認應用程式來源或網路存取。依照系統設定中的安全提示完成確認，不要反覆將應用程式複製到不同目錄。多個副本會讓設定位置、自動啟動項目與目前執行版本難以判斷。若更新後仍看到舊介面，應從活動監視器確認舊程序已結束，再從「應用程式」目錄啟動新副本。

匯入訂閱與選擇伺服器

進入訂閱管理，建立分組並儲存訂閱網址，然後更新分組。節點出現後，先選擇一個設定明確的伺服器作為活動節點。若訂閱更新失敗，檢查目前網路能否存取訂閱網址、網址是否完整複製，以及系統日期是否準確。若訂閱連結包含特殊字元，請完整貼上，不要自行刪改查詢參數。

macOS 上的節點參數檢查與 Windows 相同。VLESS 設定要注意使用者識別、加密欄位、傳輸層與 flow；REALITY 還需核對 serverName、fingerprint、publicKey 與 shortId；WebSocket 或 gRPC 則要保持路徑、主機名稱或 serviceName 一致。某節點在另一台裝置可用，只代表伺服器端整體可達，目前裝置的匯入結果仍可能遺漏欄位。

系統代理與應用程式差異

啟用系統代理後，v2rayN 會修改目前網路服務的代理設定。多數瀏覽器與遵循系統網路框架的應用程式會自動使用此設定。命令列程式、開發工具與部分跨平台應用程式可能讀取自己的代理環境變數，或完全繞過系統代理。判斷是否接管時應同時查看用戶端日誌：開啟目標應用程式並發出新請求，若日誌沒有連線記錄，表示流量尚未進入 v2rayN。

終端機中的臨時代理可以明確指向 v2rayN 的本機 HTTP 監聽連接埠。連接埠以用戶端設定頁面實際顯示的值為準，以下範例使用常見的本機位址，僅用於說明環境變數寫法：

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808

# 目前終端機工作階段結束後不再保留
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

未確認連接埠前，不要將範例長期寫入 shell 設定檔。若用戶端日後調整連接埠，舊環境變數會讓終端機持續連線到失效連接埠。需要長期使用時，應讓連接埠修改紀錄與 v2rayN 設定保持同步，並在關閉用戶端時明確取消代理變數。

TUN、DNS 與系統授權

TUN 模式適合接管不遵循系統代理的應用程式。首次啟用時，系統可能要求管理員授權或允許網路延伸功能。完成授權後，檢查選單列網路狀態與 v2rayN 日誌，確認虛擬介面已建立。若同時執行其他會修改路由或 DNS 的工具，應先退出，只保留一個接管者。多個工具同時寫入預設路由時，可能出現網頁偶爾可用、區域網路中斷或 DNS 請求循環。

DNS 設定需要與路由策略一起理解。網域先解析再比對 IP，與直接依網域規則比對，結果可能不同。若使用 FakeDNS，應確認目標應用程式與區域網路服務適合這種對映方式。關於保留位址對映與 TUN 情境界線，可繼續閱讀FakeDNS 虛擬 DNS 對映原理詳解。區域網路列印、檔案共享或開發裝置探索異常時，優先將私有位址與本地域名設為直連，並暫時關閉進階 DNS 功能進行比對。

睡眠、網路切換與退出後恢復

筆電從睡眠恢復或切換無線網路後，原有連線、DNS 快取與預設路由可能已失效。此時先停止目前連線，再重新選擇節點並啟動；若系統代理指向仍正確但沒有流量，重新啟動核心通常比重新安裝用戶端更有效。從公司環境切換到家庭環境時，也應檢查原先用於內網的直連規則是否仍符合目前需求。

退出 v2rayN 前，應先關閉系統代理或 TUN，讓系統恢復一般網路路徑。若強制結束程序後網路異常，開啟系統網路設定，檢查目前網路服務的 HTTP、HTTPS 與 SOCKS 代理是否仍指向本機連接埠。確認殘留項目後再關閉，不要刪除整個網路服務。應用程式能啟動、核心能執行、系統代理能恢復，是 macOS 安裝完成後的三個獨立驗收點。

// 04 · LINUX

Linux：軟體套件安裝、桌面代理與 TUN

Linux 版 v2rayN 面向桌面環境。安裝時需同時判斷發行版套件體系與處理器架構，執行後還要區分桌面系統代理、終端機環境變數與 TUN 三種流量入口。不同發行版的選單名稱雖有差異，但排查邏輯一致。

選擇 deb、rpm 與處理器架構

Debian、Ubuntu 及其常見衍生系統通常使用 deb；Fedora、Rocky Linux、AlmaLinux 等使用 rpm。處理器為常見桌面 x86-64 時選擇 x64，arm64 裝置則選擇相應架構。可透過以下命令確認架構與系統資訊：

uname -m
cat /etc/os-release

x86_64 對應 x64，aarch64 通常對應 arm64。確認後從Linux 安裝入口選擇軟體套件。不要只憑發行版桌面外觀判斷套件格式，也不要將不同架構的軟體套件強制安裝到目前系統。軟體套件管理器回報相依性問題時，應先重新整理發行版的套件來源中繼資料，再讓套件管理器處理相依關係。

使用套件管理器完成安裝

在下載目錄中，deb 可交由 apt 安裝，rpm 可交由 dnf 安裝。實際檔名以下載結果為準，以下命令示範從目前目錄安裝明確的軟體套件檔案：

# Debian / Ubuntu 系
sudo apt update
sudo apt install ./v2rayN-linux-x64.deb

# Fedora / Rocky Linux 系
sudo dnf install ./v2rayN-linux-x64.rpm

使用套件管理器而非只解壓縮檔案，可以讓桌面入口、相依套件與解除安裝紀錄保持一致。安裝完成後從應用程式選單啟動 v2rayN。若終端機提示找不到顯示環境，表示目前工作階段可能不在圖形桌面中；v2rayN 是圖形化用戶端，不應將桌面啟動方式直接當成無介面伺服器服務。遠端桌面環境還要確認目前使用者擁有圖形工作階段與使用者設定目錄的寫入權限。

應用程式啟動後立即退出時，可以從終端機啟動一次並讀取標準錯誤，同時查看使用者日誌目錄。常見原因包括圖形函式庫相依套件缺失、安裝套件架構錯誤、設定目錄權限異常或舊程序仍在執行。不要直接以管理員身分長期執行整個用戶端來規避權限問題，這會改變使用者設定檔的擁有者，並擴大 TUN 以外不必要的權限範圍。

訂閱管理與桌面系統代理

建立訂閱分組、貼上網址、儲存並更新。產生節點清單後選擇活動伺服器，先啟動核心但暫不啟用 TUN，透過用戶端日誌確認本機 HTTP 與 SOCKS 監聽已建立。接著在 v2rayN 中設定系統代理。GNOME、KDE 與其他桌面環境儲存系統代理的方式不同，部分應用程式會讀取桌面代理，部分只讀取環境變數，因此不能用單一瀏覽器結果代表整個系統。

啟用桌面代理後，可以在系統設定中檢查 HTTP、HTTPS 與 SOCKS 是否指向本機。終端機工具有需要時，可依目前監聽連接埠設定環境變數。從桌面選單啟動的圖形程式不一定會繼承終端機中的變數；從同一終端機啟動的程式通常會繼承。排查時要記錄應用程式究竟從哪個工作階段啟動，避免環境變數看似正確但實際程序未讀取。

TUN、能力授權與路由

Linux TUN 需要建立虛擬介面、寫入路由並處理 DNS，相關操作需要系統權限。優先使用用戶端提供的授權流程，不要任意給整個程式永久管理員權限。啟用前檢查系統是否已有其他 VPN 介面、容器網路、虛擬機橋接或策略路由。開發工作站的網路拓撲往往比一般桌面複雜，自動路由可能影響容器存取主機、區域網路服務探索或遠端維護連線。

啟用 TUN 後，使用 ip address 與 ip route 查看介面與路由變化，並結合 v2rayN 日誌判斷流量是否抵達核心：

ip address
ip route
ss -lntup | grep -E '10808|10809'

最後一個命令中的連接埠只是常見範例，實際使用時應替換為用戶端目前的監聽連接埠。若 TUN 介面存在但無法解析網域，應檢查 DNS 監聽、系統解析器與發行版使用的網路管理服務。若 IP 連線正常而網域失敗，問題集中於 DNS；若所有目標都沒有日誌，則檢查預設路由是否進入虛擬介面；若只有區域網路失敗，應新增私有位址直連規則。

更新、解除安裝與設定目錄

透過新軟體套件更新前，先退出 v2rayN，並備份訂閱、自訂路由與 DNS 設定。使用相同套件管理器安裝新套件，通常會沿用使用者設定；更新後首次啟動要核對本機連接埠與接管模式。若舊程序未退出，新程式可能因設定鎖定或連接埠占用而無法正常啟動。可先透過系統監視器或程序清單確認，再決定是否結束舊程序。

解除安裝軟體套件與刪除使用者設定是兩件事。套件管理器移除應用程式時，使用者目錄中的設定可能仍會保留，方便日後復原。排錯時不建議一開始就刪除整個設定目錄，因為這會同時遺失有助於定位問題的日誌與規則。較穩妥的方法是匯出設定、關閉程式，將現有設定目錄重新命名，再以乾淨環境啟動進行比對。若乾淨環境可用，再逐項移回訂閱與規則，即可找出觸發異常的具體部分。

// 05 · ANDROID

Android：v2rayNG 匯入、連線與應用程式分流

Android 首選 v2rayNG，使用 Xray 核心；v2flyNG 作為 v2fly 核心的備選。行動裝置透過系統 VPN 介面接管流量，不使用桌面系統代理。權限、電池策略、背景限制與應用程式分流，是行動端與桌面端最明顯的差異。

選擇 arm64 或通用安裝套件

近年的主流 Android 手機通常選擇 arm64；無法確認裝置架構或 arm64 套件無法安裝時，再使用通用版。v2rayNG 與 v2flyNG 都提供相應入口，具體順序與架構說明請見Android 安裝頁面。在同一裝置上切換用戶端時，先停止目前連線，避免系統 VPN 介面仍被另一個應用程式占用。

首次啟動後，用戶端會在連線時要求建立 VPN 連線。系統一次只能將目前流量交給一個此類連線，因此其他 VPN 類應用程式可能導致授權被覆蓋或連線立即中斷。若點擊連線後沒有出現狀態圖示，應查看系統授權是否完成，並確認未受裝置管理原則限制。

訂閱與分享連結匯入

開啟訂閱設定，新增分組名稱與訂閱網址，儲存後執行更新。行動網路下更新失敗時，可切換到穩定的無線網路再次測試；若兩種網路都失敗，則檢查訂閱網址、帳號狀態與日誌。訂閱更新成功後返回主清單，選擇節點，再點擊連線按鈕。不要在訂閱更新期間頻繁切換應用程式或清理背景程序，這可能中斷下載與解析。

單一節點可透過剪貼簿中的標準分享連結匯入，也可以掃描可信來源提供的 QR Code。匯入後進入編輯頁面，核對伺服器位址、連接埠、使用者識別、傳輸、安全層與 SNI。QR Code 只是一種編碼載體，不會代替使用者判斷參數是否相符。REALITY 節點還要確認 fingerprint、publicKey、shortId 與 flow；欄位缺失時，用戶端仍可能儲存設定，但交握會失敗。

訂閱更新通常會替換分組中的遠端節點。需要長期保留的手動修改，應複製到獨立分組，避免下一次更新覆蓋。節點名稱只用於識別，修改名稱不會改變連線參數。若清單很長，可以依訂閱分組管理，不要將多個來源混在同一層級。

路由模式與應用程式分流

連線前選擇合適的路由模式。全域模式方便驗證目前節點；規則模式依網域與 IP 決定代理或直連；自訂設定適合需要精細 DNS、多個出站或特定規則順序的使用者。首次設定建議先用簡單模式確認連線，再逐步增加規則。若一開始同時啟用複雜 DNS、應用程式分流與多組路由，發生異常時很難判斷是哪一層造成。

應用程式分流可以指定哪些應用程式進入 v2rayNG，或排除明確需要直連的應用程式。設定時要注意系統元件、瀏覽器與目標應用程式之間的呼叫關係。例如某個應用程式可能呼叫外部瀏覽器完成登入，若兩者不在相同路徑上，回呼流程可能失敗。修改應用程式清單後，應中斷並重新連線，讓系統 VPN 介面依新規則建立。

區域網路裝置、投放、列印與檔案傳輸通常需要私有位址直連。若發現開啟連線後區域網路功能失效，應先檢查繞過區域網路或私有位址規則，再觀察 DNS 是否將本地域名交給遠端解析。規則順序同樣重要：更具體的直連規則應放在會提前命中的寬泛代理規則之前。

電池最佳化與背景穩定性

部分裝置會在螢幕關閉、低電量或長時間背景執行時限制 v2rayNG。表現為連線圖示仍存在但流量停止，重新開啟應用程式後恢復。可在系統電池設定中允許用戶端依實際需要執行，並確認未限制背景資料。不同廠商的選單名稱各異，核心目標是避免系統在連線期間凍結用戶端或核心程序。

穩定性測試至少應涵蓋前景瀏覽、關閉螢幕後恢復、無線網路與行動網路切換。網路切換會改變本機位址、DNS 與預設路由，短暫重新連線屬於正常恢復過程；若每次切換後都無法恢復，先中斷再連線，並查看日誌停在 DNS、交握還是系統 VPN 建立階段。不要只透過狀態列圖示判斷連線品質，圖示代表介面存在，不代表目標節點已完成交握。

v2rayNG 與 v2flyNG 的切換界線

v2rayNG 適合使用 Xray 核心能力與相關協定設定，是 Android 的首選。v2flyNG 使用 v2fly 核心，可作為特定設定需求下的備選。切換用戶端前先匯出或儲存訂閱網址，不要假設兩者會共用應用程式內部資料庫。同一訂閱在兩款用戶端中展開的基礎節點通常相近，但進階設定欄位、實驗功能與預設行為可能不同。

比較時保持節點、網路與路由模式一致，每次只更換一個變數。若 v2rayNG 能連線而 v2flyNG 不能，應先檢查設定是否使用後者目前不處理的欄位；反過來則檢查匯入結果與預設設定。排查目標不是反覆切換核心，而是確認訂閱格式、協定參數與用戶端能力是否相符。

// 06 · ROUTING

訂閱、系統代理、TUN 與路由規則

四大平台的介面不同，但核心資料流一致：應用程式先將請求交給本機代理或虛擬介面，核心依路由規則選擇出站，再依節點協定建立連線。理解這個順序後，系統代理、TUN、DNS 與訂閱就不再是彼此孤立的開關。

訂閱更新究竟會改變什麼

訂閱更新主要會變更伺服器清單及其連線參數，不應自動改寫所有本機偏好。用戶端通常會將遠端節點放入對應分組，同時保留本機路由、系統代理模式與部分介面設定。不同訂閱格式對分組、標籤與進階欄位的表達能力不同，轉換後可能出現欄位遺失或命名變更。因此每次更換訂閱格式後，應抽查至少一個節點的協定、安全層、傳輸與 flow，不要只確認清單已出現。

多個訂閱來源應分組儲存。分組不僅方便更新，也能避免同名節點難以追溯。刪除訂閱分組前，先確認目前活動伺服器是否屬於該分組；更新後目前節點被移除時，用戶端可能保留舊快取，也可能要求重新選擇。遇到連線突然失效，應先更新目前訂閱並選擇仍存在的節點，再處理更複雜的網路問題。

系統代理與 TUN 的選擇

系統代理是應用程式主動讀取代理位址後，再連線到本機連接埠，邊界清楚、對系統路由影響較小，適合瀏覽器與標準桌面應用程式。TUN 從網路層接管流量，覆蓋範圍更廣，適合不支援代理設定的程式與統一分流。兩者不必為了「更強」而同時疊加。多數情況選擇一個主要入口即可，同時使用會增加迴圈與重複接管的判斷成本。

項目 系統代理 TUN
接管範圍 遵循系統或應用程式代理設定的流量 進入虛擬介面並符合路由的流量
系統影響 主要修改代理設定 涉及虛擬介面、路由與 DNS
適用情境 瀏覽器、一般桌面應用程式、單獨設定的命令列工具 不讀取代理的應用程式、統一分流、應用程式層級接管
排查重點 本機連接埠、應用程式代理、系統代理殘留 權限、預設路由、私有網段、DNS 與介面衝突

路由比對順序

路由規則通常依序比對，命中後選擇直連、代理或阻斷出站。具體網域、特定網段與必須保留的區域網路規則，應放在寬泛規則之前。常見結構是：私有位址直連，明確網域集合依需求分流，其餘流量進入預設出站。規則越多不代表結果越準確，重複集合與交叉條件會讓實際命中難以預測。

domainStrategy決定網域規則未直接命中時，是否進一步解析 IP。IPIfNonMatch表示網域規則沒有結果時再解析並嘗試 IP 規則，兼顧網域比對與 IP 資料庫；完全依賴 IP 規則會增加 DNS 對結果的影響。以下是可合併至 Xray 根設定的路由物件範例，出站標籤需與目前設定中的實際定義一致：

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

範例中的最後一條是兜底規則，應放在具體規則之後。若設定還包含阻斷廣告、開發環境網域或特定服務直連，需放在兜底規則之前。關於 geosite 與 geoip 的組合、比對順序及三段式範本，可參閱路由規則分流實戰。

DNS、FakeDNS 與洩漏路徑

DNS 決定網域如何轉換為位址，也會影響網域規則與 IP 規則的先後關係。系統代理模式下，應用程式可能自行解析網域，也可能將網域交給代理；SOCKS 的使用方式還會決定解析發生在本機或遠端。TUN 模式通常會集中處理 DNS，但仍要留意瀏覽器安全 DNS、應用程式內建解析與區域網路名稱服務。排查時先釐清由誰負責解析，再討論使用哪個 DNS 伺服器。

FakeDNS 使用保留位址建立網域對映，核心在後續連線中還原原始網域。它能減少部分解析往返，並協助 TUN 保留網域資訊，但不適合所有應用程式。依賴真實 IP、區域網路探索、某些點對點流程或自行驗證解析結果的應用程式可能出現異常。啟用前應保留一份一般 DNS 設定，發生問題時可快速比對，不要同時修改路由與節點。

REALITY 與傳輸參數核對

REALITY 設定常見於 VLESS 節點。用戶端必須正確儲存伺服器位址、連接埠、使用者識別、serverName、fingerprint、publicKey、shortId 與 flow。xtls-rprx-vision 需與伺服器端設定及節點協定一致。network 通常由伺服器端決定，不能一看到連線失敗就任意在 tcp、WebSocket 或 gRPC 之間切換。

交握失敗時先核對欄位，再檢查系統時間與基本連線能力。若日誌顯示已建立伺服器連接埠連線，但隨後在安全交握階段終止，表示本機代理與網路入口大致正常，重點應轉向 SNI、公鑰、shortId、指紋與 flow。若連伺服器連接埠都無法抵達，則優先檢查位址、連接埠、目前網路與節點狀態。分層判斷比不斷更換用戶端設定更有效。

設定變更後的驗證

每次修改訂閱、路由或 DNS 後，先停止連線，再重新啟動核心。清除日誌，分別測試一個應直連的目標、一個應走代理的目標與一個區域網路目標。檢查三者命中的出站標籤是否符合預期。只測試單一網頁無法證明分流規則完整，因為它可能包含多個網域、連線重用與快取。

驗證結束後記錄目前用戶端、訂閱分組、活動節點、接管方式與自訂規則。桌面端與 Android 使用同一訂閱時，可以共用伺服器參數，但系統代理、TUN 與應用程式分流仍需依裝置分別設定。將節點設定與裝置接管設定分開管理，是跨平台維持穩定的關鍵。

// 07 · TROUBLESHOOTING

常見設定問題與固定排查順序

故障排查的核心是先確認失敗層級，再處理對應變數。建議順序為：系統時間與網路、訂閱與節點、核心啟動、本機監聽、流量接管、DNS、路由規則。固定順序後，多數問題不必重新安裝用戶端。

第一步：確認基本網路、時間與訂閱狀態

先在關閉用戶端接管的狀態下，確認目前網路能正常連線一般網站，並校準日期、時間與時區。公司網路、公共無線網路與行動熱點可能採用不同的連接埠策略，同一節點在一個網路可用、在另一個網路逾時並不矛盾。接著檢查訂閱是否仍有效、帳號是否到期、流量是否可用，並執行一次訂閱更新。

若訂閱本身無法更新，問題發生在連線節點之前。查看日誌中的 HTTP 狀態、逾時或解析資訊，確認訂閱網址完整且目前網路可存取。不要在這個階段修改節點協定欄位，因為用戶端尚未取得新的設定。節點清單能更新但全部無法連線，再進入下一步。

第二步：檢查節點參數與伺服器可達性

選擇一個參數明確的節點，逐項核對位址、連接埠、協定、使用者識別、安全層與傳輸。REALITY 還要檢查 serverName、fingerprint、publicKey、shortId 與 flow。WebSocket 檢查 path 與 host，gRPC 檢查 serviceName。訂閱轉換後尤其要留意進階欄位是否保留。

日誌中的逾時只表示在限定時間內未完成目前步驟，不代表原因只有一個。連線至伺服器位址前逾時，可能是位址解析、連接埠無法連通或目前網路限制；TCP 建立後交握逾時，重點檢查安全層與伺服器狀態；連線很快被關閉，可能是參數不相符或伺服器主動拒絕。可依節點逾時六步排查清單逐項比對。

第三步：確認核心啟動與本機連接埠

清除日誌，停止連線，再重新啟動一次。首先尋找設定載入與核心啟動結果，接著確認本機 HTTP、SOCKS 或 TUN 監聽已建立。若提示位址已被占用，退出其他用戶端或修改衝突連接埠；關閉視窗不一定會結束背景程序，應檢查系統匣、活動監視器、系統監視器或應用程式清單。

設定解析錯誤通常會明確指出欄位類型、未知選項或 JSON 結構位置。自訂 JSON 出錯時，先恢復到用戶端產生的基本設定，再分段合併自訂內容。JSON 不可加入註解，陣列與物件結尾也不可保留多餘逗號。核心能持續執行後，才進入系統代理與流量接管排查。

第四步：判斷應用程式流量是否進入用戶端

啟動節點後開啟目標應用程式並發出全新請求，同時觀察存取日誌。完全沒有記錄表示流量未抵達用戶端。桌面端檢查系統代理是否啟用、應用程式是否使用獨立代理、終端機是否設定正確環境變數；Android 檢查系統 VPN 授權與應用程式分流；TUN 情境檢查虛擬介面與預設路由。

日誌出現連線記錄但目標行為異常，表示入口已建立，應繼續檢查出站、DNS 與路由。瀏覽器可能重用舊連線，測試前可關閉相關分頁或重新啟動瀏覽器。部分應用程式具有自己的 DNS 與代理設定，應分別檢查，不能只依據系統設定推斷。

第五步：拆分 DNS 與路由問題

網域連線失敗但直接 IP 連線可用，通常需要檢查 DNS。查看解析請求是否進入核心、使用哪台伺服器、是否被瀏覽器安全 DNS 繞過，以及 FakeDNS 是否適合目前應用程式。若 DNS 回傳位址但連線走錯出站，則檢查 domainStrategy、規則順序與 geosite、geoip 資料比對。

只有部分網站失敗時，記錄失敗網域及其命中規則，不要直接切換到全域模式長期使用。全域模式可用於證明節點整體正常，但最終仍應恢復規則模式並修正具體條件。區域網路失效時優先確認私有位址直連；本地域名解析失敗時，檢查系統搜尋網域與本機 DNS 是否被覆蓋。

現象 優先檢查 下一步
訂閱無法更新 網址完整性、帳號狀態、目前網路、日誌狀態 更換網路進行比對，不修改節點欄位
核心啟動後立即退出 設定解析、連接埠占用、檔案權限 恢復基本設定並重新啟動
瀏覽器沒有日誌 系統代理、應用程式獨立代理、本機連接埠 建立新連線並觀察存取日誌
啟用 TUN 後區域網路失效 私有網段、自動路由、DNS 與其他虛擬介面 新增直連規則並單獨測試
REALITY 交握失敗 時間、SNI、公鑰、shortId、指紋、flow 逐項與伺服器端設定比對
網路切換後停止傳輸 舊連線、預設路由、背景限制 停止核心並重新建立連線

平台特有的恢復操作

Windows 在強制退出後，可檢查系統代理是否仍指向本機失效連接埠，並確認舊程序已結束；TUN 網路未恢復時，先退出用戶端，再重新啟用目前的網路介面卡。macOS 檢查目前網路服務的代理項目與虛擬網路授權，不要刪除整個網路設定。Linux 查看虛擬介面、預設路由、DNS 服務與程序監聽，遠端裝置先確保管理回程。Android 檢查系統 VPN 是否仍被舊應用程式占用、電池策略是否凍結背景程序，以及網路切換後是否完成重新連線。

這些恢復操作只處理系統接管殘留，不會修正節點參數。若恢復一般網路後用戶端仍無法連線，應回到日誌層級重新排查。反覆重新安裝會清除部分上下文，卻無法改變訂閱狀態、伺服器參數與目前網路條件，因此只應在確認應用程式檔案損壞或升級遷移異常後使用。

如何整理有效日誌

提交或自行保存排查紀錄時，應包含平台、用戶端名稱、接管方式、協定類型、問題發生時間、操作步驟與相關錯誤行。訂閱網址、使用者識別、公鑰以外的帳號憑證及完整分享連結都應隱藏。日誌應擷取自清除後的一次完整重現，避免混入多個節點與多次啟動記錄。

有效描述應類似：「Windows 使用 v2rayN，系統代理模式；訂閱更新成功，核心監聽成功；瀏覽器請求能出現在日誌中，但 REALITY 交握在選擇活動節點後失敗。」這類描述已明確排除訂閱、核心與流量入口三層。只寫「無法使用」則無法判斷應從何處開始檢查。更多常見問答可前往疑難解答，其中依基礎認知、安裝設定、使用技巧與故障排查分類整理。

建立可回復的穩定設定

問題解決後，記錄目前訂閱分組、活動節點、路由模式、DNS 策略、本機連接埠與平台權限。將自訂設定另存一份基準，後續修改從副本開始。桌面端更新前備份設定，Android 保留訂閱來源與關鍵節點參數。穩定設定的價值不在於永遠不變，而在於每次測試後都能快速回到已驗證狀態。

完整驗收應涵蓋啟動、訂閱更新、節點交握、系統接管、直連規則、代理規則、區域網路存取與網路切換。四大平台的按鈕位置不同，判斷邏輯始終一致：先確認資料來源，再確認核心，接著確認流量入口，最後確認 DNS 與出站。依此順序維護，即使設定規模增加，也能定位到具體層級。