rabbitmq 通过防火墙后，生产者connection by peer

　　如果网络连接通过防火墙，而防火墙一般都会有超时的机制，在网络连接长时间不传输数据时，会关闭这个TCP的会话，关闭后在读写，就会导致异常。 如果关闭防火墙，解决了问题，需要重新配置防火墙，或者自己编写程序实现TCP的长连接。实现TCP的长连接，需要自己定义心跳协议，每隔一段时间，发送一次心跳协议，双方维持连接。

 

要解决 RabbitMQ 经防火墙后出现的 connection reset by peer 异常（根源是防火墙空闲 TCP 连接超时切断），核心思路是避免连接被防火墙判定为 “空闲”。无需完全自定义 TCP 心跳协议（RabbitMQ 已内置 AMQP 心跳机制），优先通过防火墙配置优化或启用 RabbitMQ 原生心跳即可高效解决，以下是详细方案：

一、问题根源再明确

防火墙为避免资源浪费，会对长时间无数据传输的 TCP 会话触发 “空闲超时”（不同厂商防火墙默认超时不同，如华为、Cisco 多为 30 分钟～1 小时）。当 RabbitMQ 生产者 / 消费者连接长时间无业务消息（如夜间低峰期），防火墙会主动切断该 TCP 连接；后续客户端再尝试读写时，就会因连接已被销毁而报 connection reset by peer 错误。

二、解决方案一：防火墙侧配置优化（推荐优先尝试）

若有权限调整防火墙策略，直接针对 RabbitMQ 连接优化超时规则，无需修改代码，是最彻底的方案。核心是延长 RabbitMQ 端口的 TCP 空闲超时时间，或为该端口配置 “会话保持”。

1. 关键配置方向

配置项	说明
目标端口	明确 RabbitMQ 服务端口（默认：非加密 5672，TLS 加密 5671）
TCP 空闲超时时间	将该端口的超时时间调整为 大于业务低峰期的最大空闲时长（如设为 24 小时）
会话保持（Session Keepalive）	部分防火墙支持 “主动探测”（如发送 TCP 空包），维持连接活跃，可直接启用

2. 主流防火墙配置示例（参考）

• 华为防火墙（USG 系列）：
  通过命令行延长指定端口的超时时间（以 5672 端口为例）：
  bash

   

   

  # 进入系统视图
  system-view
  # 创建 ACL 规则，匹配 RabbitMQ 端口
  acl number 3000
  rule permit tcp destination-port eq 5672
  # 配置会话超时策略（设为 86400 秒 = 24 小时）
  firewall session-timeout tcp 3000 86400
  

   
• Cisco 防火墙（ASA 系列）：
  调整 TCP 空闲超时（默认 1 小时，改为 24 小时）：
  bash

   

   

  # 全局配置模式
  configure terminal
  # 针对 5672 端口设置超时
  timeout tcp 0 24 0 0 destination eq 5672
  # 保存配置
  write memory
  

   

3. 注意事项

• 避免盲目调大所有端口的超时时间，仅针对 RabbitMQ 端口配置，减少安全风险；
• 若防火墙无 “端口级超时” 配置，可按 “源 IP / 目标 IP”（RabbitMQ 服务器 IP + 生产者 IP 段）精准匹配，缩小影响范围。

三、解决方案二：启用 RabbitMQ 原生 AMQP 心跳（代码侧配置）

若无法调整防火墙（如跨部门管理、公网防火墙），则通过 RabbitMQ 内置的 AMQP 心跳机制 主动维持连接 —— 客户端与服务器每隔指定时间互发 “心跳帧”（轻量、无业务含义），让防火墙判定连接 “活跃”，避免被切断。

1. AMQP 心跳原理

RabbitMQ 基于 AMQP 0-9-1 协议，原生支持 Heartbeat（心跳）：

• 客户端与 RabbitMQ 服务器协商一个 “心跳间隔”（如 60 秒）；
• 间隔内无业务数据时，双方会主动发送 0 字节的心跳帧（不占用业务带宽）；
• 若某一方超过 2 个心跳间隔未收到对方响应（如网络故障），则主动断开连接，避免 “僵死连接”。

