V2Ray 設定檔完整參考

JSON 結構總覽：物件、陣列與引用關係

先看資料流，再看欄位

設定檔不是把節點參數逐項列出，而是描述請求的處理路徑。應用程式先將請求交給入站，路由模組依請求屬性選擇出站，再由出站連線至目標或代理伺服器。DNS 負責提供需要解析的網域位址，策略則管理連線生命週期與統計行為。閱讀設定時，先找出這條路徑，再逐一查看各模組細節，比逐行猜欄位更容易理解設定之間的關聯。

頂層通常是一個物件，以大括號括住各模組。inbounds 和 outbounds 是陣列，因為同一個程序可以監聽多個入口，也可以設定多個出口；routing、dns、policy 通常是物件。陣列元素以逗號分隔，最後一項後面不要加逗號。布林值寫作 true 或 false，連接埠通常使用數字，協定名稱和標籤則使用字串；不能把介面上的所有文字都直接加上引號填入。

以下是用於本機結構驗證的完整直連設定。它只在迴圈位址提供 SOCKS 入口，不含遠端代理節點，所有請求都經由本機網路送出。這份設定可用來確認核心能否載入設定、應用程式能否連上監聽連接埠，以及日誌能否記錄請求。這不代表遠端代理已建立，也不能因直連成功就推斷訂閱參數正確。測試結束後，請明確選擇接下來要使用的用戶端設定。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

標籤是設定內部的連結點

tag 是內部識別標籤，不必翻譯成顯示名稱。路由中的 outboundTag 必須與目標出站的標籤完全相同，包括大小寫；inboundTag 則用來限定規則適用的入口。建議使用簡短明確的標籤，並確保同類物件各自唯一。若將出站標籤改成更易讀的名稱，也要同步修改引用該標籤的路由。否則設定檔可能通過解析，實際執行或轉送請求時卻找不到目標。

設定欄位未填，與明確填入空值並不相同。省略選填欄位時，核心通常會採用該實作的預設行為；填入 null、空字串或空物件，並不保證結果相同。複製範例時，請確認欄位所在層級；不要將 streamSettings 放進協定帳戶物件，也不要把 rules 直接放在頂層。通過 JSON 語法檢查，只代表括號和資料型態的格式大致正確，不代表核心認得這些欄位。

用戶端產生設定與手動設定的界線

圖形化用戶端通常會依節點、路由範本和 DNS 選項重新產生執行設定。直接修改暫存檔，下一次切換節點或重新啟動後可能就會被覆蓋。需要長期保留的選項，應優先在用戶端對應的設定中修改；只有明確採用匯入自訂設定的流程時，才以完整 JSON 作為主要維護對象。匯出的設定也可能包含伺服器位址和帳戶資訊，分享排錯資料前請先移除，只留下欄位結構與必要的錯誤資訊。

Xray 與 V2Fly 沿用不少歷史結構，但新功能、別名和預設值未必始終一致。本頁採用的經典結構適合說明資料流，不代表不同核心之間保證相容。遇到「未知欄位」或「未知傳輸類型」時，請先確認目前執行的核心，再核對該核心採用的設定格式。尤其不要把其他設定格式的欄位名稱混用在同一個檔案中。可參考術語表區分協定、傳輸、安全層與用戶端，避免在錯誤層級尋找設定入口。

inbounds 入站：監聽位址、連接埠與流量探測

監聽位置決定哪些裝置可以連入

入站定義用戶端從哪裡接收應用程式請求。桌面環境常見的 SOCKS 入口會接收支援 SOCKS 代理的程式流量；HTTP 入口則接收依 HTTP 代理協定送出的請求。這裡的協定指本機應用程式與用戶端之間的互動方式，不是遠端節點使用的 VMess 或 VLESS。應用程式設定的代理類型必須與入站一致；把 SOCKS 連接埠填進只支援 HTTP 代理的設定欄，通常不會因為連接埠可連通就自動轉換成正確的協定。

listen 設為 127.0.0.1 時，入口只接受本機 IPv4 迴圈連線。改成 0.0.0.0 代表監聽所有本機 IPv4 網路介面，並不表示只允許家用網路存取。裝置若同時連上其他網路，也可能在相應介面提供服務。需要在區域網路共用時，應一併考量系統防火牆、允許存取的來源及入口驗證；不能只開啟用戶端的一個選項，就認為存取範圍已受到限制。

