V2Ray從零到精通：訂閱、分流與TUN

核心概念：先分清客戶端、核心、協定與訂閱

客戶端負責操作，核心負責連線

使用V2Ray時最容易混淆的四個對象是客戶端、核心、協定與訂閱。客戶端是使用者直接操作的圖形介面，負責儲存訂閱、選擇節點、切換代理模式、產生執行設定並顯示日誌。v2rayN、v2rayNG與v2flyNG都屬於客戶端。核心則在背景讀取設定，完成建立連線、轉送流量、解析網域與比對路由。常見核心家族包括V2Fly與Xray，兩者採用相近的設定思路，但支援的協定能力與欄位細節可能不同。

因此，「客戶端能匯入某個連結」不代表「目前核心一定能正確執行這個連結」。客戶端必須先辨識分享連結或訂閱內容，再將參數轉換成核心設定；核心還必須支援相應的協定、傳輸方式與安全參數。排錯時應先判斷問題發生在匯入階段、產生設定階段，還是實際連線階段，而不是反覆重裝客戶端。匯入後看不到節點，通常與訂閱內容或解析有關；節點存在但啟動報錯，通常與欄位相容性有關；啟動正常但目標網址無法存取，則應繼續檢查代理、路由與網路鏈路。

協定描述通訊方式，傳輸參數必須成組匹配

VMess、VLESS與Trojan等名稱描述客戶端與伺服器之間如何驗證身分及組織資料。它們不是速度等級，也不能單獨決定連線品質。同一種協定還會搭配TCP、WebSocket、gRPC等傳輸方式，並可能使用TLS或REALITY等安全設定。位址、連接埠、使用者識別碼、傳輸方式、主機名稱、路徑與安全選項都必須逐項符合伺服器設定。只修改其中一個欄位，通常不會得到「相近但可用」的結果，而是直接導致握手失敗。

分享連結會將這些參數編碼成方便傳遞的文字；訂閱則把多個分享連結或結構化節點資訊集中在可更新的網址中。訂閱網址本身不是網路節點，比較像一份遠端設定清單。客戶端執行訂閱更新時，會先請求清單，再解析節點，最後寫入本機分組。更新成功只代表清單已讀取並解析，不代表其中每個節點都能連線。反過來，訂閱暫時無法更新時，本機既有節點仍可能繼續使用，因為客戶端儲存的是上一次成功同步的設定。

系統代理、路由與DNS處於不同層次

系統代理決定支援代理設定的應用程式是否將請求交給客戶端；路由規則決定客戶端收到請求後選擇代理出口、直連出口或阻擋；DNS負責將網域轉換成位址，也可能參與網域規則比對。三者需要分別觀察。瀏覽器可用而某個程式不可用，可能是後者沒有讀取系統代理；所有應用程式都進入客戶端，但部分網址走錯出口，通常是路由規則問題；網域解析失敗而直接存取位址有回應，則應檢查DNS鏈路。

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

桌面版優先使用v2rayN

v2rayN支援Windows、macOS與Linux，適合作為桌面版主力客戶端。它將訂閱分組、節點選擇、系統代理、路由規則、TUN與日誌集中在同一個介面中，方便長期維護。Windows使用者可在新一代跨平台桌面介面與經典WPF介面之間選擇；兩者的核心任務相同，主要差異在介面技術與操作習慣。macOS需依處理器架構選擇對應安裝包，Linux則依發行版的套件格式選擇。

如果需要管理多個訂閱、為工作與日常使用保留不同分組，或準備學習自訂路由，v2rayN的桌面管理方式更合適。它允許先按訂閱來源分組，再在組內選擇節點。這樣更新某個來源時，不會把所有節點混成難以追蹤的清單。使用前應先釐清「分組是設定來源，節點是連線目標」，不要以頻繁重新命名節點取代分組管理。

Android版在v2rayNG與v2flyNG之間選擇

v2rayNG採用Xray核心路線，通常是Android版的首選；v2flyNG採用V2Fly核心，適合需要相應核心能力或設定相容性的情境。兩者都能完成訂閱匯入、節點切換及透過VPN介面接管流量，但選單名稱、路由選項與核心支援範圍並不完全相同。桌面版匯出的所有進階規則也不一定能原樣移轉到行動版，應以客戶端實際可辨識的欄位為準。

