V2Ray 全平台安裝設定完整指南

01 / PREPARE

通用準備工作：先分清客戶端、核心與訂閱

客戶端不是節點，也不是訂閱服務

安裝前先拆解三個名詞。v2rayN、v2rayNG 和 v2flyNG 是圖形化客戶端，負責儲存設定、呼叫核心、設定系統代理以及顯示執行記錄。V2Fly、Xray 屬於核心家族，實際處理入站、出站、路由、DNS 與傳輸協定。訂閱連結則是由服務端維護的節點清單，客戶端讀取連結後，會將清單轉換成可選擇的伺服器設定。只安裝客戶端不會自動出現可連線節點；只有訂閱連結但沒有相容客戶端，也無法直接讓系統流量套用對應設定。

桌面平台統一優先選擇 v2rayN。它在 Windows 上提供桌面版與經典 WPF 版，在 macOS 和 Linux 上提供對應安裝包，選單位置會因介面版本略有差異，但核心概念相同：訂閱群組儲存連結，伺服器清單儲存節點，系統代理負責瀏覽器等遵循系統設定的程式，TUN 則透過虛擬網路介面接管更廣泛的流量。Android 優先選擇搭載 Xray 核心的 v2rayNG；需要使用 V2Fly 核心家族時，再考慮 v2flyNG。具體安裝包應從本站的客戶端頁面按平台選擇。

安裝前記錄四項基本資訊

準備設定時，至少確認訂閱連結是否完整、裝置時間是否自動同步、目前網路是否能正常存取常用網站，以及系統架構。訂閱連結通常是一段以 HTTP 或 HTTPS 開頭的網址，複製時不能帶有空格、換行或聊天軟體產生的尾端標點。系統時間誤差會影響 TLS 交握與憑證判斷，常見情況是節點看似存在，連線卻立即失敗。先開啟系統的自動設定時間與時區，再繼續處理客戶端問題，比反覆切換節點更有效。

系統架構決定安裝包。Windows 常見裝置使用 x64；macOS 需要在 Apple Silicon 與 Intel 安裝包之間選擇；Android 主流裝置通常使用 arm64，無法確認架構時可以使用通用包；Linux 除了架構外，還要確認發行版的軟體包體系，Debian、Ubuntu 及其衍生系統通常使用 deb，Fedora、RHEL 系及相關發行版通常使用 rpm。套件格式選錯通常不會損壞系統，但安裝程式會直接拒絕，或提示架構不相符。

建立可回復的最小設定

第一次執行時不要同時修改路由、DNS、傳輸層參數和 TUN。最小設定只有四步：匯入訂閱、更新訂閱、選擇一個節點、開啟系統代理或行動端連線。接著用瀏覽器造訪原本就穩定的網站，並觀察客戶端記錄。連線成功後再增加分流和 DNS；每次只修改一類設定，出現異常時才能知道是哪一步引入的。許多「突然全部不能用」的問題，並不是節點同時失效，而是多個進階選項一起調整後失去可追蹤性。

建議為初始訂閱群組取一個容易辨識的名稱，並保留預設路由設定。更新前不要手動修改訂閱產生的節點欄位，因為下次更新通常會覆蓋這些修改。如果確實需要針對單一節點調整傳輸參數，應複製成獨立設定，或先確認訂閱提供方是否支援在服務端修改。訂閱連結本身屬於敏感設定，不應貼入公開截圖、記錄或求助內容。需要排錯時，保留錯誤類型、時間點和客戶端狀態即可，網域、使用者識別資訊與節點位址應做好必要遮蔽。

最後準備一條回復路徑：記住系統代理開關的位置，並確認關閉客戶端後如何恢復系統網路。桌面端若使用系統代理，退出客戶端前先清除系統代理；使用 TUN 時先關閉 TUN，再退出程式。Android 端中斷連線即可釋放系統連線。完成這些準備後，各平台的安裝流程只是介面與權限模型不同，訂閱、節點、路由和 DNS 的底層邏輯一致。

02 / WINDOWS

Windows：v2rayN 安裝、訂閱與系統代理

桌面版與經典 WPF 版如何選擇

Windows 平台首選 v2rayN。下載頁提供桌面版與經典 WPF 版兩個入口。桌面版採用新一代跨平台介面，適合新安裝及同時使用多個桌面系統的人；經典 WPF 版採用 Windows 原生介面路線，選單密度較高，適合已熟悉舊版操作邏輯的使用者。兩者都能完成訂閱管理、節點選擇、系統代理、路由與 TUN 設定，不需要同時安裝。拿不定主意時先使用桌面版，只有在介面相容性、舊設定遷移或操作習慣上有明確需求時再選 WPF 版。

下載完整安裝包後，依照安裝程式提示完成安裝。若系統跳出使用者帳戶控制視窗，應先核對程式名稱與目前操作是否相符，再允許繼續。安裝路徑盡量使用目前使用者可寫入的目錄，不要把程式資料目錄放在會被自動清理的位置。首次啟動後，v2rayN 通常會建立設定目錄並準備核心元件。出現防火牆提示時，只允許目前確實需要的網路範圍；一般單機使用不需要為了「防止連線失敗」而開放無關的入站存取。

