V2Ray 從零到精通：v2rayN 完整設定

核心概念與流量路徑

先區分用戶端、核心與伺服器

使用 V2Ray 時最容易混淆的三個對象，是圖形用戶端、代理核心與遠端伺服器。v2rayN、v2rayNG、v2flyNG 屬於圖形用戶端，負責儲存訂閱、顯示伺服器清單、產生執行設定、切換代理模式，並將使用者操作轉換成核心能理解的參數。Xray 與 V2Fly 屬於核心家族，主要負責監聽本機連接埠、建立出站連線、執行路由比對，以及處理不同傳輸方式。訂閱提供者設定的遠端伺服器位於連線鏈路的另一端，接收用戶端發出的協定連線。圖形介面顯示「已啟動」，只代表本機核心程序正在執行，不表示遠端伺服器一定可連線；訂閱更新成功，也只代表網址回傳了可解析的內容，不表示其中每個節點都能建立連線。

理解這三層後，便可依邊界展開排錯：程式無法開啟，優先檢查用戶端安裝與系統相依元件；核心啟動失敗，查看本機日誌與連接埠占用；伺服器測試失敗，檢查節點參數、網路連通性與系統時間；瀏覽器仍使用原本的網路，檢查系統代理或 TUN 是否確實接管對應應用程式。把所有問題統稱為「節點不能用」會掩蓋關鍵線索，也容易導致反覆重裝。

一個請求如何離開應用程式

以 v2rayN 的系統代理模式為例，瀏覽器會先讀取作業系統的代理設定，再將請求交給 v2rayN 在本機監聽的 HTTP 或 SOCKS 入站連接埠。核心取得請求後，依照 routing 中由上而下排列的規則，檢查網域、IP、連接埠、協定或入站標籤。規則符合後，請求會送往指定出站：可以是目前選取的代理伺服器，也可以是 direct 直連出口，或 block 阻擋出口。若沒有符合任何規則，則進入設定中的預設出站。DNS 查詢可能在應用程式、系統或核心中進行，因此「網域符合直連規則但最後仍經由代理」這類現象，往往與網域解析結果及比對階段有關。

協定、傳輸層與安全層不是同一項參數

VMess、VLESS、Trojan 等名稱通常描述節點使用的代理協定；TCP、WebSocket、gRPC 等描述傳輸承載方式；TLS、REALITY 等則用於連線驗證或安全層。匯入節點後，這些欄位必須逐項與伺服器端設定相符，不能只保留位址與連接埠後自行組合。例如某個節點使用 VLESS、TCP 與 REALITY，flow、serverName、publicKey、shortId 等欄位可能共同決定連線是否成立。任意變更其中一項，都可能讓握手在送出實際請求前終止。對初學者而言，最穩妥的原則是完整匯入分享連結或訂閱，在尚未理解欄位意義前不要手動修改傳輸參數。

延遲、連通性與實際速度

用戶端中的延遲測試通常用於判斷目標是否可連線，以及握手大致需要多久，不代表持續傳輸速度。不同測試方式可能採用 TCP 握手、實際協定請求或指定網址，因此同一節點在不同用戶端出現不同結果並不罕見。延遲較低的節點可能在長連線中不穩定，延遲稍高的節點也可能擁有較充足的可用頻寬。選擇節點時，應同時觀察連續連線是否成功、網頁首個封包是否穩定、長時間使用是否頻繁中斷，而不是只依單次數值排序。建立這種分層理解，是後續訂閱管理、分流與 TUN 設定的基礎。

選擇用戶端並完成安裝

依作業系統平台選擇用戶端

桌面環境首選 v2rayN，支援 Windows、macOS 與 Linux，可管理訂閱、切換系統代理、設定路由及啟用 TUN，適合統一多台桌面裝置的操作方式。Android 環境首選 v2rayNG，採用 Xray 核心，介面依行動裝置的連線流程設計；需要使用 V2Fly 核心時，可選擇 v2flyNG。三款用戶端定位不同，不必在同一台裝置上同時執行。多個用戶端同時監聽相同本機連接埠，或同時嘗試接管系統代理，會造成難以判斷的連接埠衝突與狀態覆寫。