安裝包架構需要與裝置相符。多數較新的Android裝置使用arm64，通用版則適用於無法確認架構或需要相容其他架構的情況。架構只影響安裝包能否執行，不會改變訂閱內容與協定參數。若arm64版本能正常安裝，就沒有必要因為連線問題改用通用版；連線異常應回到日誌、節點參數與網路條件進行排查。

不要用切換客戶端掩蓋設定問題

同一份設定在不同客戶端中的表現可能不同，但更換客戶端不應成為第一個排錯動作。先記錄協定、傳輸、安全參數與錯誤日誌，再判斷是否屬於核心能力差異。如果設定在某個客戶端中無法匯入，應檢查分享格式是否完整；如果能匯入但啟動失敗，應查看產生的設定或核心日誌；如果只有特定網路環境失敗，應比較網路鏈路與DNS，而不是直接判定客戶端不相容。

完成客戶端選型後，建議固定一個主力工具，熟悉其日誌入口、設定目錄與復原方式。頻繁在多個客戶端之間反覆匯入，會產生重複節點、過期分組與不同的路由預設值，使後續判斷更加困難。桌面版以v2rayN作為管理中心，行動版則依核心需求選擇v2rayNG或v2flyNG，是較清晰的組合。具體安裝入口與系統架構說明可在客戶端下載頁按平台查看。

安裝與初始設定：先建立可復原的基準

下載前確認系統與處理器架構

Windows需先決定使用桌面版或經典WPF版。希望在不同桌面系統間維持相近介面時，可選桌面版；習慣傳統Windows操作方式時，可選WPF版。macOS裝置要區分Apple Silicon與Intel處理器，安裝包架構選錯通常會無法啟動，或需要額外相容處理。Linux使用者應依發行版選用deb或rpm套件，並繼續區分x64與arm64。Android版則優先確認裝置是否為arm64，無法確認時再考慮通用版。

安裝目錄應確保目前使用者具備讀寫權限。客戶端執行時通常需要儲存訂閱、日誌、路由設定與介面設定，放在受嚴格限制的目錄可能導致更新後無法寫入設定。Windows可攜式使用情境也應避免長期將程式放在臨時解壓縮目錄；macOS首次啟動後應確認應用程式能儲存設定；Linux安裝完成後要從應用程式選單或終端機確認程式能正常啟動，而不是只根據套件安裝成功來判斷。

首次啟動只設定必要項目

首次開啟v2rayN時，先確認介面語言、設定儲存位置與日誌入口，不要立即啟用所有進階選項。建議保留預設路由、關閉TUN、暫不設定開機自動連線，只完成一次最小連線測試。最小基準包含四項：客戶端能正常啟動、訂閱能夠匯入、選定節點後核心能夠執行、瀏覽器在開啟系統代理後能透過客戶端存取目標網址。只有這四項穩定後，再加入自動更新、開機啟動與自訂分流。

系統時間是容易忽略的基礎條件。某些安全連線對時間偏差相當敏感，裝置時間或時區明顯錯誤時，可能出現憑證驗證與握手問題。先開啟系統自動校時，再排查協定參數。代理連接埠也應避免與本機其他程式衝突。若日誌提示監聽位址已被使用，先關閉舊客戶端或查明佔用程式，不要連續修改多個連接埠，因為瀏覽器或其他應用程式可能仍引用舊連接埠。

認識設定目錄與退出方式

關閉圖形視窗不一定代表客戶端程序已退出。桌面客戶端常駐系統匣時，關閉視窗後核心與系統代理可能仍在執行。修改安裝目錄、替換程式檔案或還原備份前，應從系統匣選單執行退出，並確認相關程序已結束。如果只關閉視窗就直接移動目錄，可能出現檔案被占用、設定寫入中斷或系統代理仍指向舊連接埠等問題。

設定目錄通常包含客戶端設定、節點資料庫、訂閱資訊、路由規則與日誌。備份時應在客戶端完全退出後複製整個設定目錄，而不是只匯出目前節點。只儲存分享連結無法保留分組、自訂路由與介面設定；只複製程式目錄又可能遺漏由系統儲存的使用者資料。具體位置會隨平台與客戶端形式而異，因此應優先使用客戶端提供的開啟設定目錄或備份功能，再記錄實際路徑。

