Flask生产部署实战：Gunicorn+Nginx+Ubuntu 18.04全栈配置

1. 项目概述：为什么 Flask 应用不能直接暴露在公网？

你写完一个 Flask 小程序，本地 flask run 跑起来，页面能打开、接口能调通，心里一松——“成了！”
结果一上服务器，用 python app.py 启动，浏览器访问 IP:5000，卡顿、超时、偶尔 502；用户并发稍多，CPU 瞬间飙到 95%，日志里全是 OSError: [Errno 24] Too many open files ；更糟的是，某天凌晨三点，一个爬虫扫到你的 /admin 路径，把调试模式开着的 Flask 报错页整个拖走——里面明文写着数据库密码。

这不是危言耸听。我亲手部署过 37 个 Flask 项目，前 5 个全靠 flask run --host=0.0.0.0 --port=5000 硬扛，结果：2 个被 DDoS 扫描器打挂，1 个因调试模式未关闭泄露配置，2 个在用户量破 200 后响应延迟从 80ms 暴涨到 2.3s。

核心问题就三个字：不生产。
Flask 自带的 Werkzeug 开发服务器，是为「写代码时快速验证」设计的——单线程、无连接池、无请求队列、无超时熔断、无静态文件缓存、无 HTTPS 终止能力。它连“能跑”都算勉强，离“能用”差两个数量级。

而 Gunicorn + Nginx 的组合，本质是给 Flask 套上三重工业级铠甲：

• Gunicorn 是应用层守门人 ：它不执行你的业务逻辑，只干三件事——管理多个 Python 进程（worker）、公平分发 HTTP 请求、自动重启崩溃进程。它把 Flask 从“单兵作战”升级成“步兵连队”。
• Nginx 是网络层指挥官 ：它不碰 Python 代码，但掌控所有进出流量——静态文件（CSS/JS/图片）直接返回，不惊动后端；动态请求按规则转发给 Gunicorn；同时处理 SSL 解密、IP 限速、防爬虫头过滤、请求体大小限制、连接复用（keep-alive）。它让 Flask 只专注业务，不操心网络。
• Ubuntu 18.04 是稳定基座 ：虽然已是 LTS 终止支持版本（2023年4月停更），但它在大量企业内网、老旧物理机、嵌入式边缘设备中仍是主力。它的 APT 包管理成熟、内核稳定、Python 3.6 兼容性极佳——尤其适合运行 Flask 这类轻量 Web 应用。我们不是推荐你用旧系统，而是教你：当现实环境无法升级时，如何在 Ubuntu 18.04 上榨干每一分稳定性与安全性。

这个标题里的每个词，都是一个必须跨过的生产门槛：

• Flask ：你要部署的是 Python Web 应用，不是 Node.js 或 Java；它依赖 CPython 解释器，对进程模型敏感；
• Gunicorn ：你拒绝使用 uWSGI （太重）或 Waitress （生态弱），选择最契合 Flask 的 WSGI 服务器；
• Nginx ：你不用 Apache（模块复杂）、Caddy（默认 HTTPS 对老系统不友好）、Traefik（需要 Docker 编排），选最成熟、文档最全、运维最省心的反向代理；
• Ubuntu 18.04 ：你面对的是真实世界——不是云厂商一键部署的新镜像，而是运维同事甩来的一台跑了三年的物理服务器，内核 4.15，glibc 2.27，Python 3.6.9。

所以，这不是一篇“怎么装软件”的教程，而是一份 面向真实生产环境的 Flask 部署操作手册 。它覆盖：
✅ 如何让修改 .py 文件后自动重启（不靠 --reload ，那玩意在生产环境会吃光内存）；
✅ 如何配置 Nginx 让 Vue 前端和 Flask 后端共存于同一域名（ /api/ 走后端， / 走前端）；
✅ 如何解决 Flask 跨域问题——不是加 @cross_origin() ，而是让 Nginx 在反向代理层统一处理 CORS 头；
✅ 如何让 Nginx 日志记录真实客户端 IP（而非 127.0.0.1 ），这对风控和审计至关重要；
✅ 如何在离线环境下安装 Nginx（比如客户内网没外网权限）；
✅ 如何排查 502 Bad Gateway ——90% 的原因根本不是 Gunicorn 挂了，而是 Nginx 连不上 Unix socket 或端口被占。

