V2Ray 設定檔參考

JSON 結構總覽與設定邊界

先分清用戶端設定與核心執行檔

V2Ray 生態系的設定通常分成兩個層次。第一層是圖形用戶端儲存的訂閱、群組、介面偏好和代理模式；第二層則是啟動核心時產生的執行設定。兩者可能都使用 JSON，但欄位意義並不相同。訂閱更新間隔屬於用戶端的管理邏輯，不能直接加進核心根物件。查閱檔案前，先確認它是用戶端資料庫、訂閱內容，還是實際交由核心讀取的設定。副檔名相同，不代表兩者可以互換。

執行設定可依資料流向理解：inbounds 接收應用程式連線，routing 決定連線交由哪個出站處理，outbounds 執行直連、代理或封鎖，dns 提供內建解析設定，policy 調整連線策略。log 用於檢視啟動及執行狀況。這些模組彼此參照，但不需要一開始就啟用所有功能。新增功能越多，需要一併驗證的條件也越多；排錯時應先保留最精簡的連線流程，再逐項恢復。

最小設定：本機 SOCKS 入站與直連出站

以下是完整的基礎設定，不依賴遠端代理服務。應用程式明確使用本機 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": {}
    }
  ]
}

JSON 語法正確，只是第一步檢查

JSON 物件以大括號包住，陣列以方括號包住，欄位名稱和字串都使用英文雙引號。數字型連接埠不應寫成加上引號的文字；布林值則使用 true 或 false。正式設定檔不可加入註解、尾隨逗號或單引號。文章中的片段通常只包含一個模組，必須放回正確層級；即使把整個根物件塞進入站的 settings 後語法仍然正確，也不符合核心的結構要求。

語法檢查通過後，還要確認目前的核心是否支援相關欄位、參照的標籤是否存在，以及外部檔案路徑能否存取。Xray 與 V2Fly 共用部分設定概念，但新增的協定、傳輸欄位和測試參數並不完全相同。不要只看用戶端名稱判斷相容性，應確認目前實際啟動的核心名稱並查看日誌。介面能匯入分享連結，不代表所選核心能執行其中所有傳輸參數；匯入成功和連線成功是不同階段。

修改前先保留一份可正常啟動的設定，並記下變更是在用戶端介面還是自訂檔案中進行。若執行檔由用戶端自動產生，直接編輯後可能在切換節點或重新啟動時遭到覆寫。正確做法是先在介面完成一般設定，再透過用戶端明確提供的自訂設定入口加入擴充內容。若不確定入口在哪裡，先匯出或檢視目前產生的設定，不要反覆修改暫存檔來取代持久設定。後續章節都會沿用這種分層方式，避免把設定遭覆寫誤判為欄位無效。

inbounds 入站：監聽位址、連接埠與協定

入站說明應用程式如何連入核心

inbounds 是陣列，每個物件代表一個接收連線的入口。tag 是供路由參照的名稱，listen 決定綁定的本機位址，port 決定監聽的連接埠，protocol 則決定入口協定。應用程式設定為 HTTP 代理時，必須連到 HTTP 入站；設定為 SOCKS 代理時，則必須連到 SOCKS 入站。兩種入口不能只靠連接埠號碼互換。即使連接埠能建立連線，也不代表應用程式和入站使用相同的代理交握方式。

僅供本機使用時，監聽位址建議使用 127.0.0.1。這會將入口限制在 IPv4 迴路介面，不會因電腦連上其他網路就自動對區域網路開放。0.0.0.0 表示綁定所有可用的 IPv4 介面，適合經過審慎評估的區域網路分享情境，但仍須透過防火牆限制來源。監聽位址不是遠端伺服器位址，也不是其他裝置應填入的目標位址；其他裝置應填入執行用戶端的電腦在同一個區域網路中的實際位址。

雙入口範例與欄位說明

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

範例為兩種協定指定不同的連接埠，方便在應用程式設定中辨識。SOCKS 的 udp 開關允許入口處理相應的 UDP 要求，但無法單獨保證整條連線都能傳送 UDP。應用程式必須支援相關功能，出站協定和遠端也必須支援，途中網路還可能限制封包傳輸。若網頁瀏覽正常，但某個即時應用程式異常，請分別確認應用程式是否連上入站、是否送出 UDP，以及出站連線是否具備相應能力，而不是只反覆切換入口開關。