匯入訂閱並選擇使用中的節點

進入訂閱群組管理，新增群組名稱，將完整訂閱網址貼到 URL 輸入框並儲存。接著執行更新訂閱。更新成功後，主清單會出現伺服器項目；如果只儲存連結而沒有執行更新，清單保持空白是正常現象。選取一個節點並設為使用中的伺服器，狀態列或清單標記會顯示目前選擇。節點名稱只是訂閱中的描述，不代表連線品質，第一次測試不必連續批次測速，先選一個設定完整的項目確認基本連線即可。

更新失敗時先檢查連結頭尾是否多了空格、瀏覽器能否開啟訂閱網址，以及群組是否已啟用。訂閱內容可能是 Base64 文字、分享連結集合或結構化設定，客戶端會根據內容判斷格式。不要手動把整段訂閱內容貼進單一節點編輯器，也不要把單條 VMess 或 VLESS 分享連結誤填到訂閱 URL。單條分享連結應從剪貼簿匯入伺服器，訂閱 URL 則放入訂閱群組，兩類入口用途不同。

先開啟系統代理，再判斷是否需要 TUN

選擇節點後啟動服務，並將系統代理模式設為自動設定系統代理，或清楚標示為已啟用的模式。此時遵循 Windows 系統代理的瀏覽器與桌面應用程式會將流量交給 v2rayN。本機監聽連接埠由客戶端管理，通常不需要手動填寫。若某個程式提供自己的代理設定，可以選擇「使用系統代理」；只有它不讀取系統設定時，才需要查看 v2rayN 目前的本機 HTTP 或 SOCKS 連接埠並單獨填寫。

系統代理適合先驗證設定，因為鏈路短、權限少，也容易關閉。遊戲、部分命令列程式、商店應用程式或自行實作網路堆疊的軟體可能繞過系統代理，此時才考慮 TUN。開啟 TUN 往往需要管理員權限，並會建立虛擬網路介面卡。第一次啟用後要重新測試 DNS、區域網路存取與休眠喚醒，不要只看瀏覽器是否能開啟網頁。若開啟後全域斷網，先關閉 TUN，確認系統代理仍可運作，再檢查驅動程式、路由和 DNS，而不是繼續疊加更多開關。

Windows 常見的殘留代理與權限問題

最常見的退出後斷網情況，是系統代理仍指向已關閉的本機連接埠。處理方式是重新開啟 v2rayN，執行清除系統代理後再正常退出；也可以進入 Windows 的網路與 Internet 設定，檢查手動代理和設定指令碼是否殘留。不要一開始就重設整個網路堆疊，因為那會同時影響其他網路軟體和已儲存的設定。先確認代理位址是否指向回送位址、對應連接埠是否仍在監聽，通常就能定位問題。

若客戶端無法寫入設定、更新後設定消失，或記錄提示存取遭拒，重點檢查安裝目錄與安全軟體的受控資料夾策略。日常執行不建議長期強制使用管理員模式；需要管理員權限的功能應在操作時依提示授權。若只有 TUN 失敗而系統代理正常，表示訂閱、節點和核心基本可用，排查範圍應縮小到虛擬介面卡、路由衝突和權限。若系統代理也失敗，則回頭檢查節點、時間、訂閱欄位與核心記錄。

命令列程式可以先檢查是否繼承了舊的代理環境變數。以下 PowerShell 命令只讀取目前環境，不會修改設定。若輸出已失效的位址，應在對應終端設定或系統環境變數中清除，而不是反覆更換客戶端節點。

Get-ChildItem Env:HTTP_PROXY
Get-ChildItem Env:HTTPS_PROXY
Get-ChildItem Env:ALL_PROXY

Windows 休眠或切換網路後，虛擬介面卡和舊路由可能沒有立即更新。先中斷客戶端連線，等待網路圖示恢復，再重新啟動服務。如果頻繁發生，可優先使用系統代理完成日常瀏覽，只在確實需要接管更多程式時開啟 TUN。更詳細的第一次操作順序可參考入門指南，本章則用於選擇版本和定位 Windows 特有問題。

03 / MACOS

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

先確認 Apple Silicon 或 Intel

macOS 使用 v2rayN 時，第一步不是查看系統名稱，而是確認處理器架構。開啟系統資訊或「關於這台 Mac」，看到 Apple 系列晶片時選擇 Apple Silicon 對應的 arm64 安裝包；看到 Intel 處理器時選擇 x64 安裝包。架構選錯時，系統可能拒絕開啟，也可能需要額外轉換層，既增加變數又不利於排錯。下載頁已按晶片分開入口，確認後再安裝即可。

安裝通常是開啟 dmg，再將應用程式移入 Applications。第一次執行遇到系統安全性確認時，應透過系統設定中的隱私權與安全性頁面查看遭攔截原因，確認來源與目前下載操作一致後再允許開啟。不要為了單一應用程式長期降低整台裝置的安全策略。v2rayN 需要修改系統代理或建立網路延伸功能時，系統會另外要求權限；這些權限與一般檔案存取不同，應在實際啟用功能時依提示授予。

匯入訂閱與選擇節點

