V2Ray 設定完整指南

一、核心概念與連線流程

用戶端、核心與伺服器各自負責什麼

設定 V2Ray 前，先了解三個層次：圖形化用戶端負責儲存伺服器資訊、管理訂閱及顯示設定；核心負責接收流量、比對規則並建立連線；遠端伺服器則提供實際的對外連線能力。安裝用戶端只完成本機準備，並不會自動取得可連線的伺服器。桌面平台建議使用 v2rayN；行動裝置可選擇 v2rayNG 或 v2flyNG，選擇方式請見下一章。

Project V 是相關代理技術的生態背景，V2Fly 延續 V2Ray 的開發，Xray 則是同一技術生態中的另一種核心。用戶端名稱與核心名稱並非一一對應，也不能只憑名稱判斷是否支援所有協定。匯入設定後，請確認用戶端使用的核心、支援的欄位及伺服器需求；圖形介面能顯示某項設定，不代表核心一定能執行。

分開理解協定、傳輸方式與安全參數

協定描述用戶端與伺服器如何組織通訊，常見的有 VMess、VLESS、Trojan 和 Shadowsocks。傳輸方式則描述資料如何傳送，例如 TCP、WebSocket 或 gRPC。TLS 和 REALITY 涉及連線安全握手。分享連結通常會將多層參數一併編碼，因此看似一串網址，實際上包含連接埠、識別資訊、傳輸方式與安全設定。

VLESS 本身並非完整的加密傳輸方案，是否使用 TLS 或 REALITY，應依伺服器設定判斷。REALITY 也不是與 VLESS 並列的代理協定。手動新增時，伺服器位址、連接埠、使用者識別碼、傳輸類型與伺服器名稱等欄位必須互相吻合。即使兩台伺服器都使用 VLESS，也不能互換它們的公鑰、短識別碼或路徑。

先建立可重現的基本連線

常見的連線流程如下：瀏覽器讀取系統代理設定，將要求送到本機的入站連接埠；核心依路由規則選擇代理出站，再連線至遠端伺服器。其他應用程式可能不理會系統代理，TUN 則提供另一種流量入口。「流量進入用戶端」與「從哪個出站離開」是兩回事；之後調整模式時，請沿著這條流程逐步檢查，以免把入口問題誤判成伺服器故障。

第一次測試時，只保留一筆來源明確的伺服器設定，暫時使用用戶端的基本路由方案，不啟用複雜的自訂規則。確認系統時間正確，關閉重複執行的代理程序，再啟動核心並連線至明確的測試目標。記下連線成功時使用的模式與日誌摘要，之後才能與基準狀態比較。單次速度測試不能取代實際應用程式的連線測試，也不代表所有傳輸類型都正常。

排錯時由近到遠逐層檢查：本機入站是否啟動、應用程式是否使用該入口、規則選擇了哪個出站，以及遠端連線是否成功。日誌中的啟動失敗、握手失敗與要求逾時，分別代表不同階段。先確認故障所在層級，再調整相應設定；反覆重新安裝用戶端，通常無法解決網址失效或伺服器參數不符的問題。

二、依平台與核心選擇用戶端

桌面平台優先選擇 v2rayN

Windows、macOS 與 Linux 桌面用戶，建議從 v2rayN 開始使用，方便沿用本指南中的訂閱分組、伺服器、參數、路由及 DNS 設定等概念。選擇前先確認作業系統、處理器架構與套件格式，不要只看檔案大小。用戶端免費且開源，但不同發行套件的執行相依項目與系統整合方式仍有差異，安裝前請閱讀相應平台的說明。

Windows 下載頁提供 Desktop 桌面版與經典 WPF 版兩種選擇。Desktop 採用跨平台介面，適合希望在不同桌面系統維持相近操作習慣的使用者；WPF 則是 Windows 經典介面。兩者是不同的介面版本，不是不同協定，也不代表 Desktop 的伺服器速度一定較快。先選一種完成設定；排錯時不建議同時執行兩種介面，以免互相搶用系統代理。

行動裝置應依設定相容性選擇

Android 首選 v2rayNG，採用 Xray 核心；v2flyNG 則是採用 V2Fly 核心的替代選擇。兩者的基本操作都包括匯入設定、選擇伺服器與啟動連線，但協定實作與欄位支援並不完全相同。特別是含有 REALITY 或特定傳輸參數的設定，請先確認所選核心是否支援，不要只因為連結能解析就判定相容。

