.NET Core 3.1 MVC部署于Ubuntu 20.10环境下无法连接Linux版SQL Express问题求助

架构老林

2026-4-29

我来帮你一步步排查这个问题，毕竟Linux上跑SQL Server和Windows环境确实有不少差异，咱们从最基础的配置开始查起：

第一步：先确认SQL Server在Ubuntu上的基础配置是否正确

这部分是核心——如果SQL Server本身配置不对，应用怎么调整都连不上。

检查SQL Server服务状态
先确认服务是否正常运行：
```
sudo systemctl status mssql-server
```
如果没运行，先启动并设置开机自启：
```
sudo systemctl start mssql-server
sudo systemctl enable mssql-server
```
确认1433端口开放
SQL Server在Linux上默认用1433端口，Ubuntu的ufw防火墙可能默认没放行这个端口：
```
sudo ufw status
```
如果看不到1433/tcp的允许规则，添加并重载防火墙：
```
sudo ufw allow 1433/tcp
sudo ufw reload
```
启用SQL Server混合认证模式并激活sa账号
你用的第二种连接字符串是SQL认证，但Linux上的SQL Server默认可能是仅Windows认证模式，而且sa账号默认是禁用的：
1. 先安装sqlcmd工具（用来直接操作SQL Server）：
```
sudo apt install mssql-tools
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc
source ~/.bashrc
```
2. 修改SQL Server认证模式为混合模式：
```
sudo nano /var/opt/mssql/mssql.conf
```
  添加或修改以下内容：
```
[sqlserver]
authenticationMode=混合
```
  然后重启服务：
```
sudo systemctl restart mssql-server
```
3. 重置sa密码（如果之前没设置或忘记了）：
```
sudo /opt/mssql/bin/mssql-conf set-sa-password
```
4. 用sa账号登录并启用它：
```
sqlcmd -S localhost -U SA -P 你的sa密码
```
  登录后执行SQL命令启用sa：
```
ALTER LOGIN sa ENABLE;
GO
```
5. 测试连接：执行SELECT DB_NAME(); GO，如果能返回当前数据库名，说明SQL Server的SQL认证已经正常工作。

第二步：修正连接字符串和环境变量配置

你的第一种连接字符串Server=.\\SQLEXPRESS;...是Windows专属写法，Linux上的SQL Server Express没有SQLEXPRESS实例名（默认就是默认实例，用1433端口），而且Trusted_Connection=True在Linux上需要配置Kerberos，对自包含部署的应用来说非常麻烦，直接放弃第一种，专注调试SQL认证的连接字符串。

appsettings.json的正确写法
确保连接字符串没有多余空格，加上证书信任配置（Linux上SQL Server默认用自签证书，应用会验证失败）：
```
{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost,1433;Database=mydatabase;User ID=sa;Password=tttttt;TrustServerCertificate=True"
  }
}
```
systemd服务文件的环境变量配置
如果你想用环境变量覆盖appsettings.json的配置，注意格式：双下划线__对应配置里的层级分隔，而且连接字符串要加引号避免shell解析分号出错：
```
Environment="ConnectionStrings__DefaultConnection=Server=localhost,1433;Database=mydatabase;User ID=sa;Password=tttttt;TrustServerCertificate=True"
```
修改完服务文件后，必须重启服务让配置生效：
```
sudo systemctl daemon-reload
sudo systemctl restart your-app.service
```

第三步：确认应用是否正确读取到连接字符串

有时候环境变量没生效，或者appsettings.json没被正确加载，你可以在Startup.cs里加一行日志输出实际读取到的连接字符串，快速定位问题：

var connection = Configuration.GetConnectionString("DefaultConnection");
// 添加这行日志，查看实际读取的内容
Console.WriteLine($"当前使用的连接字符串：{connection}");
services.AddDbContext<UniGateContext>(options => options.UseSqlServer(connection));

然后用命令实时查看应用日志：

journalctl -u your-app.service -f

看输出的连接字符串是不是你期望的内容。

第四步：查看应用的详细错误日志

启用Debug级别的日志，能看到具体的连接错误信息（比如登录失败、连接超时、数据库不存在等）：
在appsettings.json里修改日志配置：

{
  "Logging": {
    "LogLevel": {
      "Default": "Debug",
      "Microsoft": "Debug",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  }
}

重启应用后，访问需要数据库的API，查看日志里的异常信息，这些信息能直接告诉你问题根源。

最后排除几个小问题

确认mydatabase数据库确实存在：用sqlcmd登录后执行SELECT name FROM sys.databases WHERE name='mydatabase'; GO检查。
自包含部署的话，确认发布目录里有Microsoft.Data.SqlClient.dll（.NET Core 3.1的自包含包应该默认包含，但可以搜一下确认）。
Nginx不会影响数据库连接（应用是直接和SQL Server建立连接的），所以可以排除Nginx的问题。

按照这个步骤排查，应该能快速找到问题——我之前在Linux上部署.NET Core连SQL Server时，大部分问题都是SQL Server的认证模式没开或者sa账号没启用。

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