JSON 設定參考

JSON 結構與處理流程

先分清客戶端與核心

v2rayN、v2rayNG、v2flyNG 提供設定管理介面；核心負責監聽連接埠、處理協定及轉送連線。介面中的節點資料通常不是完整的核心設定。客戶端會將節點、路由範本、本機監聽設定與執行選項組合成執行檔案。因此，修改暫存產生的 JSON，不代表下次啟動時修改內容仍會保留。閱讀前請先確認目前檢視的是節點資料、自訂設定，還是客戶端產生的執行設定。

V2Fly 與 Xray 的設定源自相近架構，但不能視為完全相同的介面。協定支援、傳輸欄位、DNS 擴充功能與預設行為都可能不同。本文優先介紹兩者常見的結構，遇到特定協定時會說明適用範圍。請勿截取不同核心的設定範例拼湊，再靠反覆刪除錯誤欄位讓它啟動；啟動成功只代表設定已被接受，不代表連線路徑符合預期。

最小本機測試設定

以下設定會監聽本機迴送位址，提供 SOCKS 入站，並將收到的連線直接連至目標。此設定適合驗證結構、連接埠與應用程式的代理設定，不適合測試遠端節點。執行前請確認連接埠未被占用；若客戶端已產生相同的監聽設定，請使用客戶端支援的自訂設定入口單獨測試，避免兩個程序競用同一連接埠。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-local",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

連線處理流程可簡述為：應用程式連入入站、入站辨識目標、路由選擇出站、出站建立連線。DNS 參與網域名稱解析，但並非所有要求都會經過設定中的內建 DNS；日誌與策略則分別用於記錄問題及控制連線行為。釐清各自職責，才能判斷錯誤出在入口、路由判斷或出口，而不是把所有無法連線的情況都歸咎於節點。

物件、陣列與資料型別

最上層是一個物件。inbounds 與 outbounds 是陣列，因為可以同時設定多個入口和出口；routing、dns、policy 通常是物件。陣列順序可能影響實際行為，例如路由規則的先後順序；物件欄位順序通常不會決定執行順序。調整最上層設定區段的位置，不會讓 DNS 比路由更早或更晚執行。

嚴格 JSON 的欄位名稱與字串必須用雙引號括住，不允許尾隨逗號或註解。連接埠等數值不應任意改成字串，布林值則應寫成 true 或 false。不同載入器可能容許部分寬鬆語法，但為確保設定可攜，建議遵循嚴格 JSON 格式。尤其要避免同一物件內出現重複欄位：部分剖析器只會保留最後一個值，導致檔案看似成功載入，前面的設定卻已被覆寫。

tag 是設定內部的引用名稱，不是協定類型。出站標籤可以是 direct，也可以使用其他名稱；路由必須引用完全相同的字串。大小寫、空格或拼字不同，都可能導致引用失敗。建議先列出入站與出站標籤，再撰寫規則。每次只修改一個設定區段，並保留可還原的副本，比一次替換整份執行檔案更容易判斷問題來源。

inbounds 入站設定

監聽位址決定入口範圍

入站定義核心如何接收連線，不會決定連線最後要前往哪台伺服器。listen 是綁定的本機位址，port 是監聽連接埠，protocol 則指定入口協定。若只供目前裝置使用，建議優先綁定 127.0.0.1。這與遠端服務位址無關，不能把訂閱中的伺服器網域填在這裡；這會嘗試綁定不屬於本機的位址，通常會導致監聽失敗。

綁定 0.0.0.0 會監聽本機所有 IPv4 網路介面，可能讓同一個網路中的其他裝置也能連入。是否可連線仍取決於防火牆與網路隔離，但不能把防火牆當成設定驗證機制。若確實需要在區域網路分享，應限制允許的來源、設定適當的驗證方式，並確認監聽介面。排查連線失敗時，請勿先將所有入口開放至全部網卡，以免擴大可存取範圍。

SOCKS 與 HTTP 入口

