Burp Suite拦截detectportal.firefox.com导致Firefox网络诊断失败？

Question

常见问题：当 Burp Suite（尤其启用透明代理或系统级代理配置）拦截 Firefox 发起的 `detectportal.firefox.com` 请求时，会破坏 Firefox 的网络连接健康检查机制。该域名是 Firefox 用于检测 Captive Portal（如机场/酒店登录页）和验证互联网连通性的关键端点（HTTP 302 重定向至 `http://detectportal.firefox.com/success.txt`，期望返回 200 OK 及特定响应体）。Burp 默认拦截并改写响应（如返回 403、502 或篡改 Content-Type/Body），导致 Firefox 误判为“无网络连接”或“门户检测失败”，进而禁用 HTTPS-Only 模式、阻止自动更新、禁用同步功能，甚至在地址栏显示“脱机”提示。此问题在开发者启用 Burp 后未配置恰当的 scope 排除规则或未放行该域名的 HTTP/HTTPS 流量时高频出现，且不易被直观定位——因请求无用户显式触发，仅后台静默执行。

Answer 1

```html

一、现象层：Firefox 地址栏突现“脱机”提示，同步/更新/HTTPS-Only 全面失效

开发者启用 Burp Suite（尤其勾选 Proxy → Options → Proxy Listeners → Bind to port 并启用系统级代理）后，未观察到显式请求，但 Firefox 突然显示灰色地球图标+“脱机”文字；about:preferences#privacy 中 HTTPS-Only 模式自动关闭；about:support 显示“Application Update: Disabled (Connection failed)”；登录账号同步中断。此为最表层可观测症状，常被误判为网络故障或 Firefox 自身 Bug。

二、协议层：Firefox Captive Portal 探测机制被静默劫持

• Firefox 每 60–300 秒（依网络状态动态调整）向 https://detectportal.firefox.com 发起 GET 请求
• 该请求实际触发 HTTP 302 重定向至 http://detectportal.firefox.com/success.txt（注意：明文 HTTP！）
• 预期响应：HTTP/1.1 200 OK + Content-Type: text/plain + 响应体严格等于 success（无空格、无换行、无 BOM）
• Burp 默认拦截该 HTTP 流量（因透明代理捕获所有 TCP 80/443），若未放行则返回 502 Bad Gateway 或篡改响应体，导致 Firefox nsICaptivePortalDetector 接口判定失败

三、架构层：Burp 的代理链路与 Firefox 网络栈冲突点分析

组件	行为	冲突根源
Firefox Network Stack	使用独立 socket 连接 detectportal.firefox.com，绕过 PAC/Proxy Auto-Config，强制走系统代理	Burp 作为系统级代理无法区分“健康检查流量”与业务流量
Burp Proxy Listener	默认监听 127.0.0.1:8080，透明代理模式下劫持全部 80/443 出站连接	未配置 Proxy → Options → Match and Replace 或 Project options → Proxy → Request Handling → Skip URLs in scope

四、诊断层：三步定位法精准识别问题根源

1. 抓包验证：在 Burp Proxy → HTTP history 中搜索 detectportal，确认存在 403/502/空响应记录
2. 终端复现：执行 curl -v http://detectportal.firefox.com/success.txt（需确保系统代理环境变量生效），观察是否返回 200 + "success"
3. Firefox 日志：访问 about:networking#http → 点击 “Enable Logging”，刷新后搜索 captive，可见 CaptivePortalService: network status changed to OFFLINE

五、解决层：生产就绪的四重防护方案

# 方案1：Burp Scope 白名单（推荐）
Project options → Target → Site map →右键→ "Add to scope" → 输入 https://detectportal.firefox.com

# 方案2：Match & Replace 规则（兼容旧版 Burp）
Proxy → Options → Match and Replace → Add → 
Match type: Response body → Match: .* → Replace: success → Scope: Only in-scope

# 方案3：Firefox 本地绕过（开发机专用）
about:config → 新建布尔值 network.proxy.no_proxies_on → 值设为 "detectportal.firefox.com,localhost,127.0.0.1"

# 方案4：系统级代理排除（Windows/macOS）
Windows：设置 → 网络和 Internet → 代理 → 手动设置 → 在"不使用代理服务器的地址"添加 detectportal.firefox.com

六、进阶层：自动化检测与 CI/CD 集成建议

将以下 Bash 脚本嵌入开发环境初始化流程，每次启动 Burp 前校验：

#!/bin/bash
if curl -s -o /dev/null -w "%{http_code}" http://detectportal.firefox.com/success.txt | grep -q "200"; then
  echo "[✓] Firefox portal check passes"
else
  echo "[✗] Burp is blocking detectportal.firefox.com — please adjust scope"
  exit 1
fi

七、原理层：为什么必须同时放行 HTTP 和 HTTPS？

Firefox 实现细节：首次探测使用 HTTPS（SNI 为 detectportal.firefox.com），但重定向目标为明文 HTTP URL（http://detectportal.firefox.com/success.txt）。Burp 若仅放行 HTTPS 域名，HTTP 重定向请求仍被拦截，导致响应体丢失。因此 Scope 必须包含 http://detectportal.firefox.com 和 https://detectportal.firefox.com 两个协议变体。

八、演进层：Firefox 120+ 的新行为与 Burp 2024.9 兼容性

graph LR
  A[Firefox 120+] -->|新增| B[QUIC 探测 fallback]
  B --> C{是否支持 HTTP/3?}
  C -->|是| D[尝试 h3://detectportal.firefox.com]
  C -->|否| E[回退至 HTTP/1.1]
  D --> F[Burp 2024.9+ 支持 h3 proxy]
  F --> G[需启用 Proxy → Options → Support HTTP/3]

九、生态层：同类问题横向对比（Chrome/Safari/Edge）

• Chrome：使用 http://clients3.google.com/generate_204，同样需在 Burp Scope 中放行
• Safari：macOS 系统级 ncm 服务调用 http://captive.apple.com，需在 macOS 网络设置中排除
• Edge：复用 Windows Network Connectivity Status Indicator（NCSI），请求 http://www.msftconnecttest.com/connecttest.txt

十、反模式层：绝对禁止的错误操作

❌ 在 Burp 中全局禁用拦截（Intercept is on/off）——掩盖问题而非解决；
❌ 修改 Firefox 源码禁用 captive portal（风险：破坏证书吊销检查逻辑）；
❌ 使用 Burp 的 “Drop” 功能代替 “Forward” 处理该请求（导致超时而非失败，更难排查）；
❌ 仅放行域名但忽略端口（如 detectportal.firefox.com:80 未显式声明）；
❌ 在企业代理环境中依赖 PAC 脚本过滤（Firefox 对 PAC 的 captive portal 探测有特殊 bypass 逻辑）。

```