V2Ray 全平台安裝設定大全

通用準備工作與設定邊界

安裝前先確認裝置架構、訂閱類型、代理目標與目前網路狀態。準備階段處理得越清楚，之後發生連線失敗時，就越容易將問題限定在單一環節。

先區分用戶端、核心與訂閱

v2rayN、v2rayNG 與 v2flyNG 是圖形化用戶端，負責儲存伺服器資訊、產生執行設定、啟動核心並控制系統代理。Xray 與 V2Fly 屬於實際處理連線、傳輸與路由的核心家族。訂閱則是由服務端提供的一組伺服器設定，常見內容包括位址、連接埠、使用者識別碼、協議、傳輸方式、TLS 參數與伺服器名稱。三者不在同一層級：用戶端提供操作介面，核心執行設定，訂閱提供可用的連線參數。

桌面裝置優先選擇 v2rayN。它在 Windows、macOS 與 Linux 上維持相近的訂閱分組、伺服器清單與路由設定結構，跨裝置遷移時更容易核對。Android 裝置通常選擇使用 Xray 核心的 v2rayNG；需要符合 V2Fly 核心行為時，再使用 v2flyNG。不要只憑協議名稱判斷用戶端能否連線，還要確認傳輸層、TLS、安全參數與服務端設定是否完整對應。

確認處理器架構與安裝包類型

Windows 常見桌面裝置使用 x64 套件。macOS 需依晶片選擇 Apple Silicon 或 Intel 安裝包。Android 主流裝置通常適用 arm64，無法確認架構或裝置相容性較複雜時，可使用通用包。Linux 除處理器架構外，還要區分套件體系：Debian、Ubuntu 及其衍生發行版使用 deb，Fedora、Rocky Linux、openSUSE 等環境通常使用 rpm。選錯安裝包類型時，常見結果是安裝程式拒絕執行、提示架構不相容，或程式啟動後立即退出。

保留原始資訊並建立基準

匯入前保留訂閱位址的原始文字，不要讓它長期暴露在聊天轉傳、筆記同步或 QR Code 截圖中。訂閱位址通常具備讀取整組節點的權限，外洩後可能被他人使用。首次設定只匯入一個訂閱分組，選擇一部確認可用的伺服器，以預設路由與預設 DNS 建立基準。基準連線成功後，再逐項啟用自訂路由、TUN、FakeDNS、Mux 或分應用程式代理。一次修改多個參數會讓錯誤來源互相疊加，無法判斷究竟是哪一項導致異常。

開始前還應關閉同類代理用戶端，確認系統時間、時區與網路本身正常。TLS 交握依賴準確時間，明顯偏差會表現為憑證錯誤或建立連線後立即中斷。公司網路、訪客網路與公共熱點可能限制特定連接埠或 UDP，因此應先用瀏覽器直接瀏覽一般網站，確認 DNS 與基礎網路可用。若裝置曾設定手動代理，先記錄原值，再交由用戶端管理，避免退出用戶端時殘留舊位址。

建立可重複的操作順序

1. 選擇對應安裝包依平台、處理器架構與套件體系選擇，不要用檔名相近的其他建置版本替代。
2. 匯入一個訂閱分組填寫名稱與訂閱位址，更新後確認伺服器項目正常產生。
3. 選擇作用中伺服器先進行實際連線測試，再決定是否批次測速或調整排序。
4. 啟用一種接管方式先在系統代理與 TUN 之間選擇一種進行驗證，避免同時改變網路路徑。
5. 記錄有效設定儲存路由模式、DNS 方案與用戶端設定，方便升級或遷移後還原。

準備階段的目標不是提前調整完所有選項，而是建立一條可重複、可回復的設定鏈。之後任何平台出現問題，都依「安裝是否完整、訂閱是否解析、伺服器是否可用、核心是否啟動、流量是否進入用戶端、DNS 是否匹配」六層順序檢查。如此可避免將節點故障誤判為安裝故障，也不會在系統代理殘留時反覆修改訂閱。

Windows 安裝、系統代理與 TUN

Windows 端使用 v2rayN。桌面版採用跨平台介面，經典 WPF 版適合偏好傳統 Windows 操作方式的使用者；兩者的訂閱、伺服器與路由概念一致。

下載與安裝選擇

進入Windows 下載區後，依使用習慣選擇桌面版或經典 WPF 版。新安裝通常從桌面版開始；需要傳統系統匣操作、已有 WPF 設定目錄或依賴既有操作流程時，可繼續選擇經典版。安裝前退出正在執行的舊用戶端，避免安裝程式無法替換被佔用的檔案。安裝完成後從開始功能表啟動，首次執行應先確認主視窗可以開啟、系統匣出現用戶端入口，且核心類型能正常顯示。

若系統跳出網路存取權限提示，應依實際網路環境允許用戶端通訊。該提示關係到入站監聽與區域網路功能，不等同於啟用系統代理。受管理裝置可能禁止一般使用者安裝網路元件或建立服務，遇到權限提示時應使用裝置管理員允許的安裝方式，而不是反覆解壓縮到不同目錄。攜帶式使用也要避免將程式放在會自動清理、唯讀或路徑過長的位置。

