Current location - Quotes Website - Collection of slogans - Handling of Redirect Port Loss in Nginx
Handling of Redirect Port Loss in Nginx
Nginx is sometimes not as smart as apache, and its handling of redirection location is particularly bleak, so users can only handle the problem of non-standard ports manually.

For example, for various reasons, nginx can't listen to port 80, or the external address is not the standard http(s) port, so nginx can't handle these redirections well. When redirection occurs, the port will be lost.

For example, the following two reference examples:

When the browser requests it, it will find that the port number will be lost every time redirection occurs, causing the browser to access the wrong port.

In view of these two situations, the solutions are given respectively.

This is easy to handle. I don't know when that pile of proxy_set_header began to spread on the Internet, and almost all documents at home and abroad are like this bird without exception. Later, it was found that it was no problem to access gitlab-ce with non-standard ports. I took a look at gitlab-ce's nginx configuration and found that it was configured like this:

I also found the configuration file released by nginx software package, and found that it actually contains a reference file /etc/nginx/proxy_params.

Also said proxy _ set _ headerhost $ http _ host; , so directly included, done.

If you don't have this file, please manually type it into the location configuration section.

A closer look at the official document actually mentions:

This is tricky. For example, $document_root has a data/index.html file, but when accessing it, /data does not add/to indicate that it is accessing a directory. At this time, the server will perform 30 1 Moved permanent permanent redirect processing, but it is ridiculous that if nginx listens to non-standard ports, the location returned by 30 1 has no port number, resulting in

You can see this clearly with curl:

It can be clearly seen that Location has no port number, which is different from reverse proxy. So I searched everywhere on Google and finally found a solution in stackoverflow's Q&A:

This problem is solved by configuring the form of rewriting URL with port number.