進入訂閱設定，建立新群組，貼上訂閱連結並儲存，然後執行更新。macOS 版介面配置可能與 Windows 版不同，但仍圍繞訂閱群組、伺服器清單、目前使用中的節點和代理模式四個部分。更新後若出現節點清單，先選定一個節點，再啟動服務。不要把「訂閱已更新」理解為「流量已接管」，訂閱更新只完成設定同步，系統是否透過客戶端連線仍取決於代理開關。

若從聊天工具複製連結，尤其要注意換行和文字替換。可以先貼到純文字編輯器，確認連結只有一行後，再放入客戶端。訂閱網址含有查詢參數時，尾端部分同樣不能截斷。更新時出現憑證或交握錯誤，應先確認系統時間、目前網路和訂閱網址本身；如果只有某個節點失敗而其他節點正常，則排查該節點欄位，不要刪除整個訂閱群組。

系統代理與應用程式代理的界線

啟用系統代理後，Safari、遵循系統網路設定的瀏覽器以及大量桌面軟體會使用 v2rayN 提供的本機代理。終端機命令和部分開發工具不一定會自動讀取系統代理，這取決於工具本身。不要因為終端機請求沒有變化就判斷整個客戶端失效，應同時使用遵循系統代理的瀏覽器驗證。如果某個命令列工具明確支援 HTTP 或 SOCKS 代理，可以在該工具自己的設定中填入客戶端顯示的本機位址和連接埠。

關閉客戶端前應先清除系統代理。若應用程式已退出但網頁全部無法開啟，進入系統設定的網路詳細資料，檢查 HTTP 代理、HTTPS 代理和自動代理設定是否仍啟用。殘留位址常常指向 127.0.0.1 的某個連接埠，但此時本機已沒有程序監聽。關閉對應項目後網路就會恢復。這裡不需要刪除 Wi-Fi、忘記網路或清空 DNS，先處理最直接的代理殘留即可。

TUN、網路延伸功能與區域網路存取

macOS 上的 TUN 會涉及網路延伸功能或虛擬介面權限。系統首次詢問時允許後，可能需要重新啟用功能才能生效。開啟前先確認系統代理模式連線穩定，因為 TUN 失敗時最有價值的對照組就是「同一節點在系統代理下是否可用」。如果系統代理正常、TUN 開啟後斷網，優先檢查 DNS 接管、預設路由和其他網路延伸功能衝突。多個接管全域流量的軟體同時運作時，路由優先順序和 DNS 設定可能互相覆蓋。

需要存取印表機、檔案共享或路由器管理頁面時，應讓區域網路位址保持直連。常見私有位址段包括 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16，回送位址和本機連結位址也不應交給遠端節點。使用預設分流設定時通常已包含這些規則，但自訂路由後要重新核對。若只有區域網路裝置無法連線，先不要修改節點協定，而應檢查路由規則是否將私有位址錯誤送入代理出站。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

切換 Wi-Fi、熱點和有線網路後，舊的系統代理仍可能保留，但本機連接埠會隨著客戶端重新啟動而恢復。正確順序是先中斷連線，完成網路切換，確認基本網路可用後再重新連線。若切換網路後訂閱能更新但網頁無法開啟，應查看目前使用中的節點、代理模式和 DNS；若訂閱也無法更新，則先排除新網路本身的認證頁面與連線能力。

macOS 平台的重點不是增加特殊設定，而是遵守系統權限和網路延伸功能的界線。系統代理能滿足需求時就保持簡單；需要接管更多應用程式時再開啟 TUN；需要區域網路服務時明確保留私有位址直連。每次網路延伸功能變更後都重新驗證瀏覽器、終端機和區域網路三個方向，比只測試一個網頁更快發現邊界問題。

04 / LINUX

Linux：軟體包、桌面代理與 TUN 權限

deb、rpm 與架構選擇

Linux 桌面端使用 v2rayN。下載前先確認發行版的軟體包體系和 CPU 架構。Debian、Ubuntu、Linux Mint 等通常選 deb；Fedora、RHEL 系及使用 rpm 套件管理的發行版選擇 rpm。x86_64 裝置使用 x64 包，arm64 裝置使用對應的 arm64 包。可以在終端機執行 uname -m 查看架構：常見輸出 x86_64 對應 x64，aarch64 對應 arm64。

uname -m
cat /etc/os-release

安裝本機 deb 包時，優先讓 apt 處理相依性；安裝 rpm 包時使用目前發行版的套件管理命令。以下命令中的檔名應替換為實際下載到目前目錄的檔名，不要照抄一個不存在的名稱。圖形化軟體中心也能完成安裝，但出現相依性錯誤時，終端機輸出更方便定位。

sudo apt install ./v2rayN-linux-x64.deb

sudo dnf install ./v2rayN-linux-x64.rpm

如果安裝程式回報架構不相符，應重新選擇安裝包，而不是強制略過檢查。若提示缺少桌面執行庫，先確認發行版版本仍在支援週期內，並透過系統軟體來源安裝相依套件。不要從不相關來源混裝函式庫檔案。應用程式能啟動後，先檢查視窗、系統匣圖示和設定目錄是否屬於目前使用者；長期使用 root 啟動圖形客戶端會造成設定檔擁有者混亂，之後一般使用者可能無法儲存設定。

