RabbitMQ原生不支持按IP限制连接数，因其连接准入逻辑在TCP accept后、AMQP握手前，尚未解析源IP，且无connection_per_ip等内置配置；需通过HAProxy、iptables或SDK层等外围方案实现。
直接结论：RabbitMQ 原生不支持按 IP 限制连接数
RabbitMQ 没有内置的 connection_per_ip、max_connections_per_ip 或类似配置项。所有官方文档、源码和插件（截至 2026 年）均未提供基于客户端源 IP 的连接数硬限功能。试图在 rabbitmq.conf 中添加这类参数将被忽略，且不会报错。
为什么不能直接配 IP 限连？
根本原因在于 RabbitMQ 的连接准入逻辑发生在 TCP accept 阶段之后、AMQP 协议握手之前——此时只拿到 socket 句柄，尚未解析出对端 IP（Erlang 的 gen_tcp:accept/1 不暴露远端地址给上层控制逻辑）。而连接数限制（connection_max）是全局计数器，在协议层做判断，无法拆分到 IP 维度。
常见误解来源：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 误把
num_acceptors.tcp当作 per-IP 控制（它只是并发 accept 进程数，与 IP 无关） - 混淆了
max_connections（全局）和用户级权限（如default_user_limit，仅限于 vhost 内用户连接上限，仍不绑定 IP） - 看到某些第三方插件宣传“IP 限连”，实为代理层（如 HAProxy、nginx）或客户端 SDK 的模拟策略，非 RabbitMQ 本体能力
可行的替代方案（必须组合使用）
若业务强依赖 IP 级连接控制，只能在外围拦截，RabbitMQ 本身只承担最终连接接纳：
-
用反向代理前置限流：在 RabbitMQ 前部署
HAProxy或nginx，启用stick-table或limit_conn，例如 HAProxy 中：stick-table type ip size 1m expire 30m store conn_curhttp-request deny if { conn_cur ge 50 }（限制单 IP 当前连接 ≤50） -
系统级 netfilter 限速：用
iptables+hashlimit模块临时压制异常建连频次（非精确连接数，但可防扫描/重试风暴）：iptables -A INPUT -p tcp --dport 5672 -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name rabbit_conn -j DROP -
客户端 SDK 层自我约束：强制所有服务端应用使用统一连接池（如 Spring AMQP 的
ConnectionFactory.setChannelCacheSize()+setConnectionCacheSize()），并在初始化时校验本机出口 IP 是否已超限（需配合中心化限流服务）
容易被忽略的关键点
即使你通过代理做了 IP 限连，RabbitMQ 自身的 connection_max 仍必须留足余量——因为每个代理连接会复用一个后端 RabbitMQ 连接（即“1 个代理连接 ↔ 1 个 RabbitMQ 连接”），而代理本身可能开多个连接来负载均衡。如果设 connection_max=1000，又放行了 20 个 IP 各 50 连，代理实际可能建立 1000 连接打满上限，导致新 IP 被静默拒绝（无日志、无错误响应，客户端卡在 AMQP handshake）。务必监控 rabbitmqctl status 中的 {sockets_used, N} 和 {sockets_limit, M} 实时比值。