架構、安裝形式與目錄權限

安裝前先確認作業系統架構。Windows 常見桌面裝置使用 x64；macOS 應在「關於這台 Mac」中確認晶片類型；近年的 Android 主流裝置通常使用 arm64，但無法確認時可選擇通用版；Linux 可執行 uname -m 查看架構，輸出 x86_64 對應 x64，輸出 aarch64 對應 arm64。架構不相容時，常見現象是安裝程式拒絕執行、系統提示格式錯誤，或程式啟動後立即退出。

Windows 的 v2rayN 桌面版與經典 WPF 版應擇一作為日常入口。使用壓縮包形式時，應先完整解壓縮到具備寫入權限的固定目錄，再啟動主程式；不要直接在壓縮軟體的暫存預覽視窗中執行，否則設定檔、日誌與核心檔案可能無法穩定儲存。macOS 安裝完成後，從應用程式目錄啟動。Linux 使用 deb 或 rpm 安裝時，套件管理器會依系統規則放置檔案；出現相依性提示時，應先讓對應發行版的套件管理器處理相依性，而不是手動複製函式庫檔案。

第一次啟動應檢查什麼

首次啟動後先不要立即啟用 TUN。檢查主視窗是否正常顯示、設定頁面是否能辨識核心、日誌視窗是否持續出現錯誤，並確認本機監聽連接埠沒有被其他代理用戶端占用。接著匯入一份設定，選取該伺服器並執行用戶端提供的連線測試。只有一般系統代理路徑能穩定運作後，再進入路由與 TUN 章節。如此可將安裝問題與進階接管問題分開。

系統權限與安全提示的處理原則

安裝 TUN 驅動程式、修改系統代理與寫入防火牆規則，可能觸發系統權限確認。應先核對正在執行的程式名稱與操作來源，再完成授權。一般系統代理通常不需要長期使用系統管理員權限；TUN 因為需要建立虛擬網路介面，權限要求會較高。企業裝置若有統一網路政策，應先確認本機是否允許修改代理與網路介面卡。若啟動後只有特定帳戶無法儲存設定，應優先檢查程式目錄寫入權限與帳戶設定目錄，而不是直接修改協定參數。

完成安裝後，可在用戶端下載頁核對目前平台對應的用戶端類型與安裝形式。安裝階段的目標不是一次設定所有功能，而是建立一個能穩定啟動、儲存設定並讀取日誌的基礎環境。之後每增加一項功能，都應保留回到這個基礎狀態的路徑。

訂閱匯入與節點管理

訂閱網址與單一節點分享連結

訂閱網址通常指向一份可更新的伺服器清單，用戶端請求該網址後解析出多個節點，並將其放入對應的訂閱群組。vmess、vless 等分享連結則描述單一節點的完整參數，適合臨時匯入或單獨儲存。兩者不能單靠外觀區分：訂閱網址可能是一般 HTTPS 連結，也可能帶有存取參數；單一節點連結通常以協定名稱開頭。不要把分享連結貼到訂閱網址輸入框，也不要把訂閱網址當成單一節點內容處理。

在 v2rayN 中，先進入訂閱群組管理，建立群組並填入訂閱網址，再執行「更新目前訂閱」或相應的訂閱更新選單。群組名稱應描述用途或來源，避免使用「訂閱一」、「訂閱二」這類日後難以辨認的名稱。v2rayNG 與 v2flyNG 的入口名稱可能略有不同，但操作關係相同：儲存訂閱網址、執行更新、返回設定列表、選取目標節點。更新前後的節點由用戶端依訂閱內容管理，手動修改訂閱節點欄位可能在下次更新時被覆寫。

訂閱更新失敗的分層檢查