port 是本機監聽連接埠，與節點伺服器的連接埠互不相關。修改本機連接埠後，瀏覽器、開發工具或其他手動設定代理的應用程式也要一併更新。連接埠被占用時，先確認是否已有另一個用戶端執行個體或其他程式正在監聽，不要只是不斷切換節點。日誌中的繫結失敗發生在建立本機入口時，尚未進入遠端協定交涉；此時調整伺服器 UUID、TLS 或路由都無法解決監聽衝突。

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

SOCKS、UDP 與系統代理不是同一個開關

範例中的 udp 允許 SOCKS 入站處理 UDP 請求，但無法讓原本不使用 SOCKS 的應用程式自動改走代理，也不保證後續出站及遠端服務支援這類流量。完整傳輸路徑還取決於應用程式是否發起 SOCKS UDP 關聯、系統網路是否允許傳送，以及遠端協定組合能否承載。排錯時應先用明確支援此方式的應用程式測試，不要把瀏覽器網頁能正常開啟，當成所有 UDP 情境都已驗證通過。

系統代理通常只會影響遵循系統代理設定的應用程式，不會接管裝置上的所有連線。若應用程式忽略系統設定，或自行連線至目標位址，請求不會因為用戶端正在執行就必然進入該入站。用戶端提供的虛擬網卡或透明接管屬於其他接入方式，還需要處理路由、權限和 DNS。本文先以明確設定代理的方式說明；查閱時請確認實際使用哪種入口，再依相應日誌判斷請求是否抵達核心。

sniffing 擷取的資訊用於哪些步驟

sniffing 會嘗試從已接入流量的協定特徵中擷取目標資訊，例如 HTTP 主機名稱或 TLS 交握中的伺服器名稱。它不會解密所有應用程式內容，也無法從任意連線中還原網域。若應用程式只提供目標 IP，且流量特徵無法辨識，網域路由仍可能沒有可用的名稱。因此，啟用探測只能補充部分路由依據，不能取代正確的應用程式代理設定與完整的 DNS 設計。

destOverride 用來指定嘗試辨識的類型；routeOnly 表示只將辨識結果用於路由，並保留原始目標的意圖。使用此選項前，應先確認目前核心是否支援；不能直接認定用戶端介面中的同名功能在所有實作中都相同。診斷網域規則時，可比較啟用前後的目標紀錄與出站選擇，判斷是未擷取到名稱、名稱未符合規則，還是命中後被更前面的規則攔截。

若確實需要共用入口，請先驗證僅限本機的基本設定，再逐步擴大監聽範圍與存取權限。不要同時修改監聽、驗證、系統代理和節點參數，否則連線失敗時無法判斷是本機存取受阻，還是上游交握未成功。完成後，再從另一台可信任的裝置驗證允許的存取路徑，並檢查不應開放的網路介面。圖形介面中的連線步驟可回到使用指南依序確認。

outbounds 出站：協定帳戶、預設出口與標籤

出站物件描述下一個連線目標

出站決定核心接到請求後如何建立後續連線。freedom 代表直接連線至目標，blackhole 用於封鎖流量；VMess、VLESS 等協定出站則會將請求送至指定的代理伺服器。遠端節點位址是下一個連線目標，不是使用者最後要造訪的網站。閱讀設定時，應分別記錄伺服器位址、使用者目標和 DNS 伺服器；三者都可能包含網域和連接埠，但在資料流中扮演不同角色。

在經典設定中，沒有符合路由規則的請求通常會交由 outbounds 陣列中的第一個出站處理，因此出站順序有實際影響，不只是排列展示。把 direct 移到第一項，會改變未符合規則的流量路徑。為避免誤解，可以指定明確的預設出口，並在路由末尾加入符合預期的兜底規則。調整後應以新連線驗證，因為既有連線不一定會隨設定變更立即切換。

以下是 VLESS 出站結構範例，只展示伺服器與帳戶欄位，不能直接當成已具備傳輸安全、可連線的節點。example.com 是說明用位址，全零 UUID 是示範值；實際部署必須使用服務端提供的參數。尤其不要看到連接埠是 443，就認定已啟用 TLS；連接埠只決定連線位置，是否建立安全層則由相應傳輸設定與服務端共同決定。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

帳戶欄位不能跨協定直接套用

