nginx 的 proxy_pass 处理带有特殊字符的请求路径时，核心机制是自动对 uri 中的保留字符进行 url 编码（percent-encoding），但不会改变已编码的序列。当请求进入 nginx 时，nginx 会解析 uri，如果路径中包含空格、中文或斜杠等需要转义的字符，nginx 会在转发给后端之前将其转换为标准的百分号编码格式（如空格变为 %20）。这种处理是透明的，开发者无需在 nginx 配置中手动编写复杂的正则替换规则，只需确保后端应用能正确解码即可。
proxy_pass 如何自动编码未处理的特殊字符
当使用 proxy_pass 且不带 URI 部分时，Nginx 会将客户端请求的完整 URI 原样传递给后端，但在此过程中会对非 ASCII 字符和某些保留字符进行编码。例如，如果客户端请求 /path/with space/file.txt，Nginx 会自动将其转换为 /path/with%20space/file.txt 再发送给后端。这种行为符合 HTTP 规范，确保了数据在传输过程中的完整性。需要注意的是，Nginx 不会对已经经过编码的字符再次编码，这避免了双重编码的问题。
server {
listen 80;
server_name example.com;
location /api/ {
# 不带 URI 的 proxy_pass
# 请求 /api/search?q=hello world 会被转发为 http://backend/api/search?q=hello%20world
proxy_pass http://backend_server;
}
}上述配置展示了基本的 proxy_pass 用法。当客户端发送包含空格的查询参数或路径时，Nginx 会在内部处理编码，而后端服务器接收到的则是编码后的字符串。这种处理方式简化了开发者的工作，因为不需要在 Nginx 层面对每个可能的特殊字符进行单独处理。
带 URI 的 proxy_pass 如何处理路径重写与编码
当 proxy_pass 指令后跟随了 URI 路径时，Nginx 会用该 URI 替换客户端请求 URI 中与 location 匹配的部分。在这个过程中，特殊字符的处理逻辑依然遵循自动编码原则，但路径的重写可能会影响最终发送给后端的路径结构。例如，如果 location 是 /old/ 而 proxy_pass 是 http://backend/new/，那么请求 /old/path with space 会被转换为 /new/path%20with%20space。这种替换操作是在编码之前进行的，因此原始路径中的特殊字符会在替换后被正确编码。
server {
listen 80;
server_name example.com;
location /old/ {
# 带 URI 的 proxy_pass
# 请求 /old/search?q=hello world 会被转发为 http://backend/new/search?q=hello%20world
proxy_pass http://backend_server/new/;
}
}在这个例子中，/old/ 被替换为 /new/，而剩余的路径部分 search?q=hello world 则被附加在后面。由于 proxy_pass 的 URI 部分是固定的，Nginx 会自动对附加部分的特殊字符进行编码。这种机制允许开发者灵活地调整请求路径，同时保持特殊字符的正确处理。
后端应用如何接收和处理这些编码后的路径
后端应用在接收到 Nginx 转发过来的请求时，通常会看到已经过 URL 编码的路径和参数。大多数现代 Web 框架和语言库都提供了自动解码的功能，能够将这些编码后的字符串还原为原始内容。例如，在 Python 的 Flask 框架中，request.args.get('q') 会自动解码查询参数，返回 hello world。在 Node.js 的 Express 框架中，req.query.q 同样会自动处理解码。开发者在使用这些框架时，通常不需要手动调用解码函数，除非有特殊需求。
