V2Ray 新手到進階
用戶端設定完整指南

核心概念：先釐清設定層次

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

先將圖形化用戶端視為設定入口。v2rayN 負責管理訂閱、選擇節點、產生執行設定，並呼叫相應核心；實際處理協定連線與流量轉送的是核心。伺服器位於連線另一端，必須使用與用戶端相符的協定及驗證參數。用戶端可以免費下載，但安裝用戶端本身不會自動取得可用的伺服器設定。開始操作前，請準備來源明確且仍有效的節點資訊或訂閱網址。

Project V 是相關代理技術生態的起點，V2Fly 延續 V2Ray 的社群開發，Xray 則是另一條相關的核心發展路線。sing-box 也是部分用戶端可呼叫的代理核心，但不是 V2Ray 的另一個名稱。不同核心的設定結構、功能支援與參數說明不盡相同。圖形介面能統一呈現部分選項，不代表任何設定都能原封不動交由任意核心執行。

協定、傳輸與安全參數應搭配理解

VMess、VLESS、Trojan、Shadowsocks 是代理協定的選擇；TCP、WebSocket、gRPC 等則是連線採用的傳輸方式。TLS 或 REALITY 涉及連線安全機制，不應與協定名稱混為一談。即使節點位址與連接埠正確，也可能因傳輸路徑、服務名稱或安全參數不符而連線失敗。匯入後請優先保留完整參數，不要只因名稱相似就手動替換其中一項。

以 VLESS 為例，辨識節點時通常需要一併確認伺服器位址、連接埠、使用者識別碼、傳輸方式與安全設定。使用 TLS 時可能還需要伺服器名稱；使用 REALITY 時，則須符合相應的公鑰、短識別碼等參數。VLESS 本身不代表一套完整的加密連線方案，是否啟用安全層及採用何種組合，必須依伺服器設定而定。請勿拼湊其他節點的參數來試錯。

沿著流量路徑找出設定位置

一次連線通常會經過應用程式發出請求、流量進入用戶端、路由規則選擇出口、核心連線伺服器，以及伺服器存取目標等環節。系統代理與 TUN 主要決定流量如何進入；路由規則決定進入後要直連、代理或封鎖；節點參數則決定代理連線能否建立。DNS 也會參與網域名稱解析，可能影響規則比對及實際連線位址。將這幾個層次分開，排除問題時就不會只盯著節點清單。

本章的完成標準不是記住所有術語，而是能說明目前的配置：使用哪個用戶端、呼叫哪個核心、節點採用什麼協定、應用程式透過哪種入口接入，以及預設使用哪種路由。將這幾項簡短記錄下來，之後每次變更只調整其中一個層次。遇到不熟悉的名稱，可查閱術語表；出現錯誤提示時，先判斷屬於啟動、解析、交握還是目標存取階段，再決定要檢查什麼。

選擇用戶端：依系統與設定需求決定

桌面版建議從 v2rayN 開始

Windows、macOS、Linux 桌面使用者可優先選擇 v2rayN，方便沿用本指南中的訂閱分組、系統代理與路由操作方式。下載前先確認作業系統與處理器架構，再選擇相符的發行版本。作業系統名稱相同，不代表安裝套件通用，例如 x64 與 arm64 適用於不同的處理器指令集。無法執行時，應先確認套件的適用範圍，而不是不斷更換節點，因為此時網路設定尚未進入執行階段。

Windows 下載區提供 Desktop 與經典 WPF 兩種版本。Desktop 採用跨平台介面，適合希望在不同桌面系統上維持相近操作習慣的使用者；WPF 保留經典 Windows 介面，適合已習慣該版本的使用者。兩者主要差異在介面與發行方式，不能據此推斷某個節點一定比較快。執行階段需求、介面入口與設定儲存方式，請以實際發行版本的說明為準，也不要混用兩個資料夾中的程式檔案。

Android 區分首選與相容備選

Android 首選 v2rayNG，採用 Xray 核心；v2flyNG 採用 V2Fly 核心，可作為有相容需求時的備選。兩款用戶端都能匯入節點並管理連線，但不應假設所有分享連結、傳輸參數與進階功能都完全相同。如果現有設定明確依賴某項核心功能，請先確認目標用戶端支援該組合，再匯入測試。只因名稱相似就更換應用程式，可能會把協定支援問題誤認為訂閱失效。

