这个问题确实棘手——开发环境一切正常，一部署到Linux Docker容器就触发超时，结合你提供的错误日志和环境信息，我整理了几个针对性的解决思路，你可以逐一尝试：

1. 强制启用TLS 1.0支持（核心排查点） #

SQL Server 2005仅支持TLS 1.0，而.NET Core 3.1在Linux环境下默认出于安全考虑禁用了这个老旧协议。这会导致驱动完成握手后，后续通信无法正常推进，最终触发Post-login阶段超时。

你可以通过两种方式启用TLS 1.0：

• 在Docker运行时传递环境变量：

  docker run -e DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0 -e CLR_SQLCLIENT_FORCE_ENCRYPT=false your-image-name
  

• 或者在应用启动代码中主动配置：

  System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls;
  

注意：TLS 1.0存在安全风险，这只是临时兼容方案，长远来看还是建议升级SQL Server版本。

2. 延长连接超时时间 #

从错误日志的[Post-Login] complete=30553可以看到，登录后阶段耗时已经超过了你设置的30秒超时阈值。把连接字符串里的Connection Timeout=30调整为更大的值，比如Connection Timeout=60或Connection Timeout=120，给服务器足够的时间完成登录后的初始化操作。

3. 降级Microsoft.Data.SqlClient版本 #

新版的Microsoft.Data.SqlClient（3.x及以上）已经官方放弃了对SQL Server 2005的支持，兼容性问题会非常突出。你可以尝试降级到2.1.5版本——这是最后明确支持SQL Server 2005的稳定版本之一：

dotnet add package Microsoft.Data.SqlClient --version 2.1.5

4. 调整加密相关配置 #

SQL Server 2005的加密实现和现代驱动兼容性很差，你可以尝试：

• 完全关闭加密：将连接字符串中的Encrypt=True改为Encrypt=False
• 如果必须保留加密，确保TrustServerCertificate=True的同时，验证SQL Server的证书是否符合容器的信任规范（不过SQL Server 2005的证书大概率不满足现代要求）

5. 检查SQL Server端的登录后操作 #

Post-login阶段超时，可能是SQL Server在用户登录后执行了耗时操作：

• 检查是否存在登录触发器：SELECT * FROM sys.server_triggers
• 查看SQL Server的错误日志，排查是否有登录相关的异常或延迟记录
• 监控SQL Server在应用连接时的CPU、内存占用，确认是否存在性能瓶颈

6. 验证Docker网络细节 #

虽然你用sqlcmd能正常连接，但应用的网络上下文可能存在差异：

• 在容器内用ping mysqlserver或traceroute mysqlserver检查网络连通性和延迟
• 尝试用SQL Server的IP地址代替服务器名称，避免DNS解析带来的延迟或问题

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