HAProxy平滑重启的核心是新旧进程共存、自然交接：旧进程处理已有连接，新进程绑定相同端口（依赖SO_REUSEPORT）接管新连接，通过-sf选项发送SIGUSR1信号触发，确保服务零中断。
HAProxy 平滑重启的核心，是让新配置生效的同时，不中断任何已建立的连接。它不是“停旧启新”，而是“新旧共存、自然交接”——旧进程继续服务老连接，新进程接管新连接，直到旧连接全部自然结束。
HAProxy 平滑重启的触发方式
-
推荐命令（通用可靠）
sudo haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
-sf表示 soft stop，即向旧主进程发送SIGUSR1信号，让它解除监听套接字、但继续处理已有连接；新进程启动后立即绑定相同端口（依赖SO_REUSEPORT），开始接受新连接。 -
systemd 环境下（HAProxy ≥2.0）
CPA Update - Secure CLI Proxy API Maintenance下载安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
sudo systemctl reload haproxy
此命令默认调用内置 graceful reload 逻辑，前提是 service 文件中
ExecReload=正确指向haproxy -f ... -sf ...或等效封装。可检查：systemctl cat haproxy | grep ExecReload
-
通过 stats socket（需提前启用）
若配置中启用了 admin socket（如stats socket /run/haproxy/admin.sock mode 600 level admin），可用：echo "reload" | sudo socat stdio unix:/run/haproxy/admin.sock
这种方式更安全，避免直接操作 PID 文件，适合自动化运维场景。
关键前提与注意事项
必须启用
SO_REUSEPORT（Linux 内核 ≥3.9）
HAProxy 默认启用该选项，确保新旧进程能同时监听同一端口。若内核太旧或被禁用，reload 可能失败并报Address already in use。配置语法必须正确
reload 前会校验新配置。若语法错误，新进程启动失败，旧进程继续运行，但不会自动回退提示——需人工检查日志（journalctl -u haproxy -n 50 --no-pager）。资源预留要充足
reload 期间新旧进程并存，内存、文件描述符用量临时翻倍。建议监控ps aux | grep haproxy和lsof -p <pid> | wc -l，避免因资源不足导致新进程无法启动。-
连接真正“不丢”的边界
- ✅ 已建立的 TCP 连接（含 TLS 握手中的、正在传输的、Keep-Alive 长连接）由旧进程完成
- ✅ 新建连接（含新 TLS 握手）由新进程处理，使用新配置（如新证书、新 backend 权重）
- ❌ 若 reload 过程中发生极端资源争抢（如 backlog 队列溢出），极少数新连接可能被内核丢弃（概率极低，高负载下需压测验证）
验证是否真正平滑成功
- 检查进程：
ps aux | grep haproxy应显示至少两个主进程（PID 不同） - 查看连接归属：
ss -tulnp | grep :80应看到多个 PID 绑定同一端口 - 抓包验证：对一个长连接持续 curl，reload 后仍能收到响应，且无 TCP RST
- 日志比对：新连接的日志应体现新配置行为（如新 backend 的
backend_name字段变化）
不复杂但容易忽略。
