tproxy必须配合iptables的tproxy target使用，因其仅为内核转发机制，不自动劫持流量；需通过mangle表prerouting链显式标记并重定向至本地透明代理端口，且代理须启用ip_transparent选项。
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 足够。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
以 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 加密更彻底，目前没有标准方式在内核层提取目标域名。这类边界问题，往往得在架构层面接受妥协。