多數較新的 Android 裝置通常選擇 arm64 套件，但不能只憑購買年份判斷架構。有些裝置硬體支援 64 位元，系統環境卻可能不同；不確定時，請查閱裝置資訊或使用通用版。通用版支援多種架構，但檔案可能較大。安裝失敗時，先檢查架構、系統需求與是否已有簽章不同的舊版本，再考慮更換用戶端。

切換核心不能取代伺服器參數檢查

v2rayN 可依發行套件與功能支援選擇不同核心，常見選項包括 Xray 和 sing-box。切換前，請確認目標核心能處理目前的設定，尤其是路由、DNS 與 TUN。不同核心不一定共用所有 JSON 欄位，用戶端的圖形化選項也可能需要轉換。不要將某個核心的完整設定直接貼到另一個核心的自訂設定欄位。

建立基本連線時，優先使用用戶端針對該伺服器類型提供的標準核心選項。遇到明確的相容性問題或需要特定功能時，再嘗試其他核心。切換後重新啟動連線，檢查實際產生的設定與日誌，確認代理入口、規則和 DNS 沒有恢復成預設值。介面仍顯示同一個伺服器名稱，不代表實際連線流程完全沒有改變。

在多部裝置上使用時，重點是了解各項參數的用途，不必強求每個按鈕名稱完全一致。桌面平台可透過系統代理連接瀏覽器；Android 通常透過系統 VPN 介面接收應用程式流量，兩種作業系統的授權與限制各不相同。下載版本請見下載中心；Desktop 與 WPF 的介面差異可參閱桌面版與 WPF 版的差異，選定版本後再開始安裝。

三、安裝與首次啟動檢查

安裝前確認架構、資料夾與舊設定

安裝的目標是建立可正常啟動核心、儲存設定並取得必要權限的用戶端環境。先關閉已開啟的用戶端，備份需要保留的伺服器與路由設定，再從下載中心選擇合適的套件。桌面版設定資料夾必須允許目前使用者寫入；若使用壓縮檔格式，請先完整解壓縮再執行，不要直接從壓縮軟體中暫時開啟主程式。

不要同時進行搬移與首次安裝。先啟動新環境，確認視窗與基本設定都能正常儲存，再匯入舊設定。直接覆蓋整個舊資料夾，可能一併帶入過時的核心檔案、連接埠設定或自訂參數。若程式檔案由安裝程式管理，請依安裝程式的流程操作；若使用獨立資料夾，請維持其中檔案的完整對應關係，避免混用不同來源的核心與介面檔案。

Windows 與 macOS 首次啟動

Windows 使用者先啟動 v2rayN，確認是否出現缺少執行相依項目或核心啟動失敗的提示。若提示缺少相依項目，請依該發行套件的說明處理，不要用系統管理員權限掩蓋檔案缺漏。一般系統代理通常不需要長期以系統管理員身分執行；TUN 或系統層級的網路設定則可能需要提升權限。權限、相依項目與連接埠占用是三種不同問題，請分別確認。

macOS 使用者先在「關於這台 Mac」確認晶片類型，再選擇 Apple Silicon 或 Intel 套件。依安裝流程將 App 移至一般應用程式資料夾，再首次開啟。若系統阻擋未經驗證開發者提供的 App，請先確認下載來源，再前往「系統設定 → 隱私權與安全性」查看是否有允許該 App 的選項；不應為了安裝單一用戶端而關閉整體系統安全機制。

授權成功後，仍需確認系統是否允許相關網路操作。App 能開啟，不代表修改系統代理或啟動虛擬網卡也已取得權限。請依提示允許必要操作，修改後重新啟動連線。「App 已損毀」也不一定是權限問題；請先重新下載符合架構的安裝套件，並確認安裝流程。其他處理方式請參閱macOS 安裝與權限設定。

Linux 與 Android 的安裝注意事項

Linux 使用者請依發行版的套件管理系統選擇 deb 或 rpm，再確認 x64 或 arm64 架構。建議使用系統套件管理工具安裝，讓相依項目與程式檔案依正常流程安裝。桌面工作階段、權限提升工具及系統代理整合方式可能因環境而異；若程式視窗正常，但系統代理無效，可先在單一應用程式中明確設定本機代理，以區分介面啟動與系統整合問題。

