网络代理相关知识
- 区别与原理详解
- [🌐 网络代理与 TCP 桥接原理（表格版）](#🌐 网络代理与 TCP 桥接原理（表格版）)
-
- 一、代理类型对比
- [二、HTTP 代理的两种模式](#二、HTTP 代理的两种模式)
- [三、TCP 桥接（TCP Bridging / Relay）核心机制](#三、TCP 桥接（TCP Bridging / Relay）核心机制)
- [四、TCP 桥接的三个阶段](#四、TCP 桥接的三个阶段)
- [五、HTTPS 代理中的证书获取流程](#五、HTTPS 代理中的证书获取流程)
- 六、常见技术中的代理与桥接应用
- 七、关键问题总结
- 八、一句话总结
- [🌐 Nginx 反向代理（表格版）](#🌐 Nginx 反向代理（表格版）)
- [🌐 Vue Dev Proxy（表格版）](#🌐 Vue Dev Proxy（表格版）)
区别与原理详解
| 特性 | 网络代理 (Network Proxy) | Nginx 反向代理 (Reverse Proxy) | Vue 前端请求代理 (Dev Proxy) |
|---|---|---|---|
| 层级 | 网络层 / 应用层（如 HTTP 代理） | 应用层（HTTP/HTTPS） | 应用层（HTTP/HTTPS） |
| 运行环境 | 独立的代理服务器或客户端软件（如浏览器插件、系统代理设置） | 服务器端（生产环境） | 开发环境（仅用于开发） |
| 主要目的 | - 访问受限资源 - 匿名性 - 缓存加速 - 内容过滤 | - 负载均衡 - 高可用 - 安全防护（隐藏后端） - 静态资源服务 - SSL 终止 | 解决开发时的跨域问题 （前端开发服务器和后端 API 服务器不同源） |
| 谁发起请求 | 最终用户或客户端程序 | Nginx 服务器（代表客户端） | Vue 开发服务器（webpack-dev-server） |
| 工作流程 | 用户 → 代理服务器 → 目标服务器 → 代理服务器 → 用户 | 客户端 → Nginx → 后端服务器 → Nginx → 客户端 | 浏览器 → Vue Dev Server → 代理规则 → 后端服务器 → Vue Dev Server → 浏览器 |
| 是否修改请求/响应 | 通常透明转发，但可修改（如缓存、过滤） | 可修改（如添加头、重写 URL、压缩） | 可修改（如重写路径、添加头） |
| 生产环境使用？ | 是（如企业代理、CDN） | 是（核心生产组件） | 否（仅开发时使用） |
| 典型工具/技术 | Squid, Charles, Shadowsocks, CDN 边缘节点 | Nginx, Apache, HAProxy | webpack-dev-server 的 proxy 配置 |
🌐 网络代理与 TCP 桥接原理（表格版）
一、代理类型对比
| 类型 | 是否需要手动配置 | 谁发起连接 | 代理是否解析内容 | 典型场景 | 安全性 |
|---|---|---|---|---|---|
| 显式代理 | 是（如设置浏览器代理） | 客户端主动连接代理 | 是（HTTP）或否（CONNECT） | Clash、V2Ray、浏览器插件 | 高（加密时） |
| 透明代理 | 否（自动拦截） | 网络设备劫持流量 | 是或否（取决于模式） | 公司网关、ISP、GFW | 低（可能被监控） |
二、HTTP 代理的两种模式
| 特性 | 普通代理（HTTP Proxy） | 隧道代理（CONNECT） |
|---|---|---|
| 适用协议 | HTTP（明文） | HTTPS / TLS / 任意 TCP 协议 |
| 请求方式 | GET http://example.com/path HTTP/1.1 |
CONNECT example.com:443 HTTP/1.1 |
| 代理行为 | 解析 URL，重新发起 HTTP 请求 | 建立 TCP 连接，透传数据 |
| 数据是否可读 | 是，代理可查看/修改内容 | 否，代理只转发加密流 |
| TLS 握手位置 | 代理与目标之间（若支持 SSL 代理） | 客户端与目标之间（端到端） |
| 证书获取方式 | 代理获取并可能替换（中间人） | 客户端直接接收目标服务器证书 |
| 典型用途 | 缓存、过滤 HTTP 流量 | 访问 HTTPS 网站、加密通信 |
三、TCP 桥接（TCP Bridging / Relay）核心机制
| 概念 | 说明 |
|---|---|
| 定义 | 代理将"客户端 ↔ 代理"和"代理 ↔ 目标"两个 TCP 连接"焊接"成一条逻辑通路 |
| 本质 | 不是"两个隧道"，而是一个被中继的 TCP 流 |
| 触发方式 | 客户端发送 CONNECT 请求 |
| 代理行为 | 进入"透传模式"，双向转发字节流，不再解析协议 |
| 数据流向 | 客户端 → 代理 → 目标 → 代理 → 客户端（双向） |
| 是否加密 | 桥接本身不加密，但上层可运行 TLS（如 HTTPS） |
| 类比 | 电话转接员：只传声音，不参与对话 |
四、TCP 桥接的三个阶段
| 阶段 | 连接 A（你 ↔ 代理） | 连接 B（代理 ↔ 目标） | 代理行为 |
|---|---|---|---|
| 1. 建立连接 A | 已建立 | 不存在 | 等待客户端请求 |
| 2. 发送 CONNECT | 存在 | 不存在 | 代理解析 CONNECT 请求 |
| 3. 建立连接 B | 存在 | 建立中 | 代理连接目标服务器 |
| 4. 返回 200 | 存在 | 已建立 | 返回 200 Connection Established |
| 5. 桥接数据流 | 存在 | 存在 | 双向透传，不再解析数据 |
五、HTTPS 代理中的证书获取流程
| 步骤 | 行为 | 说明 |
|---|---|---|
| 1 | 客户端发送 CONNECT google.com:443 |
通过代理请求建立 TCP 通路 |
| 2 | 代理连接 google.com:443 |
代理在境外可成功连接 |
| 3 | 代理返回 200 Connection Established |
TCP 隧道建立完成 |
| 4 | 客户端发送 Client Hello |
TLS 握手开始，通过代理透传 |
| 5 | google.com 返回 Server Hello + 证书 |
证书由真实服务器发送 |
| 6 | 客户端验证证书 | 检查 CA、域名、有效期 |
| 7 | 建立加密会话 | 后续所有数据加密传输 |
✅ 关键 ：证书是在连接建立后由服务器发送，不是提前获取。
六、常见技术中的代理与桥接应用
| 技术 | 是否使用 TCP 桥接 | 加密方式 | 流量伪装 | 说明 |
|---|---|---|---|---|
| HTTP CONNECT | ✅ 是 | TLS（上层） | ❌ 否 | 标准 HTTPS 代理机制 |
| Shadowsocks | ✅ 是 | AES/ChaCha20 | ✅ 是（可混淆） | 加密 SOCKS5 代理 |
| V2Ray / Xray | ✅ 是 | TLS + WebSocket | ✅ 是（伪装成网站） | 模块化代理平台 |
| Trojan | ✅ 是 | TLS | ✅ 是（完全像 HTTPS） | 假装是正常网站 |
| SSH 隧道 | ✅ 是 | SSH 加密 | ✅ 是（SSH 流量） | 本地/远程端口转发 |
| VPN（如 WireGuard） | ❌ 否 | IP 层加密 | ✅ 是 | 创建虚拟网络接口，非代理 |
七、关键问题总结
| 问题 | 回答 |
|---|---|
| 是"两个隧道"吗？ | ❌ 不是。是两个 TCP 连接被桥接成一个逻辑通路。 |
| 代理能看到 HTTPS 内容吗？ | ❌ 不能，除非你安装了它的 CA 证书（中间人攻击）。 |
| 如何拿到证书？ | 通过桥接的 TCP 通路，目标服务器在 TLS 握手时发送真实证书。 |
| TCP 桥接安全吗？ | ✅ 安全。只要不安装未知 CA，HTTPS 的端到端加密不受影响。 |
| GFW 能阻断吗？ | 可通过 DPI 识别特征，但无法解密内容。现代工具通过伪装对抗。 |
八、一句话总结
🔐 网络代理通过 TCP 桥接实现 HTTPS 透传：你发
CONNECT请求，代理建立通路，你与目标服务器直接完成 TLS 握手，获取真实证书，代理仅作"透明中继"。
| 步骤 | 发起方 | 接收方 | 数据内容 | 说明 |
|---|---|---|---|---|
| 1 | 客户端 | 代理 | CONNECT google.com:443 HTTP/1.1 Host: google.com [空行] |
客户端请求代理建立通往 google.com:443 的隧道 |
| 2 | 代理 | 目标服务 | TCP SYN → google.com:443 |
代理尝试与目标建立 TCP 连接 |
| 3 | 目标服务 | 代理 | TCP SYN-ACK | 目标服务器响应连接请求 |
| 4 | 代理 | 客户端 | HTTP/1.1 200 Connection Established [空行] |
代理通知客户端：隧道已建立，进入透传模式 |
| 5 | 客户端 | 代理 | [TLS Client Hello]（二进制） |
客户端开始 TLS 握手，发送 Client Hello 包含：支持的协议版本、加密套件、随机数 ClientRandom |
| 6 | 代理 | 目标服务 | [TLS Client Hello]（原样转发） |
代理不解析，只是透传二进制数据 |
| 7 | 目标服务 | 代理 | [TLS Server Hello + Certificate + ServerHelloDone] |
服务器响应： - 选择加密套件 - 发送真实 SSL 证书 （由 Google Trust Services 签发） - 包含 ServerRandom |
| 8 | 代理 | 客户端 | [TLS Server Hello + Certificate + ServerHelloDone]（原样转发） |
代理继续透传，无法篡改证书（否则浏览器会报警） |
| 9 | 客户端 | 本地处理 | 验证证书： - 是否由可信 CA 签发 - 域名是否匹配 - 是否过期 | ✅ 验证通过（因为是 Google 真实证书） |
| 10 | 客户端 | 本地处理 | 生成 Pre-Master Secret 用证书中的公钥 加密： {Pre-Master Secret}ₚᵤᵦₗᵢ꜀ |
只有 google.com 的私钥能解密此数据 |
| 11 | 客户端 | 代理 | [TLS ClientKeyExchange] {Pre-Master Secret}ₚᵤᵦₗᵢ꜀ |
客户端发送加密的密钥交换数据 |
| 12 | 代理 | 目标服务 | [TLS ClientKeyExchange] {Pre-Master Secret}ₚᵤᵦₗᵢ꜀（原样转发） |
代理无法解密，只能转发"乱码" |
| 13 | 目标服务 | 本地处理 | 用私钥 解密得到 Pre-Master Secret 结合 ClientRandom 和 ServerRandom 计算出会话密钥（Session Key） |
会话密钥用于后续对称加密 |
| 14 | 目标服务 | 代理 | [TLS ChangeCipherSpec] [TLS Finished]（已加密） |
服务器通知：切换到加密模式，并发送加密的完成消息 |
| 15 | 代理 | 客户端 | [TLS ChangeCipherSpec] [TLS Finished]（原样转发） |
代理继续透传加密数据 |
| 16 | 客户端 | 本地处理 | 使用 Pre-Master Secret、ClientRandom、ServerRandom 独立计算出相同的会话密钥 |
客户端也进入加密模式 |
| 17 | 客户端 | 代理 | [TLS ChangeCipherSpec] [TLS Finished]（已加密） |
客户端确认握手完成，进入加密通信 |
| 18 | 代理 | 目标服务 | [TLS ChangeCipherSpec] [TLS Finished]（已加密） |
转发加密完成消息 |
| 19 | 客户端 ⇄ 代理 ⇄ 目标服务 | 双向加密通信开始 | [Application Data]（如 GET / HTTP/1.1） 全部使用会话密钥加密传输 |
代理只能看到加密的二进制流，无法解析内容 |
| 步骤 | 谁在做什么 | 是否需要 TLS |
|---|---|---|
| 1 | 你发 CONNECT |
❌ 你和代理之间是 HTTP（可能明文） |
| 2 | 代理建 TCP 连接 | ❌ 代理和 Google 之间只是 TCP |
| 3 | 你发 Client Hello |
✅ 你和 Google 开始 TLS 握手 |
| 4 | 数据加密传输 | ✅ 你和 Google 之间的 TLS 加密 |
CONNECT 是 HTTP/1.1 的一个特殊方法，用于建立隧道。
| 信息 | 是否加密 | 说明 |
|---|---|---|
✅ 具体路径和参数 /search?q=xxx |
✅ 是，加密 | 在 GET 请求中，属于应用层数据，被 TLS 加密 |
✅ HTTP 请求头 Cookie、Authorization 等 |
✅ 是，加密 | 全部在 TLS 隧道内 |
| ❌ 目标域名（SNI） | ❌ 否，明文 | 在 Client Hello 中以明文发送（除非启用 ESNI/DoH） |
| ❌ IP 地址和端口 | ❌ 否，明文 | TCP/IP 层必须可见 |
| ❌ 流量大小和时间 | ❌ 否，可见 | 可用于流量分析 |
| 概念 | 一句话解释 |
|---|---|
| 透传（Relay / Passthrough） | 中间节点"原样转发"字节流，不解析、不解密、不修改内容。 |
| 隧道（Tunnel） | 把一个协议的数据"藏"在另一个连接中，形成一条逻辑上的端到端通路。 |
你 代理 Google
| | |
|--- CONNECT --------->| | ← 控制指令（明文）
| |--- TCP --------------->| ← 代理建连接
| |<-- 200 ----------------| ← 隧道建立完成
|<-- 200 --------------| |
| | |
|--- [Client Hello] -->|--- [Client Hello] -->| ← 透传开始
| |<-- [Server Hello...] --| ← 透传
|<-- [Server Hello...] -| |
| | |
|--- {Pre-Master} ---->|--- {Pre-Master} ---->| ← 透传加密数据
| | |
|<=> [加密数据] <======>|<=> [加密数据] <=====>| ← 透传 HTTPS 流量公司的CA证书
你（浏览器） 企业代理（HTTPS 解密代理） Google 服务器
| | |
|--- 访问 google.com ->| |
| | 拦截请求 |
| | ↓ |
| | 动态生成一个伪造的证书： |
| | - 域名：google.com |
| | - 公钥：代理生成的密钥对 |
| | - 签名者：Company CA |
| | - 用 Company CA 私钥签名 |
| | ↓ |
|<- 返回伪造证书 ------| |
| 浏览器验证： | |
| - 域名匹配 ✅ | |
| - CA 可信 ✅（你装了Company CA）|
| → 建立 TLS 连接（实际是和代理）|
| | |
|--- 发送加密数据 ------>| |
| | 代理解密数据（用自己的私钥）|
| | 查看内容（搜索词、Cookie） |
| | 重新加密 -> Google |
| |<- 加密响应 ----------------|
|<- 加密响应 ----------| || 条件 | 解决的问题 | 技术本质 |
|---|---|---|
| 1. 代理劫持 | "如何插进来？" | 控制网络路径： - 公司防火墙强制转发 - DNS 劫持 / ARP 欺骗 - 恶意 Wi-Fi 伪基站 - 系统代理设置被篡改 |
| 2. CA 证书信任 | "如何让浏览器不报警？" | 打破加密信任： - 你安装了公司/恶意 CA 根证书 - 代理用该 CA 动态伪造目标网站证书 - 浏览器验证通过，显示"安全锁" |
🌐 Nginx 反向代理（表格版）
| 对比项 | Nginx 反向代理 | HTTPS 中间人攻击 |
|---|---|---|
| 谁控制代理？ | 网站所有者自己 | 攻击者 / 监控方 |
| 是否合法？ | ✅ 合法，用于架构设计 | ❌ 非法或强制监控 |
| CA 证书来源 | 正规 CA（如 Let's Encrypt） | 恶意或企业自建 CA |
| 用户是否知情？ | 不需要知情（正常访问） | 不知情（被欺骗） |
| 加密是否被破坏？ | ❌ 否，端到端仍安全 | ✅ 是，中间被解密 |
| 目的 | 负载均衡、安全、缓存、SSL 终止 | 监控、窃取、过滤 |
🌐 Vue Dev Proxy（表格版）
| 类型 | Vue Dev Proxy | Nginx 反向代理 | 中间人攻击（MITM） |
|---|---|---|---|
| 使用场景 | 前端开发 | 生产环境部署 | 监控/窃取流量 |
| 运行环境 | localhost:5173（开发） |
服务器（生产） | 客户端网络路径中 |
| 是否修改请求 | 转发 + 可重写路径 | 转发、负载均衡、缓存 | 解密、查看明文 |
| 是否涉及 HTTPS 解密 | ❌ 否 | ✅ 是（SSL 终止） | ✅ 是（伪造证书） |
| 是否需要安装 CA 证书 | ❌ 否 | ❌ 否（用正规证书） | ✅ 是（自建 CA） |
| 用户是否知情 | ✅ 是（开发者配置） | ✅ 是（运维配置） | ❌ 否（被欺骗） |
| 目的 | 解决开发跨域 | 提高性能、安全、架构 | 监控、过滤、窃取 |