SOCKS 入站適合支援 SOCKS 代理的應用程式，HTTP 入站則適合使用 HTTP 代理設定的應用程式。兩者的位址都可能是本機位址，但協定不能混用。若應用程式設定的是 HTTP 代理，卻連到 SOCKS 監聽連接埠，TCP 連線可能已經建立，後續交握仍會失敗。這時通常不必更換遠端節點，應先確認應用程式選擇的代理類型是否與入口協定一致。

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

這段 HTTP 入站可以與第一章的 SOCKS 入站並存，但必須合併至同一個 inbounds 陣列，不能在最上層再新增同名欄位。兩個入口應使用不同的連接埠。客戶端介面可能會自動管理這些連接埠，此時應優先透過介面修改，而不是只修改暫存檔案。應用程式連接埠、客戶端設定與執行日誌中的實際監聽位置，彼此都應相符。

SOCKS 設定中的 udp: true 只表示此入口允許相應的 UDP 轉送能力，不代表所有應用程式的 UDP 流量都會自動進入核心。應用程式必須支援相應的代理方式，後續出站與遠端服務也必須支援。傳統的系統 HTTP 代理不會接管所有 UDP 流量。排查語音或其他 UDP 應用程式的問題時，應先確認流量是否有進入核心，而不只是檢查入口是否包含這個布林值。

嗅探與路由的適用範圍

sniffing 可嘗試從支援的協定交握中辨識網域名稱，常見類型包括 HTTP 與 TLS。它不是通用的流量內容解析工具，也無法保證每條連線都能取得網域名稱。若應用程式直接連線至 IP，且交握內容沒有可辨識的主機名稱，網域規則仍可能無法比對。因此，啟用嗅探不保證網域分流一定成功，應搭配存取日誌確認實際辨識結果。

部分核心支援讓嗅探結果只用於路由，而不取代實際連線目標；相關欄位與行為應參考目前核心的規範。通用範例不包含這些擴充功能。需要使用時，請先確認目標是補充路由依據，還是變更連線目的地。混淆兩者可能導致日誌顯示網域比對正確，實際解析或連線目標卻發生變化，尤其容易影響本機服務與特定 IP 位址的連線。

outbounds 出站設定

出口與預設選擇

出站設定描述核心如何處理已接收的連線：可以直接連至目標、透過遠端代理服務轉送，或主動丟棄。若沒有規則符合，通常會使用 outbounds 陣列中的第一個出站。因此，第一個物件不只是排列位置，也是預設行為的一部分。將直連物件移至首位，可能會讓原本未涵蓋的連線改為直接連線。

tag 為每個出口設定可供引用的名稱，protocol 決定使用哪種出站協定，settings 的結構則會依協定而異。路由中的 outboundTag 引用的是標籤，不是協定名稱。同一份設定可以有多個使用相同協定的出站，但標籤應保持唯一，否則無法清楚表示規則引用，也可能與客戶端的產生邏輯衝突，導致原有物件被覆寫。

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

freedom 表示由目前裝置直接連線至目標，不能據此推斷要求一定會使用哪台 DNS。blackhole 表示丟棄符合條件的連線；應用程式可能因此逾時或連線失敗。單獨使用上述片段時，預設出口是直連，只有規則選中阻擋出口時才會使用它。設定中有某個出口，不代表流量會自動經過該出口；還必須檢查預設順序或路由引用。

遠端節點參數無法彼此推算

VMess、VLESS、Trojan 等代理出站必須與伺服器端設定相符。伺服器位址、連接埠、身分資訊、傳輸方式與安全層各自代表不同設定，不能依某個欄位的值推測其他欄位。位址正確但傳輸路徑不同，或驗證資訊正確但安全層不符，都會導致連線失敗。實際使用的節點建議透過客戶端匯入有效連結或訂閱，不要根據網頁片段自行填入一組未知參數。