嗅探、系統代理與 TUN 是不同功能

入站可依核心支援情況設定 sniffing，從部分協定交握中辨識目標網域等資訊。這有助於依網域進行路由判斷，但不是通用的內容解析工具。加密交握特徵、應用程式實作和核心設定都會影響可取得的資訊。嗅探也可能影響原始目標與辨識出的網域之間的關係，因此不應把它當成所有分流問題的預設解法。請先確認應用程式傳入的是網域還是 IP，再決定是否啟用，並確認所用核心如何解讀相關選項。

系統代理是作業系統提供給遵循該設定的應用程式使用的代理入口；它本身不等於建立入站。TUN 則涉及虛擬網路介面、路由接管和 DNS 配合，不能只在上述 JSON 加入同名的布林欄位就完成設定。實際支援能力取決於用戶端、所選核心和配套實作。檢查時先確認本機連接埠正在監聽，再確認系統代理指向該連接埠，最後確認目標應用程式是否遵循系統設定。把這三個步驟分開，就能避免將應用程式直連誤判為核心路由錯誤。

區域網路分享還須考量裝置位址變動、訪客網路隔離和電腦休眠。手機和電腦名稱相似，或連上同一個無線基地台，都不能證明兩者能互相存取。請先確認同網段是否連通，再開放必要連接埠；測試結束後，關閉不再需要的入口。完整操作請參閱v2rayN 允許區域網路連線設定。不要為了排錯而長期關閉整台裝置的防火牆；優先設定限制連接埠及來源網路的規則，並記下用途。

outbounds 出站：目標連線與標籤參照

出站負責建立連線，不負責管理訂閱

outbounds 同樣是陣列，每個物件描述一種離開核心的方式。常見的 freedom 表示直接連線至目標，blackhole 表示封鎖；代理協定則需要與遠端相符的連線參數。tag 是路由選擇出站時使用的名稱，不是協定本身。將標籤命名為 proxy，不會自動取得遠端代理能力；實際行為由 protocol、settings 及適用的傳輸設定共同決定。

若沒有規則符合，通常會使用出站陣列中的第一個出站，因此陣列順序確實會影響行為。若預設要走代理，請確認第一項是預期的代理出站；若預設要直連，第一項則可設為直連。不要假設所有未符合規則的連線都會自動尋找名為 proxy 的物件。圖形用戶端可能依目前模式重新排序或產生出站；檢查時應以執行設定為準，不要根據訂閱清單的顯示順序推斷實際預設行為。

使用本機上游示範代理、直連與封鎖

以下片段使用另一個本機 SOCKS 服務作為上游，避免將教學設定與真實遠端認證資料混在一起。只有當本機 127.0.0.1:10810 確實有可用的 SOCKS 服務時，第一個出站才能建立連線。不可將它指回自己的入站連接埠，否則可能形成迴圈。若只要測試第一章的直連流程，就不需要這個片段；加入上游之前，請先確認上游本身能獨立處理要求。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10810
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

分層檢查協定參數與傳輸參數

VMess、VLESS、Trojan 和 Shadowsocks 的認證結構各不相同，不能直接把一種協定的設定物件複製到另一種協定底下。伺服器位址和連接埠相同，只能表示目標入口相同，不能證明認證參數正確。若節點來自訂閱，請先保留匯入的完整參數，確認用戶端是否正確辨識協定，再檢查傳輸類型、安全層和伺服器名稱。排錯時一次只調整一個已確認有誤的欄位，避免同時變更協定、傳輸和路由，導致無法比較結果。

streamSettings 用於設定適用的傳輸和安全選項，但內部結構會隨協定與核心功能而異。WebSocket 路徑、TLS 伺服器名稱和 REALITY 相關參數不能互相替代。傳輸方式應與伺服器一致，安全層也應符合伺服器設定。不要藉由關閉憑證驗證來掩蓋名稱或時間錯誤；應先檢查系統時間、伺服器名稱和伺服器憑證條件。若連線在交握階段失敗，修改路由清單通常無法修正遠端參數不相符的問題。