匯入訂閱並理解桌面環境差異

v2rayN 的訂閱流程與其他桌面平台一致：建立新群組、貼上連結、儲存、更新、選擇目前使用中的節點。差異主要來自 Linux 桌面環境。GNOME、KDE 及其他桌面對於系統代理的設定入口和應用程式繼承方式並不完全相同。瀏覽器通常能讀取桌面代理，終端程式、容器和背景服務則往往不會。首次驗證時應先使用桌面瀏覽器，確認核心與節點正常後，再單獨設定命令列工具。

某些精簡桌面環境沒有統一的系統代理介面，此時 v2rayN 的「設定系統代理」可能無法涵蓋所有應用程式。可以查看客戶端目前監聽的 HTTP 與 SOCKS 連接埠，將位址填入目標應用程式自己的代理設定。只在目前終端機暫時測試時，也可以設定環境變數；測試結束後關閉終端機即可回復，避免將失效連接埠長期寫入 shell 設定。

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

範例連接埠用於說明格式，實際值必須以客戶端介面顯示為準。如果 v2rayN 修改過本機連接埠，環境變數也要同步。大小寫不同的變數可能被不同工具分別讀取，排錯時可執行 env | grep -i proxy 查看目前工作階段。命令列可用而瀏覽器無法使用，通常是桌面代理未設定；瀏覽器可用而命令列無法使用，通常是工具沒有繼承系統代理，這兩種情況不應混為一談。

TUN 所需的權限與路由檢查

Linux 上開啟 TUN 需要存取 /dev/net/tun、建立虛擬介面並修改路由。v2rayN 可能透過權限提升機制完成這些操作。若介面提示 TUN 啟動失敗，先確認核心模組和裝置節點存在，再查看記錄中的權限錯誤。不要直接讓整個應用程式永久以 root 身份執行；正確方向是讓需要網路管理權限的元件取得有限授權，同時讓使用者設定繼續由一般帳戶擁有。

ls -l /dev/net/tun
ip address
ip route

開啟 TUN 前後分別記錄預設路由和 DNS 狀態。若開啟後完全斷網，關閉 TUN 後檢查預設路由是否恢復；若只有網域無法開啟但直接存取已知位址有回應，問題集中在 DNS；若區域網路裝置無法存取，則檢查私有位址是否被錯誤送入 TUN。NetworkManager、systemd-resolved 與桌面環境的 DNS 管理可能同時存在，設定時應確認最終生效的層級，不要在三個位置反覆寫入不同伺服器。

休眠、系統匣與背景程序

部分桌面環境關閉視窗只是隱藏到系統匣，另一些環境沒有系統匣擴充功能，關閉視窗會結束程式。第一次使用時應確認 v2rayN 的退出行為，避免誤以為客戶端已關閉但系統代理仍然保留。可以用程序清單和連接埠監聽狀態判斷核心是否仍在執行。系統代理指向本機連接埠但程序已結束時，瀏覽器會表現為所有頁面連線失敗。

休眠恢復後，網路介面名稱、預設路由和 DNS 可能重新建立。系統代理模式通常只需重新連線；TUN 模式則可能需要關閉後重新開啟。若恢復後記錄仍顯示舊介面，先讓系統網路穩定，再重新啟動客戶端。容器和虛擬機器擁有獨立的網路命名空間，主機的系統代理不會自動涵蓋其中流量。需要讓容器使用代理時，應明確設定容器的代理位址，並確認它能存取主機監聽的連接埠。

Linux 排錯最重要的是區分「客戶端核心是否運作」「桌面應用程式是否讀取代理」「系統路由是否由 TUN 接管」三個層次。不要用一個命令的結果代替全部判斷。瀏覽器、帶有代理環境變數的終端機請求和 ip route 分別對應三個層次。只要逐層驗證，就能避免將桌面環境差異誤判為節點故障。

05 / ANDROID

Android：v2rayNG、v2flyNG 與連線授權

客戶端與安裝包選擇

Android 首選 v2rayNG，它使用 Xray 核心，適合大多數訂閱和常見協定設定。v2flyNG 使用 V2Fly 核心，可作為不同核心家族的備選。兩款客戶端都提供 arm64 與通用安裝包。2015 年後的主流手機通常可以先選 arm64，裝置架構不明、安裝時提示不相容或需要涵蓋更廣泛裝置時，再選通用包。不要同時讓兩款客戶端保持連線，因為系統同一時間只會將網路交給這類連線中的其中一個。

開啟安裝包時，系統可能要求允許目前的瀏覽器或檔案管理器安裝應用程式。這項權限只應授予實際執行安裝的應用程式，安裝結束後可以在系統設定中關閉。若系統提示無法安裝，先檢查是否下載完整、架構是否相符，以及裝置上是否存在簽章來源不同的同名應用程式。直接覆蓋失敗時，應先備份客戶端內的重要設定，再決定是否解除安裝舊應用程式，避免訂閱和手動節點一併遺失。

匯入訂閱、剪貼簿連結與掃描 QR Code

