V2Ray 從入門到進階完整設定手冊

01

建立模型

核心概念：客戶端、核心與流量路徑

先區分圖形客戶端與代理核心

v2rayN、v2rayNG 和 v2flyNG 是面向不同平台的圖形客戶端。它們負責儲存訂閱、顯示節點、產生執行設定、修改系統代理，並將啟動與停止操作整合成可見介面。真正處理連線、協定、傳輸與路由的是客戶端呼叫的核心。v2rayN 可在桌面系統中管理相應核心；v2rayNG 以 Xray 核心為主要執行元件；v2flyNG 對應 V2Fly 核心。排錯時必須分清問題發生在介面層、系統代理層還是核心層。介面顯示已啟動，只能代表程序已執行，不能單獨證明目標應用程式的流量已進入本機代理。

Project V 是由相關協定、工具與實作構成的技術生態，V2Fly 與 Xray 則是其中常見的核心家族。對一般使用者而言，核心差異主要體現在協定支援、設定欄位與傳輸組合。選擇客戶端時不必先研究每個底層欄位，但訂閱中的節點協定必須能被目前核心識別。例如節點採用 VLESS 與 REALITY 組合時，客戶端與核心都必須支援相應欄位；僅看到訂閱成功更新，並不代表節點參數一定能正常執行。

用入站、出站與路由理解一次請求

V2Ray 設定可以先抽象成三個部分。入站負責接收本機應用程式送出的流量，常見形式是本機 SOCKS 或 HTTP 連接埠，也可以是由 TUN 接管的虛擬網路流量。出站決定流量下一步前往何處，通常至少包含代理出站、直接連線出站與阻擋出站。路由位於兩者之間，會依網域、IP、連接埠、網路類型或程序等條件選擇出站。理解這條鏈路後，許多介面選項就不再孤立：系統代理是在告訴應用程式使用哪個入站，節點選擇是在決定代理出站的參數，分流規則則負責將不同請求交給不同出站。

以瀏覽器造訪網站為例：瀏覽器會先依系統代理設定，將請求傳送到客戶端監聽的本機連接埠；核心取得目標網域後，從上到下檢查路由規則；符合代理規則時交由目前節點處理，符合直連規則時則由本機網路直接建立連線。如果瀏覽器沒有讀取系統代理、應用程式自行實作網路堆疊，或目標位址在規則判斷前已被錯誤解析，流量路徑就會改變。因此，「客戶端執行中」、「系統代理已開啟」與「應用程式流量已被接管」是三個需要分別確認的狀態。

節點、分享連結與訂閱不是同一層級的物件

節點是一組能建立連線的參數，通常包含伺服器位址、連接埠、使用者識別、協定、傳輸方式、TLS 相關選項與伺服器名稱。分享連結是單一節點的序列化表示，例如以 vmess:// 或 vless:// 開頭的文字；訂閱網址則用來取得一批節點或分組設定，之後還能持續更新。訂閱本身不是代理伺服器，比較接近一份可重新整理的清單。刪除本機訂閱不會改變遠端內容，修改由訂閱產生的單一節點，也可能在下次更新時被覆蓋。

協定與傳輸也要分層理解。VMess、VLESS 等描述連線協定；TCP、WebSocket、gRPC 等描述承載方式；TLS、REALITY 等則負責特定的安全與握手組合。不同欄位必須與伺服器端設定一致，不能靠反覆切換本機選項猜測。需要進一步確認術語時，可查閱名詞解釋 →。先建立這套結構，再進入後續的安裝與設定階段，便能避免將「訂閱更新失敗」、「節點握手失敗」與「系統未接管流量」混為同一類問題。

02

準備環境

選擇客戶端並完成安裝

依平台與核心需求選擇客戶端

桌面端首選 v2rayN，支援 Windows、macOS 與 Linux，適合需要訂閱管理、系統代理、路由規則與 TUN 的使用者。Android 可選 v2rayNG 或 v2flyNG：v2rayNG 使用 Xray 核心，適合訂閱包含較新 Xray 協定組合的情況；v2flyNG 使用 V2Fly 核心，可作為 V2Fly 設定體系的對應選擇。三款客戶端的安裝入口、系統架構說明與安裝包類型集中在下載頁 →，不要只根據檔名中的相似字詞判斷平台。

Windows、macOS 與 Linux 的安裝注意事項