同一個遠端節點能否在不同核心中使用，必須同時檢查協定和傳輸特性。不要只依協定名稱選擇，例如能辨識 VLESS，不代表支援連結中附帶的所有安全參數。兩個核心分支的差異，請參閱Xray 核心與 V2Fly 核心的差異。確認相容性後再切換核心，並重新檢查實際產生的檔案，避免用戶端沿用舊設定，或遺失無法表示的參數。

管理出站時也應保留明確的回復方式。新增代理出站時，先保留可驗證的直連和封鎖標籤，再用範圍很小的規則指定測試目標。確認成功後才擴大規則範圍。刪除出站前，先搜尋路由和其他模組是否仍有參照；留下懸空標籤可能導致設定錯誤，或讓連線無法依預期處理。連線重用、鏈式轉送等擴充功能，適合在基礎連線穩定後另行評估，不應列入最小範例的預設設定。

routing 路由：比對順序與預設出口

依規則順序比對，不要從文字描述推斷優先順序

路由負責決定連線交由哪個出站處理，不負責判斷遠端節點能否連線。rules 陣列通常由前往後檢查，符合適用規則後便選擇其指定的出站。特定規則應排在範圍較廣的規則前面，例如先處理區域網路目標，再處理特定網域，最後才考慮涵蓋範圍更廣的規則。若第一條規則已符合所有 TCP 和 UDP 連線，後面的細分規則就沒有發揮作用的機會。規則多不代表分流更精確，關鍵在於條件之間是否互相涵蓋。

同一條規則中的不同類型條件通常必須同時符合；同一條件陣列中的多個值則通常代表符合其中任一項即可。例如同時設定 domain 和 port，表示目標網域和目標連接埠都必須符合條件，而非任一項符合即可。若需求是「網域符合或 IP 符合」，通常拆成兩條規則會更清楚。閱讀匯入的規則時，先把條件改寫成完整句子，就能較快找出是否把交集誤寫成聯集。

區域網路直連與指定網域封鎖

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

這段設定需要已有 direct 和 block 出站，也需要核心能載入對應的地區 IP 資料。範例網域僅供教學使用，不代表實際服務。未符合規則的連線會使用預設出站；若依上一章將代理排在首位，其餘流量便會交由代理處理。請注意，AsIs 不會為了符合 IP 規則而主動解析網域目標，因此透過網域存取內部服務時，不能只靠私有 IP 規則就推斷一定會直連。內部網域應另設網域規則，或審慎評估解析策略。

網域規則、IP 規則與資料檔案

full: 用於完全符合網域，domain: 用於符合指定網域及其子網域；一般文字和正規表示式則各有不同的比對方式。若要限定單一主機，使用完全符合會更容易檢查；若要涵蓋整個網域，再使用網域比對。只有在確認簡單規則無法滿足需求後才使用正規表示式，並留意 JSON 字串中的反斜線跳脫。直接將正規表示式測試工具中的文字貼進 JSON，可能因跳脫層數不同而改變最終意義。

geosite: 和 geoip: 參照的是資料分類，不是即時查詢服務。分類是否存在、包含哪些項目，以及更新後是否有所變動，取決於實際載入的資料檔案。即使規則名稱拼寫正確，也可能因檔案缺失、路徑錯誤或分類不存在而無法啟動。使用用戶端提供的資料更新功能後，應重新啟動相關核心並查看日誌。不要一次替換多個來源的資料檔案，再只憑網頁結果判斷是否成功；請先確認核心載入的是預期檔案和路徑。

上述策略決定路由階段何時需要解析，與 DNS 模組的位址族選擇不同，也不等同於直連出站最終如何建立連線。網域可能先用於規則判斷，之後仍由出站或遠端處理連線解析。排錯時應分清「用來選擇路由的位址」和「用來建立實際連線的位址」。如果兩處的解析來源不同，日誌中的 IP 和最終存取路徑未必完全一致；不要只看到一筆解析結果，就推斷整條連線流程已經固定。

