Docker环境下ASP.NET Core应用连接SQL Server失败问题求助

故障核心原因 #

本地IIS Express运行时一切正常，切到Docker后立刻报TCP连接失败，本质是两个配置错位：

• 网络寻址错位：你现在的连接字符串写的Server=localhost,1433，在容器内部这个localhost指向的是容器自己的回环网卡，跟跑MSSQL的宿主机根本不在一个网络命名空间，当然找不到数据库服务。本地运行时所有进程都在同一个系统网络栈里，localhost就是开发机本身，所以不会有这个问题。
• 认证方式不兼容：连接字符串里的Integrated Security=True是Windows集成认证模式，当前你用的.NET Core 3.1 aspnet镜像基于Linux内核，根本没有Windows域安全上下文，哪怕网络通了也走不通这个认证流程。
• 你之前在Dockerfile里调整openssl安全级别的操作，是用来解决后续TLS版本兼容报错的，跟当前“TCP连不上”的网络层故障没关系，不用改这块配置。

可落地修复步骤 #

1. 修正数据库服务的网络寻址 #

根据MSSQL的实际部署位置替换连接字符串里的Server地址，不要直接用localhost：

• 如果MSSQL安装在运行Docker的宿主机上：
  • Windows/Mac环境下的Docker Desktop，直接把localhost,1433替换为host.docker.internal,1433——这个域名是Docker内置的、专门用来让容器访问宿主机服务的预留地址，不需要配静态IP。
  • Linux服务器上的原生Docker引擎，需要在容器启动命令里加--add-host=host.docker.internal:host-gateway参数，让容器内的这个域名正确指向宿主机的docker0网关地址。
  • 只有当你用--network=host模式启动容器时，才可以保留localhost，因为此时容器和宿主机共享整个网络栈，不存在命名空间隔离。
• 如果MSSQL是单独部署在另一个Docker容器里：先把应用容器和MSSQL容器加入同一个自定义Docker bridge网络，连接字符串里的Server直接写MSSQL容器的服务名即可。

2. 替换不兼容的认证配置 #

把原连接字符串里的Integrated Security=True删掉，换成SQL Server账号密码认证，最终的连接字符串参考格式：
"TestConnection": "Server=host.docker.internal,1433;Database=BDREPOSITORIO;User Id=你的MSSQL登录账号;Password=你的MSSQL登录密码;TrustServerCertificate=True"

补充说明：加TrustServerCertificate=True是为了跳过容器内对MSSQL自签名证书的校验，毕竟MSSQL默认生成的证书不会被Linux系统的信任证书链认可，不加这一句大概率会报证书校验失败的错。

3. 验证数据库侧的访问权限 #

• 检查宿主机防火墙的入站规则，确认1433端口允许来自Docker虚拟网段的连接，不要把Docker网段的请求拦在外面。
• 确认你用的SQL Server登录账号没有配置IP访问限制，允许来自宿主机docker网关网段的连接请求。

快速连通性验证小技巧 #

排查的时候不用等整个应用启动，直接进容器内部测连通性就行：

1. 执行docker exec -it <你的应用容器ID> bash进入容器终端
2. 装简易测试工具：apt update && apt install -y telnet
3. 执行telnet host.docker.internal 1433，如果返回连通成功的提示，说明网络层已经打通，剩下的问题就是认证、TLS配置的问题。

常见踩坑提醒 #

• 别把宿主机的局域网IP硬编码到连接字符串里，换个开发环境、换个网络位置就会失效，优先用Docker预留的host.docker.internal地址，可移植性最好。
• Dockerfile里的openssl安全级别调整可以保留，这个是解决Linux容器和低版本MSSQL之间TLS握手失败的必要操作，跟当前的网络层修复不冲突。

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