V2Ray 系統教學：
從核心概念到日常維護

核心概念：用戶端、核心與連線路徑

介面設定與實際運作

開始設定前，先分清圖形用戶端、代理核心和遠端服務這三者。用戶端負責顯示節點、儲存訂閱、產生設定並管理系統整合；核心讀取設定、接收本機請求，並依路由選擇出口；遠端服務則接收協定連線，繼續處理目標連線。介面能開啟，只代表用戶端程式正在執行，不能據此判定核心已啟動，也無法證明遠端參數正確。

Project V 是認識這套生態系的起點，V2Fly 與 Xray 則是相關的核心家族。v2rayN、v2rayNG、v2flyNG 都是圖形用戶端，不是協定名稱。用戶端支援哪些欄位，取決於介面實作，也取決於實際呼叫的核心功能。若訂閱匯入成功卻無法啟動，應查看目前使用的核心和產生的設定，不要只憑用戶端名稱推斷所有功能都可用。

入口、路由與出口

一次連線可拆解為入口、路由和出口。入口接收瀏覽器或其他應用程式送來的流量，常見形式是本機 HTTP 或 SOCKS 監聽。路由依目標網域、位址、連接埠等條件選擇出口。出口可能是代理、直連或封鎖。遠端連線失敗與本機入口未收到請求，是兩類不同問題；前者檢查節點與網路，後者先確認應用程式是否使用了對應入口。

設定中的標籤用來連結這些模組，不是可以任意新增的備註。規則指定某個出口標籤時，出口清單必須有同名項目，大小寫也要一致。用戶端介面可能隱藏這些連結並自動產生標籤，因此閱讀核心設定範例時，應先理解結構，不要直接把片段貼進任意文字欄位。也要事先確認自訂設定與圖形介面各自管理哪些內容。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "udp": true }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

協定與傳輸的不同職責

VMess、VLESS 和 Trojan 描述代理連線的協定方式；傳輸層決定這類連線如何透過網路傳送；TLS 與 REALITY 則涉及連線安全和交握條件。這些設定不能任意組合。匯入節點時，應將位址、連接埠、身分欄位、傳輸類型和安全參數視為整體；任何一項與伺服器端不一致，都可能導致連線失敗。單獨更改協定名稱通常無法解決問題。

DNS 也不是獨立於連線路徑之外的附屬設定。應用程式可能先解析網域，再將位址交給代理；也可能保留網域名稱，交由核心或遠端處理。路由能否辨識原始網域，取決於請求形式、代理協定和相關設定。看到目標變成位址時，不要立刻認定網域規則失效；應先確認在哪一層解析，以及請求是否仍包含可供比對的網域資訊。

學習階段建議每次只測試一個應用程式連線至一個已知目標。記錄使用的入口、目前節點、作用中的模式和測試結果，再判斷請求停在哪一層。上方設定是僅直連的結構範例，用來說明模組之間的關係，不代表已具備遠端代理能力。真實服務的驗證資料應從可信來源取得，不要從其他教學複製看似完整、實際上卻不符合自身服務的欄位。

選擇用戶端：平台、核心與管理方式

先依裝置選擇，再確認功能

桌面裝置可優先選擇 v2rayN，再依作業系統和處理器選擇下載版本。它適合集中管理訂閱、查看連線記錄和調整路由。Android 裝置可優先考慮採用 Xray 核心的 v2rayNG；需要 V2Fly 生態系設定時，再評估 v2flyNG。選擇時應考量現有節點所需功能、系統條件和日常操作習慣，而非只比較介面外觀，或單憑用戶端名稱判定效能。

安裝前應確認節點實際需要的協定與安全參數。一般匯入成功，不代表用戶端已完整辨識所有擴充欄位，尤其要留意 REALITY、公鑰、伺服器名稱、指紋與流量控制等設定。可先向設定提供者確認目標用戶端和核心需求，再檢查匯入後的編輯頁面。若介面沒有對應欄位，不要用不相關的輸入框代替，也不要刪除欄位後直接長期使用。

