V2Ray JSON 設定檔參考

JSON 結構與設定來源

先確認設定由誰產生，再決定要在哪裡修改。v2rayN、v2rayNG 與 v2flyNG 都是圖形化用戶端，負責將節點、訂閱、路由和本機設定整理成核心執行所需的內容。用戶端介面儲存的資料、訂閱回傳的資料，以及最後執行的 JSON，分屬不同層次。訂閱連結不能直接當成設定檔，用戶端資料庫也不等同核心設定。排錯時，應找出目前連線實際使用的設定，而不是只檢查過去匯出的某個檔案。

頂層物件與請求路徑

常見設定以單一物件作為根節點。物件中的鍵代表功能模組，模組值可能是物件或陣列。inbounds 和 outbounds 是陣列，因為同一個程序可以同時提供多個入口及不同出口。routing 則是物件，其中的 rules 才是有順序的規則陣列。理解結構層級比記住欄位排列更重要：頂層鍵通常不受書寫順序影響，但路由規則陣列與出站陣列可能改變實際行為。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [],
  "outbounds": [],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  },
  "dns": {
    "servers": ["localhost"]
  },
  "policy": {
    "levels": {}
  }
}

上方內容只是結構骨架，並非可完成轉送的設定：空入站沒有接收請求的連接埠，空出站也沒有轉送目標。實際請求通常沿著「應用程式→入站→路由→出站」流動，DNS 可能參與網域解析，日誌則記錄過程中的事件；策略會影響連線資源與逾時設定。各模組並非互不相關的開關；出站標籤即使拼寫正確，若沒有被引用，也不會自動接手任何流量。

語法正確與語意正確

標準 JSON 的鍵與字串使用英文雙引號，布林值使用小寫 true、false，數字通常不加引號。陣列或物件的最後一個成員後不能加逗號，也不要把說明文字直接放進程式碼。有些實作支援擴充語法，但在不同用戶端間複製時，建議使用標準 JSON。重複鍵尤其容易造成誤判：不同解析流程可能保留不同值，因此同一物件中只應保留一個同名欄位。

語法解析成功，只代表括號、型別與字元合法，不代表協定參數可用。核心還會檢查協定名稱、欄位支援範圍、標籤引用與監聽資源。即使成功啟動，也可能因遠端位址、驗證資訊或傳輸參數不一致而無法連線。應將「檔案可解析」、「程序可啟動」、「請求可通過」及「規則符合預期」視為四個不同檢查點，逐一確認，避免只用一次網頁瀏覽概括所有狀態。

核心差異與修改範圍

Project V 是相關工具的生態背景；V2Fly 與 Xray 則是需要分別辨識的核心實作。兩者有共同的設定概念，但不能因此假設新欄位、傳輸組合和預設值都相同。REALITY 等擴充功能尤其應依實際核心的對應欄位設定，不要直接把專屬於某個實作的區段合併到另一份檔案。本手冊範例採用常見的基礎結構；使用擴充功能前，請先確認用戶端目前選用的核心。

圖形化用戶端通常會在切換節點、更新訂閱或重新連線時產生設定。直接修改暫存的產生檔案，可能在下次操作後被覆寫。若要長期保留修改，應優先使用用戶端提供的路由、DNS 或自訂設定入口，並確認這些內容如何合併。修改前先另存原始資料，記錄變更欄位與預期結果；每次只調整一個層次，發生問題時才能準確復原。首次選擇用戶端可參考用戶端與平台下載頁。

log 日誌與觀察方式

日誌用來說明某次執行發生了什麼，不能證明所有連線都正常。設定啟動失敗時，先查看錯誤日誌；應用程式能連上本機連接埠卻無法完成請求時，再搭配存取記錄、目標位址和出站行為判斷。核心日誌、用戶端介面日誌與系統服務日誌可能來自不同程序，顯示時間和詳細程度也不同。比較兩份記錄前，先確認它們屬於同一次啟動，避免把舊錯誤當成目前故障。

日誌等級與輸出位置

loglevel 控制錯誤類日誌的詳細程度。常見值包括 debug、info、warning、error 和 none。日常使用通常維持較精簡的等級，重現問題時再暫時提高。提高詳細程度只會增加觀察資訊，不會改變規則比對或修復交握問題。若問題只發生在特定應用程式，應先縮小重現範圍，而不是長時間記錄所有日常連線。

