最准的方法是结合 ps 和 /proc/PID/exe：先用 ps aux | grep nginx 找带 “master process” 的行，提取二进制路径；再用 pgrep -f 'nginx: master' 获取 PID，执行 ls -l /proc/PID/exe 验证真实路径。
直接看进程启动路径最准，ps 和 /proc/PID/exe 联用能绕过所有软链和别名干扰。
ps aux | grep nginx 显示的是真实启动命令
运行 ps aux | grep nginx，重点找带 master process 的那行。它后面跟的路径就是当前正在运行的 nginx 可执行文件位置，比如：
root 12345 0.0 0.3 123456 7890 ? Ss 10:20 0:01 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
这里 /usr/local/nginx/sbin/nginx 就是安装目录下的二进制文件路径，安装根目录就是它的上两级：/usr/local/nginx。
- 如果看到的是
/usr/sbin/nginx，说明大概率是 apt/yum 安装的，安装目录通常就是/usr（但实际没有“安装目录”概念，只认二进制路径） - 如果启动命令里带
-c参数，那个配置路径不一定和二进制同级，别默认去猜 - grep 结果里可能混着
grep nginx自身进程，注意 PID 不要选错
ll /proc/PID/exe 是硬核验证手段
先用 pgrep -f 'nginx: master' 拿到主进程 PID，再执行：
ls -l /proc/12345/exe
输出类似：lrwxrwxrwx 1 root root 0 Jul 8 12:00 /proc/12345/exe -> /usr/local/nginx/sbin/nginx。这个符号链接指向的路径不会被环境变量或 alias 干扰，是内核记录的真实路径。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 必须用
root或有/proc权限的用户执行，否则可能提示 Permission denied - 如果 nginx 是以非 root 用户启动（比如
www-data），而你用普通用户查/proc，很可能看不到exe链接 - 容器环境里这个路径可能指向镜像内的路径，不是宿主机真实路径
nginx -V 输出的 --prefix 才是源码编译时指定的安装前缀
运行 nginx -V，在输出末尾找 --prefix= 这一项，例如：
configure arguments: ... --prefix=/opt/nginx --sbin-path=/opt/nginx/bin/nginx ...
这个 --prefix 值是 configure 阶段定死的，但不等于当前实际运行路径——如果二进制被移动过，--prefix 就失效了。
- 包管理器安装（apt/yum）的 nginx 通常不带
--prefix，或者显示/usr，不能当真 - OpenResty 编译的 nginx 也会输出自己的
--prefix，比如/usr/local/openresty -
nginx -V输出很长，建议加| grep prefix快速定位
which nginx 和 whereis nginx 只能作辅助参考
which nginx 返回的是 PATH 中第一个匹配的可执行文件路径；whereis nginx 会列出二进制、配置、man 等常见位置，但这些全是静态索引，不反映当前运行态。
-
which nginx返回/usr/bin/nginx，但实际运行的可能是/opt/myapp/nginx/sbin/nginx（通过 systemd service 文件指定） -
whereis nginx显示/etc/nginx，这仅表示“默认配置目录”，线上很可能被软链到/data/config/nginx或完全 ignore - 这两个命令对容器、多版本共存、自定义 PATH 的场景基本无效
真正关键的永远是：当前运行的那个进程，它从哪加载的二进制，又用了哪个配置。其他方法都只是线索，ps + /proc/PID/exe 是唯一能穿透所有抽象层的组合。别信文档写的默认路径，也别信安装时的 --prefix，PID 不撒谎。
