CherryPy + Nginx 生产部署：WSGI 应用轻量级高可用架构

1. 项目概述：为什么用 CherryPy 做 WSGI 应用的“内核”，再套一层 Nginx？

你是不是也遇到过这样的场景：写了个 Python Web 应用，本地用python app.py跑起来挺顺，但一上线就卡壳——用户访问慢、上传大文件直接报错 413、静态资源加载慢得像拨号上网、HTTPS 配置绕来绕去搞不定，甚至被扫出一堆安全警告？这不是你代码的问题，而是你少了一层“生产级护甲”。这个标题说的，就是一套经过十年以上线上验证、中小团队高频复用的轻量级部署组合：CherryPy 作为 WSGI 应用容器，Nginx 作为前置反向代理与静态资源网关。它不追求 Kubernetes 那种复杂度，也不依赖 Gunicorn+Supervisor 的多进程堆叠，而是在“够用、稳当、好调、易查”四个字上做到极致。

核心关键词里，“Python”是语言底座，“WSGI”是标准契约——它不是 CherryPy 独有的，而是所有合规 Python Web 框架（Flask、Django、FastAPI）都必须遵守的接口协议；“CherryPy”在这里不是当 Web 框架用，而是当一个极简、零依赖、自带 HTTP/1.1 完整实现的 WSGI 服务器用；“Nginx”则彻底剥离了应用逻辑，专注做它最擅长的事：抗并发、压请求、缓存、SSL 终结、路径重写、限流、日志切割。两者分工明确：CherryPy 只管把 Python 函数变成 HTTP 响应，Nginx 只管把用户请求精准、安全、高效地喂给 CherryPy，并把响应体干净利落地送出去。这种分层，直接规避了单进程阻塞、静态文件直出性能差、HTTP 头处理不规范等常见坑。我去年帮一家做教育 SaaS 的客户迁移旧系统，把原来裸跑的 Flask 应用换成这套结构后，首屏加载时间从 2.8 秒压到 420ms，上传 50MB 视频失败率从 17% 降到 0.3%，运维同学再也不用半夜爬起来 reload 进程了——因为 CherryPy 本身不 reload，Nginx reload 是毫秒级无感的。

它适合谁？不是大型互联网公司（他们早用 Envoy+K8s 了），而是：独立开发者、初创技术负责人、高校实验室项目维护者、内部工具平台搭建者、以及所有想用最少配置获得生产可用性的 Python 实践者。你不需要懂 Linux 内核参数调优，也不用背 nginx.conf 里上百个指令，只要理解“CherryPy 是应用引擎，Nginx 是交通警察”这个比喻，就能搭出一条稳定车道。接下来，我会带你从零开始，把这台车的发动机、变速箱、轮胎、灯光全部拆开看清楚，连螺丝拧几圈都告诉你。

2. 整体架构设计与选型逻辑：为什么不是 Gunicorn？为什么不是 uWSGI？为什么非得是 CherryPy + Nginx？

2.1 三层模型：应用层、容器层、网关层的职责切分

先画一张脑内架构图：最底层是你的 Python 业务代码（比如一个返回 JSON 的 API 或渲染 HTML 的页面），它必须符合 WSGI 协议——这意味着它得是一个可调用对象（函数或类实例），接收environ和start_response两个参数，并返回一个可迭代的响应体。中间层是 WSGI 容器，它的唯一任务就是加载你的应用、监听端口、解析 HTTP 请求、调用你的 WSGI 对象、组装响应头和响应体、发回给客户端。最上层是反向代理网关，它不碰你的 Python 代码，只做四件事：① 接收公网请求（80/443 端口）；② 根据规则（如/static/）决定是自己发文件，还是把请求转发给 CherryPy（比如http://127.0.0.1:8080）；③ 在转发前加/删/改 HTTP 头（如X-Real-IP,X-Forwarded-For）；④ 把 CherryPy 返回的响应原样或稍作处理后，发给用户。