优势：无需自定义 TCP 层心跳，AMQP 心跳在应用层与 RabbitMQ 连接管理深度整合，更可靠、易维护。

2. 配置步骤（分 “服务器端” 和 “客户端”）

（1）RabbitMQ 服务器端配置（可选，默认已启用）

RabbitMQ 服务器默认启用心跳，默认心跳间隔为 60 秒（可通过配置文件调整全局默认值）：

• 找到 RabbitMQ 配置文件（如 rabbitmq.conf，不同系统路径不同：Linux 多为 /etc/rabbitmq/，Windows 多为 C:\Program Files\RabbitMQ Server\rabbitmq_server-x.x.x\etc\）；
• 添加 / 修改以下配置（单位：秒）：
  ini

   

   

  # 全局默认心跳间隔（建议设为 30~120 秒，小于防火墙超时时间）
  heartbeat = 60
  

   
• 重启 RabbitMQ 生效：
  bash

   

   

  # Linux
  rabbitmqctl stop && rabbitmq-server -detached
  # Windows（服务方式）
  net stop RabbitMQ && net start RabbitMQ
  

   

（2）客户端配置（核心，必须与服务器协商心跳）

客户端需显式配置心跳间隔（建议设为 防火墙超时时间的 1/3~1/2，如防火墙超时 30 分钟，则心跳设为 60~120 秒，留足容错）。以下是主流客户端的配置示例：

客户端类型	配置示例（心跳间隔设为 60 秒）
Java（Spring AMQP）	在 application.yml 中配置： yaml<br>spring:<br> rabbitmq:<br> host: 192.168.1.100<br> port: 5672<br> username: guest<br> password: guest<br> connection-timeout: 5000 # 连接超时<br> requested-heartbeat: 60 # 心跳间隔（秒）<br>
Python（pika）	在连接参数中指定心跳： python<br>import pika<br>credentials = pika.PlainCredentials('guest', 'guest')<br># 配置心跳间隔 60 秒<br>parameters = pika.ConnectionParameters(<br> host='192.168.1.100',<br> port=5672,<br> credentials=credentials,<br> heartbeat=60 # 关键参数<br>)<br>connection = pika.BlockingConnection(parameters)<br>
Go（amqp）	通过 Config 结构体设置： go<br>import "github.com/streadway/amqp"<br>config := amqp.Config{<br> Heartbeat: 60 * time.Second, // 心跳间隔<br>}<br>conn, err := amqp.DialConfig("amqp://guest:guest@192.168.1.100:5672/", config)<br>

3. 关键补充：心跳超时后的重连机制

即使启用心跳，若网络临时波动导致心跳超时，客户端仍会断开连接。需在客户端配置 自动重连，确保业务不中断：

• Spring AMQP：默认通过 CachingConnectionFactory 支持重连，可配置重连参数：
  yaml

   

   

  spring:
    rabbitmq:
      # ... 其他配置
      cache:
        connection:
          mode: CHANNEL # 连接池模式
      listener:
        simple:
          retry:
            enabled: true # 启用消费端重试
            max-attempts: 3 # 最大重试次数
  

   
• Python pika：需手动实现重连逻辑（如捕获 ConnectionClosed 异常后重新创建连接）。

四、方案选择建议

1. 优先选防火墙配置：无需修改代码，一劳永逸，适合有权限管理防火墙的场景；
2. 次选 RabbitMQ 心跳：适合无防火墙权限、跨网络部署（如公网 RabbitMQ）的场景，仅需客户端配置即可生效；
3. 不建议自定义 TCP 心跳：RabbitMQ 已通过 AMQP 心跳封装了连接维持逻辑，自定义 TCP 心跳可能与 AMQP 协议冲突，增加维护成本。

五、验证方案是否生效

1. 模拟空闲场景：停止发送业务消息，等待超过防火墙原超时时间（如原超时 30 分钟，等待 40 分钟）；
2. 检查连接状态：
   • 服务器端：通过 rabbitmqctl list_connections 查看客户端连接是否仍存在；
   • 客户端：尝试发送一条测试消息，观察是否成功（无 connection reset by peer 异常）；
3. 防火墙侧：查看该 TCP 会话是否仍处于 “ESTABLISHED”（活跃）状态。