V2Ray 設定檔參考

JSON 結構總覽

設定檔描述的是核心如何處理連線，並非用戶端視窗中所有選項的備份。閱讀時先沿著資料路徑理解：應用程式將連線交給入站，路由依據目標與來源選擇出站，出站再直接連線至目標或遠端服務。DNS 為需要解析的環節提供結果，策略則管理連線時限與統計。物件之間透過標籤、使用者等級等值互相關聯；只看其中一段，往往無法理解完整行為。

先區分用戶端檔案與執行設定

v2rayN 儲存的訂閱群組、介面偏好與更新設定，不一定屬於核心 JSON。用戶端通常會依照目前的伺服器、路由範本和參數設定產生執行設定，重新連線時也可能再次產生。直接修改產生的檔案，下次切換伺服器時可能被覆寫。因此，應先找出設定的來源：一般連接埠和路由選項優先在介面中修改；確實需要完整自訂設定時，再使用用戶端提供的相應匯入或自訂入口。

本頁以常見的 V2Ray 物件式 JSON 作為閱讀基準，不將不同核心的擴充欄位混為同一套標準。v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心；v2rayN 的實際功能則取決於目前選用的核心。相同欄位名稱可能有不同的可選值，部分新傳輸方式也不適用於其他核心。遇到未知欄位時，先確認執行中的核心與設定格式，不要逐一刪除錯誤位置附近的內容。

可啟動的本機直連基礎設定

以下完整設定建立兩個僅供本機存取的入口，預設直接連線至目標，並預留一個拒絕流量的出站。此設定用於理解結構及驗證本機連線，不含遠端代理伺服器，也不會自動變更系統代理。以一般 UTF-8 文字儲存後，應透過相容核心的自訂設定方式執行；若用戶端已使用這些連接埠，請先停止原有執行個體，或同時修改本範例與測試應用程式的連接埠。

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

JSON 物件使用大括號，陣列使用方括號，鍵名與字串都必須以雙引號括住。數字連接埠不加引號，布林值則寫成小寫的 true 或 false。本頁範例不含註解與結尾逗號，方便交由嚴格的 JSON 解析器處理。即使某種載入方式允許註解，也別因此認定所有用戶端匯入入口都接受相同語法。

空物件與缺少物件不一定等同。某些協定的 settings 可以留空，其他協定則必須包含伺服器或使用者清單。欄位拼字與大小寫也必須一致，例如 outboundTag 不是可任意命名的說明文字。相對地，direct、socks-in 是範例自行定義的標籤，可以更名，但所有引用處都必須同步修改，並避免標籤重複。

不必一次填滿所有可選物件。完整不代表欄位越多越好，而是每個已填入的欄位都有明確用途。開始查閱前，可以先記下目前的入口協定、連接埠、預設出站與預期分流行為。後續逐段設定時圍繞這四項核對，就能減少整份複製他人設定後，卻無法判斷哪些規則正在生效的情況。

inbounds 入站：應用程式的連線入口

inbounds 是入口陣列。每個入口至少要指定監聽位址、連接埠與協定，並提供該協定所需的設定。應用程式實際連線至這個入口後，核心才有機會處理其流量。用戶端顯示正在執行，不代表瀏覽器、終端機與其他應用程式都已接入。排查時先確認「應用程式將連線送到哪裡」，再檢查路由是否正確，通常比直接修改分流規則更有效。

listen、port 與協定應一併核對

listen 設為 127.0.0.1 時，只接受本機回送連線；0.0.0.0 則代表監聽所有 IPv4 介面，範圍明顯更廣。連接埠是入口實際佔用的本機連接埠，不是遠端伺服器的連接埠。本頁以 SOCKS 10808、HTTP 10809 分開監聽為例；用戶端也可能使用混合入口或其他連接埠，實際設定應以目前執行中的設定為準，不能只憑常見數字判斷協定。

HTTP 代理設定應指向 HTTP 入口，SOCKS 設定則應指向 SOCKS 入口。將瀏覽器的 HTTP 代理指向純 SOCKS 連接埠，通常無法建立正確工作階段。HTTPS 網站也能透過 HTTP 代理的 CONNECT 通道存取，不必因此將本機代理位址改成 HTTPS。應用程式設定中的「安全代理」有時指的是目標流量類型，而不是本機入口啟用了 TLS。

UDP 與流量嗅探的適用範圍