Android 安裝套件通常需要在 arm64 與通用版之間選擇。較新的主流手機可先確認是否適用 arm64；不確定架構或遇到相容性問題時，再查看通用版的適用說明。通用版不代表連線品質更好，主要差異在於涵蓋的架構範圍。安裝前也要確認系統允許目前的檔案來源安裝應用程式；安裝完成後，授權仍是獨立步驟，不能將安裝成功視為代理已啟動。

比較功能前先列出實際需求

將需求寫成具體任務，比較功能數量更有幫助。例如只讓瀏覽器使用代理，通常先檢查系統代理或應用程式本身的代理設定；需要接管不讀取系統代理的程式，再研究 TUN；需要依應用程式區分流量，則確認目標平台是否支援個別應用程式設定。這些任務仰賴不同的系統機制。用戶端顯示某個開關，不代表目前的系統權限、網路環境與核心組合已符合啟用條件。

選擇用戶端時也要考量維護成本。如果某台裝置已穩定使用一套設定，遷移前先記錄訂閱來源、路由策略與特殊參數，並確認新用戶端能否重現相同設定。匯出檔案不一定能直接匯入其他用戶端，建議透過原始訂閱或標準分享連結重新建立。完整比較請參閱用戶端選擇指南，實際安裝項目請前往下載頁。本章完成後，保留一個明確的首選方案，先建立可用基準，再評估是否需要更換。

安裝與啟動：先建立可執行的基準

確認架構、安裝位置與權限

前往用戶端下載頁，依作業系統選擇發行版本。Windows 可在系統資訊中查看系統類型；macOS 可在裝置資訊中確認晶片；Linux 則需一併確認架構與套件管理格式。不要只憑副檔名判斷是否適用於目前裝置。下載完成後先安裝或解壓縮，再啟動主程式；如果發行版本要求解壓縮後執行，請勿直接從壓縮檔預覽視窗開啟程式，否則相對路徑、資源檔與設定寫入都可能出問題。

Windows 建議為用戶端保留獨立資料夾，避免將不同發行版本反覆覆蓋到同一位置。資料夾必須允許目前使用者儲存設定，首次設定時尤其要確認退出後變更仍會保留。一般使用時不應為了方便而長期提高所有權限；只有啟用需要額外權限的功能時，才依用戶端提示處理。如果出現缺少執行階段的提示，請依錯誤訊息安裝對應相依元件，不要隨意複製其他電腦上的執行階段檔案。

macOS 請選擇與晶片相符的安裝項目，依系統流程放到適當位置並啟動。如果系統阻止開啟，先確認檔案來源與系統提示，再依安全性設定中的正常授權流程處理。Linux 請選擇符合發行版的 deb 或 rpm 套件，並透過系統套件管理流程處理相依元件。圖形桌面、權限授權方式與虛擬網卡支援可能因發行版而異；啟動失敗與網路連線失敗應分開記錄，不要一概視為連線問題。

首次執行只檢查必要項目

進入主畫面後，先確認用戶端能正常儲存設定、核心可以啟動，且本機監聽位址與連接埠沒有衝突。監聽連接埠是應用程式接入用戶端的入口，不是伺服器連接埠，兩者用途不同。如果記錄顯示位址已被占用，先關閉其他代理程式，或調整本機監聽設定，再重新啟動確認。不要刪除不認識的系統程序，也不要同時啟動多個用戶端搶用相同連接埠，以免後續測試難以判斷。

首次啟動時先保持系統代理與 TUN 關閉，匯入一筆設定，再使用用戶端提供的連線測試，或透過明確設定代理的應用程式進行驗證。如此可將核心是否正常運作與系統流量是否接入分開檢查。如果介面正常但核心反覆退出，請查看啟動記錄中的第一個錯誤，優先檢查設定不相容、資源檔缺失、權限不足或連接埠占用。視窗仍然開著，並不能證明背景代理服務已成功執行。

完成一次啟動與退出測試

Android 安裝後，首次連線時會出現系統 VPN 授權要求。這是應用程式透過系統網路介面接管流量所需的許可，不代表已連上伺服器。先確認授權對象，再查看用戶端的執行狀態；如果裝置上已有其他 VPN 連線，通常需要在兩者之間擇一。桌面版也可能殘留其他網路工具的代理設定，初次排除問題時可先暫停這些工具，避免新用戶端正常執行卻仍受舊入口影響。

