Nginx容器中error_log /dev/stderr warn;不可见，根本原因是daemon模式导致子进程脱离标准流；必须添加-g "daemon off;"前台运行，并确保PID 1正确继承stdout/stderr，同时避免Python等连带进程缓冲干扰。
nginx 错误日志设为 error_log /dev/stderr warn; 后在容器里看不到，不是配置错了，而是 stdout/stderr 流被缓冲、截断或未持续输出导致的。关键在于确保 Nginx 进程以**前台模式运行**，且日志流能稳定抵达容器标准输出。
必须让 Nginx 前台运行
systemd 或容器中，Nginx 默认以 daemon 模式启动（即 fork 后主进程退出），此时子进程不继承标准流，journald 或 docker logs 就捕获不到 stderr 输出。
- 在容器中启动时，务必加
-g "daemon off;"参数，例如：nginx -g "daemon off; error_log /dev/stderr warn;" - 若用 Dockerfile，CMD 应写成：
CMD ["nginx", "-g", "daemon off; error_log /dev/stderr warn;"] - 避免 shell 封装脚本（如
sh -c "nginx &"），会切断 stdout/stderr 继承链
注意 Python 类应用的缓冲干扰（常见连带问题）
如果容器内同时跑 Python 脚本调用 Nginx 或生成日志（比如健康检查、配置热重载工具），Python 默认全缓冲会导致日志“卡住”，掩盖 Nginx 的真实输出状态。
- 启动时加环境变量：
PYTHONUNBUFFERED=1 - 或改启动命令为：
python -u your_script.py - 避免在同个容器里混用多进程且未统一控制输出流的行为
验证 stderr 是否真被容器捕获
别只信 docker logs，要分层确认：
- 进容器执行：
ls -l /proc/1/fd/{1,2}—— 查看 PID 1 的 stdout/stderr 是否指向pipe:或socket:（正常）；若指向/dev/null或已关闭，则流已被丢弃 - 临时测试：在 nginx.conf 中加一行
error_log /dev/stderr notice;，再手动触发一个配置错误（如加个非法指令），看是否立刻出现在docker logs - 用
journalctl -u docker --since "1 hour ago" | grep -i 'stderr\|nginx'查宿主机层是否有转发失败提示
替代方案：不依赖 /dev/stderr，改用日志驱动直采
如果仍不稳定，可绕过 Nginx 自身重定向，用 Docker 原生日志驱动接管：
- 启动容器时指定：
--log-driver=json-file --log-opt max-size=10m --log-opt max-file=3 - 配合 Nginx 写文件日志（保持默认
error_log /var/log/nginx/error.log），再用 Filebeat 或 ilogtail 采集该文件路径 - 优势：不依赖进程前台化，兼容性更强；缺点：多一层采集组件，实时性略低
