V2Ray 設定檔
架構與欄位參考

01 / JSON 架構與設定歸屬

先釐清用戶端設定與核心設定

先找出目前使用的設定來源，再決定要在哪裡修改。v2rayN、v2rayNG 與 v2flyNG 都是圖形介面用戶端，負責管理訂閱、選擇設定並啟動核心；核心則負責實際接收連線、比對路由及轉送資料。介面中儲存的訂閱網址、視窗選項和自動更新排程，不一定屬於核心 JSON。若把用戶端的設定檔當成核心設定來編輯，常會遇到欄位確實存在、執行結果卻沒有變化的情況。

接著確認設定是否由用戶端自動產生。切換節點、調整路由或重新啟動時，用戶端可能會重寫執行中的設定檔。直接修改暫存檔，通常只能維持到下次產生設定為止。需要長期保留的內容，建議優先在圖形介面中設定；若確實需要自訂 JSON，請使用用戶端明確支援的自訂設定入口，並保留原始檔案。匯出、檢視和編輯是不同操作；看得到 JSON，不代表該位置能永久保存修改。

依物件與陣列理解架構

可將最外層視為一組各有不同職責的物件。inbounds 與 outbounds 是陣列，因為可以同時設定多個入口與出口；routing、dns、policy 通常是物件，用來收納各自的細項設定。物件以大括號括住，陣列以方括號括住。欄位名稱與字串使用英文雙引號，數字和布林值則不加引號。連接埠填寫數字，開關使用 true 或 false，不要一律轉成文字。

以下是一份可獨立執行的本機直連範例，供理解設定架構使用。它只在本機提供 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，不含註解。編輯器能開啟檔案，只代表文字可讀；語法檢查通過，也只代表架構合法。核心是否識別欄位、協定是否支援、目標是否可連線，仍須分別驗證。不要把這幾個階段混為一談，直接判定「設定正常」。

每次修改都留下一筆簡短紀錄，例如修改了哪個物件、預期影響哪種連線，以及要如何還原。一次只調整一個職責層，避免同時更換 DNS、路由和傳輸設定。設定中若出現看似重複的欄位，先比較它們所在的路徑：路由物件中的解析策略與出站物件中的解析策略，可能作用於不同階段。欄位名稱相同不代表作用相同，複製時應連同父物件一併核對。

02 / inbounds 入站與監聽範圍

先確認應用程式如何連入核心

入站是核心接收連線的入口。先確認應用程式使用系統代理、個別 SOCKS 設定，還是由用戶端的虛擬網路介面接管，再檢查對應設定。桌面應用程式通常透過本機 HTTP 或 SOCKS 連接埠連入核心；Android VPN 模式則由用戶端搭配系統介面處理流量，不能只因 JSON 中出現 SOCKS 連接埠，就認定所有應用程式都會經過這個入口。入口尚未收到連線時，調整出口通常無法解決問題。

逐項核對 listen、port 和 protocol。監聽位址決定接受哪個網路介面上的請求，連接埠決定服務入口的編號，協定則決定入口接收哪種格式的資料。瀏覽器的 HTTP 代理設定不能隨意指向只接受 SOCKS 的連接埠。若用戶端介面顯示「混合連接埠」，還要確認這是用戶端提供的整合功能，還是核心設定中的獨立入口；不要把介面用語直接當成通用協定名稱填入 JSON。

區分本機存取與區域網路存取

僅供目前裝置使用時，建議繫結 127.0.0.1。這是 IPv4 迴圈介面位址，其他裝置無法透過它存取目前裝置上的代理。若要在區域網路中共用，通常還須設定監聽位址、作業系統防火牆、入口驗證，以及確認裝置之間的網路連通性。單獨開啟「允許來自區域網路的連線」，不代表其他裝置已取得存取權，也不表示這些連線會自動通過身分驗證。

以下僅展示一個 HTTP 入站物件，應作為 inbounds 陣列中的一個項目。它使用與前述 SOCKS 入口不同的連接埠，方便在應用程式設定中明確區分。連接埠號碼只是本機約定，不代表遠端服務的連接埠。若應用程式沒有送出請求，先檢查系統代理是否仍指向舊值，再確認用戶端是否確實載入該物件；不要因為連接埠號碼常見，就假設系統中一定已有對應服務。