首次安裝檢查順序
1. 確認系統與處理器架構
2. 安裝或解壓縮到可長期使用的位置
3. 啟動客戶端並找到日誌入口
4. 保持預設路由，暫不啟用TUN
5. 匯入一個訂閱並選擇一個節點
6. 開啟系統代理，完成瀏覽器測試
7. 退出客戶端，確認系統代理已復原

退出測試非常重要。正常退出後，如果系統仍保留指向本機代理連接埠的設定，一般網路請求可能受到影響。再次啟動客戶端時，應檢查系統代理狀態與介面顯示是否一致。若不一致，先使用客戶端的清除系統代理功能，再到系統網路設定中確認。不要把「重新啟動裝置後恢復」當作常規操作；理解代理開關與程序狀態後，絕大多數情況都能直接修復。

訂閱與節點：匯入、更新、分組與篩選

訂閱匯入不是一次性複製節點

訂閱網址用於持續取得節點清單。手動貼上單一分享連結適合臨時測試，長期使用則應將訂閱儲存到獨立分組。匯入前先檢查網址是否完整，尤其注意複製過程是否帶入前後空格、換行或通訊工具附加的標點。訂閱名稱應表達來源或用途，例如「日常訂閱」與「測試設定」，不要用目前節點名稱作為訂閱名稱，因為節點會更新，而來源關係需要保持穩定。

在v2rayN中新增訂閱後，應先儲存訂閱設定，再執行更新。有些使用者把「新增訂閱」和「更新訂閱」視為同一個步驟，結果只儲存了網址，卻沒有產生節點。更新完成後核對三個結果：目標分組是否出現、組內是否有節點、原有手動節點是否仍在獨立分組中。若更新後整個清單為空，不要立即再次覆蓋更新，應先查看訂閱日誌，判斷是回應為空、格式無法解析，還是分組篩選隱藏了結果。

更新策略要兼顧變動與可追蹤性

自動更新間隔不宜設定得過短。訂閱內容通常不需要以分鐘為單位重新整理，頻繁請求不但難以帶來實際收益，還會讓節點清單在排錯過程中不斷變動。可依設定來源的更新頻率設定數小時至一天的間隔，並保留手動更新入口。準備排查某個節點時，先暫停自動更新或記錄節點的關鍵參數，避免測試過程中名稱、位址或排序被遠端清單改變。

更新訂閱與測試節點是兩個獨立動作。更新只確認設定清單可以取得，連線能力測試才會呼叫具體節點。測試結果也要區分TCP連通性、實際連線延遲與下載速度。TCP連通只能代表目標位址與連接埠有回應；實際連線延遲還包括協定握手；下載速度則受到頻寬、伺服器負載與目標資源影響。可繼續閱讀延遲測試的差異與使用順序，避免只依一個數字排序。

分組、去重與失效設定處理

多個訂閱應分別建立分組，不建議將節點全部複製到預設組。分組能回答「這個節點來自哪裡」、「更新哪個訂閱會改變它」、「刪除某個來源時是否會誤刪手動設定」等問題。手動新增的節點也應放在專用分組，避免訂閱重新整理時被同名項目覆蓋。若客戶端提供依別名、位址或完整參數去重的功能，應先了解其規則；兩個名稱相同的節點可能參數不同，而兩個名稱不同的節點也可能指向同一份設定。

失效節點不必立即逐一刪除。先執行一次訂閱更新，確認它是否已從遠端清單移除；再透過日誌判斷是持續失效，還是目前網路暫時無法連線。若某個節點需要保留作為對照，可複製到手動分組，並標註日期或用途。長期累積大量失效設定會增加誤選機率，也會讓批次測試耗時，因此維護時應定期清理不再屬於有效訂閱的孤立節點。

代理模式：系統代理、應用程式代理與連線驗證

系統代理只影響願意讀取它的應用程式

v2rayN開啟系統代理後，會將作業系統中的HTTP或SOCKS代理指向客戶端監聽的連接埠。瀏覽器與多數遵循系統網路設定的應用程式會將請求交給客戶端，但部分程式使用自己的網路堆疊，可能忽略系統代理。因此可能出現瀏覽器正常、命令列工具或特定應用程式仍直接連線的情況。這不是路由規則失效，而是流量根本沒有進入客戶端。