SOCKS 入口中的 udp: true 允許相應的 UDP 轉送功能，但不是全域 UDP 開關。應用程式必須使用相容的 SOCKS UDP 方式，遠端協定、伺服器與網路路徑也都要支援。只有 TCP 請求正常，並不能證明 UDP 也能通行。傳統 HTTP 代理入口也不能直接視為所有 UDP 應用程式的替代方案；遊戲或即時通訊程式需要另外確認接入方式。

sniffing 可從部分應用層交握資訊中辨識目標網域，協助原本只有 IP 位址的連線參與網域路由。它不是解密工具，也無法保證從所有加密流量中取得網域。以下設定只將辨識結果用於路由判斷；routeOnly 是否可用，應依實際核心確認。若不支援此欄位，不要直接刪除後就假設行為完全相同，應重新確認是否允許改寫目標。

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

這段內容應合併到某個入站物件中，與 protocol 同層，而不是放在該協定的 settings 裡。設定樹位置錯誤時，有些載入器會拒絕啟動，有些則可能忽略未知內容。JSON 能成功解析還不夠，還要確認核心接受了該結構，並觀察對應的網域規則是否確實命中。

分享給區域網路需額外設定存取控制

讓另一台裝置使用代理時，用戶端的「允許來自區域網路的連線」通常會改變監聽範圍，也會受到作業系統防火牆影響。連線位址應填寫代理主機的區域網路位址，而非對方裝置自己的回送位址。應限制允許存取的來源，必要時設定驗證；不要只將監聽位址改成所有介面，就把入口暴露在不確定的網路中。

Android 上的 v2rayNG 與 v2flyNG 通常還會使用系統 VPN 介面及個別應用程式選擇。某個應用程式是否會經過此介面，與 JSON 中是否有 SOCKS 入口是兩回事。桌面版系統代理、應用程式個別代理及 Android 個別應用程式規則應分開檢查；授權與背景執行問題可參閱Android VpnService 與個別應用程式代理說明。

outbounds 出站：協定與預設路徑

outbounds 是處理連線的出口清單。出站可以直接連線至目標、連線至遠端代理服務，也可以主動拒絕流量。其 protocol 描述核心在此出口使用的協定，而非應用程式最初使用的入口協定。同一個 SOCKS 入站中的連線，會依路由結果交給不同出站；入口與出口不必一對一對應。

預設出站與標籤引用

在常見的物件式設定中，未符合任何路由規則的連線會使用第一個出站。因此，陣列順序也是實際行為的一部分。開頭的設定將 direct 放在第一項，所以所有未符合規則的連線預設直連；若實際遠端代理設定希望未符合規則的流量走代理，就應明確指定預設出口。不要以為標籤叫作 proxy 就會自動成為預設路徑，標籤名稱本身沒有特殊含義。

tag 是供路由引用出站的名稱。規則中的 outboundTag 必須與已定義的標籤完全相符，包括大小寫。建議使用容易辨識的短名稱，並避免重複。混用節點名稱、訂閱群組名稱與出站標籤容易造成誤解：用戶端介面顯示的名稱可能會轉換，不保證原樣出現在執行設定中；排查時應查看實際產生的設定。

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

freedom 表示由本機網路直接連線至目標，不代表略過核心。連線仍可能受到核心 DNS、出站設定與系統網路狀態影響。blackhole 則用於丟棄或拒絕所選流量，通常作為明確的封鎖結果。拒絕後，應用程式可能立即失敗，也可能持續重試並等待逾時，這與應用程式的重試機制有關，不能把頁面一直載入直接視為遠端連線故障。

不同遠端協定的 settings 不可互換

不同代理協定使用不同的伺服器與驗證結構。VMess、VLESS 的使用者資訊不等同於 Trojan 的密碼欄位；Shadowsocks 還必須搭配雙方一致的加密方式。分享連結通常同時包含遠端位址、連接埠、驗證與傳輸資訊，匯入後應一併核對。只替換一個位址，卻沿用另一條連線的傳輸或驗證設定，很容易產生語法正確但無法連線的設定。

遠端伺服器位址回答「要連線到哪台伺服器」，請求的目標位址回答「最後要存取哪裡」，兩者處於不同層級。本機監聽連接埠、遠端服務連接埠與目標網站連接埠也應分別記錄。例如，應用程式成功連入本機連接埠，只能證明第一段連線成立；遠端連接埠無法連線、驗證資訊不一致或 TLS 失敗，仍會導致最終存取失敗。查看日誌中的位址時，應先判斷它屬於哪一段。

