config.json 設定欄位參考

JSON 結構總覽

V2Ray 生態系中的設定檔描述一條完整的資料處理路徑：應用程式連至本機監聽連接埠，由入站將請求交給核心，再由路由依據目標與來源選擇出站，最後透過出站建立實際連線。dns 提供內建解析功能，policy 控制部分連線階段的等待時間。常見檔名是 config.json，但真正決定設定意義的是檔案內容及載入它的核心，而非檔名。閱讀前請先確認使用的是 Xray 還是 V2Fly，再比對該核心支援的設定格式。

物件、陣列與欄位型別

頂層是一個 JSON 物件。inbounds 和 outbounds 是陣列，因為同一個程序可以提供多個監聽入口，也能設定多個出口。routing、dns 和 policy 則是物件，各自存放規則、伺服器或策略對應資料。欄位名稱與字串須使用英文雙引號；連接埠通常使用數字，開關則使用布林值 true 或 false。數字與字串不能任意互換；路徑、標籤和協定名稱也都必須維持正確拼法。

嚴格 JSON 不接受註解、尾隨逗號或中文引號。部分核心工具可能支援額外的設定讀取功能，但在不同客戶端間移轉時，應維持嚴格 JSON 格式。範例縮排僅供閱讀，不影響執行；括號、逗號和資料型別才會影響解析。檔案能通過 JSON 解析器，只代表語法正確，不能保證協定欄位、出站引用或執行環境都設定無誤。啟動失敗時，先區分語法錯誤與核心設定錯誤，避免同時修改多個層面。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  },
  "dns": {
    "servers": ["localhost"]
  }
}

設定區段之間的引用關係

tag 是設定內部使用的名稱，不是提供給伺服器的認證資訊。路由規則中的 outboundTag 必須指向已存在的出站；inboundTag 則可限定規則只處理特定入口的請求。標籤建議採用簡短且穩定的英文名稱，並在各自的陣列中保持唯一。修改出站標籤時，也必須同步更新所有引用它的規則；否則檔案看似完整，實際連線卻可能無法依預期分流。預設出口通常是出站陣列的第一項，因此排列順序本身也是設定的一部分。

頂層區段的書寫順序不等於處理順序。將 dns 寫在 routing 前面，不代表所有請求都會先經過內建解析；但將某條規則移到陣列前面，確實可能改變比對結果。閱讀設定時，應分清物件欄位順序與陣列元素順序。前者通常只是整理文字，後者則會影響路由及預設出站的選擇。合併設定前，也要確認沒有重複的頂層鍵；重複鍵可能遭讀取器覆寫，不易察覺。

建議先保存一份能正常啟動的基準設定，再依序加入入站、出站、路由、DNS 與策略。每增加一個設定區段，就重新載入並查看記錄。如此可將錯誤範圍鎖定在最近一次變更，而不必在複雜檔案中反覆猜測。圖形客戶端產生的檔案也可能包含輔助入口和內部標籤；閱讀時先整理主要資料路徑，再判斷哪些部分由客戶端自動管理。

inbounds 入站監聽

inbounds 定義核心從哪裡接收流量。本機客戶端常使用 SOCKS 或 HTTP 入口，應用程式透過相應的代理協定連線至該連接埠。入站不等於遠端伺服器，也不負責決定最終使用哪個代理出口。排查時，先確認應用程式是否真的連上這個入口：只有請求已進入核心，後續的路由和出站設定才會生效。瀏覽器使用系統代理，與個別程式自行填入 SOCKS 位址，是兩種不同的接入方式。

監聽位址、連接埠與協定

listen 決定要監聽哪個本機位址。個人裝置上的本機代理，建議優先綁定 127.0.0.1，讓入口只接受本機連線。綁定所有介面會擴大可存取範圍，不應當成解決連線問題的通用方法。port 必須與應用程式設定的連接埠一致，且不能被其他程序占用。protocol 決定客戶端如何與入口溝通；將 HTTP 請求送到 SOCKS 連接埠，通常會造成握手失敗，而不會自動轉換協定。

