V2Ray 設定檔參考

一、JSON 結構與用戶端界線

從圖形介面設定到核心設定

v2rayN 是桌面端的優先選擇，負責管理伺服器、訂閱群組、系統代理及核心啟動參數；實際處理連線的是選用的核心。Android 端的 v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心。三款用戶端的設定介面不盡相同，產生的 JSON 也未必完全一致。閱讀設定檔前，請先確認用戶端目前使用的核心，以及這份檔案是完整的執行設定，還是單一伺服器的分享內容。訂閱網址、分享連結、用戶端資料庫與核心設定是不同的資料來源，不能只因都包含伺服器資訊，就互相取代。

一般連線可依序理解為「本機應用程式連入站、路由選出站、出站連至遠端」。inbounds 定義接收方式，outbounds 定義傳送方式，routing 將連線分配至指定出口。dns 提供需要解析網域名稱時使用的設定，policy 調整連線計時與統計開關，log 則決定記錄哪些診斷資訊。並非每份設定都需要列出所有頂層物件；省略欄位代表採用核心預設行為，不表示該功能在整個連線流程中不存在。

先看一份可執行的最小設定

以下完整設定會在本機回送位址提供 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": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

如何閱讀物件、陣列與標籤

大括號代表物件，中括號代表陣列。入站與出站通常都是陣列，因為同一個程序可以同時監聽多個入口，也可以使用多個出口。連接埠應填數字，開關應使用布林值，不能把 true 寫成字串。JSON 的鍵名與字串必須使用雙引號，不接受行尾多餘的逗號，也不接受一般註解。介面允許填寫的註解或備註，不一定是核心設定欄位。啟動失敗時，請先排除語法錯誤，再檢查協定參數，避免不必要的修改。

tag 是設定檔內部的識別標籤，不是伺服器位址，也不是介面顯示名稱。路由中的 outboundTag 必須與某個出站標籤完全相符；大小寫、空格或連字號不同，都會影響參照。建議使用簡短且固定的標籤，修改後逐一檢查所有參照位置。頂層物件的排列順序通常不代表執行順序，但陣列順序可能有影響，尤其是路由規則與預設出口。請勿藉由調換頂層鍵的順序來修復路由。

匯出設定檔前，記下目前的代理模式與使用中的伺服器；匯出後另存一份副本，再逐項修改。檔案可能包含訂閱網址、使用者識別資料與驗證資訊；向他人說明問題時，只保留相關欄位並將記錄中的敏感資料去識別化。安裝檔與平台選擇請參閱安裝檔頁面；如果還沒有成功連線，請先依照快速入門流程完成基本設定，再回到本頁逐段閱讀。

二、inbounds 入站監聽與流量探測

監聽位址決定入口可供哪些裝置存取

入站是核心接收連線的入口，不是遠端伺服器。listen 指定繫結位址，port 指定連接埠，protocol 則決定入口協定。一般單機使用時，建議監聽 127.0.0.1，只接受來自本機回送網路的連線。改成 0.0.0.0 會監聽所有 IPv4 介面，區域網路中的其他裝置可能因此存取入口；實際能否連上，還取決於防火牆、網路隔離與路由設定。若要在區域網路分享，應一併評估驗證方式與存取範圍，而非只開啟用戶端的允許區域網路連線選項。

連接埠相同只是成功連線的條件之一。應用程式設定 HTTP 代理時，必須連至 HTTP 入站；設定 SOCKS 代理時，則必須連至 SOCKS 入站。有些用戶端提供混合連接埠，會在介面層將不同代理協定整合至同一入口；本文分別列出各種入站欄位，避免將特定用戶端的連接埠慣例誤認為所有核心的固定預設值。請查看參數設定中的實際監聽連接埠，再填入應用程式的代理位址。請勿同時啟動兩份設定並占用相同的位址與連接埠。

SOCKS 與 HTTP 獨立設定範例

以下片段可取代頂層的 inbounds 陣列，分別提供 SOCKS 與 HTTP 入口。SOCKS 的 udp 可處理相應的 UDP 轉送要求，但應用程式也必須實際使用 SOCKS 的 UDP 機制，後續出口亦須支援這類流量。只開啟此欄位，不會讓所有系統應用程式自動使用 UDP 代理。HTTP 入站適用於明確設定 HTTP 代理的應用程式；應用程式是否遵循系統代理設定，仍由應用程式本身決定。

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

