V2Ray 設定檔參考

JSON 結構與設定來源

先確認要編輯的是哪一層

V2Ray 設定檔不等於用戶端視窗中顯示的所有設定。v2rayN 會儲存訂閱群組、介面選項與路由預設，再依目前使用的伺服器及核心產生執行設定。v2rayNG、v2flyNG 也各有應用程式設定。修改前，先分清訂閱原始內容、用戶端儲存的設定，以及核心實際讀取的 JSON。這三層可能描述同一個節點，卻未必存在同一個檔案中。

直接修改用戶端暫存產生的檔案，常會遇到「存檔後有效，重新啟動又還原」的情況。通常是用戶端重新產生了設定，不是核心隨機忽略欄位。優先使用用戶端提供的路由、自訂設定或節點編輯功能。若確實需要維護完整 JSON，請使用明確支援完整設定的功能，另外保留副本並記下所選核心，別把暫存檔當成唯一來源。

頂層物件與巢狀結構

常見的頂層欄位包括 log、inbounds、outbounds、routing、dns 與 policy。其中入站與出站是陣列，每個陣列物件各代表一個監聽入口或傳送出口。路由物件中的 rules 也是陣列，規則會依序處理。欄位所在層級和名稱同樣重要；把有效欄位放進錯誤的物件，也不會產生預期效果。

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

這是一份僅在本機提供 SOCKS 入口、再直接連線至目標的基本設定，不含遠端代理出口。適合用來確認監聽與本機連線流程，但請勿因請求成功就判定訂閱伺服器正常。範例使用明確指定的連接埠；若用戶端已占用相同位址與連接埠，啟動另一份設定就會衝突。請先停止原有程序，或在測試副本中一併調整監聽連接埠與應用程式的代理設定。

語法正確，不代表設定含意正確

標準 JSON 的鍵名與字串必須使用雙引號，陣列或物件最後一個項目後不能加逗號，也別將說明註解放進準備交由核心讀取的檔案。布林值寫作 true 或 false，連接埠通常使用數字。字串中的反斜線需要跳脫，尤其是手動輸入 Windows 記錄檔路徑時。使用可檢查 JSON 語法的本機編輯器，可先排除括號不成對或缺少引號等問題。

下一步要檢查引用關係。例如規則中的 outboundTag 必須對應到某個出站的 tag；規則引用的入站標籤也必須確實存在。標籤只是這份設定內部使用的名稱，不會自動建立代理功能。為避免混淆，建議採用簡短明確的英文標籤，並確保名稱唯一。修改標籤時，請一併搜尋所有引用處，別只改出站定義，漏掉路由或統計設定。

還要分清設定被接受與實際生效的差別。核心可能接受某些預設值，也可能因實作差異而拒絕特定欄位。每次儲存後，都應查看實際啟動記錄與目前使用的核心，而非只看編輯視窗沒有顯示錯誤。JSON 格式化只能確認語法，無法保證傳輸參數、伺服器憑證與遠端協定一致；這些問題需要在後續章節逐項驗證。

建議每次只針對一個目的變更設定，例如只調整路由順序，或只更換 DNS 解析器。保留原始副本，並簡單記下變更原因與預期結果。若同時修改入口、出口與解析方式，失敗時就很難判斷原因。整理設定的目的不是讓檔案越短越好，而是讓每個欄位的歸屬、引用關係與生效條件都清楚可查。

inbounds：本機應用程式如何連入核心

監聽位址、連接埠與協定

入站負責接收應用程式交給核心的流量。桌面環境最常見的是本機 SOCKS 或 HTTP 代理入口，應用程式必須指定相應的位址、連接埠與代理類型。listen 決定接受連線的本機位址，port 決定監聽連接埠，protocol 則決定入口如何解讀請求。即使連接埠號碼相同，HTTP 用戶端也不能任意將它當成 SOCKS 服務使用。

若只供本機使用，優先監聽 127.0.0.1。這是 IPv4 回送位址，其他裝置無法透過電腦的區域網路位址連上此監聽服務。0.0.0.0 表示監聽所有 IPv4 網路介面，存取範圍會明顯擴大，並不代表「自動變安全」。IPv6 監聽需要另外理解位址與防火牆規則，別以為改成所有介面就能同時正確涵蓋所有網路堆疊。

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

