proxy_connect_timeout与limit_conn协同防护：前者限制TCP建连超时（如3s），防慢握手；后者限制单IP并发连接数（如20），防连接耗尽；二者分别管控“连得上”和“连多少”，形成入口限流+建连兜底双保险。
proxy_connect_timeout 和 limit_conn 是两类不同维度的防护机制：前者控制“建连快不快”，后者限制“连得多不多”。配合使用，能有效抵御针对代理层的慢连接类攻击（如 Slowloris、RUDY 等），既防住恶意长时握手占用连接资源，又避免健康请求被拖垮。
明确分工：一个管“连得上”，一个管“连多少”
proxy_connect_timeout 仅作用于 TCP 三次握手阶段——Nginx 发出 SYN 后，等待后端返回 SYN-ACK 的最长时间。超时即断开，不消耗后续资源。
limit_conn 则在 Nginx 接收客户端连接时就生效，基于 key（如 $binary_remote_addr）限制并发连接数，防止单个 IP 占满 worker 连接池。
两者叠加，形成“入口限流 + 建连兜底”双保险：
- limit_conn 先拦住大量并发建连请求，避免工作进程被耗尽
- proxy_connect_timeout 再确保每个漏过的建连请求不会无限期挂起（比如后端故意不回 SYN-ACK）
- 二者共同压缩攻击者可利用的连接窗口和时间窗口
关键配置要点与协同逻辑
必须避免参数错位或冲突，才能真正起效：
- limit_conn_zone 必须定义在 http 块顶层，例如：
limit_conn_zone $binary_remote_addr zone=perip:10m; - limit_conn 应放在 server 或 location 块中，且建议优先置于 proxy_pass 之前（在连接建立阶段拦截）
- proxy_connect_timeout 必须出现在含 proxy_pass 的 location 或 server 块内，不能写在 upstream 或 http 全局块里（否则不生效）
- 若后端是域名，DNS 解析由 resolver 控制，与 proxy_connect_timeout 无关；但 DNS 超时也需设合理值（如 resolver_timeout 3s），否则会掩盖真实建连问题
推荐数值组合（以典型 Web 代理场景为例）
数值需根据实际网络质量与业务敏感度调整，不可照搬：
- 内网同 VPC 场景：
→ limit_conn perip 20（单 IP 最多 20 并发连接）
→ proxy_connect_timeout 3s（95% 健康节点建连 ≤800ms，设 3s 预留抖动） - 混合云或跨可用区：
→ limit_conn perip 10（降低单 IP 影响面）
→ proxy_connect_timeout 8s（容忍更高网络延迟，但绝不超 15s） - 高安全要求接口（如登录、支付回调）：
→ 可叠加 limit_req（如 5r/s）进一步控频
→ proxy_connect_timeout 设为 2s，并启用 proxy_next_upstream error timeout 实现快速故障转移
验证是否真正协同生效
配置完别只看 reload 成功，要实测行为：
- 用 ab 或 wrk 模拟 50+ 并发连接请求，观察 Nginx error_log 中是否出现大量 “limiting connections by zone” 日志（说明 limit_conn 生效）
- 停掉一个后端服务，再发起单连接请求，curl -v 查看响应延迟是否接近你设的 proxy_connect_timeout 值（如设 3s，应约 3.1–3.3s 返回 502）
- 同时开启 debug 日志（error_log ... debug），搜索 “connect() failed” 和 “client closed keepalive connection” —— 若大量连接在 connect 阶段超时后立即释放，说明两个机制都在正常兜底
