网络代理与移动安全攻防：从 TUN/iptables 到 Hook/TEE 的工程化全景

Thu, 26 Mar 2026 18:29:00 +0800

这篇是工程向版本：不聊概念套话，直接给分层模型 + 可验证命令。目标是把“流量怎么走”和“结果该不该信”彻底分开。

0) 先说结论（TL;DR）

SOCKS5 是本地入口接口，不是抗审查协议本体。
全局代理不止是改路由，常见是 TUN + 路由 或 Netfilter(iptables/nftables)。
iptables ≠ 路由表：前者改包/拦截，后者选路。
fake-ip 的价值是夺回 DNS 控制权，不是“拿假 IP 去公网通信”。
VPN 只能保证路径经过你，不保证你能看 HTTPS 明文。
Hook 的本质是控制流重定向，不是“改点内存”这么简单。
支付类 App 的核心是服务端裁决 + 硬件密钥边界，不是“客户端看起来对了就放行”。

1) 三个层次别混：入口、调度、封装

入口层：SOCKS5 / HTTP / TUN
调度层：Clash/OpenClash/sing-box（规则、分流、策略）
封装层：SS/SSR/VMess/VLESS/Trojan/TLS

一句话：你看到“本地 7890/1080”通常只是在入口层，不代表后面协议是什么。

2) “全局代理”到底改了什么（带命令）

2.1 SOCKS5/HTTP 手动代理（应用层）

应用主动把流量交给代理，系统路由本身可能不变。

验证：

1
2


# 看本地代理端口是否监听
lsof -nP -iTCP -sTCP:LISTEN | grep -E '1080|7890|7891'

2.2 TUN 模式（路由接管）

典型流程：创建 tun0 → 改路由 → 代理进程读 TUN fd。

验证：

1
2
3
4
5
6
7
8


# 看虚拟网卡
ip a | grep -A2 -E 'tun|utun'

# 看默认路由是否指向 tun
ip route

# macOS
netstat -rn | grep -E 'default|utun'

2.3 iptables 透明代理（内核链路接管）

不要求应用配代理，内核侧重定向/标记。

验证：

1
2
3
4
5
6


# 查看 NAT 表规则
sudo iptables -t nat -S
sudo iptables -t nat -L -n -v

# nft 环境
sudo nft list ruleset

3) 为什么说 iptables 不是路由表

对比：

路由表：决定“从哪张网卡走、下一跳是谁”。
iptables：决定“这个包要不要改、要不要丢、要不要重定向”。

实操对照：

1
2
3
4
5


# 路由决策（看某个目标会走哪）
ip route get 1.1.1.1

# 包计数变化（是否命中某条劫持规则）
sudo iptables -t nat -L -n -v | head -60

4) fake-ip 的关键：把 DNS 控制权拿回来

fake-ip 常见逻辑：

App 询问 example.com
代理返回保留网段假 IP（如 198.18.x.x）
App 连接假 IP
代理查映射表反解域名，再用可信 DNS 做真实解析并转发

排查命令：

1
2
3
4
5
6
7


# 直接查本机解析结果（对比开/关代理前后）
dig example.com

# 抓 DNS 包看请求打向哪里
sudo tcpdump -ni any port 53

# 如用 DoH/DoT，53 端口可能很少，需结合代理日志看

5) HTTPS 可见性边界：路径控制 ≠ 明文可见

典型误区：

“我有 VPN 服务器，流量都过我机子，为什么还是看不到请求正文？”

因为 TLS 端点通常是：App <-> 目标服务。中间节点看到的是密文。

可验证：

1
2


# 抓到的通常是 TLS record，不是 HTTP 明文
sudo tcpdump -ni any host <target_ip> and port 443

如果能看明文，一般说明你在终端侧成功做了 MITM（且 App 信任了你的证书链）。

6) Hook 的工程定义：改“执行路径”

更准确地说：

Hook = 在运行时把“调用 A”改成“先走你的逻辑，再决定是否回到 A”。

常见层级：

Java 层：方法替换/拦截（ART）
Native 层：PLT/GOT / inline hook
网络层函数：SSL_write / send 等

判断口诀：

改变量值，不一定是 hook
改调用去向，才是 hook 的核心

7) 支付/银行类 App 为何“看到了也不一定有用”

真实防线是多层组合：

环境检测：root、调试、注入框架
运行时完整性：关键路径自检、反篡改
密钥边界：Keystore/TEE，密钥不可导出
服务端裁决：签名复核、nonce/timestamp、设备指纹、行为风控

所以：

你可能拿到某段明文
但不代表你能伪造一个服务端接受的完整交易

8) 一套实战排障顺序（建议直接照这个查）

Step A：先确认“流量有没有经过代理”

1
2
3


curl --proxy socks5h://127.0.0.1:1080 https://ifconfig.me
curl https://ifconfig.me
# 两者出口 IP 是否不同

Step B：再确认“DNS 控制权在谁手里”

1
2


dig +short example.com
sudo tcpdump -ni any port 53

Step C：最后确认“你想看的数据在哪层”

抓包层只看到 TLS：正常
需要明文：要么 MITM 成功，要么在应用加密前拦截

9) 最后一句

网络代理解决的是 怎么走。
安全工程决定的是 该不该信。

把这两件事分开，你会少走很多弯路。

Android 安全 on lategege 的技术博客