做 Web 测试的朋友应该都有过这种体验：Burp Suite 里代理抓了一堆包，看着都挺可疑的，但真要一个个手动验证，效率实在跟不上。xray 的被动扫描又太依赖流量入口，没流量喂它就一直空转。两个工具单独用都有短板，组合起来反而很顺手。这篇文章就把 Burp Suite 和 xray 联动的完整思路、配置步骤、证书处理、过滤规则、常见坑一次性讲透，适合自己搭了靶场练手，或者在授权测试项目里提升覆盖率的场景。
1. 联动逻辑与适用场景
1.1 Burp Suite 的强项和短板
Burp Suite 在 Web 安全测试里基本上是标配。它的代理、抓包、改包、Repeater、Intruder 这些功能，让测试人员可以非常精细地控制每一个请求。遇到一个登录接口，我可以先在浏览器里走一遍登录流程，然后在 Repeater 里把参数改一改，看看返回有什么变化；遇到可疑的 JSON 字段，也可以断点式地修改请求体，观察目标系统有没有异常响应。这种“人工精细活”是它的核心价值。
但 Burp Suite 的短板也很明显：自带的 Active Scanner 虽然集成方便，实际用起来却经常不够痛快。扫一个稍复杂的业务系统时，速度不算快，还要处理登录态、动态 token、验证码等问题，配置成本不低。更常见的情况是，我手动测试已经走完了一轮功能点，抓到了几十个请求，却发现这些请求并不会自动变成一次系统性的漏洞扫描。如果这时候再单独跑一遍主动扫描，时间和流量开销都不小，而且可能因为会话失效导致结果失真。
1.2 xray 的定位和优势
xray 是典型的被动扫描器，它的工作方式非常直白：监听一个本地端口，等待其他代理把流量送过来，然后在请求和响应的基础上自动跑检测插件。你不给它流量，它就安静地站在那里；一旦有请求经过，SQL 注入、XSS、命令注入、SSRF、文件读取、目录枚举等插件就开始自动分析。
这个“流量驱动”的机制是它最大的优点，也是它最大的限制。优点在于，它可以跟着真实业务流量走，凡是用户和测试人员操作过的接口，都会自动过一遍漏洞检测，覆盖面广、速度快，对 JSON 接口、各种 Content-Type 的识别也比较友好。限制在于，它自己不产生业务流量，如果只靠它自带的爬虫去主动抓取，遇到登录态、JS 渲染、复杂交互容易漏，而且主动爬虫发出去的请求很容易触发目标侧的 WAF 告警。
1.3 联动的数据流和适用场景
把 Burp Suite 和 xray 接起来之后，数据流大致是这样一个走向：
浏览器 -> Burp Suite:8080 -> xray:7777 -> 目标服务器浏览器只和 Burp Suite 对话，Burp Suite 把请求原样转给 xray，xray 一边把请求转发给目标服务器，一边跑自己的被动检测插件。这样一来，测试人员可以继续用 Burp Suite 做精细的人工操作，而 xray 就在旁边默默打工，把每个经过的请求都“体检”一遍。
这个组合比较适合四类场景：
- 授权渗透测试项目：目标已经拿到授权，测试过程中可以用这套组合提升覆盖率。
- SRC 漏洞报送：在平台允许的范围内测试，Burp 负责记录和重放，xray 负责自动补漏。
- 自己搭的靶场和实验环境：怎么折腾都行，适合新手熟悉联动原理。
- 接口专项测试：目标接口数量多、参数复杂时，手动测不过来，联动可以辅助发现异常点。
如果只是想做纯主动爬虫、或者需要非常隐蔽地绕过流量检测，那这套方案不一定合适。但大部分日常测试场景下，联动带来的收益是实打实的。
2. 动手前的关键准备
2.1 工具版本与基本概念
Burp Suite Community 和 Professional 版本都可以玩这个联动，Community 免费版对联动配置没有限制，只是部分自动扫描功能被砍掉了，但不影响它作为流量入口使用。建议尽量用较新版本，新版本里 Upstream Proxy 的配置入口更好找，老版本的菜单路径会有一些差异。
xray 用开源社区版就够了，官方发布页下载对应系统的压缩包解压即可。Windows 下是 xray.exe，Linux/macOS 下是 xray 可执行文件。第一次运行最好先看下版本，不同版本的命令参数会有细微差异。
在配置之前，要先理解一个关键概念：代理链的方向。我们要做的是让 Burp Suite 把流量“向下游”转给 xray，也就是 Burp Suite 配置 Upstream Proxy 指向 xray 的监听端口。方向反了的话，xray 就成了上游代理，Burp Suite 反而拿不到明文请求，整个联动就废了。
2.2 证书机制：为什么只需要信任 Burp 的 CA
很多初次配置联动的朋友，会在证书这里绕晕。先说结论：在这个方案里，需要向浏览器导入的是 Burp Suite 的 CA 证书，xray 的证书可以不用管。
Burp Suite 监听 8080 端口后，浏览器访问 HTTPS 站点时，Burp Suite 会用自己的 CA 证书为目标站点临时签发一张证书，从而在中间解密 TLS 流量、查看明文内容。如果浏览器不信任 Burp Suite 的 CA，HTTPS 页面会直接报证书错误，所有请求都打不开。所以第一步是把 Burp Suite 的 CA 证书导入到系统或浏览器的受信任根证书列表里。
在浏览器访问http://burp，会看到一个页面，点击 CA Certificate 下载证书文件，然后导入到系统“受信任的根证书颁发机构”中。Windows 和 macOS 的导入路径不太一样，但核心逻辑都一样。导入后重启浏览器，HTTPS 站点就能正常走 Burp Suite 解密了。
xray 的证书为什么不需要导入？因为 Burp Suite 已经完成了 TLS 卸载，xray 拿到的是解密后的明文 HTTP 请求，不需要再对浏览器做中间人。xray 向目标服务器发起检测请求时，会自己建立新的 TLS 握手，这个环节跟浏览器信任哪个 CA 没有关系。所以整个链路里，只需要保证 Burp Suite 的 CA 被浏览器信任即可。
需要注意一个特例：如果某个目标域名被加进了 Burp Suite 的 TLS Pass Through 列表，Burp Suite 会对这个域名放弃解密，直接把原始 TLS 流量透传过去。这种情况下 xray 拿不到明文请求，自然也就扫不到这个域名的内容。所以做联动测试时，要确保目标域名没有被 Pass Through。
2.3 端口规划与网络路径
联动方案里涉及几个端口，提前规划好可以避免很多不必要的排查。
| 角色 | 监听地址 | 作用 |
|---|---|---|
| 浏览器代理 | 指向 127.0.0.1:8080 | 把浏览器流量交给 Burp Suite |
| Burp Suite | 127.0.0.1:8080 | 抓包、修改、转发请求 |
| xray | 127.0.0.1:7777 | 接收 Burp Suite 转发的流量并扫描 |
如果本机已经占用 8080 或 7777，Burp Suite 可以在 Proxy Settings 里改监听端口，xray 可以在--listen参数里指定其他端口。两个端口不要混用，否则流量链路会乱。
还有一个网络层面的事实需要提前理解：xray 收到 Burp Suite 转发的原始请求后，会把原始请求转发给目标服务器，同时自己再发送检测请求给目标。从目标服务器的视角来看，这些流量全部来自 xray 所在机器的 IP，而不是浏览器的内网 IP。如果 Burp Suite 和 xray 部署在同一台机器上，源 IP 看起来是一样的；如果分开部署，就要注意目标侧防火墙和安全设备对来源 IP 的白名单限制。
3. 一步一步配置联动
3.1 启动 xray 被动扫描
xray 的被动扫描启动命令比较直接，在终端里切到 xray 所在目录，执行：
./xray webscan --listen 127.0.0.1:7777 --html-output xray_report.html如果是在 Windows 环境，就是：
xray.exe webscan --listen 127.0.0.1:7777 --html-output xray_report.html--listen 127.0.0.1:7777表示 xray 监听本机的 7777 端口，等待其他代理转发流量过来。--html-output xray_report.html用于指定 HTML 报告输出文件，扫描过程中如果发现漏洞，会实时写进这个报告里。如果不想要报告，只想在终端看日志，这个参数也可以不加。
启动成功后，终端通常会输出类似“等待来自上游代理的请求”的日志。看到这行日志，说明 xray 已经进入被动扫描状态。
有些新版本第一次运行会提示没有配置文件，需要先运行一遍./xray version或者根据提示生成默认的 config.yaml。如果启动时提示缺少配置文件，按提示自动生成即可。
3.2 在 Burp Suite 中配置上游代理
打开 Burp Suite，进入 Settings，左侧导航栏找到 Network，点开 Connections，下面有一个 Upstream Proxy Servers 配置区块。点击 Add 添加一条记录。
关键字段有三个：
- Destination Host：留空。留空表示所有目标都走这个上游代理。如果只想让某个域名走 xray，可以在这里填对应的域名，比如
test.example.com。 - Proxy Host：填
127.0.0.1。 - Proxy Port：填
7777。
点击 OK 保存，确保列表里这条记录是启用状态。
这里要说明一下 Destination Host 留空的意义。实际测试中，浏览器会访问很多不同域名的资源，如果只填了一个目标域名，其他域名就不会经过 xray。留空虽然会让所有流量都经过 xray，包括一些静态资源、外域请求，但胜在配置简单。后续可以通过 xray 的 filter 参数来控制扫描范围，不一定非要在 Burp 这边做限制。
保存配置后，Burp Suite 的界面不会有明显变化，但所有经过 Burp 代理的请求都会先转给 xray，再由 xray 发往目标。排查联动不通时，优先检查这一条配置有没有真正保存成功。
3.3 浏览器代理指向 Burp Suite
浏览器需要把代理指向 Burp Suite 的 8080 端口，注意这里不是指向 xray，而是指向 Burp Suite。可以用系统代理，但我更推荐用浏览器代理插件，比如 SwitchyOmega 之类的工具，单独建一个情景模式：HTTP 代理填 127.0.0.1，端口填 8080，SSL 代理同样填 127.0.0.1 和 8080。
不建议直接开系统全局代理，因为那样会把本机其他软件的流量也带进来，Burp Suite 的 History 会塞满无关请求，xray 也会跟着扫描很多没用的目标，报告噪音变得很大。
配置好代理后，先访问一个 HTTP 站点，确认 Burp Suite 的 Proxy History 里能看到请求。能看到请求，说明浏览器和 Burp 之间的链路是通的。
3.4 验证联动是否真的打通
联动是否打通，不能只看 Burp Suite 有没有请求，还要看 xray 有没有真的吃到流量。最简单的验证方法：
- 保持 xray 终端窗口可见，确认还在监听 7777。
- 在浏览器里访问目标站点的一个具体页面，比如登录页或者任意一个带参数的 URL。
- 观察 xray 终端，如果出现“收到来自上游代理的请求”或类似的日志，同时出现正在扫描目标 URL 的提示，说明联动已经通了。
为了更直观地感受联动效果，可以在 Burp Suite 的 Repeater 里发送一个常规请求。把任意一个请求发送到 Repeater，点击 Send，xray 终端会立刻多出一条扫描记录。这是因为 Repeater 发出的请求同样会经过 Burp 的上游代理配置，被 xray 捕获。
有一个非常重要的认知必须提前建立：xray 发出的检测请求，是不会出现在 Burp Suite 的 Proxy History 里的。很多朋友第一次配联动时，习惯性地回到 Burp Suite 里找“xray 发出的流量”，找了半天找不到，误以为配置没生效。实际上 xray 在转发原始请求给目标服务器之后，会用自己的 HTTP 客户端直连目标发送检测 payload，这些检测流量并不走 Burp Suite，所以 Burp 里看不到。这是正常现象，不要因为这个误判。
如果 xray 终端一直没有任何反应，排查顺序是：先看 Burp Suite 的 Proxy History 里有没有浏览器产生的请求，确认 Burp 侧是通的；再检查 Upstream Proxy 列表里那条记录是否真的保存了、端口是否为 7777；最后看 xray 终端有没有报端口监听失败的错误。
4. 联动调优：减少噪音，提升检测质量
4.1 用 filter 限定扫描范围
被动模式下，所有经过 xray 的流量都会被扫描。实际浏览页面时，除了目标站点，还会有 CDN 资源、统计脚本、第三方字体、广告接口等一堆外部请求。如果不加限制，xray 会把这些外域请求全部扫一遍，既浪费时间，又让报告变得很嘈杂。
xray 的 webscan 子命令支持 filter 参数来限定扫描范围。常见做法是只扫描目标域名，比如：
./xray webscan --listen 127.0.0.1:7777 --filter "'*.example.com'"这里的 filter 语法在不同版本里略有差异，最稳妥的方式是运行xray webscan --help，查看当前版本对 filter 的说明。其核心作用是：只有匹配域名规则的请求才会进入扫描流程，其余请求直接放行。
我个人的使用习惯是，除了限定主域名，还会把常见的静态资源后缀排除掉，比如.js、.css、.png、.jpg这些不参与业务逻辑的资源，减少无效检测。不过这类后缀过滤如果写得太严格，也可能漏掉一些通过 JS 加载的接口，需要根据目标情况权衡。
4.2 重复扫描问题的处理
xray 内部对 URL 是有去重机制的，同一个 URL 一般只扫描一次。但它的去重粒度是 URL 全貌，包括路径、查询参数以及参数的顺序。也就是说，/api/user?id=1和/api/user?id=1&x=1会被视为两个不同的 URL，分别扫描一次。
在 Burp Suite 的 Repeater 里手动调整参数时，这个问题尤其明显。测试人员每点一次 Send，如果参数顺序变化了、或者随手加了一个无关参数，xray 都会把它当成新目标再扫一遍。短时间内大量重复请求，目标服务器会感受到明显的流量压力。
处理方式有两个方向：
- 测试时自己定好规范，尽量保持参数结构稳定，不要随意加无意义参数。
- 用
--json-output输出结构化报告，后续用脚本按 URL 路径和参数名做一次去重，把多次测试的重复结果过滤掉。
这样即使重复扫描发生了，也不会污染最终的漏洞报告。
4.3 插件开关与并发控制
xray 的 config.yaml 文件里可以控制各个插件的开关。被动模式下，不是每个插件都适合盲目开启。比如目录枚举类插件，会主动发送额外的目录探测请求，动静比较大；在正式授权测试环境中，如果目标系统对异常请求比较敏感，这类插件反而容易打草惊蛇。
我自己的经验是，根据测试目标的类型选择插件组合：
- 以 API 接口为主的测试，重点保留 SQL 注入、命令注入、SSRF、XML/JSON 解析类插件。
- 以页面功能为主的测试，可以保留 XSS、文件上传、任意文件读取等插件。
- 目录枚举、CORS 这类动静大的插件，一般按需开启。
并发控制也很重要。默认配置下，xray 多插件同时运行时，对目标服务器产生的请求量相当可观。遇到性能一般的目标系统，建议在配置里调低 QPS 上限、缩短超时时间，防止扫描动作把目标站点打崩。具体的参数名称和位置在 config.yaml 里有清晰注释，照着调整就行。
4.4 和 Repeater 配合的实操节奏
联动配置好之后，日常测试的节奏会变得非常顺畅。以一个后台业务系统的测试为例：
- 浏览器走一遍登录流程，Burp Suite 记录登录接口和 Cookie。
- 登录成功后，手动点击后台各个菜单，比如用户列表、文件上传、数据导出。
- 每点一个按钮，xray 就在后台自动扫描对应的接口。
- 遇到重点接口，把请求丢进 Repeater，手工调整参数——比如把
id=1改成id=2，或者修改请求体里的 JSON 字段。 - xray 会同步检测这些重放请求，报告里实时补充结果。
这个节奏最大的好处是，xray 的检测不再依赖爬虫去“猜”业务路径，而是跟着测试人员的操作走。凡是人工到过的地方，xray 都会自动过一遍漏洞检测；凡是人工觉得可疑的参数，xray 都会帮你做一轮 payload 级别的试探。再加上后续用 Burp Suite 对 xray 报出的可疑点做二次验证，误报率会明显降低。
5. 常见问题排查与避坑记录
5.1 典型问题速查
把实际使用中遇到比较多的问题整理成一张速查表，方便配置时对照排查。
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| xray 终端一直没有请求日志 | Burp Suite 上游代理没配置或没保存 | 回 Settings 检查 Upstream Proxy 列表，确认端口是 7777 |
| HTTPS 站点扫不到漏洞 | Burp Suite CA 未安装，或目标域名在 TLS Pass Through | 导入 Burp CA 证书；移除目标的 Pass Through 规则 |
| xray 报证书校验错误 | xray 和目标服务器之间的 TLS 握手失败 | 检查目标证书链是否完整、本机系统时间是否准确 |
| 报告里夹杂大量外域请求 | 没加 filter 限定扫描范围 | 启动 xray 时加 --filter 指定目标域名 |
| 同一个接口反复出现多次报告 | Repeater 改参数导致 URL 变化 | 统一测试习惯；用 JSON 输出后自行去重 |
| Burp History 里看不到 xray 检测流量 | 正常现象，xray 直连目标发送检测请求 | 不需要处理，不要把这个当成故障 |
| 目标站点响应明显变慢 | xray 并发过高、插件过多 | 调整 QPS、缩短超时、关闭非必要插件 |
5.2 排查顺序与日志技巧
联动出问题时，不要慌，按照下面的顺序排查，通常很快就能定位：
- 先确认 Burp Suite 的 Proxy History 里有没有浏览器的流量。没有，就说明代理设置或浏览器指向有问题，跟 xray 无关。
- 再确认 Burp Suite 的 Upstream Proxy 列表里，xray 那条记录存在且启用了。端口写错是最常见的手误。
- 再看 xray 终端有没有报错日志。有些版本会直接提示端口被占用，或者配置文件格式不对。
- 最后确认 filter 规则没有把目标域名过滤掉。有时候配置了太严格的 filter，请求进来被直接放行，也不会产生扫描日志。
我习惯在 xray 启动时把日志级别调高一些，多输出一些调试信息。这样一旦某条请求没有被扫描，能直接从日志里看到是“放行了”还是“没收到”，排查效率高很多。
5.3 几个容易被忽略的细节
联动配置本身不难，但有几个细节我会反复提醒自己和身边的人：
- 测试过程中，建议在 Burp Suite 的 Repeater 里做修改测试时，刻意保持参数顺序稳定。这样 xray 的去重机制能发挥最大作用，避免无效重复扫描。
- 如果目标站点有 WAF 或安全设备，xray 的检测流量可能被拦截，进而导致报告里出现大量“扫描超时”或“请求异常”。这种情况下，适当下调并发、延长超时时间，有时能改善不少。
- 在一些严格限制出口 IP 的环境中，xray 所在机器的 IP 不在目标白名单里，联动会一直“看起来没反应”，实际上请求还没到达目标就已经被网络层丢弃了。这时需要检查网络策略，而不是反复调代理配置。
- 不同版本的 xray 在命令参数上确实有差异，遇到参数不识别的情况，第一时间跑一下帮助命令看看当前版本支持哪些参数，比在网上盲目搜索旧教程要节省时间。
这些坑大多数不影响最终配置成功，但知道之后能少走很多弯路。
写在最后的一点体会
这套配置我用了很长时间，最大的感受是 Burp Suite 和 xray 本来就不是竞争关系，一个管深入人工测试，一个管广覆盖自动检测。把它们接起来之后，手动测试的每个请求都等于多了一次自动体检，漏报率降了不少。日常测试中，我最常用的是在 Repeater 里每发一个请求，旁边的 xray 终端就跟着滚动日志，那种“有人在帮你盯着”的感觉，确实让测试过程更踏实。
最后还是要强调一句，不管是 Burp Suite 还是 xray，都只用在授权目标上。自己搭个靶场，或者走完授权流程的测试项目，怎么折腾都行。配置步骤其实就这么点，真正值钱的是配合的习惯和节奏。把这套联动跑顺之后，再回头看手动测试和自动扫描割裂的状态，你会觉得当初没早点接起来真是太亏了。
