从Docker通过host.docker.internal连接本地SQL Server遭拒绝

我来帮你排查下这个连接被拒绝的问题——既然host.docker.internal能正常解析且ping通，那问题大概率出在SQL Server的配置细节上，而非基础网络连通性。咱们一步步来定位：

• 检查SQL Server是否真的在监听1433端口
  打开Windows命令提示符，执行以下命令：

  netstat -ano | findstr :1433
  

  如果没有返回LISTENING状态的条目，说明SQL Server并未启用1433端口监听。这时候需要：

  1. 打开「SQL Server配置管理器」
  2. 找到「SQL Server网络配置」→「MSSQLSERVER的协议」，确保TCP/IP处于启用状态
  3. 双击TCP/IP，切换到「IP地址」选项卡，拉到最底部的「IPAll」区域，将「TCP端口」设置为1433
  4. 重启SQL Server服务生效

• 确认SQL Server允许远程连接
  打开SQL Server Management Studio（SSMS），右键你的服务器实例→「属性」→「连接」，勾选「允许远程连接到此服务器」，点击确定保存。

• 校验防火墙规则的完整性
  虽然你已经开放了1433端口，但要注意：

  • 入站规则的适用网络类型要包含Docker使用的虚拟网络（一般是「专用」网络）
  • 进入Windows Defender防火墙的「高级设置」，检查规则是否覆盖了Docker的虚拟网卡（比如vEthernet (DockerNAT)）

• 用本地IP直接测试连通性
  在容器内尝试用你本地机器的实际IP（而非host.docker.internal）测试端口连通性，比如：

  telnet 你的本地IP 1433
  

  或者如果容器里有nc工具：

  nc -zv 你的本地IP 1433
  

  如果仍然连接失败，说明问题完全在本地SQL Server的配置上，和Docker的host映射无关。

• 检查SQL Server身份验证模式
  如果你用的是SQL Server身份验证，要确保对应的登录名拥有远程连接权限，且连接字符串里的用户名密码正确；如果是Windows身份验证，可能需要调整容器网络模式（比如用--network="host"），不过这个场景相对少见，优先排查前面的点。

按这个顺序排查下来，应该能快速定位到问题根源。最常见的原因就是SQL Server没启用TCP/IP监听，或者没开启远程连接权限。

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