assetnote/h3fuzz

如果你已经在用 ffuf 做内容发现，目标又支持 HTTP/3，h3fuzz 值得一看：同样的目标、字典和过滤条件，可以换来高得多的请求速率。但描述里的吞吐数字来自 PortSwigger 的研究场景，并不是 h3fuzz 本身经过独立验证的基准。

解决什么问题

做内容发现的测试者想拿一份大字典型，对着获授权目标扫一遍，最后得到一份可用的路径清单。在 HTTP/1.1 下，每个请求都要新建 TCP 连接，大字典型很快就会被连接建立开销拖住，扫描速度只剩下并发数和本地网络能容忍的水平。h3fuzz 换掉了这一步：它先协商 HTTP/3，失败再依次退到 HTTP/2 和 HTTP/1.1，并在每条 QUIC 连接上多路复用大量流。最终结果仍是那类规范化后的结果集，只是网页控制台能显示滚动速率和峰值速率，而不只是一个结束时间。

有什么不同

这个 fork 保留了 ffuf 的接口，已有的目标、字典、匹配规则、过滤器和请求文件大多可以继续用。这点的价值不在协议本身，而在迁移成本：不用重新学一套工具，只要把扫描器指向新的传输方式。扫描前，h3fuzz 会先判断是否可以用 HEAD 或 Range: bytes=-1 作为更小的响应策略，只有反复基线请求都显示响应元数据仍然可靠时才会采用。这个约束是合理的，因为响应最小化恰恰可能改变匹配规则所依赖的状态码、大小和耗时信号。控制台还增加了 SQLite 持久化会话、协议预检报告和目录树视图，比盯着终端滚屏舒服不少。代价是：它是受 Tom Stacey 的 PortSwigger 研究启发而写的 Go 实现，不是久经考验的扫描器，项目还很早；而且 HTTP/3 优先只在目标真的支持 HTTP/3 时才有用。对只支持 HTTP/1.1 的主机，你多了一步预检，换来的却是一个更不成熟的代码库，吞吐上没有任何好处。描述里的每秒 10 万次请求来自 PortSwigger 的研究条件（笔记本走 Wi-Fi，以及和目标同区域的云主机），不是 h3fuzz 自己被证明能达到的速率。

谁值得试

适合：已经在用 ffuf 的渗透测试者，目标支持 HTTP/3，又想要一个带持久化结果和可见速率的交互式控制台。也适合：自己拥有目标，想在协调好的测试中测量服务能承受多少负载的人。不适合：只想对只支持 HTTP/1.1 的应用做一次快速扫描，这种情况原生 ffuf 更简单；也不适合那些需要在客户项目中使用一个可靠性经过独立验证的扫描器的人。内置的 ASP、ASP.NET、PHP、JSP 和目录类配置，加上兼容 DirSearch 的 -D 参数，面向的是熟悉的目录爆破流程，对这类用户来说从现有 ffuf 设置迁移过来不会太久。

使用条件与边界

从源码构建需要 Go 1.26；Linux、macOS 和 Windows 的预编译包可以免去这一步，编译好的前端资源也意味着常规构建不依赖 Node.js。网页控制台默认启用 TLS 并生成自签名证书，除非设置 -web-allow-remote，否则拒绝监听非回环地址；README 建议用 SSH 隧道访问。远程监听和明文 HTTP 都有明确的注意事项，最好在扫描前就规划好怎么连控制台，而不是扫完再想。持久化的 SQLite 数据库存的是结果元数据而不是原始响应体，但大扫描仍可能占用可观空间，因为大部分响应都会被保留，所以把目标正常的 404 响应过滤掉，是日常使用中需要留意的事。合规边界是常规的那几条：只扫描自己拥有或获得明确授权的系统，高速率很可能触发防护或产生成本。

HotRepo 点评

HotRepo 在 2026-10-24 首次记录该项目，当时它才 12 天；2026-10-25 在新项目榜（不是总榜）上观察到一次，129 总星、#22。这只是一个单点快照，说明不了关注度能否持续，也没有可比的每日榜单历史。在依赖它之前，建议对照 README 中创建扫描和协议预检报告的说明，先在自己控制的目标上确认预检行为是否符合预期。

项目源码与说明