这个分层不是为了炫技，而是为了解耦。举个实际例子：某天你发现用户上传头像特别慢，排查发现是 CherryPy 默认的max_request_body_size是 100MB，但 Nginx 默认client_max_body_size是 1MB，结果用户一传 2MB 图片，Nginx 就在入口拦下，返回 413 错误——问题根本不在 Python 代码，而在网关层配置。如果没分层，你得翻遍 CherryPy 文档、Flask 文档、甚至 Python socket 库源码去找原因。分层之后，问题域立刻缩小到nginx.conf里一行配置。这就是设计的价值。

2.2 CherryPy 作为 WSGI 容器的不可替代性

现在回答那个高频问题：为什么不用更流行的 Gunicorn？答案很实在：Gunicorn 是为多进程、高并发、长连接优化的，而 CherryPy 是为单进程、低延迟、调试友好、协议完整优化的。Gunicorn 默认启动多个 worker 进程，每个进程都要加载一遍你的应用代码、数据库连接池、缓存客户端——内存占用翻倍，冷启动变慢，调试时断点跳来跳去。CherryPy 默认单线程（可配多线程，但不推荐多进程），启动快（<100ms）、内存省（空载约 15MB）、日志清晰（每条请求带完整时间戳和状态码）。更重要的是，CherryPy 的 WSGI 适配器（cherrypy.wsgi.Server）是官方维护、全协议覆盖的，它正确实现了wsgi.file_wrapper、wsgi.input_terminated、wsgi.run_once等边缘字段，而很多轻量级 WSGI 服务器（比如某些 Flask 自带的 dev server）会忽略它们，导致在 Nginx 后面运行时出现Connection reset by peer或Incomplete response。

我实测过三组数据：同一台 2C4G 的阿里云 ECS，部署一个返回{"status": "ok"}的简单 API，用 wrk 压测：

• CherryPy（单线程）：QPS 3200，P99 延迟 12ms，内存峰值 28MB；
• Gunicorn（2 workers）：QPS 3800，P99 延迟 15ms，内存峰值 65MB；
• uWSGI（2 processes）：QPS 4100，P99 延迟 18ms，内存峰值 82MB。

差距只有 20% 左右，但 CherryPy 胜在确定性——它不会因为某个 worker 崩溃导致整个服务不可用（Gunicorn 有 master 进程兜底，但故障转移有毫秒级中断），也不会因为配置错一个--master参数就卡死（uWSGI 的配置地狱是出了名的）。对于中小流量、强调稳定性和可维护性的项目，CherryPy 的“保守”恰恰是优势。

2.3 Nginx 作为网关的刚性需求：不只是反向代理

很多人以为 Nginx 就是把请求转给 CherryPy，这是巨大误解。它承担着 CherryPy 根本不做的五项关键职能：

1. SSL/TLS 终结：CherryPy 虽然支持 HTTPS，但需要你手动加载证书、配置密码套件、处理 OCSP Stapling，而且它的 TLS 实现不如 Nginx 成熟。Nginx 用 OpenSSL 优化多年，支持 ALPN、HSTS、TLS 1.3，还能自动续签 Let's Encrypt 证书（配合 certbot）。

2. 静态资源托管：让 CherryPy 去读取/static/css/app.css文件并返回，是巨大的性能浪费。Nginx 直接从磁盘 sendfile() 零拷贝发出，比 Python 读文件快 5-10 倍。而且它能自动根据Accept-Encoding头返回.br（Brotli）或.gz（Gzip）压缩版本——这正是热搜词里“verify that web server is sending .br files with”所指的核心能力。

3. 请求体大小控制：CherryPy 的max_request_body_size控制的是它自己解析的请求体上限，但 Nginx 的client_max_body_size是在 TCP 层就拦截超大包，避免恶意攻击者用 1GB 数据耗尽 CherryPy 内存。两者必须协同，且 Nginx 的值必须 ≥ CherryPy 的值。

4. 连接管理：Nginx 维护着与用户的长连接（keepalive），而只用短连接与 CherryPy 通信。这样 CherryPy 不用维持大量空闲 socket，内存更可控；Nginx 则能复用连接，减少三次握手开销。

5. 安全加固：隐藏后端指纹（server_tokens off）、过滤危险 URL（location ~ \.php$ { return 403; }）、限制请求频率（limit_req）、防止目录遍历（aliasvsroot的区别）——这些都不是 CherryPy 的职责，硬塞进去只会让代码臃肿。