SOCKS 與 HTTP 入口的差異

SOCKS 入口適合明確支援 SOCKS 代理的應用程式。啟用 settings.udp 只代表入口允許處理 SOCKS UDP 轉送；應用程式也必須使用相應協定，後續出口與遠端鏈路同樣要能承載這類流量。HTTP 入口通常供支援 HTTP 代理或 CONNECT 的應用程式使用，並非通用的 UDP 入口。系統代理開關只會影響遵循系統設定的程式，不能因此推斷裝置上的所有連線都會進入核心。

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

此片段只新增一個 HTTP 入口。若要與前一章的基準設定合併，請將該物件加入既有的 inbounds 陣列，不要再寫一個同名的頂層鍵。連接埠號碼僅為範例，並非所有客戶端的固定值。v2rayN 或 Android 客戶端可能依設定產生不同連接埠，實際操作時請查看客戶端目前使用的設定。修改監聽連接埠後，也要同步調整應用程式的代理設定，否則舊連線仍會嘗試連到原連接埠。

目標識別與接入範圍

sniffing 可依據支援的流量特徵擷取網域名稱，提供更多資訊以利網域路由。這不是解密所有流量的功能，也無法保證能從任意連線還原網域。目標覆寫、僅供路由使用等選項，須分別確認各核心的支援情況。初次排查時，可先沿用客戶端預設的識別設定，確認一般請求能正常進入，再逐步判斷網域資訊是否影響分流，避免混淆入口錯誤與識別行為。

允許區域網路存取時，須一併考慮綁定位址、認證、主機防火牆與可信任的網路範圍。只修改 listen，不代表其他裝置就一定能連線，也不代表這個入口適合公開到網際網路。個人本機使用時，保留迴圈位址監聽通常較容易控管存取範圍。若記錄顯示位址已被占用，先關閉舊客戶端或改用未占用的連接埠；若完全沒有接入記錄，則檢查應用程式的代理位址、代理類型，以及是否啟用了略過本機代理的規則。

TUN 接管與一般 SOCKS、HTTP 監聽屬於不同的接入層。客戶端可透過虛擬網卡將流量交給核心，但虛擬網卡名稱、權限要求與系統路由通常由客戶端管理，不能簡化成一個通用的入站欄位。相關操作請參閱v2rayN TUN 模式設定筆記。閱讀本節時，請先確認目前要排查的是應用程式代理入口，還是虛擬網卡接管鏈路。

outbounds 出站與預設出口

outbounds 存放核心可使用的出口。出口可以直接連線至目標、拒絕連線，或透過遠端代理轉送。路由規則最後選擇的是某個出站標籤，不是訂閱介面上顯示的名稱。客戶端切換節點時，往往會重新產生代理出站的位址與認證參數，因此「選取節點」和「編輯出站 JSON」是同一條路徑上的不同操作層。查看匯出的設定時，請確認所選節點對應哪個出站，以及實際有哪些規則引用它。

協定設定與傳輸設定分層

protocol 指定出口使用的協定，settings 則存放該協定所需的內容。對 VMess 等遠端協定而言，伺服器位址、連接埠、使用者識別碼等參數都必須與伺服器端一致。streamSettings 描述底層傳輸與安全層，例如傳輸方式、是否建立 TLS，以及使用哪個伺服器名稱。協定認證成功與傳輸連線建立成功是不同階段，不能把所有失敗都歸因於節點位址錯誤。

介面顯示的伺服器位址、TLS 伺服器名稱與 HTTP 類傳輸的 Host，可能各有不同用途。伺服器位址用來定位連線端點；TLS 伺服器名稱參與交握與憑證身分判斷；傳輸層 Host 則是相應協定的請求參數。它們有時相同，但不代表必須一律填成相同值。修改時應依據伺服器端提供的連線資料逐項填寫；任意關閉憑證驗證只會掩蓋身分與鏈路問題，並不是合理的常規排錯方式。

直連、拒絕與代理出站

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