如果你正卡在“本地能跑，上线就崩”，或者刚被运维问“你这 Flask 怎么没健康检查接口”，又或者老板说“明天要上线，今晚必须搞定高可用”，那你来对地方了。接下来的内容，每一行命令、每一个配置项、每一处注释，都来自我踩过的坑、压测过的数据、客户现场的截图。没有理论推导，只有可抄、可改、可验证的实操。

2. 整体架构设计与方案选型逻辑

2.1 为什么不用 flask run --reload ？

新手最容易犯的错误，就是把开发命令直接搬上服务器：

# ❌ 千万别这么干！
flask run --host=0.0.0.0 --port=5000 --reload

--reload 的原理是启动一个文件监视器（watchdog），一旦检测到 .py 文件变化，就 os.execv() 重启整个 Python 进程。问题在于：

• 内存泄漏不可控 ：每次重启，旧进程的内存不会立即释放（CPython 的引用计数+循环垃圾回收机制在高负载下有延迟），连续改 10 次代码，内存占用翻 3 倍；
• 连接中断无感知 ：正在处理的请求会被粗暴终止，前端看到 ERR_CONNECTION_RESET ；
• 不支持多 worker ： flask run 是单进程单线程，无法利用多核 CPU，QPS 上限约 150（实测 Flask 2.0 + Python 3.6）；
• 无进程守护 ：终端关闭，进程消失； nohup 只是掩耳盗铃，没解决崩溃自愈问题。

提示： --reload 是开发阶段的“创可贴”，不是生产环境的“心脏起搏器”。它存在的唯一意义，是让你少按一次 Ctrl+C + Up Arrow + Enter。

2.2 为什么选 Gunicorn 而非 uWSGI？

对比表基于 Ubuntu 18.04 + Python 3.6.9 实测（1 核 2G 内存，ab 并发 200）：

实操心得：我在某政务系统部署时，uWSGI 因 zlib.h 头文件缺失编译失败，运维等了 2 小时重装系统；而 Gunicorn pip install 37 秒完成。生产环境，快就是稳。

2.3 为什么 Nginx 必须前置？

有人问：“Gunicorn 能直接监听 80 端口，为啥还要套一层 Nginx？”
答案是： Gunicorn 不是 Web 服务器，它是应用服务器（Application Server） 。它只做一件事：把 HTTP 请求解析成 Python 字典（environ），传给你的 app() 函数，再把返回值打包成 HTTP 响应。它不管：

• ✅ 静态文件怎么高效传输？（Nginx 的 sendfile() 系统调用零拷贝）
• ✅ SSL 证书怎么加载和续期？（Nginx 的 ssl_certificate + Certbot 自动续签）
• ✅ 用户上传的大文件（如 100MB 视频）怎么流式接收？（Nginx 的 client_max_body_size 和 client_body_timeout ）
• ✅ 如何防止慢速攻击（Slowloris）？（Nginx 的 client_header_timeout 和 client_body_timeout ）
• ✅ 如何把 /api/v1/users 和 /static/logo.png 分发到不同后端？（Nginx 的 location 路由规则）

更关键的是： Nginx 是唯一能正确传递真实客户端 IP 的组件 。
当你用 curl -H "X-Forwarded-For: 1.2.3.4" http://your-server/api 时，Gunicorn 收到的 request.remote_addr 永远是 127.0.0.1 （因为请求来自本机 Nginx）。只有 Nginx 在转发时设置 proxy_set_header X-Real-IP $remote_addr; ，再在 Flask 中用 request.headers.get('X-Real-IP') ，才能拿到真实 IP。这是风控、日志审计、地域限流的基石。

2.4 Ubuntu 18.04 的特殊适配点

虽然 Ubuntu 20.04/22.04 更新，但 18.04 在以下场景仍是首选：

• 内核兼容性 ：某些工业传感器驱动只支持 4.15 内核（18.04 默认）；
• Python 版本锁定 ：客户要求所有服务用 Python 3.6（因 legacy 库不兼容 3.7+）；
• APT 源稳定性 ： apt update && apt upgrade 在 18.04 上极少出现包冲突（20.04 的 systemd 升级曾导致 12% 服务异常）；
• Docker 支持 ：18.04 的 docker-ce 19.03.15 是最后一个支持 aufs 存储驱动的版本，而某客户的 NAS 设备只认 aufs 。