{
  "tag": "local-http",
  "listen": "127.0.0.1",
  "port": 10809,
  "protocol": "http",
  "settings": {}
}

了解 UDP 與嗅探的適用範圍

SOCKS 入站的 udp 開關表示允許該入口處理 SOCKS UDP 請求，不代表所有應用程式的 UDP 流量都會自動進入核心。應用程式必須支援相應的代理方式，後續出口與網路路徑也必須允許轉送。只設定系統 HTTP 代理時，部分即時通訊或遊戲流量可能仍走原本的路徑。遇到這種情況，先確認應用程式支援的代理方式，再閱讀TUN 模式說明，不要反覆更換監聽連接埠。

嗅探是依據連線開頭的資料辨識目標資訊的功能，常用來輔助網域路由。它不會解密所有應用程式內容，也不能取代 DNS 解析。不同核心支援的嗅探欄位、目標協定，以及僅供路由使用的選項可能有所差異，加入前請先確認目前的實作。啟用後若部分應用程式行為異常，請保留其他設定不變，單獨關閉嗅探來比較結果。判斷依據應是個別連線，而不是一次整體測速。

最後查看日誌，確認入口是否成功繫結。若位址已被占用，請檢查是否同時啟動了另一個用戶端、舊程序是否仍在執行，以及用戶端是否已自動建立同名入口。不要為了避開衝突就立即改成監聽所有介面。需要更換連接埠時，也要同步更新應用程式中的代理位址；使用迴圈位址的應用程式還須留意 IPv4 與 IPv6 的差異，localhost 在不同系統上可能優先解析成不同位址。

03 / outbounds 出站與預設出口

先找出最後選用的出站

出站決定核心收到請求後，如何將連線送往下一步。常見類型包括直接連線到目標、連線至遠端代理服務，以及主動封鎖請求。先查看 routing 是否將流量指向特定標籤，再檢查對應的出站物件。清單中有遠端代理出站，不代表每條連線都會使用它；規則可能先命中直連出口，也可能因標籤寫錯而導致載入失敗。疑難排解時，應區分「物件存在」與「物件正在使用」。

沒有符合的路由規則時，常見的預設行為是使用 outbounds 陣列的第一個項目。因此，調整陣列順序可能直接改變未命中規則的流量去向。不要只為了方便閱讀，就把直連物件從清單末端移到開頭。用戶端通常會依自己的模式產生順序，自訂設定則須明確規劃預設出口。將預設行為記錄在維護紀錄中，比根據標籤名稱猜測可靠；名為代理的標籤也可能指向直連物件。

區分直連、封鎖與遠端協定

freedom 是常見的直連出站協定，blackhole 則用於封鎖。兩者都不需要遠端帳號，但只有在被選用時才會生效。封鎖連線後的表現也不一定相同：應用程式可能顯示連線失敗、等待重試，或改用其他位址繼續送出請求。看到頁面最後成功開啟，不能據此認定封鎖規則沒有生效；還要查看被封鎖的是哪一條連線，以及應用程式是否接著送出其他請求。

以下是完整的出站陣列片段，可用於本機路由測試。內容只有直連與封鎖，不包含任何遠端代理功能。tag 供路由規則引用，協定名稱則供核心選擇實作，兩者不可互換。若在後續章節使用 outboundTag，應與此處的標籤完全一致。大小寫、連字號或多餘空格都可能造成引用不一致；重新命名時，請一併搜尋所有引用位置。

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

遠端代理出站須依協定填寫服務位址、連接埠與驗證參數。VMess、VLESS 與 Trojan 的驗證結構不同，不應將其中一種的使用者物件搬到另一種協定。訂閱產生的設定也可能包含流控、加密與安全層等相關欄位。先在用戶端確認原始連線資料是否完整，再檢查產生後的物件；若來源資料本身缺少欄位，修改路由也無法補上伺服器所需的驗證資訊。