這兩個入口可讓不同應用程式依自身支援狀況選擇代理協定。udp: true 允許 SOCKS 入站處理相應的 UDP 請求，但應用程式仍須支援 SOCKS 的 UDP 機制，出站與遠端也必須支援完整傳輸路徑。這不會自動將所有系統 UDP 流量導入入站，也不會讓原本完全忽略系統代理的程式改變行為。入口支援的功能與接管系統流量是兩回事。

嗅探與目標位址的關係

嗅探可從部分連線的協定特徵擷取網域等資訊，常見來源包括 HTTP Host 與 TLS 交握中的伺服器名稱。即使應用程式一開始交給核心的是 IP，路由仍可能取得可供網域比對的資訊。不過並非所有流量都帶有可見網域，嗅探也不等於完整解密。開啟嗅探不能取代正確的 DNS 設定，也無法保證還原所有應用程式使用的網域。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  }
}

這段設定要放在特定入站物件中。支援此設定的實作中，routeOnly 表示嗅探結果僅供路由使用，不會直接取代連線目標；使用前應確認所選核心是否支援。遇到欄位不被接受時，別反覆猜測相似名稱。先回到不含嗅探的基本設定確認入口，再依核心的欄位定義逐項加入，分清不支援欄位與遠端連線失敗。

區域網路分享與系統流量接管

若要讓同一個網路中的其他裝置使用電腦代理，除了變更監聽位址，也要確認電腦實際的區域網路 IP、系統防火牆、網路隔離與驗證設定。請勿將代理連接埠轉送至公網，也別在不受信任的網路中開放未經驗證的入口。分享設定完成後，其他裝置要填入電腦的區域網路位址，不是各自的回送位址；裝置上的回送位址永遠指向該裝置本身。

系統代理只是通知遵循此設定的應用程式使用代理，不會改變所有應用程式的網路運作方式。TUN 則涉及虛擬網路介面、路由表、權限與 DNS 接管，通常應使用用戶端的專屬功能設定。別直接將某個核心的 TUN 欄位加入另一種 JSON 結構。若系統代理可用，但特定應用程式仍直接連線，請先確認該應用程式是否支援系統代理，再考慮是否需要 TUN。

排查入站時，先確認用戶端是否已啟動，再查看記錄是否顯示位址已被占用，最後核對應用程式選擇的代理類型。若瀏覽器透過 HTTP 入口正常，但另一個程式使用 SOCKS 失敗，應分別檢查該程式的驗證方式、網域解析方式與 UDP 需求，不要立刻重新安裝用戶端。區域網路使用情境的詳細操作，請參閱允許區域網路連線與分享代理。

outbounds：出口、協定與傳輸層

出站標籤與預設出口

出站負責將核心接收的連線送往目標。它可以直接連線至目標、將流量交給遠端代理伺服器，或依規則拒絕請求。常見的 freedom 表示直連，blackhole 表示丟棄；VMess、VLESS、Trojan 等則是與遠端協作的協定。協定名稱本身不會提供伺服器，仍須有實際可用且獲准使用的位址、連接埠與驗證資料。

若沒有其他出口選擇機制介入，未符合路由規則的流量通常會使用出站陣列中的第一個項目。因此，調整陣列順序不只是整理檔案格式，也可能改變預設連線路徑。建議明確記錄預設出站，並在路由章節設定易讀的兜底規則。定義名為 proxy 的標籤，不會自動讓流量透過代理；標籤只供引用，實際行為由該物件的協定與設定決定。

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

這組出站設定可用於本機規則測試：一般請求直連，符合封鎖規則的請求則會被丟棄。此處沒有代理伺服器，也沒有名為 proxy 的出口。參考其他教學的路由片段時，務必先確認其中引用的標籤是否已定義。直接複製指向不存在標籤的規則，可能導致設定檢查失敗，不能期待用戶端自動補上缺少的伺服器物件。

分別檢查協定設定與傳輸設定

遠端出站通常分為協定參數與傳輸參數。協定參數放在相應的 settings 結構中，例如伺服器位址、連接埠、使用者識別碼或密碼；傳輸方式與安全性交涉通常由 streamSettings 描述。兩者都必須符合伺服器端的設定。只核對位址與驗證資料，卻不檢查傳輸方式、TLS 或路徑，仍可能發生連接埠已連上、協定交握卻無法完成的情況。