{
  "log": {
    "access": "./access.log",
    "error": "./error.log",
    "loglevel": "warning"
  }
}

這段設定需要合併至頂層物件。兩個路徑都是相對路徑，實際位置取決於程序的工作目錄，不一定是 JSON 檔案所在目錄。桌面用戶端由捷徑、服務或終端機啟動時，工作目錄可能不同。找不到檔案時，先檢查啟動方式與目錄權限，再確認日誌是否已關閉。將路徑改到可寫入的位置通常更直接，不必反覆提高日誌等級；也不要因此放寬整個程式目錄的存取權限。

如果用戶端已收集核心輸出，就不一定需要另外指定檔案。未指定檔案時，輸出位置應以實際核心和啟動方式為準。有些介面只顯示摘要，有些則會另外提供存取日誌開關。若檔案持續增長，還需要在執行環境中安排輪替或清理，不能假設核心會自動限制檔案大小。日誌保留時間應依排錯需求決定；完成問題重現後，請恢復原本的日誌等級，避免長期記錄占滿磁碟。

依時間建立精簡的證據鏈

有效的問題重現應有明確的起點與終點。先停止舊連線，記下重新啟動的時間，再用已知位址發出一次請求。觀察是否出現入站接收、目標辨識、規則選擇及出站錯誤。不同實作未必會逐項印出這些資訊，不必要求每份日誌都使用相同措辭；重點是串起時間、目標和結果。連續重新整理多個網頁會引入預先連線、背景請求及快取，反而讓記錄難以對應。

常見錯誤可依層次判斷。監聽失敗通常與連接埠遭占用、位址不存在或權限有關；網域解析失敗指向解析流程；連線遠端逾時可能涉及目標可連通性及傳輸條件；驗證或交握錯誤則應比對伺服器與用戶端參數。最後出現逾時提示，無法單獨指出錯誤層次。應找出它之前第一筆有意義的錯誤，而不是只複製最後一行。多次重試產生的重複訊息，也不代表有多個獨立原因。

分辨日誌缺漏與流量未進入

沒有存取記錄時，先確認應用程式是否真的使用這個入站。瀏覽器可能讀取系統代理設定，命令列工具則可能只讀取自身參數；既有連線也可能繼續沿用原本的通道。測試時重新建立連線，並明確指定代理位址，可以減少變數。若應用程式請求根本沒有進入核心，調整出站、DNS 或路由都不會改變結果。系統代理與核心路由的職責差異，請參閱系統代理與路由模式說明。

若已看到請求進入，但記錄中的出站與預期不同，請前往路由章節檢查順序與標籤。若出站正確，只有部分目標失敗，則比較目標使用的位址族、傳輸協定或網域解析路徑是否不同。日誌只是觀察線索，還需要搭配可重複的測試。分別保存一次成功與一次失敗的記錄，逐項比較差異，通常比同時修改連接埠、解析器和路由模式更容易找出真正的變因。

inbounds 本機入口

入站定義核心在哪裡接收請求，以及如何解讀應用程式傳來的資料。桌面環境常見的是本機 SOCKS 或 HTTP 入口。連接埠只是入口編號，不會決定出口是否經過遠端節點，也不代表所有應用程式都會自動使用代理。應用程式必須主動連線至該連接埠，或由系統代理等入口機制將請求交給核心。排錯前應先確認應用程式需要的協定，不能把 SOCKS 連接埠隨意填進只接受 HTTP 代理的設定欄位。

監聽位址、連接埠與標籤

listen 決定繫結位址，port 決定監聽連接埠，protocol 決定入站協定，tag 則供後續引用。若只供本機使用，明確監聽 127.0.0.1 可以限制存取範圍。這個位址只代表本機 IPv4 迴送位址，不等同於所有網路介面，也不等同於 IPv6 迴送位址。若應用程式連線時使用另一種位址族，請核對雙方位址，不要只憑「localhost」這個名稱判斷連線位置。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      }
    }
  ]
}

範例允許本機應用程式使用不需驗證的 SOCKS 入口，並啟用 UDP 轉送能力。這裡的 udp 不代表系統中所有 UDP 流量都會被接管；應用程式仍須使用 SOCKS 的相關機制，出口也必須能處理相應流量。若只測試網頁，成功通常只能證明目前的 TCP 請求已通過，不能據此判斷語音、即時通訊或其他 UDP 應用程式。遇到差異時，應分別檢查應用程式支援、入站能力和出站連線。