先驗證一個出口，再加入選擇邏輯

新增多個出站前，先用同一個測試請求驗證單一出口。保留一個明確的直連對照，有助於區分目標本身無法連線與代理路徑異常。在完整自訂設定中，用戶端的「選擇目前伺服器」不一定會改寫你的出站清單，因此切換介面選項後，應確認設定來源。不要想當然地認為用戶端的自動選擇功能適用於所有自訂檔案。

多路複用、鏈式連線與負載分配屬於進階行為控制，不是連線失敗時應優先啟用的補救選項，因為它們會增加並行處理、相依項目與診斷的複雜度。先確認入口、路由及單一遠端連線都能正常運作，再依需求新增設定。若容易混淆協定概念，可先閱讀四種代理協定的差異，再回頭核對對應的協定欄位。

傳輸與安全性：streamSettings 的層級

代理協定與傳輸方式是兩層不同設定。協定負責工作階段與驗證，傳輸則負責資料如何在網路上傳遞；連線安全性再決定是否使用 TLS，以及如何使用。相同協定可以搭配不同傳輸方式，但只有伺服器與目前核心都支援的組合才能運作。匯入分享連結後，應一併檢查協定、傳輸與安全方式，不要只因協定名稱相同就認定相容。

network 與 security 各自描述什麼

streamSettings 通常與出站的 settings 位於同一層。其中 network 指定底層傳輸類型，security 指定該層使用的連線安全機制。傳輸專屬物件則提供路徑、要求標頭或服務名稱等細節。欄位名稱與可用值會隨核心功能而異，尤其不可將某個核心的新傳輸欄位直接視為其他核心通用的寫法。

以下是 TLS 設定結構範例，展示物件位置與憑證名稱欄位。這不是完整的遠端出站；範例網域採用文件保留網域，實際使用時應填入伺服器明確要求的名稱。不要用這段範例取代訂閱中的所有傳輸設定，也不要因此假設只要啟用 TLS，就能與任意遠端連接埠完成交握。

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

serverName 用於 TLS 伺服器名稱指示及相關憑證名稱驗證，不一定等同於建立底層連線時填寫的伺服器位址。底層連線可以指向 IP 位址，而憑證則必須符合網域名稱。反過來說，只將伺服器位址改成網域，也不能保證應用層要求標頭、傳輸路徑與 TLS 名稱都已正確設定。應分別對照伺服器端要求，不要用一個欄位代替所有名稱。

路徑、要求標頭與憑證檢查

使用 WebSocket 時，路徑屬於傳輸協定的一部分，必須與伺服器或前置轉送設定一致；斜線、大小寫及附加參數都可能影響比對。要求標頭中的 Host 與 TLS 名稱可能相同，也可能在特定部署中不同，但不可憑猜測任意填寫。TLS 成功只代表安全連線階段通過，不代表後續的 WebSocket 升級或代理協定驗證也已成功。

gRPC 的服務名稱同樣是伺服器端約定的一部分，並非介面備註。即使傳輸名稱看起來正確，也可能因服務名稱、路徑轉送或中間網路設備限制而失敗。排查時應確認失敗發生在 TCP 連線、TLS 交握、傳輸交握還是協定驗證階段。每一層都仰賴前一層；跳過順序並同時修改多個項目，會讓原本可定位的問題變得難以重現。

相容性取決於目前執行的核心

REALITY、XTLS Vision 等功能並非複製幾個欄位就能啟用；用戶端介面支援也不代表目前執行的核心已接受這組設定。遇到相關連線時，先核對服務提供的資訊與實際使用的核心，再檢查整組參數。V2Fly 與 Xray 有共同背景，但各自的擴充功能並非完全互通，相關資訊可參閱核心差異與設定相容性。

更換核心後若出現「未知傳輸」或「無法解析安全設定」，應先還原至已確認相容的設定，不要逐一刪除欄位直到能啟動。成功啟動只表示檔案已被接受，不代表雙方使用相同的連線語意。保留原始連線資訊與本機修改紀錄，還原設定時就不必再次猜測，也能將相容性問題與網路問題分開處理。

routing 路由：條件、順序與標籤