VLESS 的 encryption 設為 none，描述的是此協定層的設定，不代表整條連線一定沒有保護；實際安全層還需查看 streamSettings。VMess 帳戶設定採用不同欄位與交涉邏輯，兩者的使用者物件不能直接互換。節點分享連結中的參數也可能使用縮寫或不同名稱；匯入後應先確認用戶端解析出的協定類型，再檢查設定，不要把連結中的查詢參數逐一貼進 JSON。

帳戶身分、傳輸方式與服務端支援必須彼此相符。UUID 正確但傳輸方式不符，可能在帳戶驗證前就中斷；安全層已建立但身分欄位錯誤，也仍無法完成代理請求。日誌顯示連線已抵達伺服器，不代表帳戶已通過驗證。若想了解兩種協定的差異，可閱讀VMess 與 VLESS 差異比較，再回頭核對實際節點欄位。

直連與封鎖也需要明確命名

direct、proxy、block 是本文使用的標籤，不是核心自動建立的固定物件。若規則寫了 outboundTag: "block"，就必須存在對應的出站。直接連線仍可能涉及網域解析、IPv4 與 IPv6 選擇、系統路由及本機防火牆，並非繞過所有網路設定。某個目標無法直連，也不能據此判定代理出站一定有問題；應分別測試兩條路徑。

用戶端支援多個節點，不代表執行設定會以相同方式排列所有出站。有些模式只產生目前使用的節點，有些則會產生額外出站或內部連線。切換節點後，手動撰寫的規則若引用了已不存在的標籤，就可能失效。長期維護時，應優先使用用戶端提供的固定路由目標，並檢查最後生效的設定，而不是依賴某次匯出時看到的暫時名稱。多個出站使用相同標籤也會造成引用對象不明，應避免這種寫法。

訂閱更新後，伺服器位址、連接埠、傳輸參數和節點識別資訊都可能改變。不要只保留舊位址再拼接新的帳戶欄位，也不要混用不同節點的安全層參數。請先備份可正常使用的用戶端設定，再匯入更新並單獨測試一個節點。若要了解分享連結與原生設定的對應關係，可參閱訂閱格式與分享連結對照，釐清訂閱容器、節點資訊和最終執行設定的差別。

routing 路由：規則順序、比對條件與兜底

由上而下檢查，採用第一條符合的規則

路由模組依已進入核心的請求屬性選擇出口，不會讓尚未進入核心的應用程式流量自動出現。經典欄位規則通常依陣列順序比對，第一條符合條件的規則就會決定結果。規則越前面，優先順序越高。因此，排查時不該只確認清單裡「有沒有那條規則」，還要確認請求是否在抵達該規則前就被其他規則接走。範圍寬廣的全流量規則應放在後面，否則後續的精確規則就沒有機會判斷。

同一條規則中的不同類型條件通常必須同時符合；同一個陣列中的多個候選值則通常表示符合其中任一項即可。例如，一條規則同時包含 inboundTag 和 domain，意思是請求必須來自指定入口，且網域也符合條件，而不是入口或網域符合其中一項即可。若要表達兩個獨立情境，拆成兩條規則會比把所有欄位塞在一條裡更清楚，也方便依日誌逐步找出問題。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["socks-in"],
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "127.0.0.0/8",
          "::1/128",
          "fc00::/7",
          "fe80::/10"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

網域規則與 IP 規則的適用範圍

full:example.com 表示精確比對網域；domain:example.com 則用於比對該網域及其子網域。裸字串與正規表示式的語意也不同，不能只因文字看起來相似，就認為涵蓋範圍一樣。為單一網站設定例外時，可先用精確比對確認結果，再視需要擴大範圍。正規表示式還需要處理 JSON 字串跳脫；反斜線層級錯誤可能改變規則含義，即使檔案仍能正常載入。

IP 規則比對的是目標位址，或路由過程中取得的解析位址，不會直接把瀏覽器網址列中的網域當成 IP 比較。若應用程式只送出 IP，且沒有可用的網域資訊，網域規則可能無法套用。相反地，應用程式送出網域時是否會觸發額外解析，則與 domainStrategy 有關。即使網域清單寫得很完整，也無法補救入口未收到請求、目標資訊缺失或規則順序錯誤等問題。

IPIfNonMatch 不代表每個請求都會先解析，再逐條檢查。若網域階段已符合範圍寬廣的規則，可能根本不會進入預期的 IP 比對流程。範例末尾的 network 規則是明確的代理兜底；使用時要留意它與解析策略的搭配。若希望網域請求先依解析結果判斷私有網路位址，就要重新設計規則或選擇合適的解析策略，不能假設前面的私有 IP 清單一定會優先處理所有網域。