區域網路存取與安全界線

允許區域網路連線，不只是將監聽位址改成 0.0.0.0。還須考慮主機防火牆、網路介面、驗證方式與允許的來源。監聽所有介面會擴大可連線範圍，電腦切換至不同網路後，暴露面也會跟著改變。若只需要特定區域網路介面，可繫結該介面位址，並搭配防火牆限制來源。沒有明確的分享需求時，維持迴送位址監聽較容易管理，也能避免其他裝置誤用本機入口。

同一位址上的相同傳輸類型連接埠不能由多個程序重複占用。用戶端背景程序未結束、另一個工具使用相同連接埠，或同時啟動兩份設定，都可能造成繫結失敗。此時先關閉多餘的執行個體、確認連接埠由哪個程序使用，再決定是否更換連接埠。若修改入站連接埠，應同步更新應用程式代理設定和系統代理；只改 JSON 卻保留舊代理位址，通常會遭到拒絕連線，而不是發生協定交握錯誤。

流量嗅探與目標覆寫

嗅探會嘗試從請求內容辨識網域等目標資訊。例如，應用程式先將網域解析為 IP，再透過入口傳送 IP 目標時，HTTP 標頭或 TLS 交握中的資訊可能有助於還原網域。這有助於讓網域規則參與路由，但辨識能力取決於實際協定內容，並非所有加密流量都能還原網域。若沒有可辨識資訊、目標使用特殊交握，或協定超出支援範圍，路由仍可能只能依據 IP 及其他條件比對。

destOverride 會影響辨識結果如何改變目標，不應把「辨識網域」和「只用於路由比對」混為一談。不同核心提供的控制欄位和預設行為可能不同；若只想影響比對而不改寫連線目標，應先確認實際實作支援的功能，再進行設定。排查啟用嗅探後的存取差異時，可先針對同一目標分別關閉及開啟嗅探，觀察目標和規則變化，不要同時更換節點與 DNS。

多個入站可用於不同用途，例如為測試請求另外設定一個標籤，再以 inboundTag 指向專用出站。標籤是邏輯名稱，不會建立連接埠，也不會自動啟用系統代理。規劃時應讓名稱清楚描述用途，避免留下大量難以區分的編號。完成監聽測試後再加入嗅探和分流，可將入口問題與後續策略問題分開排查；圖形介面的基本操作仍以快速入門步驟為主。

outbounds 出站選擇

出站決定請求選定路徑後如何處理。它可以直接連線至目標、透過指定代理協定傳送至遠端，或主動拒絕連線。出站不是「節點清單」的簡單同義詞：直連與阻斷也屬於出站，且不需要遠端伺服器。一份設定可以包含多個出站，但只有預設路徑或路由引用的出站才會處理請求。先確認請求選中了哪個出站，再檢查該出口的參數，排錯順序會更清楚。

基本出站與預設行為

一般設定中，路由未比對到指定出口時，會使用出站陣列中的第一個項目作為預設出口。因此，調整陣列順序可能改變未命中規則的流量去向。建議明確記錄預設出口的用途，並為每個需要引用的出站設定唯一標籤。同一份設定中的標籤前後應完全一致，包括大小寫與字元；標籤不一定等同介面顯示名稱，也不能只憑節點備註推測實際產生的標籤。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "AsIs"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

範例將直連放在第一位，因此沒有額外規則時，請求會直接透過本機網路送出。blackhole 代表阻斷處理，只有路由指向 block 時才會使用。它不是備援線路，也不會在直連失敗時自動接手。將兩個出站加入陣列，不代表建立了故障切換；負載選擇、連線探測或鏈式處理都屬於其他設定功能，必須確認支援情況並另外設定。

協定參數與傳輸參數分層

遠端代理出站通常同時包含協定層與傳輸層設定。前者描述伺服器、連接埠、驗證資訊及協定特性；後者描述底層連線方式與其安全參數。伺服器端與用戶端的關鍵欄位必須相符；遠端連接埠可連通，只能證明網路層可建立連線，無法證明驗證與傳輸組合正確。遇到交握失敗時，應逐項比對服務提供者提供的完整參數，不要把所有欄位都改成看似熟悉的預設值。

