咨询：无需修改连接字符串，将srvtest的SQL Server识别为[production/work]

哈哈，这个需求太常见了——不想动程序连接字符串，只想靠本地配置把请求拐去测试服务器的不同实例对吧？我之前帮团队搞定过一模一样的场景，给你几个靠谱的方案：

方案1：SQL Server客户端别名（最推荐，专门适配SQL Server） #

这是微软官方提供的解决方案，完全为这类场景设计，不用改任何代码，只需要在本地配置客户端别名：

• 打开SQL Server配置管理器（直接在Windows开始菜单搜就能找到，或者通过mmc.exe添加「SQL Server Native Client 配置」管理单元）
• 注意区分32位和64位程序：如果你的测试程序是32位的，就找「SQL Server Native Client 配置」；64位的话选「SQL Server Native Client 配置(64位)」
• 右键「别名」→「新建别名」：
  • 别名名称：直接填程序连接字符串里的production或者work（就是你想让程序识别的那个服务器名）
  • 服务器：填实际的测试服务器名srvtest，如果是命名实例，写成srvtest\你的实例名就行；要是怕出问题，也可以直接填srvtest的IP地址
  • 协议：优先选TCP/IP（兼容性最好），如果用命名管道也可以
  • 端口：如果是默认实例，填1433；如果是命名实例，先去srvtest的SQL配置管理器里把实例改成固定端口（动态端口容易出问题），然后填对应的端口号
• 重复上面的步骤，给production和work分别创建别名，对应到srvtest上的不同SQL实例。配置完之后，程序里的连接字符串完全不用改，直接就能连到对应的测试实例了。

方案2：Hosts映射+端口转发（通用TCP场景适配） #

如果你的程序用的是标准TCP连接，也可以用这个通用方法，不限于SQL Server：

1. 修改本地Hosts文件：
   用管理员权限打开C:\Windows\System32\drivers\etc\hosts，添加两行：

   127.0.0.1    production
   127.0.0.1    work
   

   这样程序访问production和work时，会先指向本地IP。修改完记得刷新DNS缓存：ipconfig /flushdns
2. 设置端口转发：
   用Windows自带的netsh命令，把本地端口转发到srvtest的不同实例端口：
   • 比如把本地1433端口转发到srvtest的实例1（默认端口1433）：

     netsh interface portproxy add v4tov4 listenport=1433 listenaddress=127.0.0.1 connectport=1433 connectaddress=srvtest
     

   • 把本地1434端口转发到srvtest的实例2（假设端口是1434）：

     netsh interface portproxy add v4tov4 listenport=1434 listenaddress=127.0.0.1 connectport=1434 connectaddress=srvtest
     

   之后程序的连接字符串里，production用1433端口，work用1434端口，就能分别连到srvtest的不同实例了。不过这个方法需要确保程序支持指定端口号。

方案3：本地DNS服务器（多机器测试场景） #

如果你的测试环境不止一台本地机器，想让多台机器都能把production/work指向srvtest的不同实例，可以在本地搭个轻量DNS服务器：

• 比如启用Windows自带的DNS服务，或者用第三方工具（比如Bind9）
• 在DNS服务器里给production和work添加A记录，指向srvtest的IP
• 再配合方案1的SQL Server别名，或者方案2的端口转发，来区分不同实例
  不过这个方案比较复杂，单机器测试的话完全没必要用前两个方案就够了。

几个注意点： #

• 用SQL Server别名时，一定要对应程序的位数（32/64位），不然程序可能识别不到别名
• 如果srvtest用的是SQL Server命名实例，强烈建议改成固定端口，动态端口会导致转发失效
• 测试前可以用telnet production 1433或者Test-NetConnection production -Port 1433来验证连接是否正常

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