最後請主動退出並重新開啟一次用戶端，確認訂閱分組與偏好設定仍然保留。再檢查退出後系統代理是否已還原，並確認基本網路存取不依賴已停止的本機監聽。安裝階段的完成標準是程式能啟動、設定能儲存、核心沒有啟動錯誤，且能清楚辨別執行與停止狀態。Windows 介面與相依元件的細節可繼續閱讀Windows 安裝流程與常見問題；安裝尚未穩定前，請勿急著加入複雜分流設定。

訂閱與節點：建立可持續更新的設定來源

先判斷取得的是哪一種連結

訂閱網址用來取得一組設定，之後更新時仍會連線至同一來源；分享連結通常描述單一節點，例如以相應協定名稱開頭的連結。兩者應使用不同的匯入方式：訂閱網址加入訂閱分組，單一節點連結則透過剪貼簿或分享連結匯入。網頁可以開啟的網址不一定是訂閱網址，也可能只是帳戶頁面或說明頁面。匯入前先確認來源說明，不要把登入頁網址當成用戶端可直接解析的設定內容。

在 v2rayN 中建立訂閱分組，填入容易辨識來源的名稱，再貼上完整網址。複製時注意開頭的協定、路徑與查詢參數是否完整，尤其不要漏掉問號後的內容，也不要混入空格、換行或中文標點。儲存後更新該分組的訂閱，確認是否取得節點。分組名稱只是本機管理標籤，不參與伺服器驗證；更改名稱通常無法修復網址過期或驗證資訊失效的問題。

更新方式取決於目前能否連上網址

是否透過代理更新訂閱，應依目前網路狀況與網址是否可連線決定。尚未建立任何可用代理時，優先嘗試不透過代理更新；如果直連受到網路路徑影響，而已有可正常運作的節點，再試著透過代理更新。這兩種方式只是取得訂閱內容的不同路徑，並非修復訂閱格式的開關。如果伺服器回傳登入頁、錯誤頁或空白內容，切換連線方式也未必有用，還需要檢查網址權限與來源狀態。

更新失敗後先保留現有節點，不要立刻清空所有分組。查看記錄，確認是連線逾時、名稱解析失敗、驗證遭拒，還是內容解析錯誤。前兩種較可能與存取路徑有關，後兩種則可能涉及來源權限或內容格式。可聯絡設定提供者確認網址狀態，但不要將完整訂閱網址貼到公開討論區。訂閱網址中的查詢參數常用作存取憑證，若已外洩，應依提供者的流程更換，而不只是刪除聊天記錄。

更新成功後仍須確認實際可用性

成功取得節點清單，只表示內容可以讀取及解析，不代表每個節點都能成功連線。先選擇一個參數完整且符合目前需求的節點，設為作用中節點，再發出實際請求測試。清單中的名稱只是標籤，無法可靠反映協定、安全方式或可用區域。若長期保留單一節點，請記錄其來源與用途；如果原始來源已停止提供服務，更改顯示名稱或重複匯入相同連結都無法恢復連線。

訂閱節點與手動節點最好分開管理。有些用戶端更新分組時會重新建立其中的項目，因此直接修改訂閱產生節點的特殊參數，可能在下次更新時被覆蓋。如果確實需要本機修改，請確認用戶端是否提供保留機制，或複製為獨立設定並註明來源。不要假設更新訂閱一定會替換所有本機路由設定，也不要認定完全不會影響作用中節點；更新後應重新確認目前的選擇與重要參數。

來源穩定後再考慮自動更新。更新頻率應符合提供者的使用規範；更新過於頻繁不一定更即時，反而可能觸發存取限制。每次大型更新後，請確認節點數量是否異常、作用中節點是否變更，以及實際請求是否仍可完成。單一節點與訂閱的結構差異請參閱分享連結與訂閱網址說明；更新異常時，請依訂閱更新失敗檢查清單繼續排查，先確認取得結果，再檢查內容相容性。

代理模式：先確認應用程式如何接入

系統代理控制入口，不直接決定分流

系統代理是一組供應用程式讀取的系統網路設定。啟用後，遵循這些設定的應用程式會將請求交給本機代理監聽；沒有讀取系統代理的程式，可能仍會自行連線。因此，啟用系統代理不代表裝置上的所有流量都會被接管，也不代表每個請求都會使用遠端節點。進入用戶端後是否直連，仍由路由決定。將入口與出口分開理解，就能避免用全域路由處理應用程式根本沒有接入的問題。

