永远雪山前段时间帮朋友把一个 Python Web 项目从开发机搬到一台全新的 Linux 服务器上，项目本身不算复杂，一个 FastAPI 写的接口服务，加一个定期跑的后台任务，可真正到了部署环节，问题一个接一个：本地跑得好好的代码，到服务器上依赖装不上；好不容易起来了，发现外部访问不到；后面接上 Nginx，又出现 502。说实话，这些问题教科书上不会一次性讲明白，所以我干脆把这个完整的部署过程整理成一篇可以照着做的笔记：将 Python Web 应用部署到服务器，用 Docker + Nginx 这套组合来解决环境隔离、进程管理和对外暴露的问题。
这篇文章适合谁？如果你是刚开始接触服务器部署的开发者，或者手上有个 Python 应用需要交付出去，不想每次换台机器就重新折腾一遍环境，那么照着这套思路走，至少能避开大部分常见的坑。内容会按照方案设计、环境准备、容器化、Nginx 配置、上线验证到问题排查的顺序展开，所有命令都可以直接参考，但更重要的是理解每一步为什么这么做，否则出了问题还是不知道怎么改。
1. 部署方案的整体设计思路
1.1 为什么选择 Docker + Nginx 而不是裸进程部署
我见过不少项目，一开始图省事直接在服务器上安装 Python 3.10、创建虚拟环境、再用 systemd 去管理进程。如果只有一台机器、一个服务，这种方式凑合能用，可一旦要部署到第二台机器，或者隔了几个月再迁移，问题就来了：服务器系统版本不同、软件源里 Python 版本不一致、某个系统库缺少，甚至虚拟环境路径搞混，都会让“之前明明是好的”这个判断变得毫无意义。
Docker 解决的是环境一致性和可复现问题。你把镜像构建好，推到镜像仓库或者直接打包成 tar 文件，到目标机器上一条 docker 命令就能跑起来，不用管底层系统是 Debian 还是别的发行版，也不用担心依赖污染系统环境。更重要的是隔离：应用进程、依赖、配置文件都放进容器里，和宿主机其他服务互不干扰。这对同时跑多个项目尤其重要，A 项目要 Python 3.9，B 项目要 Python 3.11，容器完全可以并存互不冲突。
那 Nginx 有什么用？Python Web 应用在生产环境通常由一个 WSGI/ASGI 服务器对外提供服务，比如 Gunicorn、Uvicorn，它们确实能接收 HTTP 请求。但这类进程如果直接暴露在公网端口上，你会失去对入口的统一控制。Nginx 在应用前面做反向代理，集中处理外部流量，然后再转发给后端。除此之外，Nginx 还能顺手解决静态文件、HTTPS 证书、请求超时、负载均衡、访问日志记录等一堆问题。所以从第一版部署开始就引入 Nginx，后面扩展架构时会轻松非常多。
1.2 从一次访问请求看链路分工
我个人习惯先把一条完整的访问链路画出来，部署时排查问题会快很多。大致是这样：外部浏览器或者客户端请求先到服务器的防火墙，防火墙放行 80/443 端口后交由 Nginx 接收；Nginx 根据 Host 和路径做匹配，再把请求转发给 Docker 网络内的 Web 容器；容器里的 Gunicorn 或 Uvicorn 进程解析协议后调用你的 Python 应用；应用根据业务逻辑再访问数据库、缓存或者外部接口，最后把响应一路返回给客户端。
这条链路里每个组件边界非常清楚。Nginx 是入口，它只负责接收请求、转发响应、处理静态文件和 TLS 终止；Python 应用进程不直接暴露公网地址，只监听容器里的 8000 端口；数据库和 Redis 等中间件如果不是必须对外提供，就放在内部网络，连 Nginx 都接触不到它们。这样即使某个容器挂了，影响范围也被限制在服务内，不会拖垮整个系统。
另一个容易忽略的点是代理层需要把客户端真实信息传给后端。比如用户 IP、原始协议类型，Nginx 会通过 X-Real-IP、X-Forwarded-For、X-Forwarded-Proto 这些请求头传递给应用。如果应用不具备代理感知能力，通常会拿到 Nginx 内网地址而不是真实用户地址，这会在日志统计、风控、限流时造成麻烦。Flask 里要配置 ProxyFix 中间件，FastAPI 需要读取 X-Forwarded-For 头，后面在 Nginx 配置部分我会专门说明。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 服务器环境准备与基础配置
2.1 初始化服务器：用户、SSH、防火墙、时区
拿到一台全新服务器后，我一般不会直接用 root 上来装环境，而是先建一个日常部署用的用户。以 Debian/Ubuntu 系为例，用 root 登录后，先创建一个新用户，再把它加入 sudo 组，后面都用这个用户操作。这样做的原因是，即使某次误操作删除了某个系统配置，也不会因为以 root 身份执行而造成不可恢复的破坏；同时后面文件权限控制会更清晰。
SSH 登录方面，先把本地公钥通过 ssh-copy-id 放到服务器上，确认新用户能免密登录后，再修改 SSH 服务配置，把 PasswordAuthentication 和 PermitRootLogin 关掉，只允许密钥登录。修改完要记得重新加载 sshd 服务，否则一旦断连，可能连不回去。这个操作强烈建议在做完密钥验证后再执行，否则会把自己锁在外面。防火墙方面，云服务器通常有控制台里的安全组配置，系统内又有自己的防火墙，两边都要放行 SSH、HTTP、HTTPS 端口，缺一个都会造成服务不可访问。
时区也是一个经常被忽略的问题。新服务器默认时区可能是 UTC，应用日志记录的时间和本地时间差了好几个小时。我会用 timedatectl 设置时区，比如把系统时区设置成你所在的时区，并确认系统时间正常。时间对不上不仅影响日志排查，还会影响定时任务、证书校验和数据库事务时间，建议在部署流程最开始就处理掉。
2.2 安装 Docker 与 Docker Compose
在 Debian/Ubuntu 上安装 Docker，最简单的方式是使用 Docker 官方提供的 apt 仓库。先更新系统包索引，安装 curl、ca-certificates、gnupg 这些依赖，然后添加官方 GPG 密钥和软件源，最后安装 docker-ce、docker-ce-cli、containerd.io、docker-buildx-plugin、docker-compose-plugin 几个包。安装完成后执行 docker --version 和 docker compose version 验证是否正常。
这里有个建议，不要为了“快”去下载来路不明的安装脚本或者二进制，宁可让官方仓库的过程慢一点，也要保证软件来源可信。如果你的网络从 Docker Hub 拉取镜像比较慢，可以在 /etc/docker/daemon.json 里配置镜像加速地址，把 registry-mirrors 设置成你实际可用的地址，然后重启 Docker 服务。这个配置会直接影响后续镜像构建速度，值得花一分钟提前做好。
装完以后跑一个 docker run hello-world，能输出正常提示就说明 Docker 基本可用。如果是在一台已经有旧版 Docker 的机器上升级，建议先备份数据卷和容器清单，再执行清理和重装，避免镜像名冲突或数据丢失。
2.3 项目代码与生产环境变量
服务器上的项目目录我喜欢放在某个固定路径下面，比如 /opt/app，路径固定后，部署脚本、Nginx 配置、日志收集都依赖这个约定。项目代码可以通过 Git 拉取，也可以把本地打包好的发布包用 scp 或 rsync 传上去。这里更推荐 Git 的方式，因为后面更新版本时只需要 git pull，配合 CI 还能自动构建。
需要注意的是生产环境配置。很多人会把数据库连接地址、应用密钥、第三方 API Key 直接写在代码里，这是安全隐患。我的做法是维护一个 .env.example 文件，里面只写键名和示例值；在服务器上手工创建 .env 文件，填写真实值，并把 .env 加入 .gitignore，永远不进版本库。Docker Compose 可以通过 env_file 指令把 .env 文件注入容器，应用内部再从环境变量中读取配置。这样做的好处是，镜像里不包含任何敏感信息，同一份代码在不同环境下可以加载不同配置。
对于数据库地址这类配置，要特别注意容器内部网络环境和宿主机不一样。比如应用在容器里访问宿主机上的数据库，不能再写 localhost，而要写成宿主机在 Docker 网络中的网关地址，或者直接把数据库也放进同一个 Compose 文件里，通过服务名访问。后面问题排查部分我会专门讲这个。
3. 将 Python Web 应用容器化
3.1 编写 Dockerfile：镜像体积、构建缓存、非 root 运行
Dockerfile 是构建镜像的蓝图，写得好不好直接影响镜像体积、构建速度和上线后的安全性。我先给一个通用版本，适合大多数 FastAPI/Flask 项目，再解释关键点。
dockerfile复制FROM python:3.11-slim
ENV PYTHONDONTWRITEBYTECODE=1 \
PYTHONUNBUFFERED=1 \
PIP_NO_CACHE_DIR=1 \
TZ=Asia/Shanghai
WORKDIR /app
RUN apt-get update && apt-get install -y --no-install-recommends \
gcc \
libpq-dev \
&& rm -rf /var/lib/apt/lists/*
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
RUN useradd --create-home appuser
USER appuser
EXPOSE 8000
CMD ["gunicorn", "app.main:app", "-k", "uvicorn.workers.UvicornWorker", "-b", "0.0.0.0:8000"]
这里有几个值得留意的细节。第一，基础镜像用了 python:3.11-slim，而不是完整的 python:3.11，因为 slim 版本去掉了大量用不到的编译工具和文档，镜像体积小，攻击面也小。第二，先把 requirements.txt 复制进去并安装依赖，再复制整个项目源码，这是为了利用 Docker 的构建缓存。依赖文件不变时，后续构建会直接复用依赖层，速度能快很多；如果反过来把所有文件一次性复制进去，那么只要源码改动，每次都会重新安装所有依赖。第三，安装 gcc 和 libpq-dev 等编译依赖，主要是某些 Python 包在安装 wheels 时需要编译，比如 psycopg2。这类只在构建阶段需要的依赖，如果没有用多阶段构建，装完以后要记得清理 apt 缓存，否则镜像会非常大。
用非 root 用户运行容器同样重要。如果容器内部进程以 root 身份运行，一旦应用被利用，攻击者拿到的是容器内的 root 权限，风险很高。创建 appuser 并切换过去，可以显著降低风险。要注意的是，如果项目需要向容器内某个目录写文件，这个目录的属主要提前设置为 appuser，否则运行时会出现权限不够的问题。
3.2 生产环境下 Gunicorn 与 Uvicorn Worker 的选择
很多初学者会在 Dockerfile 里直接写 CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]。本地调试没问题，但用于生产会有一些隐患：Uvicorn 单进程没有自动重启和多进程管理能力，如果代码里出现内存泄漏或者进程卡死，整个服务可能一起挂掉。比较稳妥的组合是用 Gunicorn 做进程管理器，Uvicorn 作为它的 worker，这样既能享受 Gunicorn 的进程管理、超时控制和优雅重启，又能保留 ASGI 的高性能。
worker 数量怎么定？经验公式是 2 * CPU 核心数 + 1。比如服务器是两核 CPU，就配置 5 个 worker。如果应用是 CPU 密集型任务非常重，可以适当减少 worker，如果主要是网络等待型接口，可以适当增多。不过 worker 不是越多越好，多一个 worker 就多一份内存占用，尤其在 Python 这种进程模型下，每个进程都有一份独立的内存空间。我见过有人把 worker 配置到 20 个，结果服务器内存直接被打满，接口反而更慢。所以在没有压测数据时，先用默认公式，后续再根据监控调整。
Gunicorn 的 timeout 参数也要单独说。默认 timeout 是 30 秒，如果某个接口本身就需要处理超过 30 秒的任务，Gunicorn 会直接把 worker 杀掉，客户端看到的就是 504 或者连接中断。这不是 bug，是保护机制。如果你的接口确实有长时间处理场景，要么调大 timeout，要么把耗时操作放到后台异步处理，客户端先拿到一个任务 ID，再轮询结果。后者在生产里更稳定。
3.3 Docker Compose 编排：端口、环境变量、健康检查
Docker Compose 的价值在于把多个容器的启动参数从繁琐的 docker run 命令变成一份可维护的 YAML 文件。这份文件不仅是部署脚本，也是项目的基础设施说明书，后来者一看就知道服务包含哪些组件、端口怎么暴露、依赖什么环境变量。以一个只有 Web 服务的项目为例，我通常会这么写：
yaml复制services:
web:
build: .
container_name: pyweb
restart: unless-stopped
env_file:
- .env
environment:
- TZ=Asia/Shanghai
ports:
- "127.0.0.1:8000:8000"
volumes:
- ./static:/app/static
- app_logs:/app/logs
healthcheck:
test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"]
interval: 30s
timeout: 5s
retries: 3
start_period: 10s
volumes:
app_logs:
这里端口映射写成了 127.0.0.1:8000:8000，而不是 0.0.0.0:8000:8000，目的就是让外部网络无法直接访问应用端口，只有宿主机上的 Nginx 能通过本地回环地址访问到它。如果你的 Nginx 也运行在容器里并和 web 服务在同一个自定义网络，甚至可以完全不用映射端口，直接用服务名 web 访问。
restart: unless-stopped 是生产环境必选项，它保证服务器重启后容器能自动恢复。healthcheck 段落则让 Docker 能感知应用是否真正可用，而不是只看进程有没有在跑。健康检查的路径最好是应用里一个不依赖数据库的接口，比如 /health，否则数据库临时抖动会让健康检查频繁失败，容器被强制重启。
环境变量通过 env_file 注入，敏感信息不会留在镜像历史里。日志文件建议用单独的 volume 持久化，容器重建后日志不丢。静态目录的挂载是配合宿主机 Nginx 使用的，我选择宿主机 Nginx 时会把 static 目录直接绑定到项目目录里，这样 Nginx 不需要经过应用进程，就能直接返回静态文件。
4. Nginx 反向代理与静态文件处理
4.1 宿主机 Nginx 还是容器 Nginx，我为什么这么选
Nginx 可以跑在宿主机上，也可以作为一个容器跑在 Docker 网络里，两种方式各有各的适用场景。从我接触到的团队情况来看，如果是纯容器化运维，Nginx 也是容器，因为日志采集、故障恢复、编排管理全部统一；如果只是单机部署一个应用，宿主机 Nginx 反而更直接，配置文件路径和日志路径都是系统默认的，出问题时更容易定位。
我在这篇文章里选择宿主机 Nginx，不代表它比容器 Nginx 高级，而是希望把“反向代理”这件事讲清楚。宿主机安装 Nginx 后在 /etc/nginx/ 下管理配置，访问日志在 /var/log/nginx/，错误日志也在那里，对于刚入门的读者来说，这些路径非常关键。如果再用 Nginx 容器，还要考虑配置文件挂载、证书文件挂载、Nginx 如何访问同网络的 Web 容器等问题，会让文章复杂不少。
安装 Nginx 很简单，Debian/Ubuntu 下 apt install nginx 就行。装完后默认会启用一个站点，监听 80 端口，如果不处理，你的域名解析过来会先被默认站点接走。所以我会先把默认站点符号链接删除，然后在 /etc/nginx/sites-available/ 里新建一个自己命名的配置，再用 ln -s 链接到 /etc/nginx/sites-enabled/ 下。这样做的好处是站点配置可以有多个，不需要时直接删掉链接，原文件还在。
4.2 配置一个完整的反向代理站点
下面是一份比较标准的反向代理配置，配合注释一起看：
nginx复制server {
listen 80;
server_name example.com;
gzip on;
gzip_types text/plain text/css application/json application/javascript;
location /static/ {
alias /opt/app/static/;
expires 7d;
add_header Cache-Control "public";
}
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 30s;
proxy_read_timeout 60s;
}
}
location / 是核心反向代理规则，它把未匹配到其他 location 的请求全部转发给 127.0.0.1:8000。这个端口正是 web 容器映射到宿主机回环地址的端口。proxy_set_header 这四个头，作用是让后端应用能够获取到原始请求信息。Host 保留域名信息，X-Real-IP 是用户真实 IP，X-Forwarded-For 是整条代理链路的 IP 列表，X-Forwarded-Proto 则标记用户使用的是 HTTP 还是 HTTPS。如果缺少这些头，你的 Python 应用可能无法正确生成绝对链接，也无法判断用户是否通过 HTTPS 访问。
location /static/ 把静态文件交给 Nginx 处理。alias 指定了磁盘上的真实目录，/opt/app/static 正是我们项目目录下挂载给容器和宿主机共享的 static 目录。这样浏览器请求服务器的 /static/style.css 时，Nginx 会直接读取 /opt/app/static/style.css 并返回，根本不会进到 Python 进程，大大降低了应用层的加载压力。expires 7d 是设置缓存过期时间，它会让浏览器缓存静态资源七天，减少重复请求。
还有一个小坑，location /static/ 里的别名如果写错，会出现 404。比如 alias 路径以斜杠结尾而 location 不带，或者路径前面少了前缀，都可能拼接出错误路径。接完配置后一定要执行 nginx -t 测试语法，确认没问题再 reload。
4.3 静态文件、gzip 压缩与 HTTPS 证书
gzip 在 Nginx 里开启后，文本类资源能压缩到原来的三分之一左右，对减少带宽消耗和提升加载速度非常有效。配置里我建议只对 text 相关类型开启，因为图片、PDF、视频这些文件本身已经是压缩格式，再压缩不仅没有意义，还会额外消耗 CPU。一个常见误区是把所有类型都塞进 gzip_types，结果池子一大，性能反而下降。
HTTPS 部分，现在使用免费自动证书是主流做法。前提是 80 端口能正常访问你的域名，然后用支持 ACME 协议的自动签发工具生成证书，这类工具会自动修改 Nginx 配置，把监听端口从 80 扩展到 443，并写入证书路径。自动续期也不用担心，系统定时任务会在证书快到期时自动执行续期脚本。这里唯一要注意的是，如果你用了云厂商安全组，必须确保 443 端口已经放行，否则证书签发成功也连不上。
如果暂时不想上 HTTPS，至少也要保证 Nginx 配置里的 server_name 和你的域名一致，否则访问会遇到默认站点。另外，如果你有多个站点，一个 Nginx 进程可以配置多个 server 块，通过 server_name 区分，原理和这里一样，只是把每个站点的 proxy_pass 指向各自应用端口。
5. 部署执行与上线验证
5.1 一条龙命令流：构建、启动、迁移、日志
到了这一步，前面的准备工作都要落在具体命令里。我的习惯是从项目目录开始，先执行 git pull 把最新代码拉到服务器，或者把本地发布包上传到固定路径。第一次部署时用 docker compose build --no-cache 构建镜像，这样能保证不会用到旧缓存，构建环境更干净；后续部署则直接 docker compose build，正常利用缓存，速度更快。
代码构建完成后，启动前要把 .env 文件准备好。启动命令是 docker compose up -d，-d 表示后台运行。如果项目涉及数据库表结构变更，还需要在容器启动后执行迁移命令，比如 Django 项目的 migrate，再比如 SQLAlchemy 项目用 alembic upgrade head。这一步不能漏，否则应用启动后接口会报数据库表不存在。
迁移之后不要急着去做访问测试，先看容器状态和日志。docker compose ps 可以查看容器是否正常在运行，docker compose logs -f web 可以实时看应用日志。如果健康检查没有通过，日志里一般会直接抛出异常。等容器稳定之后，在服务器本机执行 curl http://127.0.0.1:8000/health，确认应用容器本身能响应；再执行 curl http://127.0.0.1/，确认通过 Nginx 也能访问到应用。这一步验证顺序很重要，如果直接在浏览器上访问域名发现打不开，很难分清是哪一层出的问题。
5.2 上线前的快速检查清单
上线前花两分钟过一遍检查项，能避免不少“上线十分钟后紧急回滚”的情况。我平时用的检查项大概这些：安全组和系统防火墙是否放行 80/443；Nginx 配置语法是否正确；容器 restart 策略是否已设置；环境变量是否通过 .env 注入而不是写在代码里；静态文件目录是否存在且有正确权限；数据库迁移是否执行；日志目录是否有持久化卷。每一项看起来都是小事，但任何一个遗漏都可能让服务在特定条件下出问题。
我印象比较深的一次，是一个项目在本地调试时一切正常，部署到服务器后第一次访问极慢，后来发现数据库连接池参数没调，应用每次请求都重新建立连接。这属于应用层问题，但如果不安排“上线后观察十分钟”这个动作，很可能被误以为是网络问题。所以我的建议是，别在更新完之后立刻离开，至少观察一段时间的日志和接口耗时，确认没有明显异常再收工。
服务器上的监控也不需要很重。最低限度看一下 docker stats 的 CPU 和内存占用，如果内存持续上涨不回落，大概率是某个 worker 里有资源没释放。再配合 docker compose logs 的时间戳和 Nginx access.log 的状态码，能快速定位大多数问题。
6. 常见问题与排查技巧实录
6.1 502 Bad Gateway：定位链路中的断点
502 是 Nginx 反向代理场景下最常见的错误，含义是 Nginx 尝试连接后端，但后端没有给出正常响应。排查顺序可以按链路从近到远。先看容器是否还活着，docker compose ps 如果有服务状态是 Exited，那就是应用进程退出，继续看 docker compose logs web 里的报错信息；如果容器还在运行，从宿主机直接 curl 一下 127.0.0.1:8000/health，判断映射到宿主机的端口是否可达。如果这一步失败，说明应用本身没起来，和 Nginx 无关；如果这一步成功，Nginx 还 502，就要检查 Nginx 配置里 proxy_pass 的地址和端口是否正确。
我踩过的一个坑是，容器启动比较慢，数据库或缓存初始化需要几十秒，而 Nginx 一直在运行，健康检查还没通过时访问就已经进来了，这时也会短暂 502。解决办法是等 healthcheck 通过后再 reload Nginx，或者把 Nginx 的 proxy_read_timeout 调大一些，避免读超时导致误报。另外，如果你把端口映射写成了 8000:8000，也就是绑定在了 0.0.0.0 上，虽然 Nginx 也能访问，但外部也能直接访问，安全性会打折扣，建议一律使用 127.0.0.1:8000:8000。
6.2 静态文件 404、权限不足与缓存过期
静态文件 404 的原因大部分集中在三处：alias 路径拼错了、目录不存在、权限不够。Nginx 的 error.log 里如果有 permission denied，就说明 nginx 进程的用户对静态文件目录没有读权限，这在把 static 目录放在 /opt/app 下时尤其容易出现。解决办法是给 /opt/app/static 设置合理的读取权限，但不建议把整个 /opt/app 都改成 777，那样容器和宿主机之间权限太松，后续容易出现安全问题。
缓存过期这个问题也很常见。你更新了 CSS 文件，浏览器还是访问旧版本，因为 Nginx 配置了 expires 7d，浏览器缓存没有失效。开发期可以把 expires 设短一点，或者临时禁用缓存；生产环境更好的做法是给静态文件名加内容哈希，让文件名随着内容变化而变化，这样即使缓存时间很长，用户也能拿到新文件。如果你不想改动应用，也可以在 Nginx 配置里放宽 Cache-Control，但这不是长效方案。
6.3 容器日志时间不对，排查时对不上号
容器默认时区继承自镜像，很多基础镜像使用 UTC 时间，所以你在 docker compose logs 里看到的时间和本地时间差 8 个小时，这个现象非常常见。如果定时任务在每天凌晨 2 点执行，你在 UTC 日志里看到的却是前一天下午 6 点，很容易把排查方向带偏。
解决方式也很简单，在 compose 文件的 environment 里加上 TZ=Asia/Shanghai，再挂载宿主机的时间相关文件，或者直接在 Dockerfile 里设置 ENV TZ。需要注意，某些操作系统镜像里没有 zoneinfo 数据，光设置 TZ 可能不够，可以额外把 /etc/localtime 和 /etc/timezone 以只读方式挂载到容器里。不过这属于环境补救，建议在项目早期就把时区统一，日志格式里也带上偏移量，否则后面迁移时还要再调一遍。
6.4 服务器重启后容器没有自动恢复
服务器重启后容器没有恢复，这个问题我遇到过不止一次。最常见的原因是 Docker 服务本身没有设置开机自启，重启后 docker 守护进程没有运行，那么容器自然也就起不来。执行 systemctl enable docker，让服务随系统启动。第二个原因是容器创建时 restart 策略不是 always 或 unless-stopped，docker compose 里虽然写了 restart，但需要确认 service 定义中确实生效。
还有一种情况是，服务器重启后，你的应用依赖的数据库或 Redis 服务没起来，应用容器虽然启动了，但健康检查失败，被 Docker 判断为不健康。这时 docker compose ps 看到容器状态不是 running，而是 restarting 循环。排查方法还是看日志，日志里往往写着数据库连接失败。数据库容器如果也定义了 restart: unless-stopped，通常会自动恢复，但如果数据库需要手动启动或者依赖外部服务，就要在应用容器的 healthcheck 里加一个等待逻辑，让应用等数据库 ready 后再继续。
6.5 数据库连不上，先检查服务名而不是 localhost
在容器环境下，最常见的一个连接问题是应用报错 can't connect to MySQL server on 'localhost'。你可能会想，数据库明明就在这台服务器上跑，为什么连不上？因为容器有自己独立的网络命名空间，容器里的 localhost 指的是容器自身，而不是宿主机。如果数据库在宿主机上直接运行，应用容器里应该配置数据库地址为宿主机在 Docker 网络中的网关 IP，通常类似 172.17.0.1。这样做虽然可行，但 IP 会随 Docker 网络变化，并不稳定。
更推荐的方案是把数据库也写进同一个 docker-compose.yml 里，作为一个独立服务，和应用容器使用同一个自定义网络。这样应用配置数据库地址时，直接写服务名即可，例如 db。Docker 内置的 DNS 解析会把服务名解析为容器 IP，应用和数据库之间通信不再依赖固定的 IP 地址。这时端口映射只需要在实际需要的时候才暴露给宿主机，数据库通常不需要对外映射端口，安全性也会更好。
我在实际部署这套 Python Web 应用时，最大的体会不是某项技术有多难，而是链路越简单，越容易定位问题。Docker 负责把环境和应用打包在一起，Nginx 负责入口和转发，应用进程老老实实监听容器内端口，剩下的就是持续观察日志。如果你也要做类似部署，建议先在本地或一台临时虚拟机上把整个流程完整跑一遍，熟悉之后再操作正式服务器，压力会小很多。最后再分享一个细节：上线前一定把数据卷备份、密钥管理、日志轮转这三件事落实，否则每次小版本更新都会提心吊胆，不是担心数据丢，就是担心某条配置被覆盖，这种体验我实在不想让你再经历一次。