開啟 v2rayNG 後，可以進入訂閱設定新增訂閱網址，儲存後返回主介面執行更新訂閱。更新成功後會產生節點清單，點選其中一項使其成為目前設定。單條分享連結則使用「從剪貼簿匯入」一類的入口；QR Code 適合匯入單條節點或客戶端支援辨識的設定內容。訂閱 QR Code 與單節點 QR Code 外觀相同，最後應根據掃描結果進入訂閱管理還是節點清單來判斷。

如果掃描 QR Code 沒有反應，先確認相機權限、QR Code 是否完整顯示以及螢幕反光情況。沒有必要將敏感 QR Code 上傳到線上辨識工具。複製連結時同樣要避免文字截斷。訂閱更新後節點為空，應檢查群組是否啟用、訂閱內容格式是否受目前核心支援，以及連結是否回傳登入頁面或錯誤頁面。詳細的訂閱入口差異可以參閱訂閱連結匯入步驟。

第一次連線與分應用程式代理

選取節點後點選連線按鈕，系統會跳出網路連線授權。允許後，狀態列出現連線標記，客戶端記錄開始記錄連線過程。第一次測試先保持預設路由，不要開啟複雜的分應用程式規則。開啟瀏覽器驗證連線，再檢查其他應用程式。Android 不需要像桌面系統那樣額外切換「系統代理」，授權連線後，系統會將符合規則的應用程式流量交給客戶端。

分應用程式代理用於決定哪些應用程式進入客戶端。通常有兩種思路：只代理選取的應用程式，或繞過選取的應用程式。設定前先看清模式名稱，避免邏輯反轉。系統元件、瀏覽器核心和應用程式主程式可能是不同套件，某個應用程式仍不符合預期時，要確認它是否呼叫了外部瀏覽器或系統下載器。第一次設定不建議啟用分應用程式代理；全域連線驗證成功後，再逐一加入或排除應用程式，問題會更容易定位。

背景限制、電池最佳化與網路切換

連線一段時間後自動中斷，常見原因是系統對背景應用程式的電池限制。可在應用程式資訊中允許 v2rayNG 或 v2flyNG 在背景執行，並依裝置系統提供的選項關閉針對該客戶端的嚴格電池最佳化。只調整目前的客戶端，不需要將所有應用程式都設為不受限制。若工作管理工具會強制結束背景程序，也要將客戶端從對應清理規則中排除。

Wi-Fi 與行動網路切換時，現有連線可能短暫失效。先等待系統網路取得位址，再觀察客戶端是否自動恢復；沒有恢復時手動中斷並重新連線。若 Wi-Fi 需要網頁認證，應先中斷客戶端完成認證，再重新連線。只有某個 Wi-Fi 失敗而行動網路正常，表示客戶端設定大致可用，應排查該網路的 DNS、認證頁面或 IPv6 路徑，而不是重新安裝應用程式。

DNS、IPv6 與區域網路存取

Android 出現「應用程式顯示已連線，但網域無法開啟」時，應優先檢查 DNS。客戶端內建 DNS、系統私人 DNS 和節點遠端解析可能共同影響結果。第一次排錯可以暫時維持客戶端預設 DNS，並確認系統私人 DNS 沒有指向目前網路無法連線的伺服器。若只有個別網域解析異常，再設定分流 DNS，而不是直接切換所有查詢路徑。

IPv6 可用性取決於目前的行動網路、Wi-Fi 和節點設定。如果記錄顯示請求選用了 IPv6 位址但連線逾時，可以先在客戶端 DNS 策略中優先返回與目前鏈路相符的位址族，或檢查節點是否支援對應出口。不要把所有逾時都歸因於 IPv6；先看記錄中的目標位址和錯誤階段。區域網路裝置無法存取時，檢查是否允許繞過私有位址，並確認分應用程式規則沒有將檔案管理器或投放元件送到不適合的出站。

v2rayNG 與 v2flyNG 的選單名稱會因介面更新而變化，但操作主線穩定：匯入設定、選擇節點、允許系統連線、觀察記錄。只要先用預設設定完成這條主線，再處理分應用程式、DNS 和背景限制，絕大多數 Android 問題都能拆成單一變數。更換兩款客戶端時也應使用同一條節點作為對照，才能判斷差異來自核心相容性還是節點本身。

06 / SUBSCRIPTION

訂閱與節點管理：更新、覆蓋與相容性

訂閱更新實際做了什麼

訂閱更新不是測速，也不是重新安裝核心。客戶端向訂閱網址發出請求，讀取回傳內容、解析節點欄位，再更新對應群組中的伺服器清單。節點名稱、位址、連接埠、使用者識別資訊、傳輸方式和 TLS 參數通常都來自訂閱。更新完成後，目前使用中的節點可能繼續保留，也可能因原項目被移除而需要重新選擇。遇到「更新成功但連線沒有變化」時，先查看目前使用中的節點是否仍是舊項目。

訂閱群組便於隔離不同來源的設定。多個訂閱不要全部塞進一個難以辨認的名稱，建議按用途建立群組。更新某個群組前，可以先記住目前使用中的伺服器。若新清單異常，切回其他已驗證的群組即可繼續排查。客戶端中的訂閱連結應視為敏感資訊，因為連結本身可能包含存取識別資訊；截圖時不要讓網址列、QR Code 或完整節點欄位出現在畫面中。

