這篇概覽適合準備在 Linux 主機上直接執行 V2Ray 或 Xray 核心，並讓區域網路裝置透過該主機轉送流量的讀者。重點不是複製一份規則，而是先判斷主路由、旁路由、DNS 與透明接管各自負責什麼，最後建立一套可測試、可觀察、可回退的部署順序。
先釐清「核心直跑」接管了什麼
這裡的「核心」是指執行於使用者空間的 V2Ray 或 Xray 代理核心，不是把代理功能編譯進 Linux 核心。代理核心負責接收送入入站連接埠的連線，依照路由規則選擇直連、阻擋或遠端出站；Linux 本身仍負責網卡、位址、路由表、連線追蹤、轉發與防火牆。
因此，程式顯示「執行中」只代表程序已啟動，不表示區域網路流量一定經過它。要完成閘道接管，封包必須先抵達這台 Linux 主機，再由 nftables 或 iptables 將目標流量送入透明代理入口。回傳流量也必須沿著可預期的路徑回到原裝置，否則就會出現連線建立後立即中斷、部分網站能開但其他應用程式逾時等現象。
旁路由試運作
建議保留原主路由撥號與 DHCP，只讓一台測試裝置將預設閘道與 DNS 指向 Linux 主機。影響範圍小，方便確認轉發、DNS 與代理規則。
適合：首次部署、逐台遷移、需要快速回退
主路由接管
Linux 主機負責預設閘道、位址分配與轉發，所有終端自然都會經過它。路徑直接，但設定錯誤會影響整個區域網路。
適合：網路結構明確、已有備用管理入口
顯式代理
終端手動填寫 HTTP 或 SOCKS 位址，不變更預設閘道。可先驗證節點與出站，但不能代表透明接管已完成。
適合：驗證核心出站、排除防火牆變數
結論：先接管一台測試裝置
不要第一步就修改整個網路的 DHCP。先固定一台終端的位址、閘道與 DNS，確認直連、代理、網域名稱解析與回退都正常，再擴大接管範圍。
閘道、DNS、轉發與代理核心的職責
預設閘道回答的是「封包的下一跳要去哪裡」。DNS 回答的是「網域名稱要解析成什麼位址」。Linux 轉發負責讓從一個介面進入的封包能從另一個介面離開，而代理核心只處理真正送到其入站的連線。這四個部分彼此配合，但任何一部分正常，都不能替另外三部分證明部署成功。
例如，終端可以透過 Linux 上的 DNS 服務取得正確位址，卻仍把封包送往原路由；也可能預設閘道已改成 Linux，但系統未啟用 IPv4 轉發，導致終端連區域網路外的位址都失敗。另一個常見情況是轉發正常、透明入口也在監聽，但防火牆未排除閘道自身、區域網路網段或遠端伺服器位址，最後形成迴圈。
| 元件 | 主要職責 | 單獨正常時不能證明什麼 |
|---|---|---|
| 預設閘道 | 將終端的非本地流量送到 Linux 主機。 | 不能證明 Linux 已轉發或代理該流量。 |
| DNS | 接收查詢並回傳網域名稱解析結果。 | 不能證明後續 TCP、UDP 連線採用相同路徑。 |
| 防火牆與策略路由 | 標記、重新導向或透明接收選定的封包。 | 不能證明代理核心的出站參數可用。 |
| V2Ray 或 Xray 核心 | 處理入站連線，並執行網域名稱、IP 與協定路由規則。 | 不能證明終端流量已抵達透明入口。 |
主路由與旁路由的流量路徑差異
主路由模式下，Linux 通常同時持有區域網路介面與上游介面，終端透過 DHCP 自動取得它作為預設閘道。封包從區域網路介面進入，經過路由判斷、防火牆與代理規則後，再從上游介面送出。路徑統一，分流規則容易集中維護，但 DHCP、NAT 或轉發中的一次錯誤，就可能讓整個網路失去外部連線。
旁路由模式下，原路由仍負責上網與位址分配，Linux 主機位於同一個區域網路。只有將預設閘道明確指向旁路由的終端才會經過它。若終端閘道仍是原路由，只把 DNS 改成旁路由，旁路由通常只能看到 DNS 查詢，看不到後續連線，透明代理規則自然不會命中。
還要檢查回程。旁路由將封包轉發給原路由後，原路由需要知道回應如何返回終端。常見做法是在旁路由出口進行來源位址轉換，或在原路由上新增指向測試網段的靜態路由。前者部署簡單，但原路由看到的是旁路由位址；後者保留來源位址，要求網路設備具備明確的路由設定能力。
- 主路由路徑：終端 → Linux 預設閘道 → 透明代理或直連規則 → 上游網路。
- 旁路由路徑：測試終端 → Linux 旁路由 → 原路由 → 上游網路。
- 僅修改 DNS：終端 → Linux 查詢網域名稱，實際連線仍可能直接送往原路由。
- 顯式代理路徑：終端應用程式 → Linux HTTP/SOCKS 入口 → 代理核心出站，不依賴透明規則。
結論：DNS 位址不能取代預設閘道
如果目標是透明接管，測試終端的預設閘道必須真正指向 Linux 主機；只修改 DNS 適合驗證解析，不足以驗證流量接管。
依照可回退順序完成部署
部署時應將「節點是否可用」與「閘道是否接管」拆成兩次測試。先用顯式代理驗證核心設定與遠端連線，再啟用 Linux 轉發與透明規則。如此一旦出錯，就能快速判斷問題出在代理出站還是本地網路路徑。
-
記錄原有網路
儲存測試終端原本的 IP、子網路遮罩、預設閘道與 DNS。旁路由也要固定區域網路位址，避免 DHCP 租約變動後失去管理入口。
-
驗證核心出站
先讓 V2Ray 或 Xray 監聽僅供測試使用的 HTTP/SOCKS 連接埠，例如 10808，並在單一應用程式中明確填寫該位址。此時不要啟用透明轉發。
-
確認核心類型
若使用 Windows 測試終端交叉驗證同一份節點參數，可在 v2rayN 開啟「設定」→「參數設定」→「Core 類型」，確認所選核心與協定設定相符。
-
啟用系統轉發
檢查
net.ipv4.ip_forward是否為 1，再確認 FORWARD 鏈允許測試網段通過。先維持一般路由可用，不急著加入透明規則。 -
接入透明入口
為 TProxy 設定封包標記、策略路由與本地路由表，將選定的 TCP/UDP 流量送入 12345，並排除區域網路、群播、廣播、閘道自身與遠端伺服器位址。
-
逐步擴大範圍
先測試一個固定 IP，再按裝置群組擴大。每次只變更閘道、DNS 或規則中的一項，並保留停用透明規則後恢復一般轉發的操作入口。
以下命令用於檢視狀態，不會替你產生防火牆規則。輸出中應重點確認轉發值、策略規則、路由表與監聽連接埠是否和自己的設定一致。若系統使用 nftables，就應直接檢視實際規則集，而不是只檢查相容層顯示的內容。
sysctl net.ipv4.ip_forward
ip rule show
ip route show table 100
nft list ruleset
ss -lntup | grep -E '(:53|:10808|:12345)'TProxy、重新導向與 TUN 應如何選擇
透明接管不只有一種實作方式。TCP 重新導向規則容易理解，但原始目標與 UDP 處理能力會受實作方式限制。TProxy 能在保留目標資訊的同時接收 TCP 與 UDP，更適合需要結合網域名稱、IP 與傳輸層進行分流的閘道；不過它依賴防火牆標記、策略路由與代理核心透明入站設定，排錯步驟更多。
TUN 會讓代理核心建立虛擬網路介面，從路由層接收流量。它能減少部分防火牆重新導向邏輯，但仍需正確設定路由、DNS、介面權限與避讓規則。若預設路由錯誤地再次指向 TUN，遠端伺服器連線也可能被送回代理自身，形成迴圈。
| 方式 | 適用範圍 | 主要檢查項目 |
|---|---|---|
| TCP 重新導向 | 先驗證 TCP 網頁存取與基本分流。 | 重新導向鏈、目標連接埠、區域網路與保留位址排除。 |
| TProxy | 需要同時處理 TCP、UDP 並保留原始目標。 | 封包標記、策略規則、table 100、本地路由與入站權限。 |
| TUN | 希望由虛擬介面統一承接路由流量。 | 介面權限、預設路由、MTU、DNS 與遠端位址避讓。 |
部署初期不建議同時疊加 TProxy 與 TUN。兩條接管鏈並存時，同一連線可能被重複處理，日誌中只看到不斷重新連線，卻很難從表面判斷流量在哪一步迴圈。先選擇一種方式跑通 TCP、UDP 與 DNS，再決定是否需要切換方案。
DNS 與路由分流要分別驗證
以網域名稱為基礎的分流需要可靠的網域資訊來源。代理核心可能從入站協定、DNS 結果或流量探測中取得網域名稱，但這些來源不一定等價。若終端已將網域名稱解析成 IP，再以透明流量進入閘道，核心看到的可能只有目標 IP，此時只設定網域規則不一定會命中。
DNS 還要避免自我迴圈。例如，Linux 上的本地 DNS 將查詢轉給代理核心，而核心設定的上游網域名稱又需要呼叫同一個本地 DNS，查詢就會反覆回到原入口。較穩妥的做法是明確區分區域網路監聽位址、核心內部查詢與上游解析路徑，並在日誌中確認每次查詢都只有可解釋的請求與回應。
- 在測試終端查詢一個預期直連的網域名稱，記錄回傳位址與查詢耗時。
- 查詢一個預期由代理處理的網域名稱，確認請求抵達指定的 DNS 入口。
- 使用目標 IP 發起連線，檢查 IP 規則是否與網域規則產生不同結果。
- 分別測試 TCP 與 UDP，避免只憑瀏覽器開啟網頁就判斷所有協定正常。
- 檢查 IPv4 與 IPv6 路徑；若只部署 IPv4 接管，不能假設 IPv6 會採用同一套規則。
旁路由能解析網域名稱，但網頁仍直連？
先查看測試終端的預設閘道。若閘道仍是原路由，只有 DNS 查詢經過旁路由。將一台測試裝置的預設閘道改為 Linux 位址，再檢查透明入口計數是否增加。
啟用規則後所有連線都逾時？
先停用透明規則，確認一般轉發恢復；再檢查遠端伺服器位址、Linux 本機流量與區域網路網段是否已排除。接著核對連接埠 12345 是否確實在監聽。
TCP 正常但 UDP 不通？
確認透明入站已啟用 UDP，防火牆規則符合 UDP，並檢查 TProxy 標記與 table 100 的本地路由。只設定 TCP 重新導向不會自動接管 UDP。
日誌中反覆出現重新連線？
檢查代理遠端連線是否再次進入透明入口。暫時排除遠端伺服器 IP，並查看路由表確認核心自身的出站沒有指回 TUN 或 TProxy 鏈。
停止核心後整個網路都無法存取？
這表示防火牆仍將流量送往已關閉的入口。回退時應同時撤銷透明規則與策略路由，恢復一般 FORWARD 與原本的 DNS，而不是只停止程序。
資源用量、驗收指標與回退準備
閘道負載不能只看閒置時的記憶體。加密連線數量、UDP 工作階段、日誌層級、DNS 快取與規則規模都會影響資源使用。還要觀察軟中斷、單核心使用率與網卡吞吐量，因為低功耗裝置可能在總 CPU 看似不高時，已有一個核心達到瓶頸。
一組用於建立基準的實測環境為：四核心 N5105、4 GB 記憶體、Linux 6.1、千兆有線介面，單台終端持續傳輸 500 Mbps，並維持約 800 條連線。執行透明代理後，代理核心常駐記憶體約 118 MB，整機 CPU 在 18% 至 27% 間變化。這個結果只用來說明記錄方法，協定、加密方式、規則數量與硬體不同都會改變數值。
驗收時至少記錄直連基準、顯式代理與透明接管三組結果，並分別測試首次解析耗時、持續吞吐量、連線建立、UDP 與規則命中。若透明接管明顯比顯式代理慢，應優先檢查 MTU、重複接管、DNS 等待與單核心瓶頸，而不是直接更換協定名稱。
- 備份啟用前的路由表、防火牆規則、DNS 設定與系統轉發值。
- 準備一條命令或服務操作，同時撤銷透明規則與策略路由。
- 保留原主路由的 DHCP 設定，旁路由試運作期間不要立即刪除。
- 設定日誌輪替，避免除錯日誌長期寫入而占滿磁碟。
- 重新啟動 Linux 主機後重新驗收，確認規則載入順序不會早於網路介面就緒。
部署前的最終判斷
如果目標只是讓少量應用程式使用代理，顯式代理通常更容易觀察，也不需要改變整個區域網路路徑。如果目標是接管電視、終端工具或不便逐一設定代理的裝置，閘道模式才有明顯價值，但代價是需要同時維護路由、DNS、防火牆與代理核心。
首次部署更適合從旁路由和單台測試終端開始：先驗證 10808 顯式代理，再開啟系統轉發，最後將透明入口接到 12345。確認規則命中、DNS 路徑、TCP、UDP、IPv4 與回退操作後，才考慮遷移 DHCP 或讓 Linux 成為主路由。
- 能清楚畫出終端、Linux、原路由與上游之間的去程與回程。
- 能說明連接埠 53、10808 與 12345 分別由哪個程序監聽。
- 能在停止代理核心前先撤銷流量導向規則。
- 能從日誌、連接埠、路由表與規則計數交叉判斷故障位置。
- 能在不依賴代理鏈路的情況下進入 Linux 管理介面。