資源檔案與規則結果應分開驗證

geosite: 和 geoip: 形式需要用戶端或核心能讀取相應的分類資料。類別名稱是否存在、資料是否可用，以及內容如何更新，都應在實際環境中確認。資源缺失屬於設定依賴問題；網域分類結果不如預期則屬於資料涵蓋範圍問題，兩者不要混為一談。初次除錯時，可先用明確網域和明確網段驗證路由邏輯，再加入分類集合，避免同時處理太多未知因素。

驗證規則時，先記錄入口標籤、請求目標、傳輸類型及最終出站，再一次只改一個條件。既有網頁連線、背景連線池和應用程式快取可能繼續沿用舊路徑，最好先關閉原有連線，再發起新請求。規則命中只代表核心選擇了某個出口，不代表遠端一定可連線。若出站選擇正確但請求失敗，接下來應檢查出站交握、DNS 或目標服務，而不是繼續調整已驗證有效的規則順序。

dns 設定：解析來源、比對範圍與連線依賴

先確認由哪個元件解析網域

一個請求可能經過應用程式自己的 DNS、系統解析器、核心內建 DNS，以及遠端代理環境中的解析程序。設定頂層 dns，不表示裝置上所有應用程式的網域查詢都會被接管。在明確設定代理的情況下，應用程式可以把網域交給代理，也可以先解析後只送出 IP；這兩種請求提供給路由的資訊不同。排查前應先確認應用程式送出的目標形式，而不是只看用戶端 DNS 設定頁填了哪台伺服器。

內建 DNS 主要供核心需要解析位址的流程使用，例如路由策略要求取得 IP、部分出站需要解析目標，或某些網域連線流程。是否使用內建解析，還取決於相應模組和選項。系統代理設定通常不會改寫系統 DNS。若網頁能正常使用、其他應用程式卻出現異常，可能是應用程式採用了不同的解析路徑；此時應分別驗證應用程式是否接入代理，以及網域由哪個元件解析，不要把所有連線問題都歸咎於 DNS 伺服器不穩定。

以下局部設定以公開 DNS 位址示範伺服器清單與靜態對應結構。hosts 中的測試名稱指向文件保留位址，只用來觀察對應行為，不提供實際網站服務。實際使用時請刪除這筆示範對應，並依網路可連線性、解析需求和隱私考量選擇 DNS 服務。範例不代表所有環境都必須固定使用這些位址，也不能據此認定解析結果一定適合目前的網路。

