V2Ray 設定檔參考

一、JSON 結構與設定範圍

區分用戶端資料與核心設定

v2rayN 儲存的訂閱群組、介面選項與伺服器記錄都屬於用戶端資料。啟動連線時，用戶端會依據目前選取的伺服器、路由預設與參數設定產生核心設定檔。核心讀取的是後者，而非介面資料庫。直接修改執行目錄中的暫存設定，切換伺服器或重新啟動後可能遭到覆寫。因此，請先確認要修改的是介面選項、路由範本，還是獨立的自訂設定。

v2rayNG 同樣負責匯入、選取伺服器及啟動核心；v2flyNG 則是採用 V2Fly 核心的 Android 替代選擇。不能只因選單名稱相似，就認定三者匯出的設定完全相同。檢視日誌時，請記下實際啟動的核心名稱；檢視設定時，確認檔案來自本次啟動，而非上次匯出的副本。設定檔路徑會隨平台及用戶端設定而異，請勿直接套用其他裝置的固定目錄。

頂層物件的分工

傳統 JSON 的最外層是物件。inbounds 和 outbounds 是陣列，分別容納一個或多個入口與出口；routing、dns、policy 通常是物件。欄位必須放在對應層級，不能把某個出站的 settings 放到頂層。大括號表示物件，中括號表示清單；鍵名與字串使用英文雙引號，數字和布林值則不加引號。

用於定位本機問題的完整基準設定

以下設定只接受本機 SOCKS 流量，並透過本機網路直接連線至目標。它不會連線至任何遠端代理，也不會自動設定系統代理，適合用來確認核心能否啟動，以及本機連接埠是否能接收請求。若要另存為獨立檔案，請使用 UTF-8 編碼；不要將說明文字、程式碼區塊標記或行號寫入檔案。若用戶端已占用相同連接埠，請先停止原本的核心程序。

{
  "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": {}
    }
  ]
}

這份基準設定刻意不加入路由與遠端伺服器，避免同時變更多個條件。請求成功代表本機監聽與直連路徑大致正常，但不代表訂閱中的伺服器可用。後續新增出站時，先將預計作為預設出口的項目放在第一位，再逐步加入規則。每個步驟都保留上一份可正常運作的檔案；發生錯誤時，先還原本次變更，不要繼續疊加設定。

標準 JSON 不允許尾隨逗號或註解；部分核心的輸入方式可能支援擴充語法，但跨工具移轉時不應依賴這些功能。也請移除重複鍵，因為不同解析器處理重複鍵的方式可能不同。編輯器的語法檢查只能找出括號、引號等格式問題，無法判斷目前核心是否支援特定協定欄位，更無法確認伺服器位址是否真的連得上。

二、inbounds：本機監聽與流量入口

監聽位址與連接埠各自控制什麼

入站設定決定應用程式如何將流量交給核心。listen 是綁定的本機位址，port 是等待連線的本機連接埠，protocol 則指定入口使用的協定。監聽 127.0.0.1 僅供本機程式使用；監聽 0.0.0.0 則會綁定所有 IPv4 網路介面，區域網路裝置可能因此連入。擴大監聽範圍後，也要一併考量防火牆、驗證機制及所在網路是否可信。

本機監聽連接埠不必與伺服器連接埠相同。瀏覽器連至本機連接埠，再由核心連至遠端伺服器連接埠，這是兩段獨立的連線。若連接埠已被占用，啟動日誌通常會顯示綁定失敗；請先找出占用的程序，再決定停止舊程序或更換連接埠。只修改命令中的連接埠，卻不調整用戶端的監聽設定，仍會導致連線遭拒。

如何選擇 SOCKS 與 HTTP 入站

SOCKS 入站適用於支援 SOCKS 代理的應用程式；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"]
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

使用這段設定測試 HTTP 入站時，請填入 http://127.0.0.1:10809；測試 SOCKS 入站時，則使用對應的 SOCKS 位址。有些用戶端會產生混合入口，讓同一個連接埠辨識多種代理請求，但是否支援取決於使用的核心與實際產生方式。疑難排解時，請先查看實際設定，不要根據教學截圖推測連接埠所用的協定。

UDP 與流量探測的適用範圍