協定名稱不等於完整連線條件

同一代理協定可以搭配不同的傳輸方式與安全層。兩份設定即使都使用 VLESS，也可能因傳輸路徑、服務名稱、TLS 伺服器名稱或安全參數不同而無法互換。服務端位址用來建立連線，憑證驗證名稱則用來核對遠端身分；兩者有時相同，有時不同。請依服務提供的參數分別填寫，不要用同一個網域取代所有看似相似的欄位，也不要把訂閱分組名稱填入網路位址欄位。

設計多出口時也要避免連線遞迴。如果代理出站連往遠端伺服器的連線，又被用戶端的全域接管機制送回同一個入口，就可能形成迴圈。圖形介面用戶端通常會處理自身程序、伺服器位址或繫結介面等細節，自訂設定時不應任意移除這些安排。若連線數持續增加、日誌反覆連往同一位址，請先停用新增的鏈式轉送與全域接管設定，恢復單一出口進行驗證。

排查遠端無法連線時，請依序檢查位址、連接埠、驗證、傳輸與安全層。能建立 TCP 連線只表示基礎網路路徑可達，不能證明代理協定交握成功。延遲測試與實際網頁請求也可能使用不同目標。若要比較指標，請參考節點測速數值說明，先確認測量對象再解讀數值。一次低延遲不能證明整份出站設定都正確。

04 / 傳輸參數與安全層

分別核對協定、傳輸與加密連線

先釐清三個問題：代理協定如何組織驗證與請求、傳輸方式如何承載這些資料，以及安全層如何驗證並保護外層連線。用戶端常將這些選項放在同一個編輯頁面，但它們屬於不同設定層。代理協定正確但傳輸錯誤，仍無法完成連線；傳輸已建立但驗證錯誤，後續仍會遭到拒絕。疑難排解時應指出失敗發生在哪一層，避免將所有問題一概歸因於節點無法使用。

常見設定中的 streamSettings 負責組織傳輸與安全相關選項。它可以放在對應的入站或出站物件內，並不是放在最外層就能全域生效的通用開關。不同核心支援的傳輸名稱與專屬欄位各有範圍，同一技術在不同階段也可能採用不同的設定方式。保留用戶端目前產生的架構，再參照目前核心的說明調整，會比整份覆蓋舊文章中的物件更穩妥。

逐項核對 TLS 名稱與驗證設定

TLS 是用來建立加密連線並驗證遠端身分的一組機制。先核對安全類型，再確認 serverName 是否符合服務提供的參數。這個名稱通常會用於伺服器名稱指示與憑證驗證，不是可任意填寫的備註。連線位址使用 IP，不代表驗證名稱也必須改成相同的 IP。若遠端憑證是以網域簽發，任意更換名稱可能使原本可連線的服務在交握階段失敗。

以下僅展示常見的 TLS 設定物件，用來說明欄位架構。example.com 是文件中的範例網域，必須依實際服務參數設定，不能用它建立代理連線。範例未指定傳輸類型，因為類型必須符合實際服務。allowInsecure 維持關閉，表示不主動略過憑證驗證；不要把停用驗證當成一般修復方式，以免掩蓋名稱、憑證鏈或裝置時間錯誤。

{
  "streamSettings": {
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com",
      "allowInsecure": false
    }
  }
}

遇到憑證相關錯誤時，先檢查裝置日期與時區，再核對名稱、服務位址及網路環境。系統時間不準會使憑證看起來尚未生效或已過期。部分網路還可能要求先完成入口網站登入，導致請求實際連到登入頁面，而不是目標服務。確認這些基本條件後，再查看核心日誌中的具體交握錯誤。瀏覽器能開啟某個網站，並不能證明代理服務的 TLS 參數完全正確。

路徑與服務名稱須符合傳輸方式

使用 WebSocket 時，路徑與相關要求標頭可能會影響伺服器端分流；使用 gRPC 時，服務名稱則是另一組參數。兩者不能互相取代，也不能只根據介面中「主機」標籤的字面意思自行推斷。複製參數時，請保留路徑開頭的斜線與大小寫，並留意空字串與未設定欄位是否代表不同含義。服務位址、HTTP 主機欄位與 TLS 名稱有時各有用途，不要為了看起來一致而強行改成相同值。

