我翻过三台服务器才找到那个nginx.conf，问题不在文件藏得深，是我一开始就找错了方向。find / -name nginx.conf 这命令敲下去，输出能刷满整个屏幕，但全是Permission denied。真正该用的命令是 sudo find / -name nginx.conf 2>/dev/null，把错误信息丢掉，剩下的才是能看的。

当然，find不是唯一的路子。生产环境里我习惯先查进程，ps aux | grep nginx 比什么都直接。master process那行会告诉你nginx的安装路径，比如 /usr/sbin/nginx，然后顺着 -c 参数或者编译时的默认路径就能摸到配置文件。有一次我遇到个奇葩情况，nginx跑在容器里，宿主机上ps根本看不到，得先 docker ps 找到容器ID，再进容器里查。

还有个更快的办法，用 nginx -t 这个命令本身就是个调试利器。它会直接告诉你配置文件在哪，还会报错——比如哪一行语法有问题。我第一次用的时候吓了一跳，以为服务挂了，其实只是测试配置，不影响运行中的进程。这命令配合 -T 参数（大写T）能直接把整个配置打印到终端，省得你到处找文件。

说到路径，不同发行版差异挺大。CentOS上编译安装的nginx通常在 /usr/local/nginx/conf/，Ubuntu的apt包则把配置散在 /etc/nginx/ 下，包含关系靠 include 指令串联。你要是用yum装过EPEL源里的nginx，路径又不一样。所以我现在的习惯是，拿到一台陌生机器，先执行 nginx -V 看编译参数，--prefix后面的路径就是一切文件的根。

最后提个野路子。有时候你连nginx装没装都不确定，那就 which nginx 或者 whereis nginx 先探探路。如果命令不存在，但端口80在监听，那大概率是别的web服务，比如Apache或者某个Java应用。别在一棵树上吊死，查端口占用 netstat -tlnp | grep :80 能帮你快速锁定真凶。

说到底，查找nginx不是目的，定位配置才是。我踩过的坑是光找到可执行文件就收工，结果改错了conf，服务重启后行为完全没变。真正的配置路径，还得靠 nginx -t 的输出确认，它说 /etc/nginx/nginx.conf 是哪个就是哪个，别自己猜。