sniffing 僅能協助識別部分連線資訊

流量探測會嘗試從協定交握中擷取網域名稱等資訊。例如，應用程式只提供目標 IP 時，核心仍可能從可識別的 HTTP 主機欄位或 TLS 交握中取得網域名稱，讓網域規則參與判斷。destOverride 指定允許探測的協定類別，並非讓核心解密任意內容。加密交握、應用程式協定與核心實作都會限制可識別的資訊。若無法探測到網域名稱，應回頭檢查應用程式提供的原始目標與 IP 規則；不要假設每條連線都能取得網域名稱。

routeOnly 主要用於將探測結果提供給路由判斷，不會直接依此取代連線目標。如此可區分「用哪個名稱比對規則」與「最後連到哪裡」。此欄位及探測支援範圍應以目前使用的核心為準；若核心不識別該欄位，請勿依照相似名稱自行建立鍵名。關閉探測後網域分流表現有所變化，表示規則可能依賴探測資訊；接下來應檢查 DNS 提供方式及應用程式是否保留目標網域名稱，而非直接認定伺服器異常。

系統代理開關是用戶端對作業系統所做的設定，不是此處的入站欄位。關閉系統代理後，手動填入 SOCKS 位址的應用程式仍可能繼續連入入口；開啟系統代理後，不遵循這項設定的應用程式仍可能直接連線。TUN 涉及虛擬網卡、路由接管與權限，不能用新增一般 SOCKS 入站取代。排查時請先確認應用程式採用哪種連線方式，再檢查相應入口，避免同時調整三個彼此不同的開關。

三、outbounds 出站協定與標籤參照

分開檢視出口定義與路由選擇

出站負責將連線傳送至下一個節點。protocol 決定使用直連、阻斷或特定代理協定；settings 儲存該協定專屬參數；streamSettings 描述與遠端之間的傳輸及安全層。路由只負責選擇出口，不會自動補上驗證資訊。即使路由記錄顯示已命中代理標籤，若伺服器位址、連接埠或安全參數有誤，連線仍會失敗。因此應分別確認「選到正確出口」與「出口成功建立連線」。

freedom 代表從目前裝置直接連至目標，blackhole 則用於終止相應流量。兩者都是本機處理方式，不需要訂閱提供遠端位址。以下片段列出兩個可重複使用的出口，可搭配第一章的入站使用。標籤名稱沒有特殊效果：將直連標籤改成其他名稱，不會改變協定行為；真正決定行為的是 protocol。但重新命名後必須同步更新路由、代理鏈及其他參照位置，否則設定可能無法啟動，或無法依預期轉送。

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

遠端出站應成組核對參數

實際使用的代理出口應根據現有伺服器資訊建立。不同協定的 settings 結構各異，不能將某個協定的使用者欄位直接移到另一個協定之下。檢視 VLESS 出站時，通常會看到伺服器清單、位址、連接埠、使用者識別資料及加密宣告等參數；Trojan 出站的驗證結構則不同。伺服器位址決定連線目的地，使用者識別資料或密碼用於驗證身分，TLS 或 REALITY 參數則決定安全交握方式。這些欄位彼此配合，單獨修改其中一項，可能導致整組設定不再相符。

使用圖形介面的伺服器編輯視窗，更適合管理這些關聯參數。先匯入可信來源提供的完整分享內容，再對照匯出的出站物件閱讀，通常比從空白檔案手動建立更容易維持一致。本文不提供可能被誤認為真實伺服器的帳號範例。若要向維護者說明問題，請提供協定名稱、傳輸類型、安全層是否啟用，以及錯誤發生階段，並移除驗證資料。請勿將包含完整使用者資訊的出站物件直接貼到公開討論區。

預設出口與陣列順序