REALITY 是特定核心支援的安全方案，不能因為另一個核心也支援 VLESS，就假設所有相關欄位都通用。涉及公鑰、短識別碼或流控的設定，應逐項符合服務端約定及目前核心的實作。此處不提供拼裝式遠端範例，以免將不同連線資料中的參數組合成看似完整、實際無法運作的物件。匯入用戶端後，先保留原始參數進行測試，再逐項調整。

也要區分傳輸設定與連線多工。多工會改變多條應用程式連線如何共用底層通道，不會自動修正錯誤的憑證名稱、傳輸路徑或驗證參數。為了排除變因，先在原始連線條件下完成驗證，再決定是否啟用相容的多工方案。部分協定、流控或傳輸組合對多工另有限制，不能只從其他設定中複製一個開關。若啟用後才出現間歇性中斷，應將多工視為獨立變因，逐項回退測試。

05 / routing 路由規則與比對順序

從第一條規則開始依序檢查

路由的工作是為每條連線選擇出站。先依陣列順序查看 rules，找出第一條符合條件的規則，再核對該規則指向的出口。不要把規則清單當成所有條件都會逐一執行的項目。範圍很廣的規則若排在前面，後續的細部規則可能永遠無法命中。新增規則時，先釐清要影響哪類連線，再決定插入位置，不要習慣性地一律加在最後。

單條規則中的不同條件通常會共同限制比對範圍，例如入口標籤與目標網域必須同時符合；同一條件陣列中的多個候選項目，通常表示符合其中任一項即可。實際組合方式仍應以目前核心的實作為準。初次除錯時，先用一個條件驗證目標，再逐步增加限制。一次填滿入口、連接埠、協定與網域，看似精確，卻會讓未命中的原因難以判斷。

先使用不依賴額外資源的規則

以下是可合併至第一章本機範例的 routing 物件，但還須同時加入第三章的 block 出站。它會將文件範例網域交給封鎖出口，並將列出的私人位址範圍交給直連出口。其他流量仍依原設定的預設出口處理。此範例不依賴外部網域分類檔，方便先了解引用方式與順序；它也不是完整的區域網路位址清單，不應直接作為正式環境的分流方案。

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

網域比對應明確選擇方式。full: 表示比對完整網域，domain: 常用來比對該網域及其子網域，規則運算式則適用於較特殊的模式。一般字串的比對方式與前綴形式不同，撰寫規則前應先確認預期結果。若要控管某個網站，也要考慮其靜態資源、登入與 API 可能位於其他網域；只比對首頁網域，未必涵蓋該應用程式實際建立的所有連線。

區分路由解析與最終連線解析

domainStrategy 決定路由階段如何處理目標網域。常見的 AsIs 不會為了 IP 規則主動解析網域；IPIfNonMatch 會在網域規則未命中時嘗試解析，再讓 IP 條件有機會比對；IPOnDemand 則會在比對過程遇到需要 IP 的規則時嘗試解析。這些設定控制的是路由判斷，不是全域 DNS 出口開關，也不會直接決定所有應用程式最後採用哪種解析方式。

採用較積極的解析策略前，先確認是否真的需要依目標 IP 分流。額外解析會帶來等待時間、快取及回傳位址變動等因素。同一網域可能回傳多個位址，核心如何據此比對也應依實際行為確認。若目標本身是 IP，網域規則通常無法憑空還原原始網域；嗅探可能為部分協定補充資訊，但並非對所有連線都有效，更不能保證辨識所有加密應用程式的流量。

geosite 與 geoip 是引用分類資料的方式，不是寫進字串就會自動進行線上查詢。規則是否可用，取決於核心支援、資源檔是否存在、分類名稱是否正確，以及用戶端如何管理這些資源。分類載入失敗時，先改用明確的網域或位址規則進行驗證。不要將某個環境中的分類標籤直接套用到另一個環境，卻忽略其依賴的資料來源與檔案位置。