VMess、VLESS、Trojan 與 Shadowsocks 的驗證結構和功能各不相同，不能只修改 protocol 名稱就互相轉換。TLS 與 REALITY 等組合也必須符合核心支援範圍。若要比較協定的選擇方式，可先閱讀四種代理協定的適用情境比較。本頁不提供使用虛構遠端憑證的「萬用節點」；完整測試設定採用直連出口，用來排除本機結構問題，而非模擬實際遠端線路。

網域目標與連線責任

出站收到網域後，會交由本機解析、使用內建 DNS 解析，或將網域傳給遠端，取決於出站協定及相關設定。freedom 的 domainStrategy 和 routing.domainStrategy 名稱相似，卻屬於不同層次。前者會影響直連出站如何處理網域目標，後者則影響路由比對是否進行解析。將路由策略改為解析 IP，不代表所有出口都會使用相同的解析流程。

多出口設定中，還要區分最終存取目標與代理伺服器本身的位址。伺服器網域也需要解析並建立連線；若相關流量又被送入依賴該伺服器的路徑，可能形成循環依賴。圖形化用戶端通常會處理必要的排除或直連邏輯；自訂設定則應明確分析啟動連線的建立路徑。若交握尚未完成就反覆逾時，應先檢查伺服器位址解析、底層連線能力及出口選擇。

修改節點參數時，優先使用用戶端的節點編輯功能，避免手動修改的內容隨後被訂閱更新覆寫。若自訂規則需要固定出站標籤，應確認用戶端產生的標籤是否固定，以及切換節點後是否仍可引用。若標籤會由用戶端重新產生，使用其提供的路由設定通常比複製執行檔案可靠。保留一份已知可用的基本設定作為對照，可將「出站本身失敗」與「路由選擇錯誤」拆成兩個可驗證的問題。

routing 規則比對

路由依規則順序檢查請求，並將比對結果交給指定出站。它不是系統代理開關，也不會主動接管未進入核心的應用程式流量。若規則正確但應用程式仍使用原本的網路，先檢查入口；只有在請求已進入、出口卻不正確時，才檢查規則順序、比對欄位與標籤引用。釐清入口接管與核心分流的差異，是理解「全域」及「繞過大陸」等介面模式的前提。

順序、條件與目標資訊

同一條規則中的不同條件通常必須同時符合，例如指定入站標籤並限制連接埠；同類陣列中的多個項目則提供可比對的選項。規則一旦命中，後續一般規則就不會再覆蓋結果。範圍較廣的規則應放在精確例外之後，否則例外永遠沒有機會生效。網域條件需要可用的網域資訊，IP 條件則依賴目標位址或解析結果；不能假設只有 IP 的請求一定會命中網域清單。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

範例先阻斷一個專用測試網域，再處理私人位址，最後將指定入站的其他 TCP 與 UDP 請求交由直連。blocked.example 是範例網域，不是需要替換的驗證資料。這裡的兩個出站標籤應與前一章的定義一致。第三條規則範圍較廣，若要增加特定目標的例外，通常應插在第三條之前。若放在其後，即使語法正確，也可能完全沒有比對機會。

網域寫法與資料檔

full: 用於比對完整網域，domain: 通常用於比對網域及其子網域，regexp: 則表示正規表示式條件。未加前綴的寫法也有自己的比對語意，不能一律視為精確網域。若要避免誤比對，優先使用能直接表達意圖的前綴，不要用複雜正規表示式取代清楚的完整網域或網域後綴。正規表示式還會受到 JSON 字串跳脫規則影響，反斜線須依字串規則處理。

geoip: 與 geosite: 引用的是對應的規則資料，不是執行時的線上搜尋結果。使用前應確認核心能讀取所需資料檔，且檔案中包含引用的分類。分類名稱存在，不代表涵蓋所有目標；資料更新也可能改變比對範圍。若某網站被分配到非預期的出口，應比對實際存取網域、相關資源和資料內容；一個頁面通常會產生多個獨立請求，不能只看網址列中的網域。

domainStrategy 的解析時機

AsIs 會盡量依據已有的目標資訊比對，不會為了 IP 規則主動執行相應的網域解析。IPIfNonMatch 會在網域階段找不到適用規則時，再嘗試解析並使用 IP 條件；IPOnDemand 則會在比對需要 IP 資訊時觸發解析。它們改變的是比對過程取得資訊的方式，並非代表「更快」或「更完整」的固定等級。解析過早會增加依賴，解析不足則可能讓預期中的 IP 分類無法參與比對。

