推荐用 $cookie_session_id 等内置变量记录指定 cookie 字段，轻量高效；结合 $request_id 实现全链路追踪；多字段时优先内置变量，非标字段再用 if+正则提取；注意反向代理行为、日志体积、编码及敏感信息脱敏。
要在 Nginx 访问日志中记录 Cookie 或 Session ID 来追踪用户会话状态，核心是利用 Nginx 内置变量直接提取目标字段，而不是记录整条 Cookie 字符串——既轻量又利于后续分析。
用 $cookie_XXX 直接记录指定 Session ID
这是最推荐的方式。Nginx 在解析请求头时，会自动把 Cookie: session_id=abc123 映射为变量 $cookie_session_id，无需正则、不额外消耗 CPU。
- 变量名必须与 Cookie 名完全一致（大小写敏感），例如
Set-Cookie: JSESSIONID=7B8A9F2E对应$cookie_JSESSIONID - 未匹配时该变量值自动为
-，不会导致日志字段错位 - 在 log_format 中直接引用即可：
log_format session_log '$time_iso8601|$remote_addr|$request_method|$request_uri|$status|$cookie_session_id|'; - 启用日志：
access_log /var/log/nginx/session.log session_log;
结合 $request_id 实现全链路会话追踪
单靠 Session ID 只能识别“是谁”，但无法确认“一次操作涉及哪些服务”。要还原完整访问路径，需叠加唯一请求标识。
- 确保 log_format 包含
$request_id，例如：
log_format trace_log '$request_id|$time_iso8601|$remote_addr|$cookie_session_id|$request_method|$request_uri|'; - 在 server 块中启用，并确认下游服务透传
X-Request-ID头 - 当用户反馈异常时，用该 request_id 在 Nginx、API 网关、后端应用等各层日志中并行检索，快速定位问题环节
需要记录多个关键 Cookie 字段时
比如同时采集 uid、token 和 session_id，可混合使用内置变量和条件提取：
- 优先用
$cookie_uid、$cookie_session_id这类内置变量（稳定、高效） - 对没有标准命名的字段（如自定义
auth_token=xxx），再用 if + 正则提取：
set $cookie_token "-";
if ($http_cookie ~* "auth_token=([^;]+)") { set $cookie_token $1; } - log_format 中统一引用这些变量，保持字段对齐
注意事项与避坑点
实际配置中容易忽略几个关键细节：
- 反向代理场景下，
$http_cookie读的是客户端原始请求头，不受 upstream 是否清除 Cookie 影响；但$cookie_xxx同样只依赖请求头，不依赖响应头 - 日志体积会随 Cookie 字段增加而上升，高并发站点建议只对特定路径（如
/api/）启用带 Cookie 的日志格式 - 若 Cookie 值含中文或特殊符号，确保日志文件编码为 UTF-8，且日志分析工具支持解析
- 敏感字段（如 token、密码类 Cookie）不应明文落盘，生产环境建议仅记录脱敏后的前缀或哈希值