匯入訂閱並選擇作用中伺服器

開啟訂閱分組管理，新增分組名稱並貼上訂閱位址。儲存後執行更新，主清單應出現協議、別名與伺服器資訊。若清單為空，先檢查位址是否完整、是否夾帶空格，以及用瀏覽器開啟該位址時服務端是否回傳有效內容。更新成功後選擇一部伺服器，將其設為作用中伺服器。測速只能反映特定測試方式下的回應，不代表所有業務流量都適合該節點，因此首次驗證應以實際網頁請求與目標應用程式連線為準。

訂閱更新會依服務端內容新增、修改或移除項目。手動修改由訂閱產生的伺服器參數，下一次更新時可能被覆蓋。需要保留個人化設定時，優先將變更放在用戶端路由、DNS 或獨立的手動伺服器分組中。刪除訂閱前先確認其中沒有唯一可用的設定；重新加入相同位址可能產生新的分組識別碼，原有排序與選取狀態不一定保留。

系統代理的三種使用狀態

Windows 系統代理主要影響遵循系統代理設定的瀏覽器與桌面程式。常見狀態包括清除系統代理、設定系統代理與不變更系統代理。日常使用通常選擇「設定系統代理」，退出時再執行「清除系統代理」。「不變更」適用於手動設定瀏覽器代理、只讓特定程式連線至本機連接埠，或由其他網路工具統一管理系統代理的情況。切換後可開啟 Windows 代理設定，核對位址是否指向本機迴送位址，以及連接埠是否與 v2rayN 目前監聽的連接埠一致。

若用戶端退出後瀏覽器無法連線，優先檢查系統代理是否殘留。可以重新啟動 v2rayN 後執行清除，也可以在系統設定中關閉手動代理。不要直接把本機監聽連接埠改成訂閱中的遠端伺服器連接埠；前者是應用程式連線至 v2rayN 的入口，後者是核心連線至服務端的目標，兩者作用完全不同。

ipconfig /flushdns
netsh winhttp show proxy
Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess

以上指令分別用於重新整理 Windows DNS 快取、查看 WinHTTP 代理狀態與檢查本機監聽連接埠。瀏覽器系統代理與 WinHTTP 代理並非同一套設定，因此 netsh winhttp show proxy 顯示直接連線時，瀏覽器仍可能正在使用系統代理。排錯時要同時檢查 Windows 設定、用戶端狀態與目標程式本身的代理選項。

TUN 模式與平台特有問題

TUN 會建立虛擬網路介面，讓不讀取系統代理的程式也能進入用戶端。啟用前先用系統代理完成一次穩定連線，再檢查 v2rayN 的 TUN 元件與權限是否就緒。首次啟用可能觸發管理員權限請求或網路介面安裝。成功後系統路由表會出現對應介面，用戶端停止時應恢復原有路徑。休眠、網路切換與異常退出可能造成虛擬介面仍存在但核心未執行，此時會表現為所有應用程式都無法連線。

遊戲、虛擬機器、容器軟體與企業網路用戶端可能同時修改路由或 DNS。出現衝突時，先關閉 TUN 並恢復系統代理進行驗證，再決定透過路由規則排除目標網段，或調整虛擬網卡優先順序。區域網路印表機、網路儲存與遠端桌面位址通常應保持直接連線。不要把私有位址區段全部送入遠端，否則會出現區域網路裝置無法連線、網域帳號驗證變慢或本機開發服務失聯。

Windows 更新或網路驅動程式變更後，如果 TUN 突然失效，可重新啟動系統並檢查虛擬介面是否正常載入。安全軟體可能限制新建立的監聽連接埠或網路介面，應依程序路徑與本機監聽用途設定明確規則。日誌若顯示核心已啟動，但瀏覽器沒有任何請求記錄，問題通常位於系統代理或應用程式代理層；若請求進入用戶端後連線遠端失敗，則繼續檢查伺服器參數、DNS、TLS 與目前網路限制。

macOS 安裝、晶片選擇與網路權限

macOS 端使用 v2rayN 桌面版。安裝重點是選擇正確的晶片建置版本、完成首次開啟授權，並理解系統代理與網路延伸功能權限的界線。

判斷晶片並完成安裝

在系統的「關於這台 Mac」資訊中查看晶片或處理器。顯示 Apple 晶片名稱時選擇 Apple Silicon 安裝包；顯示 Intel 處理器時選擇 Intel 安裝包。進入macOS 下載區取得對應 DMG，開啟磁碟映像檔後將應用程式拖曳至「應用程式」資料夾，再從應用程式資料夾啟動。不要長期直接從已掛載的磁碟映像檔執行，否則升級、權限儲存與自動啟動行為可能不穩定。

首次開啟時，系統會確認應用程式來源與網路存取權限。依系統提示完成授權後再匯入設定。若按兩下沒有反應，先在「隱私權與安全性」中查看是否有遭阻擋的開啟請求，並確認安裝包架構與裝置一致。Apple Silicon 裝置誤裝 Intel 建置版本時可能依賴相容性轉換層，雖然部分環境可以執行，但不應作為預設選擇；原生建置版本在啟動、資源使用與網路元件相容性方面更直接。