Windows 使用者需要先在桌面版與經典 WPF 版之間做選擇。桌面版採用跨平台介面，適合希望在不同桌面系統上維持一致操作方式的使用者；經典 WPF 版則適合習慣傳統 Windows 介面與既有設定流程的使用者。兩者都不應同時接管系統代理。更換版本前，先退出正在執行的客戶端，並記錄訂閱網址、路由設定與自訂連接埠。若系統匣仍有舊程序，應先正常退出，不要直接刪除正在使用的程式目錄。

macOS 安裝時最重要的是晶片架構。Apple Silicon 裝置應選擇對應 arm64 的安裝包，Intel 裝置則選擇 x64。可在系統資訊中查看晶片類型。首次啟動時，系統可能要求確認應用程式執行權限；啟用系統代理或 TUN 時，也可能出現網路設定授權。授權僅用於寫入相應的系統網路設定，取消授權後，相關模式通常無法完整啟用。若應用程式被移到其他目錄，系統記錄的路徑可能改變，建議固定放置後再設定開機啟動。

Linux 使用者首先依發行版選擇 deb 或 rpm 套件，再確認處理器架構。Debian、Ubuntu 及其衍生發行版通常使用 deb；Fedora、Rocky Linux 等常見 rpm 系發行版則使用 rpm。不同桌面環境的系統代理介面有所差異，客戶端寫入設定後，應在桌面網路面板重新確認 HTTP、HTTPS 或 SOCKS 代理是否指向本機監聽位址。僅在終端機中執行的程式通常不會自動讀取桌面代理，可能還需要明確設定環境變數或使用 TUN。

Android 安裝與背景執行條件

近年的主流 Android 裝置通常使用 arm64，無法確認架構時可選擇通用安裝包。安裝完成後，首次建立連線會觸發系統網路連線授權，這是建立本機網路接管所需的標準步驟。v2rayNG 與 v2flyNG 不應同時保持連線狀態，否則後啟動的客戶端會佔用系統提供的網路接管通道。切換客戶端前，先中斷目前連線，再匯入同一份訂閱進行相容性比較。

行動系統可能在螢幕關閉後限制背景程序。若連線在鎖定螢幕一段時間後中斷，應檢查客戶端的電池使用策略、背景活動權限與省電規則，不要先修改節點參數。行動網路與無線網路切換會使既有連線失效，核心需要重新建立出站；此時短暫中斷屬於網路環境變化，持續無法恢復才需要查看記錄。將客戶端固定在最近使用的工作清單，或允許背景活動，可減少系統回收造成的中斷。

安裝後先做基本檢查

完成安裝後先啟動客戶端，但暫時不要開啟 TUN、複雜路由或自訂 DNS。確認介面能正常開啟、核心元件能啟動、記錄目錄可寫入，並記下預設本機連接埠。接著匯入一份確定有效的訂閱或節點，使用系統代理完成首次連線。最小設定能建立基準：如果此時運作正常，後續問題通常來自新增的路由、DNS 或 TUN 選項；如果最小設定已經失敗，則應先檢查訂閱、節點參數與本機連接埠占用。

03

建立設定

訂閱匯入、節點選擇與更新

匯入前確認訂閱網址的範圍

訂閱網址通常是一段 HTTPS 位址，客戶端透過它取得節點清單。複製時要保留完整路徑與查詢參數，不能只複製網域部分，也不要混用網頁顯示網址與訂閱介面網址。若網址前後帶有空格或換行，應在儲存前移除。訂閱是需要妥善保管的設定入口，不應放進公開截圖、日誌貼文或其他人可讀取的同步文件。若訂閱提供者更換網址，應在客戶端中更新訂閱項目，而不是繼續修改由舊網址產生的節點。

在 v2rayN 中，通常先進入訂閱分組管理，新增訂閱名稱與網址，儲存後執行更新；在 v2rayNG 或 v2flyNG 中，則透過訂閱設定新增項目，再返回主介面重新整理。名稱只用於本機識別，可以填寫用途或環境名稱。匯入完成後應看到節點項目，而不只是訂閱分組。如果提示更新成功但清單為空，需查看回應內容是否確實是客戶端可識別的訂閱格式，以及目前的分組篩選條件是否隱藏了新項目。

訂閱更新會覆蓋哪些內容