尤其要留意兜底規則。如果前面已有一條能比對所有請求的規則，使用 IPIfNonMatch 時可能已經得到結果，不會再進入預期的解析階段。此時問題不是 DNS 沒有運作，而是規則已提早結束比對。應配合規則順序設計解析策略，而非只切換一個欄位。私人位址規則也只能比對核心實際掌握的位址；網域解析為私人位址的情況，須另外驗證解析時機。

用戶端產生的「繞過大陸」通常是一組規則，而不是所有核心都通用的單一選項。不同設定範本可能採用不同網域清單、IP 分類和預設出口。若要了解實際行為，必須查看目前使用的規則，而不能只引用模式名稱。若要依應用情境選擇模式，可閱讀系統代理、全域與繞過大陸模式說明；若遇到速度差異，則應進一步區分規則選擇、解析路徑與遠端線路，不要將所有現象都歸因於某個模式名稱。

dns 網域解析

DNS 設定首先要釐清「由誰發出查詢、查詢從哪裡送出、結果由誰使用」。作業系統解析器、瀏覽器本身的解析機制、核心內建 DNS 及遠端伺服器的解析可能同時存在。修改核心的 dns 不會自動取代所有應用程式的解析方式，也不會將所有系統查詢導入核心。只有相關請求路徑確實使用內建解析器時，這些設定才會影響結果。

基本伺服器與靜態對應

servers 列出內建 DNS 使用的伺服器或相關設定，hosts 則可定義靜態網域對應。以下範例將一個測試網域對應至迴送位址，其他查詢交由本機解析機制處理。靜態對應適合用於隔離測試，不適合長期固定經常變動的服務位址。服務可能依地區、負載和位址族回傳不同結果；固定位址會略過這些選擇，也可能在伺服器端調整後失效。

{
  "dns": {
    "hosts": {
      "full:manual.example": "127.0.0.1"
    },
    "servers": [
      "localhost"
    ]
  }
}

這段設定不會讓任意瀏覽器存取該測試網域時都解析為迴送位址；前提是該次存取實際使用核心內建 DNS。若直連出站採用系統解析路徑，而應用程式又已自行解析，結果可能與預期不同。因此驗證靜態對應時，也要確認查詢路徑。測試完成後請移除測試對應，以免之後將連線迴送位址失敗誤判為真實目標故障。正式設定中的對應應有明確用途及可追蹤的維護記錄。

路由解析與出站解析

路由階段可能為了比對 IP 規則而解析網域，但出站仍可能繼續使用網域建立連線。路由查詢一次，不代表最終連線一定使用同一個位址解析結果。直連出站是否使用內建 DNS，取決於它的網域策略；代理出站是否在本機解析目標，則取決於協定與具體設定。分析特定請求時，應分別記錄路由判斷採用的資訊，以及最終出口建立連線時採用的資訊，不能只看某一處的解析日誌。

應用程式也可能先完成解析，再將 IP 傳給 SOCKS 入口。此時核心未必知道原始網域；嗅探有時能補上資訊，但不保證成功。若要驗證核心端的網域處理，應使用能將網域交給代理的測試方式，並確認應用程式沒有預先將網域替換成位址。反過來說，若要比較本機解析與代理端解析的差異，也應明確控制這項變數，不要在瀏覽器、系統和用戶端快取之間猜測。

解析傳輸與循環依賴

指定解析伺服器位址，不代表查詢會自動經由遠端代理。不同形式的 DNS 伺服器設定可能使用不同傳輸路徑，應分別分析。若使用需要先解析網域才能連線的加密解析端點，還要考慮最初的解析如何完成。若解析伺服器的存取依賴某條代理，而代理伺服器的網域又依賴該解析伺服器，就可能在建立第一條連線前陷入循環。設計時應為啟動所需的連線保留明確且可連通的路徑。

不要一次替換多個解析器，並同時改變路由策略。先記錄目前回傳的位址，再只變更一個查詢環節，使用相同目標重新測試。多個解析伺服器不一定會依書寫順序逐一嘗試；實際行為可能涉及比對條件、並行查詢、回退方式及實作差異。若需依網域選擇解析來源，應查明目前核心支援的伺服器物件欄位，不要直接套用其他工具中「首選」與「備用」的語意。

位址族與快取範圍