桌面安裝版本與處理器架構

Windows 下載頁提供 Desktop 桌面版與經典 WPF 版。前者採用新一代跨平台介面，後者保留經典介面；兩者的選單位置和操作細節可能不同。首次設定時，選一種版本建立基準即可，避免同時啟動兩套程式而搶用本機連接埠。移轉時應逐項確認訂閱、路由和系統代理設定，不要以為複製程式資料夾就等於完成所有設定移轉。

macOS 裝置需區分 Apple Silicon 與 Intel。請透過系統的裝置資訊確認晶片類型，再選擇對應的下載版本，不要只按購買年份推斷。Linux 除處理器架構外，還要配合發行版使用的套件管理格式，通常選擇 deb 或 rpm。處理器架構和安裝格式是兩個條件；套件管理器能辨識檔案，不代表其中的執行程式適用於目前的處理器。

Android 的 arm64 安裝套件適用於多數較新的主流裝置；若架構不明或需要支援更多裝置，可選通用套件。最終仍應以系統支援情況為準。若系統拒絕安裝，先檢查處理器架構、可用空間和既有應用程式的簽章是否相符，不要不斷下載不同檔案碰運氣。覆蓋安裝若遇到簽章衝突，先匯出設定並確認備份可用，再決定是否解除安裝舊版應用程式。

設定管理習慣也會影響選擇

若要在多台裝置上使用同一個訂閱，應同步訂閱來源和必要參數，不要預期用戶端資料庫能直接跨平台共用。系統代理、虛擬網路介面、應用程式排除清單和檔案路徑都因平台而異。桌面可用的自訂指令碼或路徑不能原封不動搬到手機。移轉時先匯入節點並完成單一節點測試，再重新設定本機代理模式和路由，可減少不易察覺的環境相依問題。

用戶端與核心的更新不一定同步。介面上出現某個開關，不代表目前執行的核心已支援對應功能；反過來，核心支援的欄位也未必都能在介面中設定。使用進階功能前，應先閱讀目前用戶端的設定說明，再查看啟動記錄所顯示的執行環境。若無法確定，請保留預設值，以已驗證的協定組合作為基準，不要為了選項看起來齊全而頻繁更換程式。

下載方式請參閱用戶端下載頁，比較各版本的取捨請參閱用戶端比較。下載前先記下作業系統、處理器架構、所需核心功能和設定來源，安裝後即可依同一份清單核對。只有目前的用戶端確實缺少必要功能時才考慮更換；若問題出在連接埠、訂閱或系統授權，改用其他用戶端通常只會重蹈相同的設定錯誤。

安裝與基準：先確認本機環境

安裝前記錄環境

安裝前先記錄目前網路是否可用、系統是否已有代理設定，以及是否有其他會建立虛擬介面的程式正在執行。關閉不需要的舊用戶端，但不要任意刪除網路介面卡或修改系統服務。保留原有代理位址、連接埠和自動設定狀態，以便發生問題時還原。若裝置受組織政策管理，應先確認允許的安裝與網路設定方式，不要反覆提高權限來規避限制。

請透過下載頁的平台選項選擇相符的安裝版本，安裝後首次只啟動一份用戶端。程式目錄、使用者設定目錄與快取目錄可能分開存放；升級或移動程式前，先確認實際資料位置。不要將含有訂閱和身分資訊的設定目錄放在公開共用位置；桌面同步工具若自動上傳整個目錄，也可能一併傳走原本只應保存在本機的連線資料。

首次啟動與權限分級

首次執行時，先確認主視窗能正常顯示，再檢查核心能否啟動。一般本機代理通常不需要長期以最高權限執行；TUN、路由修改等功能可能需要額外授權或輔助服務。應依功能逐項授予權限，不要把所有啟動失敗都歸咎於權限不足。系統顯示提示時，先確認要求的權限與目前操作相符，再決定是否允許。