訂閱節點由遠端清單產生，再次更新時，同一節點的伺服器、連接埠、協定與傳輸參數可能被替換。直接編輯訂閱節點只能用於臨時診斷，不適合作為長期修改方式。需要保留自訂節點時，應建立獨立的手動分組，或複製為本機節點並使用易於辨識的名稱。路由規則、系統代理模式與本機監聽連接埠通常屬於客戶端設定，不會因訂閱更新而自動變成遠端值；但某些訂閱可以附帶分組或規則資訊，實際情況應以匯入預覽為準。

合理的更新流程是：先停止正在進行的重要連線，執行訂閱更新，觀察新增、刪除與名稱變化，再選擇一個節點進行測試。不要在更新後同時修改 DNS、路由與代理模式，否則發生異常時很難判斷是哪項變更造成。若舊節點消失，應先確認訂閱清單是否已調整；若節點仍在但連線失敗，再查看協定欄位是否變更，以及核心是否支援。

選擇節點時不要只依賴單一測試結果

客戶端提供的連通性測試、延遲測試或實際連線測試，其檢測目標並不完全相同。TCP 連接埠可連線，只代表網路能到達指定連接埠；協定握手成功，才能進一步說明關鍵參數相符；目標網站可存取，還會受到 DNS、路由與目標服務狀態影響。因此，單一測試結果不能取代完整的存取驗證。較穩妥的方式是先選擇節點、啟動系統代理，再造訪已知可用的 HTTPS 頁面，同時觀察客戶端記錄中是否產生相應連線紀錄。

節點名稱有助於辨識用途，但不應視為協定事實。應在節點詳細資訊中確認 address、port、協定類型、傳輸方式、TLS 開關、serverName 與相關識別碼。若訂閱包含多種協定組合，優先選擇目前客戶端核心明確支援的節點。v2rayNG 與 v2flyNG 對同一份訂閱的可見項目可能不同，通常與核心支援範圍或訂閱轉換結果有關，不代表訂閱網址本身一定失效。

手動匯入分享連結與 JSON

單一節點分享連結適合臨時匯入或單獨測試。匯入前可先確認前綴是否為客戶端支援的協定，再使用「從剪貼簿匯入」之類的入口。一次複製多個連結時，應確保每行只有一個完整連結。JSON 設定包含更完整的入站、出站、路由與 DNS 資訊，通常不應直接與圖形客戶端自動產生的設定混用。若客戶端提供「自訂設定」功能，應將其放在獨立設定項目中執行，以免自動節點設定覆蓋其中欄位。

{
  "address": "server.example.com",
  "port": 443,
  "id": "11111111-2222-3333-4444-555555555555",
  "security": "auto",
  "network": "tcp",
  "tls": "tls",
  "serverName": "service.example.com"
}

上方欄位只展示節點參數之間的關係，不代表可直接連線的服務。實際設定中，位址、連接埠、使用者識別、傳輸方式與伺服器名稱必須與伺服器端一致。出現握手錯誤時，應逐項核對，不要任意更換加密或 TLS 選項。想進一步了解分享連結與訂閱的差異，可閱讀vmess 連結與訂閱網址的差異 →。

04

接管流量

系統代理、本機連接埠與應用程式範圍

系統代理改變的是應用程式的存取入口

系統代理模式會將作業系統中的代理位址指向客戶端的本機監聽連接埠。支援讀取系統代理的瀏覽器與桌面應用程式，之後會將請求交給該連接埠，再由核心執行路由與出站連線。它不會自動改寫所有網路封包，也不能保證每個程式都遵循系統設定。某些命令列工具、遊戲、虛擬機器、容器與自行實作網路堆疊的程式可能忽略系統代理。遇到「瀏覽器可用、另一個程式不可用」時，首先檢查目標程式是否支援 HTTP 或 SOCKS 代理，不要先懷疑節點。

客戶端介面中常見「清除系統代理」、「設定系統代理」與「不變更系統代理」等狀態。設定系統代理適合一般桌面應用程式；清除代理用於退出時還原系統網路；不變更則只啟動本機連接埠，由使用者在特定應用程式中手動填寫。退出客戶端前應使用正常退出流程，讓客戶端還原先前設定。若程式被強制結束，系統可能仍保留指向本機連接埠的代理位址，導致客戶端關閉後網頁無法存取。此時應重新開啟客戶端並清除系統代理，或在系統網路設定中手動還原。

HTTP、SOCKS 與混合連接埠的差異