常見代理出站也會用 streamSettings 描述傳輸方式與安全層。協定說明「如何封裝代理要求」，傳輸說明「如何承載位元組流」，安全層則說明「如何保護或驗證連線」。這三者並非可任意組合的開關。伺服器端只接受特定組合時，客戶端必須使用相符設定；把安全欄位全部開啟不會自動增加相容性，反而可能產生伺服器無法識別的交握內容。

連線位址與 TLS 伺服器名稱也應分開理解。前者用於建立網路連線，後者參與伺服器身分驗證與交握；兩者可以不同，但必須符合服務設定與憑證限制。若憑證驗證失敗，請檢查名稱、裝置時間與伺服器憑證鏈。不要把略過驗證當成一般修復方式，因為這會改變身分驗證條件，也常掩蓋伺服器名稱填寫錯誤的問題。

核心與出口的支援能力

v2rayNG 使用 Xray 核心，v2flyNG 則是 V2Fly 核心客戶端；v2rayN 實際使用的核心應以目前設定與執行日誌為準。分享連結能被介面辨識，不代表目前選用的核心支援所有欄位。遇到未知協定或不支援的傳輸參數時，請先確認核心系列，再判斷是否需要改用相符的設定；不能只修改協定名稱來轉換節點。

出站設定也可能涉及 UDP 轉送、多路複用、連線複用與通訊端選項。這些功能取決於核心、協定與伺服器端的組合，不適合一開始就在最小設定中全部啟用。排錯時請先使用客戶端產生的基本出站設定，確認單一連線可正常使用，再逐項加入擴充功能。否則單次要求失敗可能同時涉及入口 UDP、遠端協定與底層網路，日誌也難以判斷是哪一層先出問題。

管理多個節點時，應區分客戶端的「目前節點」與核心設定中的「多個出站」。切換介面選項，可能會重新產生唯一的代理出口，也可能修改某個已被引用的出口，實際行為由客戶端決定。訂閱更新後，請重新確認標籤與規則引用是否仍存在。如需了解核心之間的關係，可接著閱讀Project V、V2Fly 與 Xray 分支沿革，再選擇合適的客戶端。

routing 路由規則

依序比對與條件關係

routing.rules 是有順序的規則陣列。核心會依序檢查，找到符合條件的規則後選擇對應出口；沒有符合條件時則使用預設出站。請將明確且範圍較小的條件放在前面，兜底條件放在後面。若第一條規則已涵蓋某個入口的所有 TCP 與 UDP 流量，後面針對同一入口的網域規則就不會生效，即使條件更精確，也不會自動取得較高優先順序。

同一條規則中的不同條件欄位通常必須同時符合；同一欄位陣列中的多個項目通常代表符合其中一項即可。例如同時指定 inboundTag 與 domain，表示連線必須由指定入口接收，且目標網域也必須符合；不是入口或網域其中一項符合即可。若要表達兩種獨立情況，應拆成兩條規則，而非將所有條件堆在同一個物件中。

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

此片段依賴第三章設定的 direct 與 block。第一條規則處理列出的 IPv4 位址範圍，第二條只會阻擋完全相符的網域。這不是完整的內網位址清單，也未涵蓋所有 IPv6 情境。範例使用 AsIs，因此不能假設尚未解析的內網網域會因最終位址落在這些網段而自動符合第一條規則；目標的呈現形式也是規則條件的一部分。

網域規則與資源檔案

full:example.com 表示完全相符的網域；domain:example.com 則可比對該網域及其子網域。請勿將完整網址填入網域欄位，協定前綴、路徑與查詢參數都不屬於網域。若要同時處理根網域與子網域，應明確選擇比對語法。正規表示式適用於確實需要模式比對的情況；一般網域使用明確前綴較容易檢查，也能降低意外擴大比對範圍的風險。

geosite: 與 geoip: 用來引用分類資源，不是核心能自動理解的任意中文分類名稱。資源檔案必須存在，指定的類別也必須確實包含在目前檔案中；客戶端還可能使用不同來源的規則資源。若載入資源失敗，請先檢查檔案位置與類別拼字。不要透過修改出站位址來修復，因為在建立遠端連線之前，規則資源載入就可能已經失敗。