此片段使用 freedom 直接連線至目標，並以 blackhole 拒絕分配到該出口的流量。第一個項目是直連，因此沒有命中規則的請求會預設直連。若將拒絕出口移到第一個項目，未命中規則的請求可能都會遭到拒絕。這裡沒有代理出口，因此無法用來測試遠端代理是否可用。加入真實的代理出站時，請先決定預設流量應走代理還是直連，再安排陣列順序或末尾的兜底規則。

核心差異與連線能力

Xray 與 V2Fly 共用部分設定習慣，但欄位並非都能互換。同名功能也可能有不同的取值、預設值或支援條件。尤其是新協定、傳輸、安全層和網域解析策略，應以目前使用的核心支援能力為準。將設定交給另一個核心前，先檢查協定與傳輸，再檢查擴充欄位；不要只因檔名同樣是 config.json，就認定可以直接執行。

UDP 能否透過某個出站，取決於整條鏈路是否都支援。入口須允許 UDP，出站協定須具備相應承載能力，伺服器端也須允許轉送，且網路路徑必須連得通；缺少任何一環都可能失敗。網頁能開啟只代表相關 TCP 請求可用，不代表語音、遊戲或其他 UDP 應用程式也有相同路徑。部分應用程式發生異常時，先確認實際使用的網路協定，再決定要檢查入口、出站還是遠端轉送設定。

首次設定時，建議使用 v2rayN 的節點編輯或訂閱匯入功能產生遠端出站，再參照本節檢視；不建議自行拼湊認證資訊。Android 端的 v2rayNG 與 v2flyNG 對應不同核心選項，相關差異請參閱Xray 與 V2Fly 核心選型筆記。分享診斷資料時，只保留必要欄位與錯誤類型，並遮蔽訂閱網址、使用者識別碼及其他認證內容，避免完整連線參數隨記錄外流。

routing 路由規則與比對順序

routing 決定每個請求要交給哪個出口。它處理的是已進入核心的流量，不能取代作業系統路由，也無法讓忽略代理設定的應用程式自動接入。最常見的結構是 rules 陣列，每條規則會檢查請求的網域、IP、連接埠、網路類型或入站標籤。規則會由前往後依序比對，命中後便執行相應選擇，因此條件過寬的規則可能遮蔽後面的精細規則。

規則條件如何組合

對欄位規則而言，同一清單中的多個候選條件通常代表符合其中一項即可，例如 domain 陣列可列出多個網域；同一條規則中的不同條件欄位則必須同時符合。例如同時填入 inboundTag 和 domain，代表請求須來自指定入口，且目標網域也符合清單。若誤把這種組合當成擇一關係，規則就會比預期更嚴格。排查時可先只保留一個條件，確認命中後再逐項增加限制。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "192.168.0.0/16"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

此片段可與前一章的直連、拒絕出口搭配使用。保留網域 blocked.example 僅用來示範精確比對語法；其餘未遭拒絕的請求最後都會直連。末尾規則是明確的兜底設定，並未示範代理分流。若要改成代理兜底，請先建立真實的代理出站，再將末尾規則指向其正確標籤。在規則中填入未定義的 proxy，不會自動建立可用出口。

網域、IP 與解析策略

full: 用於比對完整網域，domain: 用於比對網域及其子網域；一般字串與正規表示式各有不同語意，不能混用後只憑表面文字判斷範圍。IP 條件可使用單一位址或 CIDR 網段。使用地理分類資料時，也要確認執行環境具備相應資料檔、類別名稱存在，且更新來源可信。為了隔離問題，初次測試建議先使用明確的單一網域或位址，再加入大型分類集合。

domainStrategy 決定路由階段如何使用網域解析。AsIs 保留請求現有的目標資訊；IPIfNonMatch 可在網域規則未選出結果時嘗試解析，再繼續比對 IP；IPOnDemand 則可在比對需要 IP 資訊時觸發解析。實際執行方式仍須參照所用核心。選擇策略時，應考量解析成本、DNS 可達性及兜底規則的位置，不能認定解析越積極就一定越準確。