v2rayN 常見選項包括清除系統代理、自動設定系統代理、不變更系統代理及 PAC 模式。自動設定會將相應的系統設定指向用戶端的本機入口；清除則移除相應的代理設定；不變更表示維持系統現況，並非強制直連。PAC 會讓支援此機制的應用程式依指令碼結果選擇入口。實際影響哪些系統欄位，取決於目前的系統與用戶端實作；切換前最好先記錄現有的工作網路設定。

使用單一應用程式確認入口是否生效

先關閉 TUN，選好可用節點並啟動核心，再啟用自動設定系統代理。使用明確遵循系統代理的瀏覽器發出新請求，並查看用戶端存取記錄是否出現相應目標。必要時關閉舊連線或重新開啟瀏覽器，避免重複使用連線影響判斷。如果完全沒有相關請求記錄，應先檢查應用程式本身的代理選項、系統設定與本機監聽，而不是繼續更換遠端節點或修改傳輸參數。

如果應用程式允許手動設定 HTTP 或 SOCKS 代理，請依用戶端目前顯示的監聽類型、位址與連接埠填寫，不要照抄教學中的範例數字。HTTP 監聽不能任意當成 SOCKS 監聽使用；即使是支援混合入口的用戶端，也要確認該功能確實已啟用。如果應用程式另有獨立代理設定，系統代理開關可能不會影響它的行為。記錄應用程式層級的設定，才能在排除問題時說明為何同一裝置只有部分程式受到影響。

PAC、全域與繞過中國大陸不屬於同一層

PAC 會在應用程式接入前進行部分選擇；用戶端內的全域、繞過中國大陸等路由預設，則是在流量進入後決定出口。兩套規則同時套用時，有些直連請求可能根本不會出現在核心記錄中，因為入口層已經做出選擇。入門階段建議先使用單一且容易觀察的入口，再設定核心路由分流；需要 PAC 時，再確認指令碼來源、更新方式與實際支援範圍，不要同時疊加多套自動判斷。

驗證代理時應發出實際的網路請求，而不只是看用戶端圖示的顏色。某個目標可以存取，只能證明該目標與目前的請求路徑可用；其他應用程式可能採用不同協定、DNS 路徑或獨立代理設定。如果瀏覽器可用但其他程式失敗，先比較入口差異。如果網頁部分資源載入失敗，則檢查不同資源網域的路由與解析，不要只因主頁面開啟，就認定所有連線都正常。

工作網路可能透過管理政策規定代理設定，切換前應先了解本機權限與組織要求。不要在不允許變更的環境中直接覆寫個人代理設定。退出程式、休眠或切換網路後，也要檢查系統入口是否符合預期。本章完成後，應能說明哪些應用程式會接入、入口位址從何處讀取，以及關閉用戶端後如何復原。需要接管更多流量時再閱讀 TUN 章節，不要把所有系統代理失效都歸咎於節點故障。

路由分流：以精簡規則表達實際需求

從一種預設設定建立可理解的行為

先選擇符合目前用途的路由預設，再加入少量自訂規則。全域模式通常會將進入用戶端的流量交由代理出口處理，但不會改變應用程式是否進入用戶端；繞過中國大陸通常透過網域與位址規則，讓部分目標直連，實際涵蓋範圍取決於預設內容與規則資源。不要把預設名稱當成完整的技術定義。選好後應查看具體規則與預設出口，尤其要確認未命中任何規則的流量最後會如何處理。

路由通常依序比對，較早命中的規則會決定後續處理方式。範圍過大的規則若排在前面，可能會遮蔽後續更精確的規則。調整前先寫下目標：哪些網域要直連、哪些目標要走代理、哪些連線要封鎖，再確認比對條件是否正確。網域、目標位址、連接埠與應用程式資訊不一定都能取得；如果目前入口只能提供位址，單純新增網域規則未必會生效，還要檢查網域資訊的來源。

理解設定片段，不要直接拼接完整執行檔

