Unix主机通过Nolio agent调用sqlcmd连接SQL Server超时问题

这个报错和SQL Server本身的远程连接配置、服务状态没有关系——毕竟你用PuTTY手动登服务器跑相同流程是正常的。问题100%出在Nexus触发Nolio agent执行时的运行上下文，和你PuTTY交互式登录的运行上下文不一致，导致sqlcmd连不上库，常见的具体诱因：

• 运行账号不一致：你PuTTY登录用的是个人域账号/本地管理员账号，本身有SQL Server登录权限、域认证权限、网络访问权限；但Nolio agent默认是作为系统服务运行的，用的可能是本地SYSTEM账号或者专门建的低权限服务账号，既没库权限，也可能没对应网络访问权限
• 网络配置不一致：你手动登录时加载的是自己用户会话下的代理配置、hosts映射、防火墙规则，很多公司内部的网络代理只给用户会话配，系统服务会话默认不走代理或者走不通，直接连SQL Server就会报0x2AF9的TCP错误，这个错误码本身就是目标地址无法解析、链路不通的典型标识
• 环境变量不一致：你手动登录时用户级的PATH里配了sqlcmd、ODBC驱动的路径，服务运行时加载的是系统级PATH，找不到对应依赖就会误报连接超时
• 脚本参数依赖上下文：比如你脚本里用Windows集成认证没写死账号密码，手动跑的时候用的是你自己的权限，服务跑的时候用服务账号的权限自然连不上；还有的人脚本里写的SQL地址是短名，依赖自己用户配的hosts映射，服务上下文下解析不到地址

按优先级从高到低查，不用绕弯：

• 先查Nolio agent的运行账号：登装了Nolio agent的服务器，开服务管理器找到Nolio agent服务，看「登录」标签页里配的运行账号是什么，和你PuTTY登录用的账号做对比，80%的情况都是这里的问题
• 直接在Nolio的运行上下文里复现问题：别用PuTTY的交互式会话测，用工具切到Nolio agent的服务账号身份开命令行，执行和工作流里完全一模一样的sqlcmd命令，能直接复现报错就说明确实是上下文问题，测试命令参考格式：
  sqlcmd -S <SQL Server地址\实例名> -U <登录名> -P <密码> -Q "select @@version"
  用集成认证的话就去掉-U、-P参数
• 测网络连通性：在刚才开的服务账号命令行里，先ping SQL Server地址看能不能正常解析IP，再telnet对应SQL端口（默认实例是1433，命名实例要查对应动态端口）看能不能通，再执行netsh winhttp show proxy看系统级代理配置，和你当前用户的代理配置对比，看是不是服务会话没配代理
• 查依赖是否正常：还是在服务账号的命令行里，执行where sqlcmd看能不能找到sqlcmd的路径，执行odbcinst -q -d看输出里有没有ODBC Driver 17 for SQL Server，确认驱动没丢

对应排查到的问题直接改就行：

• 账号问题：把Nolio agent服务的运行账号改成你手动执行时用的、有权限的账号，重启服务再重试就行
• 网络问题：如果是代理的问题，给系统级WinHTTP配上对应内部代理，把SQL Server地址加到绕过列表里，配置命令参考：
  netsh winhttp set proxy <代理地址:端口> "SQL Server地址段"
  如果是防火墙拦截，给Nolio agent服务账号放通到SQL Server对应端口的出站规则就行
• 环境变量问题：把sqlcmd、ODBC驱动的路径加到系统级PATH里，不要只配在当前用户的用户变量里
• 脚本参数问题：把SQL Server地址改成固定IP或者完整FQDN，显式带上端口（比如sqlsrv01.corp.com,1433），用集成认证的话就给Nolio服务账号开SQL Server的登录权限和对应脚本的执行权限，别依赖交互式用户的上下文

别浪费时间去改SQL Server侧的配置，PuTTY能跑通就证明库侧的远程连接、防火墙、权限配置全是正常的，所有排查都围绕Nolio agent的服务运行上下文做就行

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