在 nginx 中处理 cdn 回源路径重写，核心做法是在 `server` 块内使用 `location` 匹配请求 uri，并通过 `rewrite` 指令将带前缀的路径重定向到后端实际路径。具体操作是设置正则表达式捕获原始路径部分，并使用 `$1` 引用替换目标路径，同时配合 `break` 标志停止后续重写规则执行，确保请求被正确转发至上游服务器。
如何配置基础的回源路径映射
当 CDN 节点向源站发起请求时，通常会在 URL 中携带特定的前缀（如 `/cdn/`）以标识流量来源或进行资源隔离。为了将这些请求正确路由到源站的根目录或特定子目录，需要在 Nginx 配置中添加对应的 `location` 块。该块通过正则表达式提取前缀后的路径，并将其作为新的 URI 传递给后端服务。
server {
listen 80;
server_name example.com;
# 匹配 /cdn/ 开头的请求
location ~ ^/cdn/(.*)$ {
# 将 /cdn/path/to/file.js 重写为 /path/to/file.js
rewrite ^/cdn/(.*)$ /$1 break;
# 代理到后端应用
proxy_pass http://backend_app;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
上述配置中，`^/cdn/(.*)$` 是一个正则表达式，其中 `(.*)` 捕获了 `/cdn/` 之后的所有字符。`rewrite` 指令的目标 `/$1` 表示将捕获的内容拼接到根路径下。`break` 标志至关重要，它告诉 Nginx 一旦完成这次重写，就立即停止处理后续的 `rewrite` 规则，并继续执行当前的 `location` 块中的其他指令（如 `proxy_pass`）。如果不加 `break`，Nginx 可能会重新从 `server` 级别开始匹配，导致无限循环或错误的路由结果。`proxy_pass` 指向的后端地址应根据实际部署情况修改，例如 `http://127.0.0.1:8080`。
如何处理多级目录与静态资源缓存
在实际场景中，CDN 回源可能涉及多级目录结构，如 `/cdn/images/2023/05/logo.png`。此时，简单的单级重写可能不够灵活，需要更精确的正则表达式来保留完整的层级结构。此外，对于静态资源，通常还需要结合缓存控制头，以减少源站负载并提升响应速度。
server {
listen 80;
server_name example.com;
location ~ ^/cdn/(images|css|js)/(.*)$ {
# 保留二级分类和剩余路径
rewrite ^/cdn/(images|css|js)/(.*)$ /static/$1/$2 break;
# 设置缓存头
expires 30d;
add_header Cache-Control "public, immutable";
# 代理到后端
proxy_pass http://backend_app;
proxy_set_header Host $host;
}
}
在这个例子中，正则表达式 `^/cdn/(images|css|js)/(.*)$` 明确指定了允许的媒体类型（`images`、`css`、`js`），并将它们映射到源站的 `/static/` 目录下。`$1` 代表媒体类型，`$2` 代表具体的文件路径。这种写法增强了安全性，防止非法路径被重写。`expires 30d` 和 `add_header` 指令用于设置 HTTP 缓存策略，告知客户端和中间节点可以缓存这些资源长达 30 天，且内容不可变。这有助于减轻源站在高并发下的压力。注意，`proxy_pass` 仍然指向同一个后端，但 Nginx 会根据重写后的路径向后端发送请求，后端需能识别 `/static/` 开头的路径并返回相应资源。
当 CDN 回源路径包含特殊字符时会发生什么
如果 CDN 回源的路径中包含 URL 编码的特殊字符（如 `%20` 代表空格，`%2F` 代表斜杠），Nginx 的 `rewrite` 模块默认不会自动解码这些字符。这意味着 `$1` 捕获的值仍然是编码后的字符串。如果后端应用期望接收解码后的路径，可能会导致 404 错误或逻辑异常。此时，需要借助 `ngx_http_sub_module` 或后端应用自身来处理解码，或者在 Nginx 中使用 `unescape` 变量（如果可用）。
考虑以下场景：请求 URI 为 `/cdn/file%20name.txt`。在之前的配置中，`$1` 的值将是 `file%20name.txt`。如果后端应用直接使用该值作为文件名，它可能会查找名为 `file%20name.txt` 的文件，而不是 `file name.txt`。为了解决这个问题，可以在 `proxy_pass` 之前使用 `sub_filter` 或依赖后端框架的 URL 解码功能。另一种方法是使用 `map` 指令预处理 URI，但这会增加配置复杂度。通常情况下，建议在后端应用中统一处理 URL 解码，以确保一致性。例如，在 Node.js 或 Python Flask 中，路由处理器会自动解码路径参数。因此，Nginx 层面的主要任务是确保路径结构正确，而字符解码则由后端负责。