在 Android 安裝 v2rayNG 或 v2flyNG 時，系統可能會要求允許目前的下載或檔案管理 App 安裝應用程式；授權範圍應限於目前操作。若無法覆蓋安裝，先檢查套件架構或簽章是否不同，備份後再決定是否解除安裝。首次啟動連線時通常會跳出系統 VPN 授權提示，確認後才會建立應用程式流量入口；連線穩定後，再另外檢查背景電池限制。

第一次關閉前，先確認系統代理設定是否已清除。部分用戶端關閉視窗後只會縮至系統匣，核心仍在執行；另一些用戶端則會結束程序，但發生異常時可能無法還原代理設定。重新開啟用戶端確認實際狀態，並記下本機入站連接埠。之後排錯時，可透過連接埠確認應用程式是否連到正確入口，不要只靠記憶推測預設連接埠。

四、匯入訂閱與管理伺服器

分辨訂閱網址與分享連結

訂閱網址用來批次取得及更新伺服器設定；分享連結通常描述單一伺服器。兩者都可能是一長串文字，但匯入位置不同。取得設定後，先確認提供者給的是哪一種；不要把網頁介紹網址當成訂閱，也不要把單一 VLESS 分享連結貼進訂閱下載欄位。QR Code 只是文字的載體，掃描後仍須判斷內容是訂閱還是單筆設定。

在 v2rayN 中開啟訂閱分組，新增分組名稱與訂閱網址，儲存後執行更新；分組名稱建議依來源或用途命名，不要用來描述連線品質。v2rayNG 與 v2flyNG 則使用訂閱設定或相應的匯入選單，儲存後更新設定。選單名稱可能略有不同，但操作順序一致：建立來源、取得設定、檢查匯入結果，再選擇目前要使用的伺服器。

更新後檢查欄位，不要只看清單

更新完成後，確認伺服器已出現在預期分組，再檢查協定、位址、連接埠、傳輸方式與安全參數。清單中的備註僅供辨識，不能證明連線可用。訂閱更新有時會取代原有項目，先前選用的伺服器可能失效或移至其他位置；更新後請重新確認目前選取的項目，避免用戶端仍使用已刪除或不適用於目前核心的設定。

分享連結可透過「從剪貼簿匯入」功能新增。複製時請保留完整字串，避免通訊軟體截掉末尾參數，或一併複製說明文字。手動新增適合清楚了解各欄位用途的情況；若已有完整分享連結，建議先匯入再逐項檢查，以免漏填路徑、伺服器名稱、公鑰或短識別碼等欄位。

訂閱與單筆設定都應妥善保護。網址中的權杖、使用者識別碼與驗證欄位，可能讓他人讀取或使用服務，不應出現在公開截圖、日誌貼文或範例程式碼中。提供資料給排錯人員時，只保留欄位名稱與錯誤訊息，遮蔽真實網址及身分資訊。若訂閱外洩，請向服務提供者重新產生或撤銷訂閱，而不是只從用戶端刪除該項目。

訂閱更新失敗時，分別檢查取得、解析與執行三個階段

第一階段是取得失敗：訂閱網域能否解析、網址是否過期、系統時間是否正確，以及回應內容是否被登入頁面取代。第二階段是解析失敗：文字格式、編碼或協定類型是否受目前用戶端支援。第三階段是執行失敗：項目已匯入，但核心不支援某個欄位，或伺服器無法連線。這三類問題的處理方式不同，不能一概歸因於「訂閱壞了」。

第一次匯入時，可嘗試「更新訂閱（不透過代理）」，避免訂閱更新依賴尚未建立的代理連線。若訂閱網址確實必須透過代理存取，請先保留另一台可用伺服器，再選擇透過代理更新。並非所有網址都適用同一種選項；關鍵在於更新要求不能依賴即將被取代、已失效或指回自身的連線。

建議依來源分組管理多個訂閱，避免頻繁混合複製項目而失去來源資訊。自動更新前，請確認是否會覆蓋手動編輯的備註或參數。若更新持續失敗，先保留一份可用設定並暫停自動更新，再依訂閱更新失敗的自我檢查步驟確認回應內容與更新方式。完成這個階段後再設定代理入口，排錯範圍會更明確。

