17370845950

小程序请求不带 Referer，需用微信签名机制（sign/timestamp/nonce）校验+Redis 按 openid 限流+idempotency_key 幂等+ Nginx 兜底防护，且时间单位须统一。

为什么直接用 $_SERVER['HTTP_REFERER'] 拦不住小程序请求

小程序发起的 wx.request 请求默认不带 Referer，服务端读到的 $_SERVER['HTTP_REFERER'] 是空或不可信值。靠它做来源校验等于没设防。

真正有效的识别依据是微信签名机制——每次请求都应携带 sign、timestamp、nonce，且服务端需用约定密钥重算签名比对。

• 前端调用前必须用 md5(timestamp + nonce + secret) 生成 sign
• 后端收到后先校验 timestamp 是否在 5 分钟有效窗口内（防重放）
• 再用相同逻辑重算 sign，严格区分大小写和拼接顺序
• 验证通过才进入后续逻辑，否则统一返回 401 Unauthorized

用 Redis 实现用户级 QPS 限流（非 IP 级）

小程序用户登录态是 openid，不是 IP。按 IP 限流会误伤同一 WiFi 下多个用户；按 openid 限流才合理。

推荐使用 Redis 的 INCR + EXPIRE 原子组合，避免竞态条件：

// 示例：每分钟最多 30 次接口调用
$openid = $this->getOpenidFromToken(); // 从 Authorization header 或 POST 中提取
$key = "rate_limit:{$openid}:api_v1_submit";
$redis->incr($key);
$redis->expire($key, 60);

if ($redis->get($key) > 30) {
    throw new Exception('Request limit exceeded', 429);
}

• 务必用 $redis->expire() 而非 SET key val EX 60，因 INCR 可能创建 key 导致过期失效
• 若用 phpredis 扩展，确保版本 ≥ 5.3.0，老版本 expire() 对不存在 key 返回 false 易漏判
• 不要在限流前查 GET 再 INCR，这会产生竞态，必须依赖原子操作

接口幂等性必须由客户端传 idempotency_key

防止恶意脚本反复提交（比如抽奖、下单），光靠频率限制不够，得靠业务层幂等控制。

要求小程序在请求头或参数中带上唯一 idempotency_key（如 UUID v4），服务端用它作为 Redis 键存处理状态：

• 收到请求先 SETNX idempotency_key:xxx processing 300（5 分钟过期）
• 若设置成功，执行业务逻辑并最终写入结果到 idempotency_key:xxx:result
• 若设置失败，直接返回缓存的结果（或查 DB 确认是否已成功）
• 注意：不能只依赖数据库唯一索引，因为网络超时后客户端可能重试，而 DB 插入可能已成功但响应未达

别忽略 Nginx 层的基础防护兜底

PHP 层限流失效时（比如 FPM 崩溃、代码绕过），Nginx 的 limit_req 是最后一道防线。

配置示例（按 $http_x_wx_openid 限流，需小程序主动透传）：

map $http_x_wx_openid $openid_key {
    default $http_x_wx_openid;
}
limit_req_zone $openid_key zone=api_per_user:10m rate=30r/m;

location /api/ {
    limit_req zone=api_per_user burst=5 nodelay;
    fastcgi_pass php-fpm;
}

• 必须用 map 提取 header，不能直接用 $http_x_wx_openid 做 zone key，否则空值会打满一个桶
• burst=5 允许短时突发，但 nodelay 表示不延迟排队，超了直接 503，避免请求堆积拖垮 PHP
• 这个配置无法替代 PHP 层签名和幂等校验，只是防流量冲击的辅助手段

最易被忽略的是时间窗口一致性：Redis 过期时间、签名 timestamp 容差、Nginx limit_req 的 rate 单位，三者必须统一用秒或分钟，混用会导致限流形同虚设。