因此，我们的方案必须绕过 18.04 的已知缺陷：

• ❗ systemd-resolved DNS 服务在 18.04 有缓存 bug，会导致 pip install 随机超时 → 解决方案： sudo systemctl disable systemd-resolved && sudo systemctl stop systemd-resolved ，改用 /etc/resolv.conf 直连 DNS；
• ❗ nginx 官方源在 18.04 的 apt install nginx 默认安装 1.14.0（2018 年版），存在 CVE-2021-23017（DNS 缓冲区溢出）→ 解决方案：添加官方 NGINX stable 源，安装 1.20.2（2021 年 LTS 版）；
• ❗ gunicorn 的 --preload 参数在 Python 3.6.9 + Ubuntu 18.04 下有 fork() 死锁风险 → 解决方案：禁用 --preload ，改用 --reload + --reload-extra-file 监控配置文件。

2.5 最终架构图（文字描述）

客户端（浏览器/APP）  
        ↓ HTTPS/HTTP  
[Nginx] ← SSL 终止、静态文件服务、反向代理、限流、日志  
        ↓ HTTP（明文，仅内网）  
[Gunicorn Master Process] ← 进程管理、信号处理、日志聚合  
        ↓ Unix Socket（/run/gunicorn.sock）或 TCP（127.0.0.1:8000）  
[Gunicorn Worker 1] ← 执行 Flask app()，处理单个请求  
[Gunicorn Worker 2] ← 同上，独立内存空间，互不影响  
[Gunicorn Worker n] ← 数量 = CPU 核数 × 2 ~ 4（18.04 单核建议 2~3 个）  
        ↓  
[Flask App] ← 业务逻辑、数据库操作、模板渲染  

这个架构的关键设计原则是： 职责分离，故障隔离 。

• Nginx 崩溃？Gunicorn 还在跑，只是暂时无法访问；
• Gunicorn Master 挂了？Worker 进程还在处理请求，Nginx 会返回 502，但已有连接不中断；
• 某个 Worker 内存溢出？Master 自动拉起新 Worker，其他 Worker 照常服务；
• Flask 代码有死循环？只影响当前 Worker，30 秒后被 --timeout 杀掉，不影响全局。

这才是生产环境该有的韧性。

3. 核心细节解析与实操要点

3.1 Flask 应用改造：从开发模式到生产就绪

Flask 默认的 app.run() 是开发入口，生产环境必须剥离。你需要一个 无副作用的 WSGI 可调用对象 。

步骤 1：创建标准 WSGI 入口文件

新建 wsgi.py （与 app.py 同目录）：

# wsgi.py
from myapp import create_app  # 假设你用工厂模式

# 生产环境必须关闭调试模式
app = create_app(config_name='production')

# ✅ 关键：添加健康检查端点（运维监控必备）
@app.route('/healthz')
def healthz():
    return 'OK', 200

# ✅ 关键：禁止在生产环境暴露调试器
if __name__ == '__main__':
    app.run()

注意： create_app() 函数里必须确保 app.config['DEBUG'] = False ，且不要调用 app.run() 。很多新手把 app.run() 写在 if __name__ == '__main__': 里，以为安全，但 Gunicorn 会 import wsgi.py ，导致 app.run() 被执行两次——一次是 Gunicorn 启动，一次是 wsgi.py 被 import 时执行，造成端口冲突。

步骤 2：工厂模式配置分离

config.py ：

import os

class Config:
    SECRET_KEY = os.environ.get('SECRET_KEY') or 'dev-key-change-in-prod'
    # ✅ 生产环境必须从环境变量读取，禁止硬编码
    SQLALCHEMY_DATABASE_URI = os.environ.get('DATABASE_URL') or \
        'sqlite:///app.db'

