V2Ray JSON 設定檔手冊

設定檔結構與請求路徑

V2Ray 設定檔以一個 JSON 物件為根。閱讀時先找出 inbounds、outbounds 和 routing：入站接收應用程式的請求，路由判斷請求應交由哪個出站處理，出站則負責後續連線。dns 提供核心可呼叫的網域名稱解析功能，policy 管理部分連線時限與統計開關。欄位之間有引用關係，但並非依照檔案順序逐段執行；頂層鍵值放在前面或後面，通常不會改變處理邏輯。

先分清三種容易混淆的資料。訂閱內容描述遠端連線資訊，用戶端設定儲存介面選項，核心執行設定則是用戶端整合這些資料後交給核心的結果。訂閱文字未必是完整 JSON，用戶端自己的設定檔也未必能直接由核心載入。看到包含伺服器清單、視窗狀態或訂閱更新時間的檔案，不能只憑副檔名就認定它是執行設定。應透過用戶端記錄、設定檔檢視入口或自訂設定說明確認檔案用途。

完整架構：本機代理入口與直接連線出口

以下是一份基本的 V2Ray 風格設定。它在迴路位址提供 SOCKS 與 HTTP 入口，所有一般請求最後都直接連線，不包含遠端代理伺服器。這份範例用來觀察入站、出站與路由如何銜接，不能取代訂閱產生的代理設定。範例連接埠為本文指定，使用前請確認未被其他程式占用；若目前用戶端產生的是混合入站，實際連接埠配置可能不同。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "http-in",
      "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",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

此處的 direct 與 block 都是自訂標籤，不是保留關鍵字。路由中的 outboundTag 必須與某個出站的 tag 完全相同。沒有符合規則的請求會預設交由第一個出站處理，因此本例仍會直接連線。私有位址規則需要相應的地理資料；若執行環境沒有提供這些資料，應先解決資源載入問題，或了解用途後改用明確的位址範圍，而非忽略啟動錯誤。

分開檢查 JSON 語法與核心語意

標準 JSON 的鍵名與字串須使用雙引號，數字與布林值不加引號，陣列與物件的最後一個項目後面不能多加逗號。本文程式碼區塊皆採標準 JSON，不在設定檔中加入註解。有些載入方式支援擴充語法，但不能因此認定所有核心都接受某個用戶端支援的寫法。複製時只取程式碼內容，不要把標題、說明文字或程式碼區塊邊界一併貼進檔案。

語法正確不代表欄位有效。"port": 10808 是數字型連接埠，"udp": true 是布林開關；若寫成字串，可能導致解析失敗或出現非預期行為。重複鍵也值得檢查：不同解析實作的處理方式可能不同，應刪除重複定義，不要依賴後面的值覆蓋前面的值。修改後依序檢查結構、引用關係與執行結果，三者不能互相取代。

後續章節的簡短範例都是局部片段，只用來替換或理解相應段落，不能單獨作為完整執行檔案。若已有用戶端產生的設定，請先複製一份，再調整目標欄位並保留其他有效內容。更完整的段落串接範例請參閱逐段拆解 V2Ray 設定檔 JSON 結構。

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

inbounds 是陣列，每個元素都定義一個接收請求的入口，回答四個問題：監聽哪個位址、使用哪個連接埠、接受哪種協定，以及為入口設定什麼標籤。應用程式必須使用與入站相符的代理協定和連接埠。瀏覽器設定 HTTP 代理時，應連線至 HTTP 入站；支援 SOCKS 的應用程式則可連線至 SOCKS 入站。只在系統代理中填入某個數字，不會讓該連接埠自動變成應用程式預期的協定。

listen 決定接收請求的範圍。單機使用時，優先綁定 127.0.0.1，讓入口只供本機使用。綁定所有網卡會擴大可存取範圍，也牽涉防火牆、身分驗證與區域網路存取控制，不該當成網頁無法開啟時的通用修正方式。迴路位址也有不同的位址族：若應用程式連線到 IPv6 迴路位址，但服務只監聽 IPv4 迴路位址，連線可能失敗。排錯時，先明確使用設定檔中實際監聽的位址。

SOCKS 入站的 UDP 與網域傳遞

以下片段會啟用本機 SOCKS 入站與 UDP 支援。auth 設為 noauth，代表此入口不需要 SOCKS 使用者名稱與密碼，不代表遠端節點不需要身分資訊。由於只綁定迴路位址，適合單一使用者的桌面本機應用情境。若要改成共用入口，應重新評估存取範圍，而不只是修改監聽位址。

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

