后端MQTT Broker通过WebSocket接入企业集成器路由失败求助

嗨，看起来你在把MQTT over WebSocket流量通过企业集成器（看你提到Axi相关，应该是WSO2 EI吧？）路由时卡壳了——直接连后端Broker一切正常，走集成器就不行，对吧？结合你的场景（测试环境无安全策略、Broker监听machine:9999/api/mqtt路径），我整理了几个重点排查和修复方向：

1. 严格匹配WebSocket路径与代理配置 #

你的Broker绑定的是/api/mqtt这个特定路径，集成器的代理配置必须1:1对应，不能有路径重写或遗漏：

• 确保集成器的目标端点URL是ws://machine:9999/api/mqtt（注意是ws://协议，不是http://，毕竟是WebSocket连接）
• 如果用的是API网关模式，要保证客户端请求的路径和Broker的路径完全匹配，或者配置正确的路径映射规则，别把/api/mqtt转发到其他路径去了

2. 确保WebSocket协议头与帧的完整透传 #

MQTT over WebSocket依赖特定的协议头和帧格式，集成器要是擅自修改这些内容，直接就会导致连接失败：

• 检查集成器是否保留了Upgrade: websocket和Connection: Upgrade这两个核心升级头，绝对不能被过滤或修改
• 确认集成器允许mqtt这个WebSocket子协议（有些集成器需要显式配置支持的子协议列表，没加的话会拒绝连接）
• 关闭集成器对WebSocket帧的额外编码/解码操作，必须让帧以原始格式透传给Broker

3. 检查集成器的监听端口与长连接设置 #

• 确认集成器对外暴露的WebSocket端口（比如WSO2 EI默认的8080或自定义端口）是开放的，客户端能正常访问到
• MQTT是长连接协议，集成器的超时设置如果太短，会主动断开连接，得把长连接超时时间调大，适配MQTT的连接特性

4. 启用日志抓细节，定位差异 #

如果前面的配置都没问题，那就开日志找线索：

• 记录客户端到集成器的WebSocket升级请求头，再对比直接连Broker时的请求头，找出两者的差异（比如少了某个头、头值被修改）
• 记录集成器转发到Broker的请求，以及Broker的响应信息，看是否有连接被拒绝的错误码或提示

给你一个WSO2 EI的简单代理配置示例，你可以参考调整：

<proxy name="MQTTWebSocketProxy" startOnLoad="true" transports="ws">
    <target>
        <endpoint>
            <address uri="ws://machine:9999/api/mqtt"/>
        </endpoint>
        <outSequence>
            <send/>
        </outSequence>
        <inSequence>
            <send/>
        </inSequence>
    </target>
    <!-- 确保WebSocket升级请求被正确处理 -->
    <parameter name="ws.outflow.dispatch.HTTP_ACCEPT">true</parameter>
    <parameter name="ws.inflow.dispatch.HTTP_UPGRADE">true</parameter>
</proxy>

这个配置会把客户端通过ws://<EI主机>:<EIWebSocket端口>/MQTTWebSocketProxy的请求，完整转发到你的Broker路径，同时保证WebSocket升级逻辑正常工作。

如果你的集成器是其他类型（比如Apache Camel、Spring Cloud Gateway），核心思路都是一样的：路径匹配、协议头透传、长连接支持。

内容的提问来源于stack exchange，提问作者Nicky