查看nginx版本命令

敲下 nginx -v，版本命终端返回 nginx version: nginx/1.24.0。版本命这是版本命最直接的方式，没有多余信息，版本命就一行版本号。版本命如果你手头是版本命 Ubuntu 或 Debian，大概率看到的版本命是 nginx/1.18.0 (Ubuntu) 这种带发行版标记的格式。别小看这个后缀，版本命它意味着 Canonical 或 Debian 维护者打过补丁，版本命版本号和上游原版可能对不上。版本命

另一个常用命令是版本命 nginx -V，注意是版本命大写 V。输出就长多了，版本命第一行仍然是版本命版本号，但后面跟着一堆编译参数。版本命比如 --with-http_ssl_module、--with-http_v2_module、--prefix=/etc/nginx 之类的。这些参数决定了你的 nginx 到底支持哪些功能。我见过有人折腾半天 HTTP/2 不生效，最后发现编译时压根没加 --with-http_v2_module。所以 -V 不只是看版本，更是看能力清单。

有时候 nginx 二进制文件不在 PATH 里，或者你用的是自定义编译安装。那就得用绝对路径，比如 /usr/local/nginx/sbin/nginx -v。还有一种情况：nginx 正在运行，但你不确定它用的是哪个二进制文件。可以 ps aux | grep nginx 找到 master 进程的路径，再执行那个路径加 -v。这招在排查“明明改了配置重启却没生效”时特别管用——你改的配置文件和实际运行的 nginx 可能不是同一个。

容器环境又是另一回事。Docker 里跑 nginx，直接 docker exec <容器名> nginx -v 就行。但如果你用的是 nginx:alpine 镜像，返回的版本号可能和 nginx:latest 不一样。Alpine 版本通常更新更勤快，但底层库是 musl libc，某些第三方模块编译起来会报错。我个人的习惯是，生产环境固定用具体版本标签，比如 nginx:1.24.0，别用 latest。不然哪天自动拉取新镜像，版本悄悄变了，配置不兼容就麻烦了。

还有一种偏门情况：nginx 已经编译安装但还没启动，你想确认版本。直接运行 nginx -v 可能会报错说找不到 pid 文件或者权限不足。其实 -v 只是打印版本然后退出，不加载配置。但如果你用的是 sudo nginx -v，而 nginx 配置里 user 指令指定了其他用户，它仍然会尝试读取配置。更干净的做法是 nginx -v 2>&1，把 stderr 重定向到 stdout，避免一些奇怪的输出干扰。

Windows 上呢？打开 cmd，进入 nginx 解压目录，运行 nginx.exe -v。注意不是 nginx -v，Windows 不认那个不带扩展名的。返回类似 nginx version: nginx/1.25.3。但 Windows 版 nginx 的编译参数和 Linux 差别很大，-V 输出里经常看到 --with-cc=cl 这种 MSVC 编译器选项。如果你在 Windows 上做开发，Linux 上做部署，别假设两边行为一致。我遇到过 try_files 在 Windows 下路径分隔符处理不同导致的 404。

版本号本身也有讲究。nginx 的奇数版本是开发版，偶数版本是稳定版。1.25.x 是开发分支，1.24.x 是稳定分支。但 nginx 官方现在把“稳定版”定义为“不增加新功能，只修 bug”，而“开发版”其实也相当可靠。很多生产环境跑的就是开发版，因为有些新特性只在开发版里。不过你要是保守派，就盯住偶数版本号。另外 1.24.0 和 1.24.1 之间可能只差一个安全补丁，但 nginx -v 只显示主版本号，不显示补丁级别。想看完整版本得用 nginx -V 的第一行，或者 nginx -v 在某些发行版上会输出 nginx/1.24.0 不带补丁号——这时候得查包管理器，比如 dpkg -l | grep nginx 或 rpm -qa | grep nginx。

最后提一个容易踩的坑：如果你同时装了系统包管理器的 nginx 和手动编译的 nginx，which nginx 返回的路径可能不是你正在运行的那个。用 readlink -f $(which nginx) 看真实路径，再配合 ps 确认。我见过一台服务器上跑了三个不同版本的 nginx，分别监听不同端口，结果运维改配置改错了文件。所以查看版本之前，先搞清楚你要查的是哪一个 nginx。