五、系統代理模式與應用程式入口

代理模式控制入口，不決定所有出站流量

系統代理模式決定作業系統如何向應用程式提供代理設定；路由規則則決定進入核心的要求要直連還是走代理。啟用「自動設定系統代理」後，瀏覽器可能開始使用本機入口，但要求仍可能依路由規則選擇直連。因此，「系統代理已啟用」不等於「所有流量都經由伺服器轉送」；測試時請分別確認應用程式入口與實際出站。

v2rayN 常見選項包括清除系統代理、自動設定系統代理，以及不變更系統代理。清除會移除目前的系統代理設定；自動設定會寫入用戶端的本機位址與連接埠；不變更則保留作業系統目前的設定。最後一項不會自動清除殘留連接埠；若系統仍指向已關閉的另一個用戶端，應用程式仍可能無法連線。

分開測試應用程式代理與系統代理

並非所有應用程式都會讀取系統代理。有些應用程式提供獨立的 HTTP 或 SOCKS 設定，有些只會在啟動時讀取環境設定；修改系統設定後，可能需要重新啟動應用程式。先選擇一個明確支援系統代理的瀏覽器進行測試，並排除擴充功能或應用程式內設定的影響。之後再測試其他程式，就能分辨是「用戶端連線失敗」還是「該程式沒有連進用戶端」。

在應用程式中手動設定代理時，位址通常填本機迴圈位址，連接埠以用戶端實際顯示為準，代理類型必須與監聽入口一致。HTTP 與 SOCKS 入口並非只有名稱不同，選錯類型可能直接造成握手失敗。若入站只監聽迴圈位址，其他裝置便無法直接使用；不要為了方便而任意開放所有網卡，否則本機代理的可存取範圍也會擴大。

本指南不指定預設連接埠，因為既有設定、用戶端發行套件與使用者修改都可能改變連接埠。若日誌顯示位址已被占用，先關閉其他代理程序，確認是否重複啟動，再決定是否更改連接埠。變更後，必須同步更新系統代理或應用程式內的設定。只改用戶端設定，卻保留瀏覽器的舊連接埠，是常見的「核心已正常啟動，但網頁打不開」原因。

確認連線成功並保留故障現場

完成自動設定後啟動連線，瀏覽明確的測試目標，並查看相近時間的日誌。先確認連線是否建立，不要立即比較速度；測試功能可能測量不同目標與階段，顯示結果不能直接代表網站的實際連線品質。若用戶端提供要求或路由日誌，請確認目標要求是否出現，以及出現後選擇了哪個出站，以縮小排查範圍。

若沒有要求進入核心，優先檢查應用程式的代理設定、系統設定與本機連接埠。若要求已進入但遠端握手失敗，請回頭檢查伺服器參數與核心相容性。若握手成功但目標仍無法存取，再檢查 DNS、路由或目標服務。依照這個順序排查，比逐一切換所有模式更有效，也能保留足夠資訊，說明問題發生在哪個階段。

Android 的連線入口通常透過系統 VPN 介面建立，不應照搬桌面版的系統代理選單。系統授權、應用程式範圍與背景限制都需要在行動裝置上個別確認。先讓一個應用程式在前景正常連線，再測試鎖定螢幕與切換網路；入口穩定後再進入下一章調整路由，避免把應用程式未接入誤判為規則問題。

六、路由分流與 DNS 設定

規則比對順序

路由分流的目標是依據明確條件選擇出站，而不是盡可能堆疊規則。常見方案包括繞過中國大陸（Whitelist）、黑名單（Blacklist）與全域（Global），實際預設規則會因用戶端設定而異。方案名稱只能作為辨識參考，實際行為取決於規則內容、排列順序與未命中時的預設出站；使用前請查看實際設定，不要只憑標籤判斷。

多數規則會依序比對，先符合的條件可能影響後續規則是否生效。區域網路與私有位址通常應明確設定為直連；特定服務網域應排在通用規則之前，範圍較廣的預設規則則放在後面。若某個網域總是走錯出站，先檢查它是否已符合前面的網域、位址或連接埠條件；在清單末尾新增規則，不一定會改變結果。