同時取得 IPv4 和 IPv6 結果時，最終情況還取決於本機網路、出口支援與連線選擇邏輯。不能只因某次請求等待較久就立刻停用某個位址族；應先確認回傳了哪些位址、哪次連線失敗，以及失敗後是否有回退。解析成功只代表取得結果，不代表這些位址都能連線。位址可連線也不等於直接使用 IP 就能取代網域，因為 TLS 伺服器名稱和虛擬主機仍可能需要原始網域。

快取能讓測試結果更穩定，也可能掩蓋設定變更。修改後應建立新請求，必要時依應用程式提供的方法清除相關快取，並區分核心重新啟動前後的記錄。不要把重新啟動所有軟體當成唯一診斷方式；有針對性地找出快取所在層次，才能說明問題為何發生。若整體速度變慢，可繼續閱讀速度變慢的分層排錯指南，分別測量解析等待時間與遠端傳輸速度。

policy 連線策略

連線策略管理計時與資源，不負責選擇路由，也不能取代應用程式本身的逾時設定。連線經常中斷時，不應先把所有逾時值調大。應先確認交握是否尚未完成、連線是否已建立但長時間閒置，或其中一端是否已結束傳送。不同階段由不同欄位限制，應用程式、作業系統和遠端裝置也可能有各自的計時器。只有確認中斷發生在哪個階段，修改策略才有明確目的。

級別物件與使用者關聯

policy.levels 會以級別名稱組織策略，JSON 物件的鍵必須寫成字串，例如 "0"。支援使用者級別的協定設定，可透過相關的 level 欄位連結策略；具體作用對象取決於協定實作與實際產生的設定。將策略寫入某個級別，不代表所有連線都會自動使用它。排錯時要確認連線所屬使用者的級別，以及未明確指定時採用的預設行為。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    }
  }
}

範例中的時間單位為秒，用於說明一組連線階段限制，不代表適用所有網路環境的建議值。handshake 限制相關交握階段的等待時間，connIdle 限制連線閒置時間，uplinkOnly 與 downlinkOnly 則涉及單向傳輸階段的等待範圍。理解欄位用途時，須參考核心文件及連線狀態，不能將它們簡單等同於瀏覽器的「網頁載入逾時」。

交握、閒置與半關閉

交握失敗可能源自參數不一致，不一定是線路速度太慢。若驗證或安全參數錯誤，延長交握時間只會讓你更晚看到失敗；只有證據顯示線路確實需要較長的建立時間時，小幅調整才有意義。觀察時應比較開始建立連線、首次收到資料及錯誤出現的時間。也要確認日誌所說的交握屬於哪一層，不能將應用程式階段、代理協定與底層傳輸的交握混為一談。

閒置連線和低速連線也不相同。長連線應用程式可能一段時間沒有業務資料，卻仍需維持工作階段；其他應用程式則會透過心跳保持連線。策略計時與應用程式心跳週期不一致時，可能造成定期斷線。此時應確認斷線間隔、是否有實際資料，以及遠端或中間設備是否先關閉連線。只延長本機閒置時間，無法阻止遠端依自身規則結束工作階段，也不能修復無線網路切換造成的狀態遺失。

半關閉表示一端已結束傳送，但另一端可能還有內容要傳遞。部分協定仰賴這個階段完成回應，單向等待時間太短可能截斷尚未傳完的資料。另一方面，所有值都設得很長，也會讓已失去用途的連線繼續占用資源。應使用特定應用程式重現問題，觀察回應是否完整、由哪一端先關閉連線，再調整對應欄位。不要只憑一個網頁載入成功，就認為所有長連線與單向傳輸情境都已驗證。

統計與緩衝不是速度開關

策略中也可能包含使用者或系統流量統計相關欄位，但啟用統計只是記錄條件之一。若用戶端要顯示相關資訊，還需要統計模組、介面及用戶端讀取方式配合。單獨複製統計開關，不會自動產生介面資料。同樣地，緩衝區設定會影響記憶體使用與資料處理方式，卻無法突破遠端頻寬、線路壅塞或伺服器限制；調大緩衝也不代表所有請求都會變快。

使用圖形化用戶端時，除非有明確且可重現的需求，否則優先保留用戶端產生的基本策略。用戶端可能依目前核心與功能安排預設值，若自訂內容整段覆蓋，可能意外移除原有欄位。只需修改單一值時，應確認用戶端是逐欄位合併，還是整段取代。記錄修改前後的設定差異，尤其確認未主動修改的級別和系統策略仍然存在，避免表面上只改了逾時，實際上卻遺失其他設定。