以下是 Xray 格式的路由片段，示範回送與私有位址直連，以及指定網域走代理的基本寫法。這不是完整的用戶端設定；引用的出口標籤必須存在於實際設定中，圖形化用戶端也可能使用不同標籤。請先在介面中設定相同目的，確有需要使用自訂設定時，再查核目前核心的文件。sing-box 的規則結構不同，不可將這段內容直接貼到另一種核心的設定欄位。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "::1/128", "fc00::/7"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      }
    ]
  }
}

在這段範例中，網域後綴比對涵蓋目標網域及其子網域，不應理解成任何包含相同字母的位址都會符合。位址規則只有在能取得並比對目標位址時才會生效；採用依原始網域處理的策略，不代表會主動解析所有網域來套用每條位址規則。因此，區域網路服務最好優先使用明確的本地域名或位址規則，並依實際存取方式測試，避免以為加入私有位址範圍就一定涵蓋所有入口情況。

DNS 與嗅探會影響規則可取得的資訊

DNS 決定網域如何解析成位址，路由則決定連線採用哪個出口，兩者會互相影響，但不是同一項設定。解析出的位址可能隨網路、解析器與時間變化，因此用某個暫時位址取代完整網域規則通常不穩定。嗅探可以嘗試從部分協定資料辨識目標名稱，但並非所有流量都能辨識，也不應將它視為萬用修復方式。啟用前先了解用途並留意相容性，不要一次開啟所有相關選項。

測試新規則時，先選定一個明確目標，記錄修改前使用的出口，再新增規則並重新建立連線。如果記錄能顯示規則或出口，請查看實際命中結果；若介面只顯示連線資訊，則搭配可控目標與請求結果判斷。如果測試仍走舊路徑，先排除連線重用、應用程式快取與規則順序，再考慮解析差異。每次只修改一項，確認有效後再繼續，否則很難判斷是哪項變更造成影響。

維護分流的重點是規則少而明確。定期刪除已無用途的暫時規則，並註明例外規則的用途；更新規則資源後，重新測試常用目標與區域網路存取。發生問題時，先還原最近一次可用的預設設定，再逐條加回自訂項目。不要為了追求複雜規則而犧牲可理解性。學習階段的合格成果是能說明預設出口、例外條件與比對順序，並以實際請求證明規則生效，而不只是看到設定已儲存的提示。

TUN 模式：在穩定設定上擴大流量接管範圍

先了解虛擬網路介面的用途

TUN 透過虛擬網路介面接收系統交給它的網路資料，讓部分不讀取系統代理的應用程式也有機會進入代理處理流程。它解決的是流量接入範圍問題，不會自動修復過期訂閱、錯誤驗證或無法連線的伺服器。啟用前應先確認同一節點在基本代理路徑中已能正常運作，否則入口、路由與遠端連線等問題會同時混在一起。只使用瀏覽器的簡單情境，未必需要再加入這一層。

桌面系統可能需要管理員權限、服務支援或額外網路授權，實際方式取決於系統與發行版本。依用戶端提示操作即可，不要從不明來源下載所謂的通用驅動程式。啟用後應確認虛擬介面已建立、核心持續執行，且路由設定沒有立即觸發錯誤。Android 用戶端通常透過系統 VpnService 接管流量；授權畫面與桌面版的 TUN 開關並非相同操作方式，不能逐項照搬。

避免代理連線再次被自身接管

TUN 必須正確處理代理伺服器本身的連線，否則可能發生流量再次進入虛擬介面的迴圈。圖形化用戶端通常會自動處理，但同時執行多個用戶端、手動修改路由，或另有 VPN 執行，都可能破壞原本的設定。首次啟用時先暫停其他網路接管工具，保持單一入口；如果記錄出現重複連線、請求堆積或啟動後立即斷網，先關閉 TUN 並還原基準，再檢查出口與系統路由。

系統代理是否同時啟用，應遵循目前用戶端建議的組合。兩者並用不一定有問題，但會增加判斷連線路徑的難度。測試時可先關閉系統代理，選擇一個原本不遵循系統代理的應用程式，比較啟用 TUN 前後的存取記錄變化。如果用戶端提供自動路由、嚴格路由或介面選擇等選項，請先保留預設值，了解作用後再調整；不同核心中名稱相同的選項，實際行為可能不同，不能只照名稱移植設定。

將 DNS、區域網路與休眠後復原納入驗證

