记我配置Nginx代理的遭遇

我一直觉得自己的Nginx知识还算过得去，可是我错了，配置Nginx代理的遭遇让我苦不堪言，即便如此，我还是挣扎着记录一二，以便让后来者能够踩着我的足迹继续前进。

说起来非常简单：某项目的搜索功能升级了，需要把请求从旧的服务代理到新的服务上面去，其中有点儿不一样的地方是参数的传递形式发生的变化，例子如下：

旧：http://www.old.com/query/lamp
新：http://www.new.com/search?q=lamp
第一次尝试：

location ~ ^/query/(.+) {
    proxy_pass http://www.old.com/search?q=$1;
}
可惜当测试的时候发现在错误日志里出现如下信息：

no resolver defined to resolve …

大概意思是说没有配置resolver指令来解析域名。我就奇怪了：印象中以前用proxy_pass的时候没配置resolver也能工作啊？带着疑问搜索了一下，发现这是一个老坑了，其原因在于如果代理地址中包含变量的话，那么必须配置resolver指令！

第二次尝试：

因为我不太喜欢在Nginx配置文件里硬编码resolver指令，所以我想既然问题出现在变量身上，那么只要想办法把变量从代理地址中移除应该就可以了：

location ~ ^/query/(.+) {
    set $args $args&q=$1;
    proxy_pass http://www.old.com/search;
}
可惜当我重启Nginx的时候发现出错了：

“proxy_pass” cannot have URI part in location given by regular expression, or inside named location, or inside “if” statement, or inside “limit_except” block …

大概意思是说在如下情况下，proxy_pass指令不能包含URI，相关情况分别是：正则表达式location；命名location；if；limit_except。本例正好用到了正则。

第三次尝试：

既然URI的存在妨碍了我们，那么就想办法从代理地址中移除它：

location ~ ^/query/(.+) {
    rewrite . /search?q=$1 break;
    proxy_pass http://www.new.com;
}
事不过三，我想这次应该成功了吧，可惜事与愿违，代理过后查询变量消失了！原因是正则表达式location中的变量无法直接在rewrite指令中使用。

第四次尝试：

在QQ群里描述了一下自己悲惨的遭遇，大家都很高兴，好在有朋友提醒我试试set：

location ~ ^/query/(.+) {
    set $q $1;
    rewrite . /search?q=$q break;
    proxy_pass http://www.new.com;
}
终于工作了，眼泪哗哗的，不过历史不止一次教育我不要高兴的太早，很快我就发现编码问题，具体点来说就是location中的字符串是解码（urldecode）的，当以此做正则匹配获取查询关键字后再发起代理请求，肯定就出问题了。

第五次尝试：

解决的关键在于数据必须是编码（urlencode）的，改变一下使用正则的位置：

location /query/ {
    if ($request_uri ~ "/query/([^?]+)") {
        set $q $1;
        rewrite . /search?q=$q break;
    }
    proxy_pass http://www.new.com;
}