【HAProxy 数据面】Frontend / bind / accept：监听、FD 与接入路径
内容提要
本文介绍HAProxy前端接入机制：bind创建监听FD，accept后连接由工作线程持有；SO_REUSEPORT和cpu-map影响连接分配与CPU局部性；expose-fd是平滑重载取回监听套接字的前提；内容切换在stream规则层执行。接入失败需区分bind、maxconn、reload窗口等问题，而非直接归因于backend或ACL。
延伸解读
接入失败排查：先看入口，再看上游
文章强调，大量“连不上”或“偶发 RST”问题其实出在监听与 FD 交接窗口，而非 backend。排查时应先确认是哪条 bind 在听、SSL 是否在 bind 上终结，再检查 maxconn、backlog、reload 窗口等入口限制。若入口已满，表现是拒绝或延迟新连接，而不是 backend 502。将“入口满”与“上游满”分开，是高效排障的关键。
SO_REUSEPORT 与 cpu-map：多线程接入的部署旋钮
SO_REUSEPORT 允许新进程在旧进程仍监听时绑定同一地址，缩小 reload 窗口；cpu-map 可将特定监听流量收束到部分线程或 CPU 集合，用于 SSL 重 frontend 与轻量任务分流。但两者只影响“谁接到连接”与 CPU 局部性，不改变“连接不迁移”的模型。配错时可能出现某几核打满、其余空闲，应检查 cpuset 配置，而非怀疑 mux。
expose-fd listeners：无缝重载的前置条件
无缝重载（seamless reload）依赖新进程从旧进程取回 listening FD，经典双进程模式下需在 stats socket 上启用 expose-fd listeners，并用 -x 指定 socket；master-worker 模式则由 master 自动协调。若未满足这些条件，重载可能退化为“靠 SO_REUSEPORT 硬绑”或“先停听再绑”的更大窗口路径。检查顺序：先确认模式，再确认旧进程能否交出 FD，最后看新进程是否带 -x 启动。
内容切换在流规则层，接入层先固定
Content switching 发生在 stream 已建立、HTTP 规则引擎可见方法/路径/首部之后，而非 bind 阶段。因此，TCP 连不上时应查 bind/maxconn/防火墙，连上后协议错乱应查模式与 SSL，进错池才查 ACL。与 Envoy 的 Listener/FilterChainMatch 相比，HAProxy 的 bind 更静态地决定 SSL/HTTP，更细的切换推到 stream 规则。先固定接入层，再查路由层，是避免误判的关键。
Q&A
HAProxy中frontend和bind分别负责什么？
frontend是面向客户端的代理入口，负责模式（tcp/http）、超时、ACL/规则挂载和默认backend；bind在frontend（或listen）上声明监听地址/端口/协议选项，真正创建监听FD。
HAProxy中accept之后连接由谁持有？
accept之后连接由接受该连接的工作线程持有，并且通常该线程会服务该连接终生。
SO_REUSEPORT在HAProxy中有什么作用？
SO_REUSEPORT允许新进程在旧进程仍监听时绑定同一地址，缩小reload时无人监听的窗口；在多线程下影响哪条线程先拿到连接，但不改变连接不迁移的特性。
cpu-map在HAProxy中如何影响连接分配？
cpu-map用于将特定监听流量收束到部分线程或CPU集合，影响连接的CPU局部性，典型用途包括SSL重的frontend与轻量健康检查分流，或与网卡多队列中断对齐。
expose-fd listeners在HAProxy中有什么作用？
expose-fd listeners是平滑重载（seamless reload）取回监听套接字的前提，在经典双进程reload中，新进程通过stats socket和-x选项从旧进程取回监听FD，避免监听空洞。
HAProxy中content switching在哪个阶段执行？
Content switching在stream规则层执行，即stream已存在后，通过ACL/规则求值选择backend，而不是在accept阶段。
HAProxy中接入失败可能的原因有哪些？
接入失败需区分bind、maxconn、reload窗口等问题，而不是直接归因于backend或ACL。例如TCP连不上可能涉及bind、maxconn、防火墙或reload窗口；连上后协议错乱可能涉及模式、SSL、mux选择。