所以，这不是“能不能用”的问题，而是“该不该用”的工程判断。就像你不会让汽车发动机直接暴露在雨里，CherryPy 也需要 Nginx 这个“引擎盖”。

3. 核心细节解析与实操要点：从代码到配置，每一步都踩过坑

3.1 CherryPy 应用的 WSGI 兼容改造：三行代码定生死

假设你有一个现成的 Flask 应用app.py：

from flask import Flask app = Flask(__name__) @app.route('/') def hello(): return "Hello from Flask!"

它不能直接扔给 CherryPy 当 WSGI 应用跑，因为 Flask 的app对象虽然符合 WSGI，但 CherryPy 的 WSGI 服务器需要的是一个“可调用的模块级对象”，而不是一个需要flask run启动的脚本。改造只需三步：

第一步：剥离启动逻辑
把app.run()或任何if __name__ == '__main__':块全部删掉，确保app.py里只有app = Flask(...)和路由定义。这是基础，否则 CherryPy 加载时会直接执行run()，端口冲突。

第二步：导出 WSGI 应用对象
在app.py最底部，添加一行：

application = app # 这行是关键！CherryPy 通过这个名字加载

注意是application（小写），不是APP或App。这是 PEP 3333 规定的 WSGI 应用默认变量名。CherryPy 的wsgi.Server会自动查找这个符号。

第三步：创建 CherryPy 启动脚本server.py
不要在app.py里写 CherryPy 代码，单独建一个启动文件：

import cherrypy from app import application # 导入你的 WSGI 应用 # 配置 CherryPy 引擎 cherrypy.config.update({ 'server.socket_host': '127.0.0.1', # 只监听本地，不暴露公网 'server.socket_port': 8080, # 端口，必须和 Nginx upstream 一致 'server.thread_pool': 10, # 线程池大小，10 是中小流量黄金值 'server.max_request_body_size': 0, # 0 表示不限制，由 Nginx 控制 'log.access_file': '', # 关闭访问日志，由 Nginx 统一记录 'log.error_file': '/var/log/cherrypy/error.log', # 错误日志必须保留 }) # 挂载 WSGI 应用 cherrypy.tree.graft(application, '/') # 启动服务器 if __name__ == '__main__': cherrypy.engine.start() cherrypy.engine.block()

提示：server.max_request_body_size: 0是关键技巧。设为 0 表示 CherryPy 不做请求体大小检查，完全交给 Nginx 的client_max_body_size控制。这样避免双重校验导致的 413 错误。我曾在一个客户项目里，因为 CherryPy 设了 50MB，Nginx 设了 100MB，结果用户传 75MB 文件时 CherryPy 先报错，根本到不了 Nginx 层——血泪教训。

3.2 Nginx 配置的魔鬼细节：location 匹配顺序、root/alias 区别、gzip/brotli 开关

Nginx 配置不是复制粘贴就能用的，nginx.conf里最常出错的三个地方，我都给你标出来：

第一处：location匹配顺序陷阱
Nginx 的location是按最长前缀匹配，不是按书写顺序。比如你写了：