更新後列表為空時，先查看日誌是「請求失敗」還是「解析失敗」。請求失敗表示用戶端未取得訂閱內容，應檢查網址是否完整、系統時間是否準確、目前網路能否存取訂閱網址，以及訂閱更新是否設定為經由目前不可用的代理出口。解析失敗表示伺服器有回傳內容，但格式不是用戶端預期的資料，常見情況包括網址過期、回傳登入頁面、缺少存取參數，或用戶端版本無法辨識新增欄位。可在不修改原群組的情況下建立測試群組，重新貼上完整網址，以排除舊欄位殘留。

若舊節點仍存在但更新持續失敗，不要立即刪除整個設定。先保留目前可用的節點，複製日誌中的第一個明確錯誤，再檢查訂閱連結。排查順序應為網址、網路請求、回傳內容、解析流程、節點連線，不要從更新失敗直接跳到重裝用戶端。更完整的檢查路徑可參閱訂閱解析失敗的常見原因與自我檢查清單。

節點測試應如何使用

批次測試適合清除明顯無法連線的項目，但不應將單次測試結果視為永久排序依據。先更新訂閱，再選擇一致的測試方式；完成後觀察失敗是否集中於同一種協定、同一組網域或同一伺服器區域。若同一訂閱內所有節點同時失敗，優先檢查本機網路、系統時間、核心狀態與訂閱參數；若只有少量節點失敗，再考慮節點本身的狀態。連續快速執行多輪測試可能造成連線壅塞，也會讓日誌混入大量並行錯誤，不利於定位。

分組、備註與更新策略

當訂閱數量增加時，應讓群組承擔邊界管理。不同來源放入不同群組；手動節點放入獨立群組；測試用的臨時節點加上清楚備註。自動更新週期不宜短到頻繁中斷正常使用，日常可依實際變化頻率設定，並保留手動更新入口。執行更新工作時若需要經由代理，應確保所依賴的目前節點可用，否則會形成「需要更新才能恢復節點，但更新又依賴失效節點」的循環。

訂閱網址本身可能包含存取憑據，不應貼到公開截圖、日誌分享或公開文件中。排錯時可以保留網域與錯誤類型，但應遮蔽查詢參數及路徑中的識別資訊。節點分享連結同樣包含完整連線參數，只應在受控裝置之間傳遞。合理的節點管理目標不是保留越多項目越好，而是讓來源、更新時間、常用節點與失敗原因都能快速辨認。

系統代理與代理模式

系統代理能解決什麼問題

系統代理是桌面端最適合優先掌握的接管方式。v2rayN 啟用系統代理後，會將作業系統的代理位址指向本機監聽連接埠。遵循系統代理設定的瀏覽器與桌面應用程式，接著會把請求交給核心處理。它的優點是邊界清楚、啟停直接、排錯成本低；限制是部分程式不讀取系統代理，某些遊戲、命令列工具或自帶網路堆疊的應用程式仍會直接連線。遇到單一程式未被接管時，應先確認該程式是否支援系統代理，再決定是否需要 TUN，而不是立即修改節點協定。

系統代理狀態與核心執行狀態是兩回事。可能出現核心已啟動但系統代理未開啟，也可能出現系統代理仍指向舊連接埠而核心已退出。正常關閉用戶端時，程式應恢復系統代理；若程式異常退出後瀏覽器無法連線，可進入作業系統代理設定，檢查是否仍保留指向本機的位址。重新開啟 v2rayN 並關閉系統代理，在許多情況下也能完成恢復。

全域、規則與直連的差異

「全域」通常表示將用戶端接管的流量統一送往代理出站；「規則」表示流量先經過路由比對，再依規則進入代理、直連或阻擋出口；「直連」表示被接管的流量直接從本地網路送出。關鍵限定是「被接管的流量」：若應用程式根本沒有進入系統代理，切換全域或規則就不會影響它。反過來，全域模式也不是讓裝置上的所有資料自動進入用戶端，只會改變核心內部的出站選擇。

透過對照測試確認接管鏈路