判斷應用程式是否進入代理，最直接的方法是查看客戶端存取日誌。操作目標應用程式時，如果日誌完全沒有相關連線，應檢查該應用程式的代理設定，或在需要接管更多流量時評估TUN模式。如果日誌出現連線，但出口與預期不同，再檢查路由規則。不要只根據網頁能否開啟來判斷系統代理狀態，因為快取、既有連線與應用程式內建代理都可能干擾結論。

PAC、自動設定與全域代理的差異

客戶端介面中的「自動設定」、「PAC」或「全域」描述的是系統層如何將請求交給本機代理，不應與核心路由模式混為一談。PAC透過規則指令碼決定哪些網域使用系統代理；全域系統代理則讓支援系統代理的請求全部進入客戶端。請求進入客戶端後，仍可能被核心路由判定為直連。因此，「系統代理全域」與「路由全域代理」是兩個不同的開關。

首次測試建議使用明確且容易觀察的組合：開啟系統代理，核心路由暫時使用預設規則，選擇一個已確認參數完整的節點。若要驗證某個應用程式是否支援系統代理，可先暫時使用全域系統代理，再查看日誌。驗證完成後再切回日常模式。頻繁同時切換PAC、路由規則與節點，會無法確認究竟是哪一項改變了結果。

既有連線、快取與驗證方法

切換節點或路由模式後，已建立的長連線不一定會立即轉移。瀏覽器可能繼續重用舊連線，DNS也可能保留舊的解析結果。測試時應關閉目標頁面的現有連線，必要時重新啟動應用程式，再發起新的請求。只重新整理頁面有時仍會重用連線，因此比較兩個節點時應使用相同目標、相同應用程式狀態與相近時段。

Windows需要清除本機DNS快取時，可以使用系統命令，但這不是每次切換節點都必須執行的步驟。只有在網域解析結果明顯過時、修改DNS設定後仍使用舊位址等情況下才需要執行：

ipconfig /flushdns

macOS與Linux的DNS快取由系統服務管理，具體命令會隨系統版本與發行版而變化。比起盲目執行命令，更可靠的做法是先確認問題確實發生在解析層：同一網域在客戶端日誌中是否被解析、是否命中預期規則、直接使用已知位址時現象是否改變。若網域與位址的存取結果不同，再針對系統使用的解析服務處理快取。

退出客戶端前應復原系統代理，尤其是在程式異常結束或被強制終止後。若客戶端未執行，而系統代理仍指向本機連接埠，應用程式會表現為普遍無法連線。此時先在系統網路設定中關閉代理，再重新啟動客戶端檢查退出行為。確認基礎代理流程穩定後，再進入路由與TUN設定，能大幅減少變數數量。

路由分流：規則順序、匹配條件與驗證

路由規則由上至下進行匹配

路由分流的目標是讓不同請求進入不同出口。常見出口包括代理、直連與阻擋。規則通常依序匹配，前面的規則命中後，後面的規則就不再參與。因此，規則內容正確但位置錯誤，也會產生不符預期的結果。例如先放置一條涵蓋範圍很大的網域規則，後面針對單一網域的例外規則可能永遠無法執行。

設計規則時，應將明確且範圍較小的例外放在前面，範圍較大的預設規則放在後面。網域、IP、連接埠、網路類型與程序名稱屬於不同的匹配維度，不要在不了解邏輯關係時一次疊加過多條件。部分設定中，同一條規則內的多個欄位需要同時符合；另一些客戶端介面則會將條件展開成獨立規則。匯入外部規則後，應檢查客戶端最終產生的設定，而不只是查看介面上的規則名稱。

網域規則與IP規則的界線

網域規則依賴客戶端能看見原始網域。如果應用程式直接連線到IP，或網域在進入客戶端前已完成解析，規則只能依IP判斷。反過來，IP規則會受到解析結果與位址變化影響，同一個網域可能在不同時間回傳不同位址。較穩妥的策略是：對明確服務使用網域規則，對區域網路與保留位址使用IP規則，最後用預設出口接住未匹配的流量。