{
  "dns": {
    "hosts": {
      "full:resolver-test.example": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

網域範圍與回退行為應一併考量

伺服器物件可以包含 address、domains、expectIPs 等欄位，用來描述解析服務位址、優先比對範圍和預期結果。網域範圍不等同於簡單的存取規則：解析請求符合某台伺服器，不代表實際網站連線也會使用相同出站。解析路徑與一般連線路徑需要分別設定，再確認兩者是否符合預期。不要把 DNS 伺服器分組直接等同於路由中的代理與直連分組。

在支援這些欄位的經典設定中，expectIPs 用來判斷解析結果是否符合預期；skipFallback 和相關回退選項則會影響未符合或結果不符時的處理方式。不同核心的回退細節應以實際實作為準。不要以為多個伺服器清單一定會依照書寫順序逐一嘗試，也不要認定只設定一台備用伺服器就能處理所有失敗情況。請透過日誌觀察實際送出的查詢與回傳結果，再決定是否要縮小比對範圍。

queryStrategy 會影響內建 DNS 查詢使用的位址類型，常見值包括 UseIP、UseIPv4 和 UseIPv6。只回傳 IPv4 可能避開某些 IPv6 路徑問題，但這不代表整個系統停用了 IPv6，也不是修復所有連線失敗的長期通用方法。若系統本身的 IPv6 路由無法使用，應先確認問題發生在哪個環節；應用程式內建的解析器也未必遵循這裡設定的查詢策略。

解析伺服器本身也需要可用的連線路徑

使用加密 DNS 時，除了查詢內容，也要考量如何連線至解析服務，以及由誰解析該服務的網域。若代理伺服器位址需要透過 DNS 解析，而 DNS 連線又仰賴尚未建立的同一個代理，就可能形成啟動循環。設計時應為必要的初始解析保留明確路徑，並確認目前核心支援的 DNS 協定與使用方式。不要只把一個 HTTPS 位址填進伺服器清單，就認為連線依賴已自動解決。

hosts 可為少數名稱設定明確對應，但長期固定網站位址可能與負載平衡、位址變更和憑證使用情境衝突。用於排錯時，請記錄原始結果、修改前後的變化，以及如何還原設定。修改 DNS 後，系統、應用程式和核心都可能保留快取；驗證時應使用新請求，必要時依用戶端提供的方式清除快取或重新啟動相關程序。只重新整理網頁，不代表一定會重新解析網域。

比較結果時，不只記錄「能不能開啟」，也要區分查詢逾時、沒有回傳結果、位址類型無法連線，以及後續連線失敗。網域已成功解析但目標連接埠拒絕連線，問題就已進入連線層；直接使用 IP 可連線、網域請求卻失敗時，還要確認安全層要求的伺服器名稱。相關概念可參閱路由與 DNS 術語，再依本頁的驗證章節逐步縮小問題範圍。

policy 策略：使用者等級、逾時與統計

策略不是選擇出站的規則

policy 管理連線處理和統計相關行為，不負責依網域選擇代理出口。路由的 domainStrategy、DNS 查詢策略和使用者等級策略屬於不同層次；雖然名稱中都有「策略」，彼此不能取代。若要設定網站走直連或代理，應查看路由；若要釐清連線為何閒置一段時間後結束，才需要進一步檢查逾時、應用程式行為與服務端限制。

levels 是以等級編號為鍵的物件。鍵名在 JSON 中仍以字串表示，例如 "0"；帳戶物件中的 level 通常則是數字。等級用來將使用者或相關處理流程連結到一組策略，不是節點速度評分，也不是介面中的節點排序優先級。若未明確設定等級，許多設定會使用預設等級；不過，具體適用的模組和預設行為仍應依目前的核心確認。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 8,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false
      }
    },
    "system": {
      "statsInboundUplink": false,
      "statsInboundDownlink": false,
      "statsOutboundUplink": false,
      "statsOutboundDownlink": false
    }
  }
}

了解不同時間限制的生效階段

handshake 限制支援此策略的協定處理流程中，等待交握完成的時間，不能視為適用於所有網路連線階段的總逾時。連線至伺服器、TLS 交涉、代理協定驗證及應用程式請求各有不同情境。範例值只用來說明時間單位與設定結構，不是適用所有網路的最佳值。網路不穩時，適度延長可能有所幫助；但驗證參數錯誤，不會因為等待更久就變正確。

connIdle 表示連線在沒有資料活動時可以維持的時間。設定得太短，可能影響長時間閒置後繼續使用的工作階段；設得很長，則可能讓閒置連線占用更多資源。連線是否維持也會受應用程式、遠端服務和中間網路設備影響，因此不能只憑一次長連線中斷就認定是此欄位造成。先確認中斷前是否有實際流量，再比對用戶端和服務端日誌，判斷是哪一端主動結束連線。

uplinkOnly 和 downlinkOnly 用於一側流量結束後，另一側仍可繼續傳輸時的等待階段。這裡的上行與下行是依連線處理方向定義，並非頻寬上限。下載完成而上傳方向關閉，或應用程式主動半關閉連線時，相關策略可能影響後續收尾流程。這些欄位不能用來控制下載速度，也不應為了「加速」而任意設為零。請先確認問題發生在建立連線、持續傳輸，還是連線收尾階段。

統計計數與統計顯示應分開處理

啟用使用者統計通常還需要頂層統計模組、可識別的使用者資訊，以及提供統計資料的介面或用戶端功能。單獨把 statsUserUplink 改成 true，不會自動出現流量圖表。不同協定支援的使用者識別方式和統計維度也可能不同。若統計資料為空，請先確認實際流量經過哪個入口和帳戶，再檢查是否真的啟用了相應計數，不要立即懷疑代理連線沒有建立。

系統層級的入口與出口統計會依相應物件彙總；使用者統計則依帳戶計算。統計位置、重新連線、連線共用和計數重設，都可能造成不同讀數，不能要求每個數值在任何時刻都完全一致。用戶端顯示的速度也可能是定期取樣後計算出的差值，不是設定檔中的固定參數。調整統計設定時，不要同時變更路由和節點，以免把資料擷取差異誤認為實際轉送路徑改變。