網域規則與位址規則的比對條件

geosite:cn 是網域集合的參照，geoip:private 是私有位址集合的參照；核心必須能讀取相應的資源檔。網域規則需要保留要求中的網域資訊，位址規則則依目標 IP 位址判斷。若應用程式先在本機完成 DNS 解析，只將 IP 傳給入口，網域比對可能受到限制；流量嗅探可在部分情況下補上網域資訊，但無法識別所有協定。

DNS 設定也會影響連線流程：由誰發起解析、解析要求走哪個出站、回傳什麼位址，都會影響路由與連線。不要只為了更換解析結果，同時啟用多組互相重疊的 DNS 功能。先釐清本機應用程式 DNS 與核心 DNS 各自負責什麼，再檢查直連解析與代理解析是否使用同一個上游，造成循環依賴。

在既有設定中新增容易理解的規則

以下是 Xray／V2Ray 格式的路由片段，用來說明私有位址與網域集合直連的用途。這不是完整的用戶端設定；既有出站中必須有 direct 標籤，也需要相應的地理資料檔。使用圖形介面的用戶端，請優先在路由設定中建立等效規則；使用其他核心時，必須依該核心的規則格式重新撰寫。

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

AsIs 表示路由階段不會只為了比對位址而主動解析網域，不代表連線階段完全不使用 DNS。不同的網域策略會影響解析時機，以及何時比對位址規則；變更策略後，原本未命中的位址條件可能開始生效。初學時請保留基本方案，確認缺少哪類比對資訊後再調整，不要把特定策略名稱當成固定的效能最佳化選項。

自訂規則應先以單一明確網域測試，指定要直連或走代理，並觀察日誌確認是否命中，再逐步擴大到網域集合。測試區域網路裝置時，也要同時檢查私有位址、區域網路網域，以及應用程式是否由 TUN 接管。只將私有 IP 設為直連，不一定能解決區域網路網域解析失敗；路由與 DNS 必須分開驗證。

更新規則資源後，結果可能改變；手動規則也可能與訂閱或預設範本衝突。每次修改前後都應留存設定內容，並記錄測試目標與命中的出站；發生故障時，先還原最近一次變更。複雜設定應能回答「這條規則比對什麼、為什麼放在這裡、未命中時怎麼處理」，否則維護成本會不斷增加。

七、TUN 虛擬網卡與流量接管範圍

從應用程式代理擴展至網路入口

TUN 透過虛擬網路介面接收 IP 層流量，適合需要接管不讀取系統代理之應用程式的情況。它能擴大流量入口的涵蓋範圍，卻不會自動修復失效的伺服器，也不保證所有應用程式協定都能正常使用。啟用前，必須先有一條正常的基本連線並了解現有路由方案；否則入口、DNS 與伺服器同時出問題，日誌會更難判讀。

桌面平台的 TUN 通常需要建立虛擬介面並修改系統路由，因此可能需要提升權限或安裝相應網路元件。v2rayN 中的「啟用 Tun 模式」只是操作入口，實際行為仍取決於核心、平台與相關設定。請先確認目前環境支援此功能，再依用戶端提示操作。核心尚未啟動或相依項目缺失時，不要反覆切換系統路由。

檢查迴圈連線、區域網路與其他隧道

啟用前先關閉其他會變更路由的代理或 VPN 程式，避免多個入口搶用預設路由與 DNS。系統中有多張虛擬網卡不一定代表故障，但必須確認目前是哪一張在接收流量。啟用後先確認用戶端日誌記錄介面建立成功，再測試一個應用程式，最後檢查區域網路裝置與一般直連目標；不要只看介面上的開關狀態。

連線至遠端伺服器的底層流量應避免再次送回 TUN 入口，否則可能形成迴圈。用戶端與核心通常提供自動路由、介面選擇或略過設定，但多張網卡、網路共享與自訂路由都可能改變原本條件。若日誌持續重複連線但始終無法建立，先關閉 TUN，恢復系統代理的基準狀態，再檢查出口網卡與伺服器位址的實際路由。