驗證代理模式時，不要只觀察系統匣圖示的顏色。先選取一個已確認可連線的節點，開啟系統代理，使用遵循系統代理的瀏覽器造訪測試頁面；接著切換為直連模式，再造訪同一頁面；最後關閉系統代理。若三種狀態毫無差異，應檢查瀏覽器是否使用獨立代理設定、系統代理位址是否指向目前連接埠，以及用戶端日誌中是否出現對應請求。若日誌有請求但連線失敗，問題位於路由或節點端；若日誌完全沒有請求，問題位於應用程式到本機入站之間。

命令列工具的行為需要單獨判斷。部分工具會讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 環境變數，而不會讀取桌面系統代理。臨時測試時可依工具文件設定代理位址，但不要照搬其他裝置的連接埠號碼，應以目前用戶端的本機監聽設定為準。修改監聽連接埠後，所有手動設定的環境變數與應用程式內代理也要同步更新。

區域網路存取與本機監聽

允許區域網路連線會讓用戶端的監聽位址，從僅本機可用擴展至區域網路介面。只有確實需要讓同一網路中的其他裝置使用這台電腦作為代理入口時才應啟用，並同時確認防火牆範圍、監聽位址與存取控制。一般單機使用維持僅本機監聽即可。若啟用後其他裝置仍無法連線，依序檢查監聽位址、系統防火牆、路由器的裝置隔離與連接埠填寫。不要為了排除問題而長期開放所有介面，因為這會改變原本清楚的本機邊界。

路由分流規則

規則依順序比對

路由分流的核心不在規則數量，而在比對順序。核心通常由上而下檢查規則，流量符合其中一條後便進入該規則指定的出站，後續規則不再處理。因此，更具體的例外規則應放在較寬泛的規則之前。例如某個網域必須走代理，但它所屬的網域集合預設直連，則單一網域的代理規則要排在集合直連規則之前。若先放入寬泛規則，後面的例外永遠不會生效。

常見的比對條件包括網域、IP、連接埠、網路類型、協定與入站標籤。domain 條件適合依完整網域、後綴或規則集比對；ip 條件處理解析後的目標位址；port 適合限定服務連接埠；inboundTag 可區分來自不同本機入口的流量。outboundTag 則決定符合後使用哪個出口。規則中的標籤必須與 outbounds 中實際定義的標籤一致，拼寫差異會導致設定檢查失敗，或使路由結果不符合預期。

一份精簡的 routing 範例

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com",
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

範例先讓私有位址走 direct，避免存取路由器、印表機或區域網路服務時繞到遠端；第二條將範例網域及指定集合送往 block；最後一條作為兜底，將剩餘的 TCP 與 UDP 流量送往 proxy。實際用戶端可能透過圖形介面產生等價設定，出站標籤名稱也可能不同，因此複製規則前要先查看目前設定中的標籤。範例中的最後一條非常寬泛，若放在第一條，區域網路直連規則便沒有比對機會。

domainStrategy 如何影響判斷

domainStrategy 決定路由階段在什麼情況下將網域解析為 IP。使用 AsIs 時，路由會優先保留原始網域，不為了 IP 規則主動解析；IPIfNonMatch 表示網域規則未符合時才解析 IP，以便繼續檢查 IP 規則；IPOnDemand 則會在規則需要 IP 時更積極地解析。選擇並非越積極越好，因為額外解析會引入 DNS 路徑、快取與解析結果差異。日常分流通常可以從 IPIfNonMatch 開始，再依日誌判斷是否需要調整。

從最小規則集開始

建立分流時先保留三類基礎行為：區域網路直連、明確需要代理的目標，以及其餘流量的預設處理。確認穩定後，再加入廣告阻擋、應用程式專用連接埠或複雜網域集合。每次只增加一組規則，並記錄它在規則列表中的位置。出現異常時，先切換至全域模式進行對照；若全域正常而規則模式失敗，表示節點本身大概率可用，問題應集中在路由條件、DNS 或出站標籤。

