sql server触发器中唯一稳定获取tcp层客户端ip的方式是立即调用connectionproperty('client_net_address')，延迟赋值可能返回null；需用varchar(48)存储、校验'::1'/'127.0.0.1'等本地地址，并在代理场景下由应用层传入真实ip。
SQL Server触发器里用CONNECTIONPROPERTY('client_net_address')取IP
这是唯一能稳定拿到 TCP 层客户端 IP 的方式，但必须在触发器内**立即读取**，不能延迟或缓存到变量后再用——因为会话上下文只在当前执行帧有效。
常见错误是写成这样：DECLARE @ip VARCHAR(48); SET @ip = CONNECTIONPROPERTY('client_net_address'); 看似没问题，但实际可能返回 NULL，尤其在并行执行或某些连接池场景下。正确做法是直接赋值并校验：
DECLARE @ip VARCHAR(48) = ISNULL(CONVERT(VARCHAR(48), CONNECTIONPROPERTY('client_net_address')), 'unknown');- 如果结果为
'::1'、'127.0.0.1'或'<local machine>'</local>，说明是本地连接（比如 SSMS 在数据库服务器本机运行） - 返回空字符串或 NULL，大概率是连接经过了代理、负载均衡器，或使用了 Windows 身份验证 + Kerberos 委派（此时 client_net_address 不可用）
为什么HOST_NAME()和USER()不能替代 client_net_address
HOST_NAME() 返回的是客户端机器名，不是 IP，且可被任意伪造（应用层调用 SET HOST_NAME('fake') 就能改）；USER() 或 SUSER_SNAME() 只返回登录账号信息，和网络来源完全无关。
真实场景中容易踩坑的点：
- 在 .NET 应用里用
SqlConnection连接池时，client_net_address显示的是应用服务器地址，不是浏览器终端 IP —— 这是设计使然，不是 bug - Always On 可读副本上执行触发器，该函数仍返回原始连接发起方 IP，不会变成副本节点地址
- contained database 中若用户无登录映射，
CONNECTIONPROPERTY可能返回 NULL，需提前测试
触发器记录 IP 时必须处理的边界情况
直接把 CONNECTIONPROPERTY('client_net_address') 插入日志表看似简单，但生产环境必须加防护：
- IPv6 地址最长可达 45 字符（如
'2001:db8::1'），字段类型至少用VARCHAR(48)，别用CHAR(15)截断 - 如果业务允许 localhost 连接，要显式接受
'::1'和'127.0.0.1'，否则会被当成非法值 - 在登录触发器（
ON ALL SERVER FOR LOGON）里用这个函数没问题；但在 DML 触发器里，若事务被回滚，IP 记录也跟着消失 —— 所以关键审计日志建议走异步写入或 Service Broker - 不要在触发器里做 DNS 反查（比如
SELECT HOST_NAME() FROM sys.dm_exec_connections），性能差且不可靠
代理或中间层导致 client_net_address 失效怎么办
当流量经过 HAProxy、Azure App Gateway、RDS Proxy 或任何四层代理时，client_net_address 必然变成代理内网 IP。此时 SQL Server 本身无解，必须由应用层补全：
- Web 应用在构造 SQL 时，把解析后的
X-Forwarded-For（经可信代理链校验后）作为参数传入，例如：INSERT INTO audit_log (op, client_ip) VALUES ('UPDATE', @real_ip) - 数据库连接字符串里加
Application Name=web-api-v2，配合sys.dm_exec_sessions关联查来源，虽不能精确定位终端，但能区分服务模块 - 如果用 Entity Framework，可在
SaveChanges前统一注入 IP 到变更实体的client_ip字段，再由触发器引用NEW.client_ip
真正难处理的不是技术实现，而是信任链：你永远得决定「信谁」——信代理头？信连接池配置？还是信应用层自己填的字段。一旦选错，日志就失去审计价值。