路由規則決定連線要交給哪個出站。常見的欄位式規則會依陣列順序逐一檢查，先符合的規則先決定結果；若沒有符合的規則，則使用預設出站。規則無法取代入站，也無法修復原本就無法連線的出口。設定分流前，應先驗證預設路徑，再加入少量目的明確的規則，避免一開始就匯入大量難以理解的條件。

理解規則內部的比對關係

同一條規則中，不同類型的條件通常必須同時符合，例如來源入口與目標網域都符合才會命中；同一欄位的陣列則用來列出多個可符合的項目。因此，將網域清單與 IP 清單放在同一條規則中，不代表條件是「網域或 IP」。若需涵蓋這兩類目標，通常應拆成兩條規則，再讓它們指向同一個出站標籤。

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

這段範例需要已有 direct 與 block 出站，也需要對應的網域與 IP 資料檔。第一條規則會精確封鎖文件範例網域，用來觀察規則優先順序；後三條則示範常見的直連分類。這不是適用所有網路的完整分流方案，未符合規則的流量仍由第一個出站處理。如果預設出站也是直連，後續規則不會自動將其他流量改為代理。

網域寫法與資料檔

full: 用於精確比對網域，domain: 用於比對網域及其子網域，regexp: 使用正規表示式，geosite: 引用網域分類。一般字串的比對範圍可能比預期更廣；若需要精確比對，應明確使用適當前綴。正規表示式中的反斜線還要經過 JSON 字串跳脫；若難以排查，建議用幾條明確的網域條件取代複雜表示式。

geosite:cn 與 geoip:cn 分別引用網域分類與 IP 分類，並非即時地理定位，也不是一一對應的資料集。資料檔缺失、類別不存在或檔案格式不相容，都可能影響載入。更新用戶端或資料後，某些目標的比對結果也可能改變；需要長期固定的業務例外，適合用明確的自訂網域規則表示。

domainStrategy 不等於 DNS 伺服器選擇

AsIs 通常保留原始目標形式，不會為路由比對主動將網域轉成 IP；IPIfNonMatch 會在網域階段未命中時嘗試解析，再進行比對；IPOnDemand 則會在路由判斷需要 IP 時觸發解析。實際執行方式仍取決於核心實作。這些選項回答的是「路由何時需要 IP」，DNS 物件回答的則是「如何處理解析請求」，兩者不可混為一談。

應用程式直接送出 IP 時，網域規則可能沒有可用的網域資訊；目標保留為網域時，純 IP 規則是否生效又會受到解析策略影響。流量嗅探在某些情況下能補充資訊，但無法保證每條連線都有網域。判斷規則失效時，應先確認核心收到的是網域還是 IP，再檢查規則順序與資料分類，不要直接將所有流量改送同一個出口。

驗證分流時，挑選一個精確網域、一個預期直連的目標與一個預設路徑目標，分別建立新連線。瀏覽器的連線池可能重用舊工作階段；修改設定後，應重新建立連線再查看日誌。系統代理的略過清單也可能讓請求在進入核心前就直接連線，這與核心路由是兩套機制；其他常見狀況可在常見問題中按連線排錯分類查閱。

dns 設定：解析在哪裡進行

設定 DNS 時，首先要確認解析在哪裡進行。瀏覽器、作業系統、應用程式內建解析器、核心內建解析器與遠端服務都可能參與。加入 dns 物件，只是設定核心內建解析器的行為，不代表系統中所有 DNS 請求都會自動交由它處理。如果應用程式先將網域解析成 IP 再交給代理，核心最初看到的目標可能已經沒有網域資訊。

servers、hosts 與查詢策略

servers 定義解析伺服器；清單項目可以是簡單位址，也可以是包含比對條件的物件。以下展示常見的分域解析結構，前提是核心支援這些欄位。IP 位址是公用解析器範例，不代表所有網路都能連線，也不是固定推薦選項。套用至實際環境前，請先確認這些解析器在目前網路與預期路徑上都可使用。

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIPv4"
  }
}

hosts 是核心解析器使用的靜態對應，不會修改系統的 hosts 檔案。範例中的 192.0.2.10 是文件保留位址，只用於展示結構，不能用來存取實際服務。靜態對應適合明確且穩定的特殊需求；若長期將經常變動的網站固定到某個 IP，可能會略過正常調度，並造成憑證、連線狀態或服務區域不如預期。