訂閱匯入與選單列狀態

v2rayN 的訂閱流程與 Windows 端一致：建立訂閱分組、填寫位址、執行更新、選擇作用中伺服器。主視窗關閉後，程式可能仍在選單列執行，因此判斷用戶端是否退出時要查看選單列狀態，而不是只看視窗。更新訂閱後若伺服器清單沒有變化，先檢查目前選取的分組，再查看更新日誌。多個分組使用相同名稱時容易誤選，建議依用途或服務來源建立簡短明確的分組名稱。

選擇伺服器後先啟動核心，確認日誌沒有設定解析錯誤。接著啟用系統代理。macOS 會依網路服務儲存代理設定，不同的無線網路、有線網路或其他網路服務可能具有獨立狀態。切換網路後若瀏覽器突然直接連線，應檢查目前作用中的網路服務是否仍由用戶端設定代理。反過來，用戶端退出後無法瀏覽網頁，則檢查系統網路設定中的 HTTP、HTTPS 與 SOCKS 代理是否留下舊位址。

系統代理、終端機與獨立代理程式

系統代理主要涵蓋遵循 macOS 網路代理設定的應用程式。終端機指令、開發工具與部分跨平台程式可能讀取環境變數，也可能完全忽略系統設定。需要讓某個命令列程式使用本機代理時，應只在目前終端機工作階段設定對應變數，並將連接埠替換為 v2rayN 實際監聽的值。工作完成後關閉終端機工作階段即可清除，避免將代理變數永久寫入全域啟動指令碼。

export http_proxy=http://127.0.0.1:本機HTTP連接埠
export https_proxy=http://127.0.0.1:本機HTTP連接埠
export all_proxy=socks5://127.0.0.1:本機SOCKS連接埠
env | grep -i proxy

這裡的「本機HTTP連接埠」與「本機SOCKS連接埠」應從用戶端設定中讀取，不能直接照抄其他裝置的數值。若程式只支援 HTTP 代理，就不要填入 SOCKS 位址。部分命令列工具對大小寫環境變數的處理不同，排錯時應查看該工具文件，並使用 env | grep -i proxy 確認目前工作階段究竟存在哪些變數。

TUN、DNS 與休眠復原

TUN 模式需要更高層級的網路權限。首次開啟時，系統可能要求確認網路延伸功能、輸入裝置密碼或允許背景項目。授權只解決元件載入問題，不代表路由一定正確。啟用後應依序驗證一般網頁、區域網路位址、終端機請求與目標應用程式。若只有區域網路失效，應檢查私有位址直接連線規則；若所有網域失敗但直接存取已知位址正常，重點檢查 DNS；若休眠復原後完全斷網，應先停止 TUN、退出用戶端，再重新啟動。

macOS 的網路服務順序、私有轉送類網路功能、企業設定描述檔與其他虛擬網路程式都可能改變流量路徑。排錯時保持一次只執行一個負責接管預設路由的程式。無線網路從家庭網路切換到公共網路後，服務端可達性、UDP 能力與 DNS 回應可能改變，不能只根據切換前的狀態判斷用戶端故障。先關閉接管以恢復直接連線，再重新啟動核心，最後重新啟用代理，是最穩妥的復原順序。

升級與設定遷移

升級前退出選單列中的 v2rayN，並記錄目前的訂閱分組、路由模式、核心類型與本機連接埠。覆蓋應用程式通常不會主動修改設定，但從舊目錄直接複製全部執行檔可能帶入失效快取或過期元件。更穩妥的方法是保留訂閱位址與明確的自訂規則，先在新程式中確認基礎功能，再進行遷移。若新舊建置版本無法共用設定結構，應優先重新匯入訂閱，而不是手動修改內部資料庫。

遷移完成後檢查開機啟動與背景項目列表，避免舊程式與新程式同時啟動。選單列出現兩個相似入口時，應退出所有執行個體，再從「應用程式」資料夾啟動目標版本。日誌目錄與暫存設定中可能包含伺服器資訊，對外提供診斷資料前要刪除訂閱位址、使用者識別碼、網域與連接埠。通常只保留錯誤類型、發生階段與必要的核心提示，就足以定位問題。

Linux 安裝、桌面整合與權限

Linux 端使用 v2rayN 桌面版。安裝前同時確認發行版套件體系、處理器架構、桌面工作階段與圖形相依元件，避免把介面問題誤判為核心問題。

deb、rpm 與處理器架構

Debian、Ubuntu、Linux Mint 等環境通常選擇 deb；Fedora、Rocky Linux 及使用 RPM 套件管理體系的發行版選擇 rpm。裝置架構可透過 uname -m 查看：常見的 x86_64 對應 x64，aarch64 對應 arm64。進入Linux 下載區時要同時符合這兩項條件。只符合套件格式而忽略架構，安裝程式會直接拒絕；只符合架構卻選錯套件體系，則會缺少對應的套件管理中繼資料。

