源码编译Nginx的第一步就是运行configure脚本。这个脚本会检测系统环境、确认依赖库位置，并根据你传入的参数生成Makefile和ngx_auto_config.h头文件。很多人习惯直接./configure然后make，但其实默认参数往往不是最佳选择——它可能编入你根本用不到的模块，也可能漏掉HTTPS、HTTP/2等关键能力。理解configure参数的意义，是定制精简、安全、高性能Nginx的前提。
路径、用户与基础配置参数
最常用的三个参数是--prefix、--sbin-path和--conf-path。--prefix指定安装根目录，默认是/usr/local/nginx，所有其他相对路径都会基于这个前缀。如果你希望把Nginx安装在/opt/nginx下，就写成--prefix=/opt/nginx。--sbin-path指定nginx可执行文件位置，默认是
用户和组相关的参数--user与--group也很关键。默认情况下Nginx以nobody用户运行，但nobody权限过低可能导致无法读取证书或访问某些目录。建议创建一个专用系统用户，例如--user=www --group=www。注意这里指定的是运行Nginx worker进程的用户，master进程仍然以root启动（如果监听80端口则需要root权限）。如果希望master进程也降权，可以使用--user同时影响所有进程，但需要确保日志目录和pid文件可写。
还有一组容易被忽略的参数：--pid-path、--error-log-path和--http-log-path。--pid-path指定存放master进程ID的文件路径，默认是
核心HTTP模块的启用与裁剪
Nginx的模块分为默认编译和需显式启用两类。默认不会编译的模块通常用--with-前缀开启，例如--with-http_ssl_module、--with-http_v2_module、--with-http_realip_module。其中--with-http_ssl_module几乎已是生产必备，它依赖于OpenSSL库。如果OpenSSL安装在非标准路径，需要通过--with-openssl=路径来指定源码目录，Nginx会静态编译OpenSSL，或配合--with-openssl-opt传递额外编译选项。
--with-http_v2_module启用HTTP/2协议支持，需要与SSL模块同时使用。--with-http_gzip_static_module允许发送预压缩的.gz文件，对于静态资源服务能显著降低CPU消耗。--with-http_stub_status_module提供简单的状态页，方便监控连接数、请求数等指标。如果你需要做反向代理，--with-http_proxy_module是默认启用的，但--with-http_upstream_hash_module、--with-http_upstream_least_conn_module等负载均衡算法模块需要手动添加。
与启用相对的是一系列--without-开头的参数。默认会编译一些你可能不用的模块，比如--without-http_autoindex_module可以禁用目录列表功能，减少信息泄露风险；--without-http_ssi_module禁用服务端包含，避免潜在的安全问题；--without-http_userid_module移除用户跟踪功能。裁剪模块的好处不仅是减小二进制体积，更重要的是缩小攻击面——每个被移除的模块都意味着少一块可能的漏洞入口。
动态模块与第三方模块集成
从Nginx 1.9.11开始，官方引入了动态模块机制。通过--with-compat参数可以让编译出的动态模块在不同Nginx版本间兼容，而--add-dynamic-module=路径可以将第三方模块编译成.so文件，例如--add-dynamic-module=../nginx-rtmp-module。动态模块的好处是灵活性高，可以在运行时通过load_module指令加载，不需要重新编译整个Nginx。但要注意，动态模块的加载时机较早，某些需要patch核心代码的模块只能静态编译。
静态编译第三方模块使用--add-module=路径。这种方式把模块直接并入nginx二进制，启动时无需额外加载，但每次升级Nginx都必须重新编译。一个常见的例子是--add-module=../ngx_http_geoip2_module，用于基于地理位置做访问控制。在选择静态还是动态时，可以这样判断：如果模块需要修改Nginx核心结构体，或者必须影响全局初始化流程，就应静态编译；如果模块功能独立、更新频率较高，则动态模块更合适。
编译第三方模块时经常会遇到兼容性问题。不同Nginx版本之间的内部API可能变化，导致模块源码无法编译通过。解决办法通常是查看模块仓库的README确认支持的Nginx版本范围，或者使用模块作者提供的补丁。另外，有些第三方模块需要额外的系统库，例如GeoIP2需要libmaxminddb，编译前必须确保这些库的开发头文件已安装，否则configure阶段就会报错。
一个精简生产环境编译示例
下面给出一个适用于反向代理+静态文件服务的编译命令示例，并解释每个参数的选择理由。
./configure \ --prefix=/opt/nginx \ --sbin-path=/opt/nginx/sbin/nginx \ --conf-path=/etc/nginx/nginx.conf \ --pid-path=/var/run/nginx.pid \ --error-log-path=/var/log/nginx/error.log \ --http-log-path=/var/log/nginx/access.log \ --user=www --group=www \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_gzip_static_module \ --with-http_stub_status_module \ --with-http_realip_module \ --with-http_proxy_module \ --without-http_autoindex_module \ --without-http_ssi_module \ --without-http_userid_module \ --with-pcre=/usr/local/src/pcre-8.45 \ --with-openssl=/usr/local/src/openssl-1.1.1w
这里指定了独立的日志目录和pid路径，便于集中管理和权限控制。用户设为www，避免使用默认nobody。启用SSL和HTTP/2满足HTTPS需求，gzip_static降低压缩开销，stub_status提供监控端点，realip用于获取真实客户端IP。裁掉了autoindex、SSI和userid三个不常用模块。PCRE和OpenSSL采用源码静态编译，这样即使系统库版本较旧，Nginx也能使用指定版本的功能。在运行make之前，建议先用nginx -V确认configure参数已经正确记录。
编译完成后可以通过安装目录下的sbin/nginx -V查看完整的编译参数列表。这个命令输出的内容不仅包含你显式传入的参数，还包含默认启用的模块和第三方模块信息。对于安全审计来说，定期检查nginx -V的输出是一个好习惯——它可以帮助你确认生产版本中没有意外编入不安全的模块，也方便在出现安全漏洞时快速判断是否受影响。
Nginx源码编译configure参数编译优化修改时间：2026-08-21 11:28:48