如果原始請求只提供 IP，網域規則可能無法命中。應用程式可能已在系統端完成解析，也可能透過自身的加密解析取得位址；入口目標識別只能在支援的流量中補充部分網域資訊。反過來說，網域請求也不一定馬上有可供 IP 規則使用的位址。診斷規則時，應從記錄確認核心實際收到的目標，而不是只根據瀏覽器網址列推測。

規則維護與回歸檢查

建議依明確層次安排拒絕規則、特定服務規則、內網規則與兜底規則。每新增一條規則，都記下預期目標與出口，並確認是否被較前面的規則攔截。整理規則檔時，不要把排序當成單純美化；移動位置可能直接改變行為。若客戶端提供預設路由模式，請先確認預設模式是否會覆蓋自訂清單，以及切換模式時是否會重新產生整個設定區段。

關於三個主要設定區段如何銜接，可繼續閱讀inbounds、outbounds 與 routing 逐段解析。如果只是想調整常用應用程式的接管範圍，請先在客戶端確認系統代理或 TUN 狀態，再編輯核心的分流規則。應用程式尚未接入時，增加更多網域規則也不會改變其實際連線路徑。

dns 解析伺服器與網域分流

dns 設定核心的內建解析器，但不會自動接管裝置上的所有 DNS 請求。系統解析、應用程式自行解析、核心為路由執行的解析，以及遠端出口端的解析，可能同時存在。閱讀設定前，先釐清哪一層需要取得位址。若應用程式傳入的已是 IP，修改內建伺服器不一定會影響該連線；當路由需要將網域轉成 IP 時，內建解析器才可能直接影響規則選擇。

servers 清單與伺服器物件

servers 可使用簡易伺服器項目，也可使用包含網域範圍等條件的伺服器物件。localhost 代表使用本機系統的解析路徑，適合用來建立最精簡的診斷基準；但解析結果仍會受到系統 DNS、網路和本機設定影響。填入公共解析位址，只是指定查詢目標，不代表查詢一定會經由代理，也不保證結果符合預期。能否連上該伺服器，以及查詢如何送出，都須依據所用核心和相關路由設定判斷。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "domains": ["domain:example.com"],
        "expectIPs": ["93.184.216.0/24"]
      },
      "localhost"
    ]
  }
}

此處使用保留示例網域，示範限定查詢與結果篩選。expectIPs 中的位址範圍僅為篩選語法範例，不代表該網域目前應回傳這個網段；網域位址可能變動，照抄可能導致篩選失敗。實際部署前，請依照自己管理的解析範圍填寫；若無法確定預期位址，先移除此條件。此範例也未表示第一台伺服器的查詢會經由代理，排查時應個別確認查詢路徑。

domains、expectIPs 與回退

domains 用來描述某台伺服器優先處理的網域範圍，不應簡單理解為路由的最終出口選擇。expectIPs 則為解析結果設定預期範圍，協助辨識不符合預期的位址；它不會憑空修正解析答案。過窄或過時的位址範圍可能排除合法結果，導致原本可連線的網域解析失敗。設定這類條件前，須先確認網域的實際託管方式，以及位址是否穩定。

符合條件的伺服器、未符合條件的伺服器，以及查詢失敗後的回退行為，都可能受所用核心和相關開關影響。不要只因伺服器位於陣列中的某個位置，就認定所有查詢都會嚴格依序執行。若要禁止某台伺服器參與一般回退，先確認該核心中相應欄位的用途，再進行局部測試。處理複雜分流時，先分別確認各伺服器都能解析目標網域，再將它們加入同一策略，比一次堆疊多項限制更容易排查。

解析循環、快取與位址族

使用加密 DNS 端點時，端點主機名稱本身也可能需要解析。如果解析這個主機名稱又依賴尚未建立的同一條解析鏈，就會形成啟動依賴循環。處理時，先梳理引導解析與查詢傳輸使用的出口，不要一再更換伺服器名稱。不同核心對本機查詢、遠端查詢和 DNS 路由標籤的支援各異；跨核心移轉時尤其要重新確認，不能把傳輸方式名稱視為完整的行為說明。