uname -m
cat /etc/os-release
echo "$XDG_CURRENT_DESKTOP"
echo "$XDG_SESSION_TYPE"

/etc/os-release 用於識別發行版與基礎體系，XDG_CURRENT_DESKTOP 與 XDG_SESSION_TYPE 用於判斷桌面環境，以及目前是 X11 還是 Wayland。v2rayN 的代理核心並不依賴某一種桌面協議，但系統匣圖示、視窗縮放、開機啟動與系統代理寫入可能受到桌面環境影響。伺服器版或最小化系統若沒有完整圖形工作階段，不適合將圖形用戶端部署為系統服務。

使用系統套件管理器安裝

deb 套件可透過圖形化軟體安裝器開啟，也可使用系統套件管理指令安裝；rpm 套件同理。命令列安裝的價值在於能明確顯示缺少的相依套件，而不是繞過發行版的套件管理。安裝檔案名稱應以實際下載結果為準，不要將範例文字直接當作路徑。

sudo apt install ./下載取得的v2rayN軟體包.deb
sudo dnf install ./下載取得的v2rayN軟體包.rpm

安裝完成後從桌面應用程式清單啟動。若視窗無法出現，先在終端機執行應用程式入口觀察錯誤輸出，再檢查圖形執行庫、顯示伺服器環境變數與使用者目錄寫入權限。不要直接以 root 身分長期執行圖形用戶端。root 啟動會在管理員家目錄建立另一套設定，也可能導致一般使用者無法讀取之後產生的檔案。只有安裝套件、設定 TUN 或修改系統層級網路設定時，才需要依提示提升權限。

訂閱、系統代理與桌面環境差異

訂閱匯入仍依循新增分組、更新內容、選擇伺服器、啟動核心的順序。核心啟動後先查看本機 HTTP 與 SOCKS 監聽連接埠，再決定如何將應用程式流量送入用戶端。GNOME、KDE Plasma 與其他桌面環境儲存系統代理的位置不同，v2rayN 能否自動寫入取決於目前的桌面整合。若自動設定後瀏覽器沒有進入代理，可在桌面網路設定中手動核對迴送位址與連接埠，但不要同時保留舊用戶端的代理值。

終端機程式通常讀取 http_proxy、https_proxy 或 all_proxy 環境變數。圖形程式可能遵循桌面代理，也可能使用自身設定。由 systemd 管理的背景服務不會自動繼承登入終端機中的環境變數，需要在服務本身的設定中明確宣告。排錯時先確認目標程式屬於瀏覽器、終端機程序、桌面應用程式還是系統服務，再檢查對應入口，不能只看桌面代理開關。

TUN、路由表與本機服務

Linux TUN 需要核心支援、裝置節點與建立網路介面的權限。啟用前可檢查 /dev/net/tun 是否存在。容器、虛擬機器、網路命名空間與防火牆管理器都可能新增策略路由或封包標記。若 v2rayN 顯示 TUN 已啟動但流量沒有進入核心，應檢查預設路由、策略路由、DNS 指向以及防火牆是否允許虛擬介面轉送。不要在不了解現有規則的情況下整體清空防火牆，這會影響系統服務與容器網路。

ip address
ip route
ip rule
ss -lntup
resolvectl status

ip route 用於確認預設路由與私有網段路徑，ip rule 用於查看策略路由，ss 用於確認本機代理連接埠是否監聽，resolvectl status 可查看採用 systemd-resolved 的系統目前 DNS。若發行版使用其他解析器，應檢查對應的網路管理服務，而不是直接反覆覆寫 /etc/resolv.conf。該檔案在不少發行版中由 NetworkManager 或解析服務動態產生，手動修改可能在重新連線網路後消失。

系統匣、開機啟動與升級

部分桌面環境預設不顯示傳統系統匣圖示，關閉視窗後很難確認用戶端是否仍在執行。首次使用應測試關閉視窗的行為，並透過程序清單確認退出方式。設定開機啟動時，只保留一個桌面自動啟動入口，避免使用者層級的自動啟動檔案與桌面設定重複。重複執行個體可能爭用同一本機連接埠，表現為第二個執行個體啟動失敗、訂閱更新正常但代理監聽不存在。

升級前退出所有執行個體，使用發行版套件管理器安裝新套件。若發生相依衝突，先讀取套件管理器提供的具體套件名稱與版本限制，不要盲目刪除桌面執行庫。設定遷移應以訂閱、路由與 DNS 設定為核心，快取與執行時產生的檔案不必整體複製。升級後依「介面啟動、核心啟動、本機監聽、系統代理、TUN」順序逐層驗證，即可準確辨識變化發生在哪一層。

Android 安裝、背景執行與分應用程式代理

Android 端首選 v2rayNG，預設使用 Xray 核心；需要 V2Fly 核心行為時選擇 v2flyNG。兩者的匯入、連線與分應用程式代理思路相近。

選擇 arm64 或通用安裝包