在常見的單一路由設定中，未符合任何規則的連線會使用出站陣列中的第一個出口。因此，直連放在首位或代理放在首位，會產生不同的預設結果。介面中的「全域」、「略過區域網路」等模式可能會重建規則或調整出口順序，不能只看模式名稱就判斷最終設定。匯出檔案後，請檢查第一個出站項目，再確認是否有涵蓋所有連線的末尾規則。若設定使用負載平衡或出站鏈，請繼續檢視相關參照，不要將這類結構簡化為單一出口情境。

多個出口不代表會同時連線到所有伺服器。一般路由命中某個出站標籤後，連線便交由該出口處理；伺服器測速、自動選擇與故障轉移則需要用戶端或核心提供相應機制。將兩個代理物件並列在陣列中，不會自動依速度選擇。多個出口共用同一標籤也可能造成歧義或設定錯誤，請確保每個邏輯出口都有唯一識別標籤。如需在多部裝置間同步，可參閱訂閱、QR Code 與設定匯出同步說明，先釐清同步的是伺服器資料還是路由設定。

從可正常直連的最小設定開始擴充時，建議先保留一個已知可用的入口，只新增一個遠端出口，再加入一條指定該入口的規則。連線成功後，再逐步加入分流設定。如此可將入口、協定參數與規則三類問題分開檢查。若用戶端對自訂設定與內建伺服器模式採用不同的啟動方式，請先確認目前模式確實載入這份檔案；編輯未被載入的設定，不會影響正在執行的連線。

四、routing 規則順序與比對條件

規則依陣列順序逐一判斷

路由會將已進入核心的連線送往指定出口。常見的欄位規則使用 type: "field"，依目標網域、目標 IP、連接埠、網路類型或入站標籤進行篩選。規則通常由上而下判斷，符合可用規則後便選定出口；因此應先列出範圍明確的例外，再列出涵蓋範圍較大的預設規則。若把廣泛比對規則放在最前面，後續的細分規則可能永遠不會執行。檢視路由時，不只要搜尋目標網域是否出現，也要確認前面是否已有規則攔截該連線。

同一條規則中的不同條件通常都必須符合。例如同時填入 inboundTag 與 domain，代表連線必須來自指定入站，且符合指定網域。網域陣列中的多個項目則可用來設定多種可接受的比對值。請勿將不同欄位間的關係誤解為符合其中一項即可。若要表達兩種彼此獨立的條件，拆成兩條規則會更清楚。規則使用的入站與出站標籤必須已存在；中文註解不能取代實際標籤參照。

網域精確比對、後綴比對與 IP 網段

full: 用於精確比對網域名稱，適合只處理完整主機名稱；domain: 用於比對指定網域及其子網域，適合涵蓋同一網域下的一組服務；regexp: 代表正規表示式，適合確實需要模式比對的情況。一般字串的比對範圍也應參照核心文件確認，不能預設為精確比對。正規表示式寫入 JSON 後，還需要處理反斜線跳脫；寫錯時可能語法正確，卻無法比對。若明確網域即可表達規則，通常不必改用複雜的正規表示式。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "::1/128",
          "fc00::/7"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["local-socks", "local-http"],
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

此片段搭配前文的直連與阻斷出口使用。保留網域僅用於示範精確比對；私有位址網段規則用來說明 IP 條件；末尾規則則將兩個本機入口的其他連線送往直連。這不是代理分流方案。若要改成代理作為預設出口，必須先加入真實且可用的代理出口，再修改末尾標籤。若網域解析至私有位址，是否會符合 IP 規則，仍取決於當時是否已有目標 IP，以及網域策略是否觸發解析。

domainStrategy 與規則資料檔

AsIs 儘量使用連線現有資訊進行比對，不會為了網域路由主動額外解析。IPIfNonMatch 會在網域未比對成功時嘗試解析，再依 IP 條件判斷。IPOnDemand 則可能在遇到需要 IP 的規則時觸發解析。選擇後兩者會增加對 DNS 的依賴，也可能改變比對結果。此處的策略用於路由判斷，不等同於出站建立連線時的解析策略，也不能取代作業系統的 DNS 設定。