常見網域匹配包括完整網域、子網域後綴與規則集合。完整網域只匹配指定主機；後綴規則會涵蓋其所有子網域，範圍更大；規則集合方便維護某一類網域，但應了解其更新來源與涵蓋範圍。不要只憑名稱推測規則集合內容。修改規則後，透過日誌查看實際命中項目，才能確認請求是依網域、IP還是預設規則離開。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com",
          "full:service.example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

這個範例先讓區域網路與保留位址直連，再讓指定網域走代理，最後將尚未匹配的TCP與UDP流量交給代理出口。實際客戶端產生設定時，出口標籤可能使用不同名稱，不能直接複製範例中的標籤來覆蓋現有設定。應先查看客戶端目前出站項目的tag，再讓路由規則引用已存在的值。若標籤拼寫不一致，核心可能拒絕載入設定，或將請求交給預設出口。

從預設規則逐步增加例外

穩定的分流設定應從簡單結構開始。先使用客戶端預設的「繞過區域網路與中國大陸」或同類預設完成基礎驗證，再新增少量明確規則。每新增一組規則，就用對應目標網址測試並記錄命中結果。一次匯入大量規則後才排錯，往往無法判斷衝突來自順序、資料集、網域解析還是出口標籤。

程序分流適合處理不遵循系統代理、但能被客戶端辨識程序資訊的桌面應用程式。它與網域分流解決的問題不同：程序規則依應用程式來源決定出口，網域規則則依存取目標決定出口。如果同一個應用程式存取不同目標時需要不同策略，應以網域或IP規則為主；如果某個應用程式的所有流量都要使用固定出口，程序規則更直接。使用TUN時，程序辨識能力還會受到平台權限與客戶端實作影響。

規則驗證應查看日誌中的目標、入站、命中規則與出站。只觀察最終頁面結果，無法確認流量路徑。修改後應建立新連線，分別測試一個應直連的目標、一個應走代理的目標，以及一個區域網路目標。三類測試都符合預期，才能表示整體規則沒有被寬泛項目覆蓋。有關設定檔各部分的結構，可繼續閱讀inbounds、outbounds與routing逐段解析。

TUN模式：接管範圍、DNS與相容性

TUN可處理系統代理涵蓋不到的流量

TUN模式透過虛擬網路介面接收更大範圍的系統流量，適合不讀取系統代理的應用程式、需要處理UDP的程式，或希望統一套用路由規則的情境。它不是「更快模式」，也不會自動修復失效節點。TUN增加了網路堆疊、DNS與路由表三個變數，因此應在一般系統代理已驗證可用後再開啟。如果基礎節點連線本身失敗，啟用TUN通常只會讓現象更複雜。

開啟TUN時，客戶端可能需要提升權限，以建立虛擬介面並修改系統路由。權限不足會表現為建立虛擬介面失敗、寫入路由失敗，或啟動後沒有流量。應從客戶端日誌確認具體階段，不要只根據開關狀態判斷。Windows、macOS與Linux處理虛擬介面及系統權限的方式不同；系統升級或安全性策略變更後，也可能需要重新授權。

嚴格路由與繞過區域網路

TUN接管範圍擴大後，必須明確區域網路流量的處理方式。印表機、網路儲存裝置、路由器管理位址與本機開發服務通常需要直連。路由設定應優先放行區域網路與保留位址，避免它們進入遠端代理。若開啟TUN後無法存取本機裝置，先檢查私有位址規則是否存在且位於寬泛代理規則之前，再檢查虛擬介面是否改變了通往區域網路網段的路由。

嚴格路由用於降低流量繞過TUN的可能，但可能與虛擬化軟體、企業網路客戶端、容器網路或其他網路過濾程式發生衝突。出現衝突時不要立即關閉所有安全選項，應先確認是哪條路由或哪個虛擬介面重疊。記錄開啟TUN前後的路由表差異，再逐項調整繞過網段或介面優先順序。多個虛擬網路工具同時執行時，最後啟動的程式可能會重寫預設路由，導致結果隨啟動順序改變。

TUN中的DNS路徑

在TUN模式下，DNS請求也可能由客戶端接管。網域解析結果既會影響連線目標，也會影響IP路由匹配。若設定使用FakeDNS，客戶端會先向應用程式回傳保留位址，再在內部還原原始網域並選擇實際出口。這種方式有利於保留網域資訊，但某些依賴真實IP的應用程式可能不相容。若出現網域可解析但應用程式連線異常，應檢查是否與FakeDNS行為有關，而不是直接更換節點。

