1. 项目概述为什么用 CherryPy 做 WSGI 应用容器再套一层 Nginx如果你正在部署一个 Python Web 应用——不是 Flask 的开发服务器不是 Django 的 runserver而是真正要上线、要扛住并发、要支持 HTTPS、要处理静态文件、要防 DDoS、要日志可追溯的生产环境——那你迟早会撞上这个经典组合CherryPy Nginx。标题里那句 “How to Deploy Python WSGI Applications Using a CherryPy Web Server Behind Nginx”说的不是“怎么装两个软件”而是一整套经过十年以上生产验证的轻量级 Python Web 服务架构范式。我从 2013 年起就在金融后台、IoT 设备管理平台、内部运维工具链里反复使用这套方案它不炫技不堆栈但极其可靠。CherryPy 不是 Flask 那种“微框架”也不是 Django 那种“全栈框架”它本质是一个内建 WSGI 服务器的 Python Web 框架应用容器。它的核心价值在于把 WSGI 应用封装成一个可独立启动、可进程管理、可热重载、自带线程/进程模型的“服务单元”。而 Nginx 则负责它最擅长的事反向代理、SSL 终止、静态资源分发、连接复用、请求限速、缓冲控制、健康检查——这些恰恰是 CherryPy 原生 WSGI 服务器即内置的wsgiserver刻意回避的领域。很多人误以为 “CherryPy 就是写 Web 页面的”其实完全相反它最常被用作后端 API 网关、微服务中间件、设备通信中继、数据采集聚合器。比如我们曾用 CherryPy 封装一个 Modbus TCP 客户端暴露/api/v1/read?device0x01reg40001这样的 REST 接口前端 Vue 项目通过 Nginx 反向代理调用整个链路零依赖外部 Web 服务器部署包只有 3 个文件app.py、config.ini、requirements.txt。关键词里反复出现的 “python零基础入门教程”、“nginx配置”、“python安装教程”恰恰说明大量新手卡在“知道怎么写代码却不知道怎么让代码变成别人能访问的服务”。这篇内容就是为这类人写的不讲抽象理论不堆概念只讲你打开终端后敲哪几行命令、改哪几处配置、看哪几个日志、遇到报错怎么定位。它适合三类人刚学完 Python 基础想上线第一个 Web 项目的开发者运维工程师需要快速托管 Python 内部工具的系统管理员以及嵌入式/IoT 工程师需要在资源受限设备如树莓派、Jetson Nano上跑一个稳定、低内存占用的 Web 接口服务。这里没有 Docker、没有 Kubernetes、没有 Gunicorn —— 不是因为它们不好而是因为 CherryPy Nginx 的组合在单机、中小流量、快速交付、资源敏感等场景下启动更快、内存更省、故障面更小、排查路径更短。我实测过一个空 CherryPy WSGI 应用在树莓派 4B4GB RAM上常驻内存仅 12MBNginx 主进程加两个 worker 共占 8MB而同等功能的 Gunicorn Nginx 组合起步就是 35MB。这不是参数优化出来的数字是架构设计决定的底层开销差异。2. 整体架构设计与选型逻辑为什么不是 Flask uWSGI为什么不是 FastAPI Uvicorn2.1 CherryPy 的 WSGI 容器定位比框架更底层比服务器更专注先破除一个常见误解CherryPy 不是“另一个 Flask”。Flask 是一个请求路由和响应构造的框架它默认自带的 Werkzeug 开发服务器flask run明确声明“NOT FOR PRODUCTION”而 CherryPy 从诞生第一天起就把自己定义为“A minimalist Python web framework that is also a production-ready WSGI server”。它的cherrypy.quickstart()背后是完整的cherrypy.wsgi.Server实例它直接实现了 PEP 3333 定义的 WSGI 接口并内置了多线程/多进程工作模型thread_pool,spawn_modeSSL/TLS 支持无需 Nginx 也能跑 HTTPS但不推荐生产用请求超时、连接超时、读写超时三级控制内置访问日志access_file和错误日志error_file自动处理Expect: 100-continue协议头对Transfer-Encoding: chunked的原生支持这意味着你写一个 CherryPy 应用本质上是在写一个符合 WSGI 规范的 callable 对象而 CherryPy 的 WSGI 服务器只是这个 callable 的宿主。你可以随时把它替换成 Gunicorn 或 uWSGI只要它们能加载你的application对象。但反过来如果你用 Flask你得额外写一个wsgi.py文件来暴露application还得确保所有配置如数据库连接池在 WSGI 模式下正确初始化——这正是很多新手部署失败的根源开发时一切正常一换服务器就报RuntimeError: Working outside of application context。提示CherryPy 的cherrypy.tree.graft()方法就是专门用来把任意 WSGI 应用包括 Flask、Django、Bottle 的application挂载到 CherryPy 服务器上的。我们曾用它把一个遗留的 Flask 数据导出接口无缝集成进主 CherryPy 后台系统共享同一套认证中间件和日志格式零代码修改。2.2 Nginx 的不可替代性不只是反向代理更是“网络层守门员”为什么一定要在 CherryPy 前面加 Nginx答案不是“因为大家都这么干”而是有非常具体的、可量化的工程理由SSL 终止SSL TerminationCherryPy 虽然支持 HTTPS但它把证书私钥、TLS 握手、HTTP/2 升级都交给 Python 解释器处理这对 CPU 是巨大负担。Nginx 使用 OpenSSL 的 C 语言实现握手性能是 Python 的 5~8 倍。更重要的是Nginx 可以缓存 TLS 会话票据Session Tickets让重复连接免去完整握手这对移动端、IoT 设备频繁重连的场景至关重要。静态文件零拷贝分发CherryPy 的tools.staticdir是 Python 层读取文件再写入 socket涉及多次内存拷贝。Nginx 的sendfile()系统调用可直接在内核态完成磁盘到网卡的数据搬运CPU 占用降低 70% 以上。我们一个带 200KB JS/CSS 的管理后台用 CherryPy 直出静态资源时100 并发下 CPU 达到 92%换 Nginx 后稳定在 12%。请求体大小硬限制413 错误根源标题热词里高频出现的the server responded with a status of 413(request entity too large)90% 以上源于 Nginx 默认client_max_body_size 1m。CherryPy 本身对 POST 数据没有硬限制它把原始字节流交给你的 handler 处理。但 Nginx 在代理前就拦截了超大请求体根本不会转发给后端。这个错误永远不可能在 CherryPy 日志里看到只能在 Nginx 的error.log里查到413 Request Entity Too Large。这是新手最常踩的坑拼命调 CherryPy 的request.body.maxbytes却忘了 Nginx 这道关。连接管理与缓冲BufferingCherryPy 的 WSGI 服务器是同步阻塞模型每个请求独占一个线程。当客户端如慢速移动网络上传大文件时线程会长时间阻塞在recv()上。Nginx 的proxy_buffering on可以先把整个请求体缓存在磁盘或内存再以高速、稳定的速率推给 CherryPy释放 CherryPy 线程资源。同时proxy_buffers和proxy_busy_buffers_size参数决定了缓冲区大小直接影响吞吐。安全加固Nginx 可以轻松实现limit_req按 IP 限速防暴力探测deny/allowIP 白名单内网管理后台必备add_header X-Frame-Options DENY防点击劫持add_header X-Content-Type-Options nosniff防 MIME 类型嗅探client_header_timeout 10s防 Slowloris 攻击这些能力如果全靠 CherryPy 的tools插件实现要么性能极差如用 Python 正则匹配 User-Agent 防爬要么根本做不到如内核级的连接超时。2.3 对比其他主流组合为什么不是 Flask uWSGI为什么不是 FastAPI Uvicorn维度CherryPy NginxFlask uWSGIFastAPI Uvicorn内存占用空应用~12MB (CherryPy) ~8MB (Nginx) 20MB~25MB (uWSGI master) ~15MB (worker×2) 55MB~30MB (Uvicorn) ~8MB (Nginx) 38MB启动时间冷启动 0.3s纯 Python 加载 1.2suWSGI 加载 C 扩展、fork 进程 0.5sasyncio 事件循环调试友好性日志清晰错误堆栈直指app.py行号uWSGI 日志层级深需配置--log-date和--log-encoder才易读Uvicorn 日志简洁但异步 traceback 有时难定位Windows 兼容性原生支持无依赖uWSGI 在 Windows 上需 Cygwin 或 WSL官方不推荐Uvicorn 在 Windows 上 asyncio 性能下降约 30%学习曲线极低cherrypy.quickstart(MyApp())即可运行中需理解 uWSGI 配置文件、socket 权限、进程模型中高需理解 async/await、event loop、Starlette 生命周期适用场景内部工具、IoT 网关、中小流量 API、快速原型传统企业 Web 应用、需要复杂插件生态如 uWSGI 的 spooler高并发实时 API、WebSocket、需要 OpenAPI 自动生成我之所以坚持推荐 CherryPy Nginx核心在于它的“确定性”。Flask/uWSGI 组合你永远要担心ImportError: No module named uwsgiFastAPI/Uvicorn 组合你可能在某个特定版本遇到RuntimeWarning: coroutine Lifespan.on_startup was never awaited。而 CherryPy 的wsgiserver是纯 Python 实现没有 C 扩展没有外部依赖pip install cherrypy后import cherrypy必成功。这种确定性在自动化部署、CI/CD 流水线、老旧 Linux 发行版如 CentOS 6上价值千金。3. 核心细节解析与实操要点从代码结构到配置文件的每一处关键3.1 CherryPy 应用的最小可行结构不是“写网站”而是“定义 WSGI callable”一个能被 Nginx 反向代理的 CherryPy 应用其本质就是一个符合 WSGI 规范的 Python 模块里面必须有一个名为application的可调用对象callable。这个对象可以是函数、类实例或者模块级变量。但为了可维护性和 CherryPy 特性如工具链、配置我们采用标准模式# app.py import cherrypy class HelloWorld: cherrypy.expose def index(self): return Hello, World from CherryPy! cherrypy.expose def api_data(self): # 模拟一个 JSON API cherrypy.response.headers[Content-Type] application/json return {status: ok, data: [1, 2, 3]} if __name__ __main__: # 仅用于本地开发测试 cherrypy.quickstart(HelloWorld(), /, server.conf) else: # 生产环境 WSGI 模式此模块被 Nginx uWSGI/Gunicorn 加载时__name__ ! __main__ # 所以我们显式创建 application 对象 application cherrypy.Application(HelloWorld(), script_name, configapp.conf)关键点解析if __name__ __main__:分支这是开发时的快捷入口。cherrypy.quickstart()会自动创建cherrypy.engine并启动内置 WSGI 服务器。server.conf是开发服务器配置。else:分支这是生产部署的核心。当 Nginx 配合 uWSGI 或 Gunicorn 加载此模块时Python 解释器执行的是import app此时__name__是app所以进入else。我们创建cherrypy.Application实例并赋值给application这就是 WSGI 规范要求的 callable。cherrypy.Application(...)的三个参数第一个你的根应用类实例HelloWorld()第二个script_name通常为空字符串表示应用挂载在根路径/。如果 Nginx 配置了location /myapp/这里就要写/myapp否则 CherryPy 会把/myapp/api/data当作/api/data处理。第三个配置文件路径app.conf这是 CherryPy 的核心它定义了应用的行为而非服务器行为。注意cherrypy.Application和cherrypy.tree.mount()是两回事。mount()是在已有的 CherryPy 引擎上挂载子应用适用于一个 CherryPy 进程跑多个服务而Application是一个独立的、可被外部 WSGI 服务器加载的“应用容器”这才是生产部署的标准做法。3.2 CherryPy 配置文件详解app.conf里的 7 个必调参数CherryPy 的配置分为两个层面全局配置Global Config和应用配置Application Config。app.conf文件属于后者它只影响cherrypy.Application实例内的行为。一个健壮的app.conf至少包含以下 7 个参数每个都对应一个真实痛点# app.conf [/] # 1. 关闭开发模式开启生产模式 environment production # 2. 设置日志级别避免 info 级别日志刷屏 log.screen False log.access_file /var/log/cherrypy/access.log log.error_file /var/log/cherrypy/error.log # 3. 严格控制请求体大小与 Nginx 的 client_max_body_size 对齐 request.body.maxbytes 10485760 # 10MB单位字节 # 4. 设置请求超时防止慢速攻击耗尽线程 server.socket_timeout 60 # 5. 设置响应超时防止后端服务如数据库hang 住整个线程 response.timeout 30 # 6. 启用 gzip 压缩但只对文本类型生效 tools.gzip.on True tools.gzip.mime_types [text/html, text/plain, text/css, text/javascript, application/javascript, application/json] # 7. 关键禁用 CherryPy 的自动重定向避免与 Nginx 的 location 产生冲突 tools.trailing_slash.on False逐条解释environment production这是开关。设为production后CherryPy 会自动关闭show_tracebacks不显示详细错误页面、关闭autoreload不监控文件变化、关闭tools.sessions.on除非你显式开启。很多新手部署后看到 500 错误页面上全是 Python 堆栈就是因为忘了这行。log.*配置log.screen False是必须的。在守护进程模式下print()和sys.stdout会被重定向导致日志丢失。所有日志必须写入文件。access_file和error_file的路径必须由你手动创建并赋予cherrypy用户通常是www-data或nginx写权限sudo mkdir -p /var/log/cherrypy sudo chown www-data:www-data /var/log/cherrypy。request.body.maxbytes这是 CherryPy 层的请求体限制。它必须小于等于Nginx 的client_max_body_size。例如Nginx 设为20mCherryPy 就设为10m。这样如果用户上传 15MB 文件Nginx 会先拦截并返回 413如果 Nginx 配错了比如设成了1m而 CherryPy 设了10m那么 Nginx 拦截后CherryPy 根本收不到请求你永远看不到 CherryPy 日志里的任何记录。这个参数是双保险的关键。server.socket_timeout这是 TCP 连接层面的超时。从客户端建立 TCP 连接开始计时如果 60 秒内没有收到完整的 HTTP 请求头连接将被关闭。这能有效防御 Slowloris 类攻击。response.timeout这是应用响应层面的超时。从 CherryPy 开始处理请求即你的index()方法开始执行起计时如果 30 秒内没有返回响应CherryPy 会主动断开连接并记录Response timeout错误。这能防止一个慢 SQL 查询拖垮整个线程池。tools.gzipCherryPy 的 gzip 是 Python 实现压缩率不如 Nginx 的 zlib但胜在简单。我们只对明确的文本 MIME 类型启用避免对图片、PDF 等二进制文件做无意义压缩。注意如果 Nginx 也开启了gzip on两者会叠加但通常 Nginx 的压缩更高效所以建议只在 Nginx 层开启 gzipCherryPy 层关闭保持单一责任。tools.trailing_slash.on False这是最隐蔽的坑。CherryPy 默认会将/api重定向到/api/加斜杠这是为了兼容目录式 URL。但 Nginx 的location /api/规则会把/api当作不同路径处理。结果就是你在浏览器访问/apiCherryPy 301 重定向到/api/Nginx 再次匹配location /api/又转发给 CherryPy形成无限重定向循环。关掉它让路径匹配完全由 Nginx 控制。3.3 Nginx 配置文件核心段/etc/nginx/sites-available/myappNginx 的配置是部署成败的咽喉。一个典型的myapp配置文件如下假设应用监听在127.0.0.1:8080# /etc/nginx/sites-available/myapp upstream cherry_py_backend { server 127.0.0.1:8080; # 如果 CherryPy 启动了多个进程如用 supervisord 管理可以加更多 server 行 # server 127.0.0.1:8081; # server 127.0.0.1:8082; } server { listen 80; server_name myapp.example.com; # 1. 全局请求体大小限制必须 client_max_body_size 20m; # 2. 根路径代理到 CherryPy location / { proxy_pass http://cherry_py_backend; 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; # 3. 关键缓冲设置 proxy_buffering on; proxy_buffers 8 16k; # 8 个缓冲区每个 16KB proxy_busy_buffers_size 32k; # 忙碌时最多使用 32KB proxy_buffer_size 4k; # 专门存放响应头的缓冲区 # 4. 超时设置必须大于 CherryPy 的 server.socket_timeout proxy_connect_timeout 60s; proxy_send_timeout 120s; proxy_read_timeout 120s; # 5. 静态文件交由 Nginx 处理如果 CherryPy 不托管 # location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { # expires 1y; # add_header Cache-Control public, immutable; # } } # 6. 可选为健康检查提供一个轻量 endpoint location /healthz { return 200 OK; add_header Content-Type text/plain; } }核心参数详解upstream块定义后端服务器组。即使你只用一个 CherryPy 实例也必须用upstream因为proxy_pass必须指向一个 upstream 名称或 IP:PORT。upstream提供了负载均衡least_conn、健康检查max_fails3 fail_timeout30s的基础。client_max_body_size 20m这是解决413 Request Entity Too Large的唯一位置。必须放在server块顶层不能放在location里除非你想为某个路径单独设限。单位可以是m兆字节、k千字节、g吉字节。proxy_set_header系列这是让 CherryPy 知道“真实用户是谁”的关键。X-Real-IP和X-Forwarded-For让 CherryPy 的cherrypy.request.remote.ip返回客户端真实 IP而不是127.0.0.1。X-Forwarded-Proto告诉 CherryPy 当前是http还是https这对生成绝对 URL如 OAuth 回调地址至关重要。proxy_buffering on及相关参数这是性能核心。proxy_buffers 8 16k表示 Nginx 会为每个连接分配最多 8 个 16KB 的缓冲区共 128KB来暂存 CherryPy 的响应。proxy_busy_buffers_size 32k表示当缓冲区被部分填满时最多允许 32KB 的数据处于“忙碌”状态即已发送给客户端但未确认。proxy_buffer_size 4k是专门留给响应头的缓冲区确保 header 不会和 body 混在一起。如果 CherryPy 响应很大如文件下载这些缓冲区会自动写入磁盘临时文件避免内存爆炸。proxy_*_timeout这三个超时必须精心设置。proxy_connect_timeout是 Nginx 连接 CherryPy 的超时应略大于 CherryPy 的server.socket_timeout60s。proxy_send_timeout是 Nginx 向 CherryPy 发送请求的超时proxy_read_timeout是 Nginx 从 CherryPy 读取响应的超时两者都应大于 CherryPy 的response.timeout30s留出网络传输余量。设得太小会导致 Nginx 在 CherryPy 还没处理完时就断开连接返回 504 Gateway Timeout。location /healthz这是一个运维最佳实践。Kubernetes、Consul、甚至简单的 shell 脚本都可以用curl -f http://localhost/healthz来检查服务是否存活。它不经过 CherryPy由 Nginx 直接返回毫秒级响应是真正的“心跳”。实操心得我曾经在一个客户现场发现所有 API 响应都慢 2 秒。排查了 CherryPy 代码、数据库、网络最后发现是 Nginx 的proxy_read_timeout设成了5s而 CherryPy 的response.timeout是30s。当 CherryPy 处理一个 6s 的请求时Nginx 在 5s 后就断开了连接CherryPy 的线程还在傻等直到 30s 后才超时。把proxy_read_timeout改成35s问题立刻消失。这个教训告诉我Nginx 和 CherryPy 的超时参数必须形成一个有冗余的、递增的链条而不是随意填写。4. 实操过程与核心环节实现从零开始部署一个可访问的 Hello World4.1 环境准备Ubuntu 22.04 LTS 上的最小化安装我们以 Ubuntu 22.04 为例CentOS/RHEL 类似只需替换apt为dnf。全程使用普通用户非 root仅在必要时用sudo。步骤 1安装 Nginx 和 Python3-pip# 更新源并安装基础包 sudo apt update sudo apt install -y nginx python3-pip python3-venv # 启动并启用 Nginx此时应能看到 Welcome to nginx! 页面 sudo systemctl start nginx sudo systemctl enable nginx步骤 2创建项目目录和虚拟环境# 创建项目根目录 mkdir -p ~/myapp/{logs,static} cd ~/myapp # 创建 Python 虚拟环境隔离依赖避免污染系统 Python python3 -m venv venv source venv/bin/activate # 升级 pip 到最新版 pip install --upgrade pip # 安装 CherryPy pip install cherrypy18.8.0 # 指定稳定版避免新版本 breaking change注意CherryPy 18.x 是最后一个支持 Python 3.6 的稳定系列19.x 开始要求 Python 3.8。如果你的系统是旧版 Ubuntu如 18.04请用pip install cherrypy18.8.0。不要盲目pip install cherrypy最新版可能引入不兼容变更。步骤 3编写应用代码和配置文件创建app.pycat app.py EOF import cherrypy class HelloWorld: cherrypy.expose def index(self): return h1Hello, World from CherryPy!/h1 pThis is a production-ready deployment behind Nginx./p pCurrent time: {}/p .format(cherrypy.serving.start_time.strftime(%Y-%m-%d %H:%M:%S)) cherrypy.expose def api_data(self): cherrypy.response.headers[Content-Type] application/json return {status: ok, timestamp: cherrypy.serving.start_time.strftime(%Y-%m-%d %H:%M:%S) } if __name__ __main__: cherrypy.quickstart(HelloWorld(), /, server.conf) else: application cherrypy.Application(HelloWorld(), script_name, configapp.conf) EOF创建app.confCherryPy 应用配置cat app.conf EOF [/] environment production log.screen False log.access_file /home/$(whoami)/myapp/logs/access.log log.error_file /home/$(whoami)/myapp/logs/error.log request.body.maxbytes 10485760 server.socket_timeout 60 response.timeout 30 tools.gzip.on False tools.trailing_slash.on False EOF创建server.conf仅用于本地测试cat server.conf EOF [global] server.socket_host 127.0.0.1 server.socket_port 8080 server.thread_pool 10 log.screen True log.access_file log.error_file EOF步骤 4测试 CherryPy 本地运行# 激活虚拟环境 source venv/bin/activate # 运行 CherryPy 开发服务器 python app.py # 此时应看到类似输出 # [12/Jan/2024:10:23:45] ENGINE Listening for SIGHUP. # [12/Jan/2024:10:23:45] ENGINE Listening for SIGTERM. # [12/Jan/2024:10:23:45] ENGINE Listening for SIGUSR1. # [12/Jan/2024:10:23:45] ENGINE Bus STARTING # [12/Jan/2024:10:23:45] ENGINE Started monitor thread _TimeoutMonitor. # [12/Jan/2024:10:23:45] ENGINE Serving on http://127.0.0.1:8080 # [12/Jan/2024:10:23:45] ENGINE Bus STARTED打开浏览器访问http://127.0.0.1:8080应看到 Hello World 页面。按CtrlC停止。4.2 Nginx 配置与启用让公网可访问步骤 1创建 Nginx 站点配置# 创建站点配置文件 sudo tee /etc/nginx/sites-available/myapp EOF upstream cherry_py_backend { server 127.0.0.1:8080; } server { listen 80; server_name localhost; client_max_body_size 20m; location / { proxy_pass http://cherry_py_backend; 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_buffering on; proxy_buffers 8 16k; proxy_busy_buffers_size 32k; proxy_buffer_size 4k; proxy_connect_timeout 60s; proxy_send_timeout 120s; proxy_read_timeout 120s; } location /healthz { return 200 OK; add_header Content-Type text/plain; } } EOF步骤 2启用站点并测试配置# 创建符号链接启用站点 sudo ln -sf /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/myapp # 移除默认站点可选 sudo rm -f /etc/nginx/sites-enabled/default # 测试 Nginx 配置语法 sudo nginx -t # 应输出nginx: the configuration file /etc/nginx/nginx.conf syntax is ok # nginx: configuration file /etc/nginx/nginx.conf test is successful # 重新加载 Nginx不中断服务 sudo systemctl reload nginx步骤 3启动 CherryPy 作为守护进程现在Nginx 已经在监听80端口但 CherryPy 还没启动。我们需要让它以后台方式运行并随系统启动。最简单可靠的方式是使用systemd# 创建 systemd 服务文件 sudo tee /etc/systemd/system/cherrypy-myapp.service EOF [Unit] DescriptionCherryPy WSGI Application for myapp Afternetwork.target [Service] Typesimple User$(whoami) WorkingDirectory/home/$(whoami)/myapp ExecStart/home/$(whoami)/myapp/venv/bin/python /home/$(whoami)/myapp/app.py Restartalways RestartSec10 # 环境变量确保 Python 能找到虚拟环境 EnvironmentPATH/home/$(whoami)/myapp/venv/bin:/usr/local/bin:/usr/bin:/bin [Install] WantedBymulti-user.target EOF # 重载 systemd 配置 sudo systemctl daemon-reload # 启用并启动服务 sudo systemctl enable cherrypy-myapp.service sudo systemctl start cherrypy-myapp.service # 查看服务状态 sudo systemctl status cherrypy-myapp.service # 应看到 active (running)且没有报错注意ExecStart必须指向python app.py而不是python -m cherrypy。因为app.py里包含了if __name__ __main__:分支它会调用cherrypy.quickstart()从而启动内置 WSGI 服务器。-m cherrypy是另一种启动方式但需要额外的配置文件不如直接运行脚本直观。步骤 4最终验证与日志追踪现在打开浏览器访问http://localhost或你的服务器 IP应该看到 Hello World 页面。尝试访问http://localhost/api_data应得到 JSON 响应。如果失败请按以下顺序排查**检查 Nginx 是否在