TUN 通常會涉及 DNS 接管或專用解析路徑。啟用後若位址可以連線、網域卻失敗，優先檢查解析流程；若網域可解析但連線逾時，再檢查出口選擇與伺服器連通性。採用合成位址機制時，還需要相應的對應與路由流程配合，不能將這些位址當成目標的真實位址寫入永久規則。企業內部網域、區域網路裝置名稱，以及需要特定解析器的服務，都應分別測試能否正常解析。

驗證清單應包含一般網頁、原本需要個別設定代理的應用程式、區域網路裝置存取，以及休眠喚醒後的復原。切換 Wi-Fi 或有線網路後，也要確認出口介面是否改變。如果只有特定網路連線失敗，可能與該網路的 DNS、入口網站驗證或管理政策有關；請先完成網路要求的登入，再啟用流量接管。系統尚未正常取得網路設定時，不要反覆重新啟動核心，以免把網路接入問題誤認為用戶端故障。

Android 還要檢查背景執行限制。系統省電策略可能在螢幕關閉後停止應用程式，導致連線時好時壞；請依裝置設定允許必要的背景執行，不要毫無限制地放寬所有權限。個別應用程式設定中也要確認清單代表包含還是排除，避免將目標應用程式放進相反範圍。詳細操作請參閱VPN 權限、省電與個別應用程式代理說明。本章完成標準是接管範圍清楚、常用情境可驗證，且關閉後能恢復正常網路。

日常維護：保留基準，分層處理異常

更新前先記錄可復原的狀態

日常維護不只是按下更新。先記錄目前的用戶端類型、使用的核心、訂閱分組、作用中節點與路由預設，再備份必要的本機設定。訂閱網址與匯出設定可能包含存取憑證，應存放在安全的位置，不要上傳至公開雲端硬碟或討論區。也要確認備份能否還原：至少要知道匯入入口、檔案包含哪些內容，以及還原時會不會覆蓋目前設定，避免發生問題後才發現備份的只是空資料夾。

更新用戶端、核心、訂閱與規則資源是不同操作。用戶端更新可能改變介面與設定管理方式；核心更新會影響協定實作與執行行為；訂閱更新會刷新來源提供的節點；規則資源更新則會影響分流比對。一次只進行一種更新，啟動後檢查記錄與常用目標，再進行下一項。如果全部一起更換，出現問題時很難判斷該還原程式、節點還是規則，也容易把短暫的網路波動誤認為更新缺陷。

無法連線時，從入口開始逐層縮小範圍

先確認基本網路是否正常，再確認用戶端與核心是否執行，接著檢查應用程式流量是否進入，最後檢查路由與遠端連線。完全沒有存取記錄時，優先檢查入口；有記錄但連線伺服器逾時時，優先檢查位址、連接埠與網路路徑；交握遭拒則檢查驗證、傳輸與安全參數。如果出現時間相關的驗證或憑證錯誤，也要確認系統時間。不要一遇到錯誤就重新安裝，因為故障層次未必與安裝有關。

如果同一節點在不同應用程式中的表現不同，先比較系統代理、應用程式獨立代理、DNS 與協定需求。如果所有節點都失敗，重點檢查共用項目，例如本機監聽、核心啟動、網路接入與共用解析設定。如果只有一個節點失敗，再確認該節點的伺服器狀態與專屬參數。如果同一裝置換用不同網路後恢復，代表值得調查網路路徑差異；但不能只憑一次測試就判定問題原因，應記錄可重現的條件。

看懂測速結果與記錄證據

TCPing 通常只反映到目標連接埠的部分連線狀況，不能證明完整代理交握與目標請求都成功。真連線延遲較接近一次透過代理完成的請求，但仍取決於測試目標；下載測速則受到頻寬、伺服器負載、目標網站與本機網路影響，也會消耗流量。不要只用單一數字選擇節點。應優先確認實際服務請求能否穩定完成，再以多次且條件相同的測試比較差異，避免混用不同測試方法的結果。

閱讀記錄時，優先擷取一次失敗發生的時間範圍，找出第一個具體錯誤，而不是最後一行摘要。常見的逾時、連線遭拒、名稱解析失敗與驗證失敗，分別指向不同階段。分享記錄前，移除訂閱網址、使用者識別碼、完整伺服器資訊與本機敏感路徑；只保留排查所需的錯誤類型與操作順序。過長的記錄可能掩蓋重要背景，精簡且能重現的紀錄通常比整頁截圖更有用。