也要區分 IPv4 與 IPv6 的解析結果。取得 IPv6 位址不代表目前的出口具備可用 IPv6 路徑；只查詢 IPv4 也不一定適合所有網路。測試時記錄解析結果的位址族，並與實際連線失敗的位址相互比對。修改 DNS 後，請重新載入設定並建立新連線；作業系統、應用程式和核心可能各自有快取，舊結果仍可能在短時間內影響觀察。不要只重新整理一次頁面，就判定設定沒有生效。

DNS 的目標是讓解析位置、查詢路徑與連線出口保持一致，而非單純增加伺服器數量。若要依網域範圍拆分解析，可參照DNS 分流解析設定筆記逐項檢查。保留少量已驗證的規則，並清楚標示每條規則的適用範圍，比維護缺乏測試依據的長清單更可靠。

policy 連線階段與使用者等級

policy 不是路由規則，也不是客戶端的全域接管模式。它主要為連線階段、閒置狀態和部分統計行為提供策略。最容易誤解的是把策略中的時間限制當成網路加速參數：縮短等待時間通常只會讓失敗更早出現，不會降低實際鏈路延遲；限制設得過於嚴格，還可能中斷原本能恢復的連線。沒有明確問題時，建議優先保留核心預設值。

levels 與 level 的對應關係

levels 以使用者等級作為鍵，每個等級都包含一組策略。由於 JSON 物件的鍵必須是字串，範例會寫成 "0"；而在支援使用者等級的協定使用者物件中，level 通常是數字。兩者是對應關係，並不是同一個欄位。定義等級不代表所有連線都會自動套用；是否生效取決於相關協定是否建立相應的使用者上下文，以及該使用者採用哪個等級。

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

此片段只展示策略物件的結構，數值單位為秒，並非適用所有網路的建議值。它不會建立使用者、出站或監聽入口，也無法保證這些限制會套用到所有協定。如果客戶端沒有提供使用者等級設定，請先確認產生的設定中實際對應方式，再考慮修改。尤其不要把 levels 當成節點優先順序清單；數字越大不代表節點越快，也不代表路由優先權越高。

握手、閒置與單向連線

handshake 控制相關連線建立階段的等待時間。部分網路的認證或握手較慢，若時間設得太短，可能導致不斷重試。connIdle 描述連線沒有資料活動時的閒置限制，但實際行為也會受協定、應用程式的保活機制及中間網路設備影響。即使核心允許長時間閒置，路由器或遠端服務仍可能提早關閉連線，因此單純延長此數值無法保證長連線一直維持。

uplinkOnly 與 downlinkOnly 用於一側資料流結束後，設定剩餘的等待時間，不是上傳或下載速度上限。這裡的上下行是以連線處理方向來理解，不能套用網速測試介面的定義。有些應用程式會先結束傳送，再等待伺服器回覆；若剩餘等待時間設得太短，回應可能尚未抵達就被關閉。分析這類問題時，須確認連線何時半關閉，而不只是看頁面是否顯示逾時。

統計開關與客戶端顯示

部分策略可控制使用者或系統層級的流量統計，但啟用策略欄位本身不一定會建立完整的統計鏈路。核心可能還需要統計模組、管理介面及客戶端讀取邏輯；使用者統計也可能依賴協定使用者識別碼。介面能顯示流量，不代表所有統計都來自 policy；介面沒有資料，也不能直接判定連線未經核心處理。排查統計問題時應與排查連線問題分開，先確認請求能正常處理。

不需要遠端管理時，不要為了顯示統計而任意開放管理監聽。如果客戶端已經管理內部介面，請維持預設的存取範圍，並確認自訂設定沒有覆蓋相關入口。不同核心在統計欄位、記憶體相關選項及預設策略上各有差異；複製一段包含許多擴充欄位的策略，可能只會增加無法啟動的風險。請逐項確認用途，移除無法說明且沒有實際需求的設定。