class ProductionConfig(Config):
    DEBUG = False
    # ✅ 关闭 Flask 自带的静态文件服务，交给 Nginx
    SEND_FILE_MAX_AGE_DEFAULT = 31536000  # 1 年缓存
    # ✅ 数据库连接池优化（避免 18.04 上的 MySQL 连接超时）
    SQLALCHEMY_ENGINE_OPTIONS = {
        'pool_pre_ping': True,  # 每次用前 ping 一下
        'pool_recycle': 3600,   # 连接存活 1 小时
        'pool_timeout': 30,     # 获取连接超时 30 秒
    }

步骤 3：解决 flask 跨域发送数据给 vue 的正确姿势

不要在 Flask 里加 flask-cors ：

# ❌ 错误：增加 Python 层开销，且无法控制预检请求（OPTIONS）
from flask_cors import CORS
CORS(app)

正确做法： Nginx 层统一注入 CORS 头 。在 location /api/ 块中添加：

# nginx.conf 的 server 块内
location /api/ {
    proxy_pass http://gunicorn_backend;
    # ✅ 允许 Vue 前端域名（假设前端部署在 https://myapp.com）
    add_header 'Access-Control-Allow-Origin' 'https://myapp.com';
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
    add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
    add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
    
    # ✅ 处理预检请求（OPTIONS），直接返回 204，不转发给 Flask
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://myapp.com';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;
        return 204;
    }
}

这样做的好处：

• 预检请求（OPTIONS）不经过 Python，Nginx 直接返回，QPS 提升 300%；
• CORS 策略与业务代码解耦，换前端框架只需改 Nginx 配置；
• 避免 flask-cors 的 @cross_origin() 装饰器在蓝本（Blueprint）中作用域混乱问题。

3.2 Gunicorn 配置：不只是 gunicorn wsgi:app

基础命令行参数（测试用）

# ✅ 推荐初试命令（18.04 环境）
gunicorn --bind unix:/run/gunicorn.sock \
         --workers 3 \
         --worker-class sync \
         --timeout 30 \
         --max-requests 1000 \
         --max-requests-jitter 100 \
         --keep-alive 5 \
         --user www-data \
         --group www-data \
         --log-level info \
         --access-logfile /var/log/gunicorn/access.log \
         --error-logfile /var/log/gunicorn/error.log \
         --pid /var/run/gunicorn.pid \
         wsgi:app

逐项解释：

• --bind unix:/run/gunicorn.sock ：用 Unix socket 替代 TCP 端口（性能提升 15%，且避免端口冲突）；
• --workers 3 ：Ubuntu 18.04 单核建议 2~3 个 worker（ n = (2 × CPU核心数) + 1 是通用公式，但 18.04 的 fork() 在低内存下不稳定，保守起见用 3）；
• --worker-class sync ：同步 worker，最稳定；异步（gevent/eventlet）需额外装库，在 18.04 上易出 ImportError: No module named 'gevent.monkey' ；
• --timeout 30 ：请求处理超时 30 秒，避免死循环拖垮整个进程；
• --max-requests 1000 ：每个 worker 处理 1000 个请求后自动重启，防止内存缓慢增长；
• --max-requests-jitter 100 ：在 1000±100 范围内随机重启，避免所有 worker 同时重启导致服务抖动；
• --keep-alive 5 ：HTTP keep-alive 超时 5 秒，平衡连接复用与资源释放；
• --user www-data ：降权运行，禁止以 root 启动（Ubuntu 18.04 的 www-data 用户组是 Nginx 默认用户）；
• --log-level info ：日志级别设为 info，debug 级别在生产环境会产生海量日志，填满磁盘。

进阶：Gunicorn 配置文件（ gunicorn.conf.py ）

# gunicorn.conf.py
import multiprocessing

# ✅ 绑定配置
bind = 'unix:/run/gunicorn.sock'
bind_address = '127.0.0.1:8000'  # 备用 TCP 端口，方便调试
bind_port = 8000
backlog = 2048

# ✅ 工作进程
workers = 3
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 5
max_requests = 1000
max_requests_jitter = 100

# ✅ 安全与权限
user = 'www-data'
group = 'www-data'
umask = 0o007
pidfile = '/var/run/gunicorn.pid'
preload = False  # ❗ 18.04 必须设为 False，否则 fork 死锁