調整路由後，使用目標明確的單一請求進行驗證。清除舊連線，觀察新連線使用哪個出口，再測試相關應用程式的其他網域。既有長連線可能繼續沿用原本通道，造成介面設定已變更、實際行為卻暫時不變。遇到流量繞行或誤封鎖時，依「入口標籤、目標資訊、第一條命中規則、出口標籤」的順序檢查。其他常見使用問題可參閱常見問題，不必先重設所有設定。

06 / dns 解析器與分流範圍

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

DNS 是將網域轉換為網路位址的查詢機制。先確認應用程式交給代理的是網域還是已解析的 IP，再檢查核心 DNS。瀏覽器、作業系統、核心與遠端服務都可能參與解析；設定中有 dns 物件，不代表裝置上的每次查詢都會經過它。應用程式若使用獨立的加密解析，也可能繞過系統預設的解析路徑，因此須一併核對應用程式層設定與核心設定。

核心內建解析器通常供需要解析網域的內部功能使用，例如依 IP 路由或部分直連出站行為。遠端代理收到網域後，也可能在遠端完成最後解析。因此，兩次解析不一定使用相同的伺服器，結果也可能不同。疑難排解時，請記錄查詢發生的位置、查詢網域與回傳位址；不要只根據系統內建查詢工具的結果，就推斷核心取得了相同答案。

依查詢用途選擇伺服器

以下展示一個 DNS 物件片段：文件範例網域優先使用指定解析器，其他查詢則可使用另一台解析器。範例中的位址是公開解析服務的位址，使用前應確認目前網路可以連線，並了解這些服務會收到相應的查詢。此片段用於說明 servers 的物件與字串寫法，不代表適用於所有地區與網路，也不保證查詢一定經由代理出口送出。

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["domain:example.com"],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

domains 用於指定伺服器優先處理的網域範圍，不代表永遠只會使用該伺服器。查詢失敗後的回退行為也會受到全域回退設定與個別伺服器選項影響。skipFallback 常用來避免該伺服器參與不相關網域的回退查詢，而不是保證符合條件的網域絕對只由它解析。若要嚴格隔離解析路徑，應一併核對目前核心的回退規則，並透過日誌或可觀察的查詢紀錄驗證。

了解回傳位址篩選與位址族

expectIPs 用來限制預期的回應位址範圍。它篩選的是解析結果，不會自動將連線送往特定出口。預期範圍設得太窄，可能會拒絕正常的內容傳遞網路位址；若使用依賴分類資源的寫法，也要確認資源確實存在。解析失敗不一定代表伺服器沒有回應，也可能是回應不符合篩選條件。先移除篩選進行比較，再決定是否需要更精確的範圍，不要直接判定目標網域已失效。

queryStrategy 控制查詢位址族的策略，常見選項包括同時查詢 IPv4 與 IPv6，或只查詢其中一種。裝置有 IPv6 位址，不代表通往所有目標的 IPv6 路徑都可用；反過來，只查詢 IPv4 也可能掩蓋部分網路環境的實際能力。選擇前先測試目前網路，再確認出口是否支援。不要為了排除一次偶發逾時，就永久停用整個位址族而不記錄原因。

hosts 可在核心解析器中提供靜態對應，但不是對所有系統應用程式生效的全域主機表。靜態對應會略過正常解析更新，適合受控測試或明確的本機需求，不適合長期固定經常變動的公共服務位址。填寫後還要考慮 TLS 仍會以哪個名稱驗證，以及路由是否會依對應後的位址重新比對。靜態位址可以連線，不代表原本的解析服務已恢復。

設定加密 DNS 時，也要考慮引導解析與連線路徑。若解析服務本身使用網域，必須先解決如何取得服務位址；若這一步又依賴同一個服務，就可能形成啟動迴圈。不同核心對查詢協定、直連方式及路由整合的語法各有差異，不要只替換位址前綴就認定分流已完成。先用簡單解析建立基準，再分別驗證解析服務是否可達，以及目標網域解析結果是否正確。

