nginx配置修改后不生效，需排查五方面：1.确认修改的是nginx实际加载的配置文件；2.用nginx -t验证语法并检查路径权限；3.区分reload（平滑重载）与强制重启，避免旧worker延迟生效；4.检查端口是否被占用或存在残留进程；5.注意docker或systemd多实例导致的配置错位。
修改 Nginx 配置后不生效，不是配置写错了就完事，而是整个“修改→验证→加载→运行”链路上任何一个环节出问题，都会导致看似改了却没效果。下面这几个点，是 Linux 环境下最常踩的坑，按排查顺序列出来，直接对症操作。
确认改的是正在用的那个配置文件
很多人在服务器上存在多个 nginx.conf（比如 /etc/nginx/nginx.conf、/usr/local/nginx/conf/nginx.conf、甚至自己 copy 的备份），改完 A 文件，Nginx 却在读 B 文件，自然无效。
- 用 nginx -V 2>&1 | grep "configure arguments" 查看编译时指定的默认配置路径
- 或运行 ps aux | grep nginx，找到 master 进程启动命令，看它是否带 -c 参数指定了配置文件
- 也可以用 nginx -t -q -T（加 -T 会输出实际加载的全部配置内容），一眼看出它最终读的是哪份
语法检查和路径权限必须过两关
语法错一条，reload 就静默失败；目录或日志路径没创建、权限不对，Nginx 启动时可能降级运行或跳过部分配置，表面正常实则不生效。
- 每次改完先执行 nginx -t，确保返回 “syntax is ok” 和 “test is successful”
- 如果提示日志路径不存在（如 error_log /var/log/nginx/access.log），手动 mkdir -p /var/log/nginx && chown nginx:nginx /var/log/nginx
- 检查配置中所有涉及的目录（root、access_log、proxy_temp_path 等）是否真实存在、属主属组是否为 nginx 运行用户（通常是 nginx 或 www-data）
重载不等于重启，长连接会拖慢生效
nginx -s reload 是平滑重载：旧 worker 继续处理已有连接，新 worker 启动并接管新请求。但如果旧连接太多（尤其 keepalive 或大文件上传场景），你测的请求可能仍落在旧进程上，看起来“没变”。
- 执行 nginx -s reload 后，用 ps aux | grep nginx 看是否有带 “is shutting down” 字样的 worker 进程
- 观察几分钟，或直接用 killall nginx && systemctl start nginx（或 nginx）强制全量重启（生产环境慎用，但排查时最干脆）
- 也可临时加一句 log_format debug '$remote_addr – $request_time – $upstream_addr';，再查 access.log 确认新配置是否真正被新 worker 执行
端口冲突和多实例干扰不能忽略
有时候你以为 reload 成功了，其实新配置监听的端口被其他服务（比如另一个 nginx 实例、Apache、Node.js）占着，Nginx 自动 fallback 到旧监听或静默跳过。
- 用 ss -tlnp | grep ':80\|:443'（或 netstat -tulnp）确认目标端口确实由当前 nginx master 进程监听
- 检查是否有残留进程：ps aux | grep nginx | grep -v grep，若看到多个 master，说明之前没关干净，需 kill -9 $(cat /var/run/nginx.pid) 或 systemctl stop nginx && pkill -f nginx
- 特别注意 Docker 容器或 systemd 多实例场景——改的可能是宿主机配置，而服务跑在容器里
