iptables不直接实现代理，而是通过REDIRECT或TPROXY将流量重定向至本地代理进程实现透明代理；需开启IP转发、内核模块及代理服务透明模式支持，并注意HTTPS透传与安全限制。

iptables 本身不直接实现代理功能，而是通过 REDIRECT 或 TPROXY 目标将流量重定向到本地或远端代理进程（如 Squid、Privoxy、SSR、Trojan、Dante 等），配合内核路由与 netfilter 机制达成“透明代理”效果。关键在于：流量在不修改客户端配置的前提下被拦截并转发，且应用层协议（如 HTTP/HTTPS）需额外处理证书或 TLS 透传问题。

一、基础前提与网络拓扑确认

透明代理依赖明确的流量路径和内核支持：

• Linux 内核需启用 CONFIG_NETFILTER_XT_TARGET_REDIRECT 和 CONFIG_IP_NF_NAT（通常默认开启）；IPv6 代理还需 CONFIG_IP6_NF_NAT
• 主机必须开启 IP 转发：echo 1 > /proc/sys/net/ipv4/ip_forward，并写入 /etc/sysctl.conf 持久化
• 典型场景：网关机器（如 OpenWrt、Debian 路由器）拦截局域网设备流量；或单机上拦截本机出向流量（OUTPUT 链）
• 确认代理服务已监听在 127.0.0.1:1080（SOCKS）或 127.0.0.1:3128（HTTP）等端口，且支持透明模式（如 Squid 需配置 http_port 3128 transparent）

二、iptables 重定向规则（常用 REDIRECT 方式）

适用于 IPv4、TCP 流量，简单可靠，但仅支持本机代理（目标地址改为 127.0.0.1）：

• 拦截局域网流量（PREROUTING 链，网关模式）：
  iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 1080
• 拦截本机发起的流量（OUTPUT 链，单机模式）：
  iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-port 3128
• 排除本地回环与代理自身流量（避免循环）：
  iptables -t nat -A PREROUTING -s 127.0.0.1 -j RETURN
iptables -t nat -A PREROUTING -d 127.0.0.1 -j RETURN

三、进阶：TPROXY 实现真透明代理（支持非本机代理 & UDP）

REDIRECT 会改写目的 IP 为 127.0.0.1，丢失原始目标地址；TPROXY 不修改包头，配合策略路由保留原始五元组，适合需要识别真实域名或处理 DNS/UDP 的场景（如 Clash、Sing-Box 的 TPROXY 模式）：

• 加载必要模块：modprobe xt_socket xt_TPROXY_IPV4 nf_tproxy_ipv4
• 标记需代理的流量（如匹配 GFWList 域名的 DNS 查询结果，或基于 ipset）：
  ipset create proxyips hash:ip
iptables -t mangle -A PREROUTING -i eth0 -m set --match-set proxyips dst -j MARK --set-mark 1
• 用 TPROXY 重定向 TCP/UDP 到本地监听端口（如 1080）：
  iptables -t mangle -A PREROUTING -p tcp -m socket --nowildcard --repl-to-port 1080 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 1080
• 配置策略路由使 marked 包走特殊路由表：
  echo "100 tproxy" >> /etc/iproute2/rt_tables
ip rule add fwmark 1 table tproxy
ip route add local 0.0.0.0/0 dev lo table tproxy

四、HTTPS 与安全注意事项

透明代理 HTTPS 流量存在固有风险，不可绕过加密本质：

• 不能解密标准 HTTPS：除非在客户端安装自签名 CA 并信任（如 Squid 的 SSL Bump、mitmproxy），否则只能做 TCP 层转发（即“HTTPS 透传”），无法过滤/审计内容
• 代理服务需正确处理 SNI（Server Name Indication）：现代代理（Clash、Sing-Box）可基于 SNI 分流，无需解密即可识别目标域名
• 避免中间人风险：切勿在公共网络或不可信环境中部署主动解密 HTTPS 的透明代理
• 日志与审计：开启 iptables 日志（-j LOG --log-prefix "PROXY:"）便于排查规则是否命中；代理日志也应启用详细级别

透明代理不是万能隧道，它解决的是“流量怎么送过去”，而安全、隐私、合规取决于代理后端如何处理。配置前务必明确需求边界：是全局加速、广告过滤、企业审计，还是科学上网？不同目标对应不同架构选择（REDIRECT vs TPROXY vs eBPF）和合规红线。