nginx 本身不记录脚本执行堆栈，其 error_log 仅记录自身行为；php 堆栈需配置 php.ini 和 php-fpm 的 error_log；lua 堆栈需 lua_code_cache off 并设 error_log 级别为 notice；njs 堆栈简略，需 info 级别日志；worker 崩溃时需分析 core dump。
Nginx 本身不记录脚本执行的堆栈（比如 PHP、Lua 或 njs 中的函数调用链），它的 error_log 只记录 Nginx 进程自身行为：配置加载、信号接收、事件循环异常、上游连接失败、模块初始化报错等。所谓“脚本执行的堆栈”，实际来自后端服务（如 PHP-FPM、OpenResty 中的 Lua）或嵌入式引擎，Nginx 仅可能在错误日志中间接反映其崩溃结果，例如 recv() failed (104: Connection reset by peer) 或 upstream prematurely closed connection。
要真正看到脚本层的堆栈，需分场景处理：
看 PHP 脚本崩溃堆栈
PHP 的致命错误（如未定义函数、内存溢出、段错误）默认不会输出到 Nginx 日志。你需要：
- 在
php.ini中启用：display_errors = Off ; 生产环境应关闭 log_errors = On error_log = /var/log/php/error.log
- 确保 PHP-FPM 的
www.conf中设置了：catch_workers_output = yes php_admin_value[error_log] = /var/log/php/fpm-error.log
- 若 PHP 因 segfault 崩溃，系统会生成 core（需按前文配置 ulimit + core_pattern），再用
gdb php-fpm /path/to/core查bt full。
看 Lua 脚本（OpenResty / ngx_lua）堆栈
ngx_lua 模块会在发生 Lua 异常时，将带行号的错误信息直接写入 Nginx error_log（前提是 lua_code_cache off 开发时开启，且 error_log ... notice 或更高级别）：
2026/06/05 12:15:22 [error] 12345#0: *123 lua entry thread aborted: runtime error: /usr/local/openresty/nginx/lua/test.lua:5: attempt to index a nil value (local 'data')
stack traceback:
coroutine 0:
/usr/local/openresty/nginx/lua/test.lua:5: in function <usr></usr>
关键点：
- 必须使用
lua_code_cache off（否则编译后错误位置不准确） - 错误级别至少设为
notice：error_log /var/log/nginx/error.log notice; - 不要依赖
print()，要用ngx.log(ngx.ERR, ...)或让异常自然抛出
看 njs 脚本堆栈
njs 的错误堆栈较简洁，但也会出现在 error_log 中（需 error_log ... info 或更高）：
2026/06/05 12:16:01 [info] 12346#0: *456 njs exception: TypeError: Cannot read property 'length' of null at test.js:3
注意：njs 不支持完整 traceback，只报错文件、行号和顶层调用点。
当 Nginx worker 因脚本问题崩溃（SIGSEGV/SIGABRT）
这时你看到的是结果，不是原因：
- error_log 中出现：
worker process XXX exited on signal 11 - 配合已启用的 core dump，用
gdb nginx /var/log/nginx/core.nginx.PID.TS→bt full - 结合
info sharedlibrary和p $_siginfo._sifields._sigfault.si_addr判断是否踩到 Lua/njs 分配的非法内存
Nginx 日志里没有真正的“脚本执行堆栈”，它只是信使。真实堆栈藏在 PHP 错误日志、Lua 异常输出、njs 报错行，或崩溃后的 core 文件里。
