Re: Баланс Ирочка по имени хоста
On Mon, 03 Dec 2018 09:41:29 -0500 "firedragon" wrote: Привет, всем. Как я понял при получении запроса nginx дальше балансирует запрос на сервер iis по IP адресу. Можете подсказать как решить проблему? Привет. Вам нужно использовать директиву proxy_set_header Host $host; http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_set_header Разберитесь с этим. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Баланс Ирочка по имени хоста
Прикладывайте конфиг С уважением, Сергей 3 дек. 2018 г., 17:41 +0300, firedragon , писал: > Привет, всем. > > Я только начал изучать nginx, может кто-нибудь мне подсказать. > Имеется несколько сайтов на одном IIS все через ssl > https://www.xxx.ru > https://www.yyy.ru > https://www.zzz.ru > > , соответственно чтобы получить доступ к нужному сайту нужно обратиться > обязательно по имени сайта, например www.xxx.ru. > > Создал несколько серверов , пытаюсь делать балансировку, nginx не может > открыть страницу. > > Как я понял при получении запроса nginx дальше балансирует запрос на сервер > iis по IP адресу. > > > Можете подсказать как решить проблему? > > Заранее спасибо. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,282240,282240#msg-282240 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Баланс Ирочка по имени хоста
Привет, всем. Я только начал изучать nginx, может кто-нибудь мне подсказать. Имеется несколько сайтов на одном IIS все через ssl https://www.xxx.ru https://www.yyy.ru https://www.zzz.ru , соответственно чтобы получить доступ к нужному сайту нужно обратиться обязательно по имени сайта, например www.xxx.ru. Создал несколько серверов , пытаюсь делать балансировку, nginx не может открыть страницу. Как я понял при получении запроса nginx дальше балансирует запрос на сервер iis по IP адресу. Можете подсказать как решить проблему? Заранее спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282240,282240#msg-282240 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_store периодически сохраняет только часть ответа :(
Hello! On Sun, Dec 02, 2018 at 11:18:05PM +0300, Виктор Вислобоков wrote: > Схема такая: nginx(1) -> nginx(2) -> httpd > На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store. Почти > работает, но в произвольный момент времени сохраняет на диск не всю > страницу с ответом, а только её часть! Это именно происходит периодически и > не зависит ни от IP адреса ни от клиента (тот же Zabbix у меня то получает > фрагмент и ругается на малый размер страницы, то в следующий повтор всё > получает нормально - стоит чистка файлов, сохранённых proxy_store каждую > минуту). > > Всю голову сломал - не могу понять что за ерунда! > Судя по логам nginx(2) всегда отдаёт полный ответ. Content-Length при этом в ответах бэкенда есть? А "только её часть" - это именно часть, или просто пустой файл? В случае, если именно пустой файл - проблема может быть связана с тем, что в ответах нет Content-Length и сохраняются ответы на HEAD-запросы. Кроме того, опять же в случае отсутствия Content-Length, стоит убедиться, что между nginx(1) и nginx(2), а равно между nginx(2) и httpd - отсутствуют сетевые проблемы, и никто не пытается преждевременно завершать процессы серверной стороны. Либо же просто попробовать включить HTTP/1.1 с помощью директивы proxy_http_version (http://nginx.org/r/proxy_http_version) и посмотреть, поможет ли. Проблема в том, что в HTTP/1.0, который nginx использует для общения с бэкендами по умолчанию, в отсутствии Content-Length нет какого-либо контроля целостности ответа кроме собственно информации с уровня TCP, и если в какой-то момент бэкенд закроет соединение (например, потому что процессу сказали завершиться, или он решил, что случился таймаут) - то с точки зрения клиента ответ будет полным. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_store периодически сохраняет только часть ответа :(
Кажется нашёл. У меня в настройках стояло так, что если файл кэша есть, то отавать его, если нет, то создавать. Но было ещё одно условие: если запрос POST то не отдавать, а создавать. Видимо при одновременном приходе GET и POST запросов ответ писался в один и тот же файл и возникала проблема. Пустил POST запросы вообще мимо кэша и файл перестал быть фрагментарным. Спасибо за участие всем, кто ответил! :) пн, 3 дек. 2018 г. в 08:52, Виктор Вислобоков : > >> А чем proxy_cache не устраивает ? прокси стор, это больше для "на > века", а Вы трете его зачемто постоянно > Куда и что сохраняет proxy_cache знает только сам proxy_cache. Найти > что-то сохранённое им на диске очень большая проблема, да и посмотреть что > там тоже не так просто. А в proxy_store можно задать вполне себе понятный и > человеко-читаемый путь и содержимое тоже вполне себе понятно. > > >> У Вас proxy_temp_path и место куда сторится на одном разделе ? > На одном. > > пн, 3 дек. 2018 г. в 00:15, Alexey via nginx-ru : > >> 02.12.2018 23:18, Виктор Вислобоков пишет: >> > Схема такая: nginx(1) -> nginx(2) -> httpd >> > На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store. >> > Почти работает, но в произвольный момент времени сохраняет на диск не >> > всю страницу с ответом, а только её часть! Это именно происходит >> > периодически и не зависит ни от IP адреса ни от клиента (тот же Zabbix >> > у меня то получает фрагмент и ругается на малый размер страницы, то в >> > следующий повтор всё получает нормально - стоит чистка файлов, >> > сохранённых proxy_store каждую минуту). >> > >> А чем proxy_cache не устраивает ? прокси стор, это больше для "на века", >> а Вы трете его зачемто постоянно >> >> У Вас proxy_temp_path и место куда сторится на одном разделе ? Если на >> разных, то, скорее всего, пока файл от одного запроса копируется, >> успевает прийти другой запрос и видя файл на месте его и отдает, ну >> сколько успело скопироваться на момент второго запроса столько и отдает. >> >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Документация к директиве fastcgi_cache_key
пт, 30 нояб. 2018 г. в 13:36, Илья Шипицин : > протоколы действительно разные. > но выглядит так, что предложение Гены поможет написать документацию, более > устойчивую к тупому копипасту (есть такой патерн, что глядя на пример > документации на авторитетном сайте, его копируют) > > пт, 30 нояб. 2018 г. в 14:30, Gena Makhomed : > >> On 29.11.2018 21:02, Maxim Dounin wrote: >> >> > CGI и HTTP - это два разных протокола. В последних вариациях на >> > тему спецификации CGI записано, что на HEAD-запросы тело >> > возвращать не надо (а если вдруг вернули - то сервер его должен >> > поскипать), https://tools.ietf.org/html/rfc3875#section-4.3.3: >> > >> > The HEAD method requests the script to do sufficient processing to >> > return the response header fields, without providing a response >> > message-body. The script MUST NOT provide a response message-body >> > for a HEAD request. If it does, then the server MUST discard the >> > message-body when reading the response from the script. >> > >> > Однако на момент собственно появления и активного распространения >> > CGI никаких подобных требований не существовало, см. >> > https://www.w3.org/CGI/ и в частности >> > https://tools.ietf.org/html/draft-robinson-www-interface-00. >> >> Там написано: >> >> REQUEST_METHOD >> >>This variable is specific to requests made with HTTP. >> >>The method with which the request was made, as described in >>section 5.1.1 of the HTTP/1.0 specification [3]. >> >> http-method = "GET" | "HEAD" | "POST" | extension-method >> >> "described in HTTP/1.0 specification" - написано где смотреть семантику. >> А в HTTP/1.0 specification написано, что "server must not return any >> Entity-Body in the response". >> >> CGI и HTTP - это два разных протокола, но первый ссылается на второй. >> При этом CGI протокол не запрещает бекенду отвечать на HEAD-запросы >> так, как этого требует от веб-сервера спецификация HTTP протокола. >> >> > И на >> > практике я не встречал скрипты, которые бы отдельно обрабатывали >> > HEAD-запросы. >> >> Но они есть. >> И их поведение ничем не противоречит спецификации FastCGI протокола. >> >> >>> Речь про какие-то фреймворки, которые обрабатывают >> >>> HEAD автоматически, не донося соответствующую информацию до кода? >> >>> Или про какой-то стандартный софт, который не возвращает тело для >> >>> HEAD-запросов? >> >> >> >> Какая разница, сам софт или фрейморк используемый софтом в каждом >> >> конкретном случае обрабатывает HEAD запросы согласно требований RFC? >> > >> > Никакой. Но с этой точки зрения так же нет разницы, что именно >> > написано в примерах в описании директивы fastcgi_cache_key. >> >> Вы не против, если я создам на хабре статью, в которой напишу >> про эту проблему с ошибочными примерами в документации nginx >> к директиве fastcgi_cache_key и ее аналогам? >> >> -- >> Best regards, >> Gena >> >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Прошу прощения, что влезаю. Есть статья Дмитрия Котерова от октября 2009 года, посвещенная кешированию в nginx http://dklab.ru/chicken/nablas/56.html Если механизм кеширование не сильно изменился, то данные там акутальные. На хабре, конечно, охват аудитории больше будет, если там появится подобная статья. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
