返回

VB.Net 远程连接 SQL Server 错误 26？配置与防火墙指南

mysql

VB.Net 远程连接 SQL Server 数据库？网络错误不用慌，看这篇！

问题来了：VB.Net 连不上别的电脑上的 SQL Server

写了个 VB.Net 程序，想连同一局域网里另一台电脑上的 SQL Server 数据库，结果程序一跑，直接给我弹了个错误：

"An network-related or instance-specific error occurred while establishing to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)"

懵了不是？明明感觉 SQL Server 配置中心里的远程连接选项都开了，SQL Server Browser 服务也跑着，两台电脑网络也是通的（无线连着呢），怎么就死活连不上？

这是我那段“问题”连接字符串：

"Data Source=NEWUSER0602akz\SQLEXPRESS;Initial Catalog=sample;Integrated Security=True"

到底是哪里出了岔子？

为啥连不上？扒一扒可能的原因

这个 "network-related or instance-specific error" 挺常见的，但也挺烦人，因为它可能的原因实在不少。别急，咱们一条条捋：

  1. 网络通路问题： 虽然你说网络是通的，但“通”也分好几种。可能只是 ping 通了，但数据库连接需要的特定端口（默认 1433）被防火墙拦住了。Windows 自带防火墙、第三方杀毒软件的防火墙，甚至路由器上的设置，都可能是“拦路虎”。
  2. SQL Server 配置没到位：
    • 远程连接开关： 你确定真的开启了远程连接吗？不只是在服务器属性里勾选，TCP/IP 协议也得启用才行。
    • TCP/IP 协议： 这是远程连接的基础。如果没在 SQL Server Configuration Manager 里给对应的实例启用 TCP/IP，那外网肯定连不上。
    • SQL Server Browser 服务： 你用的是命名实例 (SQLEXPRESS)。客户端连接命名实例时，需要先问 SQL Server Browser 服务：“喂，那个叫 SQLEXPRESS 的实例在哪台机器、哪个端口上？”。如果这个服务没启动，或者被防火墙挡了（UDP 端口 1434），客户端就找不到北了。
  3. 连接字符串写错了：
    • 服务器名/实例名： NEWUSER0602akz\SQLEXPRESS 里的 NEWUSER0602akz 是对方电脑的准确主机名吗？大小写有时候也可能影响（虽然通常不区分）。SQLEXPRESS 这个实例名对吗？
    • 数据库名： Initial Catalog=sample 这个 sample 数据库真的存在吗？名字写对了吗？
  4. 身份验证模式和权限：
    • 你用了 Integrated Security=True，也就是 Windows 集成身份验证。这意味着你的 VB.Net 程序会尝试用 运行它 的那个 Windows 用户的身份去登录 SQL Server。
    • 在 非域环境 的两台电脑之间，这种方式很容易失败。除非两台电脑上有完全相同的用户名和密码，并且做了特定配置，否则服务器那边不认你这个“外来”的 Windows 身份。
    • 即使在 域环境 下，也可能因为 SPN (Service Principal Name) 没配置对等原因导致 Kerberos 验证失败，降级到 NTLM 或者干脆失败。

这么多可能性，听着头大？别怕，下面我们一个个解决。

解决办法：一步步搞定远程连接

咱们按照从网络层到数据库配置再到代码的顺序，一步步排查。

1. 检查网络和防火墙设置

原理： 确保你的电脑能和装了 SQL Server 的那台电脑在网络层面“对话”，特别是数据库需要的端口得能通。

操作步骤：

  • 基础网络连通性测试：
    在你的开发电脑上打开命令提示符（CMD），ping 一下 SQL Server 所在的电脑。用主机名试试，再用 IP 地址试试。

    ping NEWUSER0602akz
ping <服务器的IP地址> # 比如 ping 192.168.1.101

    如果 ping 主机名不通但 IP 地址通，可能是 DNS 解析问题，后面连接字符串里直接用 IP 地址更稳妥。如果都不通，那先解决基础网络问题吧，跟 SQL Server 关系不大。

  • 检查服务器上的防火墙： 这是最常见的坑！

    • Windows Defender 防火墙：

      1. 在 运行 SQL Server 的电脑上 ，搜索并打开“高级安全 Windows Defender 防火墙”。
      2. 点击左侧的“入站规则”。
      3. 在右侧找到和 SQL Server 相关的规则。你需要确保至少有两条规则是启用的：
        • SQL Server (TCP-In): 允许 TCP 端口 1433（如果你没改默认端口）的入站连接。如果没有这条规则，就手动“新建规则” -> “端口” -> “TCP”，指定端口 1433 -> “允许连接” -> 应用到所有配置文件（域、专用、公用，根据你的网络环境选择）-> 给规则起个名字（比如 "SQL Server TCP 1433"）。
        • SQL Server Browser (UDP-In): 允许 UDP 端口 1434 的入站连接。同样，没有就新建，选择“UDP”和端口 1434。
      4. 确保规则状态是“已启用”。如果规则存在但被禁用，右键点击 -> “启用规则”。

    • 第三方防火墙/杀毒软件： 如果服务器上装了 360、诺顿、卡巴斯基之类的软件，它们也可能有自己的防火墙。你需要到这些软件的设置里，把 SQL Server 的主程序 (sqlservr.exe) 和上面提到的 TCP 1433、UDP 1434 端口添加到允许列表或例外中。具体怎么加，得看你用的软件了。