驗證新規則時，選定一個明確目標，記錄輸入形式是網域還是 IP，並暫時縮小規則範圍。觀察存取日誌是否經過預期的入站和出站，再恢復完整規則。應用程式快取或既有長連線可能繞過新的連線判斷，因此測試前應結束舊連線並重新送出要求。若用戶端啟用了路由範本自動更新，也要確認更新後是否保留自訂規則。常見規則疑問可搭配查閱常見問題，不必在多個範本間反覆切換。

dns 設定：解析來源、位址族與連線路徑

先確認由哪一層解析網域

DNS 問題的第一步不是選擇要填哪台伺服器，而是確認解析發生在哪一層。應用程式可以先透過系統解析取得 IP，再將 IP 交給代理；也可以把網域交給 SOCKS 或 HTTP 入口；核心也可能依路由策略主動解析，遠端代理則可能負責最後解析。只有在要求確實使用核心 DNS 時，修改 dns 模組才會影響相應階段。系統 DNS、瀏覽器自己的解析設定和核心 DNS 並非同一個開關，不能用一次設定變更解釋所有應用程式的行為。

檢查時記錄目標輸入、應用程式的代理方式和路由策略。例如應用程式已傳入 IP，核心通常無法只靠 DNS 設定還原原始網域；嗅探可能提供部分線索，但不保證辨識所有連線。相反地，應用程式傳入網域時，AsIs 也可能讓路由階段不觸發解析。先還原要求經過的路徑，再決定要修改系統解析、應用程式設定還是核心模組，才能避免把解析快取、規則比對和遠端連線失敗全都歸類為同一種 DNS 故障。

靜態對應與解析伺服器範例

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

這裡的靜態對應使用文件範例位址，不是可連線的服務，僅用來說明網域覆寫結構。兩個伺服器位址只示範設定格式，不代表適用於任何網路。多台 DNS 伺服器的選擇、並行和備援行為，會受設定格式及核心實作影響，不應把陣列直接理解成瀏覽器書籤般依序嘗試。正式使用前，須確認伺服器在目前網路中可連線，並檢查要求是否經過預期路徑。靜態對應會改變相關網域的解析結果，測試結束後應刪除不再需要的項目。

位址族策略與 IPv6 條件

queryStrategy 用於限制內建解析查詢或使用的位址族。UseIP 表示同時考量 IPv4 和 IPv6，UseIPv4 或 UseIPv6 則用於明確限制位址族。位址族設定應依實際網路能力決定，而非看裝置介面是否顯示 IPv6 位址。裝置有本機 IPv6 位址，不代表通往目標網路的 IPv6 路由完整；反過來說，也不應只為了解決一次逾時，就永久關閉整個系統的 IPv6，以免影響其他正常運作的應用程式。

某些網域能解析但無法連線時，應比較回傳的位址族和出站連線能力。若只有取得 IPv6 結果時失敗，可先在限定範圍內測試 IPv4 解析，再檢查本機路由、遠端出口和伺服器監聽狀況。若解析本身逾時，則先確認 DNS 伺服器的連線路徑。不要把「解析出位址」和「該位址上的服務可用」當成同一回事；DNS 成功只能證明取得了回覆，後續連接埠連線和安全交握仍須分別驗證。

使用依網域分流的 DNS 時，伺服器物件可能包含比對網域、預期 IP 範圍和備援選項。這些項目的組合邏輯比單純的伺服器陣列複雜，而且不同核心的擴充欄位也有差異。建議先建立單一伺服器可正常運作的基準，再加入網域範圍和備援條件。若一開始就同時加入多種分類、位址限制和備援開關，遇到沒有回覆時，很難判斷是上游無法連線、回覆遭到篩除，還是比對條件未涵蓋目前目標。

加密 DNS 同樣需要能建立連線的網路路徑。若解析某個上游主機需要先使用該上游，可能會產生啟動依賴；若代理節點位址也依賴同一條尚未建立的代理連線，問題就會更加複雜。設定前先畫出「解析節點位址、連線至節點、連線至解析上游、解析服務網域」的順序，確保沒有互相等待的環節。不要把加密傳輸名稱當成連線可用的保證，實際上仍受位址解析、路由和連線權限限制。

