Nginx 中 limit_req_status 仅设状态码（如429），不能定义响应体；需配合 error_page 拦截429并用 return 返回自定义JSON，同时显式设置 Content-Type 和合法JSON格式。
在 Nginx 中，limit_req_status 本身只支持设置 HTTP 状态码（如 429），**不能直接定义响应体内容或格式**。要实现“触发限流时返回自定义 JSON 错误响应”，需结合 error_page + return（或 echo 指令）来完成。
1. 正确理解 limit_req_status 的作用
limit_req_status 仅用于指定限流被拒绝时返回的 HTTP 状态码，默认是 503，常用设为 429（Too Many Requests）。它不控制响应体、Content-Type 或 JSON 结构。
- ✅ 正确用法：
limit_req_status 429; - ❌ 错误期待：不能通过它直接输出
{"error":"rate limited"}
2. 使用 error_page 拦截 429 并返回 JSON
在 http、server 或 location 块中，将 429 映射到一个内部 location，并用 return 返回 JSON 响应：
limit_req_status 429;
error_page 429 = @rate_limited;
location @rate_limited {
internal;
add_header Content-Type "application/json; charset=utf-8";
return 429 '{"code":429,"message":"Request rate limit exceeded","retry_after":60}';
}
注意：return 后的 JSON 字符串需用单引号包裹，双引号必须转义（或统一用单引号内嵌双引号）；若 JSON 复杂，建议改用 echo 模块或后端处理。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
3. 确保响应头和编码正确
仅靠 return 不会自动设置 Content-Type 和 Content-Length，需显式添加：
- 用
add_header Content-Type "application/json; charset=utf-8";告知客户端格式 - Nginx 1.13.10+ 会自动计算
Content-Length；旧版本建议升级或用echo模块更可控 - 避免在
return响应中混入 HTML 实体或非法 UTF-8 字节，否则 JSON 解析失败
4. 验证与调试技巧
配置完成后，用 curl 测试是否生效：
curl -I http://your-domain/api/test
观察响应头是否含 Content-Type: application/json，状态码是否为 429，响应体是否为预期 JSON。常见问题：
- 返回空白或默认 Nginx 429 页面 → 检查
error_page是否写在limit_req_status同一作用域，且未被其他error_page覆盖 - JSON 格式错误 → 检查引号嵌套、逗号结尾、中文是否 UTF-8 编码
- 响应头未生效 → 确认
add_header在@rate_limitedlocation 内，且未被子请求覆盖