geoip: 與 geosite: 格式需要可用的規則資料檔，且檔案中必須包含相應分類。設定字串正確，不代表用戶端已附帶所需資料。啟動時若提示找不到檔案或分類，請先檢查核心資源目錄與用戶端的規則資料管理入口，不要隨意改用看似相近的分類名稱。將自訂設定移轉到其他裝置時，也要一併處理這些外部依賴；不能只複製 JSON 檔案，就認定兩邊環境相同。

排查規則問題時，先記錄應用程式傳給入站的目標是網域還是 IP，再確認流量探測是否補上網域名稱，最後依序推演每條規則的條件。暫時將明確的網域規則移到前面，可協助判斷是否被前面的規則攔截；測試後請恢復合理順序。規則變更通常只影響新連線；瀏覽器或應用程式若沿用舊連線，觀察結果可能會延遲。請建立新的測試連線再判斷，避免因舊連線仍在執行而反覆修改設定。

五、dns 解析路徑與分流範圍

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

一次存取可能涉及作業系統解析器、應用程式自己的解析器、核心內建 DNS，以及遠端伺服器的解析流程。頂層 dns 只定義核心需要解析時如何查詢，不會自動接管系統中的所有 DNS 要求。若應用程式先將網域名稱解析為 IP，再把 IP 傳給 SOCKS 入站，核心看到的原始目標就不再是網域名稱；若應用程式將網域名稱交給代理，後續解析位置也可能不同。排查時請先確認輸入的目標形式，不能只因設定檔中有 DNS 物件，就認定所有查詢都經過它。

以下範例使用一般 DNS 位址展示欄位層級，不代表適用於特定網路環境的最佳方案。servers 是解析伺服器清單，可填入簡單位址，也可使用包含比對條件的物件。hosts 可將指定名稱靜態對應至位址，適合暫時排查或固定內部服務；對應內容不會隨服務位址變更而自動更新。範例中的測試網域與文件位址僅用於說明格式，不應長期保留為實際網站記錄。

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

查詢策略不等於連線策略

queryStrategy 控制核心 DNS 查詢使用的 IP 位址類型。UseIP 允許取得 IPv4 與 IPv6 結果；UseIPv4 或 UseIPv6 則會限制查詢範圍，實際支援情況請以目前使用的核心為準。限制為 IPv4 有助於排查部分 IPv6 路徑問題，但無法修正伺服器交握參數錯誤。反之，若裝置網路只能透過特定 IP 類型連上服務，過度限制解析結果可能使原本可用的目標失去可連線位址。

路由中的網域策略、DNS 的查詢策略，以及出站本身的網域解析選項，作用階段各不相同。路由可能為了比對 IP 規則先解析一次，建立出站連線時又依自身邏輯處理目標；若兩處策略不同，觀察到的位址可能不一致。請先釐清要「依網域選擇出口」還是「依解析後的位址選擇出口」，再決定哪些階段需要解析。不要為了讓欄位看起來一致，就將多個位置的策略設為名稱相近的值。

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

一般 DNS 查詢與加密 DNS 要求都必須能連上解析伺服器。不同核心對 DNS 位址格式、直連模式與查詢路由方式的實作各異，不能將某種格式直接套用到其他核心。若使用以網域名稱表示的解析服務，還要考量首次連線至該服務時要如何解析，這就是引導解析問題。若解析服務只能透過某個代理存取，而代理伺服器位址又依賴同一個解析服務，就可能形成循環依賴。請為其中一段保留獨立且可用的初始連線路徑。

DNS 伺服器清單不應被視為固定的逐項備援清單。是否並行查詢、何時使用備用伺服器，以及符合網域條件的伺服器是否排除預設回退，都與核心實作及物件欄位有關。若要依網域選擇解析伺服器，請先在簡單設定下確認各伺服器都能連線，再加入網域條件與回退控制。一次新增多個伺服器又同時修改路由，會讓超時原因難以判斷。測試時請記錄查詢對象、目標 IP 類型與錯誤時間，區分解析超時和連線超時。

快取也會影響觀察結果。應用程式可能保留自己的網域解析結果，作業系統可能快取記錄，核心內部也可能重複使用解析資訊。修改 DNS 後，既有連線不一定會立即重建，舊位址也可能繼續出現。請先關閉測試應用程式的舊連線，再送出新要求；必要時使用用戶端提供的重新啟動核心功能來清除執行狀態。不要只靠重新整理一次網頁，就判斷新的解析策略已完全生效；也別將快取造成的短暫差異誤認為分流規則隨機失效。