啟用 udp 只代表允許入站接收相應的 UDP 轉送請求，不代表所有應用程式流量都會進入核心，也不代表後續每種出站都能完成 UDP 傳輸。應用程式必須採用相容的轉送方式，出站協定與遠端服務也須支援相應功能。一般網頁能正常瀏覽，只能證明目前的網頁請求路徑可用，不能據此判斷即時通訊或其他 UDP 應用也一定可用。

網域在哪裡解析，取決於應用程式如何發出代理請求。應用程式可能先在本機解析，再把目標 IP 傳給 SOCKS；也可能將網域直接交由代理端處理。前一種情況下，可供網域路由使用的資訊可能較少；後一種情況則讓核心有機會依原始網域比對規則。應用程式中的「透過代理解析網域」等選項，須依實際行為判斷，不能只憑 SOCKS 名稱推斷解析位置。

HTTP 入站與入口標籤

HTTP 代理入口常用於系統代理或瀏覽器手動代理。瀏覽 HTTPS 網站時，應用程式通常會透過 HTTP 代理建立通道；這不代表本機 HTTP 入站本身必須設定網站憑證。不要混淆本機代理協定、目標網站協定與遠端代理傳輸層。如果使用獨立 HTTP 入站，系統代理設定的連接埠應與該入站一致；若用戶端使用混合入口，則以目前顯示的連接埠為準。

入站的 tag 不會決定連接埠類型，但可以作為路由條件。例如同一台電腦上的兩個入口可以分別設定標籤，再依 inboundTag 導向不同出站。標籤應保持唯一、簡短且易於辨識；修改標籤時，請同步檢查所有引用。不要把入站 tag 與出站 tag 當成自動配對關係；即使名稱相同，也不會自動建立連線，實際選擇仍由路由與預設出站規則決定。

排查連接埠占用時，先關閉重複啟動的用戶端，再查看記錄是否出現綁定失敗。變更連接埠後，須一併更新應用程式設定與系統代理；只修改 JSON 會留下舊的入口位址。用戶端重新啟動核心後，也要再次確認監聽已成功建立。入站存在、應用程式已連線與遠端存取成功是三個不同階段，應逐一驗證，避免頻繁切換伺服器來掩蓋本機入口錯誤。

outbounds：出站協定、tag 與預設出口

outbounds 定義核心接收請求後的連線方式。直接連線出站通常使用 freedom，封鎖出站通常使用 blackhole；遠端代理出站則依連線資訊使用相應協定。協定名稱決定設定結構，tag 則供其他段落引用。把 tag 改成 proxy 不會讓直接連線出站變成代理；實際行為仍取決於 protocol、協定設定與傳輸設定。

閱讀用戶端產生的設定檔時，先列出每個出站的 tag，再標示其實際用途。常見名稱有 proxy、direct、block，但用戶端也可以採用其他名稱。路由中若寫了 outboundTag: "proxy"，就必須找到同名出站；如果實際名稱是另一個標籤，應以執行設定為準。大小寫、連字號與前後空格都不能想當然地忽略。

直接連線與封鎖的最小設定

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

此片段的第一個出站是直接連線。沒有符合路由規則時，請求預設會交由第一個出站處理，因此調整陣列順序可能改變大量請求的去向。排序不能視為單純的排版作業。若希望預設使用代理，請確認第一個出站是有效的代理出站，或依核心支援的路由寫法明確設定預設規則。不要為了湊齊名稱而新增內容空白的代理出站。

封鎖出站用來主動拒絕或丟棄符合規則的流量，這與連線遠端失敗不同：前者可能是預期的路由結果，後者通常要檢查網路或遠端參數。若某個網域始終無法存取，應先確認是否符合封鎖規則，而非立刻更換 DNS。規則清單愈長，愈應保留每條封鎖規則的用途說明；可將說明記錄在維護文件或用戶端備註中，不必硬塞進標準 JSON。

分層檢視協定與傳輸設定

遠端代理出站可分成幾個部分理解：伺服器位址與連接埠描述連線位置，協定設定描述身分與協定行為，streamSettings 則描述底層傳輸與安全層。VMess、VLESS、Trojan 的欄位不能互相套用；REALITY 是特定核心支援的安全層方案，也不是直接把出站協定名稱改成 REALITY。處理訂閱匯入結果時，先確認實際協定，再逐層核對參數。

