逐跳建立並驗證 Xray 代理鏈：出口、DNS 與故障恢復

Xray 代理鏈把指定應用程式的連接先送到入口 A，再經出口 B。應先分別檢查各跳，再讓 B 的底層連接經 A 建立；任何一跳失效，指定請求都應停止，不能暗中轉為直連。

關鍵要點

• 兩台伺服器及目標須由你控制，或取得其擁有者明確授權。
• 最終出口地址不能證明哪個入口承載了連接。
• 身份認證、TLS 驗證、路由及 DNS 須分開檢查。
• 本例適用於明確設定代理的 TCP 應用，不是整台裝置的隧道，也不涵蓋 UDP。

Xray 代理鏈會涵蓋哪些流量？

本指南依 Xray-core v26.3.27 官方文件編寫，以 Ubuntu 24.04 LTS 命令列客戶端及兩個已設定的授權 Trojan over TLS 端點為範圍，未進行完整端到端實測。版本固定是為了界定示例，並非聲稱它是最新版，也不應成為忽略安全更新的理由。［1］

變更前先核對自建網絡的責任及恢復安排。兩跳的信任模型說明能隱藏及不能隱藏的部分；增加一跳不會自動證明匿名、更高速度或抗封鎖能力。Xray 與 V2Ray 的角色則有助區分核心程式與管理它的應用。

若你只需日常裝置出口，毋須控制兩台伺服器，可比較裝置整體覆蓋與應用代理。這是改變要完成的任務，不能視為用產品修復此代理鏈。

步驟 1：預留拓撲及獨立恢復途徑

採用獨立客戶端及專用測試身份。不要為了完成示例關閉或修改日常使用的代理或 VPN 客戶端。若既有路由影響檢查，記錄額外的一層，或轉用獲授權的隔離機器；不能將結果描述為沒有其他路徑的兩跳連接。

角色	所需控制範圍	私下保留的證據
客戶端 C	測試程序及回環連接埠	核心版本、設定位置、程序擁有者
入口 A	具身份認證的 TLS 端點	測試身份、來源限制、連往 B 的記錄
出口 B	具身份認證的 TLS 端點	來自 A 的連接、獲准目標、出口地址族
目標 T	授權 HTTPS 服務	憑證身份及時間相符的請求記錄

保留不經代理鏈的控制台或管理連接。記下原有監聽、防火牆的具體管理者、DNS 及應用代理設定。只備份會修改的檔案，限制讀取權限；同一程序或設定若服務其他用戶，便應停止，另設專用測試實例。

A、B 必須已有不同的 Trojan 憑據、匹配各自名稱的有效憑證、相容傳輸設定及有限的允許範圍。以官方協議文件核對入站與出站欄位。［2］ 可行時限制 A 只接受獲准客戶端；鏈式測試的 B 只接受 A，兩者只通往授權目標。不得建立匿名監聽、停用防火牆或使用未獲准的住宅出口。

步驟 2：核對 Xray dialerProxy 設定及歸屬

dialerProxy 指定建立另一出站底層連接時使用的出站標識。本例應用選擇 exit-b，而 exit-b 經 entry-a 連往 B；entry-a 不得再引用 B 或自己。［3］ tag 須唯一，引用關係不得形成循環。

以一般測試用戶建立私有工作目錄，把以下完整客戶端設定存成 chain.json。文件示例地址、憑證名稱、連接埠及兩個密碼佔位符均須換成授權端點；所示內容並非可用節點。密碼不可放進命令列參數或共用日誌。

{
  "log": {"loglevel": "warning"},
  "inbounds": [
    {
      "tag": "lab-socks",
      "listen": "127.0.0.1",
      "port": 10818,
      "protocol": "socks",
      "settings": {"auth": "noauth", "udp": false}
    }
  ],
  "outbounds": [
    {"tag": "deny", "protocol": "blackhole", "settings": {}},
    {
      "tag": "entry-a",
      "protocol": "trojan",
      "settings": {
        "servers": [{"address": "192.0.2.10", "port": 18443,
          "password": "REPLACE_ENTRY_PASSWORD"}]
      },
      "streamSettings": {
        "network": "raw", "security": "tls",
        "tlsSettings": {"serverName": "a.example.com", "allowInsecure": false}
      }
    },
    {
      "tag": "exit-b",
      "protocol": "trojan",
      "settings": {
        "servers": [{"address": "198.51.100.20", "port": 18443,
          "password": "REPLACE_EXIT_PASSWORD"}]
      },
      "streamSettings": {
        "network": "raw", "security": "tls",
        "tlsSettings": {"serverName": "b.example.com", "allowInsecure": false},
        "sockopt": {"dialerProxy": "entry-a"}
      }
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {"type": "field", "inboundTag": ["lab-socks"],
        "network": "tcp", "outboundTag": "exit-b"}
    ]
  }
}