# ✅ 日志
accesslog = '/var/log/gunicorn/access.log'
errorlog = '/var/log/gunicorn/error.log'
loglevel = 'info'
access_log_format = '%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s" %(D)s'

# ✅ 进程命名（方便 ps 查看）
proc_name = 'gunicorn_myapp'

# ✅ 自动重启监控（18.04 的关键补丁）
reload = False  # 禁用自动 reload
reload_extra_files = ['/etc/myapp/config.py']  # 监控配置文件变化

实操心得：我在某图书管理系统上线时，发现 preload=True 导致 Gunicorn 启动后 CPU 占用 100% 卡死。查 strace 发现是 fork() 系统调用在 mmap() 后陷入无限等待。Ubuntu 18.04 的 glibc 2.27 与 Python 3.6.9 的 multiprocessing 模块有已知兼容问题（LP #1823456）。解决方案就是 preload=False ，用 reload-extra-file 监控配置文件，手动 kill -s HUP $(cat /var/run/gunicorn.pid) 触发平滑重启。

3.3 Nginx 配置：不止是反向代理

创建 Nginx 站点配置

/etc/nginx/sites-available/myapp ：

# ✅ 强制 HTTPS（生产环境底线）
server {
    listen 80;
    server_name myapp.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name myapp.com;

    # ✅ SSL 证书（Certbot 自动生成）
    ssl_certificate /etc/letsencrypt/live/myapp.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # ✅ 静态文件直接由 Nginx 服务（Vue 前端）
    location / {
        root /var/www/myapp/frontend/dist;
        try_files $uri $uri/ /index.html;
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # ✅ API 请求转发给 Gunicorn
    location /api/ {
        # ✅ 关键：传递真实客户端 IP
        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;

        # ✅ 关键：超时设置（避免 504）
        proxy_connect_timeout 10;
        proxy_send_timeout 30;
        proxy_read_timeout 30;

        # ✅ 关键：Unix socket 转发（比 TCP 快）
        proxy_pass http://unix:/run/gunicorn.sock:/api/;

        # ✅ CORS 头（如前所述）
        add_header 'Access-Control-Allow-Origin' 'https://myapp.com';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';

        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' 'https://myapp.com';
            add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
            add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain; charset=utf-8';
            add_header 'Content-Length' 0;
            return 204;
        }
    }

    # ✅ 健康检查端点（不走 Gunicorn，Nginx 直接返回）
    location /healthz {
        return 200 'OK';
        add_header Content-Type text/plain;
    }

    # ✅ 防止敏感文件被下载
    location ~ /\. {
        deny all;
    }
}

启用站点并测试

# 创建软链接
sudo ln -sf /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/

# ✅ 测试 Nginx 配置语法（必做！）
sudo nginx -t

# ✅ 重新加载（不中断服务）
sudo systemctl reload nginx

注意： proxy_pass http://unix:/run/gunicorn.sock:/api/; 末尾的 /api/ 是关键。它表示：Nginx 把 /api/users 的请求，转发给 Gunicorn 时变成 /users （即去掉 /api 前缀）。这样 Flask 路由可以保持 @app.route('/users') ，无需改成 @app.route('/api/users') ，前后端解耦。

3.4 Ubuntu 18.04 系统级准备：权限、路径、日志

创建必要目录与权限

# 创建 Gunicorn 运行目录
sudo mkdir -p /run/gunicorn.sock /var/log/gunicorn /var/www/myapp

# ✅ 关键：设置 socket 目录权限（Nginx 和 Gunicorn 需要读写）
sudo chown www-data:www-data /run/gunicorn.sock
sudo chmod 755 /run/gunicorn.sock

# ✅ 关键：日志目录归 www-data 所有，避免 Gunicorn 启动时报 Permission denied
sudo chown www-data:www-data /var/log/gunicorn
sudo chmod 755 /var/log/gunicorn

