镜像站用lua做静态请求过滤，是因为p2/、packages.json等路径背后是动态元数据生成逻辑，大量无效请求（如拼错包名、旧hash、不存在provider）会直击后端，而lua在nginx层直接拦截404/302/403/429，不转发、不记录、不计费，省去php-fpm或node.js解析开销。
为什么镜像站要用Lua做静态请求过滤
镜像站不是单纯把 packagist.org 的文件拷一份就完事——p2/、packages.json 这些路径背后是动态元数据生成逻辑，但大量无效请求（比如拼错的包名、旧版 hash、不存在的 provider 文件）会直接打到后端服务。Lua 层在这里干的是“守门人”活：不转发、不记录、不计费，直接 404 或 302 重定向到上游，省掉 PHP-FPM 或 Node.js 后端的解析开销。
哪些请求会被Lua缓存层拦截
阿里云、中科大等主流镜像站的 Lua 规则基本覆盖这几类：
-
/p2/xxx/yyy/1.2.3.json中 yyy 不在已同步 provider 列表里 → 直接404 -
/packages.json被高频 GET，但内容 5 分钟内不变 →Cache-Control: public, max-age=300强制 CDN 缓存 -
/dist/xxx/xxx.zip请求带非法User-Agent（如空值、含curl/7.29.0且无Accept头）→403 -
/composer/根路径被爬虫反复刷robots.txt或.git→ Lua 限速并返回429
开发者能感知到Lua层的存在吗
绝大多数情况不能，也不该感知——它对正确请求完全透明。但以下现象说明你撞上了 Lua 过滤逻辑：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行
composer install时某几个包突然404，但用curl -I https://mirrors.aliyun.com/composer/p2/vendor/package/1.0.0.json确认地址存在 → 很可能是 provider 同步延迟，Lua 拦截了未入库的请求 - 连续跑两次
composer update，第二次快得多，且日志里没出现Downloading行 → 说明packages.json已被 CDN 缓存，根本没发请求到镜像后端 - CI 构建中偶发
Could not find package xxx，但本地重试又正常 → 可能是 Lua 限流触发，尤其当并发数设为parallel-downloads=20时
调试时绕过Lua层的方法
真要验证是否是 Lua 拦截导致问题，别改 Composer 配置，直接测镜像站 HTTP 接口：
- 加
-H "X-Forwarded-For: 127.0.0.1"绕过部分 IP 限速（仅测试环境有效） - 用
curl -v https://mirrors.ustc.edu.cn/composer/p2/monolog/monolog/2.10.0.json 2>&1 | grep "HTTP/"看真实响应码 - 对比官方源：
curl -I https://packagist.org/p2/monolog/monolog/2.10.0.json和镜像源响应头差异，重点看X-Cache和X-Backend
Lua 层本身不参与 Composer 版本解析或依赖求解，它只管“有没有、要不要、让不让”。真正卡在 Loading composer repositories 时，先确认是不是自己漏写了 repo.packagist 的 type 字段——那跟 Lua 没半点关系。