回歸測試至少應涵蓋短請求、持續傳輸，以及閒置後恢復三種情境。只測一次一般網頁瀏覽，不足以證明策略適合長連線。記錄修改前後的欄位值、實際等待狀況與錯誤類型；若沒有穩定改善，就還原預設值。這種小範圍調整比同時修改握手、閒置和多項客戶端開關更容易得出可驗證的結論。

客戶端產生設定與重新載入流程

圖形客戶端儲存的設定，不完全等同於核心最後讀取的 JSON。訂閱群組、節點備註、介面主題、系統代理與自動啟動等通常屬於客戶端層；入站、出站、路由和 DNS 則可能由客戶端依據這些設定產生。直接編輯執行目錄中的檔案，有時會在下次啟動或切換節點時被覆寫。修改前先確認設定來源，才能決定要在介面中調整，還是使用客戶端明確提供的自訂設定入口。

訂閱、節點與完整設定的差異

訂閱通常提供多個連線項目及相關資訊，由客戶端負責解析、儲存並產生出站。節點分享內容主要描述單一遠端連線，不一定包含本機監聽與完整路由。完整核心設定則須涵蓋執行所需的各個部分。將節點字串存成 config.json，不會自動轉成 JSON 設定；把只有 dns 的片段匯入「完整設定」，也可能缺少必要的入口與出口。請使用符合內容類型的匯入功能。

v2rayN 適合桌面環境使用，可管理節點並檢視設定。Android 端可依核心需求優先選擇 v2rayNG；有 V2Fly 設定需求時，再考慮 v2flyNG。三款客戶端的選單名稱與支援欄位不一定相同，不能將某款客戶端的介面路徑視為通用核心規範。下載入口與平台選擇請見客戶端頁面；從首次匯入到連線驗證的完整操作流程，請參閱入門指南。

變更前先保存可還原的狀態

先記錄目前使用的客戶端、作業系統、所選核心、接管方式，以及可重現的問題。保存現有設定或匯出必要設定，並將訂閱網址與認證資訊視為敏感資料妥善保管。診斷用備份不應任意上傳至公開位置。若只要測試一條 DNS 規則，請保持節點和路由不變；若要更換核心，暫時不要同時更新訂閱及調整傳輸方式。一次只改變一個變數，才能更清楚判斷失敗原因，也更容易還原。

使用自訂設定時，須確認客戶端是否仍會補上內部入口、統計設定或路由內容。有些入口會讀取完整設定，有些則只覆蓋特定欄位，兩者的合併方式不同。最可靠的檢查對象是最後交給核心執行的設定，而不是編輯視窗中的局部文字。若匯出功能只提供節點資訊，就不能把它當成整份執行設定的快照；還應一併比對目前模式與全域設定。

儲存、載入與建立新連線

1. 先檢查 JSON 語法及標籤引用，確認修改只涉及預定的設定區段。
2. 在客戶端儲存設定，並使用其提供的重新載入、重新啟動服務或重新連線功能。
3. 查看啟動記錄，確認新的核心程序已成功載入，且監聽連接埠沒有占用錯誤。
4. 重新建立測試連線，確認請求是否進入預期入口並選擇預期出口。
5. 若結果不符，還原上一步的設定，確認基準狀態仍可使用，再分析差異。

儲存不代表已載入；載入後也不代表舊連線會立即改用新出口。瀏覽器和其他應用程式可能重複使用既有連線，DNS 也可能命中快取。因此測試路由變更時，請建立新的請求工作階段；必要時關閉應用程式後再試，不要只在原頁面繼續操作。客戶端記錄應出現與本次測試時間相符的事件，否則看到的可能是舊連線活動。

Windows、macOS 與 Linux 遵循系統代理的方式及背景執行機制各不相同，不能只憑按鈕名稱相同就推斷效果一致。Linux 桌面環境的自動啟動也可能受到桌面工作階段與安裝方式影響，可參閱Linux 安裝與自動啟動筆記。Android 的系統 VPN 授權、應用程式分流與背景限制也屬於接入環境，應與 JSON 路由分開檢查。

