composer镜像源本身不提供恶意爬虫检测与动态验证码能力，所有防护必须在反向代理层（如nginx）或waf实现，且不能干扰composer协议语义；因composer客户端仅发起无状态get请求、不执行js、不处理html/跳转，返回验证码页或非json响应将直接导致install失败。
Composer镜像源本身不提供恶意爬虫检测与动态验证码能力，所有这类防护必须在反向代理层（如 Nginx）或 WAF 层实现，且不能干扰 Composer 协议语义——否则会导致 composer install 失败。
为什么不能在 Composer 镜像服务端加验证码
Composer 客户端是纯 HTTP 工具，不执行 JavaScript、不处理 HTML 表单、不维护 Cookie 会话。它发起的请求都是无状态的 GET 请求，例如：
GET /composer/p2/monolog/monolog.json HTTP/1.1<br>User-Agent: composer/2.9.6 (Linux; 64bit) PHP/8.3.0
一旦你在响应中返回 302 跳转到验证码页，或返回含 <script></script> 的 HTML 页面，Composer 就会直接报错：Invalid response body 或 JSON decode error，整个安装流程中断。
常见错误现象：
- 用户配置了镜像后
composer update卡住，日志显示Failed to decode response body - Nginx 日志里大量
403或302，但客户端无明确提示，只表现为超时 - 镜像站首页能打开（HTML），但
/packages.json返回 200 HTML 而非 JSON → Composer 解析失败
Nginx 层拦截可疑请求的真实可行方案
必须区分「真实 Composer 请求」和「模拟 Composer 的恶意爬虫」——前者有固定 User-Agent 和 Accept 头，后者常伪造 UA 或缺失关键头字段。
实操建议：
- 用
map提取并标记合法 Composer 请求：map $http_user_agent $is_composer {<br> ~*composer/([0-9.]+) 1;<br> default 0;<br>} - 校验
Accept头是否为application/json（Composer 2.5+ 默认发送）：if ($http_accept !~ "application/json") { return 403; } - 对非
$is_composer请求启用限流 + 动态挑战：limit_req zone=antibot burst=3 nodelay;<br>if ($is_composer = 0) { rewrite ^(.*)$ /captcha?r=$scheme://$host$request_uri redirect; } - 注意：/captcha 路径必须放行，且不能返回任何 JSON 响应；它只用于人机验证，不参与 Composer 流程
如何避免误杀正常 CI/CD 流量
CI 环境（GitHub Actions、GitLab Runner）通常用固定 IP 池或企业代理出口，UA 可能被统一改写，容易被当成爬虫。
关键判断点：
- 检查是否携带
X-CI-Build或X-GitHub-Runner这类自定义头（可由 CI 配置注入） - 允许特定 CIDR 段直通：
geo $is_trusted_ip {<br> 192.168.0.0/16 1;<br> 2001:db8::/32 1;<br> default 0;<br>}
再配合if ($is_trusted_ip = 1) { set $is_composer 1; } - 不要依赖 Referer：Composer 请求默认不带 Referer，空 Referer 是正常行为
- 避免用请求频率作为唯一判据：Composer 并发下载时可能在 1 秒内发出 10+ 个
/p2/xxx.json请求，这是合法行为
真正起效的爬虫特征识别点
不是看 UA 字符串是否含 “bot”，而是看请求链路是否违反 Composer 协议逻辑：
- 高频请求
/packages.json但不跟进/p2/→ 典型元数据扫描行为 - 请求
/p2/{vendor}/{package}.json但{vendor}是随机字符串（如a1b2c3、test123）→ 暴力探测 - 同一 IP 在 5 分钟内请求超过 200 个不同
/p2/路径 → 不符合真实项目依赖图谱 - 请求头缺失
Accept: application/json或含text/html→ 明显非 Composer 客户端
这些规则必须在 Nginx log_format 中记录 $request_uri 和 $http_accept，再通过 ELK 或脚本离线分析，才能持续调优阈值。硬编码进配置的静态规则很快会被绕过。