若網域無法存取但已知位址可連線，仍須考量憑證與伺服器名稱，不能直接將網站 URL 換成 IP，並視為等效測試。正確的排查順序是確認解析結果、確認選用的出口、確認該出口能連至目標位址，再檢查交握階段。記錄這些層次，才能避免把 DNS 錯誤與安全層錯誤混成一句「無法開啟」。

六、policy 連線計時與統計策略

依使用者等級套用策略，而非依介面群組

policy 用於管理連線生命週期與部分統計行為，不負責選擇出口，也不會修改協定驗證。levels 的鍵是使用者等級的字串形式，例如 "0"；協定支援的使用者等級欄位則用來對應相應策略。此處的等級不是訂閱群組、伺服器優先順序，也不是路由清單序號。只建立一個等級物件，不會讓所有協定物件自動套用該等級。閱讀匯出的設定時，應同時檢查使用者物件中的等級，以及核心是否支援該協定。

以下範例展示等級策略與系統統計開關的結構。數值僅用來說明欄位，不是適用於所有裝置的效能建議。一般使用情境可先保留用戶端預設值，只有當記錄與連線表現顯示可能是計時問題時，才考慮調整。不同核心的預設值、緩衝配置與統計介面各有差異，因此移轉設定時，請先確認欄位仍受支援，再比較執行結果。將同一組網路參數複製到所有裝置，不保證會有相同效果。

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

四個時間欄位各自限制不同階段

handshake 表示入站協定交握階段的時間限制，單位為秒。它不等於網頁完整載入時間，也不是可以涵蓋所有遠端 TLS 交握行為的通用開關。若交握前本機連接埠就無法連線，調高此值也沒有幫助；若遠端出站因驗證錯誤而失敗，延長入站交握時間同樣無法修復。請先根據記錄確認問題發生在哪個階段，再評估是否需要合理延長時間。

connIdle 用於限制連線在沒有資料傳輸時持續等待的時間。設定過短，可能影響間歇傳送資料的長連線；設定過長，則可能讓閒置連線占用資源更久。應用程式層級的心跳、伺服器閒置策略與網路中介設備的超時設定，也會影響連線存續；單獨延長用戶端計時，無法涵蓋其他環節。排查週期性中斷時，請記錄中斷前是否有資料交換，以及用戶端與伺服器兩端是否設定了不同的超時限制。

uplinkOnly 與 downlinkOnly 用於處理連線一側結束後，另一方向仍可繼續傳輸的等待階段。這類半關閉狀態不同於整條連線都閒置：上傳結束不代表下載也已完成，下載結束也不表示所有應用程式都停止傳送。設定過於激進可能截斷需要完成收尾的傳輸，盲目調高則可能延長殘留連線。若遇到大檔案傳輸或要求結尾異常，應搭配應用程式協定與記錄進行觀察，不要將這兩個欄位誤認為上下傳速度限制。

啟用統計不代表介面會立即顯示資料

使用者統計需要相應的使用者識別資料與核心支援；系統統計則會依入站與出站物件計數。設定為 true 只代表允許收集相應統計，不會自動建立讀取介面，也不會自動在用戶端新增面板。部分情境還需要頂層統計模組、API 服務與呼叫端配合。圖形介面用戶端可能已管理相關設定，手動加入重複的 API 入站或統計服務，可能造成連接埠衝突。若只需查看日常連線資訊，請優先使用用戶端現有的記錄與狀態介面。

策略中的緩衝相關欄位，也不應視為通用的加速按鈕。緩衝大小、並行連線數、裝置記憶體與協定行為會共同影響資源使用；增加緩衝可能提高記憶體負擔，卻無法提升遠端線路容量。除非能重現明確的瓶頸，且有核心文件作為依據，否則請先保留預設值。尤其在行動裝置上，背景執行限制與系統省電設定可能才是中斷原因；核心策略無法取代作業系統對背景執行的授權。

