access_log 中 flush=时间值需配合 buffer 使用，如 buffer=64k flush=5s；仅对 access_log 生效，须 reload 生效，推荐 buffer=32k–64k 且 flush≤2s 以平衡延迟与可靠性。

直接在 access_log 指令中加上 flush=时间值 即可设定缓冲区最长驻留时间，比如 flush=1s 表示最多等 1 秒就强制落盘。这个参数必须配合 buffer 使用，单独设置无效。

flush 参数的生效前提

它不是独立开关，依赖 buffer 存在才能起作用：

• 必须先配置 buffer=大小（如 buffer=64k），否则 flush 被忽略
• log_format 必须在 access_log 之前定义好
• 仅对 access_log 生效，error_log 不支持该参数

常见 flush 时间值选择建议

按业务场景权衡延迟容忍度和可靠性：

Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)

使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。

下载

• 1s～2s：适合安全监控、实时告警类场景，日志基本秒级可见，宕机最多丢 1–2 秒数据
• 5s：通用推荐值，多数业务能接受这个延迟，I/O 压力明显下降，断电丢失风险可控
• 10s 或更长：仅适用于日志量极大、磁盘较慢或离线分析为主的系统，但故障时可能丢失整段窗口日志

实际配置与验证要点

写法要规范，生效需 reload：

• 正确示例：access_log /var/log/nginx/access.log main buffer=64k flush=5s;
• 时间单位只能是 s（秒），不支持 ms 或 m
• 每个 worker 进程独享一份缓冲区，总内存占用 = worker_processes × buffer_size
• 修改后执行 nginx -s reload 生效，无需重启进程
• 可用 strace -p $(pgrep nginx) -e write 观察实际刷盘频率，验证是否按预期触发

避免典型误配导致延迟失控

大 buffer + 长 flush 是高危组合：

• 比如 buffer=128k flush=30s，低流量时可能几十秒才凑满缓冲，日志“卡住”不落盘
• 攻击行为或异常请求发生后，无法及时进入 SIEM 或日志平台，错过响应窗口
• 推荐搭配：buffer 控制在 32k–64k，flush ≤ 2s（尤其安全敏感场景），小缓存+短时限更可控