伺服器位址、TLS 伺服器名稱，以及某些傳輸方式中的 Host 並非永遠相同。位址決定最初連往何處；伺服器名稱用於 TLS 身分與憑證驗證；Host 或路徑則可能參與反向代理的流量分派。別為了讓幾個欄位看起來一致，就全部改成相同值。匯入訂閱時，優先保留提供者給出的完整參數，再依記錄判斷是否有欄位遺失或不相容。

別用降低驗證要求來掩蓋問題

遇到憑證錯誤，應先校準系統時間，再核對伺服器名稱、憑證有效期限與憑證鏈。略過憑證驗證會改變連線的信任條件，不應作為一般修復方式。若直連目標正常，遠端代理交握卻失敗，表示入站與部分本機網路已可使用；接下來應集中檢查遠端協定與傳輸，不必重新調整所有本機連接埠，也不必清空整套路由表。

部分協定還仰賴額外的交握欄位或專用安全設定，而支援欄位會因核心實作而異。用戶端能顯示某個協定名稱，不代表所有核心都支援相同參數。匯入後若出現不支援協定、未知安全類型等錯誤，請先確認目前使用的核心是否符合節點需求。切換核心後，也要重新確認用戶端產生的傳輸欄位是否有所變更。

多工、連線保活與其他最佳化選項並非越多越好。它們會改變連線的組織方式，也可能影響長連線、伺服器資源與中間網路設備的運作。基本連線尚未建立前，先使用提供者建議的設定；只有在問題明確、測試可重現且伺服器支援時才調整。別把單次短請求成功，當成長時間傳輸、UDP 或所有目標都可用的證明。

排查出站問題時，建議分成位址可達性、傳輸交握、協定驗證與目標存取四個層面。某一層成功只能縮小問題範圍，不能跳過後續檢查。節點全面逾時的排查順序，請參閱系統時間、連接埠與傳輸層排查。涉及驗證資料時，分享記錄或設定前應移除使用者識別碼、密碼與完整訂閱網址，只保留協定類型與錯誤類別。

routing：比對順序與分流範圍

從單一連線了解規則比對

路由不只是簡單的網域清單，而是依據連線所帶的目標位址、入口標籤、連接埠及其他資訊來選擇出站。常見欄位規則會使用 type: "field"。規則會依序檢查，由第一條符合的規則決定出口，因此越明確的例外通常越靠前。若寬泛規則排在前面，後續較精確的規則可能永遠不會執行，這也是規則明明存在卻看似無效的常見原因。

同一條規則中的不同條件欄位通常必須同時符合；同一網域或 IP 陣列中的多個項目通常表示符合其中任一項即可。例如同時指定 inboundTag 與 domain，代表特定入口中的特定網域，而不是兩個彼此獨立的比對入口。若要表達「這個入口的所有流量走某個出口，或這些網域走某個出口」，應拆成兩條規則，分別列出條件。

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

這段設定依賴已存在的 direct 與 block 出站，也要求執行環境能讀取相應的地理資料。第一條只封鎖完全相符的網域，第二條處理私有位址，最後一條則明確讓其他 TCP 與 UDP 流量直連。此範例用於說明規則順序，不是通用的正式環境策略。若要新增真正的代理出口，請先完成出站定義，再將需要代理的規則指向該標籤。

網域規則與 IP 規則是兩回事

full:example.com 用於完全相符的網域比對；domain:example.com 通常用於該網域及其子網域。沒有前綴的字串、正規表示式與分類資料各有不同的比對方式，不能混為一談。封鎖主網域不一定會涵蓋另一個資源網域；網站載入失敗，也可能是某個資源請求符合了規則。排查時應查看實際請求的網域，而不只看網址列。

geosite: 與 geoip: 是對資料集的引用，並非核心內建的即時網際網路查詢。分類是否存在、包含哪些項目，以及資料檔能否載入，都取決於目前的資料資源。若記錄提示找不到分類或資料檔，應先修復資源與路徑，不要反覆更換標籤。分類規則比對結果改變，也可能是資料更新造成範圍變動，而非規則順序改變。