自動更新與手動更新的界線

手動更新適合首次匯入、設定變更後立即同步以及排錯。自動更新適合長期維護，但不應設定得過於頻繁。訂閱內容沒有變化時，反覆請求不會改善節點連線。自動更新失敗也不一定影響已儲存的舊節點，客戶端通常仍可使用本機清單。此時要分別判斷「訂閱網址無法存取」和「現有節點無法連線」，兩者不是同一種故障。

若訂閱回傳空內容、網頁文字或認證頁面，客戶端可能提示格式錯誤。可以在不公開連結的前提下，用本機瀏覽器檢查請求結果是否符合預期。瀏覽器能開啟但客戶端失敗時，再查看系統代理是否造成訂閱更新繞路、憑證是否被本地網路替換，以及客戶端是否支援回傳格式。更新訂閱時使用代理還是直連，應根據訂閱網址的可達性決定；不要把固定模式當成所有網路都適用的答案。

手動修改為什麼會被覆蓋

訂閱節點由遠端清單產生，下次更新通常會重新寫入欄位。手動修改節點名稱、連接埠或傳輸參數後，更新可能覆蓋修改，這是訂閱管理的正常行為。需要保留自訂項目時，可以將節點複製為獨立伺服器，不讓它歸屬於自動更新群組；或者在訂閱提供的管理介面完成修改，再重新同步。直接修改產生結果適合暫時測試，不適合作為長期維護方式。

路由和 DNS 通常屬於客戶端層級設定，不一定會隨節點更新而被覆蓋。應將「伺服器欄位」和「本機策略」分開管理：伺服器欄位決定如何連線到遠端，路由決定流量走哪個出站，DNS 決定網域如何解析。節點更新後所有網站行為突然改變時，先查看使用中的節點和伺服器欄位；只有部分網域的流向不符時，再查看路由與 DNS。

協定欄位與核心相容性

常見訂閱可能包含 VMess、VLESS、Trojan 等節點。協定名稱只是第一層，真正決定能否連線的還有傳輸方式、TLS、安全參數、伺服器名稱和路徑等欄位。不能因為客戶端辨識出節點名稱，就認為所有欄位都完整。記錄中的「未知欄位」「不支援的傳輸方式」或設定解析失敗，通常表示訂閱產生格式與目前核心能力不相符。

Android 上可以用 v2rayNG 與 v2flyNG 進行核心家族對照，但對照時應保持同一節點、同一網路以及盡量一致的路由設定。某條設定只在其中一個核心上運作，不代表另一個客戶端整體故障，可能是特定欄位的實作或支援範圍不同。桌面端 v2rayN 也要確認目前選用的核心與節點需求相符。不要憑節點名稱猜測協定，開啟設定詳情查看實際欄位更可靠。

訂閱異常的分層檢查

第一層檢查連結：是否完整、是否過期、是否混入空格。第二層檢查請求：目前網路能否存取、回傳的是否為訂閱正文。第三層檢查解析：客戶端是否辨識格式、記錄是否回報欄位錯誤。第四層檢查連線：節點能否完成網域解析、TCP 建立連線和 TLS 交握。依層處理比不斷刪除再新增訂閱更快，也能保留可用設定。

如果訂閱裡幾十個節點同時失敗，應優先懷疑共同條件，例如裝置時間、DNS、網路、訂閱欄位整體變更或核心設定。只有一個節點失敗，則檢查該節點的位址、連接埠和傳輸參數。節點能連線但特定網站失敗，則進入路由和 DNS 層。這個判斷樹能避免把所有問題都歸結為「訂閱失效」。

訂閱管理的目標不是讓清單越長越好，而是讓設定來源、更新時間和目前使用中的節點都可追蹤。保持群組清晰，保留一個已驗證節點作為對照，修改進階參數前記錄原值。這樣即使訂閱內容發生變化，也能快速判斷是遠端清單、客戶端解析還是本地網路出了問題。

07 / PROXY AND TUN

系統代理、TUN、路由與 DNS 的關係

系統代理只接管願意讀取它的程式

系統代理本質上是將一個本機 HTTP 或 SOCKS 入口告訴作業系統和應用程式。瀏覽器、部分桌面軟體會讀取這項設定，再將請求交給 v2rayN。它不會強制攔截每一個封包，因此某些遊戲、命令列工具、背景服務和自行實作網路堆疊的程式可能繞過。系統代理的優點是權限要求低、路徑清楚且容易關閉，最適合作為第一次連線和日常瀏覽的預設方案。

客戶端本機通常會監聽回送位址，例如 127.0.0.1 上的 HTTP 與 SOCKS 連接埠。回送位址只允許本機存取，符合單機使用情境。若開啟允許區域網路連線，就要明確設定監聽範圍和防火牆規則，不要為了連線本機應用程式而將連接埠開放到所有網路介面卡。應用程式手動設定代理時，協定類型和連接埠必須對應；將 SOCKS 連接埠填入 HTTP 代理欄位，會產生看似連線遭拒或協定交握失敗的結果。

TUN 為什麼能接管更多應用程式

