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

0) 先说结论（TL;DR）

1. SOCKS5 是本地入口接口，不是抗审查协议本体。
2. 全局代理不止是改路由，常见是 TUN + 路由 或 Netfilter(iptables/nftables)。
3. iptables ≠ 路由表：前者改包/拦截，后者选路。
4. fake-ip 的价值是夺回 DNS 控制权，不是“拿假 IP 去公网通信”。
5. VPN 只能保证路径经过你，不保证你能看 HTTPS 明文。
6. Hook 的本质是控制流重定向，不是“改点内存”这么简单。
7. 支付类 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 常见逻辑：

1. App 询问 example.com
2. 代理返回保留网段假 IP（如 198.18.x.x）
3. App 连接假 IP
4. 代理查映射表反解域名，再用可信 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 为何“看到了也不一定有用”

真实防线是多层组合：

1. 环境检测：root、调试、注入框架
2. 运行时完整性：关键路径自检、反篡改
3. 密钥边界：Keystore/TEE，密钥不可导出
4. 服务端裁决：签名复核、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) 最后一句

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

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