啟用 SOCKS 的 udp 後，只代表該入口允許處理符合協定規範的 UDP 轉送請求。應用程式本身也必須支援 SOCKS UDP，後續出站與遠端連線同樣要支援相應功能。這不會自動收進系統中的所有 UDP 流量。瀏覽器的一般 HTTP 代理請求與部分應用程式的 UDP 通訊，也可能走不同路徑，請分開驗證。

sniffing 會嘗試從已進入核心的流量辨識目標資訊，例如 HTTP 主機名稱或 TLS 握手中的網域名稱，以輔助路由判斷。這不是解密功能，也無法保證每個請求都能辨識出網域。部分加密握手、純 IP 服務或非標準協定可能無法提供這些線索，因此不能以「啟用探測」取代正確的 DNS 與路由設計。

destOverride 會利用探測結果處理目標位址，不只是替日誌加上名稱。若原始目標是特定 IP，探測結果卻是網域名稱，後續解析與連線目標可能受到影響。若某個網站只有在啟用探測時才出現異常，請針對同一請求比較開啟與關閉時的結果，並檢查是否命中不同規則。不要同時變更探測、DNS 與伺服器設定，以免失去判斷依據。

與區域網路共享不同於接管系統網路

若要將電腦上的代理分享給手機或電視，裝置應填入電腦的區域網路位址，而不是電腦自身的迴路位址。您還需要允許相應的入站連線並限制來源網段；在公共網路中，不應公開未經驗證的入口。圖形介面的設定方式請參考允許區域網路連線的設定方式；修改後請從另一台裝置測試，不要只在電腦本機測試。

一般 SOCKS、HTTP 入站需要應用程式主動使用代理。系統代理開關只會向支援該功能的程式提供代理設定；TUN 則涉及虛擬網路介面、路由與權限，不能只新增一般入站就達成相同效果。若瀏覽器能用代理、終端機卻沒有，請先確認程式是否讀取系統設定或環境變數；若完全沒有入站日誌，應優先檢查流量入口，而非先調整遠端協定。

三、outbounds：出口、標籤與遠端連線

出站物件與預設出口

出站設定描述核心收到請求後，要透過哪種方式連線至目標。每個物件的 protocol 會決定 settings 中允許哪些欄位；不同協定的設定不能只因名稱相同就直接複製。tag 是供路由引用的本機識別標籤，不會自動傳送給伺服器，也不是訂閱中的顯示名稱。建議使用簡短且穩定的標籤，並將介面備註與設定引用分開管理。

沒有規則命中時，傳統設定通常會使用出站陣列的第一個項目。因此，調換陣列順序可能改變大量未明確命中的流量。將代理出站放在首位，再設定私人位址直連；或將直連放在首位，只代理特定網域，是兩種不同的預設行為。移轉設定時，請先明確決定要採用哪一種，再逐條核對規則，不能只確認標籤是否齊全。

直連與封鎖是兩種基礎出站

freedom 會使用本機網路連線至目標；這不代表不需要解析網域，也不保證目標一定連得上。blackhole 用於拒絕選定的流量；若不慎放在首位，未命中的請求也可能被拒絕。以下片段可搭配路由作為基礎設定，兩個標籤分別代表直連與封鎖動作，本身不包含遠端代理連線。

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

路由中的 outboundTag 必須與此處的標籤完全相同，大小寫與連字號也不能不同。修改標籤時，請一併搜尋並更新所有引用。多個出站使用相同標籤會增加閱讀與定位困難，不應把標籤當成可重複使用的分類名稱。有些引用缺失會在載入設定時直接報錯；有些組合則可能等到處理請求時才暴露問題。

透過本機上游了解出站結構

以下出站會將請求交給本機的另一個 SOCKS 服務。這個範例不需要遠端帳號，方便說明伺服器清單的巢狀結構；只有在 127.0.0.1:2080 確實有其他服務監聽時才會成功。請勿讓這個上游連接埠指向目前核心自己的入站，否則可能形成流量迴圈。若要獨立測試，請先確認上游服務本身正常運作。

