一、閱讀方式與設定全貌
客戶端、核心與訂閱各自負責什麼
要完成一套可用設定,首先要區分客戶端介面、代理核心與訂閱內容這三個層次。v2rayN、v2rayNG 與 v2flyNG 負責顯示節點、儲存偏好設定及呼叫系統功能的圖形客戶端;Xray 或 V2Fly 則是處理協定、路由與連線的核心;訂閱是服務提供者提供的設定集合,通常包含伺服器位址、連接埠、使用者識別碼、傳輸方式、TLS 參數與名稱等資訊。客戶端匯入訂閱後,不會立即替所有應用程式接管網路,而是先將節點交給核心,再由系統代理或 TUN 決定哪些應用程式流量進入本機代理入口。
因此,「客戶端顯示已啟動」與「瀏覽器已經使用代理」是兩回事。核心正常運作,只能表示本機監聽連接埠已建立;瀏覽器是否經過該連接埠,還取決於系統代理設定、瀏覽器本身的代理策略、路由規則,以及 DNS 請求的處理方式。排錯時應沿著資料流逐段確認:訂閱內容能否解析、所選節點能否建立連線、本機入口是否正在監聽、應用程式是否將請求交給入口、路由是否選出正確的出站,以及 DNS 是否回傳可用結果。把這些環節混在一起反覆重裝,往往無法找出真正原因。
四大平台的建議客戶端範圍
| 平台 | 客戶端 | 主要接管方式 | 安裝時重點 |
|---|---|---|---|
| Windows | v2rayN | 系統代理、TUN | 權限、防火牆與系統代理狀態 |
| macOS | v2rayN | 系統代理、TUN | 晶片架構、應用程式權限與網路授權 |
| Linux | v2rayN | 桌面代理、環境變數、TUN | 發行版套件格式、桌面環境與權限提升 |
| Android | v2rayNG、v2flyNG | 系統 VPN 介面 | 背景限制、省電策略與應用程式分流 |
桌面平台統一優先使用 v2rayN,方便在相近的介面結構下管理訂閱、路由與記錄。Android 首選 v2rayNG;需要採用 V2Fly 核心路線時,可選擇 v2flyNG。兩款 Android 客戶端的基本操作相近,但不應假設設定資料庫與核心能力完全相容。更換客戶端時,應重新匯入原始訂閱,而不是複製另一款客戶端的內部資料目錄。
完整設定的標準順序
- 確認平台與架構。先判斷裝置使用的作業系統、處理器架構與發行版套件格式,再前往下載中心選擇對應安裝檔。
- 完成客戶端安裝。首次啟動時處理系統權限、防火牆或網路介面授權,確認介面能正常開啟。
- 匯入並更新訂閱。建立訂閱分組,輸入完整網址,主動更新一次並檢查節點清單是否出現。
- 選擇節點與模式。先使用基本系統代理完成驗證,再依應用程式涵蓋範圍決定是否啟用 TUN。
- 驗證請求路徑。檢查客戶端記錄、瀏覽器存取情況與系統代理狀態,不要以單一延遲結果取代實際連線驗證。
- 最後調整路由。基本連線建立後,再加入直連、代理或阻斷規則,每次只變更一類條件。
系統代理適合瀏覽器與遵循系統網路設定的桌面應用程式,設定簡單且影響範圍明確;TUN 透過虛擬網路介面接管更廣泛的流量,適合不讀取系統代理、只傳送 UDP 或自行建立網路堆疊的程式,但同時也會引入管理員權限、路由表、DNS 接管及與其他網路工具衝突等變數。合理做法不是預設開啟所有功能,而是從最少設定開始,確認主要連線路徑成立後再擴大涵蓋範圍。這也是本頁各平台章節都採用「安裝、訂閱、系統代理、TUN、平台問題」順序的原因。
二、安裝前準備:平台、架構、訂閱與權限
判斷系統與處理器架構
下載前應先確認作業系統版本、處理器架構與安裝套件類型。Windows 常見桌面裝置使用 x64;macOS 需區分 Apple Silicon 與 Intel;Linux 除了 x64、arm64 外,還要確認發行版採用 deb 或 rpm 套件管理體系;Android 近年的主流裝置通常使用 arm64,只有無法確認架構或安裝失敗時才考慮通用套件。架構選錯通常會表現為安裝程式無法啟動、系統提示套件不相容,或應用程式安裝後立即退出。這與訂閱、節點及網路狀態無關,不應透過修改代理參數來解決。
Windows 可在「設定 → 系統 → 系統資訊」查看系統類型。macOS 可開啟「關於這台 Mac」,晶片欄出現 Apple 系列名稱時選擇 Apple Silicon,顯示 Intel 處理器時選擇 Intel。Linux 可在終端機執行 uname -m,輸出 x86_64 對應 x64,輸出 aarch64 或 arm64 對應 arm64。Android 架構通常不必借助額外工具判斷:優先安裝 arm64 套件,系統明確拒絕後再使用通用套件,不要在來源不明的檢測頁面上傳裝置資訊。
uname -m
# 查看 Debian、Ubuntu 及其衍生發行版的套件架構
dpkg --print-architecture
# 查看 Fedora、Rocky Linux 等發行版的機器架構
rpm --eval '%{_arch}'
準備有效訂閱與基本資訊
訂閱網址本質上是客戶端取得設定集合的入口,必須保持完整。複製時常見的問題包括遺漏結尾參數、混入換行、把網頁顯示文字而非實際網址複製到剪貼簿,或訂閱已由服務端停用。建議先記錄訂閱名稱、更新網址與用途,但不要在截圖、記錄或公開求助內容中暴露完整網址,因為其中可能包含用於識別帳戶的權杖。客戶端內應為不同來源建立獨立分組,避免多個訂閱覆蓋同一分組後,無法判斷節點來源。
如果服務提供者提供多種訂閱格式,優先選擇明確標示適用於 V2Ray、Xray 或對應客戶端的格式。一般網頁網址、控制台登入網址與訂閱網址不是同一種內容。成功匯入的判斷標準也不是「沒有跳出錯誤」,而是訂閱分組下出現可辨識的設定項目,而且手動更新時記錄顯示已完成取得與解析。如果清單為空,應先檢查訂閱回應與格式,不要立即切換 TUN、DNS 或路由模式。
權限、時間與網路環境
客戶端的一般代理功能通常只需要使用者權限,TUN 則可能需要建立虛擬網路介面、寫入路由表或修改 DNS,因此會觸發管理員授權。授權應在系統原生提示中完成。若裝置受組織政策管理,相關權限可能受到限制,此時應先確認裝置管理規則,而不是反覆啟動客戶端。Windows 防火牆可能在首次執行核心時詢問網路存取範圍;macOS 可能要求允許網路設定;Linux 可能透過 polkit 或終端機提升權限;Android 首次連線會出現系統 VPN 授權對話框。拒絕授權後,介面按鈕可能仍可操作,但流量接管不會完整建立。
裝置時間也會影響 TLS 交握與具有有效期限的驗證。應啟用系統自動校時,並確認時區正確。錯誤的日期、時間或時區可能導致憑證尚未生效、憑證已過期或驗證時間窗不相符。另一項準備工作是暫時減少網路變數:首次設定時關閉其他代理、網路過濾器與同類虛擬網卡,只保留目前客戶端;優先在穩定的家庭或行動網路上驗證。公共網路若要求先開啟驗證頁面,應在啟用代理前完成驗證,否則所有連線都可能被重新導向登入頁面。
建立可復原的設定習慣
安裝前不需要搬移來源不明的整套設定。更穩妥的方法是保存訂閱來源說明、路由規則意圖與少量必要偏好,然後在新客戶端中重新建立設定。若從舊版客戶端更新,應先退出正在執行的核心,再依照目前安裝方式覆蓋或並行安裝。不要同時啟動兩個監聽相同本機連接埠的執行個體,否則後啟動的程序會回報位址已被使用。可攜式目錄也不應放在需要頻繁授權寫入的位置,記錄、資料庫與更新檔案都需要穩定的寫入權限。
準備完成後,前往下載中心依平台選擇客戶端。下載頁提供 Windows 桌面版與經典 WPF 版、macOS 兩種晶片架構、Linux 的 deb 與 rpm 套件,以及 Android 的 v2rayNG、v2flyNG 安裝入口。安裝檔的選擇只取決於平台與架構,不取決於訂閱協定;VMess、VLESS、Trojan 等協定屬於匯入後的核心設定,不需要為每種協定安裝不同客戶端。
三、Windows:v2rayN 安裝、訂閱與系統代理
選擇桌面版或經典 WPF 版
Windows 平台首選 v2rayN。下載中心提供桌面版與經典 WPF 版:桌面版採用新一代跨平台介面,適合希望與 macOS、Linux 保持相近使用體驗的使用者;WPF 版沿用經典 Windows 介面結構,適合已熟悉舊版選單位置與操作邏輯的使用者。兩者都用於管理訂閱、啟動核心與設定系統代理,但介面配置可能不同。不要同時執行兩個版本,它們可能爭用本機監聽連接埠、系統代理狀態或設定目錄。
安裝或解壓縮時,目錄應具備一般使用者的寫入權限,路徑也應盡量保持穩定。若採用安裝程式,依照系統精靈完成即可;若使用可獨立執行的套件,應先完整解壓縮再啟動,不要直接從壓縮檔預覽視窗執行。首次啟動若出現防火牆提示,應允許目前可信任網路範圍內的存取,以便本機應用程式連線至客戶端監聽連接埠。客戶端本身通常不需要對外提供區域網路服務,因此沒有明確需求時,不要開啟「允許來自區域網路的連線」。
匯入訂閱並選擇活動節點
進入訂閱分組管理,新增容易辨識的分組名稱,貼上完整訂閱網址並儲存。儲存動作只會建立來源記錄,接著還需要執行「更新目前訂閱」或「更新所有訂閱」。更新完成後回到伺服器清單,確認名稱、位址類型與傳輸資訊已經出現。節點數量不是可用性的證明,應選擇一個設定項目設為活動伺服器,再進行實際連線測試。若更新後清單仍為空,先查看記錄中的 HTTP 狀態、解析錯誤或格式提示,不要重複建立相同分組。
延遲測試只能作為初步篩選依據。部分伺服器不回應一般探測,但仍能建立實際代理連線;也可能出現探測值正常、實際交握失敗的情況。更可靠的方法是選取節點後執行實際連線延遲測試,再啟動系統代理並開啟一個先前未快取的網頁。測試期間觀察記錄是否出現連線成功、交握失敗、逾時或驗證遭拒。需要更細緻的選擇方法時,可閱讀v2rayN 首次連線教學。
系統代理模式的使用範圍
啟用系統代理後,v2rayN 會將 Windows 的代理設定指向本機監聽位址。遵循系統設定的瀏覽器與桌面程式會把 HTTP、HTTPS 請求交給客戶端,再由路由規則決定直連或代理。建議首次驗證使用「自動設定系統代理」或介面中相同功能的標準模式,維持預設本機連接埠,不要急著手動修改。切換節點時通常不必關閉系統代理,客戶端會在新的活動設定接管後處理後續連線;已建立的長連線可能繼續使用舊路徑,必要時重新開啟應用程式。
命令列程式不一定會讀取 Windows 圖形介面的系統代理。PowerShell、套件管理器與開發工具各有自己的代理規則,有些讀取環境變數,有些需要個別參數,有些則直接使用 WinHTTP。遇到「瀏覽器可用、終端機不可用」時,應視為應用程式代理機制的差異,而不是節點突然失效。可以先查看 WinHTTP 目前狀態,但不要把該結果等同於瀏覽器代理:
netsh winhttp show proxy
# 查看目前工作階段是否設定了代理環境變數
Get-ChildItem Env: | Where-Object Name -Match 'proxy'
若只希望目前終端機工作階段使用本機 SOCKS 或 HTTP 入口,應依照特定工具的文件設定暫時參數,結束工作階段後便會恢復。不了解影響範圍時,不要將代理環境變數寫入系統層級設定,因為客戶端未啟動時,這些程式仍會嘗試連線至已不存在的本機連接埠。瀏覽器與終端機分開排查的完整流程可參考系統代理沒有生效怎麼辦。
TUN、權限與 Windows 特有問題
TUN 模式適合不讀取系統代理、需要 UDP,或希望統一接管更多應用程式的情境。啟用前先退出其他同類客戶端,透過系統授權允許建立虛擬介面,再觀察 v2rayN 記錄是否完成介面初始化、路由寫入與 DNS 監聽。若啟用後立即斷網,先關閉 TUN 並恢復系統代理,確認基本連線仍然成立;接著檢查是否有其他虛擬網卡、企業網路軟體、遊戲加速工具或安全軟體同時修改路由表。一次只保留一個負責預設路由的工具。
Windows 休眠、網路切換或客戶端異常退出後,可能留下已啟用的系統代理狀態。典型現象是 v2rayN 已關閉,但瀏覽器仍嘗試存取本機監聽連接埠。重新啟動客戶端並正常關閉系統代理通常即可恢復;也可以進入 Windows 代理設定確認手動代理已關閉。問題尚未確認前,不要刪除所有網卡或重設整套網路協定,這會同時影響無線網路、虛擬化環境與企業設定。記錄提示連接埠被使用時,應先退出重複執行個體,再使用系統工具確認監聽程序:
netstat -ano | findstr LISTENING
# 查看系統 DNS 快取,排查前可先記錄目前狀態
ipconfig /displaydns
四、macOS:晶片架構、網路權限與代理接管
依晶片選擇 v2rayN 安裝套件
在 macOS 使用 v2rayN 時,第一步是選擇正確架構。Apple Silicon 裝置使用 arm64 安裝套件,Intel 裝置使用 x64 安裝套件。系統「關於這台 Mac」中的晶片或處理器資訊是判斷依據。架構不相符可能導致應用程式無法開啟,或必須透過相容轉換層才能執行,不應把這類啟動問題誤判為訂閱故障。安裝時將應用程式放入一般應用程式目錄,避免長期從下載資料夾或磁碟映像檔直接執行,因為設定寫入、更新與權限記錄都需要穩定路徑。
第一次開啟時,系統可能要求確認應用程式來源或網路權限。應透過系統設定中的隱私權與安全性頁面處理目前應用程式的提示,不要反覆複製應用程式產生多個執行個體。若客戶端介面可以開啟但核心無法啟動,先查看應用程式記錄是否提示檔案無法執行、權限不足或架構錯誤。只有核心啟動並建立本機監聽後,系統代理與 TUN 才有可用的目標入口。
訂閱管理與節點驗證
在 v2rayN 中建立獨立訂閱分組,填入完整網址後主動更新。macOS 上的訂閱操作邏輯與 Windows 相同:儲存訂閱來源、執行更新、確認清單、選擇活動節點並進行實際連線驗證。若剪貼簿中包含前後空格或換行,應重新複製乾淨的網址。訂閱回應逾時可能來自目前網路、DNS 或服務端狀態;解析失敗則更可能是格式不相容。兩類錯誤的處理方向不同,執行記錄中的第一個明確錯誤通常比介面最後顯示的提示更有參考價值。
連線驗證應先使用系統代理,而不是直接啟用 TUN。系統代理會修改目前網路服務的代理設定,Safari 與多數遵循系統網路設定的應用程式會使用該入口。啟用後可以在終端機查看系統代理狀態,確認 HTTP、HTTPS 或 SOCKS 項目是否指向本機位址:
scutil --proxy
# 查看目前系統的預設路由
route -n get default
scutil --proxy 只能說明系統設定已寫入,不代表節點連線一定成功。接下來仍需開啟實際網頁並觀察客戶端記錄。如果系統代理顯示已啟用,但應用程式請求沒有出現在記錄中,應檢查該應用程式是否使用獨立代理、是否啟用了繞過規則,或是否沿用了啟用代理前建立的連線。關閉並重新開啟應用程式可以排除連線重用的干擾。
系統代理與不同網路服務
macOS 會為無線網路、有線網路與其他網路服務分別儲存設定。使用者切換網路後,代理狀態可能需要重新套用。若 v2rayN 顯示系統代理已啟用,而新連線的網路仍然直連,可以先關閉再重新啟用一次系統代理,讓客戶端針對目前活動中的服務寫入設定。公共網路存在驗證頁面時,應先關閉代理完成網路驗證,再重新啟用,否則驗證跳轉可能被送入代理,導致所有頁面都無法開啟。
終端機工具與圖形應用程式之間也存在代理差異。部分命令會讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 環境變數,部分工具則忽略系統圖形代理。只在目前終端機工作階段設定變數較容易復原,關閉終端機後不會持續影響其他工作。不要把固定連接埠寫入全域 shell 設定,除非已確認 v2rayN 的本機入口會長期保持一致,並且知道客戶端未啟動時如何取消設定。
TUN 與網路擴充功能衝突
在 macOS 上啟用 TUN 時,系統可能要求網路相關授權。完成授權後,應檢查記錄是否成功建立虛擬介面並寫入路由。若連線按鈕開啟後網路完全中斷,常見原因包括另一款網路工具仍在執行、系統中存在並行的過濾擴充功能、DNS 被多個程式同時修改,或休眠恢復後舊介面未釋放。先關閉其他接管工具並重新啟動 v2rayN,再判斷是否需要重新啟動系統;不要直接刪除不認識的系統網路服務。
TUN 的範圍通常比系統代理廣,也更容易影響區域網路裝置探索、列印服務與開發環境。啟用後若網際網路存取正常但區域網路位址無法連線,應檢查路由規則是否保留私有位址直連,例如 geoip:private 或同等的區域網路規則是否位於一般代理規則之前。規則順序錯誤會把區域網路請求送往遠端出站,裝置自然無法回應。需要存取本機服務的使用者,應將保留區域網路直連列為啟用 TUN 前的固定檢查項目。
應用程式無法退出或系統代理未恢復時,應先在 v2rayN 中執行關閉系統代理,再正常退出。若應用程式已異常結束,可在系統網路設定中檢查目前網路服務的代理項目。恢復後重新啟動客戶端,以預設設定進行一次連線驗證。只有在同一問題反覆出現時,才需要結合記錄判斷是權限、介面還是應用程式生命週期問題。
五、Linux:軟體套件、桌面代理、環境變數與 TUN
選擇 deb、rpm 與處理器架構
Linux 平台使用 v2rayN 時,需要同時確認架構與軟體套件體系。Debian、Ubuntu 及其衍生發行版通常使用 deb;Fedora、Rocky Linux 等通常使用 rpm。x64 裝置選擇對應的 x64 套件,arm64 裝置選擇 arm64 套件。套件格式選錯時,套件管理器會直接拒絕;架構選錯時,則會出現無法執行或相依性無法滿足。安裝前可透過 uname -m 確認架構,並使用發行版內建的套件管理器安裝,讓桌面選單、相依套件與解除安裝記錄更容易保持一致。
# deb 軟體套件安裝範例,檔名以實際下載結果為準
sudo apt install ./v2rayN-linux-x64.deb
# rpm 軟體套件安裝範例,檔名以實際下載結果為準
sudo dnf install ./v2rayN-linux-x64.rpm
上面的命令僅展示本機軟體套件的安裝方式,檔名應以從下載中心實際取得的檔案為準。若套件管理器提示相依性問題,應先重新整理目前發行版的軟體來源並處理系統相依套件,不要從不明來源拼湊共享函式庫。圖形應用程式啟動後,設定目錄需要讓目前使用者具備寫入權限。不要長期以 root 身份執行整個桌面客戶端;只有建立 TUN 或修改路由時,才透過系統授權提升必要操作的權限。
訂閱匯入與桌面環境差異
訂閱流程與其他桌面平台相同:建立分組、貼上網址、儲存、主動更新並選定活動節點。若應用程式無法從剪貼簿讀取內容,可在一般文字編輯器中確認網址完整後再貼上。Wayland 與 X11 的剪貼簿、系統匣與視窗行為可能不同,但不會改變訂閱格式。系統匣圖示未顯示不代表核心沒有執行,應以客戶端主視窗與程序記錄為準;部分桌面環境需要擴充功能才能顯示傳統系統匣項目。
更新訂閱後,應先確認伺服器清單出現內容,再啟動核心。若記錄提示本機連接埠已被使用,可使用 ss 查看監聽狀況。不要看到連接埠存在就直接結束系統程序,先確認是否有另一個 v2rayN 執行個體、殘留核心或其他代理程式占用相同連接埠。
ss -lntp
# 查看目前使用者工作階段中的代理變數
env | grep -i proxy
# 查看預設路由
ip route show default
桌面系統代理與環境變數
Linux 沒有一套涵蓋所有桌面與命令列程式的統一代理設定。GNOME、KDE 等桌面環境可以儲存圖形代理,瀏覽器是否讀取則取決於瀏覽器設定;終端機程式通常透過環境變數或自身設定決定代理。v2rayN 寫入系統代理後,應先使用目前桌面中的瀏覽器驗證,再個別檢查終端機工具。不要因為終端機直連就判斷系統代理完全失效,也不要因為瀏覽器可用就假設所有背景服務都會自動使用代理。
需要讓某個終端機工作階段使用本機 HTTP 入口時,可以暫時設定環境變數;需要 SOCKS 時,應確認目標工具是否支援對應變數與解析方式。暫時設定應使用 v2rayN 介面顯示的實際監聽位址與連接埠,以下使用回環位址與常見本機連接埠示範語法:
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
# 完成目前工作階段後取消設定
unset HTTP_PROXY
unset HTTPS_PROXY
如果客戶端使用的連接埠不同,應以介面中的參數設定為準。變數名稱的大小寫相容性因程式而異,設定全域變數前必須了解目標工具。系統服務通常不會繼承使用者終端機環境,桌面工作階段的變數也不會自動傳遞給所有容器。排查開發工具時,應分別檢查主機系統、容器、遠端工作階段與整合終端機,避免把多個網路命名空間當成同一個環境。
TUN、權限與 DNS
Linux TUN 依賴系統虛擬網路介面、路由與權限。啟用前應確認系統支援 TUN 裝置,並退出其他會修改預設路由的程式。v2rayN 要求提升權限時,只授權目前所需的網路操作。啟用後可透過 ip addr 與 ip route 觀察介面及路由變化;若預設路由被錯誤替換,先在客戶端內關閉 TUN,再重新檢查。遠端管理的裝置尤其需要謹慎,因為錯誤路由可能中斷目前的遠端連線。
DNS 可能由 systemd-resolved、NetworkManager、桌面環境或手動檔案共同管理。啟用 TUN 後網頁網域無法解析,但直接存取已知位址仍有回應時,應優先檢查 DNS 請求是否進入客戶端、系統目前的解析器指向何處,以及其他網路工具是否覆寫設定。不要長期直接改寫系統解析檔來掩蓋問題,網路管理器可能在下一次連線時重新產生該檔案。正確做法是明確由系統、客戶端或本機解析服務中的哪一個負責 DNS,並避免多個元件爭用相同監聽連接埠。
Linux 上最穩定的排錯方式是分層進行:先驗證 v2rayN 圖形介面與核心可以運作,再驗證瀏覽器系統代理,接著測試終端機環境變數,最後才啟用 TUN。每一層都留下明確結果,出現問題時便能知道是桌面設定、應用程式設定、權限、路由還是 DNS。若記錄出現重複的 timeout、rejected 或解析錯誤,可搭配執行記錄閱讀指南定位具體環節。
六、Android:v2rayNG、v2flyNG 與應用程式分流
選擇客戶端與安裝套件
Android 首選 v2rayNG,採用 Xray 核心路線,適合常見訂閱與路由設定;需要 V2Fly 核心時,可使用 v2flyNG 作為備選。兩款客戶端都透過系統 VPN 介面接管流量,但核心支援範圍、設定名稱與設定儲存方式不保證完全一致。切換客戶端時,應從原始訂閱重新匯入,不要複製另一款應用程式的資料目錄。下載時,近年的主流裝置優先選擇 arm64 套件;無法確認架構或 arm64 安裝遭系統拒絕時,再使用通用套件。
安裝完成後,第一次連線時系統會顯示 VPN 授權提示。允許後,狀態列會出現由系統管理的連線標誌。該標誌只表示虛擬介面已建立,並不代表遠端節點可用。真正的驗證仍需結合客戶端記錄與實際網頁請求。若裝置中已有另一款占用系統 VPN 介面的工具,新客戶端連線時通常會讓原有連線退出;兩個應用程式無法同時控制同一個系統介面。
匯入訂閱、更新與選擇節點
在 v2rayNG 或 v2flyNG 中開啟訂閱分組設定,加入完整訂閱網址並命名,儲存後執行更新。部分系統會限制背景網路存取,若更新一直停滯或立即失敗,可先讓應用程式保持在前景,並確認目前網路本身能夠存取訂閱來源。更新成功後應看到設定清單,選擇其中一項作為活動設定,再進行實際連線測試。QR Code 適合匯入單一設定,訂閱則更適合長期更新;兩者用途不同,不應把單節點 QR Code 當成可自動更新的訂閱分組。
節點清單中顯示的延遲僅供輔助判斷。行動網路在基地台切換、訊號微弱與省電狀態下波動明顯,單次結果不能代表持續品質。選擇節點後啟動連線,開啟新的瀏覽器頁面,並立即回到記錄查看是否產生實際請求。若記錄只有介面啟動資訊而沒有任何出站記錄,表示應用程式流量可能未進入客戶端;若出現 timeout、TLS 或驗證錯誤,則流量已經進入,問題位於遠端連線或設定參數。
系統 VPN 介面與應用程式分流
Android 客戶端通常支援依應用程式決定是否經過代理。應用程式分流有兩種常見思路:只讓選定的應用程式進入,或讓大多數應用程式進入並排除少數應用程式。規則越複雜,之後安裝新應用程式時越容易遺漏。初次設定建議先關閉應用程式分流,確認全域接管可以運作後,再依需求建立允許清單或排除清單。遇到「瀏覽器可用、某個應用程式不可用」時,應先檢查該應用程式是否被排除,而不是修改伺服器參數。
某些應用程式會直接使用 IP、使用特定 UDP 流量,或不遵循傳統 HTTP 代理,因此 Android 客戶端透過系統 VPN 介面接管,通常比桌面系統代理更全面。同時,本機區域網路、投放、列印與裝置探索也可能受到影響。需要存取同一網路中的裝置時,應開啟區域網路繞過,或建立私有位址直連規則。若應用程式分流與路由規則同時存在,資料會先由系統決定是否進入客戶端,進入後才由核心路由決定出站;被系統分流排除的應用程式不會再符合核心規則。
背景限制、電量與網路切換
Android 的省電策略可能限制客戶端在背景執行。典型表現是鎖定螢幕一段時間後連線中斷,重新點亮螢幕後恢復,或系統清理背景程序後狀態標誌消失。可在系統應用程式設定中允許必要的背景活動,並避免使用過於激進的自動清理策略。不同裝置的設定入口名稱各異,但判斷標準一致:螢幕關閉後,客戶端仍應維持系統 VPN 服務運作。不需要授予與網路無關的權限。
從無線網路切換到行動網路時,既有連線可能失效,核心需要重新建立出站連線。若切換後長時間沒有恢復,可在客戶端中停止後再啟動一次,不必刪除訂閱。公共無線網路要求網頁驗證時,應先中斷客戶端連線,完成驗證後再重新連線。若無線網路可用而行動網路失敗,請檢查行動網路的 DNS、IPv6 與電信商接入差異;若所有節點都只在某一種網路上失敗,更可能是網路路徑問題,而不是每筆訂閱同時失效。
啟用「永遠開啟」這類系統選項前,應先確保客戶端穩定,並了解系統的阻斷策略。如果同時啟用「未連線時封鎖網路」,客戶端異常退出或更新期間,其他應用程式也會無法上網。這項設定適合已完成長期驗證的設定,不適合作為首次安裝的預設步驟。排查斷網時,應檢查系統 VPN 頁面是否啟用了這類限制,以免把系統主動阻斷誤認為節點故障。
v2rayNG 與 v2flyNG 的記錄入口位置可能不同,但排錯思路一致。應關注首次失敗前後的錯誤,而不是連續重試後大量重複的資訊。分享記錄時,請刪除訂閱網址、使用者識別碼、伺服器位址等敏感內容,只保留錯誤類型、發生階段與系統環境。若客戶端顯示已連線但網頁仍無法存取,可繼續閱讀代理已連線但無法上網排查清單。
七、路由、DNS 與 TUN:從預設規則到可維護的分流
路由規則的比對順序
路由決定已進入客戶端的請求應使用哪個出站。常見出站包括直連、代理與阻斷。規則通常由上至下比對,命中後便不再繼續,因此具體規則應放在通用規則之前。例如區域網路與明確的直連網域應先處理,最後再使用兜底規則將其餘流量交給代理。若把「全部代理」放在最前面,後面的區域網路直連永遠不會生效;若把範圍過大的直連規則放在前面,原本應走代理的請求也可能提前退出。
網域規則與 IP 規則處理的是不同階段的問題。請求最初只有網域名稱時,可以比對 geosite 或明確網域;解析後取得 IP,則可比對 geoip、私有位址或網段。一個連線可能同時具備網域名稱與目標 IP,但客戶端能取得哪些資訊,取決於入口協定、DNS 流程與應用程式行為。不要依賴單一規則涵蓋所有情況,尤其是直接連線 IP 的應用程式不會觸發網域規則。較完整的規則通常會同時保留網域集合、IP 集合與最終兜底規則。
建議的基本路由結構
基本設定可以從三層開始:區域網路與私有位址直連;明確屬於本地網路環境的網站與位址集合直連;其餘請求走代理。是否加入阻斷規則,應依實際需求單獨維護,不要未檢查影響就直接併入大範圍網域清單。以下 JSON 片段展示 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"
}
]
}
}
domainStrategy 控制網域規則未命中時,是否進一步解析 IP。IPIfNonMatch 表示先嘗試網域比對,未命中時再解析並嘗試 IP 規則。它不是越積極越好:額外解析會增加 DNS 的參與程度,而完全不解析又可能讓 IP 規則無法比對網域請求。圖形客戶端可能以「網域策略」下拉選單呈現這個參數。調整前先明確要解決的問題,不要只因為某個選項看起來更完整就切換。
DNS 請求為什麼會影響連線
DNS 負責將網域名稱轉換為位址,既可能由系統完成,也可能由客戶端轉送、接管或依規則分流。常見異常包括系統取得無法連線的位址、客戶端與系統得到不同結果、TUN 接管後 DNS 請求未進入預期的監聽入口,以及 IPv4 與 IPv6 的回傳順序不適合目前網路。表現上可能是網域無法開啟、直接使用位址卻有回應,或某些網站可用而另一些持續逾時。此時反覆更換節點只能偶爾繞過症狀,無法修正解析鏈路。
排查 DNS 時先回答三個問題:應用程式將查詢交給誰、解析請求從哪個出站送出,以及最後回傳哪類位址。系統代理模式下,瀏覽器可能自行處理安全 DNS,也可能交給系統;TUN 模式下,客戶端通常能接管更多查詢。若瀏覽器啟用了獨立 DNS 設定,其結果可能繞過系統與客戶端的預期。應先使用預設瀏覽器網路設定驗證,再決定是否加入自訂 DNS。同時啟用多個解析方案會讓記錄與結果難以對應。
系統代理與 TUN 如何選擇
| 比較項目 | 系統代理 | TUN |
|---|---|---|
| 涵蓋範圍 | 主要涵蓋遵循系統設定的應用程式 | 可涵蓋更廣泛的 TCP、UDP 流量 |
| 權限需求 | 通常較低 | 需要虛擬介面與路由權限 |
| 排錯複雜度 | 入口清楚,方便按應用程式判斷 | 涉及路由、DNS 與介面衝突 |
| 適用情境 | 瀏覽器、一般桌面軟體 | 不讀取代理設定或需要 UDP 的程式 |
應先使用系統代理完成基本連線,再決定是否需要 TUN。如果目標應用程式已能透過系統代理運作,啟用 TUN 不會自動提升節點品質,只會改變流量進入的方式。確實有應用程式不讀取系統代理、需要 UDP 或希望統一管理時,再啟用 TUN,並保留區域網路直連。啟用前記錄目前的系統代理、DNS 與其他虛擬網卡狀態,發生異常時才能復原。
驗證規則變更的方法
每次只修改一組規則,並使用明確目標進行驗證。例如新增區域網路直連後,分別測試區域網路裝置與網際網路一次;修改 geosite 規則後,查看記錄中的目標網域與最終出站;調整 DNS 後,分別測試新網域與已快取網域。不要一次匯入大量規則、切換 DNS、啟用 TUN 並更換節點,因為無論成功或失敗,都無法判斷是哪項變更造成的。
路由規則名稱應表達設定意圖,例如「區域網路直連」「常用本地域名直連」「其餘代理」,不要使用難以理解的臨時編號。長期維護時,先寫清楚規則目的,再記錄比對條件與出站。訂閱更新通常只更新伺服器設定,不應覆蓋使用者自訂路由;但不同客戶端的匯入方式可能影響目前選擇,因此更新後若行為出現變化,應確認活動路由設定仍然正確。
八、常見設定問題與分層排查
先依資料路徑定位故障層
有效的排錯不是從「重新安裝客戶端」開始,而是判斷請求停在哪一層。第一層是訂閱取得:能否更新、能否解析並產生節點;第二層是核心啟動:設定能否載入、本機連接埠能否監聽;第三層是遠端連線:節點能否完成 DNS、TCP、TLS 與協定交握;第四層是應用程式接管:系統代理、環境變數或系統 VPN 介面是否讓流量進入客戶端;第五層是路由與 DNS:請求進入後是否選到正確出站,網域是否解析為可連線的位址。每一層都有獨立證據,應先找出最早的失敗點。
閱讀記錄時,重點查看單次操作對應的時間區段。先清空記錄或記住目前位置,再執行一次訂閱更新、連線或網頁存取,接著閱讀新產生的內容。之後連續重試會製造大量重複的 timeout,掩蓋最初的解析、權限或驗證錯誤。常見關鍵字中,timeout 表示未能在規定時間內完成,原因可能是網路無法連線、服務沒有回應或 DNS 緩慢;rejected 表示連線遭規則、遠端或協定條件拒絕;invalid user 通常與使用者識別碼、驗證資訊或服務端設定不一致有關。具體判斷可參閱執行記錄怎麼看。
訂閱更新失敗或更新後沒有節點
先確認訂閱網址完整,且沒有複製到顯示省略號的文字。刪除網址前後的空格與換行,保留原始參數。接著在客戶端內手動更新一次對應分組並查看記錄。如果記錄顯示網路逾時,檢查目前網路與 DNS;如果回傳內容無法解析,確認所選訂閱格式適用於目前客戶端;如果回應為空或權限遭拒,則需要在訂閱來源一側確認狀態。不要連續新增相同訂閱,這只會產生多個失敗副本。
更新顯示成功但清單為空時,檢查目前介面是否套用了分組、搜尋詞或設定類型篩選,也要確認節點被匯入了哪個分組。若從另一款客戶端遷移,不要直接複製內部資料庫,重新匯入原始訂閱更可靠。訂閱更新後舊節點仍在,可能是客戶端設定為保留舊設定;此時應先確認新內容是否已產生,再決定是否清理,不要在沒有備份來源資訊時一次刪除所有分組。
客戶端已啟動但系統代理沒有生效
先開啟客戶端記錄,然後從瀏覽器發出新的請求。如果記錄完全沒有內容,問題位於應用程式與本機入口之間:系統代理沒有寫入、瀏覽器使用獨立設定、應用程式尚未重新建立連線,或目前網路服務沒有套用代理。如果記錄出現請求但遠端連線失敗,表示系統代理已生效,問題應轉向節點、DNS 或路由。用這種方式可以避免將代理接管問題與伺服器問題混為一談。
Windows 與 macOS 可進入系統網路設定確認代理狀態;Linux 需要分別檢查桌面代理與終端機環境變數;Android 則檢查系統 VPN 授權與應用程式分流。終端機工具沒有像瀏覽器一樣生效,屬於常見的機制差異,應查看該工具支援的代理參數。客戶端退出後無法上網時,檢查是否留下系統代理或「未連線時封鎖網路」設定。相關桌面排錯流程可繼續閱讀瀏覽器與命令列終端機分開排查。
顯示已連線但網頁無法開啟
「已連線」通常只表示核心或虛擬介面已啟動。首先切換到已完成實際連線驗證的節點,確認裝置時間與時區正確;其次觀察網頁請求是否進入記錄;接著檢查 DNS 是否報錯、路由是否將請求送往預期出站;最後檢查系統代理或 TUN 是否與其他網路工具衝突。如果所有節點都在同一裝置、同一網路上失敗,而換到另一個網路即可使用,應優先調查目前的網路路徑。若只有單一節點失敗,則更可能是該設定或遠端狀態所致。
不要把 Ping 結果當成最終判斷。伺服器可能不回應一般探測,但代理協定仍能連線;反過來,位址可以回應探測,也不代表驗證與 TLS 交握成功。實際連線測試與真實網頁請求更接近實際使用路徑。完整清單請見v2rayN 與 v2rayNG 逐項排查清單,其中依節點、時間、DNS、路由與系統代理順序整理檢查項目。
TUN 啟用後斷網或區域網路無法存取
立即在客戶端內關閉 TUN,確認基本網路能否恢復。如果仍未恢復,再檢查系統代理、系統 VPN 阻斷選項與殘留虛擬介面。基本網路恢復後,只保留目前客戶端,關閉其他會修改路由或 DNS 的程式,再次啟用 TUN 並觀察第一個錯誤。權限不足通常會在建立介面階段失敗;連接埠衝突發生在監聽階段;預設路由或 DNS 錯誤則常表現為介面建立後請求逾時。
網際網路可用但區域網路無法存取時,檢查私有位址直連規則是否存在,並確認其位於兜底代理之前。常見私有位址與本機鏈路不應交給遠端出站。Android 還要檢查應用程式設定中的區域網路繞過;桌面平台則要確認防火牆沒有將新虛擬介面歸入不合適的網路範圍。修改後分別測試區域網路位址與一般網域,不能只驗證其中一項。
連接埠占用、重複執行個體與設定回退
記錄提示位址已被使用時,通常是另一個客戶端執行個體、殘留核心程序或其他代理程式占用了相同連接埠。先從工作管理員、活動監視器或程序清單確認歸屬,再正常退出對應程式。隨意更換連接埠雖然可能讓目前執行個體啟動,但系統代理、環境變數與應用程式內的固定設定也必須同步修改,容易留下新的不一致。應優先處理重複執行個體,再考慮調整連接埠。
如果問題發生在某次設定變更之後,最有效的方法是回退最近一項,而不是還原所有設定。依相反順序關閉 TUN、自訂 DNS、新增路由與應用程式分流,保留訂閱與單一節點。基本連線恢復後再逐項加回。若客戶端設定已難以判斷,可記錄訂閱來源,建立新的最小設定進行對照;新設定可用表示舊偏好存在衝突,新設定也失敗則繼續檢查平台權限、網路與訂閱內容。
最終檢查清單
- 安裝套件與目前平台、處理器架構及發行版格式一致。
- 訂閱分組可主動更新,節點清單不是空白,也沒有被篩選條件隱藏。
- 活動節點通過實際連線驗證,系統時間與時區正確。
- 核心成功啟動,本機監聽連接埠沒有被重複執行個體占用。
- 瀏覽器或目標應用程式的請求能夠出現在客戶端記錄中。
- 路由規則依具體到通用排列,區域網路與私有位址保留直連。
- DNS 由明確的單一路徑負責,沒有多個工具同時覆寫。
- TUN 只在基本系統代理驗證後啟用,發生異常時能夠關閉並復原。
完成以上檢查仍無法定位時,應將現象縮小到一個平台、一個客戶端、一個訂閱分組、一個節點與一種接管方式,再記錄完整重現流程。先說明「在哪個步驟失敗」,再說明「記錄出現什麼」,比只描述「無法連線」更容易得到有效判斷。需要重新走一遍最短操作流程時,返回快速上手教學;需要更換安裝套件或確認平台入口時,前往下載中心。