Windows 上應留意系統代理是否持續被其他工具覆寫；macOS 上要分清應用程式啟動許可與網路相關授權；Linux 則應確認圖形工作階段、系統匣環境和套件相依性是否符合需求。這些差異會影響系統整合，但不會改變節點欄位本身。若主視窗可用但系統匣圖示不見，可先在視窗中完成設定，不要把介面整合問題直接當成遠端連線故障處理。

Android 首次啟動連線時，通常需要確認 VPN 授權。授權前先儲存節點，授權後查看應用程式是否進入執行狀態。若裝置已建立其他 VPN 連線，系統可能要求切換；應先確認兩者用途，避免反覆爭用。也要記錄背景執行策略，但首次測試時先讓應用程式保持在前景，以排除電池管理的影響；基本連線確認後，再處理鎖定畫面和背景執行行為。

監聽位址與連接埠占用

本機監聽優先使用回送位址，讓入口只接收本機請求。只有確定需要其他裝置連線時，才評估區域網路監聽、驗證方式和防火牆範圍。連接埠號碼只是入口識別，不是節點伺服器端連接埠的副本；兩者可以不同。若記錄顯示位址已被占用，先退出另一個用戶端或查明占用程式，再修改本機監聽連接埠，並同步修改手動設定該連接埠的應用程式。

