httpx 数字解读：HTTP 探测工具值不值得试
httpx 是 ProjectDiscovery 用 Go 写的 HTTP 探测命令行工具，输入域名、URL 或 CIDR，批量输出存活状态、标题、状态码、TLS 证书与指纹。这篇文章用仓库公开数字和真实 Issue 记录，帮读者判断它是否适合自己的资产梳理场景。
手里先有一串子域名或 IP 段，接下来要回答的问题很碎：哪些还活着、返回什么状态码、页面标题是什么、用了什么框架、证书里还挂着哪些域名、要不要顺手截个图。用脚本加 curl 硬拼也能出结果，并发一上去容易丢数据，碰到 WAF 拦截又没有退避机制。httpx 把这些探测收进一个命令行程序，用 retryablehttp 处理重试与退避，靠增加线程数提升吞吐，同时维持结果的可靠性。
httpx 是 ProjectDiscovery 用 Go 写的 HTTP 探测工具，输入域名、URL 或 CIDR，批量输出存活状态、标题、状态码、TLS 证书、指纹、截图等信息。
它的常见位置是侦察流水线的一环，前面接子域枚举工具，后面接漏洞扫描器。输入可以从文件读（-l）、直接写在命令行（-u），也能从管道灌进来；输出默认打在终端，也能走 JSON、CSV、JSONL，或写进 MongoDB、PostgreSQL、MySQL。用的人主要是做外部资产盘点的安全工程师、漏洞赏金参与者，以及需要给一批域名批量确认存活与指纹的运维。
它能探测和输出什么
标志位按输入、探测、无头浏览器、匹配器分组，同一批目标可以在一次跑批里拿到多类结果。
- 多类探测项。状态码
-sc、内容长度-cl、内容类型-ct、跳转地址-location、页面标题-title、服务端名称-server、响应时间-rt、行数-lc、词数-wc、正文前若干字符-bp（默认 100）、favicon 的 mmh3 哈希-favicon、JARM 指纹-jarm、响应体哈希-hash（支持 md5、mmh3、simhash、sha1、sha256、sha512）、WebSocket-ws、IP-ip、CNAME-cname、ASN-asn、CDN/WAF-cdn、请求方法-method、探测状态-probe。标志位数量不少，实际用哪几个取决于你要回答什么问题。 - 输入形态。支持 hosts、URLs 和 CIDR 三类输入；
-l读列表文件，-u直接给目标，-rr读原始请求文件，-im burp用于 Burp 导出的输入。默认带 https 到 http 的自动回退，目标只开 80 端口也不会漏。 - 无头浏览器截图。
-ss开启页面截图，-system-chrome用本机已装的 Chrome，-ho追加启动参数，-st设超时（默认 10s），-sid设截图前空闲等待（默认 1s），-jsc在导航后执行 JavaScript。-esb与-ehb分别把截图字节和 headless 头从 JSON 输出里排除，-no-screenshot-full-page关闭整页截图。这一组要求环境里有浏览器。 - 匹配器。用
-mc按状态码筛、-ml按内容长度、-mlc按行数、-mwc按词数、-mfc按 favicon 哈希、-ms按字符串、-mr按正则、-mcdn按 CDN 供应商、-mrt按响应时间。这批标志让结果在跑批阶段就被过滤，不用落地后再写一轮脚本。 - 技术指纹与知识库分类。
-td按 wappalyzer 数据集识别在用技术，-cff指定自定义指纹文件。v1.9.0 加了页面、表单与表单字段的分类器，v1.11.0 起把页面类型分类改成显式开启，用-kb。 - TLS 指纹冒充。v1.11.0 为
-tls-impersonate增加了 chrome 和 JA3 策略，让握手层更接近普通浏览器。 - 结果落库。v1.9.0 起支持把扫描结果写进 MongoDB、PostgreSQL、MySQL。
- 断点续跑。中断后可以从
resume.cfg恢复。事实表里有用户报告过这个文件在工具完成校验或刷新之前就落盘的问题，该条已标记为解决。
安装要求 Go 1.25.0 以上：
go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest最短的一次跑通，把目标交给 stdin，打开标题、状态码与技术识别：
echo https://example.com | httpx -title -status-code -tech-detect
httpx -u https://example.com -sc -title -td -silent结果默认打在终端，-silent 只留结果行方便串管道；要结构化输出可以走 JSON、CSV 或 JSONL，Issue 里出现过用 -j 时文件未生成与格式异常的报告，均已标记为解决。截图默认落到哪个目录、输出文件怎么命名，README 里没有说明，这部分要查官方文档站点 docs.projectdiscovery.io。
同类项目横向对照
| 项目 | 适合谁 | 部署方式 | 主要限制 | 什么情况下选它更合适 | 项目地址 |
|---|---|---|---|---|---|
| httpx | 要在授权范围内给成百上千个域名做存活、指纹、证书和截图确认的安全工程师 | 用 go install 安装，仓库也提供 Dockerfile 与 Docker Hub 镜像 | 安装需 Go 1.25.0 以上；README 自述处于活跃开发中，升级要读 changelog；README 明确说主要为独立 CLI 设计，当服务跑有安全风险 | 目标量大，且想在一次跑批里同时拿到标题、状态码、TLS 证书、指纹和截图 | httpx |
| cokmap | 只想弄清目标开了哪些端口、上面跑着什么服务的扫描者 | 未逐一核实 | 未逐一核实；从描述看聚焦网络扫描与指纹识别，不覆盖 HTTP 响应层的细节 | 任务只到端口与服务识别为止，不需要标题、跳转链这类 HTTP 层结果 | cokmap |
| certinfo | 只想从 HTTPS 站点证书里批量提取域名的人 | 未逐一核实 | 未逐一核实；从描述看只做 SSL 证书抓取与域名提取 | 只要证书里的域名，不想为一次提取去记一串 httpx 标志位 | certinfo |
三个项目都在做同类的事，重合一处在「从目标上取回信息」，不重合处在取什么。cokmap 与 certinfo 各自只盯一个角度，httpx 把存活、指纹、证书、截图压进一次跑批。如果你要做的只是从证书里批量提域名，httpx 那一长串默认探测项和标志位反而是负担，certinfo 这类窄工具路径更短；反过来，只想确认端口和服务，cokmap 的定位更直接。httpx 的优势场景是目标量大、要的字段多、结果还要往下游灌。
它的实际表现
- Star：10438
- Fork：1107
- Watcher：86
- 开放 Issue：15
- 许可证：MIT
- 主要语言：Go（占 71.2%，另有 HTML 28.6%、Shell 0.1%）
- 创建时间：2020-05-29
- 最近一次提交：2026-09-24（事实表抓取时间为 2026-09-30）
- 最近一次发布：v1.12.0，2026-09-08
- 仓库体积：5510 KB，默认分支为 dev
这些数字说明什么
创建于 2020-05-29，到 2026 年已经持续六年多，说明它经历过足够长的使用周期，不是一阵热度留下的仓库。
最近一次提交是 2026-09-24，距事实表抓取时间 2026-09-30 只有 6 天，代码主线还在动。版本节奏也能对上：v1.8.1 在 2026-01-22、v1.9.0 在 2026-03-10、v1.10.0 在 2026-07-10、v1.11.0 在 2026-08-31、v1.12.0 在 2026-09-08，八个月里发了五个版本，最近两个版本相隔 8 天。
10438 个 Star 与 1107 个 Fork 的比例接近十比一，说明关注它的人远多于直接改它的人，它更像一个被当成基础设施调用的工具，而不是一个鼓励二次开发的框架。Open Issue 只有 15 条，相对这个体量偏低，与事实表里列出的高频 Issue 全部标记为「已解决」是一致的。
MIT 许可证加上以 Go 为主的语言构成，意味着可以直接编译成单个二进制塞进流水线，商用和内部改造都没有许可证障碍。
数据看不到的部分
Star 和 Fork 量的是关注度，量不出代码质量，也量不出并发拉高之后结果准不准。事实表里有一条 CIDR 配 -ports 会漏掉有效主机的报告，正是这类「跑得快但结果对不对」的问题，而这类问题在 Star 数上完全看不出来。
开放 Issue 只有 15 条，不等于坑少。它更可能说明处理得快，也可能说明一部分问题被引导到别处去了。事实表里把 14 条高频 Issue 全部标为已解决，但「已解决」指的是仓库那边的状态，不代表你在自己的网络环境里不会复现：有几条就是 VPN 环境下部分主机超时、200 的 URL 被读成 404 这类依赖具体链路的问题。
提交时间和版本号看不出文档是否跟得上实现。README 已经 22.3 KB，标志位表还在随版本扩，官方文档另挂在 docs.projectdiscovery.io 上，两者与当前版本是否同步，这些指标一个都反映不了。
近 30 天增长、提交频率这类指标，事实表没有提供，所以热度是升是降这里判断不了。截图目录、输出文件命名规则这类落地细节，README 也没写。
所以值不值得试
值得试的情形。你手里已经有一份子域或 IP 列表，要在一次跑批里同时拿到存活、状态码、标题、TLS 证书、技术指纹和截图，并且这些结果要往下游灌，走 JSON、CSV 或数据库；本机装了 Go 1.25.0 以上，或者愿意用 Docker 镜像，安装成本对你来说不高。
先别急的情形。你只需要取回单个页面的正文，curl 或者浏览器更直接；你想把它当成常驻服务对外开放，README 明确写着这个项目主要为独立命令行使用而设计，当服务跑可能带来安全风险，并建议配合额外的安全措施。
httpx 属于探测类工具，只能用于自己拥有或已经获得明确书面授权的资产。对别人的域名批量跑探测，在多数司法辖区都可能触及未授权访问相关的法律问题，也会触发对方 WAF 和云厂商的风控，轻则出口 IP 被封，重则收到正式的法律函件。漏洞赏金场景要在项目声明的测试范围内按它给的规则跑，越界的结果不算你的成绩。仓库地址是 https://github.com/projectdiscovery/httpx，许可证为 MIT License，主要语言是 Go。
焚评：这个项目的量化评分
本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 10.0 分（满分 10）。下表是各维度的得分：
| 评分维度 | 得分 |
|---|---|
| 热度动量（权重 25%） | 10.0 / 10 |
| 开发活跃（权重 25%） | 10.0 / 10 |
| 社区响应（权重 15%） | 10.0 / 10 |
| 文档质量（权重 15%） | 10.0 / 10 |
| 发布节奏（权重 10%） | 9.6 / 10 |
| 风险控制（权重 10%） | 10.0 / 10 |
评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。
内容核验说明
这篇把 httpx 的标志位、输入形态、同类工具对比和仓库数字放在一起，给的是判断依据而不是安利。有用之处在于：批量资产盘点该开哪些探测项，和 cokmap、certinfo 怎么选，以及 Star、Issue 数之外看不到的东西——CIDR 配 -ports 漏主机、VPN 环境超时这类链路相关问题。适合已有子域列表、要一次跑批拿多类结果的安全工程师。
文中的 Star、Fork、Open Issue 数、提交时间与版本节奏来自仓库公开页面的抓取结果，诀.com 未独立验证。所列 Issue 案例取自仓库提交记录且均标注为已解决；「已解决」是仓库那边的状态，不代表在其他网络环境不会复现，本文也没有实际运行 httpx 的测试数据。焚评评分由焚.com 授权引用，口径以其评分方法页为准。用户反馈摘要
根据仓库 Issue 来看，提交者反映的问题集中在几类：v1.1.4 出现空指针 panic、CIDR 配 -ports 漏掉有效主机、resume.cfg 在工具完成校验前落盘导致中断恢复后目标被跳过、-pr http11 因 retryablehttp 的 HTTP/2 回退被忽略、http-proxy 未生效与 User-Agent 截断、DNS 收到完整 URL、-j 的 JSON 字段无法按标志位定制。另有提交者提到大批量目标提前停止、VPN 下少数主机超时。这些报告状态均为已解决，多集中在并发与环境相关的边界情况。
基于该仓库公开 Issue 整理，只反映提交者报告的现象与诉求，不代表诀.com 立场，也不代表问题已被确认。项目来源与说明
开源项目：projectdiscovery（projectdiscovery）
本文由诀.com 编辑基于该项目的公开信息独立撰写，属原创解读，不是对项目文档的翻译或转载；文中提到的功能与参数以官方仓库为准，代码与文档版权归原作者所有。
查看项目仓库