最後清除快取再比較修改結果。應用程式快取、系統快取、核心快取及仍在使用的連線，都可能保留舊結果。重新啟動一個元件不一定會清除其他元件的狀態。建議固定一個測試網域，記錄修改前後的位址族、回傳位址與實際出口；若要進一步了解中國大陸與境外網域的分組解析，請閱讀DNS 分流解析設定筆記，不要將解析分組直接等同於連線分流。

07 / policy 策略與執行狀態

先保留預設值，再分析逾時問題

policy 用來控制部分連線生命週期與統計行為，不是自動加速功能。先保留預設策略執行；只有日誌與重現步驟能指向特定時間條件時，才考慮調整。網路速度慢、伺服器回應遲緩或應用程式暫停傳送，都可能呈現等待狀態，但原因各不相同。把所有逾時值一併調大，可能只是讓失敗更晚發生；全部調小，則可能讓原本可維持的閒置連線提早結束。

策略通常依使用者等級組織。levels 物件中的鍵代表等級編號，對應協定使用者的等級設定；它不是節點排序，也不是用戶端視窗中的群組編號。未明確指定時，常見情況會使用預設等級。若設定中有多位使用者或不同入口，先確認實際連線屬於哪個等級，再判斷自訂策略是否會套用。只新增一個未被引用的等級物件，通常不會改變目前觀察到的連線。

依連線階段理解時間欄位

以下是策略物件範例，時間欄位以秒為單位，緩衝欄位以 KB 為單位。這些數值用來說明欄位之間的關係，不是適用於所有裝置的最佳化建議。部分欄位的適用範圍與核心實作有關，尤其涉及不同協定與緩衝管理時，應以目前核心的行為為準。將片段併入設定後，先確認能否正常啟動，再用相同應用程式與操作流程比較；不要同時更換出口。

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

handshake 限制相應連線在交握階段可等待的時間。它不是網頁完整載入時間，也不負責限制應用程式下載檔案所需的時間。若連線總是在建立前失敗，先檢查位址、連接埠與傳輸協商，再判斷是否確實需要延長交握等待時間。基本參數錯誤時，延長等待只會讓使用者更晚看到失敗，無法讓不相容的協定變成可用連線。

connIdle 表示連線閒置時間的限制。推播、聊天或遠端工作階段可能長時間沒有明顯的資料傳輸，閒置限制設得太短會讓應用程式不斷重新連線；反之，設得太長也會讓失去用途的連線保留更久。請區分應用程式層心跳、底層網路保活與核心策略：它們位於不同層次，某一層啟用保活，不代表其他層也會認定連線仍然有效。

uplinkOnly 與 downlinkOnly 控制連線一側結束後，另一方向還能維持多久。它們不是上傳與下載限速。某些應用程式會先結束請求傳送，再等待較長時間以接收回應；單向等待設得太短，可能造成回應遭到截斷。若遇到「請求已送出但結果中斷」，應配合日誌時間軸判斷，不要因欄位名稱含有上行、下行，就將數值解讀成頻寬。

緩衝與統計設定都要搭配理解

bufferSize 會影響相關連線的緩衝設定。增加緩衝不等於直接提高線路頻寬，在多連線情境下還可能增加記憶體負擔。尤其在 Android 裝置上，程序遭系統終止、背景執行受限及緩衝設定過大，可能呈現相似的表面現象，不能只看最後一次斷線。先觀察系統資源與用戶端狀態，再考慮是否需要調整；不要把不明確的效能建議當成適用於所有裝置的固定值。

啟用統計開關，不代表會自動產生可檢視的報表。核心統計通常還需要統計模組、查詢介面與用戶端讀取機制配合；用戶端介面顯示的流量也可能來自其他計算方式。啟用前先確認是否有元件會實際使用這些資料，不要為了讓設定看起來完整而加入不需要的介面。統計結果只能代表相應計算方式下的資料量，不能據此推斷實際傳輸量、回應時間或遠端服務品質。