{
  "outbounds": [
    {
      "tag": "upstream",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 2080
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

VMess、VLESS、Trojan 和 Shadowsocks 的驗證結構各不相同。伺服器位址、連接埠、使用者識別碼或密碼，以及加密方式，都應依照伺服器提供的設定填寫，不能只更換 protocol 名稱就完成轉換。除了協定參數，還可能需要符合傳輸與 TLS 條件。用戶端成功匯入只代表連結可被解析，不代表遠端驗證與傳輸設定一定吻合。

連線失敗時該從哪個層級排查

遠端位址若是網域名稱，通常必須先解析才能建立代理連線。若強制要求這次解析依賴尚未建立的代理，就會形成循環依賴。連線日誌中的解析失敗、連線逾時、連線遭拒、驗證失敗與 TLS 握手失敗，分別指向不同階段；先依錯誤發生的階段排查，比連續修改多個出站參數更有效。

若需要多層轉送，請確認目前核心支援的出站串接欄位及其適用範圍，不要直接合併另一種核心的範例。本機上游監聽、中間出口與最終出口各有不同的故障點；鏈路越長，就越需要逐跳驗證。一般訂閱使用者應優先保留用戶端產生的單一出口設定，只有在確定額外一跳能解決什麼問題時，才增加複雜度。

更新訂閱可能會替換伺服器記錄，但不一定會一併更新自訂設定中的舊位址、驗證參數或標籤。如果介面顯示已更新，連線卻仍使用舊資料，請檢查目前選取的設定類型與啟動日誌。分享設定前，請移除驗證資訊、訂閱網址及可連結個人帳戶的欄位；通常保留結構層級、協定名稱與錯誤階段，就足以討論設定問題。

四、routing：規則順序與出口選擇

先比對規則，再選擇出口

路由不是伺服器清單，而是用來判斷已進入核心的請求。規則通常依陣列順序逐一檢查，命中後便選擇相應出口，不會繼續尋找後面看似更精確的規則。因此，放在前面的寬泛規則可能遮蔽後續的精細規則。閱讀設定時，應從第一條規則開始模擬，而不是先分別看完網域規則與 IP 規則，再猜測結果。

同一條規則中，不同類別的條件通常必須同時符合；同一類別中的多個值則代表符合其中一項即可。例如同時設定 inboundTag 與 domain，表示指定入站且目標網域符合條件，而非兩者擇一。若要表達兩種彼此獨立的情況，應拆成兩條規則。標籤條件尤其適合用來區分瀏覽器入口與其他應用程式入口。

易於閱讀的規則片段

以下片段需要搭配第三章的 direct 與 block 出站。它會依序處理範例封鎖網域、私人位址與文件範例網域。geoip:private 需要執行環境提供相應資料檔；若日誌顯示資料檔缺失，請修正資源路徑，或依實際網路改用明確的 CIDR 清單，不要忽略啟動錯誤。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

full: 用於完全符合網域名稱；domain: 則符合該網域及其子網域。兩者都不能填入網頁路徑、查詢參數或協定前綴。要比對特定網站的請求，不能把完整網頁網址放進網域陣列。只有確實需要比對模式時才使用正規表示式，因為較難檢查；若能以明確網域表達，就不必使用複雜的正規表示式。

網域策略不等於 DNS 總開關

AsIs 表示在路由階段盡可能沿用既有目標資訊，不會為了比對 IP 規則而主動解析網域。IPIfNonMatch 會在網域比對沒有結果時嘗試解析，再繼續比對 IP；IPOnDemand 則會在遇到需要比對 IP 的規則時觸發解析。實際流程也會受到請求原本提供的是網域還是 IP 影響，不能只看策略名稱判斷。

若應用程式已先將網域解析成 IP，再以 IP 連線至本機代理，核心可能已無法取得原始網域來比對。流量探測有時能補上線索，但不適用於所有協定。排查「網域規則沒有命中」時，請先確認入口取得的目標格式，再確認探測結果，最後才檢查網域清單；否則容易把資訊不足誤認為規則語法錯誤。

連接埠、網路類型與私人位址

port 比對的是目標服務連接埠，而非本機代理監聽連接埠；network 可用來區分 TCP 與 UDP。將所有網頁連接埠都設為代理，不等於讓特定瀏覽器的所有流量都走代理，因為 DNS、即時通訊或其他協定可能使用不同的目標連接埠。普通的欄位路由也無法直接推導出依程序選擇出口的功能。

私人位址規則常用來讓路由器管理頁面、區域網路服務與本機資源維持直連。不過，網域解析成私人位址後能否命中 IP 規則，取決於路由是否取得解析結果。使用合成位址方案時，還必須依該方案對核心的要求處理位址映射與流量接管；不可將合成位址一概視為一般私人網路位址而直接連線，否則請求可能略過必要的還原流程。

驗證規則時，請選定一個明確目標，暫時啟用能顯示出口標籤的日誌，送出一次請求，再核對入口、目標與出口。重試可能產生多筆記錄，瀏覽器背景連線也可能干擾判斷；使用命令列送出單一請求更容易定位。連線測試方式可接著參考首次連線與代理生效檢查，不要單憑網頁載入速度推斷路由結果。

五、dns：解析來源與循環依賴

先區分三種解析方式

設定 DNS 前，請先區分應用程式自行解析、核心內建解析與遠端伺服器解析。應用程式可能先從系統取得 IP，再將 IP 交給代理；也可能把網域交給 SOCKS，由後續鏈路處理。核心中的 dns 物件只會影響使用內建解析器的路徑，不會自動取代系統解析器，也不會自動改變瀏覽器個別設定的加密 DNS。

伺服器本身的網域名稱也需要解析，這與最終要瀏覽的網站網域是兩件不同的事。前者是建立代理鏈路的先決條件；後者則可能依協定與出站行為交由遠端處理。排查 DNS 問題時，請分別記錄這兩個網域。若伺服器位址無法解析，造訪任何網站都可能失敗，不能因此認定所有目標網站的解析都出了問題。

基礎欄位與條件式解析

servers 可包含簡單的伺服器位址，也可包含帶有比對條件的物件；hosts 則用來在內建解析器中設定明確的位址對應。以下範例展示固定對應與條件式 DNS 伺服器的結構。這不是適用於所有網路的通用方案；仍須自行評估實際伺服器的可用性、網路政策與隱私需求，不能假設公共解析位址在任何環境都能使用。

{
  "dns": {
    "hosts": {
      "lab.example.com": "192.168.50.10"
    },
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "domains": ["domain:example.com"]
      },
      "8.8.8.8"
    ]
  }
}

範例中的區域網路位址用來說明靜態對應，只有本機確實存在相應服務時才有意義。核心的 hosts 也不等同於作業系統的 hosts 檔案：若請求根本沒有經過內建解析器，這項對應可能完全不會生效。為網域設定固定對應後，還需考量服務位址變更、多地區入口與憑證名稱；固定 IP 並非長期取代正常解析的通用方法。

查詢如何送出，以及如何備援

DNS 伺服器項目中的網域條件是用來選擇解析伺服器，不是替業務流量選擇代理出口；業務路由仍由 routing 處理。條件式伺服器失效後是否改用其他伺服器、是否同時查詢，以及是否接受回傳位址，都要依目前核心支援的欄位判斷。不同核心的備援參數不能互相套用；修改前請先確認欄位名稱與實際用途。

內建 DNS 發出的查詢也有自己的網路路徑。部分形式會經過核心路由，帶有本機語意的某些解析形式則會使用本機網路堆疊，不能只因為「使用加密 DNS」就判定查詢經過哪個出口。若解析服務位址採用網域名稱，還需要先解決該服務網域的初始解析問題；若初始解析又依賴同一服務，就可能形成循環。

常見的循環狀況是：建立代理需要先解析伺服器網域，但解析請求又被要求必須經過尚未建立的代理。解決時請先整理依賴順序，為建立連線所需的位址保留可用的初始解析路徑，再處理業務網域。將所有 DNS 請求一律送往同一個代理出口，看似規則簡單，實際上可能讓啟動流程完全無法完成。

IPv4、IPv6 與快取

取得 AAAA 記錄，不代表目前網路具備穩定的 IPv6 連線路徑；只能連 IPv4，也不代表網域沒有 IPv6 服務。修改查詢策略會影響回傳的位址類型，但無法修復路由器、電信網路或遠端伺服器沒有 IPv6 監聽等問題。若只有部分目標逾時，請分別查看解析結果與實際連線位址，再決定是否暫時限制位址類型以進行比較測試。

DNS 快取可能存在於瀏覽器、作業系統、用戶端及遠端等多個位置。修改設定後，同一個網域仍呈現舊行為，不一定代表新設定沒有生效。請先重新啟動實際負責解析的元件，或改用明確的測試網域，再查看日誌。不要為了清除快取而同時刪除用戶端的所有資料，否則訂閱、路由與伺服器選擇等設定也會成為新的變因。

比較命令時，curl 中的 socks5:// 與 socks5h:// 處理網域的方式不同；後者會將目標網域交給 SOCKS 代理端解析。這項差異適合用來判斷本機解析是否參與，但成功只代表該請求路徑可用。若要進一步排查訂閱更新時的解析錯誤，請參考訂閱更新失敗的排查方式，因為下載訂閱不一定會使用目前的代理鏈路。

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

策略控制行為，不負責選擇出口

policy 用來設定連線處理策略，例如握手等待時間、閒置逾時與統計開關。它不是路由規則，也不負責決定特定網域要直連還是走代理。發生連線失敗時，請先確認失敗階段；只有日誌確實顯示與等待或閒置中斷有關，才有理由調整策略。一味拉長所有逾時時間，往往只會讓錯誤晚一點出現。

levels 中的鍵代表使用者等級，在 JSON 中須以字串表示。等級不是速度方案或訂閱方案，而是協定使用者設定所引用的一組策略索引。是否有可供引用的使用者等級，取決於相應的入站與協定。若未設定專用等級，就應依預設行為處理；不要以為新增等級物件後，它就會自動套用至所有流量。

連線時間欄位的意義

以下片段展示等級零與系統統計開關的結構。時間欄位的單位是秒，數值僅用於示範完整寫法，並非適用於所有網路的最佳化建議。若要保留目前核心的預設值，可省略相應欄位；若要修改，請先記錄原本行為，再逐項比較變更前後的結果，並特別測試長連線應用程式。

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

handshake 指受該策略控制的協定握手等待時間，不能一概視為所有遠端撥號、TLS 協商與網頁回應的統一逾時。connIdle 則設定連線在沒有有效資料活動時可閒置多久。即時通訊、遠端工作階段與推播可能長時間沒有業務資料；期限太短會增加重新連線，太長則可能讓失效連線占用資源更久。

uplinkOnly 與 downlinkOnly 涉及連線一端結束後，另一端仍可繼續傳輸的等待時間，並非上傳或下載限速。數值較小可能加快連線清理，也可能中斷仍有資料待傳的半關閉工作階段。下載大型檔案、串流回應或長時間維持的請求時，請特別留意這類結束處理，而非只測試短暫的網頁連線。

統計開關與介面顯示的關係

啟用統計通常需要同時設定 stats 物件與相應的統計策略。系統層級統計適用於入站等物件；使用者層級統計則要求協定使用者具有可識別的設定。開啟使用者統計開關，不代表所有匿名 SOCKS 請求都會自動產生個別使用者報表。統計名稱與讀取方式也會受到核心服務介面及用戶端實作影響。

允許設定累計統計，不代表圖形介面一定會顯示這些數值。讀取統計的程式需要適當的介面與呼叫方式；介面的監聽範圍也應限制在可信任的網路中。一般使用情境建議優先採用 v2rayN 自身的統計功能，不必為了讓介面顯示特定數字而額外公開控制介面。統計沒有記錄時，也要先確認流量是否經過對應物件。

日誌等級與資源使用

日常使用可保留 warning 等較精簡的日誌等級。排查時再暫時提高詳細程度，重現一次問題後立即恢復，避免日誌持續增加。存取日誌與錯誤日誌用途不同：前者協助確認請求的流向，後者用來判斷連線在哪個階段失敗。日誌檔案路徑必須可寫入；路徑設定錯誤可能導致沒有日誌，不能直接據此認定沒有請求。

若啟用檔案日誌，桌面用戶端以一般使用者權限執行時，不應將日誌輸出至只有管理員能寫入的系統目錄。磁碟空間不足、目錄唯讀或安全性政策限制，都可能影響觀察結果。排查用戶端一開啟就關閉的問題時，請先檢查程序啟動狀況與目錄權限，再檢查連線策略；相關步驟請見v2rayN 啟動閃退排查。

策略欄位不會變更作業系統層級的程序優先順序、全域頻寬限制或電源管理。Android 背景限制、Linux 休眠與恢復、網路介面切換都可能使既有連線失效，這些狀況無法單靠延長閒置時間解決。若裝置待機後無法恢復連線，請先比對前景與背景狀態及網路變化，再分別檢查用戶端的背景執行條件、系統代理是否恢復，以及核心日誌。

七、協定、傳輸與核心相容性

將一條連線拆解為三個層級

描述伺服器設定時，請分清代理協定、承載傳輸與安全層。VMess、VLESS、Trojan、Shadowsocks 負責代理資料與驗證；TCP、WebSocket 等描述連線的承載方式；TLS 或其他安全機制則負責相應的連線保護。三個層級的參數都必須與伺服器端一致，不能因網域與連接埠正確，就忽略傳輸類型、路徑或憑證名稱。

設定中的 settings 屬於代理協定，streamSettings 則屬於連線傳輸。將 WebSocket 路徑放進協定使用者物件，通常不會得到預期結果；將驗證欄位放進傳輸物件，也無法完成協定驗證。先確認欄位所在層級，再檢查欄位值，比反覆匯入同一條錯誤連結更有效。

如何讀取 WebSocket 與 TLS 片段

以下只是某個相容出站物件中的傳輸片段，無法獨立執行；必須與實際伺服器的協定設定合併。範例網域與路徑只用來說明欄位位置，並非可連線的伺服器。若用戶端產生的欄位名稱不同，請以目前選用核心支援的結構為準，尤其不要將不同世代傳輸的名稱當成同義詞任意替換。

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

出站伺服器位址決定初始連線的目的地；TLS 的 serverName 用於伺服器名稱指示與憑證驗證；WebSocket 的 Host 則是 HTTP 升級請求中的主機資訊。這些值有時相同，也可能因合法的反向代理部署而不同，但不能憑猜測填寫。即使已連上正確 IP，名稱不符仍可能遭前端服務拒絕。

WebSocket 路徑必須與伺服器端路由相符；開頭斜線、大小寫、結尾斜線及查詢字串都可能影響處理結果。若收到非預期的 HTTP 回應，請檢查反向代理是否將請求轉送至正確的後端。在瀏覽器中直接開啟網域首頁成功，只能證明網站入口可連線，無法證明對應的升級路徑與代理協定後端正常。

不要以關閉驗證來掩蓋憑證錯誤

請保持 allowInsecure 關閉。遇到憑證錯誤時，請分別檢查系統時間、憑證有效期限、名稱是否相符、憑證鏈是否完整，以及系統信任存放區是否正常。若企業網路使用經授權的內部憑證體系，請依組織規範管理信任設定，不要將所有連線都改成略過驗證。關閉驗證會降低辨識錯誤伺服器的能力，也會掩蓋真正的設定問題。

TLS 握手失敗也可能是安全層不一致：用戶端發起 TLS，但伺服器對應連接埠只接受一般 TCP，或反過來。有些錯誤發生在驗證之前，因此更換使用者識別碼無法解決問題。請先確認連接埠上實際提供的服務，再檢查安全層、傳輸升級，最後確認代理驗證；依序排查才能減少無效嘗試。

V2Fly、Xray 與用戶端各自的角色

Project V 提供相關模組化代理設計的背景；V2Fly 與 Xray 則屬於不同的核心系列。兩者在基礎 JSON 結構上有部分共通之處，但新協定功能、安全層欄位與部分路由行為各有差異。REALITY 是需要確認核心是否支援的功能，不能將相關設定直接加入任意 V2Ray 設定檔。具體參數應以與伺服器端相符的設定來源為準。

在桌面環境使用 v2rayN 時，請先確認目前設定實際呼叫哪個核心；在 Android 上使用 v2rayNG 時，請留意其 Xray 設定支援；使用 v2flyNG 時，則依 V2Fly 的功能檢查。用戶端名稱不代表固定的一組欄位，也不能因介面相似就認定彼此相容。選擇用戶端時可參考三款用戶端與核心比較，再決定是否移轉。

移轉設定時，請依序核對協定、驗證、安全層、傳輸、路由與 DNS，並先保留一個能正常運作的伺服器，再搬移其他規則。遇到不熟悉的欄位，不要直接刪除後繼續使用，因為它可能是連線正常所必需的條件。設定能成功載入，不代表內容符合原本意圖；最後仍須透過明確的請求與日誌驗證實際行為。

八、設定合併、驗證與分層疑難排解

讓修改套用至真正的設定來源

修改前請先匯出或備份用戶端現有資料，並另存目前可正常運作的自訂設定。一般伺服器記錄建議透過 v2rayN 介面編輯；路由預設請在路由管理區修改；完整的自訂設定則應獨立維護。不要一邊編輯用戶端產生的暫存檔，一邊在介面切換伺服器，否則很難確認最後實際執行的是哪份設定。

合併本文片段時，先建立欄位清單：每個頂層物件只保留一個同名鍵；入站連接埠不得與既有監聽衝突；出站標籤必須唯一；規則引用都能找到對應標籤；所需資料檔確實存在。範例中的私人位址與文件網域也要依用途處理；不需要的規則請直接移除，避免教學範例成為長期保留的設定。

先測試入口，再測試出口

還原第一章的完整基準設定並啟動後，可以執行以下 SOCKS 測試。測試前請確認本機 10808 正在接受 SOCKS 請求。目標是公開的文件範例網域，不需要提供私人伺服器資訊。若該網站在目前網路無法使用，可改用已知可連線的 HTTPS 位址，但整個比較測試期間請固定使用同一個目標。

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

若使用第二章的雙入站設定，也可以另外測試 HTTP 入口。只有確實啟用該連接埠時，以下命令才有意義。伺服器可能回傳成功、重新導向或其他有效的 HTTP 狀態；收到回應只代表這次請求抵達 HTTP 服務，不代表流量一定經過遠端代理。基準設定使用的是直連出口，不能將測試結果當成伺服器連線證明。

curl -I --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:10809 \
  https://example.com

明確指定代理位址比只依賴系統代理更適合排查，因為可減少環境變數、桌面設定與應用程式相容性的影響。若要驗證系統代理，請改用實際應用程式送出請求並檢查入口日誌。命令列可用但瀏覽器不可用，問題可能出在瀏覽器設定；瀏覽器可用但特定程式不可用，問題可能出在該程式的代理支援或 DNS 行為。

依錯誤階段縮小排查範圍

若核心啟動成功，卻沒有任何請求記錄，請先確認應用程式是否真的使用代理，不要立刻懷疑遠端伺服器。若有請求記錄，但出口不是預期標籤，請檢查規則順序與預設出站。若出口正確但連線失敗，再檢查伺服器網域解析、網路連線、TLS 與驗證。每次只沿著已有證據的層級繼續排查。

不要將 ping 的結果當成代理協定測試。目標可能拒絕 ICMP，卻仍接受正常的業務連線；也可能回應 ICMP，卻未開啟指定連接埠。同樣地，TCP 連線建立成功只代表有服務接受連線，不代表該服務使用預期協定。請分別記錄入口測試、連接埠可達性、協定握手與實際請求，避免以單一結果代替整條鏈路的檢查。

還原與複查

單次變更驗證成功後，請重新啟動用戶端並重做相同測試，確認設定沒有被重新產生的檔案覆寫。接著測試區域網路資源、需要代理的目標與長連線應用程式，確保修好一條路徑時沒有破壞另一條。網路切換或休眠恢復後的行為也值得另外檢查，特別是在桌面環境啟用系統代理或 TUN 時。

回報問題時，請提供核心名稱、作業系統、錯誤階段，以及已移除敏感資訊的相關設定片段。不要公開訂閱連結、完整驗證資料或含帳戶參數的日誌。若修改後無法定位問題，請先還原備份，再依本章順序重新進行最小測試；常見狀況可接著查閱常見問題，若要重新整理匯入與連線步驟，請返回使用指南，不要反覆重新安裝來取代設定排查。