修改策略時一次只調整一項，並保留原本有效的設定。測試應涵蓋短時間要求、持續傳輸與閒置後恢復三種情境，分別觀察是否異常。若用戶端會重新產生設定檔，請透過支援的進階設定入口儲存，而非一再修改暫存執行檔。設定能成功啟動，只表示語法與部分語意已獲接受，不代表計時策略適合目前的應用程式；仍須透過實際操作確認限制。

七、傳輸、安全層與核心差異

代理協定之外，還有傳輸組合

伺服器項目通常同時包含代理協定、傳輸方式與安全層。代理協定負責驗證與代理行為，傳輸方式決定資料如何承載，安全層則負責相應的交握保護。這些選項在介面上可能相鄰，卻不是同一個欄位。出站的 protocol 與 streamSettings.network 用途各異；若將介面上的傳輸類型填入代理協定欄位，就會產生錯誤結構。若某份設定只能在一種用戶端使用，請先比較這三個層次，再確認核心是否接受相應語法。

以下是 WebSocket 與 TLS 的傳輸片段，應放在包含實際伺服器參數的出站物件內，而非直接放在 JSON 頂層。範例使用保留網域說明欄位位置，不是可直接連線的伺服器資料。傳輸方式、路徑與憑證名稱也必須符合伺服器端設定。只複製這段而未正確設定出站協定與驗證資料，無法建立有效連線。

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

位址、serverName 與 Host 各有用途

出站伺服器位址決定要向哪個主機建立網路連線。serverName 用於 TLS 交握及憑證名稱驗證；WebSocket 的 Host 則是 HTTP 交握中的主機資訊。在某些部署方式中，三者相同；另一些部署則要求使用不同值。請勿為了看起來整齊，就強行將它們改成相同值。遇到憑證錯誤時，應先檢查裝置時間、伺服器名稱及伺服器端憑證設定，而非關閉憑證驗證。停用驗證會改變連線的信任條件，也可能掩蓋目標填寫錯誤。

WebSocket 路徑用於對應伺服器上的傳輸入口，大小寫與路徑內容都應符合伺服器端設定。它不是可任意填入的網頁網址路徑，也不應從其他伺服器項目複製。若回應內容看起來像一般網頁，或出現交握狀態錯誤，可能是連到了同一主機上的其他服務。此時應檢查傳輸方式、路徑與主機欄位，不要只是不斷更換使用者識別資料。一般連接埠連線測試只能證明該連接埠有回應，無法證明後續的代理協定組合正確。

REALITY 與核心選擇

REALITY 是安全層相關功能，不是頂層代理協定名稱，也不是可隨意開啟的通用強化選項。使用前應確認目前核心支援此功能，並核對伺服器提供的伺服器名稱、公鑰材料、短識別碼及其他必要參數。不同核心或設定世代可能使用不同欄位表示，不能靠猜測鍵名解決相容性問題。本文不提供缺少伺服器端資料的 REALITY 通用範本；請以用戶端能正確識別的完整分享內容為起點，再對照實際產生的出站物件。

v2rayN 的實際功能取決於所選核心與用戶端適配；v2rayNG 與 v2flyNG 也不能只因介面相似，就視為完全相同。需要特定協定或安全層時，請先確認核心已實作該功能，再選擇用戶端。更換核心後，舊設定中的欄位可能遭到拒絕，或採用不同預設行為。請先儲存原設定，再透過用戶端支援的方式重新產生設定，並比較重要參數。相關背景請參閱Xray 核心與 V2Fly 核心的差異。

Mux 多路複用屬於另一種連線組織機制，無法修復安全交握或驗證錯誤，也不保證對所有應用程式都有幫助。用戶端中的 Mux 開關可能會影響產生的出站設定，使用前應確認協定組合及核心限制。排查時請先關閉額外的連線組織選項，以基本組合完成測試，再逐項恢復。協定尚未連通時，請勿同時調整 Mux、DNS、路由與探測；否則即使問題碰巧排除，也難以判斷是哪一項設定生效。