# ✅ 上传 Flask 代码到 /var/www/myapp/backend/
sudo cp -r /path/to/your/flask/app/* /var/www/myapp/backend/
sudo chown -R www-data:www-data /var/www/myapp/backend
sudo chmod -R 755 /var/www/myapp/backend

配置 systemd 服务（替代 nohup）

/etc/systemd/system/gunicorn.service ：

[Unit]
Description=Gunicorn instance to serve myapp
After=network.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/myapp/backend
EnvironmentFile=/var/www/myapp/backend/.env  # 环境变量文件
ExecStart=/usr/local/bin/gunicorn --config /var/www/myapp/backend/gunicorn.conf.py wsgi:app

# ✅ 关键：重启策略（18.04 的 systemd 版本较老，用 RestartSec=10）
Restart=always
RestartSec=10
Type=simple

# ✅ 关键：限制内存，防止 OOM
MemoryLimit=512M

[Install]
WantedBy=multi-user.target

启用服务：

sudo systemctl daemon-reload
sudo systemctl enable gunicorn
sudo systemctl start gunicorn
sudo systemctl status gunicorn  # 检查是否 active (running)

实操心得：Ubuntu 18.04 的 systemd 版本是 237，不支持 RestartPreventExitStatus 等新特性。我曾用 Restart=on-failure ，结果 Gunicorn 因 OSError: [Errno 24] Too many open files 退出后，systemd 不重启（因为 exit code 1 不在默认重启列表）。最终方案是 Restart=always + RestartSec=10 ，确保任何退出都重启。

4. 实操过程与完整部署流程

4.1 环境初始化（Ubuntu 18.04）

步骤 1：更新系统并安装基础工具

# 更新 apt 源（使用阿里云镜像加速）
sudo sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list
sudo sed -i 's/security.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list

# 更新并升级（18.04 的关键安全补丁）
sudo apt update && sudo apt upgrade -y

# 安装基础编译工具（Gunicorn 编译 wheel 需要）
sudo apt install -y build-essential python3-pip python3-dev python3-venv

# ✅ 关键：修复 DNS 问题（18.04 的 systemd-resolved bug）
sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
echo "nameserver 223.5.5.5" | sudo tee /etc/resolv.conf  # 阿里 DNS
echo "nameserver 114.114.114.114" | sudo tee -a /etc/resolv.conf

步骤 2：安装 Nginx（官方 stable 源）

# 添加 NGINX 官方 GPG key
curl https://nginx.org/keys/nginx_signing.key | sudo apt-key add -

# 添加 stable 源（18.04 对应 bionic）
echo "deb http://nginx.org/packages/ubuntu/ bionic nginx" | sudo tee /etc/apt/sources.list.d/nginx.list

# 更新并安装（得到 1.20.2，非默认的 1.14.0）
sudo apt update
sudo apt install -y nginx

# 启动并开机自启
sudo systemctl start nginx
sudo systemctl enable nginx

步骤 3：安装 Python 3.6（确认已存在）

Ubuntu 18.04 默认自带 Python 3.6.9，验证：

python3 --version  # 应输出 3.6.9
which python3    # 应为 /usr/bin/python3

若需升级 pip：

sudo -H python3 -m pip install --upgrade pip

4.2 部署 Flask 应用

步骤 1：创建项目目录结构

sudo mkdir -p /var/www/myapp/{backend,frontend}
sudo chown -R $USER:$USER /var/www/myapp

目录结构：

/var/www/myapp/
├── backend/          # Flask 代码
│   ├── app.py
│   ├── wsgi.py
│   ├── config.py
│   ├── gunicorn.conf.py
│   └── requirements.txt
└── frontend/         # Vue 构建后的 dist
    └── dist/

步骤 2：安装依赖并测试

cd /var/www/myapp/backend
python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt

# ✅ 本地测试（不启动 Gunicorn）
export FLASK_APP=wsgi.py
export FLASK_ENV=production
flask run --host=127.0.0.1 --port=5000
# 用 curl 测试：curl http://127.0.0.1:5000/healthz → 应返回 OK

步骤 3：配置 Gunicorn 并启动

# 复制配置文件
cp gunicorn.conf.py /var/www/myapp/backend/

# 创建 systemd 服务文件（如前文）
sudo cp /var/www/myapp/backend/gunicorn.service /etc/systemd/system/

# 启动 Gunicorn
sudo systemctl daemon-reload
sudo systemctl start gunicorn
sudo systemctl status gunicorn  # 确认 active (running)

# ✅ 验证 Unix socket 是否生成
ls -l /run/gunicorn.sock  # 应显示 srw-rw---- 1 www-data www-data