即使連接埠與目標位址相同，也不足以證明兩份設定等效。伺服器要求的傳輸類型、TLS 服務名稱、路徑或其他協商參數，只要有一項不符，都可能在連線或交握階段失敗。不要從另一個節點資料中借用看似相近的值。本文不提供可用的遠端認證資料；實際連線資訊應來自使用者有權使用的服務設定，分享記錄時請遮蔽身分資訊與訂閱網址。

使用網域格式的伺服器位址，也會產生解析相依性。核心建立遠端連線前，必須先取得該位址對應的 IP；如果解析過程又依賴尚未建立的同一條連線，就可能形成啟動循環。故障表現可能是持續逾時，而非明顯的 JSON 錯誤。排查時應區分「遠端位址解析失敗」與「目標網站解析失敗」；兩者位於請求路徑的不同位置，不能只檢查一項 DNS 設定。

用戶端可能會依目前選取的伺服器重新建立代理出站。此時手動編輯暫存的執行檔案，即使短暫生效，也可能在切換伺服器或重新啟動時被覆蓋。若要長期保留出站調整，應使用用戶端支援的自訂設定方式。若只想比較桌面與行動裝置的管理差異，可參閱用戶端選擇指南；不要把不同用戶端匯出的所有欄位原封不動地合併成同一個檔案。

驗證出站時，至少分別觀察一個明確應直接連線的請求，以及一個明確應透過代理的請求。只開啟一次網頁，無法證明路由選擇符合預期；瀏覽器快取、既有連線與應用程式自身的代理設定都會干擾判斷。修改後請關閉舊連線再測試，並搭配記錄中的目標位址、出站標籤與錯誤階段確認結果。

routing：比對條件、規則順序與預設路由

routing 決定請求交由哪個出站處理。規則通常由上而下檢查，符合第一條規則後就會使用該規則指定的出口，不會繼續尋找「更精確」的後續規則。因此，規則順序本身就是設定語意。範圍很大的規則若放在前面，會遮蔽後面範圍較小的規則；例外規則若放在最後，也可能永遠不會符合。編輯前先規劃順序：局部例外、一般分類、最後的預設規則。

一條規則中的不同條件欄位通常必須同時符合；同一條件陣列中的多個值通常是候選比對項目。例如同時設定 inboundTag 與 domain，表示請求必須來自指定入口，且目標網域也符合條件。這不是「符合入口或網域任一項即可」。若要表達不同路徑，應拆成多條獨立規則，避免在同一個物件中堆疊彼此無關的條件。

先設定網域規則，再補上位址規則

以下片段展示規則比對順序，所有符合條件的請求都指向 direct，用來說明條件結構。設定檔中必須已有同名出站。範例以保留的示例網域說明 full: 與 domain:，並採用明確的私有位址範圍，避免依賴地理資料檔案。這不是完整的地區分流方案。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

full: 用於比對完整網域，domain: 則用於比對指定網域及其子網域。後者適合管理同一網域下的一組服務，但網站頁面、圖片與驗證介面可能來自多個網域，不能把網站主網域視為所有相依服務。裸字串與正規表示式也各有比對語意；維護一般規則時，優先採用意圖明確的前綴，以減少誤判與後續說明成本。

geosite: 與 geoip: 是資料集引用，不是線上查詢服務。能否使用及包含哪些分類，取決於執行環境中的資料檔案與分類內容。規則寫了某個分類，不代表目前核心一定能載入。匯入第三方規則時，應同時確認分類存在、資源可讀取，且引用的 tag 已有定義；不能只檢查 JSON 括號是否成對。

domainStrategy 不等於 DNS 伺服器設定

AsIs 表示路由階段通常依照現有目標資訊比對，不會為了 IP 條件主動解析網域。IPIfNonMatch 會在網域規則未符合時嘗試解析，以便繼續比對 IP。IPOnDemand 則會在路由需要 IP 資訊時觸發解析。選擇策略應依規則結構決定，而非認為愈早解析就愈準確；額外解析會增加相依性，也可能改變請求處理時機。