複雜設定可搭配V2Ray 設定檔結構逐段解析，理解 inbounds、outbounds 與 routing 的關係。排查分流時，應記錄「原始網域、解析位址、符合規則、目標出站」四項資訊，而不是只記錄網頁是否開啟。只要這四項能夠對應，路由行為通常就能被解釋並重現。

TUN 模式設定

TUN 與系統代理的接管差異

TUN 模式透過虛擬網路介面接收系統流量，能涵蓋更多不讀取系統代理的應用程式。系統會將符合路由條件的封包交給虛擬介面，用戶端再將其轉換後送入核心。由於它運作在比應用程式代理更低的網路層，DNS、UDP、區域網路存取、預設路由與防火牆都會參與結果。TUN 不是「更強的全域開關」，而是一種接管範圍更廣、設定變數也更多的執行方式。

啟用前應先完成三項確認：一般系統代理能透過目前節點穩定連線；路由規則在系統代理模式下結果正確；用戶端能以所需權限建立虛擬介面。若基礎鏈路尚未驗證，TUN 啟動失敗時便無法分辨是節點、規則、驅動程式還是系統網路問題。建議儲存一份關閉 TUN 時可用的設定，出現異常時先回復至該狀態。

啟用流程與必要檢查

在 v2rayN 的設定中啟用 TUN 後，系統可能要求提升權限並建立虛擬網路介面卡。完成授權後查看日誌，確認介面卡建立、位址分配、路由寫入與核心啟動都沒有錯誤。接著先造訪一般網頁，再測試需要 UDP 的應用程式，最後檢查區域網路裝置。不要一開始就同時開啟自訂 DNS、嚴格路由、複雜規則集與多個網路過濾工具，否則任何一步異常都會產生多個可能原因。

如果 TUN 顯示已啟動但所有網路都中斷，先關閉 TUN，確認基礎網路恢復；再檢查預設路由是否正確寫入、DNS 是否有可用出口、虛擬介面是否取得位址，以及其他安全軟體是否阻擋新介面。若只有瀏覽器正常而特定應用程式失敗，查看該程式使用 TCP 還是 UDP，以及路由規則是否阻擋了對應協定。若只有網域失敗而直接存取測試位址有回應，問題通常集中在 DNS。

DNS 與迴圈問題

在 TUN 情境下，必須避免用戶端自身發出的連線再次被 TUN 捕獲並送回用戶端，形成路由迴圈。成熟的用戶端會為核心程序、伺服器位址或特定出站設定繞行，但自訂規則可能破壞這層關係。典型表現是日誌反覆出現對同一伺服器位址的連線、CPU 使用率上升、連線快速失敗。此時應恢復預設 TUN 規則，確保代理伺服器位址透過實體網路介面直連，並確認核心出站沒有再次進入虛擬介面。

DNS 處理應維持單一且可解釋的主要路徑。系統 DNS、用戶端內建 DNS、瀏覽器內建解析與其他網路工具若同時生效，網域可能在不同位置得到不同結果。排查時可暫時關閉額外的應用程式層級 DNS 功能，使用用戶端建議的預設解析設定，觀察日誌中網域查詢從哪個入站進入、經由哪個出站返回。確認穩定後，再逐項恢復自訂策略。

休眠、切換網路與退出後的恢復

筆記型電腦從休眠恢復、在有線與無線網路間切換，或從一個網路切換到另一個網路後，虛擬介面與預設路由可能仍引用舊狀態。出現連線中斷時，可先停止 TUN，等待實體網路取得有效位址，再重新啟用。若用戶端異常退出後網路未恢復，檢查系統代理、虛擬介面與預設路由，不必立即刪除全部設定。Windows 可先關閉殘留的系統代理並重新啟動用戶端；Linux 可用 ip route 查看預設路由；macOS 可在網路設定中確認目前的服務順序。

TUN 設定完成的標準，不是圖示顯示「就緒」，而是一般網頁、UDP 應用程式、區域網路資源、休眠恢復與用戶端退出這五種情境都能得到可預期的結果。完成測試後記錄目前的 DNS 方式、私有網段規則與權限設定，日後升級或更換網路時即可快速對照。

