解决Nginx反向代理不会自动对特殊字符进行编码的问题

问题起因是利用Nginx做反向代理的时候，需要访问如下链接
http://192.168.14.141/iserver/services/3D-0524hd/rest/realspace/datas/0524hd/data/path/Tile_+003_+011/Tile_+003_+011_L5_00003.s3m
其中192.168.14.141被反向代理到了192.168.14.141:8090
实际请求的时候返回404，通过查看服务日志，发现服务器收到的Nginx请求确实是这个链接（注意后半部分）：

http://192.168.14.141/iserver/services/3D-0524hd/rest/realspace/datas/0524hd/data/path/Tile_+003_+011/Tile_+003_+011_L5_00003.s3m

如果我直接请求8090端口，服务器实际收到的请求是下面这样：

http://192.168.14.141/iserver/services/3D-0524hd/rest/realspace/datas/0524hd/data/path/Tile_%2B003_%2B011/Tile_%2B003_%2B011_L5_00003.s3m

’+’ 号应该被编码未‘%2B’，但是Nginx没有将其编码，导致请求404

手动将+号写成%2B请求到Nginx， Nginx请求目标服务器时还是以+号的形式请求。

解决办法：手动处理一下编码的问题

location /server {
set $modified_uri $request_uri;
if ($modified_uri ~ "^/([w]{2})(/.*)") {
set $modified_uri $1;
}
proxy_pass http://192.168.14.141:8090$modified_uri;
}

详见：https://stackoverflow.com/questions/31266629/nginx-encoding-normalizing-part-of-uri

附官方文档：

If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI:

如果proxy_pass没有指定具体的URI，那么请求Nginx的URI将原封不动的被转发到目标服务器。 即便是手动将+号编码，但是Nginx貌似会对其进行解码，最后发送出去的请求仍然是没有编码的。

最后

以上就是会撒娇乌龟最近收集整理的关于解决Nginx反向代理不会自动对特殊字符进行编码的问题的全部内容，更多相关解决Nginx反向代理不会自动对特殊字符进行编码内容请搜索靠谱客的其他文章。