HTTP 代理適合瀏覽器與支援 CONNECT 的應用程式；SOCKS 代理能承載更通用的 TCP 請求，也可依應用程式實作處理網域解析。部分客戶端提供混合連接埠，讓同一個監聽位址識別 HTTP 與 SOCKS 請求。連接埠號碼本身不代表協定能力，關鍵在於該連接埠對應的入站類型。手動設定應用程式時，必須讓應用程式選擇的代理類型與客戶端監聽類型一致。把 SOCKS 連接埠填入只接受 HTTP 代理的欄位，通常會立即連線失敗。

命令列工具應明確確認代理變數

在 Linux、macOS 或 Windows 終端機中，許多工具不會自動讀取桌面代理設定。可以針對目前命令或目前終端機工作階段設定代理環境變數。以下範例假設客戶端的 HTTP 入站監聽於本機 10809 連接埠；實際使用時應以客戶端介面顯示的數值為準。環境變數名稱可能因大小寫與工具而異，設定後應透過工具本身的詳細輸出確認是否已採用。

export http_proxy="http://127.0.0.1:10809"
export https_proxy="http://127.0.0.1:10809"

curl -I https://example.com

unset http_proxy
unset https_proxy

如果使用 SOCKS 入站，部分工具支援 socks5h://127.0.0.1:10808。其中帶有 h 的形式通常表示網域解析也會透過代理端處理，有助於避免本機解析結果與路由預期不一致。並非所有程式都能識別這種寫法，因此應查閱程式本身的參數說明。不要在確認該連接埠會隨客戶端穩定啟動前，就將環境變數永久寫入全域啟動檔案；否則客戶端停止後，所有繼承這些變數的終端機程式都會持續嘗試連線到不存在的本機服務。

確認本機連接埠是否確實監聽

當應用程式回報「連線遭拒」時，應先檢查本機入站，而不是遠端伺服器。Windows 可使用 PowerShell 查看監聽狀態，Linux 可使用 ss。如果連接埠沒有監聽，可能是核心未啟動、設定產生失敗、連接埠被其他程序占用，或安全策略阻止繫結。若連接埠正常監聽但完全沒有存取記錄，表示應用程式流量沒有進入該入站；若有入站記錄並出現遠端握手錯誤，才進一步排查節點參數。

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 10808,10809

ss -lntp | grep -E '10808|10809'

同時執行多個客戶端時，不要讓它們使用相同的本機連接埠，也不要讓兩個客戶端同時寫入系統代理。建議為測試中的第二個客戶端使用不同連接埠，並讓系統代理指向目前需要驗證的其中一個。完成比較後，清理不再使用的監聽設定，避免開機啟動時發生連接埠競爭。代理模式的目標是建立清楚、可觀察的流量入口，而不是同時開啟所有開關。

05

控制出口

路由分流規則與比對順序

路由規則的本質是選擇出站

路由不會改變節點協定，只決定某類流量使用哪個出站。常見出站標籤包括 proxy、direct 與 block，分別代表代理連線、直接連線與阻擋。規則可以依網域、IP、連接埠、網路類型與入站標籤進行比對。圖形客戶端中的「全域」、「繞過區域網路」、「規則模式」等名稱，是對一組路由行為的介面封裝；真正的判斷結果仍取決於產生設定中的規則順序、條件與最終預設出站。

建立規則時，先寫目標明確的小範圍規則，再處理大範圍集合，最後保留預設去向。例如本機與區域網路位址通常應優先直連；明確需要阻擋的網域應放在一般代理規則之前；其餘請求再交給代理或直連。如果把涵蓋範圍很大的規則放在最上方，後面的細分規則就不會執行。排查「規則已寫入但未生效」時，第一項檢查就是是否已被更前面的規則比對到。

網域規則與 IP 規則處於不同的判斷階段

網域規則使用請求中的網域進行比對，可採用完整網域、子網域後綴、關鍵字或 geosite 分類。IP 規則使用目標 IP，可採用 CIDR 網段或 geoip 分類。請求是否同時具備網域與 IP 資訊，取決於入站協定、DNS 策略，以及是否執行網域解析。如果只依賴 IP 規則，核心可能需要先解析網域；若解析路徑與預期出站不一致，就可能形成迴圈或錯誤結果。因此，能穩定以網域表達的服務，優先使用網域規則；網路位址範圍再使用 IP 規則。

domain: 通常表示精確網域，full: 強調完整比對，keyword: 會比對包含指定文字的網域，範圍較寬，應謹慎使用。geosite: 與 geoip: 引用分類資料集合，適合管理大量規則，但分類資料需要隨客戶端資源更新。自訂規則應使用容易理解的名稱，並在外部文件中留下註解，避免幾個月後無法判斷某條規則的來源與必要性。