故障排查與日常維護

先讀取第一個有效錯誤

核心啟動失敗時，日誌中較後方的大量錯誤可能只是第一個問題引發的連鎖結果。應從本次啟動時間點開始往下閱讀，找出第一條包含欄位名稱、連接埠、檔案路徑或設定區段的明確錯誤。常見類型包括本機連接埠已被占用、JSON 欄位格式錯誤、出站標籤不存在、傳輸參數缺失、核心檔案無法執行，以及設定目錄沒有寫入權限。記錄原始錯誤後再修改設定，每次只處理一個原因並重新啟動，避免同時更換節點、連接埠、核心與路由規則。

發生連接埠占用時，先確認是否有另一個用戶端仍在背景執行。Windows 可使用以下命令查看占用本機連接埠的程序編號，再到工作管理員核對程式；Linux 可使用 ss 查看監聽程序。連接埠號碼應替換為用戶端設定中實際顯示的本機監聽連接埠。

netstat -ano | findstr LISTENING
ss -lntup

不要看到連接埠占用就隨意改成任意數字。若瀏覽器、環境變數或其他應用程式已手動填入舊連接埠，修改後必須同步更新。更詳細的日誌閱讀方法可參考從日誌視窗定位核心啟動錯誤的排查路徑。

依鏈路建立排錯清單

當程式能啟動但無法存取目標時，依序檢查：訂閱是否能更新、目標節點是否能完成連線測試、核心是否正在執行、應用程式請求是否進入本機入站、路由是否選擇正確出站、DNS 是否回傳可用結果。每一步都需要可觀察的證據，例如訂閱日誌、核心啟動日誌、請求記錄或模式對照結果。若全域模式可用而規則模式不可用，重點檢查路由；若系統代理可用而 TUN 不可用，重點檢查虛擬介面、DNS 與系統路由；若所有模式都無法建立連線，回頭檢查節點參數、系統時間與基礎網路。

日常更新與回復

用戶端、核心、訂閱與規則集是四類不同的更新對象，不應在同一次維護中全部更換。較穩妥的順序是先記錄目前可用狀態，更新其中一項，重新啟動並驗證常用情境，再繼續下一項。用戶端升級後重點檢查設定遷移與選單變化；核心更新後重點查看協定參數與啟動日誌；訂閱更新後留意節點增刪與名稱變化；規則集更新後對照常用網站與區域網路存取。只要每一步都有驗證點，異常就能限定在最近一次變更中。

回復需要保留可辨識的基線。至少記錄目前使用的用戶端類型、訂閱群組、常用節點、系統代理模式、TUN 狀態與自訂路由規則。設定匯出檔應存放於受控位置，訂閱網址與節點資訊不應放入公開同步目錄。若升級後出現問題，先回復最近的變更項目，不要刪除全部設定重新開始。重建環境雖然有時能暫時恢復，但也會同時清除可用來解釋原因的日誌與差異。

分享日誌前的處理

日誌適合保留錯誤時間、錯誤類型、欄位名稱、目標連接埠與用戶端操作步驟，但其中可能出現訂閱路徑、伺服器位址、使用者識別資訊或本機目錄。向他人提供日誌前，應刪除訂閱查詢參數、節點識別資訊與個人目錄名稱，同時保留錯誤上下文。只截取最後一行通常缺少啟動階段資訊；公開整份設定又會暴露不必要的資料。建議提供「發生前執行了什麼、預期結果、實際結果、第一個錯誤及其前後幾行」。

穩定維護依賴可重現的步驟，而不是頻繁清空設定。只要保留基線、一次只修改一個變數，並從第一個錯誤開始閱讀，大多數問題都能定位到明確層級。主視窗各區域的作用可繼續參閱v2rayN 主介面功能分區詳解。

設定檔與進階路線

從圖形設定對應至設定結構