{
  "type": "field",
  "domain": ["geosite:category-ads-all"],
  "outboundTag": "block"
}

只有資料檔包含該分類時，才能使用這條規則。加入前先確認現有規則中是否已有涵蓋範圍更廣的網域或全流量比對。重複的規則不會提升效果，反而增加理解與維護成本。若只想測試順序，可先使用前面完全相符的保留示例網域，確認記錄中的目標標籤有變化，再加入依賴外部資料的分類規則。

domainStrategy：決定何時解析以供比對

AsIs 會盡量依照連線已有的位址進行比對；IPIfNonMatch 會在網域比對不到時嘗試解析，再供 IP 規則判斷；IPOnDemand 則會在規則需要 IP 時較早觸發解析。這些設定討論的是路由判斷時的解析時機，不等於應用程式 DNS、系統 DNS，或出站連線目標位址族的所有設定。採用較積極的解析策略，也可能增加查詢次數與等待時間。

如果應用程式送出的是 IP，且沒有可用的網域資訊，網域規則可能無法符合；若應用程式送出網域，而策略未觸發解析，IP 規則也不一定有判斷依據。先檢查入站收到的目標類型，再決定是否使用嗅探或調整解析策略。別把所有未符合規則的情況都歸因於格式錯誤；缺少比對依據時，網域條件寫得再精確，也不會自動取得目標名稱。

實用的整理方式是將本機服務與必要例外放在前面，需要明確選擇出口的業務規則放在中間，最後清楚設定預設行為。內網規則仍須依目標環境判斷，不能把所有特殊用途位址都視為一般公網存取。驗證時，同時測試應該符合與不應符合規則的目標，才能找出規則範圍過大的問題。其他分流問題請參閱疑難排解。

dns：解析來源、查詢路徑與連線位址

先分清三種解析方式

設定 DNS 前，先分清應用程式自行解析、核心內建 DNS 解析與系統解析。應用程式可能先取得 IP，再將 IP 交給代理；也可能將網域交給核心，由後續流程解析。瀏覽器也可能啟用獨立的安全 DNS。修改核心的 dns 物件，不會自動涵蓋所有應用程式與系統查詢。若未釐清查詢從何處發起，就很難判斷設定實際影響哪條路徑。

核心內建 DNS 常用於路由的 IP 比對，也可能由部分出站的解析策略呼叫。它並不是宣告後就會自動啟動的系統級 DNS 服務。若要讓系統或其他裝置向核心送出 DNS 請求，還需要相應的入口與轉送設定；實際功能與欄位則依核心而定。用戶端啟用 TUN 後的 DNS 接管屬於另一個層面，不能只憑這個物件就推定系統查詢已被接管。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      "1.1.1.1",
      {
        "address": "8.8.8.8",
        "port": 53,
        "domains": ["domain:example.org"]
      }
    ]
  }
}

這是內建解析器設定的局部範例。公共解析器位址僅用來示範結構，實際是否可連線取決於所在網路。domains 用來影響指定網域選用哪個解析器，不等於建立通往該網域的代理路由。也要留意回退行為：其他伺服器是否參與查詢，取決於優先比對、失敗狀態與回退設定。不能將網域選擇條件視為隔離查詢的唯一保證。

分別設定解析策略與出站策略

queryStrategy 可影響內建 DNS 請求使用的位址族，例如只查詢 IPv4，或依支援情況處理 IPv4 與 IPv6。它與路由中的 domainStrategy 是不同欄位，也不同於某些出站自己的網域策略。排查 IPv6 存取問題時，應一併確認解析結果、系統是否有可用的 IPv6 路徑，以及所選出站如何使用位址，而非只關閉其中一個選項。

若網路沒有穩定的 IPv6 路徑，卻優先嘗試無法連線的 IPv6 目標，可能會等一段時間才成功。反過來說，貿然限制 IPv4 也可能影響只有 IPv6 的資源。先查看失敗目標的解析結果與連線錯誤，再決定位址族策略。能連上一個雙協定網站，不代表所有網路情況都正常；不同目標的記錄、連線回退與應用程式快取都可能不同。

查詢路徑也必須可連線