domainStrategy 的解析範圍

AsIs 會盡可能使用原始目標進行路由比對；IPIfNonMatch 會在網域未符合時嘗試解析，再檢查 IP 條件；IPOnDemand 則可能在比對過程需要 IP 條件時觸發解析。後兩者會改變路由階段對 DNS 的需求。這些設定不等於「全域代理」或「直連模式」，也不會直接決定遠端代理伺服器要在哪裡解析最終目標。

客戶端介面中的路由模式通常對應一整套規則範本，而不是單一 domainStrategy 值。切換模式可能會替換規則順序、預設出站或分類資源。檢查分流效果時，應查看最終產生的 routing，並記錄目標網域、入口標籤、符合的出口與規則位置。單看瀏覽器能否開啟頁面，無法分辨是預設出口生效，還是特定規則符合。

建議建立簡短的測試清單，分別驗證完全相符的網域、子網域、直接 IP 與本機服務，每次只修改一條規則。若存取日誌只顯示 IP，請進一步確認應用程式是否在流量進入核心前就完成解析，以及入口是否提供網域資訊。DNS 與路由需要搭配使用，但兩者無法互相取代。更多解析分流方法請見V2Ray DNS 分流設定詳解。

dns 解析設定

先確認是哪一層發出查詢

同一次連線可能涉及多個解析流程：系統解析應用程式的目標、核心為路由解析網域、出站解析遠端伺服器位址，以及遠端服務解析最終目的地。設定 dns 區段，只會定義核心內的解析器行為，不會自動接管系統與所有應用程式的查詢。排查時必須先確認「哪個程序查詢了哪個名稱」，否則很容易把瀏覽器取得的解析結果誤認為核心 DNS 的結果。

入口收到網域名稱時，核心仍可能直接將網域交給代理出站；入口只收到 IP 時，DNS 網域分類通常沒有可用的原始名稱。路由策略、直連出口的解析選項與客戶端網路接管方式，都會影響實際查詢路徑。因此，修改 DNS 位址後若看不出存取路徑有變化，不一定代表設定失效，也可能是這筆要求根本沒有使用內建 DNS。

servers、hosts 與查詢類型

{
  "dns": {
    "hosts": {
      "full:example.com": "192.0.2.1"
    },
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIPv4"
  }
}

此片段用來說明靜態對應與系統解析入口。192.0.2.1 是文件範例位址，不是可用的網站位址；保留這筆對應時，不能據此驗證依賴內建 DNS 的相關連線是否正常。localhost 表示使用系統解析機制，不代表會將要求傳送至本機任意 UDP 連接埠。實際使用時請刪除示範對應，再選擇符合環境的解析方案。

hosts 可固定特定名稱的解析結果，適合用於問題定位或已知的內部名稱需求，但也會略過該名稱原本的動態解析。服務位址變更後，舊對應可能長期指向錯誤位置。若某個網域始終解析至相同的異常位址，請一併檢查核心對應、系統 hosts 與應用程式快取，而不只是更新訂閱。這些屬於不同層，修改其中一層不會自動清除其他層。

queryStrategy 控制內建查詢使用的位址系列，例如 UseIPv4、UseIPv6 或 UseIP。這不等於修改系統網路協定，也不保證所有連線都只使用某個位址系列。若裝置有 IPv6 位址但連線路徑不可用，請分別測試解析與連線；取得 AAAA 記錄只代表解析有結果，不表示一定能連線至該位址。

依網域選擇解析器

servers 陣列可包含伺服器物件，常見欄位有 address、domains 與 expectIPs。domains 用來指定優先交由該伺服器處理的網域集合；expectIPs 則用來限制可接受的結果範圍。後者不是為網域設定靜態位址，也不是出站規則；結果遭篩除後是否會改用其他伺服器，還取決於其他伺服器設定與目前核心的回退設定。