最後確認還原方式：保留可用節點、原始模式及修改前的設定，不要讓診斷變更直接取代日常設定。若客戶端更新後不再接受某個欄位，先還原產生設定時的預設範本，再確認核心支援情況。不要不斷堆疊舊欄位，讓設定檔變得難以理解；只有能清楚說明每個自訂欄位用途，後續維護才會更容易。

設定驗證與故障排查順序

設定排錯應沿著資料路徑逐層進行：先確認檔案能載入，再確認入口收到請求，接著確認路由選到正確出口，最後檢查解析、握手與目標回應。每次只驗證一項假設。直接更換節點、DNS、路由和逾時參數，可能偶然讓連線恢復，卻無法判斷哪項修改有效。保留一組穩定的測試目標、相同的接入方式及相應記錄，才能比較修改前後的實際差異。

啟動失敗：先查看第一筆錯誤

檔案無法載入時，優先查看最早出現的明確錯誤，而不是後續連鎖退出訊息。括號或逗號錯誤屬於 JSON 語法問題；未知協定、欄位型別不符或缺少必要參數屬於設定語意問題；位址占用、權限不足和檔案路徑無法讀取則屬於執行環境問題。這三類問題的處理方式不同。即使編輯器顯示語法正確，仍須讓實際使用的核心驗證，不能以另一個核心成功載入的結果取代。

若錯誤指向某個設定區段，先還原該區段最近一次的變更。合併檔案時，檢查是否有重複的頂層鍵、陣列遭錯誤取代，或數字被改成字串。若連接埠已被占用，檢查是否同時啟動多個客戶端執行個體；先停止舊執行個體再試。處理權限問題時，確認涉及的資源與操作；建立虛擬網卡所需的權限，與監聽本機高位連接埠並不相同。不要因一般設定錯誤，就長期讓所有操作以較高權限執行。

能啟動但無法連線：逐段縮小範圍

入口完全沒有請求時，檢查應用程式的代理位址、連接埠、類型及系統代理是否生效。入口有收到請求但出口不正確時，檢查規則順序、目標是否帶有網域，以及標籤引用是否正確。出口選擇正確但連線失敗時，再檢查網域解析、遠端可達性、認證與傳輸參數。若只有某個目標失敗，也要考慮目標服務本身的狀態，不要因此直接推斷整份設定已損壞。內網資源異常時，先確認是否被兜底規則送往不適合的出口。

記錄層級與最小重現案例

診斷期間可暫時提高記錄詳細程度，以觀察入站、路由和連線錯誤。記錄可能包含目標網域、位址和使用行為，收集時應控管範圍，問題排除後恢復日常層級。分享記錄前請隱藏敏感連線資訊，只保留足以說明錯誤的資料。不要在求助內容中貼上完整訂閱或認證欄位；多數設定問題只要提供欄位結構、錯誤類型和已處理的目標資訊即可說明。

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

此片段只調整記錄層級。實際記錄位置可能由客戶端管理；若未填入檔案路徑，請在客戶端的記錄介面查看。提高層級後，重新送出一次目標請求，記下前後相關事件，再恢復原層級。不要長時間收集所有應用程式活動來尋找單一錯誤。若資訊層級仍無法判斷問題發生階段，再依核心支援情況使用更詳細的層級，並縮短收集時間。

最小重現測試可從本頁第一章的直連基準設定開始，先確認本機入口與一般網路可用，再還原真實的代理出站。基準直連成功不代表代理鏈路正常，只能排除部分本機接入問題。接著依序還原路由、DNS 和策略，每一步都重新載入並建立新連線。若業務不適合直連測試，就不要勉強改變存取路徑；可改用自己管理的測試目標，驗證相同的設定階段。

常見問題與參考連結

本頁提供欄位參考與分層診斷；首次操作仍請以入門指南為主線，協定與生態系名詞可查閱名詞解釋。排錯完成後，建議留下簡短的變更記錄：修改了哪個設定區段、觀察到什麼結果、是否需要重新載入，以及如何還原。能說明、能重現、能還原，比不斷堆疊參數更有助於維護。