多數個人桌面使用情境可先保留用戶端產生的策略，只有在明確重現閒置連線中斷、交握等待問題或統計需求時才調整。每次修改都記錄原值、修改原因和驗證條件，並保留還原方式。核心策略無法涵蓋作業系統休眠、行動網路切換、遠端逾時或應用程式本身的連線池管理。把所有逾時都調大，只會延後錯誤顯現，不一定能改善實際連線品質；根據證據調整，比套用一組所謂的最佳化參數更可靠。

傳輸與安全層：streamSettings、TLS 與 flow

分別核對協定、傳輸方式與安全層

節點設定至少包含代理協定、承載傳輸方式和連線安全三個面向。VLESS 或 VMess 描述代理協定；TCP、WebSocket 等描述承載方式；TLS 或 REALITY 則描述相應的安全機制。介面把這些選項放在同一張表中，不代表它們可以填入同一個欄位。連線失敗時，先依這三個面向逐一比對服務端資料，再檢查其他參數，比不斷切換「協定類型」更容易找出設定不符之處。

streamSettings 通常與出站的 settings 並列。前者說明如何建立承載連線，後者則說明代理協定本身的伺服器和帳戶參數。以下提供經典 WebSocket 與 TLS 的局部結構範例，用來說明欄位位置。此範例需合併至實際出站中，且伺服器必須提供相應服務。網路名稱與傳輸設定可能隨不同核心版本演進，出現別名或變更；複製前請先確認目前使用的實作。

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com",
      "allowInsecure": false
    },
    "wsSettings": {
      "path": "/proxy",
      "headers": {
        "Host": "example.com"
      }
    }
  }
}

位址、serverName 與 Host 各有用途

出站中的 address 是實際連線的下一個目標位址；serverName 用於 TLS 伺服器名稱相關處理；WebSocket 的 Host 則屬於 HTTP 請求資訊。合法部署中，三者可以不同，但不能因為「看起來都是網域」就任意互換。若服務端依伺服器名稱或 HTTP 主機名稱分配站點，欄位填錯就可能連到其他服務，即使位址和連接埠本身可連通也一樣。

path 必須與服務端約定的 WebSocket 路徑相同，包括大小寫、開頭的斜線，以及可能存在的查詢字串。HTTP 404 或升級失敗，有時代表路徑或反向代理轉送設定不相符，而不是帳戶身分錯誤。應先確認請求抵達預期服務，再檢查代理協定驗證。TLS 交握失敗則發生得更早；此時反覆修改 WebSocket 路徑通常不會改變結果，因為 HTTP 層尚未開始運作。

allowInsecure 應維持為 false。遇到憑證驗證異常時，請先檢查系統時間、伺服器名稱、憑證有效期限與部署狀態。關閉驗證只會掩蓋重要錯誤，無法修正連到錯誤服務的問題。某些環境可能需要額外設定受信任的憑證，應依實際憑證鏈處理，而不是全域略過驗證。排錯紀錄應保留具體錯誤類型，避免只留下「TLS 失敗」這種資訊不足的描述。

REALITY 與 Vision 各有明確適用範圍

REALITY 是 Xray 生態系中的相關安全功能，不能假設 V2Fly 或任意匯入工具都支援相同欄位。服務端提供的名稱、公開參數、短識別碼和用戶端指紋需要彼此對應；欄位名稱則應以目前核心及用戶端支援的結構為準。不要從不同教學各複製一段，再拼湊成同一個節點；也不要把用途不同的私密資料填進用戶端。若要深入了解運作原理，可閱讀REALITY 與 XTLS Vision 原理解析。

flow 位於相應協定的帳戶設定中；xtls-rprx-vision 只適用於支援此功能的服務端與傳輸組合。它不是普遍適用的速度選項，也不應一律加到所有 VLESS 節點。服務端未設定相應流控時，僅在用戶端填入可能導致連線失敗。指紋欄位同樣是特定安全層中的選項，不能取代正確的伺服器名稱，更不能只憑指紋名稱推斷實際瀏覽器的所有網路行為。

多路複用 Mux 與上述安全層也是不同概念。它會嘗試讓多個邏輯請求共用承載連線，是否適合取決於協定支援、傳輸組合與實際流量。預設啟用不保證更快，某些組合也可能不適用。若只有並行或長連線情境會失敗，可在其他參數不變的情況下進行對照測試。不要一次同時關閉 Mux、修改 flow、更換指紋並調整 TLS，否則無法判斷真正生效的是哪一項。