近年的主流 Android 手機和平板通常使用 arm64，可優先選擇對應安裝包。無法確認裝置架構、系統較舊或安裝時提示不相容時，可改用通用包。通用包包含更多架構程式碼，檔案通常較大，但相容範圍更廣。進入Android 下載區時，先選用戶端，再選架構：通常使用 v2rayNG；只有明確需要 V2Fly 核心時，才安裝 v2flyNG。

安裝前確認系統允許目前的瀏覽器或檔案管理器開啟下載取得的安裝包。這項授權通常依來源應用程式個別管理，安裝完成後可以關閉對應來源的安裝權限。覆蓋升級應保持應用程式識別碼一致；若系統提示簽章不相符，不要強行覆蓋，先備份訂閱位址與自訂設定，再確認目前已安裝的應用程式與新套件來源是否一致。解除安裝會清除應用程式私有設定，因此不要在尚未儲存訂閱資訊前直接解除安裝進行排錯。

匯入訂閱與 QR Code

複製訂閱位址後，在訂閱分組中新增設定並執行更新。QR Code 適合匯入單一伺服器或服務端提供的訂閱資訊，但掃描前仍要確認 QR Code 來源。從相簿辨識需要儲存空間或相片讀取權限，使用相機掃描需要相機權限；只在使用該功能時授權即可。匯入後檢查伺服器項目是否包含位址、連接埠、協議與傳輸資訊，名稱出現亂碼通常不影響連線，但全部項目為空則表示訂閱未正確解析。

選擇伺服器後點選連線按鈕，系統會顯示網路連線授權對話框。確認後狀態列出現系統網路圖示，表示應用程式取得了流量入口，不代表遠端連線一定成功。此時應查看 v2rayNG 日誌並開啟實際網頁進行驗證。若點選連線後立即恢復斷線狀態，重點檢查設定解析、連接埠佔用與系統是否限制應用程式啟動；若保持連線但網頁無法開啟，再檢查伺服器可達性、DNS 與路由模式。

背景保活與電池策略

Android 製造商的省電策略可能在螢幕關閉後限制 v2rayNG，表現為鎖定螢幕一段時間後連線中斷、通知仍在但沒有流量，或切回應用程式後重新連線。應在系統電池設定中允許用戶端於背景執行，並將其加入受保護應用程式或背景白名單。具體選單名稱因裝置而異，判斷標準是允許背景活動、關閉自動凍結，並避免系統清理工具終止用戶端程序。

背景保活不代表應關閉所有省電功能。先觀察問題是否只在鎖定螢幕、切換行動網路或長時間待機後出現，再針對 v2rayNG 調整。若耗電量明顯增加，應檢查是否啟用了不必要的全域代理、頻繁訂閱更新、持續測速或高負載的 Mux 設定。可參考v2rayNG 背景保活與耗電排查，依系統限制、分應用程式代理與連線參數逐項處理。

分應用程式代理與繞過區域網路

分應用程式代理用於控制哪些應用程式進入 v2rayNG。正向選取表示只有選中的應用程式使用代理；繞過選取表示選中的應用程式保持直接連線。啟用前先確認目前模式，避免將支付、區域網路控制或公司驗證應用程式意外送入遠端。系統元件、瀏覽器核心與應用程式之間可能存在呼叫關係，只選取主要應用程式時，透過外部開啟的網頁或下載服務不一定沿用相同路徑。

區域網路裝置位址、路由器管理頁面、投放裝置與網路儲存通常應保持直接連線。若連線 v2rayNG 後無法存取這些裝置，請檢查路由模式是否包含私有位址直連規則。行動網路與無線網路切換時，本機網段會改變，舊網路的特定網段規則不一定適用於新網路。通用私有位址規則通常比逐一設定裝置位址更穩定，但企業網路可能使用更複雜的內部網段，需要依實際網路補充。

行動網路切換與連線復原

從無線網路切換到行動數據時，底層網路位址、DNS 與 IPv6 條件都會改變。應用程式可能維持系統連線狀態，但原有遠端工作階段已失效。正常情況下核心會重建連線；若長時間沒有流量，可先切換一次用戶端連線，而不是立即刪除訂閱。公共無線網路常要求先完成網頁驗證，應在暫停代理後完成驗證，再重新連線。

若只有某個應用程式無法存取，先關閉分應用程式代理進行驗證，再檢查該應用程式是否使用私有 DNS、內建 QUIC 或獨立代理設定。若所有應用程式都失敗，查看日誌中是否有 DNS 逾時、連線遭拒或 TLS 相關提示。提供日誌求助時只保留錯誤階段與類型，刪除完整伺服器位址、使用者識別碼與訂閱內容。行動裝置問題常與背景限制及網路切換有關，因此排查時必須記錄「前景正常還是背景異常」與「無線網路正常還是行動網路異常」這兩個條件。

訂閱管理、協議參數與路由分流

訂閱負責分發設定，路由決定每一類流量從哪個出口離開。穩定設定的關鍵是區分服務端參數與本機策略，不要在錯誤的層級反覆修改。

訂閱更新的完整流程

