Nginx与Node.js端口冲突需先定位占用者：若Nginx启动失败（如bind 80失败），用sudo lsof -i :80查占用进程；若Node报EADDRINUSE，则查对应端口（如3000）；根据场景选择停冲突进程或修改Nginx listen端口及proxy_pass指向。
Nginx 和 Node.js 通常配合使用（比如 Nginx 做反向代理，Node.js 做后端服务），但两者若共用同一端口（如都试图监听 80 或 3000），或配置不当导致端口冲突，就会引发启动失败。排查重点不是“Nginx 中部署 Node.js”本身占用了端口，而是两个服务是否在无意中竞争同一端口，或Nginx 反向代理指向的 Node.js 端口实际未就绪/被占。
下面分场景说明如何快速定位和解决：
确认 Nginx 和 Node.js 各自监听的端口
Nginx 默认监听 80/443，Node.js 默认常监听 3000、5000、8080 等。必须明确： - Nginx 的 `listen` 指令在哪（如 `/etc/nginx/sites-enabled/default` 中 `listen 80;`） - Node.js 应用实际绑定的端口（看 `app.listen(3000)` 或 `process.env.PORT` 值） - Nginx 的 `proxy_pass` 是否指向了该 Node.js 端口（如 `proxy_pass http://127.0.0.1:3000;`）如果 proxy_pass 指向的端口（比如 3000）被其他进程占着，Node.js 就起不来，Nginx 虽然自身能启，但反向代理会返回 502；如果 Nginx 自己的监听端口（如 80）被占，Nginx 直接启动失败并报 Address already in use。
查清到底是哪个服务的端口被占了
根据报错来源决定查哪边： - 若 `systemctl start nginx` 失败，日志含 `bind() to 0.0.0.0:80 failed` → 查 Nginx 监听端口（如 80、443） - 若 `node server.js` 报 `EADDRINUSE` → 查 Node.js 绑定端口（如 3000） - 使用对应命令精准定位：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 查 80 端口谁在用：sudo ss -tuln | grep ':80'（推荐）或 sudo lsof -i :80
- 查 3000 端口谁在用：lsof -i :3000（Linux/macOS）或 netstat -ano | findstr :3000（Windows）
- 确认 Node.js 进程是否残留：ps aux | grep node，留意重复的 `node server.js` 或 `nodemon`
区分处理：是停掉冲突进程，还是改配置绕开
- 如果占用者是不需要的服务（如测试时留下的另一个 Node 实例、Apache、旧 nginx）：- 杀掉它：kill -9 [PID]（Linux/macOS）或 taskkill /PID [PID] /F（Windows）
- 再验证端口空闲：ss -tuln | grep ':3000' 应无输出
- Nginx 改监听端口（如 `listen 8080;`），同时配好防火墙放行
- Node.js 改监听端口（如 `app.listen(process.env.PORT || 4000)`），再同步更新 Nginx 的 `proxy_pass http://127.0.0.1:4000;`
检查 Nginx 与 Node.js 的协作状态
即使各自端口不冲突，仍可能因衔接问题“看似启动失败”： - 启动 Node.js 后，手动访问 curl http://127.0.0.1:3000，确认服务真正在响应 - 启动 Nginx 后，访问 curl http://127.0.0.1（或你的域名），看是否返回 Node.js 内容 - 若返回 502 Bad Gateway，大概率是 `proxy_pass` 地址/端口写错、Node.js 没起来、或 Node.js 绑定了 `127.0.0.1` 但 Nginx 尝试连 `localhost`（DNS 解析差异），建议统一用 `127.0.0.1:3000`不复杂但容易忽略