TUN 會建立虛擬網路介面，將系統路由指向該介面，再由客戶端判斷每個連線應走代理還是直連。應用程式不需要理解代理協定，因此覆蓋範圍比系統代理更廣。代價是需要更高權限，並且會與系統路由、DNS 和其他虛擬網路軟體互相作用。TUN 不是「更快模式」，也不會修復錯誤節點；它解決的是應用程式不讀取系統代理的問題。

啟用順序應為：先確認同一節點在系統代理下可用，記錄目前的 DNS 與區域網路狀態，關閉其他會接管預設路由的軟體，再開啟 TUN。驗證時至少測試一般網域、區域網路位址和一個原本會繞過系統代理的程式。若瀏覽器可用但區域網路失效，應檢查私有位址直連；若所有網域都失敗，查看 DNS；若只有某個程式失敗，查看它是否使用特殊協定或獨立網路環境。

路由規則依順序比對

路由規則決定流量交給哪個出站。通常先設定明確的私有位址直連，再設定需要代理的網域或位址，最後設定兜底行為。規則順序很重要：流量命中前面的規則後，後續規則通常不會再參與。一個過寬的網域規則放在頂部，可能讓後面的直連規則永遠沒有機會生效。排查分流時，應查看實際目標網域、解析後的 IP、命中的規則和最終出站標籤。

domainStrategy 決定路由階段如何使用網域與解析結果。AsIs 優先按原始網域比對，適合網域規則明確的設定；其他策略可能在需要時解析位址，再參與 IP 規則。不了解其行為時，不要同時修改路由策略和 DNS。先維持預設值進行驗證，再根據「網域規則未命中」或「需要按目標 IP 分流」的具體需求調整。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      }
    ]
  }
}

DNS 洩漏、遠端解析與分流 DNS

DNS 負責將網域轉換成位址，它與連線流量可以走不同路徑。如果網域在本地解析、連線卻走代理，解析結果可能受到目前網路影響；如果所有查詢都送到遠端，又可能讓本地域名和區域網路服務無法正確解析。合理做法是根據網域類別決定解析路徑，並讓路由與 DNS 的判斷保持一致。相關實作可查看DNS 洩漏檢測與設定步驟。

出現 DNS 問題時，先區分解析失敗與連線失敗。記錄若明確顯示找不到網域或 DNS 查詢逾時，才進入 DNS 層；已解析出位址但 TCP 連線逾時，則要查看節點、路由或目標網路。瀏覽器還可能啟用自己的安全 DNS，繞過系統設定。進行對照測試時可暫時讓瀏覽器遵循系統 DNS，避免客戶端、系統和瀏覽器三套解析同時變化。

所謂防洩漏設定，不是簡單填入一個伺服器位址，而是確保應用程式查詢、系統查詢和 TUN 接管之間沒有意外旁路。驗證時應在系統代理與 TUN 兩種模式下分別觀察，因為系統代理通常不會強制接管全部系統 DNS，而 TUN 可以更集中地處理查詢。修改後還要清除舊快取或等待快取過期，否則會將歷史結果誤當成新設定的效果。

建議的漸進式設定順序

第一階段只使用預設路由和系統代理，驗證訂閱與節點。第二階段加入私有位址直連和必要網域規則，確認每條規則的命中情況。第三階段設定 DNS，讓解析路徑與分流一致。第四階段才開啟 TUN，測試更多應用程式、區域網路和休眠恢復。每完成一個階段都保留可回復設定。這個順序看起來比一次開啟所有功能慢，實際上能省下大量沒有方向的試錯時間。

系統代理、TUN、路由和 DNS 是四個彼此連結但職責不同的層次。系統代理決定應用程式是否將請求交給客戶端；TUN 決定系統封包是否進入虛擬介面；路由決定進入客戶端後的出站；DNS 決定網域如何取得位址。按職責定位問題，比記住選單位置更持久，也適用於不同平台和日後的介面變更。

08 / DIAGNOSIS

常見設定問題：依記錄階段逐層排查

先判斷故障發生在哪一層

完整連線鏈路可以拆成六層：本機應用程式是否進入客戶端、網域是否解析、客戶端是否連線到節點位址、傳輸層是否建立、TLS 等安全層是否完成，以及目標請求是否按路由出站。記錄中的錯誤位置比「網頁無法開啟」更有資訊量。排錯時記錄時間點，重新發起一次請求，再查看該時間附近的記錄，避免被早先錯誤和背景重試淹沒。

如果記錄完全沒有新的連線，表示應用程式可能繞過系統代理、分應用程式規則排除了它，或 TUN 沒有接管對應路由。記錄出現 DNS 逾時，檢查解析伺服器和查詢路徑。節點位址連線逾時，檢查目前網路、位址可達性和連接埠。TLS 交握失敗時，檢查系統時間、伺服器名稱與安全參數。連線建立後目標回傳錯誤，則繼續查看路由和目標服務，不要立刻重新安裝客戶端。

訂閱能更新，但所有節點都無法連線

這表示客戶端至少能存取訂閱網址，但不能證明節點鏈路正常。先確認裝置時間與時區自動同步，然後選擇一個節點，清除舊記錄並重新連線。若所有節點都回報相同的 DNS 錯誤，檢查系統和客戶端 DNS；若都在連線節點位址時逾時，檢查目前網路和路由；若都在設定解析階段失敗，則更應關注訂閱格式或核心相容性。

