结论：用包管理器安装HAProxy最快最稳，90%生产环境应优先选apt install haproxy或dnf install haproxy；源码编译仅适用于需特定版本、定制编译选项或内核级补丁等少数场景，否则易引发systemd配置、SELinux、日志、升级及配置校验等问题。
直接说结论：用包管理器装 haproxy 是最快最稳的方式，90% 的生产环境都该从 apt install haproxy 或 dnf install haproxy 开始，别一上来就编译源码。
为什么不用源码编译安装？
除非你明确需要某个特定版本（比如 2.9+ 的 HTTP/3 支持）、或必须启用 USE_OPENSSL=1 + USE_PCRE=1 组合、或要 patch 内核级选项，否则源码编译纯属给自己加戏。它带来的问题远多于收益：
- systemd unit 文件得自己写，
systemctl enable haproxy直接报错 -
haproxy -f /etc/haproxy/haproxy.cfg启动时可能因 SELinux 上下文缺失被拒（尤其 CentOS/RHEL） - 日志默认不走
rsyslog，得手动配log 127.0.0.1 local2和/etc/rsyslog.d/49-haproxy.conf - 升级时得重编译、重链接、重配用户权限，而包管理器一条
apt upgrade就搞定
haproxy -c -f /etc/haproxy/haproxy.cfg 报错怎么办？
这是配置阶段最常卡住的地方。错误本身不重要，关键看报哪一行——但 80% 是以下三类：
-
invalid number 'timeout'：在defaults段写了timeout http-request却没配mode http；TCP 模式下只能用timeout connect/timeout server -
cannot bind socket：端口被占（ss -tlnp | grep :80），或非 root 用户尝试绑定:80；检查user和group是否设为nobody或自建的haproxy用户 -
unknown keyword 'stats'：HAProxy 版本太老（listen 块里，新版可直写在frontend下
验证命令永远是：haproxy -c -f /etc/haproxy/haproxy.cfg，别跳过这步直接 systemctl start。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
后端服务器健康检查总显示 DOWN？
不是网络不通，大概率是健康检查发的是 HTTP 请求，但后端没返回 2xx/3xx。常见坑：
-
option httpchk GET /health要求后端必须有/health路径且返回 200，否则直接标红；换成option httpchk（默认 GET /）更稳妥 - 后端开了防火墙但没放行 HAProxy 机器的 IP，
curl -I http://172.16.122.104:10900在 HAProxy 本机跑通才算数 - 用了
http-check expect status 200却忘了加option httpchk，expect 不生效 - 后端是 HTTPS 服务，但 HAProxy 配了
check ssl verify none却没开ssl关键字（应写成server s1 172.16.122.104:443 check ssl verify none）
Web 统计页面打不开或 403？
统计页默认不暴露，必须显式配置。最容易漏的是认证和监听范围：
- 只加了
stats uri /stats，没加stats auth admin:password→ 返回 401 - 写了
bind *:80却没在frontend下追加 stats 块，而是扔在global段 → 完全不生效 - 用
bind 127.0.0.1:80启动，结果从外网访问http://ip/stats→ 连不上，得改成bind *:80或加bind 0.0.0.0:80 - SELinux 启用时，即使端口通，也可能拦截 stats 请求，临时测可用
setsebool -P haproxy_connect_any on
真正上线前，务必确认 stats enable、stats uri、stats auth 三者都在同一个 frontend 或 listen 块里，缺一不可。
