Azure Pipelines Agent 运行环境下测试结果上传失败问题分析与解决方案

问题背景

在企业混合云环境中使用Azure Pipelines Agent时，当运行环境配置了企业级网络设置和正确的绕过规则后，虽然大部分功能运行正常，但在发布测试运行数据时会遇到上传失败的问题。具体表现为尝试连接ufxtcmprodweu21.vstmrblob.vsassets.io:443时出现套接字超时错误。

错误现象

系统日志显示以下关键错误信息：

Microsoft.Azure.Storage.DataMovement.TransferException: The transfer failed.
 ---> Microsoft.Azure.Storage.StorageException: A connection attempt failed because the connected party did not properly respond after a period of time...

错误发生在尝试上传测试结果文件TestResultDetails_202412171341402018.tau到Blob存储时。值得注意的是，其他外部目标的通信都能正常进行，只有测试结果上传这一特定功能失败。

根本原因分析

经过深入调查，发现问题根源在于网络配置的传递机制：

1. 虽然网络配置通过相关文件正确设置，但这些配置未能正确传递给所有组件
2. TestLogStoreDALImpl类虽然将网络设置对象传递给基类TestLogStoreDAL，但仅关联到WebRequest.DefaultWebProxy
3. 关键的HttpClient.DefaultProxy未被正确初始化，导致部分组件无法使用网络设置

临时解决方案

目前可用的临时解决方案是设置以下环境变量：

1. NO_PROXY - 指定不需要特殊网络设置的地址
2. HTTP_PROXY - 指定网络服务地址

这种方法虽然能暂时解决问题，但存在安全隐患，因为：

• 环境变量会被所有应用程序读取
• 网络凭据可能被泄露
• 不符合最佳安全实践

长期解决方案

微软团队已经确认这是一个需要修复的问题，将在未来版本中提供官方解决方案。建议的修复方向包括：

1. 统一网络配置机制，确保所有组件都能正确获取网络设置
2. 改进网络凭据的安全存储和传递方式
3. 增强错误日志，帮助诊断类似连接问题

最佳实践建议

在等待官方修复期间，建议采取以下措施：

1. 监控网络服务的连接日志，了解实际被阻止的请求
2. 评估是否可以将测试结果上传目标地址添加到网络白名单
3. 考虑在非生产环境中使用临时解决方案，但避免在生产环境使用环境变量存储敏感信息
4. 定期检查Azure Pipelines Agent的更新，及时应用包含修复的版本

技术细节

深入分析显示，问题的技术本质在于.NET框架中不同HTTP客户端组件的网络处理机制不统一：

• WebRequest.DefaultWebProxy - 传统组件的网络设置
• HttpClient.DefaultProxy - 现代组件的网络设置
• 某些库(如Azure Storage SDK)可能使用自定义的HTTP栈

这种碎片化的网络配置方式是导致部分功能无法正常工作的根本原因。