成功匯入節點只代表「欄位已解析」，不代表所有傳輸功能都已驗證。用戶端可能無法保留另一個核心的擴充欄位，也可能在編輯介面儲存時重新產生設定。匯入後應檢查重要參數，再發起新的連線測試；若需改用支援相應功能的用戶端，可前往下載頁選擇適用的平台，並保留原設定作為對照，避免排錯時失去可正常使用的參考。

設定驗證：載入檢查、日誌判讀與還原

分別驗證語法、載入與實際請求

設定驗證可分成三個層次。第一層是 JSON 語法，確認括號、逗號、字串和資料型態有效；第二層是核心載入，確認目前實作接受這些欄位、協定、資源和引用；第三層是實際請求，確認應用程式進入正確入口、路由選擇符合預期、出站交握成功，並取得目標回應。前一層通過不能取代後一層驗證。尤其是合併局部範例後，應重新檢查完整檔案，而不只是驗證剛複製的片段。

圖形化用戶端應優先使用內建的設定檢查、日誌與重新啟動核心功能；具體操作位置會依介面而異。修改前請保留原設定或匯出副本；修改後確認已確實儲存，再重新載入核心。若用戶端會自動產生設定，應檢查已儲存的介面選項，不要只編輯執行目錄中的暫存檔。看到程序仍在執行，不代表新設定已成功載入；舊程序可能仍在提供服務，新程序也可能啟動後立即結束，這些情況都需要從日誌判讀。

定位問題時，可以暫時提高日誌詳細程度。以下是局部日誌設定，適合短時間觀察目標、連線過程與路由結果。詳細日誌可能包含存取網域、伺服器位址及帳戶相關資訊，不宜長期收集或原樣公開。取得足夠線索後，應恢復較低的日誌層級，並依本機檔案管理方式處理不再需要的紀錄。提供排錯資料時，只需保留錯誤行和必要的前後文。

{
  "log": {
    "loglevel": "info"
  }
}

沿著資料流逐段確認

第一步，確認請求已抵達入站。使用明確遵循代理設定的應用程式發起新請求，並查看日誌中是否出現相應目標。若沒有紀錄，先檢查應用程式的代理類型、監聽位址、連接埠和系統代理的適用範圍。第二步，確認路由出口。若日誌中的出站與預期不同，再檢查標籤引用、規則順序與目標資訊；此時不要先修改帳戶身分。第三步才檢查遠端連線、安全層和代理協定交握，最後觀察目標服務的回應。

錯誤訊息必須配合發生階段判讀。「連線遭拒」通常表示該位址和連接埠沒有接受連線，可能來自本機入口，也可能來自遠端；「逾時」可能發生在解析、建立連線或等待回應時；憑證錯誤則通常需要檢查安全層情境。不要只摘出最後一個詞就下結論。請一併記錄錯誤發生前的目標、連接埠和使用的出口，才能判斷問題屬於哪一段連線。反覆點擊測試卻不保留相關資訊，通常無法增加有效線索。

建立可還原的最小變更流程

每次只修改一個獨立變數，例如先修正監聽連接埠，驗證後再調整網域規則。若多個節點參數必須同步變更，就將整組視為一次變更，並保留完整舊設定以便還原。驗證時使用相同的應用程式和目標，並建立新連線，避免前後兩輪分別使用網頁和不同協定的工具。若問題只出現在特定應用程式，也要檢查它是否使用內建解析、連線共用或略過代理的設定。

延遲測試只能證明它實際涵蓋的連線路徑。TCP 建立連線成功，不代表代理驗證成功；真實連線請求通過，不代表大型檔案的傳輸速度穩定；下載速度正常，也不代表每條網域路由都符合預期。可參閱v2rayN 測速方法說明，了解測試涵蓋範圍。排查路由問題時，優先觀察出口；解析問題則觀察查詢；傳輸量問題再進行持續傳輸測試，不要用單一數值概括所有設定狀態。

遷移到另一台裝置或另一種核心時，不要只複製最終 JSON 就算完成。系統權限、監聽衝突、分類資料、憑證信任和用戶端產生設定的方式都可能不同。先在新環境完成最基本的入口與單一節點連線，再逐步還原自訂 DNS、路由和策略。路由器或旁路由還涉及系統層級的轉送設定，可另行參閱在 OpenWrt 部署 Xray 的方式；不要把桌面明確代理設定當成透明接管方案。