В nginx - Когда я устанавливаю отправку заголовка хоста для восходящего сервера на $ proxy_host URL-адрес изменяется в браузере на восходящий URL-адрес
Когда я устанавливаю для заголовка хоста, отправляемого на вышестоящий сервер, значение $ proxy_host, я получаю запрошенную страницу, но URL-адрес изменяется в браузере на исходный URL-адрес.
...
proxy_set_header Host $proxy_host;
proxy_pass ...
вышеуказанное работает нормально, за исключением того, что URL-адрес в браузере изменяется и показывает исходный URL-адрес вместо URL-адреса, введенного пользователем - мы хотим, чтобы отображался URL-адрес пользователя
Чтобы исправить это Когда я отправляю вместо этого $ host, в браузере появляется сообщение об отказе в соединении.
...
proxy_set_header Host $host;
proxy_pass ...
Это означает, что в соединении было отказано - я не уверен, генерируется ли эта ошибка nginx или моим вышестоящим сервером . Я не очень сильно контролирую то, что ожидает вышестоящий сервер, так как это вызов хранилища s3 (объектного хранилища) через http на DO.
Есть ли способ определить, откуда исходит ошибка, и если она из вышестоящего сервер, как я могу сделать так, чтобы пользователь получал тот же URL-адрес в своем браузере, передавая $ proxy_host вышестоящему потоку?
Влияет ли передача $ proxy_host на восходящий поток на браузер пользователя? По какому механизму ?? Должно ли это повлиять не только на то, что идет на вышестоящий сервер? Почему меняется поведение браузера? Кто-нибудь может пролить свет на это поведение? Заранее благодарим.
* РЕДАКТИРОВАТЬ - включая полный контекст сервера ниже по запросу:
server {
listen 80;
server_name example.com;
location / {
rewrite ^(.*)/$ $1/index.html break;
rewrite ^(.*/[^./]+)$ $1/index.html break;
proxy_set_header Host $proxy_host;
proxy_pass http://someotherexample.com;
}
}
Это не имеет ничего общего с конфигурацией прокси и явно настроено на стороне восходящего потока.
В общем, ваш исходный пост содержит несколько описанных проблем, поэтому вам следует разделить их на несколько вопросов . На большинство из них можно было ответить, просто открыв стандартную документацию на http://nginx.org/en/docs/ .
Тайна разгадана! Публикация здесь, чтобы это могло помочь кому-то в подобной ситуации в любой момент в будущем ...
Проблема заключалась в том, что https «обновление» автоматически происходило в восходящем потоке и настраивал заголовки hsts. Эти заголовки передавались браузеру на стороне клиента, вынуждая его сделать еще один запрос с https, который мой серверный блок, прослушивающий порт 80, не обрабатывал, что вызывало аномалии.
Я изменил вызов proxy_pass на https, который решил проблему, потому что затем восходящий поток прекратил попытки принудительного применения https, отправив заголовки, из-за которых клиентская сторона работала неуверенно и делала неожиданные вещи. Теперь мой клиентский браузер по-прежнему выполняет http-вызов, который мы хотели как часть нашего общего дизайна, и мы получаем то, что хотели, в браузере, по-прежнему получая правильный контент в браузере, не показывая исходный URL-адрес в браузере.