1. Redirect loop
When we surf the Internet, sometimes we encounter the following errors prompted by the browser:
ERR_TOO_MANY_REDIRECTS
That is, too many redirects, this error prevents users from browsing the desired content.
Why does this error occur?
This error is usually caused by a misconfigured web server, a typical case being a redirect loop. For example: for two urls:
url_a
url_b
The web server configures the following redirects for url_a:
When the user requests url_a, redirect to url_b.
In this way, when the user visits url_a, the user's actual request url will change, and the request will jump from url_a to url_b.
At this point, if the web server also configures redirection for url_b:
When the user requests url_b, redirect to url_a.
In this way, a redirection loop will be generated: when the user accesses url_a, the user's actual request url will change, and the request will jump from url_a to url_b; after the request reaches url_b, it will jump to url_a again.
The above is a relatively simple and intuitive scenario for generating redirection loop errors. In a real-world scenario, redirect loops might not be so simple. For example, there may be more than two urls in the circular chain that causes redirection loops:
url_a > url_b > url_c > url_d > url_a
This obviously increases the difficulty of troubleshooting.
2. CDN and redirect loop
In my practical experience, there is another situation that is a problem with the CDN. When the CDN configuration is not compatible with the origin server configuration, a redirection loop will also be generated.
For example:
For the following sites:
For CDN acceleration, configure the origin site address as:
wwwcdn.site.com
Users can access the site through the following urls:
Custom Application Development Software for Business - Salesforce.com
Custom Application Development Software for Business - Salesforce.com
The difference between the above urls is only that the protocols used are different, one is http and the other is https.
Since the CDN is enabled, the user's request does not actually reach the source server directly, but is intercepted by the edge node of the CDN. According to the cache situation, the CDN edge node then requests the source server through the following url:
Similarly, the difference between the two back-to-source URLs of the CDN is only in the protocol. In fact, you can configure the protocol used by the CDN back-to-source. Based on performance considerations, it is usually configured to use the http protocol for the CDN back-to-source, which means that the CDN back-to-source uses the following url:
So far, a CDN-accelerated site is running normally.
Generation of redirection loop
Suppose there is a new requirement at this time, requiring users to use the https protocol to access the site. Of course, we can't force the user's browser to type https when entering the domain name. The solution is to do redirection. If the redirection is implemented on the source server, you need to modify the source server web configuration (nginx):
server {
listen 80;
listen 443 ssl;
server_name www.site.com wwwcdn.site.com;
ssl_certificate /etc/nginx/ssl/site.com.fullchain.cer;
ssl_certificate_key /etc/nginx/ssl/site.com.key;
access_log off;
root /home/site/guangzhuiyuan/appdownload/unipixel;
if ($scheme = http) {
rewrite "^/(.*)$" https://$server_name/$1 permanent;
}
...
}A rewrite command is added here, when the user uses the http protocol, it is forced to jump to the https protocol. However, when a user accesses the site using the following url:
Custom Application Development Software for Business - Salesforce.com
Browser prompt:
ERR_TOO_MANY_REDIRECTS
A redirection loop has appeared, let's sort out the request process:
1. A user accesses Custom Application Development Software for Business - Salesforce.com through a browser .
2. The request reaches the CDN.
3. The CDN returns to the origin through http://wwwcdn.site.com .
4. The origin server receives the request http://wwwcdn.site.com .
5. The source server performs redirection, and the user request is redirected to CDN - Home .
6. The request reaches the CDN.
7. The CDN returns to the origin through http://wwwcdn.site.com .
8. The origin server receives the request http://wwwcdn.site.com .
9. The source server performs redirection, and the user request is redirected to CDN - Home .
… …
Solution
After sorting it out, we can know that the core of the problem is that the CDN returns to the origin using the http protocol, and the origin server redirects the http protocol, triggering the user's second request, and causing the CDN to return to the origin again using the http protocol, and so on. The solution lies in breaking the circular chain.
method one:
The redirection from http to https on the client side is handled by the CDN, and the redirection is not performed on the source server.
Method Two:
The origin server is responsible for the redirection from http to https on the client side, and the CND back-to-origin protocol is changed to https.
Method three:
Split www.site.com and wwwcdn.site.com into two independent server configurations, do not place them in the same nginx server configuration block, and, www.site.com does redirection, wwwcdn.site.com does not redirect.