SQL Server触发器中获取真实客户端IP唯一可靠方式是直接调用CONNECTIONPROPERTY('client_net_address')，该函数返回当前会话TCP层源地址，支持IPv4/IPv6，无需额外权限，且在Always On等场景下仍准确反映原始连接IP。
SQL Server触发器里怎么拿到真实客户端IP
直接用 CONNECTIONPROPERTY('client_net_address')，这是唯一可靠的方式。其他函数如 HOST_NAME() 或 @@REMOTEADDR 要么返回主机名、要么在某些版本中已弃用或行为不稳定。
关键点在于：该函数必须在触发器内「立即执行」，不能延迟或封装进视图/UDF；它返回的是当前会话建立时的 TCP 层源地址，不受故障转移影响，但会反映连接池或代理层地址（比如应用服务器 IP）。
-
CONNECTIONPROPERTY('client_net_address')返回VARCHAR(48)，IPv6 地址也支持 - 若结果为
::1或127.0.0.1，说明是本地连接（如 SSMS 本机直连），不是远程客户端 - 在 Always On 可读副本上执行触发器时，该值仍为原始发起连接的 IP，不会变成副本节点地址
- 不需要额外权限，但触发器执行者需有对目标表的 DML 权限即可
为什么不能用 sys.dm_exec_connections 子查询
看起来直观，但触发器中直接写 SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id = @@SPID 会失败——尤其在 SQL Server 2019 及之后，默认启用参数化计划缓存时，该查询可能被判定为“非确定性引用”，导致触发器编译报错或运行时拒绝执行。
更实际的问题是：这个 DMV 在某些高并发场景下存在极短窗口的竞态，虽然概率低，但日志类触发器对一致性要求高，不建议冒险。
- 推荐只用
CONNECTIONPROPERTY()，它是标量函数，无执行计划干扰 - 如果非要查 DMV，必须包装成
SECURITY DEFINER的标量函数再调用，徒增复杂度且无收益 -
@@REMOTEADDR在 SQL Server 2022 中已被标记为“过时”，文档明确建议迁移到CONNECTIONPROPERTY
触发器里记录 IP 的典型写法
不要依赖临时变量缓存、不要做多余判断，直接取值插入日志表。下面这段是生产环境验证过的最小可行模式：
CREATE TRIGGER tr_log_update ON Orders AFTER UPDATE AS
BEGIN
SET NOCOUNT ON;
DECLARE @ip VARCHAR(48) = CONNECTIONPROPERTY('client_net_address');
DECLARE @login NVARCHAR(128) = SUSER_SNAME();
DECLARE @dt DATETIME2 = SYSDATETIME();
INSERT INTO OrderChangeLog (OrderID, OldTotal, NewTotal, ClientIP, LoginName, ChangeTime)
SELECT
i.OrderID,
d.TotalAmount,
i.TotalAmount,
@ip,
@login,
@dt
FROM inserted i
INNER JOIN deleted d ON i.OrderID = d.OrderID;
END
- 所有变量赋值放在
BEGIN后第一块，避免后续逻辑影响上下文 - 不用
ISNULL(@ip, 'unknown')——CONNECTIONPROPERTY在正常 TCP 连接下绝不会返回 NULL，加判断反而掩盖配置问题（如强制使用 shared memory 协议） - 别在触发器里调用
APP_NAME()或HOST_NAME()做辅助验证，它们和 IP 不是一致来源，容易引发误判
绕不过去的中间层问题
如果你的应用走 Nginx / IIS / .NET Connection Pool / pgbouncer 类中间件，CONNECTIONPROPERTY('client_net_address') 拿到的一定是那个中间件的出口 IP，不是最终用户浏览器或手机的真实 IP。
这时候没有数据库侧的银弹方案。必须由应用层把原始 REMOTE_ADDR 或 X-Forwarded-For 头解析后，作为显式字段传入 SQL（例如 INSERT INTO ... (..., client_ip) VALUES (..., '203.0.113.42')）。
试图在触发器里解析 CONTEXT_INFO 或 SESSION_CONTEXT 来补救，需要应用每次请求前主动设置，维护成本高且易遗漏——不如一开始就约定好字段契约。
