WSO2 MI 4.4.0通过SQUID代理使用AWS SQS Connector推送数据超时问题

一、缺失配置排查 #

• Connector级代理显式配置：AWS SQS Connector v3.x不会自动继承MI全局代理，需在Connector初始化参数中单独指定代理信息，包括proxyHost、proxyPort，若代理需认证还要补充proxyUsername和proxyPassword。
• 系统代理环境变量生效验证：确保Ubuntu服务器的http_proxy、https_proxy环境变量是在WSO2 MI进程启动前设置的，或直接在MI启动脚本micro-integrator.sh中添加这些变量，避免进程未读取到代理配置。
• SQUID代理规则检查：确认SQUID允许MI服务器IP访问sqs.us-east-1.amazonaws.com:443，无ACL拦截规则，同时检查代理侧的超时设置是否合理，避免因代理端超时导致连接失败。
• MI SSL代理配置验证：在deployment.toml中完善HTTP/HTTPS代理的全量配置，避免遗漏SSL相关参数，示例：

  [transport.http.proxy]
  host = "你的SQUID主机地址"
  port = 3128
  username = "代理用户名"
  password = "代理密码"
  
  [transport.https.proxy]
  host = "你的SQUID主机地址"
  port = 3128
  username = "代理用户名"
  password = "代理密码"
  

  同时检查axis2.xml中是否存在覆盖上述配置的自定义参数，避免配置冲突。

二、与SQS Connector v3.0.1的关联性 #

SQS Connector v3.x基于AWS SDK v2开发，而旧版本（如v2.x）基于SDK v1，两者代理处理逻辑差异明显。v3.x不会自动复用全局代理配置，必须显式添加Connector级代理参数，这是导致部署后超时的核心原因之一。

三、VS Code中降级Connector版本 #

• 打开VS Code的WSO2 MI扩展，进入Connectors面板。
• 找到AWS SQS Connector，点击右侧下拉菜单，选择Install Specific Version。
• 在版本列表中选择v3.0.1以下的稳定版本（如v2.1.0），等待安装完成后重新构建CAR包。

四、超时问题解决步骤 #

1. 配置Connector专属代理：在SQS Connector的LocalEntry配置中添加代理节点，示例：

   <localEntry key="SQSConfig">
       <awssqs:config>
           <awssqs:basic-configuration accessKey="AKIAXXX" secretKey="XXX" region="us-east-1"/>
           <awssqs:proxy-configuration proxyHost="SQUID主机地址" proxyPort="3128" proxyUsername="代理用户" proxyPassword="代理密码"/>
       </awssqs:config>
   </localEntry>
   

2. 调整MI传输超时参数：在deployment.toml中增加HTTP/HTTPS发送超时设置：

   [transport.http]
   sender.timeout = 30000
   [transport.https]
   sender.timeout = 30000
   

3. 测试代理连通性：在Ubuntu服务器上用curl验证代理能否正常访问SQS端点：

   curl -x http://SQUID主机地址:3128 https://sqs.us-east-1.amazonaws.com
   

   确认网络层面无阻塞，排除代理本身的连通问题。
4. 开启DEBUG日志定位细节：修改log4j2.properties，将org.apache.http、com.amazonaws的日志级别设为DEBUG，查看具体连接失败原因（如代理认证失败、SSL握手异常等）。

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