請勿為範圍很廣的網域集合套用過於嚴格的預期 IP 條件。內容傳遞網路、雙堆疊部署與服務遷移，都可能讓合法的解析結果改變。過度嚴格的篩選可能將正常回應變成解析失敗，表面看來卻像是遠端節點無法使用。設定前應確認分類規則與實際位址分布；設定後記錄哪些結果被接受或丟棄。若缺乏相關資訊，建議先用範圍較小的指定規則進行測試。

一般 DNS、加密 DNS 與本機系統解析的連線路徑可能不同；部分位址格式會略過一般出站處理，部分則會參與核心路由。具體行為應依目前核心的伺服器位址規範確認，不能只憑「加密」二字就推斷一定會經過代理。若解析器連線需要代理，而代理伺服器名稱又依賴該解析器才能解析，就會形成啟動相依迴圈；應先規劃獨立的伺服器名稱解析路徑。

policy 連線與統計策略

級別不是路由優先順序

policy 用來設定連線生命週期與部分統計行為，不負責選擇節點。levels 下的鍵是使用者級別編號，JSON 物件的鍵仍須使用字串。協定使用者或相應的入站設定可以引用使用者級別，但實際引用欄位會因協定而異。若沒有指定級別，通常會使用預設級別；級別數字越大不代表速度越快，也不能取代路由規則順序。

設定策略前，應先確認實際使用者。如果入口協定沒有對應的使用者設定，或客戶端產生的檔案沒有寫入預期級別，自訂的其他級別可能完全不會被引用。請在最終執行檔案中檢查相關欄位，而不是只看到 levels 物件存在就認定設定已生效。對單人使用的本機客戶端而言，明確指定預設級別通常比建立多個未被引用的級別更容易維護。

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

這些時間值用來示範以秒為單位的常見策略寫法，不是通用的最佳化建議。不同核心的預設值與支援項目應分別確認。遇到連線中斷時，不要先照抄較大的逾時值；應判斷是交握未完成、連線長時間閒置，還是某個方向已經關閉。策略只在對應階段生效，無法修復驗證錯誤、憑證錯誤或遠端服務未監聽等問題。

四種逾時值對應的階段

handshake 限制連線交握階段可等待的時間。網路建立較慢時，限制過短可能讓原本可完成的交握提早終止；但無限制地延長，只會讓失敗等待更久。connIdle 用於判斷連線閒置時間，常見用途是清除長時間沒有活動的連線。它與應用程式自己的要求逾時、遠端反向代理的逾時不是同一個計時器，實際中斷可能由任何一層先觸發。

uplinkOnly 與 downlinkOnly 涉及連線只剩單向活動時的保留時間，可能影響下載、長連線與半關閉情境。不過，名稱中的上行與下行應依核心處理方向理解，不宜直接解讀為「加速上傳」或「加速下載」。若應用程式送出資料後仍在等待較長時間的回應，過短的單向逾時可能提早結束連線，應搭配應用程式協定與日誌分析。

若要判斷是否真的需要修改策略，可觀察問題是否總是在相近的閒置時間後穩定發生，以及恢復活動是否能避免中斷。如果連線一開始就失敗，應優先檢查協定與驗證；若只有切換網路後才失敗，則先檢查連線重建與系統網路狀態。把所有故障都歸類為逾時，可能掩蓋真正原因，還會讓無效連線占用資源更久。

統計開關不等於統計介面

policy.system 中的入站、出站流量統計開關用來控制相應計數，使用者級別也可能提供使用者統計選項。啟用這些欄位不代表介面會自動顯示流量圖，更不代表已對外提供查詢介面。客戶端仍須設定統計模組、查詢服務與標籤關聯。若只是想在客戶端顯示流量，請先檢查客戶端內建選項，避免手動建立重複介面。