location /api/ { proxy_pass http://127.0.0.1:8080; } location / { root /var/www/html; }

你以为/api/xxx会走 proxy，其他走 root，但如果你的 CherryPy 应用根路径是/，那么/api/请求会被location /先匹配到，因为/是/api/的前缀，且长度更短但优先级更高（Nginx 规则是：精确匹配 > 最长前缀匹配 > 正则匹配）。正确写法是：

location /api/ { proxy_pass http://127.0.0.1:8080/api/; # 注意末尾斜杠！ } location / { root /var/www/html; }

或者更稳妥的，用=精确匹配首页：

location = / { root /var/www/html; index index.html; } location / { root /var/www/html; } location /api/ { proxy_pass http://127.0.0.1:8080/; }

第二处：root和alias的生死之别
root是拼接路径，alias是替换路径。比如：

location /static/ { alias /var/www/myapp/static/; # 请求 /static/css/app.css → 映射到 /var/www/myapp/static/css/app.css } # 如果写成 root： location /static/ { root /var/www/myapp; # 请求 /static/css/app.css → 映射到 /var/www/myapp/static/css/app.css }

表面一样，但alias结尾必须有/，root结尾不能有/。写错会导致 404。我见过最多的是alias /path/to/static（缺末尾/），结果 Nginx 去找/path/to/staticstatic/xxx，直接挂。

第三处：Brotli 压缩的启用条件
热搜词里反复出现 “verify that web server is sending .br files”，说明很多人配了但没生效。Brotli 需要三个条件同时满足：

1. Nginx 编译时启用了 Brotli 模块（Ubuntu 22.04+ 自带，CentOS 需yum install nginx-module-brotli）；
2. 在http块里开启：

   brotli on; brotli_comp_level 6; brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

3. 静态文件必须预压缩好。Nginx 不会实时压缩，它只在磁盘上找同名.br文件。所以你要用brotli -Z file.js生成file.js.br，放在和file.js同目录。Nginx 会自动根据Accept-Encoding: br头返回它。

注意：Brotli 和 Gzip 不能共存于同一location，否则可能冲突。建议只开 Brotli，它比 Gzip 压缩率高 15-20%。

3.3 安全与健壮性配置：413 错误、超时、日志、权限

生产环境不是跑通就行，得扛住真实流量。以下是我在 20+ 个项目里沉淀下来的最小安全集：

解决 413 Request Entity Too Large
这是热搜词里高频问题。根源永远在 Nginx，不是 Python。在http或server块里加：

client_max_body_size 100M; # 必须 ≥ CherryPy 的 max_request_body_size client_header_timeout 60; client_body_timeout 120; send_timeout 120;

超时联动配置
CherryPy 和 Nginx 的超时必须匹配，否则会出现upstream timed out。CherryPy 侧：

cherrypy.config.update({ 'server.socket_timeout': 60, # socket 空闲超时 'engine.timeout_monitor.on': True, 'engine.timeout_monitor.frequency': 60, })

Nginx 侧：

proxy_connect_timeout 60; proxy_send_timeout 120; proxy_read_timeout 120; proxy_buffering on; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k;

日志格式定制
默认日志看不出真实 IP（全是 127.0.0.1）。在http块定义新日志格式：

log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$request_time $upstream_response_time $http_x_forwarded_for'; access_log /var/log/nginx/access.log main;

并在location里透传头：

location / { 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_pass http://127.0.0.1:8080; }

权限最小化
绝对不要用root用户跑 CherryPy 或 Nginx。创建专用用户：

sudo useradd -r -s /bin/false cherrypy sudo useradd -r -s /bin/false nginx # 修改 CherryPy 日志路径属主 sudo chown cherrypy:cherrypy /var/log/cherrypy/ # Nginx 配置里指定用户 user nginx;

4. 实操过程与核心环节实现：从安装到上线，手把手复现

4.1 环境准备：Ubuntu 22.04 LTS 为例的完整命令流

我们以最主流的 Ubuntu 22.04 为例，全程使用apt，不编译源码（除非必要）。所有命令均经实测，复制即用：

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

sudo apt update && sudo apt upgrade -y sudo apt install -y python3-pip python3-venv curl wget gnupg2 ca-certificates

步骤 2：安装 Nginx 并验证

sudo apt install -y nginx sudo systemctl start nginx sudo systemctl enable nginx # 检查是否运行 curl -I http://localhost # 应返回 HTTP/1.1 200 OK

步骤 3：安装 Python 依赖与 CherryPy

# 创建项目目录 mkdir -p /opt/mywebapp/{src,logs} cd /opt/mywebapp # 创建虚拟环境（强制！避免系统 Python 污染） python3 -m venv venv source venv/bin/activate # 升级 pip 并安装 CherryPy pip install --upgrade pip pip install cherrypy # 验证 CherryPy 安装 python -c "import cherrypy; print(cherrypy.__version__)" # 应输出 18.8.0 或更高

步骤 4：部署应用代码

# 进入 src 目录放代码 cd src # 创建 app.py（以 Flask 为例） cat > app.py << 'EOF' from flask import Flask import os app = Flask(__name__) @app.route('/') def home(): return f"<h1>Hello from CherryPy+Nginx!</h1><p>Server: {os.getenv('HOSTNAME', 'unknown')}</p>" @app.route('/health') def health(): return {"status": "ok", "uptime": "1d"} application = app # WSGI 入口 EOF # 创建启动脚本 server.py cat > server.py << 'EOF' import cherrypy from app import application cherrypy.config.update({ 'server.socket_host': '127.0.0.1', 'server.socket_port': 8080, 'server.thread_pool': 10, 'server.max_request_body_size': 0, 'log.access_file': '', 'log.error_file': '/opt/mywebapp/logs/cherrypy_error.log', }) cherrypy.tree.graft(application, '/') cherrypy.engine.start() cherrypy.engine.block() EOF

步骤 5：配置 Nginx

# 备份默认配置 sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak # 创建新站点配置 sudo tee /etc/nginx/sites-available/mywebapp << 'EOF' upstream mywebapp_backend { server 127.0.0.1:8080; } server { listen 80; server_name example.com; # 替换为你的域名 root /var/www/html; # 静态资源直接由 Nginx 服务 location /static/ { alias /opt/mywebapp/src/static/; expires 1y; add_header Cache-Control "public, immutable"; } # API 请求转发给 CherryPy location / { proxy_pass http://mywebapp_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_connect_timeout 60; proxy_send_timeout 120; proxy_read_timeout 120; proxy_buffering on; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; } # 健康检查端点，不走代理 location /health { return 200 '{"status":"ok"}'; add_header Content-Type application/json; } } EOF # 启用站点 sudo ln -sf /etc/nginx/sites-available/mywebapp /etc/nginx/sites-enabled/ sudo nginx -t # 测试配置 sudo systemctl reload nginx

步骤 6：创建 CherryPy 启动服务（systemd）

# 创建服务文件 sudo tee /etc/systemd/system/cherrypy-mywebapp.service << 'EOF' [Unit] Description=CherryPy WSGI Server for MyWebApp After=network.target [Service] Type=simple User=cherrypy Group=cherrypy WorkingDirectory=/opt/mywebapp/src ExecStart=/opt/mywebapp/venv/bin/python /opt/mywebapp/src/server.py Restart=always RestartSec=10 StandardOutput=journal StandardError=journal SyslogIdentifier=cherrypy-mywebapp [Install] WantedBy=multi-user.target EOF # 重载 systemd 并启动 sudo systemctl daemon-reload sudo systemctl start cherrypy-mywebapp sudo systemctl enable cherrypy-mywebapp sudo systemctl status cherrypy-mywebapp # 应显示 active (running)

4.2 关键参数计算与选择依据：为什么是 10 个线程？为什么是 128k 缓冲区？

所有参数都不是拍脑袋定的，背后有计算逻辑：

CherryPythread_pool大小 = CPU 核心数 × 2 ~ 4
原理：Python 的 GIL（全局解释器锁）让多线程无法真正并行 CPU 密集型任务，但 Web 服务大部分时间在等待 I/O（数据库查询、HTTP 调用、文件读写）。此时线程会释放 GIL，让其他线程运行。所以线程数应略高于 CPU 核心数，以充分利用 I/O 等待间隙。一台 2 核机器，设 10 个线程是经验值——太少会排队，太多会增加上下文切换开销。我用htop观察过，2C 机器上 10 线程时 CPU 利用率稳定在 60-70%，线程切换次数 < 500/s；设到 20 线程时，CPU 利用率没涨，但切换次数飙到 2000/s，延迟反而上升。

Nginxproxy_buffer_size和proxy_buffers
proxy_buffer_size是存储响应头的缓冲区，必须 ≥ 后端返回的最大响应头大小。CherryPy 默认响应头约 2KB，设 128k 是冗余保险。proxy_buffers是存储响应体的缓冲区，4 256k表示 4 个缓冲区，每个 256KB，总 1MB。计算依据：平均响应体大小 × 并发请求数 × 0.7（缓冲区利用率）。假设平均响应 50KB，峰值并发 100，那么需要 50KB × 100 × 0.7 ≈ 3.5MB。但 Nginx 缓冲区是 per-connection 的，所以 1MB 是安全起点。如果日志里频繁出现*1023 upstream sent too big header while reading response header from upstream，就说明proxy_buffer_size太小，需增大。

client_max_body_size的设定
这不是越大越好。设 100M 是平衡点：足够上传高清视频、大 Excel，又不至于被恶意用户用 1GB 文件拖垮。计算公式：业务最大上传文件大小 × 1.2（冗余）。比如你允许用户上传 50MB 视频，就设60M。超过这个值，Nginx 直接返回 413，不传给 CherryPy，保护后端。

4.3 上线前必做检查清单：10 个动作，一个都不能少

部署不是systemctl start就完事，以下是上线前我必做的 10 项检查，漏一项都可能半夜告警：

1. 检查端口占用：sudo ss -tuln | grep ':80\|:443\|:8080'，确认 80/443 被 Nginx 占，8080 被 CherryPy 占，没有冲突。
2. 验证 Nginx 配置语法：sudo nginx -t，必须输出syntax is ok和test is successful。
3. 检查 CherryPy 日志：sudo tail -f /opt/mywebapp/logs/cherrypy_error.log，启动时应有Started HTTP server on 127.0.0.1:8080。
4. 本地 curl 测试 CherryPy：curl -I http://127.0.0.1:8080，应返回HTTP/1.1 200 OK，证明 CherryPy 独立工作正常。
5. 本地 curl 测试 Nginx 代理：curl -I http://localhost，应返回HTTP/1.1 200 OK，且Server头是nginx，不是CherryPy。
6. 检查响应头：curl -I -H "Accept-Encoding: br" http://localhost/static/test.js，应返回Content-Encoding: br，证明 Brotli 生效。
7. 测试大文件上传：用curl -F "file=@large.zip" http://localhost/upload，验证 413 是否在预期位置触发。
8. 检查日志权限：ls -l /var/log/nginx/ /opt/mywebapp/logs/，确保nginx和cherrypy用户有写权限。
9. 模拟高并发：用ab -n 1000 -c 100 http://localhost/压测 1 分钟，观察htop中 CPU、内存、Nginx worker 进程数是否稳定。
10. 检查防火墙：sudo ufw status，确保80/tcp和443/tcp是ALLOW状态（如果开了 UFW）。

5. 常见问题与排查技巧实录：那些年踩过的坑，都给你列成表

5.1 413 Request Entity Too Large：定位链路的黄金三问

这是热搜词里最高频问题，但 90% 的人查错方向。记住排查链路：用户 → Nginx → CherryPy。按顺序问三个问题：

实操心得：我有个客户，Nginx 配了100M，但 CherryPy 代码里写了cherrypy.config.update({'server.max_request_body_size': 50*1024*1024})，结果用户传 75MB 文件，Nginx 放行，CherryPy 拦截，日志里却只有一行ValueError，根本没打到 access log。后来我把 CherryPy 的值设为0，问题立解。所以，永远让 Nginx 做唯一入口校验，CherryPy 只负责业务逻辑。

5.2 502 Bad Gateway：不是 CherryPy 挂了，可能是连接没建好

502 意味着 Nginx 能连上 CherryPy 的地址，但 CherryPy 没返回合法 HTTP 响应。常见原因：

• CherryPy 没启动或端口不对：sudo ss -tuln \| grep :8080，确认有LISTEN状态。如果没输出，sudo systemctl status cherrypy-mywebapp看服务状态。
• CherryPy 绑定错了地址：检查server.py里server.socket_host是'127.0.0.1'，不是'0.0.0.0'（后者不安全）或'localhost'（DNS 解析可能失败）。
• Nginx upstream 地址写错：sudo nginx -T \| grep proxy_pass，确认是http://127.0.0.1:8080，不是http://localhost:8080（同样 DNS 风险）。
• SELinux 或 AppArmor 拦截：Ubuntu 一般没 SELinux，但 CentOS 有。临时关闭测试：sudo setenforce 0，如果好了，就需配策略。

5.3 静态文件 404：root/alias 和路径拼接的终极对照表

这是新手最容易懵的点。下面这张表，是我整理了 50+ 个失败案例后总结的：