基于Redis原子操作的Composer镜像限流与防刷实战-composer-PHP中文网

composer客户端本身不支持限流防刷，因其无服务进程、不连redis、无法执行原子命令；限流必须由镜像服务端（如nginx+lua或openresty）基于redis实现滑动窗口或令牌桶，并结合请求路径、状态码和行为特征精准识别攻击。

基于redis原子操作的composer镜像限流与防刷实战

Composer 镜像本身不支持限流或防刷，所谓“基于 Redis 原子操作的 Composer 镜像限流”是概念混淆 —— 限流防刷只能落在镜像服务端（如 Nginx、OpenResty 或自研代理层），而非 Composer 客户端。

为什么不能在 Composer 客户端用 Redis 做限流

Composer 是纯客户端工具，运行时无服务进程、不监听端口、不维护状态。它既不连接 Redis，也无法执行 SETNX 或 INCR 这类原子命令。所有“限流”“防刷”逻辑必须由镜像服务提供方在 HTTP 层实现。

Composer 执行 composer install 时，只发起大量 GET 请求（如 /packages.json、/p2/vendor/package/1.0.0.json）
这些请求最终落到镜像服务器（如 Nginx + Lua 或 Go 编写的反向代理）
只有服务端才能读写 Redis、判断 IP/Token 限流、返回 429

镜像服务端如何用 Redis 实现原子限流

以 OpenResty + Redis 为例，核心是用 Lua 脚本封装令牌桶或滑动窗口逻辑，确保 GET 请求计数与过期时间设置原子执行。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

Key 设计建议：rate:ip:{client_ip}:composer 或 rate:token:{auth_token}:composer
避免用固定窗口：用滑动窗口（ZSET）或令牌桶（Lua + EXPIRE）更抗突发
必须设置 EXPIRE，否则 Redis 内存持续增长；推荐 TTL 与窗口周期一致（如 60 秒窗口 → EXPIRE key 60）
示例 Lua 脚本片段（用于 OpenResty 的 access_by_lua_block）：

local redis = require "resty.redis"
local red = redis:new()
red:set_timeout(100)
red:connect("127.0.0.1", 6379)
local key = "rate:ip:" .. ngx.var.remote_addr .. ":composer"
local limit = 100
local window = 60
local current = red:incr(key)
if current == 1 then
  red:expire(key, window)
end
if current > limit then
  ngx.exit(429)
end