最小路由設定的結構

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

domainStrategy 決定網域規則未直接得出結果時，是否以及何時解析 IP。AsIs 傾向依原始網域進行比對，不主動為 IP 規則解析；IPIfNonMatch 會在網域規則未命中時解析 IP，再繼續檢查 IP 條件；部分核心還提供更積極的解析策略。選擇時要考量 DNS 設定與規則目標，不要把「解析更多」理解成一定更精準。如果現有網域規則已經完整，優先維持簡單策略；只有需要依目標網段分流時，再引入額外解析。

從簡單規則逐步擴充

第一次設定分流時，建議只保留三層：私人網路直連、明確網域規則，以及其他流量走預設出站。確認運作穩定後，再加入廣告阻擋、特定程序、連接埠或協定規則。一次加入大量來源不明的規則，會讓錯誤難以定位，也可能將軟體更新、區域網路裝置探索或 DNS 請求送往錯誤出站。每次新增規則後，至少驗證一個應直連的目標與一個應代理的目標，並在記錄中確認最終出站標籤。

連接埠規則適合處理目標連接埠明確的協定，但現代服務經常共用 443 連接埠，僅依連接埠無法區分具體網站。程序規則依賴平台與接管方式，在系統代理模式下不一定能取得完整程序資訊；TUN 環境的支援情況也受客戶端實作影響。不要將某個平台可用的程序規則直接複製到所有裝置。跨平台同步時，應優先同步網域與 IP 規則，再為各平台單獨維護程序條件。

路由排錯要查看最終命中結果

當某個網站走錯出口時，先記錄請求網域，再在日誌中尋找對應連線的 outbound 標籤。如果日誌只顯示 IP，需要檢查 DNS 與嗅探設定是否保留網域。接著從規則清單頂端開始，逐條判斷該網域或 IP 是否可能提前命中。暫時將目標網域加入第一條明確規則，可以驗證問題是否來自優先級；驗證完成後，再將規則移到合理位置，不要長期依賴頂端例外。

涉及中國大陸網路環境的境內直連與境外代理思路，可繼續閱讀路由分流規則實戰 →。設定前還應確認規則資料與客戶端資源處於可用狀態。路由是一套確定性的比對流程，只要保留目標、命中規則與出站標籤三項證據，就能逐層定位，不必反覆切換節點碰運氣。

06

涵蓋更多應用程式

TUN 模式、DNS 與路由表協作

TUN 用來處理系統代理無法涵蓋的流量

TUN 模式透過虛擬網路介面接收系統流量，再交由核心進行路由與轉送。它適合不讀取系統代理的應用程式、部分命令列程式，以及需要統一接管的桌面環境。相較於系統代理，TUN 更接近網路層，因此設定範圍也更廣：虛擬介面位址、系統路由、DNS 接管、MTU、繞過位址與權限都可能影響結果。首次使用 TUN 前，應先確認同一節點在一般系統代理模式下能夠連線，藉此區分節點問題與 TUN 環境問題。

啟用時，客戶端通常需要系統網路管理權限，用於建立虛擬介面與寫入路由。客戶端正常退出後應刪除這些暫存設定；若程序異常結束，可能留下舊介面或路由。出現「關閉客戶端後網路仍異常」時，可以先重新啟動客戶端並正常關閉 TUN，再檢查系統網路介面與預設路由。不要同時執行多個會修改虛擬網卡或路由表的網路工具，否則相同目標網段可能被不同規則反覆覆蓋。

DNS 決定路由能看見哪些資訊

應用程式存取網域時，必須先取得解析結果。如果 DNS 請求繞過客戶端，核心可能只能看到後續連線的 IP；若 DNS 請求由 TUN 接管，則可結合網域規則選擇解析伺服器與出站。設定目標不是讓所有查詢都走同一條路徑，而是讓解析結果、路由判斷與實際連線保持一致。例如準備直連的內部網域，應由能解析該內部區域的 DNS 處理；需要依網域代理的請求，則應確保核心仍能取得原始網域以進行規則比對。

常見異常包括：網域解析成功但取得無法連線的位址、DNS 請求被路由回本機入站而形成迴圈、應用程式快取舊結果、IPv6 結果優先但目前路徑不支援，以及瀏覽器啟用獨立 DNS 設定後繞過系統方案。排查時可先清除應用程式與系統的 DNS 快取，再查看客戶端日誌是否出現查詢紀錄。如果直接存取目標 IP 有回應但網域失敗，應優先檢查 DNS；若網域已解析且連線在握手階段失敗，則回到節點與傳輸參數。

