抓包的本质是回答一个问题：数据从浏览器到服务器，一路上经过哪些环节，每个环节能看到什么、看不到什么？ 拆开就是三件事实——HTTP 是明文协议，所以”抓包能看到内容”；代理是流量路径上的中转站，所以”抓包工具能插进链路”；HTTPS 是加密协议，所以”想看到内容必须成为 TLS 端点或拿到密钥”。把这三件事串起来，就得到一张完整的流量观察地图。
本文只讨论授权环境下的流量观察与抓包原理。
一、流量本质：数据在网络上到底是什么
你在网络上发送的每一个请求，物理上都是一串比特流。从应用层到物理层，数据被一层层”套娃”封装：
1 | HTTP 数据（可读文本） |
网络七层模型（OSI）和四层模型（TCP/IP）讲的就是这层封装关系。对抓包来说，只需要记住一个简化视角：以太网帧 → IP 包 → TCP 段 → HTTP 数据。
抓包工具本质上是解封装器，从底层一层层剥掉头，把内容展示给你：
- Wireshark：从以太网帧开始剥，你看到完整的 TCP/IP 结构、每个包的十六进制内容，视野最大、最底层
- Burp / Yakit：直接停在 HTTP 层，只展示请求行、请求头、body 这种”人类友好”视图，专门为 Web 测试设计
核心认知：HTTP 请求”看起来”是一段可读文本（请求行 + 头部 + 空行 + body），而它被包裹在 TCP/IP/以太网里。这段文本的可读性，就是”抓包能看到明文”的物质基础——下面一章展开。
二、HTTP：明文的可观察性
1. 一个 HTTP 请求长什么样
在 Burp 里看到的典型请求：
1 | GET /login |
结构就四部分：请求行（方法 + 路径 + 协议版本）、请求头（Host、Cookie、User-Agent 等键值对）、空行、body（GET 通常没有，POST 有表单或 JSON 数据）。响应结构对称：状态行（200 OK）、响应头、body。
2. 为什么明文 = 可看可改
HTTP 不加密，意味着链路上任何能读到这段数据的节点，都可以看、改、重放：
- 看：路由器、运营商、WiFi 热点、企业网关、抓包工具——都能读到完整内容
- 改：中间节点可以篡改响应（最经典的例子：公共 WiFi 上被插入广告、HTTP 页面被注入脚本）
- 重放：拦截到登录请求后，原样重发（如果服务端没做防重放）
这就是 HTTP 的三大安全缺陷：窃听、篡改、身份伪造——也是 HTTPS 出现的直接原因。
3. HTTP 抓包：零配置
因为不存在加密，HTTP 抓包没有任何证书问题：
1 | 浏览器 ──明文──▶ Burp ──明文──▶ 服务器 |
只要把代理指到抓包工具，立刻就能看到全部明文，不需要装任何证书、不需要任何额外配置。这也是内网靶场、老系统、开发环境调试这么方便的原因——它们大量跑纯 HTTP。而现代公网站点几乎全是 HTTPS 了（浏览器会把 HTTP 标为”不安全”，HSTS 强制跳转 HTTPS），所以抓包的重头戏在 HTTPS——也就是接下来两章的主角。
三、代理：流量被”插一脚”的机制
1. 什么是代理
代理是一个中间转发者：客户端不直接连服务器，而是把请求交给代理，由代理转发。按位置和用途分三种形态，面试最爱考：
| 形态 | 替谁干活 | 谁配置 | 典型例子 |
|---|---|---|---|
| 正向代理 | 替客户端转发 | 客户端主动设置 | Burp、Fiddler、翻墙代理 |
| 反向代理 | 替服务器接收 | 服务器端部署 | Nginx、CDN、负载均衡 |
| 透明代理 | 替网络强制接管 | 无需客户端配置 | 企业上网行为管理、iptables 重定向 |
抓包工具是标准的正向代理。你设置浏览器代理 127.0.0.1:8080，本质是改写了请求的目的地——原本直连 example.com:443，现在先到本机的 Burp。Burp 收到后再替你连真正的服务器。正向代理就是”客户端主动把流量交给你”，这是主动抓包的前提。
透明代理值得多说一句：它不需要客户端任何配置，靠网络设备（交换机/路由器/防火墙）强制把流量重定向到代理。企业里”我明明没设代理，为什么上网行为被记录”的答案就是它。对抓包来说，Burp 也有透明代理模式（Invisible Proxy），配合 iptables 重定向可以抓不认代理的客户端。
2. HTTP 代理 vs SOCKS5
| HTTP 代理 | SOCKS5 代理 | |
|---|---|---|
| 工作方式 | 用 CONNECT 方法建隧道 |
更底层，直接转发任意 TCP/UDP |
| 支持协议 | HTTP/HTTPS 为主 | 任意协议（TCP/UDP 都行） |
| 能看到的细节 | 能解析 HTTP 层（可抓包） | 只认 IP:端口，不关心内容 |
| 典型用途 | Web 抓包、Web 调试 | 内网穿透、全局代理 |
注意：SOCKS5 是”更底层”的代理，它不解析协议，所以SOCKS5 代理本身不做抓包——它只负责搬运字节流。Burp 走的是 HTTP 代理；而内网渗透常用的 frp、chisel 等隧道工具则大量用 SOCKS5。
3. VPN vs 代理：搬运工与翻译官
很多人把 VPN 和代理混为一谈，其实对”流量观察”来说差别巨大：
| 维度 | VPN | 代理（Burp） |
|---|---|---|
| 工作层次 | 网络层/传输层（整个 IP 包） | 应用层（只处理特定协议） |
| 覆盖流量 | 全部（含 DNS、UDP、游戏、邮件） | 只看代理指向的协议 |
| HTTPS 解密 | 不主动解密，只能看密文 | MITM + 装证书，能看明文 |
| 中间人能力 | 无（不做证书伪造） | 有（假证书 + 双密钥） |
| 典型用途 | 内网接入、匿名 | 安全测试、调试 |
一句话：VPN 是”搬运工”，Burp 是”翻译官”。VPN 服务器作为流量出口，能看到所有经过的流量——但目标站是 HTTP 就看到明文，是 HTTPS 就只能看到密文（和任何网络节点一样）。现实中”VPN 能看到 HTTPS 明文”的场景（如企业上网行为管理），本质是网关叠加了 MITM + 预装企业证书，不是 VPN 天生能解密。没有装证书这一环，任何设备都解不开 HTTPS——这是所有流量观察手段的公共边界。
4. 转发型代理 vs 抓包型代理：搬与拆
顺着上面的对比再进一步：代理本身也分两种，对抓包的理解这是最关键的一刀。
| 转发型代理 | 抓包型代理 | |
|---|---|---|
| 代表 | Clash、frp、SOCKS5、VPN | Burp、Yakit、Fiddler |
| 做什么 | 纯搬运字节流 | 解析协议、读内容、改内容 |
| 需要伪装证书吗 | 不需要（密文原样搬） | 必须（要成为 TLS 端点） |
| 能看 HTTPS 明文吗 | 不能 | 能（装证书后） |
规律：要不要伪装证书，取决于”要不要看内容”，而不是”是不是代理”。TLS 是端到端加密，转发型代理不参与握手，收到的是密文，原样搬走即可——Clash 节点服务器看到的内容和运营商看到的没有任何区别。而抓包工具本质是”代理 + 拆信能力“：它在搬运工的基础上多了一个 MITM 引擎，伪装证书、持有双密钥，才能读、能改。理解了这一层，就理解了为什么”装证书”是抓包工具绕不开的一环（第五章展开）。
5. 代理链
代理还可以串联成链：客户端 → 代理 A → 代理 B → 服务器。内网渗透里这叫多级代理/代理链，用于逐层深入目标内网；渗透时”Burp → Clash → 节点”的组合就是典型用法（既能抓包又能翻墙）。本文不展开，相关实战可参考另一篇《FRP 内网穿透与代理实战》。
四、HTTPS：加密之后抓包看到了什么
1. 为什么加密
HTTPS = HTTP + TLS（SSL 是 TLS 的前身，已淘汰）。它解决三件事：
- 机密性：数据加密传输，防止窃听
- 完整性：防篡改（哈希校验）
- 身份验证：通过 CA 数字证书确认”对面真的是 example.com”
2. TLS 握手简版（五步）
握手是”加密开始前的协商”，全程发生在数据加密之前。以最常见的 ECDHE 流程为例：
1 | 客户端 服务器 |
三个要点：
- SNI（Server Name Indication）在 ClientHello 里明文传输——这就是防火墙、企业网关能识别”你在访问哪个域名”的原因
- 证书是明文下发的，因为客户端必须验证它
- 握手完成后，双方用对称会话密钥加密数据（TLS 1.3 中 pre-master 概念被 (EC)DHE 共享密钥直接派生取代，且握手优化为 1-RTT 完成）
3. 加密后抓包看到什么：握手明文，数据密文
这是整篇文章最重要的一个认知：
| TLS 阶段 | 抓包能看到 |
|---|---|
| 握手 | TLS 版本、密码套件、SNI、证书（明文元数据） |
| 数据 | Application Data 记录——全部密文 |
在 Wireshark 里打开一个 HTTPS 包，你看到的是十六进制密文，不是 GET /login HTTP/1.1。HTTPS 的加密使”抓包”退化为”抓密文”——内容从此与旁观者无关。
4. Wireshark 怎么解：SSLKEYLOGFILE
Wireshark 能解密 HTTPS，但路径和 Burp 完全不同——它不伪装服务器，而是直接借密钥：
- 设置环境变量
SSLKEYLOGFILE=/path/to/keylog，启动浏览器 - 浏览器把每次 TLS 会话的密钥（pre-master secret）写入该文件
- Wireshark 的
Pre-Master-Secret log filename指向它 - 重放/刷新流量，密文自动被解密成明文 HTTP
注意两个限制：只能用 SSLKEYLOGFILE，不能用服务器私钥——现代 TLS 用 ECDHE 前向保密，即使拿到服务器私钥也解不开历史流量（TLS 1.2 早期的 RSA 密钥交换时代私钥能解，已废弃）；而且这种方式只能解本机浏览器自己发的流量，因为密钥只属于你自己的连接。想改包？这条路做不到，只能看。
5. HTTP/2 与 HTTP/3 对抓包的影响
现代 Web 已经进入 HTTP/2/3 时代，抓包认知要同步更新：
- HTTP/1.1：文本协议，请求/响应逐行可读，好改好重放
- HTTP/2：二进制分帧、多路复用。抓包工具里看到的是解码后的友好视图，不再是原始文本行，但 Burp 能正常处理
- HTTP/3（QUIC）：底层换成 UDP，不再是 TCP。Burp 默认抓不到 HTTP/3 流量——很多人在新协议站点上”工具失灵”，其实是没意识到这点。抓 HTTP/3 需要专门配置（或让站点回退到 HTTP/2）
面试如果被问”为什么有些流量抓不到”，HTTP/3 是标准答案之一。
五、中间人：为什么 Burp 还能解密 HTTPS
1. 核心机制：两段独立的 TLS
Burp 能看 HTTPS 明文，不是因为破解了 TLS，而是因为它把自己拆成了两段完全独立的 TLS 连接，夹在中间当”翻译官”：
1 | TLS #1（自签证书） TLS #2（真实证书） |
- 第一段（浏览器 ↔ Burp）：Burp 对浏览器假装自己是服务器，出示一张自己签发的证书。这段的会话密钥 Burp 掌握 → 明文在这里可见、可改
- 第二段（Burp ↔ 服务器）：Burp 作为普通客户端，用服务器的真实证书重新握手，把请求重新加密转发。服务器无感知
关键认知：Burp 看得到明文，是因为它本身就是第一段 TLS 的”服务器端”，而不是它破解了什么。它是两段 TLS 的端点，不是旁观者。
2. 一次 HTTPS 抓包的七步
1 | ① 代理接管 浏览器发 CONNECT example.com:443 给 Burp（请求先到 Burp） |
整个流程只有第③步需要人工干预（装证书），其余全自动。
3. 双会话密钥：中间人全知全能的来源
- 两段连接各自独立握手，各自随机生成密钥，两套密钥完全独立、互不相通
- 浏览器只有 TLS#1 密钥，它不知道 TLS#2 的存在
- 服务器只有 TLS#2 密钥，它认为 Burp 就是个普通客户端
- Burp 是唯一同时持有两套密钥的一方：用 TLS#1 解开浏览器的请求 → 看/改 → 用 TLS#2 加密转发；响应方向同理
一句话：两端各信一半，中间全知全能。这就是”中间人”的技术含义。
4. 为什么必须装证书（信任链）
浏览器验证证书走的是证书信任链：
- Burp 需要出示一张
example.com的证书——它没有真实的，只能用自己内置的 Burp CA 私钥临时签发一张 - 浏览器向上查签发者，发现”Burp CA”不在系统信任列表 → 报错
NET::ERR_CERT_AUTHORITY_INVALID，拒绝连接 - 安装 Burp CA 证书 = 把”Burp CA”加进系统信任库
- 从此 Burp 签发的任何假证书验证通过，第一段 TLS 顺利建立
所以装证书不是破解 TLS，而是让浏览器主动信任了中间人：
1 | 系统信任 Burp CA → Burp CA 签发假证书 → 浏览器放行 |
5. 为什么不能只靠”点继续访问”
有人问：证书报错时点”高级 → 继续前往”不就行了吗？其实点继续也能抓到包——因为连接依然是和 Burp 建立的，TLS 握手依然由 Burp 完成，Burp 照样看到明文。但”点继续”有四个致命局限，装证书才是正规做法：
| 问题 | 点”继续前往” | 安装 CA 证书 |
|---|---|---|
| 每个新域名 | 都要重新点一次警告页 | 自动信任，全程无感 |
| 地址栏 | 永久显示”不安全” | 正常锁形图标 |
| 非浏览器客户端 | 没有”继续”按钮，直接失败 | 系统级信任，curl/Java/Python 都过 |
| HSTS 站点 | 连”继续”按钮都不给 | 正常抓包 |
最后一条最硬：HSTS（HTTP 严格传输安全）站点的响应头带 Strict-Transport-Security，浏览器会记住”这个域名永远只走 HTTPS、禁止证书例外”——遇到证书错误直接显示”连接不是私密连接”，不提供任何绕过入口。Google、GitHub 等几乎所有大厂都开 HSTS，不装证书 = 直接抓不了。
6. 证书装浏览器还是系统
取决于客户端的证书库，实战一律装系统：
| 客户端 | 用谁的证书库 | 装哪 |
|---|---|---|
| Chrome / Edge | 系统证书库 | 装系统即可 |
| Firefox | 自己的独立证书库（NSS） | 必须单独装进 Firefox |
| curl / Java / Python | 系统证书库 | 装系统 |
| 桌面 App | 系统证书库 | 装系统 |
手机端是真正的坑：
- Android 7.0+：App 默认只信任系统 CA，不信任用户安装的 CA——证书装到”用户证书”区对大多数 App 无效，要 root 后塞进系统区，或用 Frida 等过检测
- iOS：装完描述文件后，还要去
设置 → 通用 → 关于本机 → 证书信任设置手动打开”完全信任”开关
7. SSL Pinning：为什么 App 抓不到
App 里经常”抓不到包”或直接报错，因为做了 SSL Pinning（证书固定）：不信任系统 CA 列表，而是硬编码了服务器证书的指纹/公钥。Burp 的假证书即使被系统信任，App 也不认。这就是为什么抓 App 要过证书校验（root + 系统证书 + Frida 绕过 Pinning）。
8. 被动嗅探 vs 主动代理
“抓包”在安全语境里其实有两个含义，别混淆：
| 主动代理（Burp） | 被动嗅探（Wireshark 监听） | |
|---|---|---|
| 流量怎么来的 | 客户端主动把流量交给你 | 你偷听路过的流量 |
| 需要条件 | 配置代理 + 装证书 | 端口镜像 / 混杂模式 / ARP 欺骗 |
| 能改包 | 能 | 不能 |
| HTTPS 明文 | 能（MITM + 证书） | 不能（除非拿到密钥） |
| 层次 | 应用层中间人 | 网络层旁路 |
被动嗅探的经典形态：交换机端口镜像、WiFi 监听、ARP 欺骗后的流量截获——它只能”看”，不能”改”，且 HTTPS 下基本只能看到握手元数据。
六、防御视角：如何让中间人失效
攻击讲完了，反过来说”怎么防”。所有中间人攻击的成功前提是：目标安装了你的证书，或你拿到了会话密钥。防御就是堵住这两条路：
| 防御手段 | 原理 | 防住了什么 |
|---|---|---|
| HSTS | 浏览器强制 HTTPS + 禁止证书例外 | 防降级攻击、”点继续”的侥幸心理 |
| Certificate Pinning | 客户端锁定证书/公钥，不信任系统 CA | 防”装证书”式 MITM（App 场景） |
| SRI 子资源完整性 | 页面引用的 CDN 资源校验哈希 | 防 CDN 脚本被中间人篡改 |
| CA 透明度（CT） | CA 签发的证书强制写入公开日志 | 防证书被偷签（伪造 CA 证书全网可查） |
一条认知收束：HTTPS 不等于绝对安全，它把”随便看”升级成了”必须突破信任链”。企业能监控员工 HTTPS 流量、恶意软件能解密银行流量，靠的都是”目标机器上装了证书”这一环——所以信任链是 HTTPS 安全模型的基石，也是唯一的薄弱点。
七、心智模型：一张图看懂所有流量观察手段
把全文收拢成一张全景图：看到 HTTPS 明文，只有两条路——
1 | HTTPS 密文流量 |
汇总对照表：
| 手段 | 层次 | 看 HTTP | 看 HTTPS | 能改包 |
|---|---|---|---|---|
| 被动嗅探 | 网络层 | 明文 | 仅握手元数据 | 否 |
| 代理（Burp） | 应用层 | 明文 | MITM 后明文 | 是 |
| VPN | 网络层隧道 | 出口可见明文 | 仅密文 | 否 |
| Wireshark + 密钥 | 旁路分析 | 明文 | 借密钥解密 | 否 |