若統計服務與管理介面需要監聽位址，應限制在適當的本機範圍，不要與區域網路入站一同對外開放。統計標籤也應對應實際入口與出口，否則可能得到空白計數或錯誤歸屬。在設定中加入不明統計欄位，不會讓不支援此功能的核心自動相容；若出現欄位或服務載入錯誤，請先還原基本策略，再逐項確認擴充功能是否受支援。

驗證策略時，應使用可重現的單一連線情境，而不是憑開啟網頁的感受判斷。記錄修改前後的等待階段、中斷原因與應用程式表現，再決定要保留哪些調整。重新啟動核心通常會影響現有連線與記憶體中的計數，前後比較時應維持一致的起始條件。日常使用客戶端時，保留產生器提供的合理預設值，只修改有證據顯示需要調整的欄位，通常更利於後續升級與排錯。

客戶端與設定接管

找出持續生效的設定來源

圖形化客戶端通常會分別儲存節點資料、訂閱群組、路由範本與介面設定，再依目前選項產生核心執行檔案。這些並不是同一份資料。更新訂閱主要會變更遠端節點資料，切換路由模式主要會變更規則，系統代理則會影響應用程式入口。修改前請先確認需求屬於哪個層級，避免為了調整瀏覽器入口而修改遠端出站，或為了調整路由而重新匯入所有訂閱。

在 v2rayN 中，建議透過相應的本機監聽、路由設定與核心設定入口完成一般調整；需要完整自訂 JSON 時，再使用客戶端提供的自訂設定功能。選單名稱可能依介面版本而異，請依功能確認，不要照抄其他畫面截圖中的檔案路徑。尤其不要只修改正在執行的暫存設定，因為重新選擇節點或重新啟動後，產生器可能會立即覆寫內容。

匯入、儲存與執行是不同步驟

客戶端接受檔案，可能只代表格式或連結已辨識；還必須選取對應設定、啟動核心並檢查執行日誌。儲存後若沒有重新載入，舊程序仍可能使用舊內容。驗證時應查看啟動記錄與實際監聽資訊，不能只看清單中的名稱已變更。若客戶端支援預覽產生的設定，請在啟動前後比對重要欄位，確認這次執行使用了預期的入口標籤與出站引用。

在 Android 上，v2rayNG 與 v2flyNG 通常透過系統授權建立虛擬網路入口來接管網路；應用程式選擇與背景執行設定也會影響哪些流量進入核心。桌面系統代理的行為不能直接套用於此情境。手動新增 SOCKS 入站不等於取代客戶端的網路接管流程；反過來說，開啟系統接管也不代表自訂檔案中的每個入口都會被使用。

在三款客戶端之間移轉時，應分別判斷節點資料與完整設定是否可移轉。分享連結通常只包含節點資訊，不一定包含本機連接埠、DNS、路由資源與策略。即使目標核心支援完整 JSON 中的欄位，客戶端也可能要求特定標籤、入口或執行方式。移轉後應重新驗證入口、預設出口、DNS 與規則資源，不能只確認節點清單中已出現項目。

安全合併設定的順序

合併片段時，請以目前可正常執行的設定為基礎，先建立備份，再替換一個完整的設定區段。陣列應合併項目，物件則應合併欄位，不能直接將兩份最上層物件貼在一起。若標籤衝突，應先重新命名，再更新所有引用。特別是路由規則指向新標籤時，必須先確認出站已存在；若先啟用規則再補上出口，核心可能在載入階段就拒絕啟動。

訂閱網址與節點驗證資訊都屬於敏感資料。儲存設定副本、提交畫面截圖或向他人求助時，請移除位址中的存取參數、身分欄位與訂閱連結。日誌也可能包含伺服器位址或存取目標，分享前應先檢查。本文範例只有本機入口與文件位址，不能視為遠端服務資訊；實際驗證內容應從服務設定取得，不要在公開文件中填入真實資料。

系統代理與核心執行應分開驗證。核心正常運作時，若系統代理仍指向舊連接埠，應用程式仍會連線失敗；退出客戶端後，若系統代理未還原，應用程式也可能繼續連到已不存在的入口。反之，部分應用程式會忽略系統代理，需要個別設定。若只有某個應用程式無法連線，請先檢查該應用程式的入口，不要立刻替換整份核心設定檔。