Fake DNS 與實際解析的使用界線

部分 TUN 設定使用 Fake DNS：核心先向應用程式回傳一個保留位址，再透過對映關係還原原始網域並執行路由。這有助於保留網域資訊，也能減少應用程式繞過網域規則的情況。但它要求相關流量始終經過同一核心對映；若應用程式快取保留位址，並在客戶端停止後繼續存取，就會失敗。區域網路服務、需要真實 IP 的程式與某些點對點情境通常應加入排除範圍，不適合一律交給 Fake DNS。

是否啟用應由實際需求決定。一般瀏覽器與支援系統代理的應用程式已穩定運作時，沒有必要只為了「設定更完整」而開啟。需要涵蓋特定不遵循系統代理的程式時，可以先使用真實 DNS 的 TUN 設定，確認路由與 MTU 正常後，再評估是否引入 Fake DNS。每增加一個處理層，都應保留關閉後的對照結果。

MTU、IPv6 與區域網路繞過

MTU 決定虛擬介面單一封包可承載的大小。設定過大可能在部分網路路徑中產生分片或丟包，表現為小頁面可開啟、較大回應停滯；設定過小則會增加額外負擔。沒有明確症狀時，應保留客戶端預設值。若只在特定網路環境中出現 TLS 握手停頓或上傳失敗，可逐步降低 MTU 進行對照，每次修改後重建 TUN 介面並記錄結果，避免連續調整多個網路參數。

IPv6 需要同時從系統、DNS、節點與出站路徑四個層面看待。系統取得 IPv6 位址，不代表代理出站一定支援；DNS 回傳 AAAA 記錄後，應用程式可能優先嘗試 IPv6。若目前設定沒有完整的 IPv6 路由，應明確採用客戶端提供的策略，不要讓系統與客戶端形成一半啟用、一半阻擋的狀態。區域網路網段通常應直接繞過，確保印表機、路由器管理頁面、檔案分享與本機開發服務不會被送往遠端出站。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "port": "53",
        "network": "udp",
        "outboundTag": "dns-out"
      }
    ]
  }
}

範例表達的是規則關係：私人位址優先直連，符合條件的 DNS 流量交給專用出站。實際設定中必須同時定義名為 dns-out 的出站，否則規則引用會失敗。圖形客戶端可能自動產生這些結構，不應在不了解產生邏輯時直接覆蓋完整設定。需要自訂時，先匯出目前的執行設定，確認入站與出站標籤，再加入最小規則。

分四步啟用 TUN

第一步，在系統代理模式下驗證節點與訂閱；第二步，關閉其他會寫入網路路由的程式；第三步，啟用 TUN，但保留預設 DNS 與 MTU，測試瀏覽器、命令列工具與區域網路位址；第四步，再依據記錄新增 DNS 分流或繞過規則。如果某一步失敗，回到上一步確認，不要同時開啟 Fake DNS、修改 MTU、切換 IPv6 與匯入大量路由。穩定的 TUN 設定來自逐層驗證，而不是開關數量。

07

維持可用

日常維護、日誌閱讀與故障排除

將更新分成客戶端、核心、訂閱與規則資料

日常維護不是反覆重新安裝。至少需要關注四類物件：圖形客戶端負責介面與設定產生，核心負責協定執行，訂閱提供節點參數，規則資料提供 geosite 與 geoip 分類。它們的更新節奏不同，也可能由客戶端分別管理。發生問題時，應記錄最近變動的是哪一層。客戶端更新後介面行為異常，與訂閱更新後單一節點失效是兩種不同問題；規則資料過時則更可能表現為分類比對偏差，而不是所有節點同時無法啟動。

更新前保留訂閱名稱、自訂路由、本機連接埠與重要截圖。更新完成後，先用原有節點與簡單系統代理進行驗證，再恢復 TUN 或複雜規則。不要把客戶端更新、訂閱重新整理與路由大幅修改安排在同一次操作中。若需要回復，應回復最近發生變化的一項，並確認設定目錄是否仍相容。使用自動啟動的使用者還應確認更新後的啟動路徑沒有改變，系統匣中也不存在舊程序。

日誌應依時間與連線階段閱讀

