关键在确认configure是否真正成功：检查exit code 0、搜索config.log中“not found”等线索，并核对summary中模块是否enabled，而非仅看终端输出。
排查 Nginx 源码编译过程中的疑难问题，关键不在“看编译输出”，而在于定位 configure 阶段是否真正完成、以及 config.log 是否记录了被忽略的失败细节。很多报错看似是 make 失败，实则是 configure 已悄悄跳过关键检查，导致后续链接或编译直接崩。
先确认 configure 脚本有没有真正跑通
configure 执行完后，不要只看最后几行有没有 “configuration summary”——那只是表面成功。重点检查三件事：
- 终端最后一行是否为 exit code 0（可用
echo $?立即验证）； - 输出中是否有 “checking for … not found” 或 “WARNING: using system PCRE” 类提示，这类不是错误但可能埋雷；
- summary 中你依赖的模块（如
http_ssl_module、http_v2_module）是否显示为 enabled，而非 disabled 或压根没出现。
核心线索在 config.log，不是屏幕输出
configure 不会把所有检测过程打印出来，它把每一条探测命令（比如 gcc -o conftest conftest.c）的完整执行环境、返回码、stderr 全记在当前目录的 config.log 里。这是唯一能查到“为什么 OpenSSL 没被识别”的地方。
- 用
grep -n "OpenSSL" config.log快速定位检测段落； - 找含 “not found”、“failed”、“exit 1” 的行，往前翻 10～20 行看具体命令和报错上下文；
- 若看到
conftest.c:1:10: fatal error: openssl/ssl.h: No such file or directory，说明缺的是openssl-devel，不是openssl运行包。
make 报错时别急着改源码，先看它在编译哪个文件
make 失败的典型提示如：cc1: error: unrecognized command line option '-m64' 或 undefined reference to 'PCRE2_32_match'。这些往往暴露的是 configure 阶段的遗留问题：
-
-m64类错误：说明 configure 检测到的是 32 位工具链，但你在 64 位系统上编译，需检查CC环境变量或显式传--with-cc-opt="-m64"； - undefined reference：大概率是 configure 找到了旧版库（比如系统自带 pcre2-10.20），但头文件和库文件版本不匹配，应统一指定路径，例如
--with-pcre=/opt/pcre2 --with-pcre-opt="-I/opt/pcre2/include -L/opt/pcre2/lib"； - 如果报错指向第三方模块（如
ngx_http_lua_module），先确认该模块源码目录存在、且路径是相对于 configure 脚本所在位置的相对路径。
绕过缓存，强制重跑关键步骤
configure 和 make 默认会复用中间产物，有时改了参数却没生效，是因为缓存没清：
- 删掉整个
objs/目录再make； - 删掉
Makefile和objs/后，重新运行./configure ...； - 不想全删？可加
--no-cache参数（部分旧版不支持），或手动清除config.cache（如果存在）。
