启用 buffer 和 flush 参数可将日志写入从“每请求一写”改为“攒够再写”，降低 I/O 压力；需配合使用，推荐 buffer=32k–64k、flush=1s–5s，并配合 SSD 挂载与系统优化。
直接在 access_log 指令中加上 buffer 和 flush 参数，就能让日志写入从“每请求一写”变成“攒够再写”，显著降低磁盘 I/O 压力和 worker 进程阻塞风险。
buffer 和 flush 必须一起用
只设 buffer=64k 不设 flush，日志可能长时间卡在内存里，Nginx 仅在缓冲区满、reload 或进程退出时才落盘——这在生产环境极不安全。
-
buffer=32k或64k：每个 worker 进程为该日志分配对应大小的内存缓冲区，日志先暂存于此 -
flush=1s、3s或5s：从上次刷盘开始计时，超时即强制刷出（即使没填满） - 正确写法示例：
access_log /var/log/nginx/access.log main buffer=64k flush=3s;
参数值怎么选才合理
不是越大越好，得看业务对延迟、丢志风险和内存开销的容忍度。
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
-
buffer 推荐 32k–64k：32KB 覆盖多数中高并发场景；64KB 更适合含长字段（如完整
$http_user_agent或$request_body）的日志 - 避免 buffer > 128k：宕机时可能丢失数秒甚至十几秒日志
-
flush 推荐 1s–5s：监控敏感接口用
1s，通用服务用3s或5s；不建议设成 30s 或更长，排查窗口会严重滞后
配套动作不能少
光改 Nginx 配置不够，系统层也要配合，否则缓冲效果打折扣。
- 把
/var/log/nginx/单独挂载到 SSD 或 NVMe，并加noatime（ext4）或nobarrier（XFS） - 关闭 rsyslog 或 journald 对 access.log 的实时 tail 监控，防止多进程争抢文件句柄
-
error_log不支持buffer/flush，若输出频繁（如 debug 级别），应调高日志级别或转 syslog 处理
特殊路径可单独配置
对长耗时导出类请求（如报表下载、大文件流式响应），默认机制可能延迟刷盘。可在对应 location 中单独设置更激进的缓冲策略：
- 例如：
location ^~ /export/ { access_log /var/log/nginx/export.log main buffer=8k flush=1s; } - 小 buffer + 短 flush，确保日志在秒级内可见，又不影响全局性能
