需要固定安装目录或编译特定模块时，可以从源码构建 Nginx。相比包管理器安装，这种方式也意味着自己负责版本、依赖、服务配置和后续升级，编译完成只是第一步。
先记录构建条件
我最初使用过 1.6.2。这里说明源码构建的流程，实际部署应选择与目标环境适配、经过验证的发行版本，不把旧版本号当成安装建议。
下载对应源码并检查来源及校验信息。根据所选模块准备编译器、正则库、zlib 和 TLS 库的开发依赖，包名随发行版变化；不能把安装某个库的运行包当成已经具备编译头文件。
在解压后的源码目录中执行：
./configure --prefix=/opt/nginx --with-http_stub_status_module --with-http_realip_module --with-http_gzip_static_module --with-http_ssl_module
make
make install
./configure 指向当前目录脚本，不是 /configure。安装会写入指定目录，应先确认目标不是正在使用的另一套安装，并保留构建参数与依赖版本。
将二进制与运行配置对上
/opt/nginx/sbin/nginx -V
/opt/nginx/sbin/nginx -t -c /opt/nginx/conf/nginx.conf
-V 用于检查版本与编译参数，-t 检查配置语法和相关文件能否访问。确认日志、pid、临时目录与工作进程账户权限，再启动服务。
SysV init 与 systemd 的服务定义不同，应按当前发行版管理，避免同时存在两个服务管理入口却指向不同二进制。服务声明的 pid 路径也要与 Nginx 配置一致。
配置变化先验证再加载
语法通过后，可以用对应安装实例的 nginx -s reload 请求重载。已有进程仍需成功读取新配置；检查错误日志与新请求，而不是只看命令返回。
反向代理需要设置合适的 Host、连接及读取超时。real_ip 只信任明确的代理范围，状态页限制访问，静态目录只放可公开内容。生产配置应围绕业务路径写，不照搬一份包含私人目录和过宽网络范围的完整示例。
源码安装的升级还应验证动态模块、TLS 库与服务脚本兼容。保留旧二进制、配置和回退方式，能让升级风险更容易控制。