HttpClient问题：控制台程序正常运行但Outlook VSTO中连接意外关闭

这问题我之前帮同事排查过类似的，核心原因是Outlook VSTO运行的Office进程，和普通控制台程序的网络环境存在差异，导致请求内部API时出现连接中断。结合你描述的“访问谷歌正常但公司API报错”的情况，大概率是下面几个原因之一，你可以按顺序排查：

1. TLS版本不兼容（最常见） #

普通控制台程序在Windows 10/11默认会启用TLS 1.2或1.3，但Office进程（尤其是旧版本Office）可能默认还是用TLS 1.0/1.1，而你的公司API大概率只支持较新的TLS协议。

解决方法：在创建HttpClient实例之前，强制指定TLS版本：

// 启用TLS1.2和TLS1.3
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;
// 然后再实例化HttpClient
HttpClient client = new HttpClient();

2. Office代理配置与控制台不一致 #

Outlook可能单独配置了代理（比如使用系统代理或者企业内部代理），而控制台程序用的是默认设置，导致请求公司API时代理转发失败。

你可以尝试两种方案：

• 强制HttpClient使用系统代理：

var handler = new HttpClientHandler
{
    UseProxy = true,
    Proxy = WebRequest.DefaultWebProxy
};
HttpClient client = new HttpClient(handler);

• 或者暂时禁用代理测试：

var handler = new HttpClientHandler
{
    UseProxy = false
};
HttpClient client = new HttpClient(handler);

3. 企业级Office的安全拦截 #

很多企业会给Office套件安装安全插件（比如防病毒、数据泄露防护工具），这些工具可能会拦截对内部API的请求，但允许访问公开网站（比如谷歌）。

这种情况你可以：

• 把公司API的域名添加到Office的信任站点列表；
• 联系公司IT部门，确认是否有针对Office进程的网络拦截规则。

4. 请求头或编码的细微差异 #

虽然代码看起来和控制台完全一致，但VSTO环境可能会默认添加一些额外请求头，或者编码处理有差异。你可以尝试：

• 显式添加User-Agent头，模拟控制台或浏览器的请求标识：

client.DefaultRequestHeaders.UserAgent.ParseAdd("ConsoleApp/1.0");

• 检查StringContent的编码是否正确，也可以尝试显式指定编码的字节顺序标记：

var content = new StringContent(json, new UTF8Encoding(false), "application/json");

内容的提问来源于stack exchange，提问作者Arnaud F.