進階學習的重點不是脫離圖形用戶端手寫所有設定，而是理解介面操作最終改變了哪一段結構。V2Ray 設定通常由 log、dns、inbounds、outbounds、routing 等部分組成。inbounds 定義流量如何進入核心，例如本機 SOCKS、HTTP 或 TUN 入口；outbounds 定義代理、直連與阻擋出口；routing 決定入站流量送往哪個出站；dns 影響網域如何解析，以及解析請求經由哪條路徑傳送；log 決定記錄層級與輸出位置。

在 v2rayN 中切換伺服器時，通常會改變主要代理出站的參數；切換全域或規則模式會改變路由選擇；修改本機連接埠會影響入站監聽；啟用 TUN 會新增或調整對應入站以及系統網路設定。理解這些對應關係後，日誌中的 inboundTag、outboundTag、網域策略等詞就不再是孤立欄位。閱讀設定時，應先畫出「入口—規則—出口」三段關係，再查看協定細節。

設定修改的最小變更法

手動調整設定前，先複製目前可用的版本，並在副本中註明用途。每次只修改一個邏輯目標，例如新增一個直連網域、變更 DNS 出站或增加一個測試入站。儲存後先執行用戶端或核心提供的設定檢查，再啟動並觀察開頭的日誌，最後驗證與修改目標直接相關的請求。不要在同一次編輯中重排所有路由、替換 DNS、修改監聽連接埠及更換節點，因為即使最後連線成功，也無法判斷哪項修改真正產生作用。

{
  "log": {
    "loglevel": "warning"
  },
  "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，表示僅限本機存取；開啟 UDP 可讓該入站接收相應請求。它不是完整的遠端代理設定，因為代理出站必須使用訂閱或伺服器提供的實際協定參數。學習時可以用這種精簡片段理解結構，但日常連線應讓用戶端產生與訂閱相符的完整設定。

日誌層級與觀察範圍

日常執行使用 warning 等較克制的日誌層級即可；排查複雜路由或連線過程時，可暫時提高詳細程度，確認問題後再恢復。詳細日誌會快速增加內容量，也可能記錄更多目標資訊，不適合長期啟用。觀察日誌時，應圍繞一個測試請求記錄時間點，再從該時間附近尋找入站、目標網域、路由決定與出站錯誤。沒有明確測試動作的長篇日誌，通常難以區分背景請求與目標請求。

建議的進階學習順序

第一階段掌握系統代理、節點選擇與日誌入口；第二階段理解網域、IP、連接埠與規則順序；第三階段學習 DNS 請求發生的位置及 domainStrategy 的影響；第四階段再研究 TUN 的虛擬介面、預設路由與 UDP；第五階段才進入協定欄位與傳輸參數。這個順序從本機可觀察的行為逐步深入協定細節，遇到問題時仍能回到已驗證的基礎層。

協定學習應圍繞欄位關係展開。VLESS 等協定欄位負責身分與流量控制，TCP、WebSocket、gRPC 等傳輸方式負責承載，TLS 或 REALITY 負責相應的安全與驗證參數。任何分享連結都應視為一組完整參數處理，不能因名稱相近就互換欄位。需要比較單一節點連結與訂閱的結構時，可閱讀vmess 與 vless 分享連結怎麼使用。

建立自己的執行基線

完成本手冊後，建議建立一份裝置基線：記錄用戶端名稱、作業系統平台、監聽連接埠、系統代理模式、TUN 狀態、DNS 路徑、路由規則來源與常用訂閱群組。基線不需要儲存節點敏感參數，只需描述設定關係。每次升級或修改後，使用同一組情境驗證：用戶端啟動、訂閱更新、一般網頁、規則分流、區域網路存取、UDP 應用程式與休眠恢復。結果與基線一致，才能視為變更完成。

從零到精通不代表要記住每個欄位，而是具備穩定的分析順序：先確定問題層級，再蒐集日誌證據，接著進行最小修改，最後用對照測試確認。需要重新走一遍最短設定流程時，返回快速上手；需要更換平台安裝包時，前往用戶端下載頁。兩者負責操作入口，本手冊則負責說明設定之間的因果關係。