Linux透明代理：TPROXY流量拦截教程

本文深入解析了Linux下基于TPROXY实现真正无感透明代理的核心原理与实战要点，揭示其并非开箱即用的代理方案，而是依赖iptables精准标记、内核参数调优、代理程序显式启用IP_TRANSPARENT及全链路透传支持的精密协同机制；文章直击常见配置陷阱——如误用REDIRECT导致目标端口丢失、忽略rp_filter引发回包丢弃、DNS与DoH绕过造成策略失效等，并给出可落地的最小可靠配置集与多语言代理适配方案，最终指出透明代理的本质挑战不在流量拦截本身，而在于如何在不破坏协议语义的前提下，从加密流量（如TLS SNI、QUIC）中安全、合规地还原用户原始访问意图。

TPROXY 为什么必须配合 iptables 的 REDIRECT 或 TPROXY target 使用

TPROXY 本身不是代理程序，而是一个内核机制，用于将流量“无连接地”转发到本地监听的透明代理（如 haproxy、privoxy 或自研服务）。它不修改数据包目标 IP 和端口，而是保留原始目的地址，让应用层能读取到真实目标 —— 这正是透明代理的核心前提。但内核不会自动把流量送过去，必须靠 iptables 在 mangle 表中用 TPROXY target 显式标记并重定向到指定端口。

常见错误是只配了用户态代理监听 0.0.0.0:12345，却忘了加 iptables 规则，结果流量根本没进代理；或者误用 REDIRECT（会改写 dst port，丢失原始目的端口），导致代理无法做基于目标域名或端口的策略分流。

• TPROXY 只支持 IPv4 的 mangle 表 PREROUTING 链，且要求 socket 绑定时使用 IP_TRANSPARENT 选项
• 代理进程必须以 root 或 CAP_NET_RAW 权限运行，否则无法 bind 到非本机 IP 或启用透明 socket
• 若需处理 IPv6，得用 ip6tables + TPROXY，规则结构类似但不能混用

iptables 规则怎么写才不丢包、不绕过

典型漏配点：只对 PREROUTING 做 TPROXY，却没关掉 rp_filter（反向路径过滤），导致回包被内核丢弃。TPROXY 流量的响应路径和请求路径不一致（请求进 eth0，响应可能从 lo 出），必须禁用严格模式。

正确最小集如下（假设代理监听在 127.0.0.1:1080，目标端口为 80/443）：

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A DIVERT -m socket -j ACCEPT
iptables -t mangle -A DIVERT -j TPROXY --tproxy-mark 0x1/0x1 --on-port 1080 --on-ip 127.0.0.1

关键点：

• -m socket 是核心：它匹配已建立连接或本地监听 socket 的包，避免对非目标流量误操作
• --tproxy-mark 需与后续路由规则配合，若只做本地透明代理，可简化为 --on-port 直接指定
• 务必确认 net.ipv4.conf.all.route_localnet = 1，否则发往 127.0.0.1 的 TPROXY 包会被丢弃

用户态代理如何正确启用 IP_TRANSPARENT 支持

不是所有代理软件默认支持 TPROXY。比如 nginx 需要编译时加 --with-stream_ssl_preread_module 并配置 transparent 参数；haproxy 要求 1.5+ 且 backend listen 必须带 transparent，同时启动时加 -d 或确保 ulimit -n 足够。

以 haproxy 为例，关键配置段：

frontend transparent_https
    bind 127.0.0.1:1080 ssl alpn h2,http/1.1
    mode tcp
    option tcp-check
    tcp-request connection set-var(req.dst_ip) req.dst_ip
    tcp-request connection set-var(req.dst_port) req.dst_port
    use_backend https_servers if { req.dst_port 443 }

backend https_servers
    mode tcp
    option ssl-hello-chk
    server gateway 192.168.1.100:443 transparent

注意：transparent 必须出现在 bind 和 server 行，且整个链路（包括 upstream）都要支持透传，否则代理拿到的是 127.0.0.1:1080 而非原始目标。

• Go 程序用 net.ListenTCP 时，需在 ListenConfig.Control 中调用 setsockopt(fd, SOL_IP, IP_TRANSPARENT, 1)
• Python 的 socket 模块不直接暴露该选项，得用 ctypes 或 socket.ioctl 手动设置 IP_TRANSPARENT
• 若代理日志里看到全是 127.0.0.1，基本是没开 transparent 或没设 IP_TRANSPARENT

为什么 DNS 查询经常被忽略，导致 HTTPS SNI 识别失败

TPROXY 只作用于 TCP/UDP 数据包，DNS 查询（尤其 UDP 53）若走普通路由，代理就收不到原始域名，无法做基于域名的策略（如直连国内站、代理境外站）。更麻烦的是，现代浏览器常通过 HTTPS DNS（DoH）或 QUIC 绕过系统 DNS，进一步削弱透明性。

可行解法有限，且都有代价：

• 用 iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 5353 强制本机 DNS 查询走本地 DNS 代理（如 dnsmasq 或 coredns），再由其转发并记录域名
• 对 DoH 流量，只能靠 TPROXY 拦截 443 端口后，在代理中解析 TLS ClientHello 的 SNI 字段 —— 但这要求代理支持 TLS 解析且不破坏证书链
• 完全放弃 DNS 透明，改用 PAC 或系统级代理设置，换取确定性

真正难的从来不是拦截，而是拦截之后怎么不失真地还原意图。SNI 可读，ALPN 不一定；QUIC 加密更彻底，目前没有标准方式在内核层提取目标域名。这类边界问题，往往得在架构层面接受妥协。

以上就是《Linux透明代理：TPROXY流量拦截教程》的详细内容，更多关于的资料请关注golang学习网公众号！