不要連續切換幾十個節點，只看介面顏色。每次切換後保留一段完整記錄，比較錯誤階段是否一致。相同階段表示存在共同條件，錯誤階段不同才可能是節點個別差異。還可以用系統代理模式與 TUN 模式作對照：系統代理正常而 TUN 失敗，範圍在權限、路由和 DNS 接管；兩者都失敗，範圍更接近節點、訂閱或核心。

顯示已連線，但網頁無法開啟

「已連線」通常只表示客戶端程序或系統連線狀態已建立，不代表每個目標請求都成功。先檢查瀏覽器是否讀取系統代理，或行動端的目標應用程式是否包含在分應用程式規則中。接著查看記錄中是否有對應的網域請求。沒有請求就處理接管層；有 DNS 查詢但沒有結果就處理 DNS；已取得位址卻連線失敗，再查看路由和節點。

桌面端還要檢查系統代理位址是否對應目前 v2rayN 的本機連接埠。升級、遷移設定或手動調整後，系統可能仍指向舊連接埠。瀏覽器本身的代理擴充功能也可能覆蓋系統設定，排錯時應暫時只保留一條代理鏈路。若只有一個瀏覽器異常，用另一個遵循系統代理的應用程式測試，可以快速判斷問題出在瀏覽器還是客戶端。

只有部分網站或應用程式失敗

部分失敗通常與分流、DNS、IPv4 和 IPv6 選擇，以及應用程式獨立網路堆疊有關。先查看失敗目標是否命中預期的路由規則，再查看 DNS 回傳的位址。也要確認網域規則使用的比對形式：完整網域、子網域和關鍵字的匹配範圍不同。規則過寬會影響無關目標，規則過窄則只會匹配單一主機名稱。調整後清除相關快取，再重新測試。

應用程式失敗而瀏覽器正常時，檢查它是否支援系統代理、是否使用 UDP，以及是否執行在容器或虛擬機器中。系統代理主要涵蓋 HTTP 類請求，TUN 才能接管更多通用流量，但也要確認客戶端設定如何處理 UDP。Android 分應用程式代理應檢查套件選擇；Linux 容器應檢查網路命名空間；Windows 背景服務可能在不同帳戶內容下執行。這些平台差異都屬於接管層，而不是訂閱層。

TUN 開啟後全域斷網

第一步關閉 TUN，確認基本網路和系統代理恢復。第二步查看虛擬介面是否建立成功、預設路由是否指向預期位置。第三步檢查 DNS 是否被改到無法連線的位址。第四步排除其他虛擬網路程式的路由衝突。不要在全域斷網狀態下繼續修改節點協定和訂閱欄位，因為這些設定與虛擬介面未建立沒有直接關係。

如果關閉 TUN 後仍然斷網，檢查殘留的系統代理、預設路由和 DNS。Windows 查看手動代理，macOS 查看網路代理項目，Linux 查看環境變數、桌面代理和 ip route。恢復基本網路後再重新啟用。頻繁切換網路或休眠後出現問題時，可以先重新建立客戶端連線，而不是重新啟動整台裝置。只有路由持續無法恢復時，才考慮更深層的系統網路處理。

如何閱讀記錄，哪些內容適合提供

有效記錄包含時間、模組、錯誤類型和上下文。常見關鍵字可以分為解析錯誤、連線逾時、連線遭拒、交握失敗、設定欄位錯誤和權限錯誤。排錯時複製錯誤前後數行，說明平台、客戶端、目前使用系統代理還是 TUN，以及問題能否穩定重現。不要只截取一行「failed」，因為同一個單字在不同階段代表完全不同的原因。

提供記錄前應遮蓋訂閱連結、節點位址、使用者識別資訊、驗證欄位和本機個人路徑。節點名稱如果包含帳戶資訊也要處理。保留協定類型、傳輸方式、錯誤模組和時間順序通常已經足夠。更多常見問答可進入FAQ 頁面，生態與客戶端的關係則可查看Project V、V2Fly 與 Xray 的關係。

一套可重複的恢復流程

當設定已經改得難以追蹤時，不要繼續疊加參數。先匯出或記錄現有設定，然後關閉 TUN、清除系統代理、恢復預設路由與 DNS 策略。保留一個訂閱群組，更新後選擇一個節點，用系統代理完成最小測試。成功後依照「路由、DNS、TUN、分應用程式」的順序逐項恢復，每增加一項就驗證記錄和目標行為。

如果最小設定仍然失敗，換一個已知正常的網路作對照，可以區分裝置設定和目前網路。再用同一訂閱中的另一個節點作對照，可以區分節點個別問題和共同設定。Android 還可以在 v2rayNG 與 v2flyNG 之間進行核心家族對照，但應保持網路和節點一致。對照實驗一次只更換一個變數，結果才有解釋價值。

最終目標不是消除記錄中的所有提示，而是確認請求依預期進入客戶端、正確解析、連線成功並命中正確出站。部分重試和非關鍵提示可能不會影響實際使用。先解決導致請求中斷的第一個錯誤，再處理後續衍生錯誤。掌握這個順序後，即使介面名稱改變，排錯方法也不會失效。