数据库审计日志默认记录的是连接发起方的socket远端地址，但该地址通常不是攻击者真实IP：应用直连时为应用服务器内网IP（如10.2.3.15），经HAProxy/Nginx等代理后可能变为代理地址甚至127.0.0.1；唯有应用层显式传入X-Forwarded-For并配合session_context或statement审计才能关联真实来源。
数据库审计日志本身不直接暴露攻击者真实IP，也不能单靠它锁定人——必须和Web层、网络层日志交叉比对，否则90%的溯源会误判为应用服务器或代理IP。
SQL Server audit_log 里 client_ip 是谁的 IP？
默认记录的是连接发起方的 socket 远端地址，但这个“远端”往往不是浏览器：
- 应用直连数据库时，
client_ip是应用服务器内网地址（如10.2.3.15），不是攻击者出口IP - 用了 HAProxy / Nginx stream / Always On Listener 时，
client_ip可能被覆盖成代理自身地址，甚至变成127.0.0.1 - 只有在应用层显式调用
sp_set_session_context或拼入/* req_id=abc123 */注释，并开启审计策略捕获statement字段，才能把 Nginx 的X-Forwarded-For关联进来
MySQL general_log 查不到新语句？先看这三个配置
开了 general_log 却查不到请求，大概率是下面三个地方没对齐：
-
log_output仍是'NONE'：必须执行SET GLOBAL log_output = 'TABLE';才写进mysql.general_log - 已有连接不会自动生效：
general_log开关只影响新建立的连接，需用新 session 复现请求 - 查日志卡死？
mysql.general_log默认是 CSV 引擎，无索引。别直接SELECT * FROM mysql.general_log WHERE argument LIKE '%union%'，改用带时间范围和正则的轻量查询：SELECT * FROM mysql.general_log WHERE event_time > NOW() - INTERVAL 5 MINUTE AND argument REGEXP "'[[:space:]]*union[[:space:]]+select|sleep\(|benchmark\("
PostgreSQL pg_audit 看不到真实参数值？
开完 pg_audit 只见 WHERE id = ?，payload 全是问号——这是默认配置故意脱敏的结果：
-
pgaudit.log_parameter = off（默认值）：必须手动设为on，否则所有绑定参数都隐藏 -
pgaudit.log_catalog = on（默认值）：会导致大量SELECT * FROM pg_class类系统表日志刷屏，业务语句被淹没。应设为off - 推荐最小化配置：
pgaudit.log = 'read, write, ddl'+pgaudit.log_parameter = on+pgaudit.log_catalog = off，改完重启 PostgreSQL 生效
真正难的不是打开审计，而是让每条 SQL 日志都能和 Nginx access_log 里的 $request_id、应用层打点里的 trace_id 对上时间戳和语句特征——NTP 偏差超过 500ms，三重对齐就失效；少传一个注释或漏配一个参数开关，整条链路就断在中间。
