Jenkins通过Office 365 Connector推送Teams消息失败，疑与代理相关

从你给出的报错栈和场景来看，你的推测完全站得住脚——这个java.io.IOException: Stream closed异常确实大概率是公司代理在处理请求时出了问题，下面给你拆解原因和排查方向：

为什么这个报错指向代理问题？ #

这个异常本质是网络请求的数据流被意外中断，结合你已经确认Jenkins代理配置测试普通外部站点正常，但插件请求Teams webhook失败的情况，核心差异就在于代理对outlook.office.com这个特定域名的处理规则。

可能的代理问题场景 #

• 特定域名的拦截/白名单限制：很多公司代理会对Office 365相关域名设置单独的访问规则，比如需要额外的白名单审批，或者开启了SSL证书拦截（中间人代理），导致插件的HTTPS请求在传输过程中被代理强制断开。
• 代理认证格式不兼容：你使用的user=[domain]\[user]格式，部分代理服务器可能不支持带域的用户名写法，或者需要对反斜杠进行转义（比如用\\代替\），认证失败后代理直接关闭了连接。
• 代理连接超时设置过短：Teams webhook的请求经过代理转发时可能存在延迟，如果代理的连接超时阈值设置得太低，会提前中断连接，触发Stream closed异常。
• POST请求被限制：有些代理默认只允许GET请求，而Teams webhook需要通过POST方法推送消息，请求被拦截后数据流直接关闭。

排查建议 #

• 用curl直接在Jenkins服务器测试：模拟插件的请求方式，带上代理参数测试webhook地址，命令示例：

  curl -x http://[proxy-host]:[proxy-port] -U [domain]\[user] https://outlook.office.com/webhook/[removed]/JenkinsCI/[removed] -d "test message"
  

  如果curl也失败，那基本可以锁定是代理问题；如果curl成功，再去排查插件的配置细节。
• 查看代理服务器日志：找与outlook.office.com相关的请求记录，看有没有认证失败、拦截或超时的日志条目，这是定位具体问题最直接的方式。
• 调整Jenkins代理的SSL配置：如果是代理的SSL证书拦截导致的问题，可以尝试导入公司代理的根证书到Jenkins的JVM信任库中；或者临时关闭SSL证书验证（仅测试用，不建议长期开启），看是否能解决问题。
• 确认代理允许POST请求：联系运维团队，确认代理是否允许向outlook.office.com发送POST请求。

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