代理原理（一）：你的数据包是怎么翻过墙的
从 IP 地址和 DNS 讲起，拆解代理的本质、协议演进（SOCKS5 → SS → VMess → VLESS → Trojan → Reality）、传输层伪装、代理链与路由规则。
这篇文章的目标是让你从网络层彻底搞懂代理是怎么工作的。不讲”点击这个按钮”，只讲”数据包在链路上发生了什么”。
第零章：你需要知道的网络基础
在聊代理之前，先把三个核心概念钉死。
IP 地址：你的网络门牌号
每台联网设备都有一个 IP 地址，就像快递需要收件地址一样。但 IP 地址分两种——内网 IP 和 公网 IP，它们的分配方式完全不同。
内网 IP：路由器说了算
你的手机连上家里 WiFi 时，路由器运行一个叫 DHCP 的服务，从预设的地址池里挑一个 IP 分给你：
路由器 DHCP 配置（默认）：
地址池：192.168.1.2 ~ 192.168.1.254
子网掩码：255.255.255.0
手机连上 WiFi → 路由器分配 192.168.1.100
笔记本连上 WiFi → 路由器分配 192.168.1.101
iPad 连上 WiFi → 路由器分配 192.168.1.102内网 IP 有三个保留网段，全球统一规定，任何人都可以随便用，不会和公网冲突：
| 网段 | 范围 | 常见场景 |
|---|---|---|
10.0.0.0/8 | 10.0.0.0 ~ 10.255.255.255 | 企业网络 / 云服务器 |
172.16.0.0/12 | 172.16.0.0 ~ 172.31.255.255 | 较少用 |
192.168.0.0/16 | 192.168.0.0 ~ 192.168.255.255 | 家用路由器 |
这些 IP 只在局域网内有效——出了你家路由器就没人认。你家的 192.168.1.100 和隔壁老王家的 192.168.1.100 完全不冲突，因为它们在各自的局域网里。
公网 IP：运营商层层分配
公网 IP 是全球唯一的，由一套自上而下的分配体系管理：
IANA（全球 IP 地址管理机构）
│ 把 IP 大段分给五大区域注册机构
▼
APNIC（亚太区域）/ ARIN（北美）/ RIPE（欧洲）...
│ 把 IP 段分给各国运营商
▼
中国电信 / 联通 / 移动
│ 从分到的 IP 段里，给每个用户分配公网 IP
▼
你家的光猫/路由器 → 拿到公网 IP（如 113.45.67.89）NAT：内网和公网之间的”翻译官”
你家所有设备共用一个公网 IP，靠 NAT（网络地址转换） 来区分流量：
你的手机 (192.168.1.100) ──┐
你的笔记本 (192.168.1.101) ──┼──→ 路由器 NAT ──→ 公网 IP 113.45.67.89 ──→ 互联网
你的 iPad (192.168.1.102) ──┘
↑
路由器记录了"哪个内网设备发的哪个请求"
收到响应后，按记录转发回对应设备就像一栋公寓楼只有一个门牌号，快递员到了之后由门卫查登记表分发到各户。
CGNAT：为什么你可能连公网 IP 都没有
IPv4 地址全球只有约 43 亿个，早就不够用了。现在大多数家庭用户拿不到独立公网 IP——运营商用 CGNAT（运营商级 NAT） 让几十户共享一个公网 IP：
传统（有独立公网 IP）：
你家路由器 → NAT → 公网 IP 113.45.67.89 → 互联网
现在（CGNAT，无独立公网 IP）：
你家路由器 → NAT → 运营商内网 (100.64.x.x) → 运营商 NAT → 共享公网 IP → 互联网
↑
几十户共用一个公网 IP怎么判断自己有没有独立公网 IP？登录路由器管理页，看 WAN 口 IP：如果是
113.x.x.x之类的正常地址，你有独立公网 IP；如果是100.64.x.x或10.x.x.x，你在 CGNAT 后面。
移动网络：运营商直接当你的”路由器”
用手机流量时，没有家用路由器这一层——运营商的核心网设备直接充当你的”路由器”：
WiFi 场景：
手机 → 家用路由器(分配内网IP) → 路由器NAT → 公网IP → 互联网
手机流量场景：
手机 → 基站 → 运营商核心网(PGW/UPF) → 分配IP → CGNAT → 互联网
↑
运营商的 PGW（4G）或 UPF（5G）
就是你的"路由器"手机开流量后，基站把你的请求送到运营商核心网的网关设备（4G 叫 PGW，5G 叫 UPF），它通过 DHCP 给你分配一个 IP——几乎一定是运营商内网 IP，然后经过 CGNAT 出公网：
你手机拿到的 IP：10.147.32.85 （运营商内网，你看不到）
│
▼ 运营商 CGNAT
外面看到的 IP： 223.104.3.xx （共享公网 IP，可能几百人共用）移动网络和 WiFi 的关键区别：
| WiFi | 手机流量 | |
|---|---|---|
| 内网 IP 谁分配 | 家用路由器 | 运营商 PGW/UPF |
| 公网 IP | 可能有独立的 | 几乎不可能有独立的 |
| IP 稳定性 | 较稳定 | 不稳定（切基站就可能换 IP） |
| 同一公网 IP 共用人数 | 1 户（有独立 IP 时） | 几百人 |
为什么手机流量的 IP 经常变？ 你走路、坐车时会在基站间切换（Handover），每次切换到不同区域的基站，可能被分配到不同的 PGW，IP 就变了。飞行模式开关一次，IP 也会重新分配。
关键点：目标服务器看到的 IP = 你的公网 IP（不管是独占的还是共享的）。 这就是为什么网站能知道你”在哪里”，也是代理要解决的核心问题。
DNS：域名 → IP 的电话簿
你在浏览器输入 claude.ai，但网络只认 IP 地址。DNS 负责翻译：
你的设备: "claude.ai 的 IP 是多少？"
│
▼
DNS 服务器: "160.79.104.x"
│
▼
你的设备: → 连接 160.79.104.xDNS 污染：GFW（Great Firewall，防火长城） 是中国的互联网审查系统，负责封锁境外被禁网站。它的第一招就是在 DNS 环节动手脚——你问
google.com的 IP，它返回一个错误的地址（或者直接不回应）。你的请求还没出发就迷路了。这就是为什么很多代理工具需要自带 DNS 解析（如 DoH、DoT）来绕过污染。
TCP/TLS：数据怎么传输
互联网上传输数据就像寄快递，有一套分层的规则：
应用层 (HTTP/HTTPS) ← 你看到的网页内容
│
传输层 (TCP) ← 保证数据完整到达
│
网络层 (IP) ← 负责寻址（数据包该发往哪个 IP）
│
链路层 (以太网/WiFi) ← 物理传输（电信号/无线信号）- TCP（Transmission Control Protocol，传输控制协议）：保证你发的每个字节都完整、有序地到达对方。它会自动重传丢失的数据包、排列乱序的包——就像快递公司保证你的包裹不丢不乱。但 TCP 本身不加密，数据是明文的。
- TLS（Transport Layer Security，传输层安全协议）：在 TCP 之上加一层加密。你在浏览器地址栏看到的 HTTPS 里的 “S”（Secure）就是指 TLS。加密后，传输途中的任何中间人（包括 GFW）看到的都是乱码，无法读取内容。
TLS 握手：建立加密连接时，客户端和服务器要交换证书、协商密钥。这个握手过程中有一个字段叫 SNI（Server Name Indication）——它会明文告诉中间人”我要连的是哪个域名”。GFW 就是靠检查 SNI 来判断你是不是在访问被封锁的网站。这个漏洞后面讲 Reality 时会详细说。
第一章：代理的本质
不用代理时
你 (113.45.67.89) ───────────────→ claude.ai (160.79.104.x)
GFW 在这里检查
❌ 发现目标是 claude.ai
❌ 连接被重置 (RST)GFW 的检查手段：
- DNS 污染：让你查不到正确 IP
- IP 黑名单：直接封锁目标 IP
- SNI 检测：检查 TLS 握手中的域名
- 深度包检测（DPI）：分析流量特征，识别代理协议
用代理时
你 (113.45.67.89) ──[加密隧道]──→ 代理服务器 (美国) ──→ claude.ai
GFW 在这里检查 ↑
✅ 目标是代理服务器 网站看到的是这个 IP
✅ 流量看起来像正常 HTTPS
✅ 放行代理的本质就两件事：
- 隐藏目的地：GFW 只看到你在连代理服务器，不知道你最终要访问谁
- 隐藏身份：目标网站只看到代理服务器的 IP，不知道真实请求来自中国
第二章：协议演进 —— 一场猫鼠游戏
代理协议的演进史，就是一部和 GFW 的军备竞赛史。
Level 0：HTTP 代理 / SOCKS5（原始时代）
最朴素的方案：你告诉代理服务器”帮我访问 google.com”，它帮你转发。
你 → "CONNECT google.com:443" → 代理服务器 → google.com
↑
这段是明文！GFW 一眼看穿SOCKS5 比 HTTP 代理更通用（支持 TCP/UDP），但不加密。
SOCKS5 的用途：虽然不安全，但它在代理链中仍然很有用。比如你的住宅代理（Residential Proxy）通常就是 SOCKS5 协议——因为它运行在代理服务器和目标网站之间（已经在墙外了），不需要加密来躲避 GFW。
致命弱点：GFW 直接读取内容，秒封。
Level 1：Shadowsocks（2012）
由 @clowwindy 开发，开创了”加密代理”时代。
核心思想：把代理流量用对称加密（如 AES-256-GCM）加密，GFW 看到的只是一串随机字节。
你 → [AES加密(目标地址 + 数据)] → SS服务器 → 解密 → 目标网站
↑
GFW 看到的是随机数据
没有明显的协议特征为什么曾经有效？ 因为加密后的数据看起来和随机噪声一样，没有固定的协议头、没有可识别的模式。GFW 没有理由封锁”看起来随机”的流量——因为很多正常加密通信也是这样的。
怎么被破解的？ GFW 后来发现了一个关键线索：真正的随机数据在互联网上很少见。 正常的 HTTPS 流量虽然加密，但有 TLS 握手头、证书交换等固定结构。而 SS 的流量完全没有结构——这反而成了它的特征。GFW 开始用”没有特征”本身作为识别特征（被称为”流量白名单”策略）。
更致命的是 主动探测（Active Probing）。GFW 发现一个可疑 IP 后，会伪装成客户端主动去连它，根据服务器的回应来判断是不是代理。
SS 的协议设计没有握手过程——客户端发过来的第一个数据包就是加密的目标地址 + 数据。所以 SS 服务器收到任何非法输入时，解密失败后会静默关闭连接，什么都不回复。
这就成了致命指纹：
GFW 的探测手段：
探测 1：发一个 HTTP 请求 "GET / HTTP/1.1"
正常网站 → 返回网页（200 OK）
SS 服务器 → 静默关闭连接 ❌
探测 2：发一堆随机字节
正常网站 → 返回错误码（400 Bad Request）
SS 服务器 → 静默关闭连接 ❌
探测 3：发一个 TLS ClientHello
正常网站 → 返回 TLS 证书
SS 服务器 → 静默关闭连接 ❌不管 GFW 发什么，SS 服务器的反应都是”静默关闭”——正常服务器一定会回复某种东西（错误码、网页、证书），只有 SS 在解密失败时什么都不说就关门。 这个行为模式太独特了，GFW 一探一个准。
这也是为什么后面的 Trojan 和 Reality 要彻底改变策略——它们在收到非法请求时不再静默关闭，而是返回一个真实网站的内容，和正常服务器的行为一模一样，让 GFW 无法区分。
Level 2：VMess / V2Ray（2015）
V2Ray 项目引入了 VMess 协议，核心改进：可以把流量伪装成正常的 HTTP/WebSocket/gRPC 流量。
你 → [TLS加密 [WebSocket 帧 [VMess 加密(真实数据)]]] → V2Ray 服务器
↑
GFW 看到的：一个普通的 HTTPS WebSocket 连接
和你刷网页、用在线聊天没区别关键创新——传输层（Transport）与协议层分离：
| 层级 | 负责什么 | 选项 |
|---|---|---|
| 协议层 | 认证 + 加密真实数据 | VMess |
| 传输层 | 伪装成什么样的流量 | TCP / WebSocket / gRPC / HTTP/2 |
| 加密层 | 外层加密 | TLS |
这种分层设计影响了后来所有的代理工具。
VMess 的问题：协议本身设计了双重加密（自身 + TLS），性能有浪费。而且认证机制依赖时间同步，客户端和服务器时间差超过 90 秒就连不上。
Level 3：VLESS（2020）
VLESS 是 VMess 的”减肥版”——既然外层已经有 TLS 加密了，协议层就不需要再加密一次。
VMess: [TLS [WebSocket [VMess加密(数据)]]] ← 双重加密，浪费性能
VLESS: [TLS [WebSocket [VLESS明文(数据)]]] ← 信任外层 TLS，协议层只做认证VLESS 只保留了 UUID 认证（16 字节），去掉了所有加密逻辑。 性能更好，延迟更低。
UUID：一个 128 位的随机标识符，格式如
31ced8e4-0c46-4ec5-9510-89bb487667b9。客户端和服务器预共享同一个 UUID，用来验证身份——就像一个暗号。
Level 4：Trojan（2019）
完全不同的思路——不做任何伪装，直接把自己做成一个真正的 HTTPS 服务器。
你 → TLS 连接到 trojan-server.com:443
│
├── 如果发送正确的密码 → 进入代理模式，转发流量
│
└── 如果密码不对（包括 GFW 的探测）→ 返回一个正常网页
（如 Nginx 默认页）Trojan 的精髓：当 GFW 主动探测时，服务器返回的就是一个普通网站的内容——和真正的网站服务器完全一样。GFW 无法区分”这是一个代理”还是”这就是一个正常网站”。
弱点：你需要一个真实的域名 + 真实的 TLS 证书。域名和证书的申请过程会留下痕迹。
Level 5：VLESS + Reality（2023）⭐ 当前最强
Reality 解决了 Trojan 的最后一个弱点：连域名和证书都不需要是你的。
还记得前面说的 SNI 吗？TLS 握手时，客户端会明文告诉服务器”我要连的是 xxx.com”。GFW 会检查这个 SNI。
Reality 的做法是：SNI 填一个真实的大网站（比如 www.microsoft.com），然后用特殊的密钥机制完成认证。
你 → TLS ClientHello (SNI: www.microsoft.com)
│
GFW 检查: 目标 IP 是你的 VPS，SNI 是 microsoft.com
↓
GFW 主动探测：用 microsoft.com 的身份去连你的 VPS
↓
你的 VPS：检测到不是合法客户端
→ 把连接直接转发给真正的 microsoft.com
→ GFW 拿到的是微软官网的真实证书和内容
→ GFW：这就是个普通的微软 CDN 节点嘛，放行 ✅Reality 的核心魔法：
- 客户端持有一个
public-key（服务器生成的公钥） - 握手时，客户端用这个公钥进行特殊的密钥交换
- 服务器验证成功 → 进入代理模式
- 服务器验证失败（GFW 探测）→ 把流量原样转发给
www.microsoft.com，让 GFW 拿到真实的微软响应
对 GFW 来说，这台服务器和微软官方 CDN 节点没有任何区别。
你的配置里的 US-Dallas 就是 VLESS + Reality：
type: vless servername: "www.microsoft.com" ← SNI 伪装成微软 flow: xtls-rprx-vision ← XTLS 流控，减少 TLS-in-TLS 特征 reality-opts: public-key: "9oOPKw..." ← Reality 认证公钥 short-id: "870ca1..." ← 短 ID，进一步验证身份
Level 6：AnyTLS（2025）
你另一个机场配置里用的协议。思路类似 Reality，但实现机制不同——它不依赖单一 SNI 伪装，而是动态模拟多种 TLS 行为，更难被统计分析。目前是较新的协议，还在快速迭代。
协议演进总结
明文代理 → 加密代理 → 伪装代理 → 冒充代理 → 寄生代理
SOCKS5 SS VMess+WS Trojan VLESS+Reality
(秒封) (已被识别) (较安全) (安全) (目前最安全)| 协议 | 加密 | 伪装 | 抗主动探测 | 需要域名/证书 |
|---|---|---|---|---|
| SOCKS5 | ❌ | ❌ | ❌ | ❌ |
| Shadowsocks | ✅ | ❌ | ❌ | ❌ |
| VMess+WS+TLS | ✅ | ✅ | ⚠️ | ✅ |
| Trojan | ✅ | ✅ | ✅ | ✅ |
| VLESS+Reality | ✅ | ✅ | ✅ | ❌（借用别人的） |
第三章：出口 IP —— 机房 vs 住宅
你已经成功翻墙了。但代理服务器用什么 IP 去访问目标网站，直接决定了你会不会被目标网站封。
机房 IP（Datacenter IP）
来自 AWS、DigitalOcean、搬瓦工等云厂商的 IP 段。
你 → VPS (机房IP: 45.76.x.x) → claude.ai
↓
"这个 IP 来自 Vultr 机房"
"正常人不会从机房访问我"
"可能是爬虫/代理 → 封！"很多服务（Netflix、Claude、ChatGPT）会维护一个机房 IP 黑名单，检测到机房 IP 就拒绝服务或触发验证。
住宅 IP（Residential IP）
来自真实的家庭宽带 ISP（如 AT&T、Comcast）。
你 → VPS → 住宅代理 (住宅IP: 98.45.x.x) → claude.ai
↓
"这个 IP 来自 AT&T 家庭宽带"
"看起来是正常用户 → 放行 ✅"这就是你配置里”代理链”的意义：
- name: "US-Dallas" # 第一跳：穿墙（VLESS+Reality）
type: vless
...
- name: "住宅代理" # 第二跳：换身份（住宅 IP 出口）
type: socks5
server: 204.14.74.193
dialer-proxy: "US-Dallas" # 流量先走 US-Dallas 出去| 跳 | 作用 | 解决什么问题 |
|---|---|---|
| 第一跳 VPS | VLESS+Reality 加密，骗过 GFW | 翻墙 |
| 第二跳 住宅代理 | 用住宅 IP 访问目标 | 过风控 |
单跳做不到两全：
- 只用 VPS → 能翻墙，但 Claude 可能封你（机房 IP）
- 只用住宅代理 → Claude 不封你，但 GFW 封你（流量没加密）
- 两跳组合 = 翻墙 + 过风控，完美
第四章：路由规则 —— 流量调度
不是所有流量都需要走代理。访问百度走代理反而更慢。路由规则的作用就是按域名/IP 把流量分流到不同的出口。
规则的本质：if-else
# 伪代码，但这就是路由规则的本质
def route(request):
domain = request.domain
if domain.endswith('.cn'):
return DIRECT # 国内网站 → 直连
if domain in ['claude.ai', 'anthropic.com']:
return proxy_group['AI'] # AI 服务 → AI 策略组
if domain.endswith('youtube.com'):
return proxy_group['YouTube']
if geoip(request.ip) == 'CN':
return DIRECT # 目标 IP 在中国 → 直连
return proxy_group['Proxy'] # 其他 → 默认代理规则匹配顺序
规则是从上到下匹配的，第一个匹配到的规则生效：
rules:
# 优先级最高：精确匹配
- DOMAIN,claude.ai,AI # 完全匹配 claude.ai
# 次优先：后缀匹配
- DOMAIN-SUFFIX,anthropic.com,AI # 匹配 *.anthropic.com
# 再次：关键词匹配
- DOMAIN-KEYWORD,google,Google # 域名里包含 "google"
# IP 规则
- IP-CIDR,91.108.0.0/16,Telegram # Telegram 的 IP 段
# GeoIP 规则
- GEOIP,CN,DIRECT # 中国 IP → 直连
# 兜底规则（最后一条）
- MATCH,Proxy # 以上都没匹配 → 走代理GEOIP：一个 IP 地址和国家/地区的映射数据库。通过查表可以知道某个 IP 属于哪个国家。代理工具内置了这个数据库，用来判断”这个目标 IP 在不在国内”。
策略组（Proxy Group）
策略组是一组节点的集合，决定流量最终走哪个具体节点：
proxy-groups:
- name: AI
type: select # 手动选择
proxies:
- 🇺🇸 美国 01 # Claude 推荐美国节点
- 🇸🇬 新加坡 01
- 🇯🇵 日本 01
- name: YouTube
type: url-test # 自动测速，选最快的
url: http://www.gstatic.com/generate_204
interval: 300
proxies:
- 🇭🇰 香港 01
- 🇭🇰 香港 02
- 🇸🇬 新加坡 01| 策略类型 | 行为 |
|---|---|
select | 手动选节点 |
url-test | 自动测速，用最快的 |
fallback | 自动故障转移：第一个挂了用第二个 |
load-balance | 负载均衡：随机分配 |
第五章：完整数据流 —— 一次请求的旅程
现在把所有概念串起来。当你在手机上打开 claude.ai，到底发生了什么？
┌─────────────────────────────────────────────────────────┐
│ 📱 你的手机 │
│ │
│ Claude App: "我要连 claude.ai" │
│ │ │
│ ▼ │
│ Shadowrocket 拦截请求 │
│ │ │
│ ▼ │
│ 规则匹配: DOMAIN-SUFFIX,claude.ai → AI 策略组 │
│ │ │
│ ▼ │
│ AI 策略组当前选中: "住宅代理" │
│ │ │
│ ▼ │
│ 住宅代理配置了 underlying-proxy: US-Dallas │
│ 所以先建立到 US-Dallas 的连接 │
│ │ │
│ ▼ │
│ VLESS + Reality 握手: │
│ - TLS ClientHello, SNI = www.microsoft.com │
│ - Reality 密钥交换验证身份 │
│ - 建立加密隧道 │
└───────│─────────────────────────────────────────────────┘
│
══════════════ GFW ══════════════
│ GFW 检查:
│ ✅ 目标 IP: US-Dallas 的 VPS
│ ✅ SNI: www.microsoft.com (正常)
│ ✅ TLS 指纹: Chrome 浏览器 (正常)
│ ✅ 放行
════════════════════════════════════
│
▼
┌───────────────────────────────────────┐
│ 🖥️ US-Dallas VPS (107.161.90.139) │
│ │
│ VLESS 解密 → 得到: "连住宅代理" │
│ │ │
│ ▼ │
│ SOCKS5 连接到 204.14.74.193:8022 │
│ 认证: axezadrqxq / ipymoymeymoqu │
└───────│───────────────────────────────┘
│
▼
┌───────────────────────────────────────┐
│ 🏠 住宅代理 (204.14.74.193) │
│ 出口 IP: 某个美国 AT&T 家庭宽带 IP │
│ │
│ SOCKS5 转发 → 连接 claude.ai │
└───────│───────────────────────────────┘
│
▼
┌───────────────────────────────────────┐
│ 🤖 claude.ai (160.79.104.x) │
│ │
│ 看到的请求来源: 美国住宅 IP │
│ 风控判断: 正常用户 ✅ │
│ 正常返回页面内容 │
└───────────────────────────────────────┘整条链路上，三个”敌人”分别被不同机制骗过：
| 敌人 | 检查什么 | 怎么骗它 |
|---|---|---|
| GFW | 你在访问什么 | Reality 伪装成 microsoft.com |
| Cloudflare | 请求是否来自代理 | 住宅 IP 不在黑名单里 |
| Claude | 用户是否在支持地区 | 美国住宅 IP → 判定为美国用户 |
小结
-
代理的本质：中间人转发，隐藏你的真实目的地和身份。
-
协议演进是一场猫鼠游戏：明文 → 加密 → 伪装 → 冒充 → 寄生。当前最强方案是 VLESS + Reality——借用真实网站的 TLS 身份，让 GFW 无法区分代理流量和正常流量。
-
出口 IP 决定风控：机房 IP 容易被封，住宅 IP 最干净。代理链（VPS + 住宅代理）= 翻墙 + 过风控的组合拳。
-
路由规则是流量调度器：按域名/IP/GeoIP 把不同流量分发到不同出口，实现”国内直连、国外代理”。
-
一切都是分层的：协议层管加密认证，传输层管伪装，出口层管身份，规则层管分流。理解了分层，就理解了所有代理工具的配置逻辑。
下一篇预告：代理原理（二）——自建节点实战。从零搭建一台 VLESS + Reality 服务器，配置 Clash/Shadowrocket 客户端，实现完整的翻墙链路。
💬 评论
评论加载中...