crt.sh 速率限制 —— 我们实际知道的
crt.sh 没有公开速率限制，但任何尝试脚本调用它的人都撞过墙。这里是社区多年测试的共识，以及几种让 recon 流水线继续工作的方法。
尽我们所知的数字
- 每分钟约 5 次请求（按源 IP，JSON 端点），多年社区报告都接近此数。
- 不返回 429。服务器会返回 502 Bad Gateway、空数组，或长时间挂起的查询。
- 没有 Retry-After。退避策略自己定。社区经验值是请求间隔 12-15 秒。
- 通配符代价更重。通配符查询（%.example.com）消耗更多查询预算，更快撞限。
- 非对称：HTML 界面通常仍响应，JSON 端点已拒绝，说明走不同查询路径。
为什么有这个限制
crt.sh 用一个 PostgreSQL 实例查询几十亿行。一个客户端的并发重查询可以把整个服务挤死。Sectigo 把 crt.sh 当免费公共服务运营 —— 速率限制是为了保持服务可用，不是为了变现。
如何让你的流水线继续工作
1. 激进缓存
CT 数据只会增长。一旦你拿到某域名的证书历史，只有新条目重要。用 ETag/条件请求查自己的缓存，别去打 crt.sh。
2. 用通配符查询替代逐子域循环
一次 %.example.com 比 200 次单独子域查询便宜，即使通配符单次成本更高。
3. 使用公开了配额的服务
CT Radar 免费档每天 100 次搜索，超额时显式返回 429 + Retry-After header。Pro 档提到 10K/天。Censys、Cert Spotter 等也有公开配额。
4. 自建 CT 镜像
如果量够大，用 certspotter（开源）直接消费 CT 日志自己索引。crt.sh、Censys、CT Radar 内部都是这么做的 —— 没有捷径。