開啟 3 天免費試用
註冊即可免費體驗全部高級功能。
*只限新用戶；每位用戶只可獲得一次試用。
Linux 透明代理如何選擇：REDIRECT、TPROXY 與 TUN
Ryan Foster
2026年10月11日· 8 分鐘讀完
Linux 透明代理讓流量進入代理，而毋須每個應用程式自行指定代理。REDIRECT 改寫目的地，將流量送往本地監聽；TPROXY 結合透明通訊端與政策路由；TUN 則把送入虛擬介面的 IP 封包交給用戶態程式。選擇取決於你控制的流量、實作支援的協議，以及能否安全還原網絡。［1］［2］［3］
關鍵要點
- 捕獲、路由投遞與代理協議支援是不同責任。
- TPROXY 需要合適路由及程式支援，並非只開連接埠。
- TUN 是 IP 介面，不保證加密或完整涵蓋。
- 優先使用獨立 network namespace，並保留管理通道。
Linux 透明代理選型應考慮甚麼？
以一部獲授權 Linux 主機或閘道、一部測試客戶端及一個自有目標開始。分開主機本身產生的流量與轉送的區域網絡流量；閘道 prerouting 和本機程式 output 是不同入口，前者設定不會自動適用於後者。
用自建服務規劃方法列明網絡負責人、維護時段及還原通道。若只是讓受支援程式使用裝置代理，先比較系統代理及 TUN 的程式涵蓋範圍，再承擔防火牆與政策路由責任。整機隧道與程式代理的範圍亦對應不同任務。
本文比較機制，並非通用安裝程序。以 Linux 核心 TPROXY、TUN 文件及 Xray 通訊端選項說明實作邊界，沒有聲稱作者完成端到端實驗、吞吐量測試或發行版兼容矩陣。實作前核對實際核心、防火牆後端、代理版本與支援功能。［1］［2］［3］
Linux 透明代理路由為何須與捕獲分開？
把連線視為三層交接：捕獲選出進入代理路徑的封包，路由將其送到正確監聽或介面並維持回程一致，代理程式再處理傳輸協議及建立獲允許的出站連線。
| 責任 | 管理員要問的問題 | 應保留的證據 |
|---|---|---|
| 捕獲 | 哪些來源、目的地、協議及 hook 符合？ | 限定規則計數與指定客戶端 |
| 本地投遞 | 封包為何交給這個程序？ | 監聽位址、政策規則、路由、namespace |
| 代理處理 | 實作是否支援所需傳輸？ | 版本設定及單一流量診斷 |
| 回程 | 回覆如何到達原客戶端？ | 客戶端回應與預期路由 |
| 排除 | 哪些管理及代理自有流量繞過捕獲？ | 管理不變與有界計數 |
計數上升只證明規則符合，不證明代理轉送成功；監聽連接埠只證明通訊端存在，不證明封包已到達。TCP 網頁請求正常只證明該請求，不能代替 UDP、DNS 或另一條路由上程式的驗證。
選擇欄位前畫清角色，並把 DNS 當成獨立路徑。客戶端可向路由器解析器、程式自有解析器或合成位址服務查詢。Mihomo DNS 模式診斷解釋客戶端取得的位址為何可能不同於實際出站目標。
REDIRECT 及 TPROXY 何時適合？
REDIRECT 透過目的地轉換將連線送至本地監聽，接收實作須正確還原或以其他方式取得原目標。核心文件說明了轉換限制，包括原目標處理；更改連接埠並不代表所有程式都能保留正確目的地。［1］
TPROXY 可在不作相同目的地改寫下，把封包送至透明通訊端；仍需政策路由完成本地投遞，也要求程式支援透明通訊端。核心例子解釋這些依賴，不是每部生產主機可直接使用的完整防火牆。照搬標記或路由表編號，可能與既有負責人衝突。［1］
| 比較項目 | REDIRECT | TPROXY | TUN |
|---|---|---|---|
| 捕獲對象 | 目的地已轉換的連線 | 送往透明通訊端的指定封包 | 路由至虛擬 IP 介面的封包 |
| 原始目標 | 由實作正確取得 | 保留在封包位址中 | 用戶態可從 IP 封包讀取 |
| TCP 及 UDP | 視監聽而定；Xray redirect 文件為 TCP | Xray tproxy 文件支援 TCP 及 UDP | 視用戶態堆疊與出站實作而定 |
| 路由歸屬 | Netfilter 路徑及本地監聽 | 標記、政策規則、本地投遞路由 | 介面路由與排除項 |
| 權限邊界 | 防火牆及相關通訊端權限 | 防火牆、政策路由及透明通訊端權限 | 介面建立設定與程式存取 |
| 常見故障 | 目標錯誤或傳輸不支援 | 缺投遞路由或自我循環 | 路由過闊或封包處理不支援 |
TPROXY UDP 支援須按實作核對：Xray 文件把 Linux redirect 描述為 IPv4/IPv6 TCP，tproxy 則為 IPv4/IPv6 TCP 及 UDP；透明代理需要 root 或 CAP_NET_ADMIN。這是 Xray 的特定邊界，不是所有 REDIRECT 程式均有相同能力。實作結論應與其來源一併表達。［2］
TUN 增加甚麼，又留下甚麼問題？
TUN 讓用戶態程式讀寫 IP 封包，核心將其與處理 Ethernet 訊框的 TAP 區分。建立介面、分配路由和實作可用代理傳輸並非同一工作。［3］
某個用戶態堆疊可把指定 TCP、UDP 流量轉成代理連線，其他程式可能採用另一種隧道設計。介面名稱或 tun 開關不能證明 DNS 涵蓋、IPv6 轉送、加密或斷線阻擋；應核對實作文件及觀察路徑。
預設路由送入介面時，歸屬尤其重要。代理自身出站須能到達遠端端點而不再次進入自己；管理、本地資源與回程均須有清楚安排。若過闊路由捕獲控制通道，可能未開始診斷數據面已先失去管理。
優先採用即棄虛擬機或專用 network namespace，讓客戶端、監聽、介面及路由都有明確負責人。namespace 可減少誤碰，但主機防火牆、轉送設定及實體介面仍屬獨立責任，不能把隔離當成修改共用主機網絡的授權。
如何安全評估一條獲授權路徑？
變更前寫清實驗契約：主機與 namespace、一個客戶端來源、自有目標、協議、預期路由、排除、觀測方法及各項逆操作。管理連線應置於捕獲來源或介面之外；沒有獨立主控台或可靠回復方法，就停在機制比較。
以下唯讀指令可記錄 Linux 基線，不會建立代理；權限及輸出可見性視環境而定。分享診斷時，應私下保存位址、規則及程序資料。
uname -r
ip -brief address
ip rule show
ip route show table all
ss -lntup
使用符合實際後端的防火牆檢查工具，不混用 legacy iptables 與 nftables。預留新對象前記錄已有表、標記、優先次序及路由。已使用的連接埠或標記有其服務負責人，不可覆蓋或終止程序。
按所選實作的官方方法排除代理自有出站通訊端。排除可能依賴程序身份、標記、介面或目標，須配合路由投遞。計數急升、相同目標重複及資源消耗快速增加，可能表示循環；停止測試並執行逆操作，不靠提高限制繼續。
本文刻意不提供可直接複製的防火牆規則。拓撲、後端、namespace、代理支援設定與還原必須同時確定，指令才有安全適用條件。概念表選出某機制，不足以支持臨時新增全域規則。
哪些觀察能證明成功或失敗？
在獲授權範圍安排正反測試，需要 UDP 時選自有服務。DNS 查詢只證明那次交換，不代表所有 UDP 程式。紀錄限定測試中繼資料，不擷取其他用戶內容。
| 檢查方法 | 預期現象 | 失敗處理 |
|---|---|---|
| 一條指定 TCP 連線 | 規則、監聽、出站與回應一致 | 逐層追查交接再改其他層 |
| 一次獲授權 UDP 交換 | 支援傳輸，回覆到達客戶端 | 核對實作與回程 |
| 重做排除的管理請求 | 管理不進入捕獲 | 先移除測試捕獲 |
| 觀察代理自有出站 | 不會遞迴進入代理 | 停止並修正排除 |
| 新 DNS 及 IPv6 檢查 | 各自符合指定政策 | 記錄未驗證並限制部署 |
| 停止測試代理 | 失敗或直連後備符合設計 | 拒絕非預期直連逃逸 |
涉及互聯網出口時，檢查該請求的公網出口，另測 DNS、IPv6、UDP 及斷線行為。只比較本地捕獲時，IP 網頁不能代替路由證據。捕獲以外的系統解析問題，另按Ubuntu DNS 歸屬檢查處理。
還原能力如何影響選擇？
選擇能逐項命名和撤銷、不影響其他服務的機制。記錄每條測試規則、路由、政策規則、介面、程序及臨時設定，註明 namespace 與持久設定負責人。還原既要撤銷執行狀態，也要移除啟動來源，否則實驗可能在重新啟動後回來。
按依賴的逆序，只移除本次建立對象。不要用 nft flush ruleset、清除全部政策規則或重設主機預設路由作通用清理。若對象已被另一負責人使用，應停下協調而非盲目刪除。
還原後比較管理存取、一般路由、解析設定與原基線，確認測試監聽或路由沒有殘留，並恢復本來需要保留的代理。日常使用的代理或 VPN 客戶端及無關客戶端維持原狀。瀏覽器可用只是輔助觀察，不能取代對象清單比較。
總結
- 按協議支援、投遞依賴及可還原的對象歸屬選擇。
- 分別觀察捕獲、路由、DNS 及代理處理。
- 限定一條獲授權路徑並排除管理流量。
- 撤銷已命名測試對象、確認還原後再擴大範圍。
常見問題
TPROXY 是否一定較 REDIRECT 好？
TPROXY 有不同的目標與投遞語義，也增加政策路由責任。只有實作及傳輸需求確實需要，而且能還原狀態時才選擇。
所有代理的 REDIRECT 都支援 UDP 嗎？
UDP 支援取決於接收程式及原目標處理。Xray redirect 文件說明的是 TCP，不能從 Netfilter 名稱推斷其他實作能力。
TUN 是否會加密捕獲流量？
TUN 把 IP 封包交給用戶態，加密取決於程式及出站傳輸。主機有這個介面，不代表已建立加密隧道。
為何規則符合但流量到不了監聽？
規則命中只證明捕獲。缺少政策路由、監聽位址不正確或 namespace 不一致，均可令計數上升卻無法投遞。
可以沿用核心示例的路由表 100 嗎？
使用前先確認該表的現有負責人及實作要求。文件例子解釋依賴，並沒有替你的系統預留編號。
網頁正常可否證明 UDP 及 IPv6 已涵蓋？
網頁請求只證明自身路徑及協議。獨立檢查自有 UDP、IPv6 路由、DNS 與失敗行為後，才可提出更廣涵蓋結論。
刪除 namespace 是否足以還原全部設定？
刪除隔離 namespace 不會自動撤銷主機側規則及持久設定。列出各項變更歸屬，移除後核對原管理、路由與 DNS。
免責聲明：結論根據所列公開實作文件，沒有聲稱作者完成整體實驗。實際變更須獲授權、固定拓撲，並保留可獨立使用的還原通道。
來源:
- Linux kernel — Transparent proxy support — https://cdn.kernel.org/doc/html/latest/networking/tproxy.html
- Project X — Sockopt — https://xtls.github.io/en/config/transports/sockopt.html
- Linux kernel — Universal TUN/TAP device driver — https://docs.kernel.org/networking/tuntap.html
Sources checked 2026 年 10 月 11 日。
延伸閱讀:
