Python后端启动失败常因端口被占，需用ss/lsof确认监听状态与进程，核对uWSGI/Gunicorn配置，验证Nginx能否curl/telnet直连，并检查systemd服务状态及日志。
Python 后端服务（如 uWSGI、Gunicorn）启动失败，常因端口被占用，而 Nginx 作为反向代理又依赖该后端端口，导致整体服务不可用。排查需聚焦“后端监听端口”本身是否空闲、是否可访问、是否配置一致。
确认后端实际监听的端口和地址
不要只看 Python 启动命令里写的端口——得验证它是否真在监听、监听在哪。
- 查端口状态：
sudo ss -tlnp | grep ':8000'（把8000换成你配置的后端端口） - 若无输出，说明后端根本没成功监听；若有输出，注意第二列是
0.0.0.0:8000还是127.0.0.1:8000——Nginx 在本机反向代理时，两者都可连；但若配置成127.0.0.1，则不能用公网 IP 访问该端口 - 对比你的部署配置：uWSGI 的
http-socket或socket参数、Gunicorn 的bind参数，确保和ss输出一致
检查是否有其他进程抢占了后端端口
常见干扰源包括：残留的旧进程、调试时手动启动的临时服务、其他 Python 应用、甚至 Node.js 或 Flask 自带服务器。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 执行
sudo lsof -i :8000或sudo netstat -tulnp | grep ':8000'，直接看到 PID 和进程名 - 若 PID 对应的是
python但不是你的应用（比如是python -m http.server），可安全终止：sudo kill -9 PID - 若不确定能否杀，先用
ps aux | grep PID看完整命令行，再决定
验证 Nginx 能否连通后端端口
即使后端监听了，Nginx 也可能因网络或权限原因连不上——这会表现为 502 错误，但根源仍是端口层问题。
立即学习“Python免费学习笔记（深入）”；
- 在 Nginx 所在服务器上执行：
curl -v http://127.0.0.1:8000/health（替换为你的健康检查路径） - 如果返回
Connection refused，说明后端没起来或监听地址不对；如果超时或无响应，可能是防火墙拦截或后端卡死 - 用
telnet 127.0.0.1 8000测试 TCP 连通性（若未安装 telnet，可用nc -zv 127.0.0.1 8000）
检查 systemd 服务与配置是否冲突
用 systemd 管理 Python 服务时，容易因多次 reload、failed 状态残留或配置未生效，导致端口未释放或重复启动。
- 运行
systemctl status your-app.service，看是否处于active (running)还是failed或activating (auto-restart) - 若显示
failed，用journalctl -u your-app -n 50 --no-pager查最后 50 行日志，重点找Address already in use或OSError: [Errno 98] - 重启前务必执行：
sudo systemctl stop your-app→sudo systemctl daemon-reload→ 再start，避免旧实例残留