回環 SOCKS 入口只供可信的單用戶客戶端使用，其他本機用戶也可能連入；共用機器不應採用這個無身份認證入口。UDP 已停用。［4］ TLS 名稱須與有效端點憑證相符。本教程不混用 REALITY、Vision、多路複用或透明捕獲；傳輸安全與撥號出站選擇是兩種設定。［2］［5］

路由依序匹配，沒有規則命中時採用首個出站。把 deny 放在第一位，未匹配流量便預設拒絕；明確的 TCP 規則才把測試入口交給 B。［6］ 不加入直連出站或回退負載平衡器。日後若要直連例外，須另外定義用途、範圍及失效證據。

步驟 3：分別驗證代理鏈的各個部分

使用預定的二進位程式執行檢查，需要時換成實際路徑：

xray version
xray run -test -config ./chain.json
ss -lntp '( sport = :10818 )'

啟動前須確認連接埠空閒。設定測試成功只證明可解析，不表示已連接兩端、通過身份認證或證明路徑。版本或載入設定與登記不符便停止。

建立兩份私有副本作單跳檢查。A 副本的路由規則選 entry-a；B 副本保持選 exit-b，但只移除 B 的 sockopt.dialerProxy。每次只在預留連接埠啟動一個前景實例，請求 T 並保存相應伺服器證據，按 Ctrl-C 停止後才啟動下一個。

B 單跳檢查須從已有授權的來源或 B 自己受控的測試環境發起。若 B 只允許 A，就在 A 檢查 B；不能為了客戶端基線擴大公網存取。基線來源及預期出口須與最終代理鏈分開記錄。

使用你控制且憑證可正常驗證的 HTTPS 目標。以下是讀者操作指令，並非本文的實測結果：

curl --fail --show-error --connect-timeout 5 --max-time 15 \
  --noproxy "" --proxy socks5h://127.0.0.1:10818 https://target.example.com/health

執行前先替換目標。socks5h 將目標名稱交給代理，並不捕獲無關系統 DNS 或瀏覽器自己的安全 DNS 請求。組合兩跳前，先分清拒絕連接、TLS 錯誤、憑據錯誤與目標拒絕。

--noproxy "" 只為本指令覆蓋繼承的 NO_PROXY／no_proxy 排除清單，否則匹配目標即使指定 --proxy 仍可能直連。單跳、鏈式及斷跳檢查均須保留此參數；它不會更改其他應用的代理設定。［7］

步驟 4：組合兩跳並對照證據

還原原來的鏈式設定，再作檢查，以 xray run -config ./chain.json 在前景啟動。透過明確指定代理的指令發起新請求，對照 C、A、B、T 的時間及授權目標，並考慮時鐘偏差；重用舊連接可能掩蓋新身份認證失敗。

在 A 確認獲准客戶端身份及通往 B 的出站連接。在 B 確認來源對應 A，且有目標請求。A 的出口可能經 NAT，應記錄轉換後的預期來源，不可假設 B 看見的就是 A 的介面地址。

比較公網出口時，用已明確設定此 SOCKS 入口的瀏覽器設定檔核對網站看見的出口地址。該請求應顯示 B 的出口，但觀察只適用於該次請求；不能替代逐跳記錄，也不代表所有應用都經 B。

只保留短時間且受控的日誌。若按實例的官方日誌設定暫時啟用存取日誌，完成診斷後恢復原政策。不收集載荷或公開密碼，也不能只因日誌沒有記錄便聲稱流量已被阻擋。

步驟 5：檢查 DNS、地址族及故障行為