選擇解析器時，不只要看解析器位址，也要確認查詢如何抵達。一般 UDP 查詢、加密 DNS 請求與呼叫本機系統解析器，可能走不同路徑；某些本機解析模式也可能略過一般路由處理。別只憑協定名稱就斷言查詢經過指定代理。應依核心支援的 DNS 傳送方式核對，再搭配記錄與網路環境驗證，別把預期路徑當成已發生的事實。

使用網域形式的加密 DNS 位址時，也要考慮啟動依賴：要連上解析器，必須先解析解析器網域；如果這一步又完全仰賴同一個尚未可用的解析器，就可能形成循環。同樣地，若代理伺服器位址也需要解析，而查詢又被要求透過尚未建立的代理傳送，也會陷入依賴。規劃時應為啟動階段保留明確且可連線的解析路徑。

快取可能讓 DNS 調整看起來沒有立即生效。系統、瀏覽器、應用程式與核心都可能保留解析結果，只重新啟動其中一層未必會清除其他層的快取。驗證時，關閉舊連線、視需要重新啟動相關應用程式，並選用明確知道預期結果的目標。別連續切換多個解析器後只刷新一次網頁；既有長連線可能根本沒有重新查詢，觀察結果也就無法說明新設定是否生效。

若網域連線失敗，但直接連線至目標 IP 可達，問題通常較可能出在解析或網域相關交握；不過 TLS 憑證依賴網域，直接用 IP 存取未必是等效測試。較可靠的方式是分別檢查 DNS 查詢是否有回應、回傳位址是否可達，以及協定交握是否成功。每次只變更解析來源或位址族其中一項，並保留前後記錄，避免將多項變更混為同一個原因。

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

策略依使用者等級套用

policy 用來設定連線處理策略與部分統計選項，不負責網域分流，也不決定遠端伺服器是否接受驗證。常見結構包括 levels 與 system。前者依使用者等級設定逾時與統計選項；後者則用於系統層級的入站或出站統計。等級是設定關聯值，不代表付費等級或速度等級；數字越大不表示連線越快。

部分協定的使用者物件可設定 level，對應 levels 中同數字字串的項目。若未明確指定，應依該協定與核心的預設等級判斷。定義了從未被使用者引用的等級，不會讓所有連線自動套用該設定。排查策略是否生效時，先確認連線所屬的使用者與等級，再檢查策略欄位；不要只因設定中存在該物件，就認定它已套用。