包含 domains 的伺服器項目可為特定網域設定比對條件；expectIPs 用於檢查結果是否符合預期分類，但不是「只允許這個地區存取」的防火牆。解析器候選項目、回退與結果接受邏輯，也取決於核心及其他選項。不要把伺服器陣列簡單理解成永遠等第一項失敗後才嘗試第二項，也不要只憑排列順序推斷所有查詢的流向。

解析路徑與連線路徑應分開驗證

解析請求能否抵達 DNS 伺服器，與最終網站連線是否走代理，是兩個不同問題。某些解析方式可以參與核心路由；某些具有本機語意的模式則會直接使用本機路徑，細節需依實際實作確認。只新增一條指向代理的網域規則，不一定會改變所有解析請求的出口；只更換 DNS 位址，也無法自動修復錯誤的遠端驗證或傳輸參數。

使用 HTTPS 型解析服務時，還要處理「先解析解析器本身的網域」這個引導問題。若解析伺服器位址本身是網域，而目前的解析路徑又依賴它，就可能形成循環相依。應釐清啟動階段如何找到解析器與代理伺服器，保留可用的引導路徑，並避免讓代理伺服器網域的解析依賴尚未建立的同一條代理連線。

IPv4、IPv6 與快取

UseIPv4 用於限制相應查詢策略，不等於關閉整台裝置的 IPv6。應用程式若使用自己的解析器，仍可能取得 IPv6 位址並嘗試連線。反之，能夠解析 AAAA 記錄，也不代表目前網路具有可用的 IPv6 路徑。應分別驗證解析結果與連線結果，不要以全面關閉某種位址族來取代對具體故障路徑的定位。

修改解析設定後，應用程式快取、系統快取與既有連線都可能影響觀察結果。先發出新的請求，再比對日誌中的目標形式與路由選擇。命令列的系統解析工具通常測試的是系統解析路徑，不一定等同核心解析器的行為；若要驗證核心 DNS，應讓測試請求通過實際入口，並搭配執行日誌判斷，不能只看一次系統查詢就認定設定已生效。

policy 策略：連線時限與統計

policy 主要管理各使用者等級的連線行為與系統層級的統計選項。此處的「策略」不是網域分流規則，也不是系統代理模式。路由決定連線交給哪個出口；策略則決定相關連線可以等待多久、何時結束，以及是否記錄部分統計。分開理解這兩個物件，可避免用縮短逾時時間來處理路由選錯等不相關問題。

levels 與使用者等級的關係

levels 的鍵是等級編號字串，例如 "0"。支援使用者等級的協定物件可以在使用者設定中引用等級；若未明確指定，通常會套用預設等級，實際情況取決於協定與核心。等級不是優先順序排名，也不會自動讓某位使用者的網路連線更快。設定前應確認受管理的使用者物件確實使用這個等級，否則修改可能不會生效。

