nginx通过limit_req模块实现请求级排队，基于漏桶原理（常被误称为令牌桶），配合burst和默认无nodelay参数使超限请求进入队列等待，而非立即拒绝。
proxy_pass 本身不直接实现连接排队，它只是把请求转发给后端。真正控制排队行为的是 Nginx 的连接接入与请求处理机制，以及配套的限流、缓冲和超时策略。
用 limit_req 实现请求级排队
这是最常用、最可控的排队方式，基于令牌桶算法，在请求进入 upstream 前就做节流与排队：
- 定义共享内存区存储计数器：limit_req_zone $binary_remote_addr zone=api_queue:10m rate=200r/s;
- 在 location 中启用排队（允许积压，不立即拒绝）：limit_req zone=api_queue burst=500 nodelay=0;
- burst=500 表示最多缓存 500 个等待请求；nodelay=0（即默认行为）表示超出速率的请求会进入队列，而非直接 503
- 配合 limit_req_status 429; 统一返回状态码，便于前端识别限流
靠 listen backlog 和内核参数保障“接得进”
排队的前提是连接能先建立起来。大量 SYN 或 ESTABLISHED 连接卡在 TCP 层，会导致客户端重试、丢包，看似“排不上队”，实则是连门都进不来：
WeChat macOS Proxy
下载
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
- 调高系统内核参数：net.core.somaxconn = 65535、net.ipv4.tcp_max_syn_backlog = 65535
- Nginx listen 必须显式声明：listen 80 backlog=65535;（不写则默认仅 511）
- 确保 worker_rlimit_nofile 1048576; 且系统 ulimit -n ≥ 同值，避免文件描述符耗尽
通过 proxy_timeout 和 keepalive 防止后端拖垮排队队列
如果后端响应慢或挂死，Nginx worker 会被长期占用，导致新请求无法入队或超时失败：
- 设置合理超时，让连接“快进快出”：proxy_connect_timeout 3s;、proxy_read_timeout 8s;（略小于后端 keepalive timeout）
- 启用 upstream 连接复用：keepalive 200; + proxy_http_version 1.1; + proxy_set_header Connection "";
- 限制单个连接最大请求数：keepalive_requests 1000;，防长连接泄漏
结合 error_page 和 proxy_cache 提供柔性排队体验
当后端不可用或超时，可降级为缓存响应或排队提示页，避免用户看到空白或错误：
- 配置陈旧缓存兜底：proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
- 自定义排队中页面：error_page 503 /queue.html;，并用 location = /queue.html { internal; root /usr/share/nginx/html; }
- 对 /queue.html 本身也加轻量限流，防止排队页被刷爆