驗證 DNS 變更時，也要處理快取。系統、瀏覽器、應用程式和核心可能各自保存解析結果，既有連線也可能繼續使用舊位址。優先建立新連線並使用明確的測試網域觀察日誌；必要時依平台的正常方式清除快取或重新啟動應用程式。不清楚快取層級時，不要連續更動多台伺服器；如此一來，較早的設定可能剛好在稍後測試時生效，導致錯誤結論。保留測試時間和當時設定，比單純比較網頁能否開啟更有參考價值。

policy 策略：連線生命週期與統計條件

策略不是線路選擇器

policy 用於調整連線處理和統計行為，不負責將特定網域分配給代理節點。常見結構包含依使用者層級組織的 levels，以及全域系統統計設定 system。層級索引以 JSON 字串表示，例如 "0"；相關使用者採用哪個層級，則取決於其協定設定和核心的解讀方式。若沒有明確需求，不必為了讓設定看起來完整而增加多個層級。先維持預設行為，再針對日誌中可重現的連線問題調整少數參數。

理解策略前，先分清交握階段、正常傳輸階段和單向結束階段。交握逾時針對初始協商，閒置逾時針對一段時間沒有活動的連線；單向結束後的等待，則關係到另一方向的資料是否仍須繼續傳送。將所有數值設得太小，可能導致正常的長連線被關閉；全部調大，也可能延長異常連線占用資源的時間。策略值不是越大越穩定，應依應用程式的連線方式和實際故障現象調整。

層級策略與系統統計片段

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

片段中的時間以秒為單位，用來示範欄位結構，不代表適用於所有應用程式的最佳化建議。handshake 限制適用連線的交握等待時間，connIdle 限制閒置連線，uplinkOnly 和 downlinkOnly 則涉及其中一個方向結束後的等待時間。實際生效範圍須依協定與核心實作確認。若調整後出現上傳結束便中斷下載、背景連線定期重建等情況，請先還原原值，再根據連線日誌縮小問題範圍，不要繼續疊加更多策略。

分開理解統計開關與數據顯示

啟用統計開關，不代表用戶端會立即顯示所有數值。統計模組、查詢介面和用戶端的讀取邏輯必須相互配合；使用者層級統計也與協定支援的使用者識別等條件有關。範例明確關閉使用者上下行統計，只示範系統入站和出站的統計開關。若用戶端已自動產生統計和介面設定，不要再盲目加入另一組同名模組；重複設定可能產生衝突，也可能讓介面繼續讀取舊介面，造成核心已執行但顯示區域沒有變化。

閒置連線與慢速連線也不是同一個概念。連線仍持續傳送少量資料時，是否會被判定為閒置，取決於核心如何判斷活動狀態；應用程式如何傳送心跳，也會影響連線維持情況。排查週期性中斷時，應比較應用程式日誌中的重新連線時間、核心關閉連線的原因與系統休眠記錄。電腦進入睡眠、無線網路切換或行動裝置的背景執行限制，都可能造成類似現象。僅看到連線在某個時間點中斷，不能直接判定是 connIdle 設定不當。

若要查詢統計資料，優先使用用戶端現有的狀態介面和受限制的本機介面。不要為了查看數值，就將管理介面暴露在所有網路介面上；介面是否存在、監聽位置及可存取對象，都是獨立的安全界線。一般桌面使用者不必為了閱讀本章而自行架設遠端管理入口。核心重新啟動後，統計數值也可能重新計算；不要直接用用戶端的歷史彙總減去本次程序計數，進而推斷設定遺失或連線繞過代理。

調整策略的合理流程是先描述現象，再選擇欄位，最後驗證副作用。例如，確認某個應用程式在閒置後被核心主動結束連線，才評估相關的閒置等待時間；若在認證階段就失敗，則應回頭檢查出站參數。每次都記錄原值、修改值和測試條件，並維持其他設定不變。需要復原時，直接還原整段已驗證的設定，比憑記憶逐項改回更可靠。策略屬於後續微調，不應排在入站可連線、出站可用和路由正確這三項基礎條件之前。

用戶端整合：產生檔案、訂閱與核心切換

透過用戶端的持久設定進行修改