安全建议：

  • 防火墙规则别开太大。如果你的开发电脑 IP 地址是固定的，可以在防火墙规则里只允许来自你 IP 地址的连接，而不是允许所有 IP。在规则的“作用域”里设置远程 IP 地址。
  • 只开放确实需要的端口。

2. 确认 SQL Server 配置无误

原理： 光通路打开了还不够，SQL Server 自己得愿意“接客”（接受远程连接），并且得告诉别人它在哪个“房间”（端口）接待。

操作步骤：

  • 使用 SQL Server Configuration Manager： 这是配置 SQL Server 网络协议和服务的官方工具。
    1. 在 运行 SQL Server 的电脑上 ，搜索并打开 "SQL Server Configuration Manager"（根据你的 SQL Server 版本，名字可能略有不同，比如 "SQL Server 2019 Configuration Manager"）。
    2. 在左侧导航栏，展开 "SQL Server Network Configuration"，然后点击 "Protocols for SQLEXPRESS" (你的实例名是 SQLEXPRESS)。
    3. 在右侧，确保 TCP/IP 协议的状态是 Enabled 。如果是 Disabled，右键点击它 -> "Enable"。会提示你需要重启服务才能生效。
    4. 重要： 右键点击 TCP/IP -> "Properties"。切换到 "IP Addresses" 选项卡。
    5. 检查端口： 向下滚动，找到 "IPAll" 节点。
      • TCP Dynamic Ports: 如果这里有值（通常是个类似 5xxxx 的数字），表示 SQL Server 在用动态端口。清空它！ 否则客户端连接很麻烦。
      • TCP Port: 在这里输入 1433 （或者你希望使用的其他 静态端口 ）。确保这里有明确的端口号。
      • 检查其他 IP 地址： 往上看，检查服务器上每个活动的 IP 地址对应的设置。确保它们的 "Enabled" 设置为 "Yes"，并且 "TCP Port" 也设置为了 1433 (或者你统一设置的那个端口)，"TCP Dynamic Ports" 同样是 空的 。
    6. 点击 "OK" 保存设置。
    7. 检查 SQL Server Browser 服务： 在左侧导航栏，点击 "SQL Server Services"。
    8. 在右侧找到 "SQL Server Browser"。确保它的 "State" 是 Running 。如果不是，右键点击 -> "Start"。同时，最好把它的 "Start Mode" 设置为 "Automatic"，这样电脑重启后它能自动运行。
    9. 重启服务： 为了让 TCP/IP 的修改和 Browser 服务状态生效，你需要重启 SQL Server 服务本身。在 "SQL Server Services" 里找到 "SQL Server (SQLEXPRESS)"，右键点击 -> "Restart"。如果刚才修改了 TCP/IP 设置，它可能会提示依赖的 Browser 服务也需要重启，同意即可。

进阶使用技巧：

  • 静态端口 vs 动态端口： 强烈建议给 SQL Server 实例配置一个 静态端口 （默认 1433 就挺好）。动态端口每次 SQL Server 服务重启都可能变化，客户端连接时必须依赖 SQL Server Browser 服务去查询当前端口，增加了出错点和网络开销。使用静态端口，客户端可以直接连，更稳定。如果你用了非 1433 的静态端口，比如 1450，那后面的连接字符串里也要指明。

3. 优化连接字符串

原理： 连接字符串是应用程序找到并登录数据库的“地图”和“钥匙”。一点错误就可能导致迷路或被拒之门外。

代码示例 & 步骤：

基于你原来的连接字符串，我们来尝试几种修正：

  • 尝试使用 IP 地址代替主机名： 这是排除 DNS 解析问题的好办法。
    假设服务器 IP 是 192.168.1.101，连接字符串改成：

    "Data Source=192.168.1.101\SQLEXPRESS;Initial Catalog=sample;Integrated Security=True"

    试试这个能不能连上。

  • 显式指定端口（如果用了非默认端口或 IP 地址）： 如果你在上一步设置了非 1433 的端口（比如 1450），或者即使是 1433，有时显式指定也有助于解决问题，特别是用 IP 地址连接时。

    ' 假设端口是 1433