用戶端更新訂閱時，會請求訂閱位址、讀取回傳內容、解析各個伺服器項目，再寫入本機分組。任何一層失敗都會顯示為「更新失敗」，但處理方式各不相同。請求階段逾時要檢查目前網路與訂閱位址的可達性；回傳空內容要檢查訂閱狀態；解析失敗要檢查編碼、格式與用戶端支援情況；寫入後清單為空則檢查分組篩選與過濾規則。可以依照訂閱連結失效或解析失敗六步自查逐層定位。

訂閱位址可能包含存取憑證，不應公開分享。不同裝置使用同一訂閱時，更新頻率應保持合理，避免短時間內連續重新整理。用戶端支援定時更新時，可以設定符合實際需求的週期，但不要將節點測速與訂閱更新混為一談。更新只會同步設定，測速才會主動存取伺服器。服務端移除項目後，下一次更新可能同步刪除，因此重要的手動設定應放在獨立分組。

協議與傳輸參數必須成組匹配

VMess、VLESS、Trojan 與 Shadowsocks 描述的是不同協議體系，WebSocket、gRPC、TCP 等屬於傳輸層，TLS 與 REALITY 則涉及安全交握與服務端身分參數。連線能否建立，取決於整組參數是否與服務端一致，而不是只要協議名稱相同即可。VLESS 設定常見欄位包括使用者識別碼、傳輸方式、安全類型、伺服器名稱與流控；Trojan 需要匹配密碼與 TLS 相關資訊；Shadowsocks 需要匹配加密方式與密碼。

由訂閱正常產生的設定通常不需要手動修改協議欄位。只有服務端明確提供修改說明時，才調整對應參數。將 WebSocket 路徑、gRPC 服務名稱、伺服器名稱或公鑰留空，都可能導致連線失敗。用戶端顯示的伺服器備註只用於識別，不參與交握；修改備註不會改變連線。協議選擇的橫向說明可參閱VMess、VLESS、Trojan、Shadowsocks 情境選型。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/vless"
        }
      }
    }
  ]
}

此片段用於說明欄位層級，範例網域與使用者識別碼不能直接用於連線。實際設定還需要與服務端匹配的 TLS 伺服器名稱、請求標頭或其他傳輸參數。圖形化用戶端通常會由訂閱自動產生完整結構，日常設定不必直接編輯 JSON。只有在閱讀日誌、核對欄位或遷移自訂規則時，才需要理解這些層級。

路由規則的匹配順序

路由通常依據網域、IP、連接埠、網路類型與程序資訊匹配出口。規則由上到下判斷時，越具體的規則應放在越前面，預設規則則放在最後。常見出口包括代理、直接連線與阻斷。區域網路與本機位址應直接連線；明確需要遠端出口的網域進入代理；不需要存取的遙測或惡意位址可以阻斷。規則未命中時會使用預設出口，因此預設值決定整體設定的方向。

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

IPIfNonMatch 表示網域規則未匹配時，再解析位址以進行 IP 規則判斷。這會增加 DNS 的參與程度，因此 DNS 設定必須穩定。若使用 AsIs，路由會更依賴原始網域規則，不會為了 IP 匹配而主動解析所有未命中的網域。不同核心與用戶端對可用策略名稱、規則集來源及更新機制可能有所差異，應以目前用戶端介面提供的選項為準。

全域、繞過與自訂規則怎麼選

全域模式適合短時間驗證伺服器是否可用，因為幾乎所有目標都會進入代理，變數最少。但它不適合作為所有環境的預設答案：區域網路裝置、本機開發位址與企業內部服務可能因此無法連線。繞過中國大陸類預設會依內建網域與位址規則分流，維護成本較低，但規則集需要隨用戶端更新。自訂路由適合有明確業務邊界的使用者，應從少量規則開始，每增加一條都記錄匹配目的與預期出口。

判斷路由是否生效不能只看網頁能否開啟。應在用戶端日誌中確認目標網域、匹配規則與最終出口。網域被應用程式提前解析成位址時，用戶端可能只能看到 IP；啟用嗅探後可以從部分連線還原網域資訊，但並非所有協議都能可靠識別。路由問題要同時考慮應用程式請求形式、DNS 回應與規則順序。保留一份預設路由設定，可以在自訂規則失效時快速回復。

系統代理、TUN與 DNS 協同

系統代理決定應用程式是否主動連線至本機連接埠，TUN 從網路層接管流量，DNS 決定網域如何取得位址。三者職責不同，但設定錯誤時都可能表現為「網頁無法開啟」。

系統代理適合哪些情境

系統代理設定成本低，適合瀏覽器與遵循作業系統代理介面的桌面程式。用戶端通常在本機監聽 HTTP、SOCKS 或混合連接埠，再將系統代理指向迴送位址。應用程式請求進入本機連接埠後，核心依路由選擇代理或直接連線出口。系統代理不會自動涵蓋所有程式：命令列工具、遊戲、背景服務與自行實作網路堆疊的應用程式可能忽略它。