更新客戶端或切換核心後，請保留原設定副本，並重新確認擴充欄位與產生邏輯。介面保留舊選項，不代表新核心仍會以相同方式解讀。基本使用流程可返回快速入門指南；訂閱相關問題請參閱訂閱更新與自動更新設定，避免將訂閱取得失敗與核心轉送失敗混為一談。

設定驗證與日誌排錯

依載入、監聽、連線分層檢查

應從最早發生錯誤的階段開始驗證。第一層是 JSON 能否剖析，第二層是核心是否接受欄位與標籤，第三層是入口能否監聽，第四層是應用程式流量能否進入，最後才是路由、解析與遠端連線。若日誌已顯示連接埠綁定失敗，繼續更換 DNS 毫無幫助；若核心根本沒有啟動，瀏覽器連線失敗也不能用來判斷出站協定是否正確。

先從客戶端日誌確認選用的核心及本次啟動結果，再查看最早出現的錯誤。後續的「程序結束」或「連線遭拒」可能只是前一個錯誤造成的結果。閱讀日誌時應保留時間順序，並區分啟動錯誤與存取錯誤。相同視窗可能混有上一輪的執行記錄；修改後應明確確認新一輪啟動的起點，避免將舊錯誤誤認為修復尚未生效。

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

需要觀察連線過程時，可以暫時將日誌級別設為 info；只有必要時才短暫啟用更詳細的除錯級別。日誌設定應合併至原有的 log 物件，避免重複宣告。存取日誌與錯誤日誌的輸出方式可能由客戶端管理，不要隨意指定沒有寫入權限的路徑。排錯完成後請恢復合適的級別，以減少持續記錄存取目標及產生大量檔案。

依錯誤類型定位設定區段

剖析錯誤通常與引號、逗號、括號及資料型別有關。編輯器標示的位置可能是發現錯誤的位置，不一定是錯誤起點；請往前檢查上一個項目是否缺少分隔符號。未知協定、未知欄位或無效列舉值則較可能是核心相容性問題。請先確認目前使用的核心，不要擅自把欄位名稱改成看似相近的寫法，除非規範明確說明兩者的對應關係。

監聽失敗時，請檢查連接埠是否被其他程序占用、綁定位址是否屬於本機，以及客戶端是否已建立相同入口。路由載入失敗時，請檢查目標標籤是否存在、資源檔案是否可讀，以及類別名稱是否有效。DNS 失敗則需確認查詢目標、伺服器可連線性與回退條件。這些問題發生在不同階段，逐項處理比直接重新安裝客戶端更能保留排錯線索。

建立可還原的測試流程

準備一份能穩定啟動的基本設定作為基準，再逐項加入入站擴充功能、代理出口、規則、DNS 與策略。每加入一個區段，先確認核心能啟動，再執行相應測試。使用直連基準只能驗證本機入口與基本網路，不能證明遠端節點可用；透過代理成功連線也不能證明分流規則正確，因為連線可能使用了預設出口。測試結論應限於實際驗證的範圍。

記錄每次修改的欄位、預期結果、實際日誌與還原方式。測試路由時，至少應包含網域與直接 IP 兩種目標；測試 DNS 時，應區分位址系列與快取；測試策略時，則應區分連線建立與閒置階段。若結果不如預期，請先還原至上一份基準，確認問題是否隨修改出現，再逐步縮小範圍；不要在已損壞的設定上不斷疊加修補。

設定檔是由多個職責明確的物件組成，不是越長就代表功能越完整。保留用途清楚的欄位，刪除確認不再需要的測試設定，並將由客戶端負責產生的部分留在正確入口管理。常見情況請參閱常見問題；啟動錯誤的閱讀順序請見核心啟動失敗與日誌排查。完成排錯後，請儲存最終可正常執行的副本，再恢復日常使用。