有效日誌通常包含設定載入、入站監聽、DNS 查詢、路由結果、出站撥號與協定握手等階段。排查時先清除舊日誌或記下目前時間，再只執行一次目標操作。大量歷史紀錄會掩蓋真正的錯誤。看到 connection refused 時，要區分拒絕來自本機連接埠還是遠端位址；看到逾時，則要判斷發生在 DNS、TCP 建立連線還是協定握手；看到設定欄位錯誤，表示核心甚至尚未進入網路連線階段。

可以暫時提高日誌等級以取得詳細資訊，但長期維持過高等級會產生大量檔案，也可能記錄造訪網域等執行資訊。完成排查後應恢復一般等級。分享日誌前，應刪除訂閱網址、伺服器位址、使用者識別、驗證欄位與本機路徑，只保留錯誤類型、發生階段與必要上下文。不要只截取最後一行，因為真正原因可能出現在前面的設定載入或 DNS 紀錄中。

依現象選擇排查分支

系統時間、連接埠衝突與權限是常見的基礎問題

TLS 與 REALITY 等握手依賴正確的系統時間。裝置時間偏差明顯時，可能出現憑證時間或握手相關錯誤。應啟用系統時間同步，並確認時區設定正確。連接埠衝突則常發生在同時執行舊客戶端、測試版或其他本機代理時。透過系統命令查看監聽程序，比反覆更換隨機連接埠更直接。若決定修改連接埠，系統代理、應用程式手動代理與環境變數都要同步更新。

權限問題主要出現在 TUN、寫入系統代理、設定目錄與日誌目錄。一般系統代理通常不需要長期以高權限執行；TUN 建立虛擬介面時則可能需要系統授權。若程式只能在提升權限後啟動，應查看具體失敗的檔案或網路操作，不能把長期以高權限執行當作預設解決方案。設定目錄位於不可寫入的位置時，客戶端可能可以開啟，卻無法儲存訂閱與規則，關閉後所有修改都會遺失。

恢復網路時先撤銷接管，再處理節點

如果客戶端異常後整個系統都無法存取網路，首要目標是恢復本機網路設定。先關閉 TUN、清除系統代理，確認系統 DNS 與預設路由已恢復，再測試不經過客戶端的一般連線。只有基礎網路恢復後，才重新啟動客戶端檢查節點。若一開始就持續切換節點，可能保留錯誤的系統代理或虛擬路由，讓所有節點看起來都已失效。

行動端出現斷流時，先檢查網路是否從無線網路切換到行動網路、客戶端是否受到背景限制，以及系統網路接管指示是否仍存在。桌面端從睡眠喚醒後無法恢復時，可先停止連線再重新啟動核心，讓舊通訊端點與 DNS 狀態重新建立。若頻繁發生，再檢查開機啟動、睡眠策略與網路介面變化日誌。

建立每月維護清單

穩定使用後，每月執行一次簡單維護即可：更新訂閱並刪除確定失效的本機副本；檢查客戶端與核心是否有相容性更新；確認規則資料能正常載入；清理過大的日誌檔案；檢查開機啟動與系統代理退出後的還原狀態；驗證一個直連目標與一個代理目標的路由。修改記錄應寫明日期、變更項目與回復方式。如此發生故障時，就能從最近的變更開始排查，而不是重設整個環境。

如果準備更換裝置，可以匯出客戶端允許匯出的本機設定，同時另外記錄訂閱入口與自訂規則。在新裝置上先安裝對應平台的客戶端，再恢復訂閱，最後遷移路由與 TUN。不同作業系統的路徑、程序規則與網路介面名稱不應直接複製。快速操作可返回使用文件 →，客戶端差異可查看選型指南 →。

08

理解底層

進階路線與設定檔結構

從圖形選項對應到底層設定

進入進階階段，不必立刻放棄圖形客戶端。更有效的方式是先匯出或查看客戶端產生的執行設定，將介面中的本機連接埠、目前節點、路由模式與 DNS 選項對應到 JSON 欄位。系統代理對應的是作業系統設定，不一定會直接出現在核心設定中；本機 SOCKS 或 HTTP 連接埠位於 inbounds；節點與直連出口位於 outbounds；分流位於 routing；網域解析位於 dns。理解這些對應關係後，才能判斷某個介面開關是在修改設定檔，還是在修改系統環境。