如果不使用FakeDNS，就需要明確DNS伺服器請求要走直連還是代理，並避免形成迴圈：DNS請求被送入代理，但代理建立連線前又必須依賴同一個DNS結果。客戶端預設設定通常會避免基本迴圈，自訂時則要保留一個可用於解析節點伺服器位址的引導DNS。節點位址本身若是網域，這點尤其重要。

安全開啟與復原步驟

開啟前先儲存目前設定，退出其他會修改路由的網路工具，並記錄一般系統代理下可用的節點。接著啟用TUN，確認虛擬介面建立成功，再測試區域網路、網域解析、TCP與UDP應用程式。若失敗，先關閉TUN並確認基礎網路恢復；如果關閉後仍異常，應退出客戶端，檢查殘留的虛擬介面、系統代理與預設路由。不要在網路尚未恢復時連續重裝客戶端，因為殘留路由通常無法靠重新安裝解決。

日常維護：更新、備份、日誌與速度排查

將客戶端更新與訂閱更新分開

客戶端更新會改變程式介面、設定轉換邏輯與核心管理方式；訂閱更新只會改變節點清單。兩者應分別安排，並保留復原途徑。更新客戶端前先退出程式、備份設定目錄，並記錄目前可用模式。更新完成後先使用原有節點與原有路由測試，不要同時重新整理訂閱。如此若發生異常，就能判斷變化來自程式更新，而不是遠端設定變更。

訂閱更新則應保留分組結構，並留意更新後新增、移除與重新命名的項目。某個常用節點消失時，應先確認訂閱來源是否調整了清單，不要從舊快取反覆複製回主分組。若必須保留舊設定作短期對照，可複製到手動分組並標註用途。對照結束後及時清理，避免之後誤選過期參數。

備份內容與復原演練

有效備份至少應包括訂閱設定、手動節點、路由規則、客戶端偏好與必要的本機設定。日誌通常不需要長期完整保存，但發生可穩定重現的問題時，應保留包含啟動階段與錯誤時刻的片段。備份檔案應放在不同於程式目錄的位置，並在客戶端退出後製作，以減少資料仍在寫入所造成的不一致。

只製作備份而從未測試復原，無法確認備份是否完整。可以在更新前記錄設定目錄位置，並檢查備份中是否存在最近修改的分組與路由檔案。復原時先安裝可執行的客戶端，再在程式退出狀態下放回設定，接著從預設路由開始驗證。不要反覆混合覆蓋新舊設定目錄，否則很難判斷客戶端最終讀取的是哪一份檔案。

日誌要從第一筆錯誤開始閱讀

核心日誌常會在一個基礎錯誤後產生多筆連鎖訊息。例如設定欄位無效會導致核心退出，接著客戶端繼續回報連線本機連接埠失敗。真正需要處理的是最早出現的設定錯誤，而不是最後一筆「連線被拒絕」。閱讀時從核心啟動位置開始，依序關注設定載入、監聽連接埠、DNS初始化、出站連線與協定握手。

分享日誌前應刪除訂閱網址、使用者識別碼、伺服器位址等設定內容，只保留錯誤類型、時間順序與必要上下文。排查時不需要公開完整設定。對於重複錯誤，可以記錄觸發動作，例如「更新訂閱後出現」、「開啟TUN後出現」或「僅某個節點出現」。觸發條件比單獨截取最後一行更有判斷價值。

速度慢要按本機、節點與線路分層排查

速度問題不應先靠反覆測速來解決。第一層檢查本機設定：是否誤用全域代理、路由是否讓大流量工作進入不合適的出口、TUN是否與其他虛擬網卡衝突、裝置是否有背景下載。第二層比較節點：在相同時段、相同目標與相同代理模式下測試兩個節點。第三層觀察線路：比較不同時段以及不同網路接入方式，判斷波動是否與壅塞有關。

延遲低不代表下載速度高。延遲反映一次連線或請求的等待時間，吞吐量則同時受頻寬、壅塞控制、封包遺失與伺服器負載影響。影片卡頓也可能與DNS、分片及持續連線穩定性有關。完整的分層方法可參考V2Ray速度慢分層排查。測試時一次只變更一個條件，並記錄節點、模式、目標與時間，才能得到可比較的結果。