存取區域網路時，私有位址與名稱解析都要正常。無法連線至印表機、路由器管理頁面或網路儲存裝置時，先用明確的區域網路 IP 測試，再改用裝置名稱。前者失敗通常與路由或防火牆有關；只有後者失敗時，則較可能是 DNS 問題。不要以新增範圍過廣的代理規則來處理所有區域網路故障，以免原本應在本機完成的要求繞送到遠端。

DNS、UDP 與切換網路的檢查順序

TUN 設定常會搭配 DNS 接管，但 DNS 接管不能取代完整的解析策略。先確認系統查詢會送往何處、核心如何解析遠端伺服器，以及 DNS 上游是否又依賴代理連線。若伺服器位址解析依賴尚未建立的隧道，可能造成啟動死結。設定時應保留一條可完成初始連線的解析路徑，不要盲目將所有 DNS 都交給同一個出站。

瀏覽器能正常開啟網頁，不代表 UDP 或其他應用程式流量都正常。語音、即時通訊及其他應用程式，應依各自使用的協定測試，並確認伺服器與傳輸方式支援所需流量。測試失敗時，檢查流量是否進入核心、是否命中正確的出站，以及是否遭系統防火牆攔截。不要因為啟用 TUN，就認定所有應用程式都會自動獲得相同的連線效果。

裝置從有線網路切換至無線網路、從睡眠中喚醒或更換基地台後，出口介面與 DNS 都可能改變。先重新啟動連線再測試，不要立刻重寫所有規則。Android 也應檢查系統 VPN 狀態、背景執行限制與應用程式接管範圍。只有前景、背景與切換網路三種情況都得到明確結果，才能判斷這套入口方案是否適合日常使用。

八、日常維護與分層排錯

維護可用基準設定與必要備份

日常維護時，優先保留一份已驗證可用的設定，包含用戶端版本、使用的核心、訂閱分組、代理模式、路由方案及必要的 DNS 設定。備份只需包含復原所需資訊，不要將所有日誌長期混在設定檔中。匯出檔可能含有訂閱憑據與伺服器身分資訊，請存放在安全的位置；搬移時也應避免公開同步或誤傳。

訂閱更新、用戶端更新、切換核心與更新規則資源，應盡量分開進行。一次只變更一項，重新啟動連線並測試常用目標後，再進行下一步。如果同時更新所有項目，故障發生時很難判斷原因是伺服器設定變動、參數轉換、規則比對或程式相依項目。維護紀錄不必使用複雜表格，但至少要記下變更內容、原因與復原方式。

依故障階段閱讀日誌

核心啟動失敗時，先檢查設定語法、欄位相容性、資源檔與連接埠占用；核心正常啟動但應用程式沒有要求進來，則檢查入口；要求進入後連線逾時，再檢查伺服器位址、網路與出站；握手錯誤則核對身分資訊、TLS 或 REALITY 參數。日誌錯誤文字只是線索，必須對照操作時間判讀，不要把舊連線的錯誤當成目前設定的結論。

需要收集日誌時，可暫時提高詳細程度，重現一次明確操作後，再恢復日常等級。過多日誌可能占用儲存空間，也可能記錄目標網域、位址或帳戶欄位。提交排錯資料前，請移除憑據與無關要求，只保留用戶端環境、錯誤時間、操作步驟及相關日誌。問題描述越具體，越容易得到可驗證的建議。

固定檢查系統時間、連接埠與網路環境

系統時間錯誤可能影響憑證判斷與部分協定的驗證流程；裝置長時間離線、從睡眠中喚醒或關閉自動校時後，尤其值得確認。連接埠衝突通常與重複程序或其他代理程式有關，請先正常退出後再試；若更改連接埠，必須同步更新應用程式設定。網路環境變更時，則要確認新的 DNS、出口介面，以及是否需要先完成入口網站登入。

若同一份設定在一個網路正常、另一個網路異常，請保持用戶端設定不變進行對照測試。先檢查該網路的一般連線與 DNS 解析，再觀察連線在哪個階段失敗。不同目標的結果不一致時，不應立刻推斷所有伺服器都已失效；同樣地，單一伺服器失敗也不代表需要重新安裝用戶端。固定比較條件，才能將差異歸因於正確的層級。

更新後要回復舊版時，應優先還原設定與相容的執行環境，而非只替換單一主程式檔案。新版設定格式可能無法讓舊介面完整讀取，搬移前先保留獨立備份會比較穩妥。Android 解除安裝可能會刪除應用程式資料；桌面版解除安裝也不保證保留設定資料夾。操作前請確認匯出檔可正常讀取，並妥善保護其中的敏感資訊。