{
  "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 控制閒置連線的時限，uplinkOnly 與 downlinkOnly 則涉及連線其中一側結束後，另一側可繼續運作的等待時限。常見實作以秒為單位，但這些時限作用於核心的連線流程，並不等於瀏覽器顯示的頁面載入時間。

時限設得太短，可能讓高延遲網路上的交握尚未完成就被中止，也可能影響長輪詢、訊息推播，或短時間沒有業務資料的連線。時限設得太長，則可能占用更多閒置資源。偶爾斷線時，先確認原因是逾時、遠端關閉，還是應用程式主動結束；不要一看到斷線就同時調高所有數值。過度調整會掩蓋連線品質問題，也會增加重現難度。

統計開關不等於完整監控介面

使用者流量統計、入站統計與出站統計的對象各不相同。開啟某個開關，不代表用戶端一定會顯示相應數值；統計模組、查詢介面與用戶端本身的取樣方式也必須相互配合。使用者統計還可能需要可辨識的使用者資訊。不要將這些計數直接等同網卡流量；協定負載、重傳及其他處理程序的流量，都可能造成統計口徑差異。

若完整設定需要統計功能，通常還必須依照核心要求設定統計物件與查詢功能。API 入口屬於管理介面，應限制在本機或受控網路中；不要為了讀取流量而直接暴露在不受信任的介面。本頁不提供開放管理連接埠的組合範例；使用圖形用戶端時，建議優先使用用戶端內建的統計功能，避免重複啟用彼此衝突的管理入口。

策略、日誌與並行處理應分開調整

日誌層級由 log 物件控制，不是 policy 的統計開關。策略統計記錄位元組數，日誌記錄執行事件，兩者無法互相取代。多路複用也有獨立的設定位置，不會因為啟用使用者統計就自動開啟。排查資源占用時，應分別觀察連線數量、業務並行量、日誌輸出與統計需求，再決定要修改哪個項目。

桌面與行動裝置對背景連線的限制也可能來自作業系統。Android 的電池最佳化可能會暫停用戶端，網路切換也可能使既有連線失效；這些問題無法只靠調高 connIdle 解決。先確認處理程序仍在執行、系統網路介面仍有效，再檢查核心策略，否則可能把系統層級的中斷誤判為設定中的閒置逾時。

評估修改是否有效時，應在相同網路、相同應用程式及相近使用流程下重新測試。短請求正常，不代表長連線也正常；長時間維持連線，也不代表資源使用合理。記錄具體失敗階段與日誌，比反覆套用所謂通用最佳化參數更有幫助。沒有明確需求的選項應審慎使用，通常更有利於維護及後續升級相容性。

驗證與排錯：從檔案到實際請求

設定驗證分成四個層次：文字能否解析、核心能否載入、應用程式是否接入，以及最終路徑是否符合預期。前一層通過不代表後一層也通過。合法的 JSON 可能引用不存在的出站；已啟動的核心可能沒有收到任何應用程式連線；成功存取一次，也可能只是系統略過代理後直接連線。每個層次都應留下可觀察的證據，才能判斷修改實際影響了哪個環節。

先排查語法與載入錯誤

先檢查雙引號、逗號、括號是否配對，以及欄位型別是否正確。複製程式碼時，不要把說明文字或程式碼圍欄一併貼入檔案。JSON 成功解析後，再查看核心啟動日誌是否指出未知協定、缺少資料檔、無效標籤或連接埠占用。錯誤訊息指出的行列通常是解析停止的位置；真正缺少的逗號可能在上一行，因此應連同前後物件邊界一起檢查。

確認目前執行的是剛才修改的檔案，而不是用戶端重新產生的另一份設定。圖形用戶端通常能查看日誌或相關執行資訊，實際入口名稱可能隨介面而異。排查時不必一開始就更換用戶端；先保留原始檔案副本、關閉衝突的執行個體、重新啟動一次，並記錄第一次出現的錯誤。後續重複出現的錯誤可能只是同一根因引發的連續重試。

使用明確指定的入口發起測試

以下兩個命令分別測試前述分開設定的 SOCKS 與 HTTP 入口。SOCKS 位址中的 socks5h 表示將網域交由代理端處理，適合用來區分本機解析路徑。在 Windows 命令環境中可明確使用 curl.exe；其他系統則使用可用的 curl 命令。測試存取的是文件範例網站，不是速度測試，也不能據此判斷所有應用程式都已透過代理連線。

curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --head https://example.com/
curl --noproxy "" --proxy http://127.0.0.1:10809 --head https://example.com/

明確設定空的略過清單，是為了減少現有代理環境變數對測試造成的干擾。如果本機連接埠立即拒絕連線，先檢查處理程序、監聽位址與連接埠；若本機接入成功但遠端逾時，再檢查出站與網路。對照開頭的直連基準時，測試成功只證明「應用程式到核心，再到目標」的基本連線成立，不代表已有可用的遠端代理伺服器。

依日誌階段定位欄位

warning 適合一般執行；若細節不足，可短暫提高日誌詳細程度。修改後重新發起一個容易辨識的請求，記錄時間、目標、入口與選中的出口，再恢復日常日誌層級。詳細日誌可能包含網域、位址與連線資訊，分享前應移除訂閱位址、驗證資訊及其他敏感資料，不要直接傳送整份執行設定檔。

「逾時」只是結果，不是唯一原因。目標無法連線、解析失敗、出口錯誤或遠端交握停滯，都可能出現相似現象。應先確認失敗位置，再選擇要檢查的欄位。典型日誌的進一步說明可參閱執行日誌與常見錯誤；若只有終端機無法使用，請查看系統代理與終端機路徑排查，不要先修改整套路由。

建立可還原的修改紀錄

每次修改都保留三項資訊：修改了哪個物件、預期改變什麼，以及用哪個請求驗證。更新訂閱或切換伺服器後，再確認用戶端是否保留自訂設定。需要復原時，還原到最近一份可執行的設定，不要繼續疊加修補。若仍無法找出問題所在，請依照教學主線重新驗證匯入、模式與連線，再依本頁的物件順序逐層加回自訂內容。