nginx解码特殊字符引发400问题处理案例分享
问题背景和现象
公司任务管理使用的是开源的redmine，以前是单机部署（bitnami_redmine），后来由于项目数量、人员数量和任务数量的增加，卡顿问题比较明显，于是改造为基于k8s的分布式集群部署(nginx+puma)。
改造后有个现象是，wiki标题中，如果包含引号特殊字符，在打开页面时，redmine后台将返回400。
wiki标题如下：
400显示效果如下：
处理办法
方案1：替换数据库中的引号，替换为空
- 首先查出wiki标题，使用update进行修改。
这里仅为试验，没有使用MySQL的replace函数进行全局替换
- 之后去掉引用页wiki_content的引号
- 通过浏览器测试访问正常
小结：
此方案虽然可以通过update … replace … 进行全部替换wikis title字段，但由于redmine wiki页面可以在项目内进行引用(issue和其他wiki均可引用)，引用时内容较多，无法区分引号是否需要被替换，所以无法对wiki_contents以及journal_details表进行全局替换
方案2：找到参数丢失的根源
思路大致是先通过对比缩小范围，找到400是哪个节点返回的，之后再进一步分析具体原因。
- 1.首先看下nginx端是否正常接收到了参数，中文及特殊字符会进行urlencode，我们直接用转码后的结果在kibana中进行搜索
url.original : *%E4%B8%BB%E6%8E%A7%E6%9C%BA%E6%8A%A5%E9%94%99*可以看到参数到达nginx端时，还是对的，这很有可能是nginx再向后端svc传递时丢失了参数导致。
我们可以通过curl跳过nginx，直接测试svc地址能否正常返回。
- 2.先复制可以响应200的请求
- 3.在服务器上跳过nginx直接访问svc地址，url中增加引号字符(%22)，同时数据响应状态码-w %{http_code}
从上面的测试可以看出，跳过nginx转发，可以拿到正常的响应结果。
注：简单说明下，此前置nginx由于各类转发问题(比如cdn回源、oss图片转发等)没有使用nginx-ingress-controller暴露k8s集群中的服务，使用的是集群外置nginx。
- 4.返回400的请求，在rails日志中并没有看到处理过程
- 5.rails使用的是puma发布，查看puma日志，可以看到转换异常的错误
到这里基本可以定位到问题节点，处于nginx—>puma时，发送的http请求不被puma认可。
而curl发出的请求，是能被puma认可的。
那么区别到底在哪里？nginx发出的请求为何有差异？
查看nginx error日志没有线索，问题到这里已经陷入了困境，难道只能抓包分析下？
- 6.服务器上使用tcpdump抓包，期间触发两次请求，一次curl svc地址(响应200的)，一次curl nginx地址(响应400的)tcpdump -i cnio host 10.10.2.187 -w /tmp/1.pcap
- 7.从服务器传到本地用wireshark分析
从上面的对比可知，nginx收到浏览器发送的请求后，发现有urlencode后的字符%22，会进行解码后将引号传递到后端。
为何其他中文字符没有解码，唯独解码引号这一个字符？要弄清楚这个问题，需要结合nginx源码看一下。
- 8.如何避免这个问题？
正常情况下，uri的转义操作在浏览器端已经完成，所以nginx侧的$request_uri肯定是encode后的正确状态，这一点在文章开头中Kibana的access日志中可以看到。我们可以利用这个参数，对location进行特殊处理
修改前的配置如下
location / {
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://10.89.0.8/$1;
}修改后的配置如下
location / {
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
if ($request_uri ~* ^/(.*)$) {
proxy_pass http://10.89.0.8/$1;
}
}写在后面
nginx内置变量很多，配合location rewrite正则可以满足多种转发场景。
有其他解决思路的朋友可以留言哟~。