啟用系統代理前應確認本機連接埠已在監聽。連接埠被其他程序佔用時，核心可能改用其他連接埠或直接啟動失敗，但系統仍指向舊連接埠。退出用戶端時應清除系統代理；異常退出後若全域斷網，第一步就是檢查殘留設定。系統代理只應指向 127.0.0.1 或用戶端明確允許的本機位址，不要將遠端伺服器位址直接填入系統代理設定。

TUN 為什麼涵蓋範圍更廣

TUN 會建立虛擬網路介面並接收系統路由送來的封包，因此能涵蓋不支援 HTTP 或 SOCKS 代理的程式。用戶端需要將封包轉換為核心可處理的連線，再依規則送往直接連線或代理出口。它通常需要更高權限，也更容易與其他虛擬網路、企業安全程式、虛擬機器與容器路由衝突。啟用 TUN 前，必須先驗證同一伺服器在系統代理模式下能正常連線。

TUN 設定至少涉及介面位址、路由注入、DNS 接管、MTU 與繞過範圍。MTU 過大可能導致部分網路交握成功但大型頁面載入失敗，過小則增加分片與負擔。預設值通常更適合多數網路，沒有證據時不應調整。若問題只發生在行動熱點、企業網路或某個寬頻環境，可逐步降低 MTU 進行驗證，但每次修改後都要重建連線並清除舊工作階段。

DNS 查詢在哪一層發生

應用程式可以將網域交給系統解析，也可以使用自身的加密 DNS。系統代理模式下，SOCKS 請求可能攜帶網域，也可能只攜帶應用程式已解析的 IP。TUN 模式通常透過 DNS 接管將查詢送入用戶端，以便路由規則使用網域資訊。若 DNS 直接連線而目標連線走代理，可能取得不適合目前出口的位址；若所有 DNS 都強制走遠端，又可能影響區域網路名稱與企業內部網域。

穩定方案通常將公共網域與內部網域分開處理：區域網路與企業網域交由本機 DNS，其他查詢則依路由策略選擇解析器。需要依網域分流時，應確保用戶端能看到網域，或使用嗅探補充資訊。嗅探不是解密應用程式內容，而是從連線交握中識別可見的目標名稱；面對加密程度較高或非標準流量時，識別結果可能有限。

FakeDNS 的適用界線

FakeDNS 會從保留位址池回傳虛擬 IP，並在用戶端內部儲存虛擬位址與原始網域的對應。應用程式之後連線至虛擬 IP 時，用戶端可以還原網域並提前執行網域路由。它適合 TUN 情境下需要穩定依網域分流、又無法直接從連線取得網域的情況。工作原理與組合方式可參閱FakeDNS 原理與適用情境。

FakeDNS 不適合不經用戶端處理的流量，也可能影響依賴真實位址的診斷工具、區域網路探索與某些應用程式的位址驗證。開啟後若系統顯示保留網段位址，這是預期結果，不能據此判斷 DNS 遭到竄改。真正需要檢查的是虛擬位址連線是否被用戶端接收、對應是否存在，以及最終出口能否解析並連線至真實目標。關閉 FakeDNS 時應重新啟動受影響的應用程式，必要時重新整理系統 DNS 快取，避免舊虛擬位址繼續殘留。

建議的漸進式設定方法

1. 先用系統代理驗證節點確認訂閱、協議、TLS 與遠端連線沒有基礎錯誤。
2. 保持預設 DNS 驗證網域檢查一般網頁、區域網路位址與目標應用程式的基本行為。
3. 單獨啟用 TUN暫不加入複雜路由，觀察虛擬介面、預設路由與應用程式涵蓋範圍。
4. 加入私有位址直連恢復路由器、印表機、網路儲存與內部服務的存取。
5. 最後調整 DNS 與 FakeDNS每次只變更一項，並透過日誌確認網域、位址與出口的對應關係。

判斷設定是否完成，應涵蓋四類測試：一般網頁能否載入、區域網路資源能否直接連線、不讀取系統代理的目標程式能否依預期進入 TUN，以及退出用戶端後直接連線網路能否恢復。只通過其中一項，並不能證明整體路徑正確。對複雜網路保留一份「系統代理、預設 DNS、預設路由」的基礎設定，再單獨儲存 TUN 設定，切換環境時比反覆手動修改參數更可靠。

設定常見問題與分層排錯

排錯應沿著資料路徑由外而內進行：系統網路、用戶端入口、核心啟動、訂閱參數、遠端連線、DNS 與路由。每一步都要有可觀察的結果。

第一層：確認直接連線網路與系統狀態

先停止用戶端接管，關閉 TUN，清除系統代理，確認裝置在目前網路下可以直接瀏覽一般網站。若直接連線本身失敗，應先處理無線網路驗證、行動數據、路由器、系統時間或 DNS，而不是修改伺服器設定。公共網路可能要求開啟驗證頁面；企業網路可能限制未知連接埠；休眠復原後網卡可能沒有正確取得位址。只有直接連線基準正常，後續測試才有意義。

同時確認沒有其他代理用戶端、虛擬網路程式或殘留環境變數。Windows 檢查系統代理與本機監聽，macOS 檢查目前網路服務與終端機變數，Linux 檢查桌面代理、環境變數與策略路由，Android 檢查系統連線狀態與背景限制。若關閉 v2rayN 或 v2rayNG 後網路仍被接管，表示系統層存在殘留，應先恢復再繼續。