維護完成後，應再次確認退出後的復原狀態、系統代理設定與常用應用程式。保留一份已驗證可用的基本設定，但不要不斷累積失效節點與臨時規則。測速原理請參閱TCPing、真連線與下載測速的差異；常見情況可查閱常見問題。維護完成的標準是變更有記錄、異常能定位到相應層次、復原步驟可執行，而不是讓設定頁上的開關盡可能都保持啟用。

進階學習：從能連線到能解釋設定

第一階段：用可重複的測試取代反覆試錯

進階不代表立刻編寫完整設定檔。先為常用情境建立可重複的測試方法：固定一個應用程式、一個目標與一種入口，記錄節點、路由及解析設定，再觀察一次請求的結果。修改設定時一次只變更一個變數，確認結果後再繼續。這樣累積的經驗才能套用到其他節點與網路，而非仰賴偶然可用的組合。如果無法說明為何有效，先保留紀錄，不要把推測寫成通用結論。

逐步了解 DNS 的作用範圍，分清系統解析、應用程式內建解析與核心解析。觀察網域是否在進入用戶端前已轉換成位址、規則是否需要原始網域，以及解析請求本身如何選擇出口。不要一開始就追求複雜的解析流程，先確認各層由誰負責。若目標同時有不同類型的位址，也要確認系統網路具備相應的連線能力，避免將位址能解析誤認為位址必然可連線。

第二階段：依實際需求了解核心差異

選擇 Xray、V2Fly 與 sing-box，應一併考量節點協定、傳輸組合、路由能力與用戶端支援情況。切換核心前，先列出必須保留的功能，再確認用戶端能否正確產生相應設定。介面中的選項可能只對應部分功能，自訂設定也可能略過某些圖形介面選項。不要假設切換後所有選項都會自動保持相同效果；應重新驗證連線、解析與路由，而不只是確認程序能否啟動。

學習參數時，請以一個已知可用的節點為基準逐項確認：位址與連接埠用來找到伺服器，驗證資訊用來確認身分，傳輸參數用來符合承載方式，安全參數則用來建立預期的保護機制。TLS 的伺服器名稱不是任意備註；REALITY 公鑰也不是可以自行產生並替換的顯示欄位。每一項參數都必須符合伺服器端條件。了解這些界線後，才能判斷問題來自用戶端的設定能力，還是設定本身不完整。

第三階段：學習設定結構與驗證流程

閱讀完整設定時，先辨識記錄、入站、出站、路由與 DNS 等功能區塊，再追蹤標籤之間的引用關係。入站描述要接收哪些流量，出站描述如何連線或處理流量，路由則將比對條件連結到特定出站。標籤只是設定內部的引用名稱，不能只憑名稱判斷用途；需要查看它實際對應的協定與設定。遇到不同核心時，請重新辨識其結構，不要將一種設定格式的欄位名稱套用到另一種格式。

編寫自訂設定前，先複製一份可用設定，並在獨立的測試環境中操作。確認 JSON 語法、欄位適用範圍與引用關係，再交由相應核心進行語意驗證。語法正確只代表格式可解析，不代表欄位受到支援，更不代表伺服器參數正確。圖形化用戶端可能在啟動時重新產生執行設定，因此不要直接修改可能被覆蓋的暫存檔；應使用用戶端明確提供的自訂入口，並記錄哪些圖形介面設定仍會生效。

整理一份自己的精簡操作指南

將穩定的操作流程整理成簡短文件：如何安裝與匯入、預設使用哪種模式、發生問題時先檢查哪個層次、如何停止流量接管並恢復網路，以及哪些設定需要備份。為每條例外規則註明用途，並為每次變更保留復原方式。遷移裝置時，先重新建立最基本的連線，再還原訂閱分組與常用路由，最後啟用 TUN。依照本頁的操作順序進行，可避免將舊環境中未明確記錄的相依設定一次帶到新系統。

最後應能回答四個問題：流量從哪裡進入、為何選擇這個出口、網域在哪裡解析，以及發生問題後如何回到基準。能回答並透過記錄與實際請求驗證，才算建立了可維護的設定。接著依需求查閱術語表、常見問題與專題文章，不必一次啟用所有進階功能。需要重新整理最精簡的操作流程時，請回到快速入門教學，先恢復可用狀態，再逐層增加功能。