修改策略後，應一併記錄啟動日誌、應用程式行為與發生時間。若整個用戶端程序消失，優先檢查程序是否結束及系統限制，而不是繼續放寬連線逾時。桌面版執行環境、解壓縮路徑與設定讀取錯誤，以及 Android 版權限與背景限制，都屬於另一條排查流程；可搭配啟動閃退疑難排解區分。連線策略只作用於執行中的連線，無法修復尚未正常啟動的核心。

08 / 設定驗證與疑難排解順序

分開驗證啟動成功與存取成功

先儲存修改，再讓用戶端重新載入相應設定。確認介面仍選取預期的設定，並檢查日誌中的實際核心是否符合預期。用戶端顯示啟動按鈕處於執行狀態，只能表示某個啟動流程已執行，不能取代對監聽、路由與遠端存取的驗證。自訂檔案存在磁碟上，也不代表它就是目前正在使用的檔案。若實際行為與內容完全不符，先回頭確認設定來源，避免繼續修改未被讀取的檔案。

第一步檢查載入狀態。語法錯誤、欄位型別錯誤、未知協定及分類資源缺漏，通常會在開始處理業務流量前發生。將日誌中的第一條相關錯誤對照最近的修改，不要只看最後出現的程序結束提示。修正一個架構錯誤後可能會顯示下一個錯誤，這不代表修正無效。每次只處理目前明確的問題，確認通過啟動階段後，再進行連線測試。

沿著請求路徑逐段縮小範圍

第二步檢查入口。讓一個明確支援代理設定的應用程式送出請求，核對位址、連接埠與協定，並觀察核心是否收到連線。若沒有入口紀錄，先檢查應用程式本身的代理選項與系統代理涵蓋範圍。有些程式只在啟動時讀取系統設定，須關閉舊連線或重新啟動應用程式；另一些程式則完全不使用系統代理。尚未確認請求進入核心前，不要將失敗歸因於出口驗證。

第三步檢查路由與解析。先確認目標是以網域還是 IP 的形式傳入，再依序找出可能命中的規則，最後核對出口標籤。若日誌中的目標資訊不足，可在受控測試期間暫時提高日誌詳細程度，測試完成後再恢復。詳細日誌可能包含存取網域、連線位址與本機路徑，分享前請刪除與問題無關的資訊。日誌層級會影響可觀察性，不會自動改變路由結果。

第四步檢查出口交握。區分連線遭拒、等待逾時、憑證驗證失敗與使用者驗證失敗，這些情況指向不同環節。連線遭拒時，通常先檢查目標連接埠與服務狀態；逾時則要考慮網路路徑與防火牆；憑證錯誤先檢查名稱與時間；驗證錯誤則核對連線資料。不要遇到任何錯誤都一律更換 DNS。逐項說明請參閱執行日誌解讀。

採用可控回退，不要連續疊加修補

準備兩份有清楚紀錄的設定：一份保留正常基準，另一份只加入目前要驗證的修改。測試時使用相同的應用程式、目標與連線方式，避免一邊更換伺服器、一邊調整路由，再根據結果猜測哪個變因造成影響。若新增規則導致部分連線異常，先撤回該規則確認是否恢復；恢復後再縮小規則條件，比繼續增加例外更容易找出根本原因。

合併物件時也要留意，陣列不是一般文字段落。將兩個完整的 routing 物件直接並排貼上，會造成重複鍵或架構錯誤；用第二份 outbounds 覆蓋第一份，則可能刪除仍被路由引用的出口。正確做法是先決定要保留哪個父物件，再逐項合併需要的陣列項目，並檢查標籤是否唯一、引用關係及預設出口順序。即使某些解析器接受重複鍵，也不應依賴其覆寫行為。

驗證完成後，將穩定設定移至可永久保存的位置，並再次測試用戶端重新啟動、切換設定及更新訂閱後的結果。若重新啟動後恢復舊值，表示修改仍留在自動產生的檔案中，應回到用戶端支援的設定入口。儲存最終設定時，附上簡短說明：使用哪個核心、修改了哪些層、依賴哪些分類資源，以及如何還原。無須記錄不相關的裝置細節，也不要將驗證資料寫入公開筆記。