第二層：確認用戶端與核心真正啟動

視窗能夠開啟不代表核心已經執行。選擇伺服器後查看狀態區與日誌，確認設定產生成功、本機連接埠開始監聽，且沒有立即退出。設定解析錯誤通常會明確指出欄位、協議或 JSON 位置；連接埠佔用會顯示監聽失敗；權限問題常出現在 TUN 介面或網路延伸功能的建立階段。先處理日誌中的第一個關鍵錯誤，後續錯誤往往只是前一個錯誤的連鎖結果。

若本機連接埠沒有監聽，系統代理即使指向該連接埠也不會產生有效連線。修改連接埠後要同步更新系統代理、瀏覽器設定與終端機環境變數。多個用戶端同時啟動時，後啟動者可能無法佔用預設連接埠。退出所有執行個體、確認連接埠已釋放，再只啟動目標用戶端，是排除爭用最直接的方法。

第三層：區分訂閱失敗與伺服器失敗

訂閱更新成功只表示設定能夠取得與解析，不代表其中每部伺服器都可用。反過來，訂閱更新失敗也不一定影響已儲存的舊伺服器。排查時記錄兩個獨立結果：訂閱位址能否更新，現有伺服器能否建立連線。若所有項目同時失敗，優先檢查目前網路、訂閱統一變更、用戶端核心或 DNS；若只有一個項目失敗，更可能是該伺服器參數或遠端狀態問題。

手動檢查設定時，重點核對位址、連接埠、使用者識別碼、協議、傳輸方式、TLS 安全類型、伺服器名稱、路徑與服務名稱。不要隨機替換協議或關閉 TLS 來碰運氣，這會讓設定與服務端進一步偏離。服務端提供新訂閱後，應重新更新並用新項目測試，而不是在舊項目上不斷累積修改。

第四層：根據日誌階段判斷方向

「連線逾時」不能直接證明伺服器不可用，因為目前網路、DNS 回應、IPv6 路徑與防火牆都可能造成相同結果。最有效的交叉測試是保持伺服器不變、改用其他網路，再保持網路不變、改用其他伺服器。如果同一伺服器在另一個網路正常，問題偏向目前的網路路徑；如果同一網路下其他伺服器正常，問題偏向該項目或遠端。每次測試只改變一個變數，結論才可靠。

第五層：處理能連線但無法正常使用

用戶端顯示已連線，但網頁無法開啟時，先確認應用程式請求是否進入日誌。完全沒有請求，檢查系統代理、分應用程式代理或 TUN 路由；有請求但 DNS 失敗，還原預設 DNS；網域解析成功但遠端連線逾時，檢查伺服器與網路；部分網站失敗，檢查 IPv6、MTU、路由規則與目標位址選擇。只有瀏覽器失敗時，還要檢查瀏覽器內建代理、私有 DNS、擴充功能設定與快取。

網頁可以開啟但速度異常時，不要只依賴節點清單中的回應時間。實際速度會同時受到伺服器負載、線路、目標網站、傳輸方式與目前網路影響。關閉批次測速、下載工作與其他佔用頻寬的程式，以同一個目標進行對照。Mux 並非在所有環境都能提升效能，行動網路或不穩定鏈路下可能放大單一連線故障；若持續卡頓，可還原預設值後重新測試。

第六層：復原、遷移與提交有效日誌

複雜設定無法確認問題來源時，先匯出需要保留的訂閱位址與自訂規則，然後建立最小設定：一個訂閱、一部伺服器、預設 DNS、預設路由與系統代理。最小設定成功後，依路由、TUN、DNS、FakeDNS、分應用程式代理的順序逐項恢復。若某一步再次出現問題，就能將範圍鎖定在該設定，而不是直接重新安裝用戶端。

跨裝置遷移時不要複製執行中的快取、鎖定檔案與暫存設定。優先遷移訂閱位址、獨立的手動伺服器、路由規則說明與必要的 DNS 選擇。不同平台對權限、路徑與網路介面的處理方式不同，完整複製設定目錄可能帶入無效路徑或平台專屬狀態。遷移後依各平台章節重新完成系統代理或 TUN 授權。

向他人提供日誌時，應說明平台、用戶端名稱、使用系統代理還是 TUN、問題發生在安裝後還是設定變更後、直接連線是否正常，以及最早出現的關鍵錯誤。刪除訂閱位址、完整伺服器網域、使用者識別碼、密碼、路徑中的個人目錄名稱與可識別的網路資訊。不要只提供「無法使用」的結論；可重現的步驟與分層結果比一大段完整日誌更有價值。

• 安裝包與平台、處理器架構及套件體系一致。
• 訂閱更新與伺服器連線分別記錄結果，不要混為同一個問題。
• 系統代理、TUN、應用程式內代理只保留目前需要的一套入口。
• 區域網路與內部服務具有明確的直連規則。
• 日誌已隱藏訂閱、使用者識別碼與伺服器敏感資訊。