v2rayN 是桌面版的主要選擇，支援 Windows、macOS 和 Linux；Android 則可依設定需求選擇 v2rayNG 或 v2flyNG。安裝入口統一在用戶端下載頁。這些用戶端會將節點、模式和路由選項整理成可執行的設定，因此介面上的結構不必與 JSON 一一對應。查閱本手冊時，請先找出目前用戶端提供的設定預覽、日誌或自訂設定功能，再判斷修改應留在介面中，還是交由獨立檔案管理。

匯入訂閱後，用戶端通常會儲存來源資訊和節點清單，再依目前選擇產生執行設定。節點群組、篩選關鍵字和自動更新屬於用戶端層，不是通用的 routing 或 policy 欄位。在核心檔案中加入群組名稱，不會讓訂閱清單自動分類；直接修改訂閱產生的節點參數，也可能在下次更新時遭到取代。長期調整時應明確區分來源資料與本機覆寫，確保更新訂閱不會在不知情的情況下改變正在驗證的設定。

檢查產生的設定時，核對四項對應關係

第一，介面中的目前節點是否對應實際出站。第二，系統代理或應用程式設定是否指向實際入站連接埠。第三，目前的路由模式是否產生預期規則和預設出站。第四，介面選取的核心是否與啟動日誌一致。完成這四項檢查後，再深入檢視協定參數。這些步驟有助於釐清許多「設定看起來正確，實際行為卻不同」的情況，例如節點已切換但舊連線仍使用原本的出口，或另一個背景執行個體仍占用系統代理指向的連接埠。

{
  "inbounds": [
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-http"],
        "outboundTag": "direct"
      }
    ]
  }
}

這個獨立範例明確將 HTTP 入站對應至直連出站，用來說明介面連接埠與標籤之間的關係，並非要求取代現有訂閱。若用戶端的自訂設定模式會接管整份執行檔，請先確認該模式是否仍會自動設定系統代理、更新連接埠或產生統計介面。不同功能入口的用途各異；用於附加路由的輸入框，不應貼入包含所有入站和出站的完整檔案。儲存前先閱讀入口說明，儲存後查看實際產生的結果，不要只確認介面是否顯示成功。

分別驗證核心切換與流量接管模式

不能只根據共同欄位名稱推斷 Xray 與 V2Fly 的設定相容性。切換核心前，先確認協定及傳輸所需功能，並保留舊設定。切換後重新啟動，查看日誌中的核心識別資訊，再確認產生的設定是否有所變動。若使用自訂檔案，用戶端不一定會自動將專屬欄位轉換成另一個分支支援的結構。遇到未知欄位或未知協定時，先切回原核心並確認基礎連線恢復，再逐項建立相容設定，不要直接刪除所有報錯欄位。

系統代理和 TUN 也應分別建立測試基準。先在不接管全部流量的情況下驗證本機代理連接埠，再啟用系統代理測試遵循該設定的應用程式，最後才評估 TUN。TUN 可能需要額外權限、虛擬介面、路由和 DNS 設定；其功能取決於目前的用戶端及配套核心。若啟用後無法正常存取區域網路，請檢查接管範圍和私有網路規則；若只有特定應用程式沒有使用系統代理，就不應先懷疑訂閱損毀。

若同時使用多個訂閱來源，建議先整理來源和群組，再處理複雜的自訂設定。這樣在節點更新後能快速辨認參數來源，也方便還原至已知可用的版本。整理方式請參閱v2rayN 訂閱群組與節點篩選。桌面權限問題則應回到平台安裝流程處理，例如macOS 安裝與網路權限說明。尚未取得權限時，反覆修改 JSON 通常無法改變系統拒絕接管網路的結果。

需要搬移設定時，應分別記錄訂閱來源、自訂規則和目前平台相關選項。不同平台的設定目錄、檔案權限與網路權限各不相同，不能直接複製絕對路徑後就假定可用。完成搬移後，先驗證單一節點，再恢復路由和 DNS 擴充設定，最後檢查流量接管模式。首次操作仍請依照快速入門流程；本頁提供欄位說明，不取代用戶端目前介面的操作指引。