進階路線：從會用客戶端到讀懂設定

先讀懂入站、出站與路由的關係

進階學習不需要從記住所有JSON欄位開始。先建立三段式模型：入站接收應用程式流量，出站決定流量如何離開，路由則在兩者之間作選擇。系統代理通常連接本機HTTP或SOCKS入站；TUN對應虛擬網卡入站；代理節點、直連與阻擋則分別對應不同出站。路由規則依據網域、IP、連接埠、網路或程序資訊，將請求交給某個出站。

理解這個模型後，介面選項就能對應到設定結構。修改本機監聽連接埠是在調整入站；切換節點是在更換代理出站參數；選擇繞過區域網路是在調整路由規則；啟用TUN則是新增或啟用另一類入站。遇到錯誤時，可以根據日誌判斷哪一段尚未建立，而不是把所有問題歸類為「節點無法使用」。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

這段範例展示一個僅監聽本機的SOCKS入站，以及直連與阻擋兩個基礎出站。它不是完整的代理設定，不能取代訂閱產生的節點出站，但適合用來觀察欄位關係。監聽位址使用127.0.0.1表示只接受本機連線；若改成其他位址，可能擴大可存取範圍，需要同時考慮本機防火牆與網路邊界。手動修改客戶端產生的檔案前，應確認該檔案是否會在下次啟動或切換節點時被覆寫。

學會建立最小重現

處理複雜故障最有效的方法是縮減設定。先保留一個節點、一個本機入站、最簡單的預設路由與明確的DNS設定，確認問題是否仍然存在。若最小設定可用，再逐項恢復訂閱分組、自訂規則、TUN、程序分流與自動更新。恢復到哪一步重新出現問題，就集中檢查該層。最小重現並不是刪除原始設定，應先備份，再於副本中操作。

協定問題也應按欄位分組驗證。先核對位址、連接埠與使用者識別碼，再核對傳輸方式，最後檢查TLS、REALITY、主機名稱、路徑等組合參數。不確定時不要使用隨機值嘗試，因為這些欄位由伺服器設定決定。若日誌提示握手、憑證名稱或傳輸路徑錯誤，應回到對應的參數組，而不是調整路由規則。

建立自己的變更記錄

當設定從預設範本逐步發展成自訂規則時，應保留簡單的變更記錄。記錄日期、修改目的、涉及規則、驗證目標與回退方式即可。例如「為本機開發網域新增直連規則，驗證本機服務與一般網站」、「為特定應用程式新增程序規則，失敗時刪除此規則」。這類記錄能說明某個例外為何存在，也能避免數月後誤將必要規則當成多餘項目刪除。

手動調整設定檔時，先使用格式驗證工具確認JSON語法，再檢查標籤引用。JSON不允許註解，最後一個陣列項目後也不能保留多餘逗號。語法正確仍不代表語意有效：路由引用不存在的出站標籤、連接埠被占用、協定欄位放在錯誤層級，都會導致核心無法啟動。客戶端日誌中的設定路徑與錯誤位置是主要依據。

完整排錯樹

1. 客戶端無法啟動：檢查系統架構、目錄權限、相依元件與舊程序占用。
2. 訂閱無法更新：檢查網址完整性、訂閱回應、解析格式與目標分組。
3. 核心無法執行：從第一筆設定錯誤開始，檢查連接埠、欄位與核心支援情況。
4. 應用程式沒有日誌：檢查系統代理與應用程式代理能力，必要時再評估TUN。
5. 有日誌但出口錯誤：檢查規則順序、網域與IP條件、出站標籤。
6. 只有網域失敗：檢查DNS接管、快取、引導解析與FakeDNS相容性。
7. 連線可用但速度慢：依本機設定、節點負載與線路波動分層比對。

完成這條進階路線後，應能獨立回答四個問題：流量從哪個入口進入、命中了哪條規則、使用哪個出口離開、失敗發生在哪個階段。客戶端介面仍是日常操作中心，設定檔與日誌用於解釋行為，不需要為了進階而放棄圖形客戶端。需要重新核對首次安裝項目時，可參考v2rayN首次安裝設定清單；需要重新走最短操作路徑時，回到快速入門文件。