"Data Source=192.168.1.101\SQLEXPRESS,1433;Initial Catalog=sample;Integrated Security=True"
' 或者用主机名
"Data Source=NEWUSER0602akz\SQLEXPRESS,1433;Initial Catalog=sample;Integrated Security=True"

    注意，端口号跟在实例名后面，用逗号隔开。

  • 切换到 SQL Server 身份验证： Integrated Security=True 在跨机器（特别是工作组环境）时真的比较麻烦。强烈建议 考虑使用 SQL Server 身份验证，通常更简单直接。

    1. 在 SQL Server Management Studio (SSMS) 里操作：
      • 连接到你的 NEWUSER0602akz\SQLEXPRESS 实例。
      • 在对象资源管理器中，右键点击服务器节点 -> "属性"。
      • 进入 "安全性" (Security) 页面。
      • 在 "服务器身份验证" (Server authentication) 部分，选择 "SQL Server and Windows Authentication mode" （混合模式）。如果原来是 "Windows Authentication mode"，改了之后需要重启 SQL Server 服务才能生效。
      • 在对象资源管理器中，展开 "安全性" (Security) -> 右键点击 "登录名" (Logins) -> "新建登录名" (New Login)。
      • 输入登录名（比如 vb_user）。
      • 选择 "SQL Server authentication"。
      • 输入密码并确认密码。
      • 取消勾选 "强制密码策略" (Enforce password policy) 和 "强制密码过期" (Enforce password expiration) （如果是测试环境可以这样方便点，生产环境请慎重）。
      • 在左侧选择 "用户映射" (User Mapping) 页面。
      • 勾选你的数据库 sample。
      • 在下面的 "数据库角色成员身份" (Database role membership) 列表里，勾选 db_datareader (允许读数据) 和 db_datawriter (允许写数据)，或者根据需要赋予更精确的权限。
      • 点击 "确定" 创建用户。
    2. 修改 VB.Net 连接字符串： 
      "Data Source=NEWUSER0602akz\SQLEXPRESS;Initial Catalog=sample;User ID=vb_user;Password=YourPassword;"
' 或者用 IP 地址
' "Data Source=192.168.1.101\SQLEXPRESS;Initial Catalog=sample;User ID=vb_user;Password=YourPassword;"
      把 vb_user 和 YourPassword 换成你实际创建的用户名和密码。

安全建议：

  • 千万不要 把数据库密码硬编码在源代码里！这非常不安全。至少应该把连接字符串（包含密码）放在配置文件（如 App.config）中，并考虑对配置文件中的敏感部分进行加密。更好的做法是使用更安全的凭据管理方式。
  • 给 SQL Server 登录名分配 最小必需权限 。不要图省事就给 sysadmin 权限。

4. 处理 Windows 集成认证 (Integrated Security)

原理： 如果你坚持要用 Integrated Security=True，尤其是在工作组环境下，那就要理解它背后的认证机制。它需要服务器能验证运行客户端程序的用户身份。

步骤与说明：

  • 域环境 (Domain)：

    • 确保客户端电脑和服务器电脑都加入了 同一个 Windows 域 ，或者它们所在的域之间有信任关系。
    • 运行 VB.Net 程序的用户必须是域用户。
    • 这个域用户需要在 SQL Server 中被授予登录权限，并映射到 sample 数据库，拥有必要的读写权限 (可以在 SSMS 的 "安全性" -> "登录名" 中添加 Windows 用户或组)。
    • 进阶： 偶尔会遇到所谓的 "Kerberos double-hop" 问题，或者 SPN (Service Principal Name) 未正确注册的问题。比如，如果你的 VB.Net 应用是个 Web 服务，再去连接数据库，就可能出现双跳。SPN 需要在域控上使用 setspn 命令为 SQL Server 服务账户注册。这比较复杂，通常需要域管理员协助。如果连接字符串里用 IP 地址代替主机名，可能会强制使用 NTLM 认证而非 Kerberos，有时能绕过 SPN 问题，但也可能带来其他限制。

  • 工作组环境 (Workgroup)：

    • 这是最不推荐使用 Integrated Security=True 的场景。
    • 一种不安全且不推荐 但有时能“凑合”用的方法是：在客户端电脑和服务器电脑上，创建 完全相同 的本地 Windows 用户名和 完全相同 的密码。然后，确保你的 VB.Net 程序是以这个用户身份运行的。即便如此，成功率也不是 100%，受很多网络策略设置影响。
    • 强烈建议： 在工作组环境下，放弃 Integrated Security=True，老老实实使用上面第 3 点提到的 SQL Server 身份验证 。省心省力。

把这些步骤都检查一遍，特别是防火墙、TCP/IP 配置和连接字符串（尤其是尝试用 IP 和 SQL Server 身份验证），你的 VB.Net 程序大概率就能顺利连上另一台电脑上的 SQL Server Express 数据库了。