路由的 domainStrategy 與 DNS 的 queryStrategy 處理的是不同問題：前者決定何時為路由取得位址，後者決定 DNS 查詢偏好的位址族。直接連線出站也可能有獨立的網域解析策略。排錯時應明確記下解析發生的階段，而非籠統地說「已啟用 DNS」。如果網域已在應用程式端解析，核心能否取得網域資訊，還取決於應用程式傳遞的內容及嗅探等額外機制。

預設路由需要另外確認。沒有規則符合時，會預設選擇第一個出站；若維護者誤以為「最後一個出站才是預設出口」，結論就會完全相反。有些用戶端介面以 final → proxy 表示最後的流向，這只是方便閱讀的概括，不代表核心 JSON 有通用的 final 頂層欄位。請查看用戶端實際產生的規則或第一個出站，確認介面上的選擇如何實際套用。

新增規則後，分別用一個應符合與一個不應符合的目標進行對照測試。若新規則沒有作用，先往上檢查是否已被既有規則截取，再確認核心取得的目標是網域還是 IP，最後檢查 tag 引用與資源載入。系統代理中的「全域」只影響應用程式如何交付流量，核心路由仍可能進行分流；兩者應分開確認，相關操作步驟請參閱使用指南中的模式選擇。

dns：解析伺服器、位址族與查詢路徑

dns 定義核心可使用的解析功能，但不會因為設定檔中有這個區段，就自動接管整台電腦的所有 DNS。應用程式、作業系統、瀏覽器與核心可能各自進行解析。先確認由哪一層發起查詢，再決定應修改什麼。瀏覽器若自行啟用加密解析，系統 DNS 的變更未必會影響它；應用程式若先將網域轉成 IP，核心也未必能依預期套用網域規則。

判斷設定是否符合預期，需要釐清三件事：查詢送給誰、透過哪條路徑送達，以及取得的位址用於哪個階段。只更換伺服器位址，解決的是第一件事，不能保證另外兩件事也隨之改變。遠端代理伺服器的位址解析、路由進行 IP 比對時的解析，以及直接連線目標的解析，也可能發生在不同位置。記錄這些相依關係，比同時加入多個解析伺服器更有助於穩定排錯。

指定解析伺服器與靜態 hosts

以下是局部 DNS 範例。靜態 hosts 會將示例網域固定指向迴路位址，僅供本機測試；日常使用時應移除這筆測試對應。伺服器清單採用明確的 IP，避免必須先解析伺服器自身的網域才能連線。伺服器是否可連線、查詢會經過哪個出口，仍須搭配核心行為與路由設定驗證。