驗證與排錯：從讀取檔案到連線目標

依失敗階段縮小排查範圍

排查設定問題時，應依序檢查啟動、監聽、接入、選路、解析和遠端連線。核心尚未啟動時，網頁測試無法說明路由是否正確；應用程式尚未連上入站時，修改出站也沒有驗證意義。先開啟用戶端日誌，重新啟動一次核心，找出這次啟動最早出現的錯誤，不要從大量後續重試中隨意挑一行。早期錯誤可能引發多個連鎖提示；先修正第一個明確的失敗點，通常比同時處理所有警告更有效。

檢查檔案讀取階段時，重點在 JSON 結構、欄位類型與路徑。錯誤訊息指出某個欄位附近，也可能是前面出了問題，例如上一行少了逗號、字串沒有結尾，或陣列結束位置錯誤。不要只刪除報錯行；先釐清最外層物件和模組層級，再比對最近修改的部分。若要使用編輯器輔助檢查，請在本機處理含有節點資訊的檔案；不要將完整設定上傳到資料處理方式不明的網站，分享日誌前也要移除位址和認證資訊。

先測試，再長期執行

自行管理核心檔案時，可先執行目前核心支援的設定測試命令。以下範例採用 Xray 的命令格式，要求系統能找到對應的可執行檔，且工作目錄中存在目標檔案。V2Fly 的命令參數可能不同，請先查看本機程式的說明，不要將一個核心的參數直接套用到另一個核心。圖形用戶端使用者應優先查看用戶端日誌和其提供的檢查入口；若不需要獨立管理核心，就不必為了執行命令而額外安裝另一套執行環境。

xray run -test -config config.json

測試通過只表示目前的程式接受這份檔案，不代表遠端可連線，也不代表應用程式已使用代理。下一步請檢查連接埠是否成功監聽。若出現位址已被占用，應確認是否有重複啟動的用戶端、舊核心程序或其他本機服務。不要為了避開衝突只修改 JSON 中的連接埠，卻忘記同步更新系統代理和應用程式設定；這會讓核心正常啟動，但應用程式仍連到舊連接埠。連接埠變更後，請重新發出要求並核對入站日誌。

透過可觀察的日誌驗證連線流程

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

暫時將日誌層級調整為 info，可以取得更多執行資訊；但實際可看到的內容，取決於用戶端如何擷取核心輸出，以及是否另外設定存取日誌。若要確認選路結果，請查看用戶端提供的連線紀錄或存取日誌，分辨入站標籤、目標形式和出站標籤。問題解決後，將日誌層級恢復為適合日常使用的設定。詳細日誌可能包含存取目標、裝置位址和連線時間，不應無故長期保存，也不應未經處理就貼到公開討論區。

入站和路由都正確後，再檢查解析與遠端交握。連線逾時可能發生於連線至遠端連接埠，也可能發生於連線至服務目標；認證失敗、伺服器名稱不符和解析失敗都需要不同的處理方式。請對照日誌中的實際目標與發生階段，不要只憑「逾時」兩個字就判定節點失效。若同一份設定在不同網路上的表現不同，請記錄網路切換、位址族和權限條件，保持設定不變進行比較，避免在同一次測試中混淆網路差異和設定修改。

逐項恢復設定是驗證修正結果的最後一步。先用已知可用的最小設定完成一條連線，再加入目標出站，接著加入一條路由，最後恢復 DNS 和策略擴充。每增加一層就保存測試結果；出現異常時，便能定位最近的變更。測試規則應涵蓋預期符合和預期不符合的兩種目標，避免某條範圍過廣的規則只讓單一網頁正常，卻將其他流量全部導向錯誤出口。結束既有連線後再重試，才能確保新設定確實參與判斷。

若需要更詳細的日誌判讀方式，請參閱從日誌找出 config.json 錯誤；重複出現的基礎疑問可查閱常見問題，術語說明則請參考術語手冊。最後應保留一份已驗證的設定基準，並明確標示哪些部分由訂閱更新、哪些部分由用戶端產生、哪些部分由本機維護。後續升級或搬移時，先與基準比對，再判斷是否需要調整欄位，避免重新從整份檔案猜測問題原因。