跨平台移轉也要留意系統環境。Windows、macOS、Linux 的系統代理機制各不相同；Android 的 VPN 連線方式與個別應用程式選擇，也不屬於 JSON 傳輸欄位。即使傳輸設定正確，若應用程式沒有連入入站，仍不會產生預期的連線。macOS 首次執行時若涉及系統放行或網路權限，可參閱安裝放行與網路權限說明，不要透過修改協定參數來處理系統權限問題。

八、設定檢查、記錄判讀與還原

依序檢查語法、啟動、入口與出口

排查設定問題前，請先準備一份可還原的有效副本。儲存目前的用戶端設定與自訂設定後，一次只修改一個層級，重新啟動相應核心，再建立新連線。若無法啟動，先查看第一則有意義的錯誤訊息：缺少逗號屬於 JSON 語法問題；未知欄位或協定屬於設定相容性問題；監聽失敗通常與位址或連接埠衝突有關。這些問題都發生在正常轉送之前，不應先從遠端伺服器速度或網站是否可用著手。修正最前面的錯誤後，再查看後續記錄，避免追查連帶錯誤。

以下片段可暫時取代頂層 log 物件，用來增加診斷資訊。記錄等級設為 debug 時會產生大量內容，可能包含目標位址與連線特徵；排錯完成後，請恢復適合日常使用的等級。範例未指定檔案路徑，實際輸出位置取決於啟動方式與用戶端管理設定。若介面沒有顯示新增記錄，請先確認用戶端是否支援該等級，以及目前執行的程序是否已載入修改後的檔案，不要立即認定記錄模組失效。

{
  "log": {
    "loglevel": "debug"
  }
}

依錯誤發生階段縮小排查範圍

核心正常啟動後，先確認應用程式是否真的建立了入站連線。若找不到相應記錄，請核對應用程式的代理位址、代理協定、系統代理模式與個別應用程式設定；若有記錄但選到錯誤出口，請檢查標籤、規則順序與目標形式；若出口正確但連線失敗，再檢查遠端位址、驗證資料、傳輸與安全層。若已建立連線但只有特定網域異常，再進一步檢查 DNS、網域比對及目標服務。依此順序排查，可避免將所有問題一概歸類為「節點無法使用」。

連接埠拒絕連線通常表示目標連接埠沒有監聽或主動拒絕，不等於 DNS 解析失敗；解析超時則發生在取得位址之前；交握失敗表示已進入某種協定協商階段，但仍須結合記錄判斷實際原因。超時本身不是明確結論，可能發生於建立連線、協定交握或等待回應等不同階段。向他人說明問題時，請寫清楚發生階段與重現步驟，不要只提供一行籠統的錯誤訊息。記錄中的時間有助於將操作與相應訊息對應起來。

建立容易判讀的最小重現案例

先選用一台目前使用中的伺服器，設定一個明確入口與一條簡單的出口規則，暫時移除其他分流設定。確認基本連線正常後，再依序恢復網域規則、IP 規則、DNS 條件與進階策略。恢復某個層級後問題再度出現，就保留該層最少的相關條件繼續排查。若設定依賴規則資料檔，也請說明檔案是否存在及分類是否有效。第一份排錯資料不要使用包含大量無關規則的完整匯出檔，過多資訊會掩蓋真正的關聯。

用戶端重新產生設定檔是常見的變因。修改後短暫有效，切換伺服器後又失效，通常表示編輯的是暫存檔，或目前模式沒有儲存自訂內容。請回到用戶端支援的設定入口確認儲存位置，再比對重新匯出的設定檔。訂閱更新只會更新它所管理的伺服器資料，不應假設所有手動新增欄位都會保留。主視窗介面請參閱伺服器清單、記錄面板與參數設定導覽；設定結構則可接續閱讀config.json 分段解析。

常見的邊界問題

還原時，請恢復最後一份已知有效的用戶端設定或完整設定檔，重新啟動核心，並確認目前使用的伺服器、代理模式及入口連接埠。若問題仍存在，表示原因可能不只來自這次 JSON 修改，還應檢查系統網路、權限與伺服器端狀態。基本操作順序可回到快速入門核對；需要重新選擇適合裝置的用戶端時，請前往安裝檔頁面，不要用反覆更換用戶端取代錯誤階段的定位。