{
  "inbounds": [
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

這裡展示的是入口片段，不是完整代理設定。它說明監聽範圍、連接埠、協定與標籤之間的關係；實際使用時，應由用戶端搭配出口等內容產生完整設定。不要把 HTTP 入口填入只接受 SOCKS 的應用程式欄位，也不要因為兩個連接埠相鄰就以為可以互換。若應用程式有獨立的代理設定，也要確認代理類型、位址和連接埠；三者都一致才算設定正確。

建立基準時，先不要啟用複雜路由、流量探測或 TUN。確認記錄沒有啟動錯誤後，匯入一個已知有效的節點，再用支援系統代理的應用程式測試一次。記下成功時的設定並保留還原方式。若必須調整多個選項才能運作，應依調整順序記錄原因；否則日後升級或移轉時，很難分辨哪些設定是必要條件，哪些只是排錯時留下的暫時修改。

匯入訂閱：來源、格式與節點確認

分清訂閱網址與分享連結

訂閱網址是取得一組節點資料的入口；分享連結通常描述單一節點；原生 JSON 則描述核心設定結構，三者不能混用。將完整 JSON 貼入訂閱網址欄，或把單一分享連結當成可定期更新的訂閱來源，都可能導致匯入失敗。匯入前先辨識內容類型，再使用用戶端對應的訂閱管理、剪貼簿匯入或自訂設定入口，避免把格式錯誤誤判為網路故障。

訂閱連結通常包含可辨識帳戶的存取憑證，取得後應視為敏感資料管理。不要將完整網址放進公開截圖、討論記錄或共用文件，也不要上傳至不明的轉換網站。需要求助時，可以說明協定類型和錯誤發生位置，並隱藏身分欄位、具識別性的網域部分與查詢參數。編碼後的字串仍可能還原成原始內容，不能把編碼當成存取保護措施。

建立群組並執行首次更新

在用戶端的訂閱管理中新增群組，填入方便辨識的名稱和來源網址，再執行更新。不同介面的選單名稱可能不同，但流程都是先儲存來源，再取得並解析內容。更新後確認節點出現在預期群組，不要只看跳出的成功訊息。若群組是空的，先檢查來源是否回傳有效內容，再查看解析記錄；暫時不要反覆重裝用戶端或修改所有網路設定。

更新訂閱與代理連線是兩次不同的網路請求。更新可能採用直連，也可能經由目前的代理，取決於用戶端選項和系統環境。如果更新必須透過已失效的作用中節點，就會形成無法取得新節點的循環。此時應確認更新使用的連線路徑，在網路條件允許時調整更新方式，並保留原有群組；不要先清空所有節點，以免排錯時失去可用的參照。

解析完成後，開啟一個節點的編輯頁，核對伺服器位址、連接埠、協定、身分欄位、傳輸方式和安全設定。節點顯示名稱只供辨識，不影響連線是否正確。特別留意伺服器名稱可能與連線位址不同，傳輸路徑和要求標頭也各有用途。不要因欄位看起來重複就刪除；有些欄位分別負責網路定址、交握驗證與應用層請求，功能並不相同。

匯入後的驗證與更新注意事項

將一個節點設為作用中設定後，先確認核心可以重新啟動，再用固定的應用程式和目標進行驗證。清單中的測試結果只代表特定測試方式，不能涵蓋所有實際應用情境。若用戶端測試正常但瀏覽器失敗，應檢查瀏覽器的入口；若啟動階段就報錯，則先確認欄位相容性。將匯入、啟動和實際連線分開觀察，比不斷切換節點更容易找出問題。

訂閱更新可能會覆蓋由訂閱產生的節點項目，因此手動修改節點前，先確認哪些欄位會在下次更新時還原。若確實需要長期自訂，可使用用戶端提供的獨立設定或複製功能，並為副本取清楚的名稱。分開管理訂閱原始項目與本機副本，可降低誤覆蓋的風險。刪除群組前，先確認作用中的節點是否來自該群組，避免更新後目前選取的項目已不存在。

遇到驗證失敗、內容空白或格式無法辨識時，應分別處理。驗證失敗時檢查來源憑證與帳戶狀態；內容空白時確認回應是否實際包含節點；格式錯誤時核對用戶端支援的匯入形式。完整設定也可能包含本機路徑和特定出口標籤，不能像單一節點連結一樣直接重複使用。更多格式關係請參閱訂閱連結格式解析，了解結構後再決定是否轉換。

代理模式：應用程式接入與核心分流

系統代理不代表所有流量都會被接管

系統代理會將代理位址提供給支援此機制的應用程式。瀏覽器通常可以使用，但有些程式保留獨立設定，另一些則完全不讀取系統代理。啟用後只有部分應用程式發生變化時，應先檢查各應用程式的接入方式，不要立刻更換節點。判斷時要分清本機代理是否正在執行，以及系統是否指向該代理：即使核心運作正常，系統若仍指向舊連接埠，也會造成看似全面失效的情況。

手動代理是直接在應用程式中填入本機入口，方便隔離測試，也適合只讓單一應用程式接入。此時系統代理可以維持原狀，但應用程式中的協定類型、位址和連接埠必須符合核心監聽設定。若應用程式同時有自動設定、擴充代理和手動代理，應確認實際生效的是哪一層。排錯時暫時只保留一個明確入口，避免多層設定互相覆蓋，造成介面顯示與實際行為不一致。

分開理解接入範圍與出口選擇

用戶端介面中的全域、規則、直連等名稱，通常描述出口選擇策略；系統代理與 TUN 則主要影響應用程式如何將流量交給用戶端。這是兩個不同面向。全域代理不會自動讓所有應用程式使用系統代理；啟用 TUN 接管也不代表所有目標都必須經由遠端。先決定哪些應用程式需要接入，再決定這些流量如何分流，可避免把入口問題誤當成路由問題而反覆調整。

首次驗證建議採用簡化的代理出口策略，讓已接入的測試應用程式先透過所選節點連線至目標。成功後再切換至日常分流規則，並以同一目標比較記錄差異。若簡化策略正常但規則策略失敗，優先檢查規則順序、預設出口和 DNS 條件。若兩種策略都失敗，應回頭檢查節點與入口，不要繼續堆疊規則來掩蓋尚未解決的基本連線問題。

驗證結果應涵蓋實際使用情境

驗證時固定測試應用程式、目標和作用中節點，分別觀察網域解析、建立連線以及實際內容是否載入。某個頁面能開啟，不足以證明其他應用程式的 UDP 請求或長連線也正常。反過來，單一目標無法連線也不代表所有連線都失敗，應換一個已知可用的目標進行對照。每次只改變模式或節點其中一項，才能將結果變化與特定設定連結起來。

桌面應用程式若內建獨立代理功能，應留意它是否將網域名稱交由代理解析。不同請求形式可能讓核心看到網域，也可能只看到已解析的位址，進而影響後續網域規則。不要為了讓單一應用程式正常運作就立刻更改全系統 DNS；先檢查應用程式本身的代理與解析行為。必要時可查看用戶端記錄，確認請求是否抵達本機，以及記錄中的目標採用哪種形式。

區域網路存取也需要個別驗證。印表機、檔案分享和本機服務可能依賴私人位址或本地域名；若規則將這些請求送往遠端，常會出現外部網頁正常、本機資源卻無法使用的情況。先確認不使用代理時資源本身可正常存取，再為明確的本機範圍設定直連。不要將所有未知位址都設為直連，也不要用過於寬泛的規則來修復單一裝置，以免改變其他目標的預期路徑。

退出用戶端前，先還原或清除由它設定的系統代理，再停止核心，可降低系統仍指向失效連接埠的機率。若程式意外結束，重新啟動後檢查代理狀態，必要時到系統設定中還原原有設定。完成本章後，應能說明某個應用程式是否已接入、使用哪個入口，以及最後採用哪個出口。若有任何一項無法確認，先補足觀察資料，不要繼續啟用更複雜的接管功能。

路由分流：比對順序與 DNS 條件

將規則安排成可解釋的順序

路由規則通常會依序檢查，符合條件後便選擇相應出口，因此具體例外應排在範圍較廣的規則之前。規劃時先寫下預期行為：本機資源直連、指定網域使用特定出口，其餘請求則依預設策略處理。不要先收集大量規則，再猜測執行結果。每條規則都應說明比對對象、選擇的出口和設定理由；若兩條規則涵蓋同一目標，也要能解釋為何前一條應優先。

下方設定是完整的僅直連示範，用來觀察規則結構，不包含遠端代理節點。第一條處理私人位址，第二條處理分類網域，最後一條則為送入此入口的其他請求提供預設出口。實際建立直連與代理分流時，應由用戶端建立有效的代理出口，再將相應規則指向其實際標籤。不要只填入代理標籤卻未定義出口，也不要假設不同用戶端使用的標籤名稱完全相同。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "udp": true }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

網域策略不是 DNS 伺服器設定

domainStrategy 位於 routing 物件中，不屬於單一規則。它控制路由比對時何時解析網域，以便參與位址規則的判斷。AsIs 保留原有目標形式；IPIfNonMatch 在網域比對沒有結果時嘗試以位址比對；IPOnDemand 則可能在遇到需要位址資訊的規則時觸發解析。實際行為仍須配合目前使用的核心與完整規則理解。

路由網域策略不負責獨立指定要查詢哪一台 DNS 伺服器，也不等同於應用程式的解析設定。若應用程式已將網域解析成位址，核心未必能憑空還原原始名稱。反過來，核心為了比對位址規則而解析網域，也不代表實際連線一定使用同一條解析路徑。因此排查 DNS 時，應分別確認查詢由誰發起、使用哪個出口、回傳什麼結果，以及最終連線目標，避免把不同階段混成一個模糊的結論。

geosite 和 geoip 需要相應的資料檔與分類內容。若出現分類不存在或資料載入失敗，先確認用戶端使用的資料位置、檔案是否齊全，以及核心能否辨識其格式。分類資料會更新，也不保證涵蓋每個新網域；對於必須明確處理的服務網域，可以新增範圍清楚的明確規則。新增例外後記錄原因並定期檢查，避免暫時規則長期累積、彼此遮蔽。

用記錄驗證規則，不只看網頁

驗證時，分別準備本機位址、明確網域和未符合規則的目標，觀察請求選擇的出口標籤。單一網頁往往會請求多個網域，不同資源可能符合不同規則；頁面能顯示，不代表所有請求都走相同路徑。若要定位單一規則，先使用範圍明確的目標測試，再回到實際網頁。比較規則修改前後的記錄，比只憑體感速度更能判斷規則是否生效。

也要檢查預設處理方式。有些核心設定在沒有規則符合時，會使用出口清單中的第一個出口；用戶端也可能額外產生預設規則。編輯介面中的排序不一定等同於最終設定的排列，尤其啟用預設規則時，更應查看產生的結果。不要為了調整預設路徑就任意重新排列所有出口；優先使用用戶端提供的預設策略設定，並確認重新啟動後的行為符合預期。

設定異常時，先回到最精簡的規則組合，保留本機資源需要的規則和一條明確的預設規則，再逐條加入例外。若加入某條規則後問題重現，就集中檢查該規則的條件與順序。網域分類、位址分類和預設代理出口的組合方式，請參閱路由規則設定實例。擴大規則規模前，應先確保每一層都有可觀察、可還原的驗證方式。

TUN 與多平台：接管範圍和還原方式

啟用前確認實際需求

TUN 透過虛擬網路介面處理由系統路由送入的流量，適用於無法直接使用應用程式代理設定的情境。它會增加介面、路由、DNS 與權限之間的相依性，不應做為首次連線時預設的排錯方式。先透過一般入口確認節點可用，再決定哪些應用程式確實需要接管。若原本只是系統代理的連接埠填錯，啟用 TUN 只會增加變數，不會自動修正錯誤。

啟用前記錄目前的預設網路、DNS 設定和其他虛擬介面的用途，並關閉不必要的同類接管程式。多個程式若都嘗試修改預設路由，可能互相覆寫或形成循環。如需共存，必須明確分工：誰負責入口、誰負責 DNS，以及哪些目標應繞過接管。若分工不明，先讓單一程式獨立運作，完成驗證後再逐項評估共存條件。

權限、路由與連線循環

桌面環境可能需要管理員權限、輔助服務或虛擬介面元件，實際需求取決於用戶端實作和系統條件。啟用失敗時，先依記錄判斷失敗階段：介面建立失敗，檢查權限與元件；路由寫入失敗，檢查權限或衝突；介面已建立但沒有流量，則檢查路由與排除條件。不要只因授權提示尚未完成就反覆安裝，也不要同時開啟多個相關選項來掩蓋具體錯誤。

代理核心連線至遠端服務的流量，必須避免再次被自身的接管規則送回入口，形成無限循環。用戶端通常會處理必要的繞行，但自訂路由、介面繫結和其他網路工具可能破壞這項安排。若一般代理正常，啟用 TUN 後卻立即逾時，應優先檢查迴圈、出口網路和遠端位址的處理路徑。不要直接將所有流量改為直連來測試，否則會同時改變測試條件與接管目標。

個別驗證 DNS 與區域網路

TUN 生效後，仍需確認 DNS 查詢的路徑。有些環境會接管系統查詢，有些則需要特定 DNS 模式或用戶端設定。若已能連線至已知位址，卻無法解析網域，應優先檢查名稱解析，而非立刻否定遠端節點。若啟用合成位址機制，也要確認對應、排除網域與路由能相互配合；這類機制回傳的位址不宜誤認為目標伺服器的真實位址，進而寫入其他規則。

區域網路裝置、本機服務和遠端管理連線都需要個別檢查。啟用接管前，應先儲存必要工作並確保有本機還原方式，避免透過唯一的遠端連線測試可能改變預設路由的設定。私人位址的繞行方式應配合實際網路範圍，不要只複製他人的排除清單。驗證時除了測試外部目標，也要測試本機分享、裝置管理頁面和需要保留的系統網路功能。

Android 與桌面的不同檢查重點

Android 用戶端通常透過系統 VPN 介面接入應用程式流量，不能與桌面上的獨立 TUN 開關逐項類比。主要檢查重點是系統授權、依應用程式選擇的設定和背景執行限制。使用應用程式範圍設定時，應確認介面指的是只包含所選應用程式，還是排除所選應用程式；儲存後重新連線並測試。不要只憑清單中的勾選狀態猜測用途，應參考說明並檢查實際請求記錄。

鎖定畫面後若連線中斷，先比較前景與背景狀態，再檢查電池管理、背景執行限制和網路切換，不要立即更換節點。桌面從有線網路切換至無線網路，或從休眠狀態恢復時，也可能需要重新建立虛擬介面與路由。每次只測試一種環境變化，並記錄連線恢復情形。若只有切換網路後異常，應著重檢查介面狀態與出口網路變化，不要反覆修改已確認正確的驗證欄位。

日常維護：備份、更新與故障排除

保留可還原的設定基準

日常維護的第一步，是保留一份可理解、可用的設定，而非不斷增加選項。備份內容應包括訂閱群組、手動節點、自訂路由、DNS 選擇和必要的介面偏好，並記錄哪些內容由用戶端自動產生。匯出的資料可能包含存取憑證，應存放在受控位置並限制共用。備份完成後，確認自己能辨識其格式和適用的用戶端；無法還原的檔案不能算是有效保障。

更新前記錄目前的可用狀態和重要設定，結束重要連線，再更新用戶端或相關元件。更新後先進行與以往相同的基本測試，確認啟動、訂閱、入口和路由都正常，再啟用新功能。介面調整後若找不到舊選單，應先確認設定分類是否改變，不要立刻重新填寫所有參數。若升級後出現異常，保留記錄與設定差異，再依事先準備的方式還原。

依失敗階段閱讀記錄

排查故障時，先依時間順序確認：程式是否啟動、是否產生設定、核心是否運作、請求是否進入、是否與遠端建立連線，以及目標是否回傳內容。記錄中最早出現的相關錯誤，通常比後續連鎖錯誤更有參考價值。閱讀時保留錯誤前後的內容，不要只截取一個紅色單字。若要提高記錄詳細程度，只在重現問題時啟用；完成後恢復日常層級，避免長期累積含敏感資訊的請求記錄。

核心啟動失敗時，優先檢查 JSON 語法、欄位位置、出口標籤、資料檔案和本機連接埠。此時網路尚未進入正常處理階段，更換遠端節點未必有幫助。若連接埠遭占用，找出同一台裝置上的占用程式；若分類檔案缺失，核對資料路徑；若欄位不受支援，則確認核心功能。更詳細的記錄排查方式請參閱核心啟動失敗排查，修正一項明確錯誤後，再重新啟動觀察。

速度問題應分層比較

可以連線但速度變慢時，應分別檢查節點負載、傳輸路徑和本機設定。先固定應用程式和目標，在相近條件下比較不同節點，再確認是否只在特定時段或網路環境發生。不要同時更換節點、傳輸參數和 DNS，否則即使恢復正常，也難以判斷原因。測試結果只適用於當時使用的方法與環境，不能直接當成所有應用程式長期使用體驗的結論。

本機端先檢查其他下載工作、資源使用情況和重複代理，再評估連線重用等進階選項。重用機制並非在所有協定和應用程式中都更合適，任意啟用可能改變故障表現。三層排查的詳細順序，請參閱連線速度變慢的分層檢查。平時不必頻繁批次測試所有節點；先確保常用設定穩定，再依實際問題進行有目標的比較。

分享故障資料時，應保留用戶端名稱、作業系統、問題發生階段和已遮蔽敏感資訊的錯誤內容，同時移除訂閱網址、身分資訊及不必要的存取記錄。截圖也可能包含群組名稱、伺服器位址和帳戶相關內容，傳送前應逐項檢查。若對方只看到逾時提示，卻不知道入口和模式，很難有效判斷；簡短但結構完整的重現說明，比大量未整理的截圖更有幫助。

維護記錄只需使用一般文字，寫下修改項目、修改原因、測試目標、觀察結果和還原方式。臨時設定不再需要時應及時移除，避免幾年後只能依賴一組無人理解的例外規則。定期檢查訂閱群組是否仍在使用、備份是否有效，以及系統代理是否與目前的用戶端一致。維護的目標是縮小故障範圍、讓修改有跡可循，而不是持續增加設定數量。

進階學習：依需求增加設定複雜度

從連線可用到設定可驗證

完成前面章節後，進階學習應以實際需求為主。需要精細控制流量路徑，就深入了解路由與 DNS；需要管理不同裝置，就研究設定移轉的限制；需要處理特殊協定參數，先確認核心支援情況。不要把同時啟用所有進階選項當成學習完成的標準。能說明每條規則的用途、重現測試並隨時還原的精簡設定，比大量未經驗證的選項更適合長期維護。

建議每次測試都記錄四項內容：目前基準、準備驗證的假設、唯一的修改項目和預期結果。例如要確認網域規則是否優先，可以維持節點與入口不變，只新增一條範圍明確的規則，再觀察出口記錄。若實際結果不符，先釐清差異，不要繼續疊加第二項修改。這樣能讓學習過程成為可重複的實驗，也能避免將一次成功誤以為是同時調整多個參數所致。

協定功能與核心差異

深入了解 VLESS、XTLS Vision 或 REALITY 時，應先掌握各參數所屬的層級，再確認用戶端和目前核心是否支援。伺服器位址、伺服器名稱、流量控制、公鑰和短識別碼等欄位，不能因為名稱相似就互相替代。只看協定名稱不足以判斷節點是否可用，還要考量具體傳輸組合與伺服器端設定。既有服務正常時，不要只為嘗試新功能名稱就全面改寫已驗證的參數。

V2Fly 與 Xray 的關係和功能界線，可參閱兩種核心功能比較。學習重點不是籠統評比核心，而是釐清某項功能由哪一方實作、設定結構有哪些差異，以及目前用戶端如何提供此功能。切換核心前先準備相容性檢查清單；切換後重新驗證啟動、交握、分流與 DNS，不要把舊核心上的成功直接當成新環境的保證。

自訂設定與圖形介面的界線

使用自訂 JSON 前，應先釐清它是完整取代圖形設定，還是只合併局部片段。不同入口可能採用不同處理方式，重複定義入口、出口或標籤會造成衝突。先用最精簡的直連範例熟悉結構，再逐項加入自己的有效節點與規則。不要直接匯入包含他人本機路徑和特定標籤的完整設定；若無法確認合併順序，也不要同時維護兩套彼此覆蓋的設定。

圖形介面產生的設定適合用來查看實際結果，但不一定適合作為長期手動編輯的位置。用戶端下次儲存或切換節點時，可能會重新產生檔案並覆蓋修改。需要長期保留的進階設定，應放在用戶端明確支援的自訂入口；若沒有對應入口，先評估維護成本，不要依賴每次啟動後手動修改檔案。記錄資料來源、產生流程和最終設定之間的關係，可避免修改看似已儲存，實際上卻從未生效。

建立小規模回歸測試

設定變複雜後，應保留一組固定檢查項目：一般網域是否可連線、本機資源是否維持直連、指定規則是否選擇預期出口、未符合規則的目標是否正確套用預設路徑，以及休眠或切換網路後是否恢復。每次更新或修改規則，都用同一組項目比較結果。測試不必涵蓋所有網站，只要能代表自身的重要情境，並在失敗時協助定位模組，就有實際價值。

自動化也應建立在穩定流程上。定期更新訂閱、自動啟動和背景接管能減少重複操作，但也可能在無人注意時改變節點或系統狀態。啟用前先確認失敗時的處理方式，例如更新失敗是否保留舊內容、啟動時是否覆寫系統代理，以及異常結束後能否還原。先手動完成一次完整流程並測試還原方式，再啟用自動化，避免未解決的問題變成週期性背景故障。

本指南的目標，是建立一套能獨立定位問題的順序：確認環境、驗證入口、核對節點、觀察路由、檢查解析，再評估流量接管與進階參數。需要重新建立基本連線時，可回到快速入門；需要依裝置選擇安裝版本時，請參閱用戶端下載頁；想閱讀延伸案例，可從使用心得選擇相關主題。每項新增設定都應對應明確問題並留下驗證依據，才能持續維護。