下表列出讀者檢查及預期政策，並非測量結果。每次只改一項條件並使用新連接，下一項前先恢復已知正常設定。

檢查方法	預期現象	失敗時處理
新的鏈式 TCP 請求	A、B 記錄可對應 T	停止並核對 tag、TLS 及路由
依次使用 A、B 的錯誤測試密碼	各項受影響的新請求失敗	檢查身份選擇及非預期路由
只停止專用 A 實例	新的鏈式請求失敗	查直連分支或其他代理層
恢復 A，再只停專用 B	新的鏈式請求失敗	只經 A 的出口不能算成功
請求受控 IPv4-only、IPv6-only 目標	聲明支援的地址族均經 B 抵達 T	列明不支援範圍並查 B 的路由
對照名稱與數字地址請求	目標 DNS 路徑符合解析設計	分別查客戶端、A、B 及應用解析器
應用需要 UDP 或 QUIC	本 TCP 示例不足以涵蓋	另用有文件及驗證的設計

不可為故障檢查停止共用服務。示例以 IP 字面量連接 A、B，避免其引導解析，但 TLS 仍會核對名稱。SOCKS 轉交的目標名稱須在相應出口路徑解析；單設 routing.domainStrategy 不是防止 DNS 外洩的政策。［3］［6］

瀏覽器可能選用不同協議或繞過代理設定，需要獨立檢查。受控私網目標若因地址重疊而失敗，先處理重疊子網的拓撲；多加一跳無法區分兩台同地址機器。

步驟 6：撤銷測試並恢復基線

只停止你啟動的前景程序，確認回環監聽消失。撤銷 A、B 的專用身份，驗證其新身份認證連接會失敗；若伺服器撤銷機制不關閉舊連接，也須終止餘下測試工作階段。

只恢復本次應用代理設定、臨時日誌及精確防火牆例外。按政策保留最少已脫敏證據後，移除私有設定副本。不能刪除共用設定目錄或清空防火牆作清理。

獨立回讀管理存取、原監聽、路由及 DNS。無法確認恢復便停止後續實驗，使用恢復控制台。若保留代理鏈，另行確定憑據輪換、憑證續期、日誌保留及故障行為的運維責任。

總結

• 先證明各跳可用，再使用鏈式撥號。
• 逐跳記錄須配合最終出口觀察。
• 列明 TCP、DNS 及地址族限制。
• 意外直連應判為驗收失敗。

常見問題

兩跳是否自動提供匿名性？

不會。營運者、時間關聯、帳戶及目標標識仍可能把活動連起來；第二跳只是改變路徑，不能證明匿名。

dialerProxy 應放在 A 還是 B 的出站？

本客戶端設計放在 B 的出站，引用 A 的出站 tag，使 B 的底層連接經 A 建立。

可否保留直連作預設出站？

本驗收政策不允許。未匹配流量須拒絕，另行獲准的直連分支也要明確界定範圍及檢查失效行為。

網站顯示 B 是否證明 Xray 代理鏈成立？

不能。網站只識別其觀察到的出口，須結合 A、B 的相關證據，才可區分代理鏈與直接連接 B。

這個設定涵蓋 UDP 及整台裝置嗎？

不涵蓋。入口停用 UDP，只接受明確設定代理的應用；系統服務及其他應用繼續使用原來的網絡路徑。

排查失敗時應停用憑證驗證嗎？

不應。分別核對憑證名稱、信任鏈、系統時間及端點；繞過驗證會改變安全契約，而非修好故障。

若無法控制兩跳應怎樣處理？

除非擁有者提供所需授權及證據，否則停止此流程。未知第三方端點不能滿足本指南的驗收條件。

來源:

1. Xray-core — Release v26.3.27
2. Project X — Trojan outbound and credential fields
3. Project X — Sockopt
4. Project X — Socks inbound
5. Project X — Transport Configuration
6. Project X — Routing
7. curl — --noproxy and proxy environment variables

Sources checked 2026 年 10 月 11 日。

---

延伸閱讀：

• 區分重疊私網地址
• 理解第二跳增加的信任關係
• 分清 Xray 核心與客戶端
• 選擇應用或裝置覆蓋