2. 代理与浏览器协同工作流

Burp Suite 的核心能力建立在“中间人代理”这一机制之上。浏览器发出的每一个 HTTP 请求，本可以直接送达目标服务器，但在代理模式下，请求会先被送到 Burp 监听的端口，由 Burp 解析、记录、必要时修改，再转发给服务器；服务器返回的响应同样先经过 Burp，最后才回到浏览器。理解这条往返链路，是后续所有抓包、改包、重放操作的前提。

HTTP 代理的原理相对直观：浏览器把完整的请求行和请求头发给代理，代理根据 Host 头或请求行中的绝对 URI 决定转发目标。而 HTTPS 则不同，浏览器与服务器之间本应建立端到端加密的 TLS 通道，代理无法直接读取明文。Burp 的做法是“分而治之”：它用自己的 CA 证书分别与浏览器、与服务器建立两条独立的 TLS 连接，浏览器以为自己在和服务器对话，实际上中间多了一层 Burp。这就是 HTTPS 抓包必须安装并信任 Burp CA 证书的根本原因。

证书安装与信任链配置

要让浏览器接受 Burp 动态签发的站点证书，必须把 Burp 的 CA 根证书导入到浏览器或操作系统的信任库中。操作路径是：浏览器配置好代理后访问 http://burp，点击页面上的 “CA Certificate” 下载 cacert.der，再导入信任库。Firefox 有独立的证书管理器，需要单独导入；Chrome、Edge 在 Windows 上通常读取系统证书库，导入到“受信任的根证书颁发机构”即可。

导入时有两个常见坑。第一，证书必须放进“受信任的根证书颁发机构”，如果误放进“个人”或“中间证书颁发机构”，浏览器仍会报 NET::ERR_CERT_AUTHORITY_INVALID。第二，部分新版浏览器对证书有效期和密钥用途有更严格校验，若 Burp 版本过旧，可能出现证书被拒的情况，此时升级 Burp 并重新导出 CA 证书即可。验证是否配置成功，最直接的方法是访问任意 HTTPS 站点，观察地址栏是否仍显示锁形图标且无告警，同时 Burp 的 HTTP history 中能看到该请求的明文内容。

浏览器代理切换策略

日常浏览与安全测试往往需要频繁切换代理，手动改系统代理既慢又容易忘记关闭。推荐使用浏览器扩展（如 FoxyProxy、SwitchyOmega）建立多个代理配置：一个“直连”用于正常上网，一个“Burp”指向 127.0.0.1:8080，通过点击图标一键切换。更精细的做法是按域名规则分流，例如只把测试目标域名走 Burp，其余流量直连，避免无关请求污染 HTTP history。

如果不想让浏览器流量全部经过 Burp，也可以使用 Burp 内置的代理监听配置，把监听地址绑定到 127.0.0.1 而非 0.0.0.0，减少被局域网其他设备误用的风险。切换代理后若发现请求没有出现在 Burp 中，先检查扩展是否真的启用了对应配置，再确认 Burp 的 Intercept 是否处于关闭状态——Intercept 开启时请求会被挂起等待放行，容易误判为“没抓到”。

上游代理与 SOCKS 代理

当测试环境要求流量先经过公司统一出口，或需要通过跳板访问目标时，就要用到上游代理。Burp 支持在 Settings → Network → Connections → Upstream Proxy Servers 中配置：指定目标主机（可用通配符 *）和上游代理地址、端口、认证信息。这样 Burp 转发请求时会先连上游代理，再由上游代理连目标服务器，形成“浏览器 → Burp → 上游代理 → 服务器”的链路。

SOCKS 代理则常用于把流量导入到本地工具链，例如通过 proxychains 或 SSH 动态转发建立 SOCKS5 通道。Burp 本身不直接作为 SOCKS 客户端，但可以让浏览器或上游工具使用 SOCKS，再把流量交给 Burp。典型组合是：浏览器 → Burp（HTTP 代理）→ SOCKS5（如 127.0.0.1:1080）→ 目标。配置时注意 SOCKS5 支持远程 DNS 解析，能避免 DNS 泄漏，这对需要隐藏真实解析路径的场景很重要。

移动端抓包接入

移动端抓包的关键是让手机流量经过 Burp。首先确保手机与运行 Burp 的电脑在同一局域网，然后在手机 Wi-Fi 设置中配置手动代理，主机填电脑的局域网 IP（如 192.168.1.100），端口填 8080。接着用手机浏览器访问 http://burp 下载 CA 证书。Android 7 及以上版本默认不信任用户安装的证书，需要在应用层配置 network_security_config 或使用已 root 的设备把证书装入系统证书目录；iOS 则需在“设置 → 通用 → 关于本机 → 证书信任设置”中手动开启对该根证书的完全信任。

移动端常见问题包括：代理配置后无法上网，通常是电脑防火墙拦截了 8080 端口；部分 App 使用证书绑定（SSL Pinning），即使安装了 CA 证书也无法解密，此时需要借助 Frida 等工具绕过绑定，或改用其他测试手段。抓包前建议先关闭手机上的 VPN 和私人 DNS，避免流量绕过代理。

把上述链路串起来看，代理协同工作流的本质是“让流量可控地经过一个可观测、可修改的中间节点”。证书解决的是“能不能看懂 HTTPS”，代理切换解决的是“什么时候走 Burp”，上游与 SOCKS 解决的是“流量还要再经过谁”，移动端接入解决的是“非桌面环境怎么接进来”。四者配合，才能覆盖绝大多数 Web 安全测试的抓包需求。