在使用Nginx作为反向代理的时候,如果源服务返回了30x
(301、302、303、307等)返回码,需要用户再重新发送一次HTTP请求。但此时有可能出现用户不能直接访问重定向后的URL,就需要Nginx能自动进行重定向,读取新的URL后,通过200返回码返回真正的内容。
本文主要就是研究了怎么配置Nginx以实现这样的功能。
Ngnix提供了error_page
错误处理机制,允许用户在出现指定错误时进行自己的处理逻辑。
error_page 403 404 =200 /error.html;
location = /error.html {
root /data/www;
}
这样可以在出现403
、404
错误时返回error.html
页面的内容,同时用户看到的还是200
返回码。
事实上,error_page
也支持指定一个处理函数。
resolver 10.1.1.1;
location / {
proxy_pass http://xxx.com/;
error_page 301 302 303 = @handle_redirect;
}
location @handle_redirect {
proxy_pass $upstream_http_location;
}
这样Nginx就可以自动请求重定向后的URL了。
resolver 10.1.1.1;
这行是为了指定DNS服务器,否则会有no resolver defined to resolve xxx.com while sending to client
的报错。
但是如果请求重定向后的URL返回的还是30x
会怎样呢?按照现在的写法,Nginx并不会继续请求了。这种情况可以通过多次配置error_page
来解决。
location / {
proxy_pass http://xxx.com/;
error_page 301 302 303 = @handle_redirect;
}
location @handle_redirect {
proxy_pass $upstream_http_location;
error_page 307 = @handle_redirect_307;
}
location @handle_redirect_307 {
return 302 "http://yyy.com$upstream_http_location";
}
测试发现,现在这种写法并不会引起多次自动重定向,这是为什么呢?
这是因为Nginx默认只会处理一次错误码,要支持多次,需要添加以下配置项:
recursive_error_pages on;
Nginx最大的优势就是高效,如果自己实现服务来支持这个自动跳转特性的话,成本会增加,性能也不见得会比Nginx好。因此,对于这种场景,优先考虑通过配置Nginx来解决是最佳方案。