{
  "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 限制相應的交握階段，connIdle 則關注閒置連線；上行與下行的單向等待欄位，描述其中一側結束後的保留時間。它們不是總下載時間限制，也不能取代應用程式本身的重試與逾時設定。特定欄位是否適用於目前的連線，應依協定實作判斷。

逾時設定無法修復協定不相符

交握失敗的原因很多：驗證資料不符、傳輸方式不一致、憑證錯誤或目標無法連線，都可能表現為連線中斷。延長交握時間，只能讓原本有效但速度較慢的協商多等一會兒，無法讓錯誤的協定變正確。若記錄已明確指出驗證遭拒或欄位不受支援，繼續延長時間只會讓失敗更晚發生。應先解決已確認的錯誤，再討論等待時間是否合適。

回收閒置連線也必須考量應用程式的行為。即時通訊、遠端工作階段、串流回應與偶爾才傳送資料的連線，對閒置時間的需求各不相同。將閒置門檻設得太低，可能導致背景連線反覆建立；設得太高，則可能占用更多資源。調整前先確認用戶端中斷是否確實由閒置回收造成，而非網路切換、省電策略、伺服器主動關閉或中間設備逾時。

統計選項不等於統計介面

開啟統計相關的布林值，不會自動產生圖表報表。核心統計通常還需要統計模組、可識別的使用者及相應的查詢介面等配套條件；用戶端顯示的流量也可能採用自己的收集方式。核心使用者統計、用戶端程序流量與網路介面總流量並非同一項數據。轉送、協定額外負荷、統計範圍與重新啟動後的計數週期，都可能造成觀察結果不同。

為了顯示流量而手動新增 API 入站或控制介面時，尤其要謹慎。控制介面應限制在可信任的範圍內，不要為了方便從區域網路讀取就直接開放所有監聽位址。一般使用者通常可使用用戶端既有的記錄與狀態功能，不必另外架設查詢介面。本頁範例關閉統計，是為了將設定重點放在連線與規則，不代表所有環境都必須停用這些功能。

在 Android 上，連線進入背景後中斷，常與系統限制應用程式的背景活動有關，而非核心的閒置策略。請分別檢查 v2rayNG 的 VpnService 授權、背景執行權限與廠商省電設定。相關操作請參閱VpnService、省電白名單與分應用程式代理，不要用極長的逾時設定取代系統層級的正確授權。

調整策略時應有明確且可重現的條件：記錄使用的應用程式、連線閒置多久、是否切換網路，以及哪個方向仍在傳輸，再觀察調整後的差異。缺少這些前提，就很難確認變化是策略造成，還是環境剛好恢復。一般瀏覽與使用訂閱時，保留用戶端產生的合理預設值通常較容易維護；優先處理會直接影響連線是否正確的入口、出口與路由設定。

用戶端產生的設定與核心差異

介面選項相同，不代表 JSON 設定相同

v2rayN 主要用於桌面環境，用戶端中的系統代理、TUN、路由預設與核心切換，最終會對應到不同的執行方式。v2rayNG 主要使用 Xray 核心，v2flyNG 則是採用 V2Fly 核心的 Android 替代選項。三者可處理相近的節點概念，但應用程式資料目錄、匯入方式、背景執行行為與產生設定的方式都不同，不能直接用一個用戶端的整個資料夾覆蓋另一個用戶端。

V2Fly 與 Xray 共用部分設定傳統，某些 JSON 欄位也相似，但兩者的擴充功能、支援協定與欄位演進並不完全一致。sing-box 採用另一套結構，入站類型、出口定義、DNS 與路由動作都必須依照自身規格設定。協定名稱相同，不代表設定可以逐字複製。遷移時應先對照功能，再重新建立欄位，不要只替換協定名稱。

分層理解系統代理、路由與 TUN

系統代理決定支援該功能的應用程式如何將請求交給本機入口；核心路由決定已進入核心的請求要走哪個出站；TUN 則透過虛擬網路介面接收範圍更廣的系統流量。三者位於不同層級。修改路由規則，無法讓完全沒有進入核心的應用程式突然受到控管；啟用 TUN 也不能保證每條核心規則都正確，更無法修復錯誤的遠端驗證資料。

用戶端中的「全域」通常表示某個層級的預設出口或流量接管範圍，實際含意須依目前模式判斷。它可能會改變核心路由，也可能只是系統代理模式的名稱。應查看產生的設定、實際入口與記錄來判斷，別只依賴按鈕文字。若區域網路服務失去連線，既要檢查核心是否將私有位址送往錯誤出口，也要檢查 TUN 的系統路由是否改變了本機網路的接管方式。

TUN 需要適當權限，也可能與其他虛擬網路軟體衝突。若啟用後所有網路都中斷，先關閉 TUN 恢復基本網路，再檢查權限、虛擬介面、DNS 與路由衝突；不要同時修改遠端伺服器參數。系統代理模式能夠連線，表示部分核心連線流程已經成立。此時保留原節點設定、集中檢查流量接管層，通常比重新匯入所有訂閱更有效。

訂閱、自訂規則與更新覆寫

訂閱通常負責提供節點資訊，不一定包含本機路由、系統代理與 DNS 設定；部分匯入格式也可能包含較完整的設定，因此匯入前要先確認內容類型。更新訂閱後節點參數有所變動，屬於正常同步行為，但手動修改的本機節點可能被覆寫。需要長期保留的例外，應放在用戶端明確支援的本機規則或獨立設定中，避免每次更新訂閱後都得重複手動修改同一欄位。

也要確認完整自訂設定的處理方式：用戶端可能直接執行該設定，也可能補上監聽連接埠、記錄、控制介面或統計設定。別預設檔案內容就是最後實際執行的設定。若要分析故障，應一併記錄匯入來源、用戶端選項與最後的啟動記錄。匯出設定不代表可以公開分享，內容可能包含伺服器位址、驗證欄位與訂閱網址，散布前應逐項移除敏感資訊。

在 macOS、Windows 與 Linux 上，即使 JSON 相同，檔案路徑、目錄權限、防火牆與系統代理入口仍不相同。記錄檔應放在用戶端有寫入權限的位置，別直接貼上其他作業系統的絕對路徑。初次安裝所需的目錄與執行環境說明，請閱讀v2rayN 首次安裝與初始設定；啟動失敗時，則先分清是程序當掉還是設定遭拒。

需要安裝或更換用戶端時，請前往安裝檔下載頁面，依作業系統與處理器架構選擇，桌面環境優先使用 v2rayN。不要為了測試單一欄位而頻繁更換用戶端與核心，否則設定差異與環境差異會交互影響。將遷移拆成可復原的小步驟並保留最後一份可用設定，才能清楚判斷是哪項功能或哪一層設定發生變化。

完整設定範例與逐層驗證

本機直連與精確封鎖的基準設定

以下是用於本機驗證的完整 JSON：在回送位址上監聽 SOCKS 與 HTTP 連接埠，一般流量直連，完全符合的示例網域則送往封鎖出口。不需要遠端代理驗證資料，也不依賴分類資料檔，適合用來理解路由運作方式。若用戶端正在使用相同連接埠，請先停止其核心，或在獨立測試副本中改用未占用的連接埠，並同步修改應用程式端的設定。

{
  "log": {
    "loglevel": "warning"
  },
  "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": {}
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

驗證時應選用用戶端支援的完整設定入口，確認目前執行的是目標核心，並查看設定載入結果。若啟動後立即失敗，先處理語法錯誤、未知欄位與連接埠占用；若啟動成功，但應用程式沒有請求記錄，優先檢查應用程式是否確實連上本機入口。此時先別調整 DNS 或遠端傳輸，因為請求可能還沒到需要這些設定的階段。

依序進行正向與反向測試

第一步，使用明確支援 HTTP 代理的應用程式，將位址設為 127.0.0.1、連接埠設為 10809，並連線至目前網路原本就能直連的目標。第二步，連線至完全符合封鎖條件的示例網域，觀察失敗情況是否符合規則。最後暫時移除封鎖規則並重新載入，比較結果。務必讓請求以網域形式進入代理；若應用程式事先解析成 IP，網域規則可能沒有比對依據。

反向測試同樣重要：封鎖範圍以外的目標應維持正常連線。只觀察一個目標連線失敗，無法證明規則正確，也可能是整個入口都無法使用。測試時請關閉應用程式既有連線，並留意瀏覽器快取、安全 DNS 與獨立代理擴充功能可能改變連線路徑。若無法確認應用程式的行為，可先用單一應用程式完成整組對照測試，減少環境變因，再擴大至其他程式。

依連線階段閱讀記錄

記錄的首要用途是找出失敗階段，不是收集越多越好。日常使用可維持較低的記錄量，重現問題時再暫時提高詳細程度。確認入口標籤、目標位址、符合規則的出口與最終錯誤是否屬於同一筆請求。多個應用程式同時連線時，前後相鄰的兩行記錄未必描述同一條連線。若記錄中出現大量重複連線，先縮小測試範圍，避免將背景程式活動誤認為目前目標的結果。

記錄可能包含瀏覽網域、區域網路位址與伺服器資訊。排錯結束後，請恢復日常記錄層級，並清除不再需要的詳細記錄。需要向他人說明問題時，保留錯誤類別與發生階段，移除驗證資料、完整訂閱網址與個人瀏覽紀錄。別直接公開整個用戶端資料目錄，其中除了執行設定，也可能存有舊節點、群組資訊及其他帳戶相關資料。

從基準設定逐步還原實際設定

本機基準設定通過後，先還原一個已知可用的遠端出站，暫不加入複雜路由。確認遠端連線後，再新增一條明確的分流規則，接著加入分類資料與 DNS，最後才考慮調整策略。每一步都要測試應符合與不應符合規則的請求。發生問題時，回復上一份可用副本，比在已疊加多層變更的檔案中不斷嘗試更容易找出原因。

更新訂閱、切換核心與升級用戶端後，也可沿用相同的驗證順序。別把「視窗能開啟」當成設定全部生效，也不要把「一個網頁能連線」當成所有協定都正常。只有入口、出口、規則與解析都各自得到預期結果，才能確認這份設定適合目前用途。日常操作請回到快速入門教學；特定問題則可繼續查閱疑難排解。