{
  "dns": {
    "hosts": {
      "example.com": "127.0.0.1"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

hosts 適合暫時固定已知位址，或在受控環境中確認解析與連線的差異，不適合長期取代位址可能變動的服務。對應到迴路位址後，存取該網域會連到本機；如果本機沒有對應服務，連線失敗就是預期結果。排錯完成後請移除測試對應，否則下次發生問題時，原因可能是遺留設定，而非解析伺服器本身。

queryStrategy 常見值包括 UseIP、UseIPv4 與 UseIPv6，實際支援範圍以目前使用的核心為準。在雙協定堆疊網路中，解析出 IPv6 位址不代表 IPv6 連線一定可用。暫時限定 IPv4 有助於確認位址族問題，但不應將停用某個位址族當成適用所有網路的固定解法。還須考量遠端位址、目標位址與作業系統網路能力是否相符。

分域解析與回退範圍

較複雜的伺服器物件可以設定網域比對範圍與預期位址等條件，將不同網域交由不同解析來源處理。採用這類設定前，先確認目前核心支援的欄位與回退規則。多個伺服器不代表系統會依陣列順序逐一嘗試直到成功；比對條件、回退開關與解析結果判斷都會影響決策。若尚未釐清需求，應先維護一條容易理解的基本路徑，再逐步加入分域策略。

使用加密 DNS 時，也要分清傳輸加密與出口選擇。加密描述查詢在相應鏈路上的傳輸方式，不會自動決定請求經過哪個代理出站。不同的解析位址格式可能採用不同處理路徑，不能把一般路由處理 UDP 查詢的方式套用到所有加密解析方法。設定前先確認所用形式的路由與引導解析需求，再透過記錄和實際請求驗證。

解析相依循環常見於解析伺服器需要透過代理存取，而代理伺服器的網域又依賴同一台解析伺服器。此時設定即使通過結構檢查，也可能無法建立第一條連線。修正時應為必要的啟動解析提供可用路徑，而不是一再延長逾時時間。記下代理伺服器網域、解析伺服器位址與使用的出站，就能直接畫出循環，再決定在哪個環節解除相依性。

測試 DNS 時，先關閉舊網頁與既有連線，確認應用程式使用預期的代理設定，再比較目標網域的解析與存取結果。作業系統或瀏覽器快取可能讓設定變更看似無效，重用連線也可能略過新的解析流程。應清除哪一層快取，取決於實際發起查詢的來源。想了解具體檢測步驟，可繼續閱讀DNS 查詢路徑檢測與設定排查；不要把單一檢測網站的結果當成所有應用程式的實際行為。

policy：使用者等級、連線時限與統計

policy 管理部分連線行為與統計開關，不負責選擇遠端伺服器，也不負責依地區分流。它通常分為 levels 與 system：前者依使用者等級定義策略，後者控制系統層級的部分統計。閱讀時，先確認連線使用哪個等級，再查看該等級實際設定了哪些欄位。若一律認定所有使用者都是等級零，可能會忽略協定使用者物件已指定的其他等級。

等級名稱在 JSON 中是物件鍵，因此範例使用字串 "0"；協定設定中引用的 level 通常是數字。等級不是伺服器優先順序，也不是節點品質評分。提高等級數字不會改善連線效能，只會改用另一組策略。如果沒有明確的分級需求，設定宜保持簡單，避免新增沒有任何使用者引用的等級項目，以免誤以為設定已變更卻沒有生效。

連線時限的局部範例

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

這些數值用來示範欄位結構，不是適用所有網路的建議調校值。handshake 表示交握階段的允許時間，單位為秒；connIdle 涉及連線閒置時限。uplinkOnly 與 downlinkOnly 用於設定一個方向結束後，另一個方向繼續保留的時間。這些欄位主要影響連線生命週期，不能改善路徑壅塞、遠端服務處理能力或本機無線網路品質。

交握逾時設得太短，網路不穩可能讓原本可以建立的連線提早中止；設得太長，真正無法連線的目標則會讓應用程式多等一段時間。判斷是否需要修改，必須配合錯誤發生階段。若記錄顯示伺服器名稱或安全層參數不符，延長時間無法修正參數錯誤；若錯誤是本機連接埠綁定失敗，policy 更不是處理入口。先找出失敗位置，再決定是否調整時限。

分清統計開關與用戶端顯示

使用者統計與入站統計涵蓋的範圍不同。開啟某個統計開關，不代表用戶端介面會自動顯示相關資訊；也可能需要核心統計模組、查詢介面與用戶端讀取功能配合。部分統計還要求使用者具備可識別的標記。只複製開關，卻未確認資料收集與讀取流程，容易得到始終空白的結果。也不要因為介面沒有顯示，就認定網路連線沒有經過核心。

用戶端本身可能會管理應用程式狀態、連線記錄或其他執行資訊，這些內容未必都來自 policy。檢視匯出的設定檔時，應分開確認「核心是否收集」與「介面是否顯示」。若統計只是暫時用於排錯，明確設定排錯目標即可，不必為了讓設定看起來完整而全部啟用。需要長期保留執行記錄時，也應考量磁碟空間，以及記錄中可能包含的存取目標。

緩衝區相關策略同樣不該照抄所謂的通用效能設定。連線數量、應用程式資料模式與裝置記憶體都會影響資源負載；一味加大緩衝區可能增加記憶體用量，卻無法改善實際回應速度。不同核心也可能調整欄位支援範圍或預設值。遇到不熟悉的策略欄位，先查閱目前核心的文件；不要因為舊文章曾提過，就認定目前用戶端一定支援。

需要測試策略變更時，請固定使用同一個應用程式、同一個出口與相近的網路環境，每次只修改一組相關數值，並保留修改前的設定。測試應涵蓋新建連線、短暫閒置後恢復，以及長時間閒置後重新連線。若應用程式本身有心跳機制，連線可能不會進入預期的閒置狀態。持續下載一次無法驗證閒置回收行為，應針對欄位實際管理的情境進行觀察。

預設設定已符合需求時，可以不明確寫出整段 policy。省略欄位代表採用目前核心的預設行為，不等於功能已停用。列出每個預設值會增加維護負擔，也可能把舊核心的選擇固定套用到新環境。維護手冊應記錄「為何覆寫預設值」，而不只是一串數字，方便日後判斷這項調整是否仍有必要。

用戶端產生設定與自訂設定的界線

v2rayN 是本站首選的桌面用戶端，支援 Windows、macOS 與 Linux；Android 可使用主要採用 Xray 核心的 v2rayNG，或採用 V2Fly 核心的 v2flyNG。用戶端提供訂閱、伺服器、路由與參數管理介面，實際執行行為仍取決於選用的核心及產生的設定結果。安裝檔統一收錄於用戶端下載頁；本手冊僅說明設定關係，不提供獨立核心安裝檔或遠端伺服器資訊。

用戶端設定的關鍵在於「由誰管理資料」。訂閱負責更新連線資訊，伺服器選擇決定目前使用的代理出站，路由範本決定分流規則，參數設定則影響入站連接埠及其他執行選項。產生的檔案是這些輸入的組合結果。直接修改產生的檔案，可能在切換伺服器、更新訂閱、重新啟動核心或變更應用程式設定後被覆寫；這不是 JSON 沒有儲存，而是下一次產生設定時，管理來源中的值又重新套用了。

訂閱管理不是核心頂層鍵

subscription 是用戶端的管理概念，不是本文所述 V2Ray 核心 JSON 通用的頂層欄位。訂閱網址、自動更新週期與群組名稱應在用戶端的訂閱管理介面設定，不能在執行檔案中新增同名物件來實現。訂閱內容也可能以編碼文字或協定連結清單提供；由用戶端解析後，再轉換成核心所需的協定與傳輸設定。

訂閱更新失敗時，先保留目前可用的資訊，再檢查連結有效期限、存取路徑、回應格式與用戶端提示。不要因為更新失敗就刪除所有伺服器，也不要把訂閱網址貼到公開記錄中。自動更新只負責同步資訊，不會自動修正本機連接埠衝突或系統代理設定。詳細排查方式請參閱訂閱更新失敗與自動更新設定。

分層檢查系統代理、路由與接管模式

系統代理會將請求交給本機入口，供遵循系統代理設定的應用程式使用；核心路由則決定進入入口的請求如何離開。選擇「自動設定系統代理」不代表所有應用程式都會被接管；選擇「清除系統代理」也不一定會停止核心監聽。有些應用程式會保留自己的代理設定，可能繼續使用本機連接埠。排錯時，作業系統與應用程式自己的網路選項都要檢查。

v2rayN 常見的相關功能入口包括「訂閱群組」、「路由設定」、「參數設定」與系統代理選單，實際名稱及位置可能因介面版本而異。Android 用戶端通常透過系統授權建立相應的接管方式，不能直接套用桌面系統代理的操作路徑。跨平台移轉時，應移轉需求與連線資訊，再於新平台確認權限、監聽方式與路由模式，而非直接複製桌面產生的設定檔。

部分用戶端也提供虛擬網卡接管模式，與一般系統代理在流量範圍、權限需求及 DNS 路徑上都不同。啟用後應重新確認區域網路存取、解析方式及其他網路軟體能否正常共存，不能直接沿用先前只針對 HTTP 代理得出的結論。需要提高權限時，應先確認確有使用該模式的必要；若只有單一瀏覽器需要手動代理，就不必為了修正連接埠填寫錯誤而立刻更換接管方式。

保留可維護的修改來源

打算長期自訂前，先確認用戶端提供的是路由規則編輯、自訂片段，還是完整自訂設定。三者的涵蓋範圍不同：局部片段可能會合併，完整設定則可能略過部分自動產生流程；實際行為請以目前用戶端說明及產生結果為準。每次調整都應保存原始設定，並記錄修改入口、目標欄位與預期現象，以便設定被覆寫時找出真正的管理來源。

匯入外部完整設定前，檢查是否包含額外監聽、控制介面、遠端位址或不明路由。能夠執行不代表符合本機需求。尤其要確認監聽範圍沒有從迴路位址改成所有網卡、原有系統代理連接埠仍對應正確入口，且預設出站方向符合預期。遇到不理解的欄位，先查明用途，不要只為了讓核心啟動就盲目刪除整段安全層或路由設定。

設定檔與記錄也有分享界線。協定身分資訊、完整訂閱網址、存取目標與本機路徑都可能包含個人資料。公開尋求協助時，只保留重現問題所需的欄位與錯誤階段，替換敏感值並註明核心類型。不同核心的錯誤訊息不能只因字面相似就一併處理；先清楚說明環境，才能判斷問題來自語法、支援範圍還是網路路徑。

設定驗證、記錄閱讀與復原方式

驗證應沿著請求路徑逐步進行：設定能否載入、入站能否監聽、應用程式是否進入入口、路由是否選對出站、遠端連線是否建立，以及目標解析與存取是否完成。每個階段都可能失敗，外在症狀卻常常只是「網頁無法開啟」。不要同時更換伺服器、DNS、路由與本機連接埠；多個變數一起變動，即使暫時恢復，也很難找出真正原因，更無法在下次故障時沿用判斷。

開始前，先保存一份已知可正常運作的用戶端設定或設定檔副本，並記錄目前模式。接著每次只修改一項，套用設定並重新啟動對應核心，再以明確目標測試。只儲存檔案、卻未讓核心重新載入，觀察到的可能仍是舊設定。反之，重新啟動用戶端後設定又消失，就應回到上一章檢查設定產生來源，而非反覆編輯同一個暫存檔案。

先分辨載入失敗與連線失敗

載入階段的問題通常包括 JSON 語法錯誤、欄位型別錯誤、核心不支援的協定或欄位，以及路由資料資源缺漏。此時先查看記錄中最早出現的關鍵錯誤，不要只看最後的「啟動失敗」。錯誤行附近的逗號、引號與陣列邊界特別值得檢查，但有時錯誤位置會指向實際問題之後，因此也應回頭檢查前一個物件的結尾。

核心已啟動但連接埠無法連線時，檢查位址族是否不一致、連接埠是否衝突，或應用程式是否仍使用舊連接埠。系統代理殘留也很常見：用戶端退出後，系統可能仍指向已不存在的本機監聽，影響所有遵循系統代理設定的應用程式。處理時先恢復正確的系統代理，再確認用戶端執行狀態，不必先修改遠端協定參數。

暫時提高記錄詳細程度

以下片段將記錄層級設為 info，用於暫時觀察連線與路由。不同用戶端可能會將記錄收集在自己的介面中，也可能寫入指定檔案。若未明確設定檔案路徑，實際顯示位置取決於啟動方式。如果資訊仍不足，可在受控的排錯期間進一步提高詳細程度；完成後請調回較少輸出的設定，避免長期累積大量請求資訊。

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

閱讀記錄時，請針對同一次測試查找目標、入站、出站與錯誤階段。逾時可能發生在解析、建立連線或交握期間，代表的問題各不相同；連線遭拒通常表示該位址與連接埠沒有預期服務，或請求遭到明確拒絕；安全層交握失敗則應核對服務名稱、時間與協定參數。不要把所有錯誤都歸咎於節點無法使用，也不要把正常關閉的記錄誤當成故障原因。

系統時間也會影響部分協定與安全交握。若記錄顯示認證或憑證時間相關錯誤，先檢查裝置的時間與時區是否正確，再確認遠端資訊。網路切換後若出現問題，則須重新確認預設網路、解析伺服器是否可連線，以及既有連線狀態。裝置從有線網路切換到無線網路，不代表舊連線仍然有效；重新建立連線有助於分辨環境變更與靜態設定問題。

復原時應還原整個相關修改單元，而不是只刪除報錯欄位。例如修改了出站 tag，就要一併還原路由引用；修改連接埠，也要同步還原系統與應用程式代理設定。復原後重新載入核心，確認記錄中沒有啟動錯誤，再重做最初的測試。如果還原副本後仍無法使用，應考慮外部網路或遠端服務已變更，而非繼續在同一段 JSON 中尋找不存在的差異。

完整的問題重現記錄應包含測試應用程式、接管方式、核心類型、目標所屬路由類別、錯誤發生階段與最後一次修改。無須公開完整訂閱內容或所有伺服器資訊。更貼近介面操作的排錯順序，請參閱已連線卻無法瀏覽網頁的檢查清單；若要重新建立基本流程，請返回快速入門指南，重新確認匯入資訊、選擇模式與驗證連線的步驟。

維護設定的目標，是讓每個欄位都有明確來源、每條規則都有可說明的用途，每次修改都有可執行的復原方式。設定檔較短，不必為了完整而補上所有選用區段；設定檔較長，也不代表功能更完整。保留實際需要的入口、出站與規則，了解預設行為及核心限制，比不斷堆疊來源不明的片段更方便查閱與排錯。