常見問題可先查閱常見問題；需要快速重建基本連線流程時，請回到使用指南。維護重點是減少不確定的變更，而不是讓所有設定永遠保持最新；能夠理解目前設定、穩定重現問題並可靠復原，才是繼續深入設定的基礎。

九、進階設定學習路線

先閱讀產生的設定，再撰寫自訂設定

進階學習的第一步，是了解用戶端已產生哪些設定，而不是立刻從空白檔案開始建構整套設定。先在本機查看目前執行設定中的入站、出站、路由與 DNS 關係，確認圖形化設定如何轉換成各欄位。請注意，產生的檔案可能會在下次啟動時遭覆寫；應透過用戶端支援的設定入口進行修改，不要將直接編輯暫存檔當成長期維護方式。

閱讀設定時，先追蹤各個標籤：哪個入站接收應用程式要求、規則指向哪個出站、預設出站又是什麼。接著查看傳輸方式與安全參數，最後再處理 DNS 和特殊功能。一次只追蹤一筆要求的路徑，就能確認某個欄位是否真的影響目前連線。沒有被引用的出站或沒有命中的規則，不會只因為出現在檔案中就自動生效。

透過最小規則實驗理解比對方式

先新增一條範圍明確的網域規則，確認命中後再擴大到網域集合。以下片段會將 example.com 及其子網域交給名為 direct 的出站；此範例只用於測試規則，不代表該網域在所有環境中都應直連。片段必須加入既有的 Xray／V2Ray 格式路由規則陣列中，且必須存在相應的出站標籤。

{
  "type": "field",
  "domain": ["domain:example.com"],
  "outboundTag": "direct"
}

實驗前先記錄原有規則順序；實驗後確認目標網域是否進入核心、是否保留網域資訊，以及是否選中指定出站。若沒有命中，先檢查前面的規則與入口資訊，再調整 DNS 或嗅探。先釐清失敗原因再新增條件，才能避免最後得到一組只在某次啟動時偶然生效、卻無法解釋原因的設定。

依需求研究 DNS 與 FakeDNS

FakeDNS 使用保留位址池中的 IP 位址代表網域，並維護兩者的對應關係，後續流量再透過對應資訊還原目標。它常與 TUN 及網域分流搭配使用，不是一般公共 DNS 位址，也不適用於所有情況。應用程式快取、區域網路解析或入口接管不完整，都可能造成異常。啟用前，請先了解位址如何回傳、核心如何接收，以及何時轉換為實際連線。

研究此功能前，應先能分別測試一般 DNS、TUN 與網域路由。啟用後，請測試網域連線、直接 IP 連線、區域網路裝置，以及關閉功能後是否能復原；尤其要留意應用程式是否快取先前取得的位址。原理與適用範圍請參閱FakeDNS 原理與 TUN 搭配方式；不要把它當成連線失敗時的萬用修復開關。

將進階設定整理成容易維護的方案

自訂設定、複雜路由與不同核心之間的規則轉換，應先在獨立設定中測試，並保留原本的日常方案。每項功能都應註明用途、輸入條件、相依資源及復原方式。例如，網域規則需要應用程式保留網域資訊；某些 TUN 設定需要相應權限與出口介面；特定解析方案則依賴代理連線先建立。了解這些前提，比複製一長串參數更重要。

評估效能時也要控制變因。固定網路、伺服器與測試目標，分別觀察連線建立、網頁載入與應用程式實際使用情形，不要將短時間的測試結果套用到所有情境。日誌詳細程度、同時執行的應用程式與 DNS 快取都會影響觀察結果。只有測試結果穩定重現，且能解釋變更如何影響連線流程，才值得將實驗設定納入日常方案。

可依本頁順序反覆練習：先確認安裝與訂閱無誤，再檢查應用程式入口，接著驗證路由與 DNS，最後再擴展至 TUN 和自訂功能。若仍不熟悉基礎概念，可閱讀V2Ray 新手入門十問補足術語，再回到相關章節操作。保留簡潔且容易理解的設定，比長期依賴一整套看不懂的參數更容易維護。