Composer镜像请求被WAF拦截主因是默认User-Agent或/p//等路径被识别为扫描行为，表现为403错误但curl可通；验证需查响应头X-Powered-By-WAF字段或WAF日志rule_id（如910100），绕过方式包括覆盖UA、禁用并行下载、添加Referer及确保URL以/结尾。
为什么 Composer 镜像请求会被 WAF 拦截？
不是镜像地址本身有问题，而是 WAF 把 Composer/2.x 的默认 User-Agent 或特定请求路径（如 /packages.json、/p/<package>/</package>）识别为扫描行为或恶意探针——尤其当 WAF 启用了“爬虫识别”“高频请求拦截”或“UA 黑名单”规则时。常见表现是 composer install 卡在某个包、返回 403，但手动 curl -v 同 URL 却能通（说明网络和镜像本身正常）。
如何验证是否是 WAF 在拦截？
直接看响应头和返回体：
- 执行
curl -v https://mirrors.aliyun.com/composer/packages.json 2>&1 | grep "X-Powered-By\|X-Firewall\|Server:，若出现X-Powered-By-WAF或类似字段，基本锁定 - 用浏览器或
curl -i访问镜像根 URL，返回页含 “Request blocked”、“Security rule matched” 等字样，就是 WAF 干的 - 检查 WAF 日志（如
/var/log/phpwaf/block.log或雷池/Azure WAF 控制台日志），找匹配rule_id为910100（爬虫 UA）、933150（高频目录遍历）或942100（SQL 关键字误判）的条目
绕过 WAF 拦截的实操配置
不改 WAF 规则也能让 Composer 正常工作，关键是让请求“看起来更像人”：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 强制覆盖 UA：在项目根目录创建
composer.json，加字段"config": {"http-basic": {}, "platform": {}, "extra": {},"user-agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36"}—— Composer 2.2+ 支持该字段，会覆盖默认 UA - 禁用并行下载（降低请求密度）：运行
composer config -g parallel.downloads 1，避免触发“高频请求”规则 - 换镜像源 + 手动指定 Referer：部分 WAF（如 PHPWAF）会校验
Referer，可临时加全局配置：composer config -g http.extra-options "--header 'Referer: https://mirrors.aliyun.com/composer/'" - 若用私有源，确保
"repositories"中每个源的url以/结尾且协议为https，否则 Composer 可能拼出非法路径（如/composerpackages.json）被 WAF 当作路径遍历拦截
哪些 WAF 场景下镜像配置本身会失效？
镜像地址写得再对，也救不了这几类情况：
- 公司级透明代理重写了
User-Agent或剥离了Accept头，导致 Composer 请求被识别为“无头客户端” - WAF 开启了“仅允许白名单域名反向代理”，而你配的镜像域名（如
mirrors.tuna.tsinghua.edu.cn）不在白名单里 - CI 环境（如 GitHub Actions）中，runner IP 被 WAF 封禁，此时换镜像没用，必须联系运维加 IP 白名单
-
auth.json权限为644，WAF 日志模块读取该文件失败并触发安全告警，间接导致后续所有请求被限流
真正卡住的往往不是镜像地址，而是请求特征与 WAF 规则之间的隐性冲突——调参比换源更关键，而日志里的 rule_id 比报错信息更值得细读。