客戶端通常會在每次啟動時重新產生執行設定，因此直接編輯暫存檔案可能在下次啟動後消失。需要長期使用自訂 JSON 時，應採用客戶端提供的自訂設定入口，或將修改寫入其支援的範本與路由編輯器。修改前先複製原始設定，並使用 JSON 解析工具檢查語法。JSON 不允許註解、尾隨逗號與未跳脫的特殊字元，這是許多「設定看起來正確但核心無法啟動」的直接原因。

最小設定包含哪些必要部分

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "service.example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

這份範例展示結構關係，不包含可連線服務。入站僅監聽 127.0.0.1，因此只接受本機請求；若改為監聽所有介面，就會擴大可存取範圍，必須同時考量防火牆與驗證。代理出站使用範例 VLESS 參數，實際使用時必須替換 address、port、id、傳輸與 TLS 欄位。direct 與 block 出站提供路由目標，規則先將私人位址交給 direct，未命中的流量則依核心預設行為選擇後續出站。

入站標籤與出站標籤是設定的連接點

tag 不負責加密或連網，它是設定內部的引用名稱。路由透過 outboundTag 選擇出站，也可以使用 inboundTag 限定某條規則只處理特定入站。標籤拼寫必須完全一致，重新命名時要同步修改所有引用。設定變複雜後，建議採用 socks-in、tun-in、proxy、direct、block 這類能表達用途的名稱，而不是數字編號。

多個入站可以使用不同的路由策略。例如，本機瀏覽器 SOCKS 入站使用一般規則，TUN 入站則額外處理 DNS；多個出站可以代表不同節點或不同連線方式。此時可以使用 balancers 或更複雜的路由結構進行組織，但沒有明確需求時不應增加。若節點切換已由圖形客戶端管理即可滿足需求，手動撰寫多個出站反而會讓訂閱更新難以同步。

先學會驗證設定，再擴充功能

設定驗證分為三層。第一層是 JSON 語法，確保括號、陣列、字串與逗號正確；第二層是核心設定檢查，確認欄位名稱、協定結構與標籤引用有效；第三層是執行驗證，確認連接埠監聽、路由命中與握手成功。語法通過不代表協定參數正確，程序啟動也不代表應用程式已使用該入站。每次增加一個出站或規則後，都應重新完成三層驗證。

複雜設定適合拆成可測試的小階段。先保留一個 SOCKS 入站與一個代理出站，確認手動指定代理的瀏覽器可以存取；再加入 direct 與基礎路由；之後加入 DNS；最後才增加 TUN。如果客戶端支援查看最終執行設定，應以最終檔案為準，因為介面範本可能自動補充 mux、日誌、策略或 DNS 欄位。想進一步逐段閱讀，可參考設定檔結構詳解 →。

協定選擇應以伺服器端參數與相容性為準

VMess 與 VLESS 都是生態中的常見協定。VMess 包含自身的驗證與資料處理機制，VLESS 結構較精簡，常與 TLS、REALITY 等安全層組合。客戶端無法單獨決定協定：伺服器端提供哪些參數，本機就必須使用相符的設定。效能差異也不能脫離網路品質、傳輸方式、加密層與裝置能力單獨判斷。一般使用者應優先確保核心支援、參數一致與連線穩定，再考量更細部的傳輸負擔。

當訂閱同時提供多種協定時，可以在相同網路環境下分別測試連線建立、長連線穩定性與行動網路切換後的恢復能力，不要只比較一次連接埠探測。涉及協定概念時，可閱讀VMess 與 VLESS 的差異 →。涉及 OpenWrt 主路由或旁路由部署時，應先理解裝置將負責的入站、透明接管、DNS 與路由職責，再查看OpenWrt 部署要點 →。

建立自己的進階順序

建議將後續學習拆成四個階段。第一階段能說明應用程式、系統代理、本機入站與遠端出站之間的路徑；第二階段能寫出私人網路直連、指定網域代理與阻擋規則，並根據日誌確認命中；第三階段能獨立處理 TUN、DNS、MTU 與區域網路繞過；第四階段才進入多入站、多出站、依程序分流或路由器透明接管。每個階段都應保留一份最小可用設定作為回復基準。

真正的「從零到進階」不是開啟所有選項，而是能判斷一個請求停在哪一層：應用程式是否送入本機連接埠，DNS 是否取得預期結果，路由命中了哪個出站，核心是否完成遠端握手。掌握這四個問題後，客戶端介面、JSON 設定與系統網路設定就能放進同一個模型中。需要重新選擇安裝包時，返回客戶端下載頁 →；需要依最短步驟重新設定時，返回快速入門文件 →。