驗證策略調整時，使用相同應用程式和操作流程，並設定可觀察的判定標準，例如閒置一段時間後是否仍可繼續傳送，或單向回應是否完整。若無法穩定重現，先保留原值並收集更多證據，不要同時修改交握、閒置與緩衝設定。記憶體有限的環境也應留意並行連線數與日誌量，避免將資源不足誤判為線路問題。策略的目標是讓限制符合實際使用方式，而不是追求數值越大越好。

完整範例與分層驗證

先使用只包含本機入口與直連出口的設定驗證結構，再加入真實節點與複雜分流。如此可暫時排除遠端驗證、傳輸條件和訂閱產生邏輯。以下提供一份完整的基本設定，接收本機 SOCKS 請求，並將指定測試網域交給阻斷出口，其餘請求則直連。它不會建立遠端代理線路，也不會自動為應用程式設定系統代理；用途是驗證入口、規則與出口之間的引用關係。

可執行的本機測試設定

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "AsIs"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  },
  "dns": {
    "servers": ["localhost"]
  },
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    }
  }
}

執行前，先停止其他占用相同監聽連接埠的執行個體。若使用用戶端的自訂設定入口，請確認匯入的是完整設定，而不是只能填入特定子區段的欄位，兩者結構不同。儲存後先檢查核心能否啟動，再查看監聽狀態。測試中未啟用嗅探，是為了讓規則測試直接依賴應用程式提交的目標名稱。dns 保留基本結構，但直連出站使用 AsIs 時，不應據此斷言請求一定經過內建 DNS。

依序測試入口、比對與出口

第一步，確認應用程式能連上本機連接埠。若立即遭到拒絕連線，請檢查程序是否已啟動、位址族是否一致，以及連接埠是否曾變更。第二步，明確傳送網域目標，避免應用程式先行解析為 IP。第三步，比較一般目標與阻斷目標的行為。下列命令適用於已提供相應命令列工具的環境，只會向正在執行的本機入口發出請求；若終端機已將工具名稱設為其他命令的別名，請改用實際的可執行程式。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2raygpu.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://blocked.example/

socks5h 會將網域交由代理入口處理，方便測試完整網域規則。第一個請求能否成功，還取決於本機網路與目標網站是否可用；第二個請求應遭到阻斷，但只看失敗結果仍不足以證明規則已命中，因為範例網域本來就不是一般業務目標。還要檢查請求目標與出站記錄，或在受控環境中暫時以可存取的目標取代測試規則，完成後再恢復。不要把任何一次逾時直接當成阻斷成功。

確認基本路徑後，再透過用戶端匯入現有的真實節點資料，加入實際的出口選擇。每次只新增一項功能，例如先驗證遠端出口，再新增網域規則，最後加入解析條件。若匯入後立即失敗，請將新增內容與基本設定逐層比對；不要用完整測試設定覆蓋用戶端自動產生的流程，卻仍假設原有節點與路由都會保留。設定來源改變時，也要重新確認驗證起點。

故障記錄與復原順序

保存故障記錄時，寫明使用的用戶端、實際核心、設定來源、入口位址、測試目標及預期出口。移除驗證資料後，仍須保留標籤之間的關係，否則他人無法判斷路由引用是否有效。若只有特定應用程式失敗，先比較它與成功應用程式的入口方式、網域提交方式及連線重用行為。若所有應用程式都失敗，再依序檢查啟動、監聽、解析和遠端連線，不要一開始就重新安裝用戶端。

復原時應依最後一次修改的相反順序操作。先撤銷新增的規則或欄位，重新啟動並再次測試；若仍未恢復，再切回已知可用的設定來源。訂閱更新造成的變化要區分節點資料與本機範本，不能混用舊檔案和新介面。平台安裝差異可查閱下載頁，基本連線操作請回到快速入門教學，術語說明則可參閱術語手冊。

最後確認目標是否真正達成：語法通過、監聽正常、請求進入、出口符合規則、解析路徑明確，且連線在預期範圍內結束。任何一項尚未確認，都應保留相應的觀察點。手冊中的片段用於說明各個模組，只有標示為完整範例的設定才能整份使用；複製子區段時，必須合併至正確層級並保留其他必要模組。穩定設定仰賴可重複驗證的依存關係，而不是不斷增加更多欄位。