From sergio на outerface.net Sun May 3 02:22:33 2020
From: sergio на outerface.net (sergio)
Date: Sun, 3 May 2020 05:22:33 +0300
Subject: =?UTF-8?B?0LrQsNC6INGA0LDQsdC+0YLQsNC10YIgZ3ppcF9zdGF0aWM/?=
Message-ID: <7a25aab7-b064-10f8-5979-4f45a8a7d367@outerface.net>
Есть два файла: test.html и test.html.gz
Если gzip_static не указана, то отдаётся test.html
(нет content-encoding=gzip в ff webdeveloper)
Если написать gzip_static on, то отдаётся test.html.gz
(content-encoding=gzip в ff webdeveloper)
1. Если после этого удалить test.html то nginx отвечает 404, хотя ни
https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html ни
https://docs.nginx.com/nginx/admin-guide/web-server/compression/ не
говорят ни слова, о том, что для этого должны присутствовать ОБА файла.
По-моему документацию стоит исправить.
2. Так же ngx_http_gzip_static_module.html говорит:
With the “always” value .. It is useful if there are no uncompressed
files on the disk anyway
Но переключние gzip_static с on на anyway при отсутствующем test.html
ничего не меняет: nginx продолжает отвечать 404.
--
sergio.
From mdounin на mdounin.ru Sun May 3 21:02:43 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 4 May 2020 00:02:43 +0300
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
=?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
=?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
=?UTF-8?B?IExpbms/?=
In-Reply-To: <4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>
References: <20200428000852.GT20357@mdounin.ru>
<4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200503210243.GW20357@mdounin.ru>
Hello!
On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:
> > > Востребованные ресурсы из push-кэша переходят в основной и будут
> > > использованы для следующих страниц.
> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> > в
> > > кэше.
> > > В крайнем случае несложно пометить клиента стандартным способом
> > через
> > > cookie.
> >
> > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как
> > на сервер, так и на канал. И статистика как бы говорит нам, что в
> > среднем эти накладные расходы - больше, чем польза.
>
> Я таковой статистикой не располагаю.
Ссылку на статистику я привёл. Если вы не располагаете другой -
вероятно, другой и нет.
> Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> дополнительный запрос к ресурсу.
По ресурсам "получить push" и "сделать дополнительный запрос и
получить на него ответ" - строго одно и то же. Разница - только во
времени, полученный push будет доступен чуть раньше, что в хорошем
случае немного сократит время до показа страницы. А в плохом -
потребует передачи по сети дополнительных данных (начала push'а и
его отмены) и приведёт к увеличению времени до показа страницы.
Именно на баланс "хороших" и "плохих" случаев и стоит смотреть.
> > Что будет конкретно в вашем случае - зависит, безусловно, от
> > конкретной нагрузки и от того, насколько "в крайнем случае
> > несложно" вам будет избежать лишних push'ей. Но, повторюсь, в
> > среднем - будет хуже, потому что "в крайнем случае" никто не
> > заморачивается. Именно поэтому я начал с вопроса пробовали ли вы
> > тестировать, что получится. Подозреваю, что от банального
> > перекладывания существующих в push'ы -
> > станет только хуже.
>
> Да, я понял Вашу точку зрения.
> Да, узкого эксперимента я не проводил.
>
> >
> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> > >
> > > Не совсем понимаю какие выводы делают авторы.
> > >
> > > Предлагают работать над приоритезацией (которая и так корректная, и
> > > регулируется preload'ом), использовать экспериментальный QUIC,
> > поддержики
> > > которого толком нет.
> >
> > Авторы ясно и однозначно показывают, что server push - в среднем
> > вредит, и в большинстве случаев лишь способ выстрелить себе в
> > ногу. И предлагают работать над другими технологиями,
> > потенциально более полезными.
> >
> > Тут важно понимать, что речь идёт про взгляд разработчиков
> > браузера, и рассказывалось это всё на HTTP working group, то есть
> > в рамках встречи людей, занимающихся разработкой протокола.
>
> Из Ваших соображений и трактовке вышеприведённого исследования складывается
> впечатление, что даже разработчики протокола не донца понимают зачем push
> нужен.
> При том, что не только они описали его в протоколе, но и сторонние
> разработчики реализовали поддержку push'а клиентах и нескольких серверах.
Зачем нужен push - все понимают. Насколько он при этом полезен
для интернета в среднем - можно выяснить только практически. Вот
есть исследование от команды одного из браузеров, которое говорит,
что в среднем - вреден.
Что до "реализовали поддержку push'а", то вот мы - всегда считали,
что полезность push'а, мягко говоря, преувеличена. Но, тем не
менее, вынуждены были реализовать, просто мотому, что пользователи
читают маркетинговые материалы, рассказывающие о новом красивом
протоколе HTTP/2 и его замечательных возможностях. А понимать,
какие недостатки есть у этих замечательных возможностей - не
пытаются.
> > (Ну и да, про приоритезацию - смешно. Нет, это не про preload,
> > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с
> > бассейном и джакузи запроектирован в рамках стандарта, корректности
> > ждать не приходится.)
>
> Я о текущей примитивной приоретизации.
> Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею,
> браузеры всё равно будут вынуждены использовать указания как рекомендацию.
Приоритизация в рамках стандарта HTTP/2 - это вполне конкретная
вещь, и именно она и упоминается в соответствующем докладе. И с
ней проблемы, именно потому она там и упоминается.
> > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на
> > практике
> > > проталкивание критических ресурсов, которые в любом случае
> > приоритетны и
> > > будут загружены для отрисовки.
> >
> > Именно с этого я и начал: попробуйте на практике на отдельных
> > страницах, без попыток вытаскивать версии ресурсов через SSI и вот
> > этого всего. Получите статистику, сравните.
> >
> > Сейчас же вы пришли и убеждаете разработчиков, что вам надо,
> > потому что оно точно будет лучше, но тестировать вы ничего не
> > тестировали и не хотите.
>
> Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно?
> Я задал вопрос о планах.
И получили на него ответ. А равно рекоменацию о том, с чего
начать, если вы вдруг считаете, что вам, тем не менее, надо.
Но почему-то пытаетесь спорить, убеждая меня в том, что статистика
не нужна, а надо слепо верить в теоретические рассуждения в
интернете.
> А учитывая, что использовать саму директиву http2_push затруднительно — один
> ресурс за раз, невозможность использования в if — и предвидя рекомендацию
> использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и
> что уже попробовал сделать своими силами, и о том, какие возможности могли
> бы помочь в решении задачи.
Директив http2_push может быть сколько угодно. Если после
интерполяции переменных парамером оказалась пустая строка -
директива не делает ничего. То есь если хочется push'ить ресурсы
условно, то это можно сделать элементарно:
set $push "";
if ($want_push_css) {
set $push "/css/main.css";
}
http2_push $css;
Аналогично можно push'ить произвольное количество ресурсов, если
это нужно. Достаточно написать соответствующий конфиг.
> > Так это не работает. Придёте со
> > стастикой, явно показывающей плюсы - мы задумаемся над тем, как
> > облегчить вам жизнь в конфигурации с SSI. Пока же из статистике
> > есть вот только ссылка выше, из которой явно следует, что делать
> > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно.
>
> То, о чём я рассказываю и есть эксперимент.
> Проще внедрить это на dev- или даже production-версии сайта, чем готовить
> узкие эксперименты из двух страниц.
> В случае pdocution'а можно прогнозировать значимое изменение в статистике
> загрузки страниц, в том числе по данным браузеров — в той же Метрике, Google
> Console или PageSpeed Insights.
>
> Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и
> несколько доступных браузеров и инструментов.
Ну вот для эксперимента - у вас есть все ресурсы, начиная от
собственно отдачи страниц с бекенда напрямую, без кеширования
SSI-кусков, с явно проставленными заголовками Link, и заканчивая
явной выдачей необходимых push'ей с помощью директивы http2_push.
--
Maxim Dounin
http://mdounin.ru/
From mdounin на mdounin.ru Sun May 3 21:13:31 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 4 May 2020 00:13:31 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIGd6aXBfc3RhdGljPw==?=
In-Reply-To: <7a25aab7-b064-10f8-5979-4f45a8a7d367@outerface.net>
References: <7a25aab7-b064-10f8-5979-4f45a8a7d367@outerface.net>
Message-ID: <20200503211331.GX20357@mdounin.ru>
Hello!
On Sun, May 03, 2020 at 05:22:33AM +0300, sergio wrote:
> Есть два файла: test.html и test.html.gz
>
> Если gzip_static не указана, то отдаётся test.html
> (нет content-encoding=gzip в ff webdeveloper)
>
> Если написать gzip_static on, то отдаётся test.html.gz
> (content-encoding=gzip в ff webdeveloper)
>
>
> 1. Если после этого удалить test.html то nginx отвечает 404, хотя ни
> https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html ни
> https://docs.nginx.com/nginx/admin-guide/web-server/compression/ не
> говорят ни слова, о том, что для этого должны присутствовать ОБА файла.
>
> По-моему документацию стоит исправить.
Ответ 404 будет тогда и только тогда, когда файл test.html для
чего-то используется и отсутствует на диске. В случае, если
запрос идёт непосредственно к файлу, клиент поддерживает gzip, и
включён gzip_static - клиенту будет отправлен ответ из
test.html.gz.
> 2. Так же ngx_http_gzip_static_module.html говорит:
>
> With the “always” value .. It is useful if there are no uncompressed
> files on the disk anyway
>
> Но переключние gzip_static с on на anyway при отсутствующем test.html
> ничего не меняет: nginx продолжает отвечать 404.
В случае с "gzip_static always;" меняется ровно одно: становится
не важно, поддерживает ли клиент gzip, или нет - всегда будет
отправлен сжатый ответ. Если вы и в этом случае видите ответ 404,
то это означает, что до gzip_static дело не доходит, и ответ 404
отправляется раньше.
Например, так может быть, если у вас в конфиге стоит что-нибудь
вроде "try_files $uri =404;", то есть существование конкретного
файла проверяется явно.
--
Maxim Dounin
http://mdounin.ru/
From sergio на outerface.net Mon May 4 04:56:12 2020
From: sergio на outerface.net (sergio)
Date: Mon, 4 May 2020 07:56:12 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIGd6aXBfc3RhdGljPw==?=
In-Reply-To: <20200503211331.GX20357@mdounin.ru>
References: <7a25aab7-b064-10f8-5979-4f45a8a7d367@outerface.net>
<20200503211331.GX20357@mdounin.ru>
Message-ID: <6861173d-c72a-7252-18ce-760e9b0d26bd@outerface.net>
On 04/05/2020 00:13, Maxim Dounin wrote:
> Если вы и в этом случае видите ответ 404,
> то это означает, что до gzip_static дело не доходит, и ответ 404
> отправляется раньше.
> Например, так может быть, если у вас в конфиге стоит что-нибудь
> вроде "try_files $uri =404;", то есть существование конкретного
> файла проверяется явно.
Все так (:
Тогда следующий вопрос:
На диске лежит index.html.gz (index.html нет)
Запрос https://website.tld/index.html удачно отображается в браузере.
Запрашиваем https://website.tld/
Если написать "index index.html;" то nginx пытается отобразить
содержимое директории.
Если написать "index index.html.gz;" или "index index.html; try_files
$uri.gz =404;" или то nginx отдаёт index.html.gz как есть: без
content-encoding=gzip и с content-type=application/octet-stream
--
sergio.
From mdounin на mdounin.ru Mon May 4 15:27:54 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 4 May 2020 18:27:54 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIGd6aXBfc3RhdGljPw==?=
In-Reply-To: <6861173d-c72a-7252-18ce-760e9b0d26bd@outerface.net>
References: <7a25aab7-b064-10f8-5979-4f45a8a7d367@outerface.net>
<20200503211331.GX20357@mdounin.ru>
<6861173d-c72a-7252-18ce-760e9b0d26bd@outerface.net>
Message-ID: <20200504152754.GZ20357@mdounin.ru>
Hello!
On Mon, May 04, 2020 at 07:56:12AM +0300, sergio wrote:
> On 04/05/2020 00:13, Maxim Dounin wrote:
>
> > Если вы и в этом случае видите ответ 404,
> > то это означает, что до gzip_static дело не доходит, и ответ 404
> > отправляется раньше.
>
> > Например, так может быть, если у вас в конфиге стоит что-нибудь
> > вроде "try_files $uri =404;", то есть существование конкретного
> > файла проверяется явно.
>
> Все так (:
>
>
> Тогда следующий вопрос:
>
> На диске лежит index.html.gz (index.html нет)
> Запрос https://website.tld/index.html удачно отображается в браузере.
> Запрашиваем https://website.tld/
>
> Если написать "index index.html;" то nginx пытается отобразить
> содержимое директории.
>
> Если написать "index index.html.gz;" или "index index.html; try_files
> $uri.gz =404;" или то nginx отдаёт index.html.gz как есть: без
> content-encoding=gzip и с content-type=application/octet-stream
Так и в чём вопрос?
--
Maxim Dounin
http://mdounin.ru/
From sergio на outerface.net Mon May 4 17:02:27 2020
From: sergio на outerface.net (sergio)
Date: Mon, 4 May 2020 20:02:27 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIGd6aXBfc3RhdGljPw==?=
In-Reply-To: <20200504152754.GZ20357@mdounin.ru>
References: <7a25aab7-b064-10f8-5979-4f45a8a7d367@outerface.net>
<20200503211331.GX20357@mdounin.ru>
<6861173d-c72a-7252-18ce-760e9b0d26bd@outerface.net>
<20200504152754.GZ20357@mdounin.ru>
Message-ID: <59da4c43-ac40-05f6-c411-a1af5499113f@outerface.net>
On 04/05/2020 18:27, Maxim Dounin wrote:
>> На диске лежит index.html.gz (index.html нет)
> Так и в чём вопрос?
Как сделать так, что бы https://website.tld/ работал?
--
sergio.
From mdounin на mdounin.ru Mon May 4 23:50:42 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 5 May 2020 02:50:42 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIGd6aXBfc3RhdGljPw==?=
In-Reply-To: <59da4c43-ac40-05f6-c411-a1af5499113f@outerface.net>
References: <7a25aab7-b064-10f8-5979-4f45a8a7d367@outerface.net>
<20200503211331.GX20357@mdounin.ru>
<6861173d-c72a-7252-18ce-760e9b0d26bd@outerface.net>
<20200504152754.GZ20357@mdounin.ru>
<59da4c43-ac40-05f6-c411-a1af5499113f@outerface.net>
Message-ID: <20200504235042.GC20357@mdounin.ru>
Hello!
On Mon, May 04, 2020 at 08:02:27PM +0300, sergio wrote:
> On 04/05/2020 18:27, Maxim Dounin wrote:
>
> >> На диске лежит index.html.gz (index.html нет)
>
> > Так и в чём вопрос?
>
> Как сделать так, что бы https://website.tld/ работал?
Способов множество.
Можно написать явный (или условный) rewrite с "/" на "/index.html"
в конфиге, например.
Проще всего - положить index.html (достаточно нулевого размера),
тогда index-модуль сделает соответствующее перенаправление на
"/index.html", а "gzip_static always;" уже вернёт вместо него
содержимое index.html.gz с нужными заголовками.
--
Maxim Dounin
http://mdounin.ru/
From nginx-forum на forum.nginx.org Wed May 6 23:05:57 2020
From: nginx-forum на forum.nginx.org (yyyuuu)
Date: Wed, 06 May 2020 19:05:57 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC0?=
=?UTF-8?B?0YDRg9Cz0L7QuSDQsNC00YDQtdGB?=
In-Reply-To: <7392647de857488a3ab2209713d4bd7a.NginxMailingListRussian@forum.nginx.org>
References: <7392647de857488a3ab2209713d4bd7a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <08d33518ddc55988dc4b61810de727f5.NginxMailingListRussian@forum.nginx.org>
У кого нибудь есть мысли как это сделать?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287854,287964#msg-287964
From gmm на csdoc.com Thu May 7 14:50:55 2020
From: gmm на csdoc.com (Gena Makhomed)
Date: Thu, 7 May 2020 17:50:55 +0300
Subject: could not build server_names_hash,
you should increase server_names_hash_bucket_size: 64
Message-ID:
Здравствуйте, All!
nginx version: nginx/1.17.10 из официального репозитория.
Почему nginx время от времени ни с того ни с сего глючит при релоаде
конфигурации и остается работать со старой конфигурацией
при добавлении нового хоста в конфиг?
Уже в который раз наступаю на эти грабли.
При выполнении команды nginx -t он выдает такие ошибки:
nginx: [warn] could not build optimal server_names_hash, you should
increase either server_names_hash_max_size: 512 or
server_names_hash_bucket_size: 64; ignoring server_names_hash_bucket_size
nginx: [emerg] could not build server_names_hash, you should increase
server_names_hash_bucket_size: 64
nginx: configuration file /etc/nginx/nginx.conf test failed
или такие:
nginx: [emerg] could not build server_names_hash, you should increase
server_names_hash_bucket_size: 64
nginx: configuration file /etc/nginx/nginx.conf test failed
и т.п.
Почему нельзя его научить самостоятельно подбирать нужные ему размеры?
Например, так:
server_names_hash_max_size auto;
server_names_hash_bucket_size auto;
и забыть про эти глюки как про страшный сон?
Документацию http://nginx.org/ru/docs/hash.html читал,
но так и не понял, почему nginx не может это делать самостоятельно,
пусть даже ценой некоторой небольшой задержки пре релоаде конфигурации.
Небольшая задержка при релоаде конфигурации имхо - это гораздо лучше,
чем выдавать ошибку и в случайные и непредсказуемые моменты времени
полностью игнорировать добавление нового хоста в конфиг.
--
Best regards,
Gena
From nginx-forum на forum.nginx.org Fri May 8 08:29:04 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Fri, 08 May 2020 04:29:04 -0400
Subject: =?UTF-8?B?UmU6INCn0YLQviDQstGL0LHRgNCw0YLRjCBsb2NhdGlvbiDQuNC70LggcmV3cml0?=
=?UTF-8?B?ZT8=?=
In-Reply-To:
References:
Message-ID: <15401aae5ef362ba107d4c545245bd3e.NginxMailingListRussian@forum.nginx.org>
Еще заметил одну вещь. В конфиге, для директории запаролен доступ. Сделано
по примеру из документации:
location /admin/ {
auth_basic "admin";
auth_basic_user_file /www/admin/.htpasswd;
index index-admin.php;
}
Получается такая вещь - если обратиться к директории по адресу
site.ru/admin/, то пароль запрашивается, а если обратиться к любому файлу
напрямую в этой директории site.ru/admin/123.php, то запроса пароля нет.
Подозреваю, что туплю наверно где-то я. Всё проверил уже не один раз, но
даже не знаю в какую сторону копать.
Подскажите, плз :)
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287729,287972#msg-287972
From kulmaks на gmail.com Fri May 8 10:25:29 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Fri, 8 May 2020 13:25:29 +0300
Subject: =?UTF-8?B?UmU6INCn0YLQviDQstGL0LHRgNCw0YLRjCBsb2NhdGlvbiDQuNC70LggcmV3cml0?=
=?UTF-8?B?ZT8=?=
In-Reply-To: <15401aae5ef362ba107d4c545245bd3e.NginxMailingListRussian@forum.nginx.org>
References:
<15401aae5ef362ba107d4c545245bd3e.NginxMailingListRussian@forum.nginx.org>
Message-ID:
Вы запрашиваете .php файл и он будет обработан в location ~ \.(php|html)$,
а не в location /admin/
Порядок обработки location можно найти здесь:
http://nginx.org/ru/docs/http/ngx_http_core_module.html#location
пт, 8 мая 2020 г. в 11:29, grey :
> Еще заметил одну вещь. В конфиге, для директории запаролен доступ. Сделано
> по примеру из документации:
>
> location /admin/ {
> auth_basic "admin";
> auth_basic_user_file /www/admin/.htpasswd;
> index index-admin.php;
> }
>
> Получается такая вещь - если обратиться к директории по адресу
> site.ru/admin/, то пароль запрашивается, а если обратиться к любому файлу
> напрямую в этой директории site.ru/admin/123.php, то запроса пароля нет.
>
> Подозреваю, что туплю наверно где-то я. Всё проверил уже не один раз, но
> даже не знаю в какую сторону копать.
>
> Подскажите, плз :)
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287729,287972#msg-287972
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL:
From nginx-forum на forum.nginx.org Fri May 8 12:07:30 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Fri, 08 May 2020 08:07:30 -0400
Subject: =?UTF-8?B?UmU6INCn0YLQviDQstGL0LHRgNCw0YLRjCBsb2NhdGlvbiDQuNC70LggcmV3cml0?=
=?UTF-8?B?ZT8=?=
In-Reply-To:
References:
Message-ID: <26023a2934edd2271cf3f8133d3a6c66.NginxMailingListRussian@forum.nginx.org>
Понял. Тогда другой вопрос: как сделать, чтобы и скрипты работали и
директория была запаролена? Сделать именованный и везде его указывать?
location /downloads/ {
...
@php;
}
location /dir123/ {
...
@php;
}
location /admin/ {
auth_basic "admin";
auth_basic_user_file /www/admin/.htpasswd;
index index-admin.php;
@php;
}
location @php \.(php|html)$ {
fastcgi_pass 127.0.0.1:9123;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
Правильное ли такое решение?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287729,287975#msg-287975
From nginx-forum на forum.nginx.org Sun May 10 15:09:13 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Sun, 10 May 2020 11:09:13 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC0?=
=?UTF-8?B?0YDRg9Cz0L7QuSDQsNC00YDQtdGB?=
In-Reply-To: <08d33518ddc55988dc4b61810de727f5.NginxMailingListRussian@forum.nginx.org>
References: <7392647de857488a3ab2209713d4bd7a.NginxMailingListRussian@forum.nginx.org>
<08d33518ddc55988dc4b61810de727f5.NginxMailingListRussian@forum.nginx.org>
Message-ID:
у гугла полно мыслей... "nginx redirect"
# ПРАВИЛЬНЫЙ редирект для домена www.site.ru на site.ru
server {
listen 80;
server_name example.org;
return 301 http://www.example.org$request_uri;
}
# Редирект для домена www.site.ru на site.ru
server {
listen 80;
server_name www.site.ru;
rewrite ^ http://site.ru$request_uri? permanent;
}
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287854,287985#msg-287985
From mdounin на mdounin.ru Sun May 10 17:29:33 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sun, 10 May 2020 20:29:33 +0300
Subject: could not build server_names_hash,
you should increase server_names_hash_bucket_size: 64
In-Reply-To:
References:
Message-ID: <20200510172933.GF20357@mdounin.ru>
Hello!
On Thu, May 07, 2020 at 05:50:55PM +0300, Gena Makhomed wrote:
> Здравствуйте, All!
>
> nginx version: nginx/1.17.10 из официального репозитория.
>
> Почему nginx время от времени ни с того ни с сего глючит при релоаде
> конфигурации и остается работать со старой конфигурацией
> при добавлении нового хоста в конфиг?
>
> Уже в который раз наступаю на эти грабли.
>
> При выполнении команды nginx -t он выдает такие ошибки:
>
> nginx: [warn] could not build optimal server_names_hash, you should increase
> either server_names_hash_max_size: 512 or server_names_hash_bucket_size: 64;
> ignoring server_names_hash_bucket_size
Этот warning означает, что построить оптимальный хэш в рамках
заданных параметров не удалось, поэтому хэш будет построен без
учёта server_names_hash_bucket_size. Возможно, результирующий хэш
будет не оптимален, поэтому - warning.
> nginx: [emerg] could not build server_names_hash, you should increase
> server_names_hash_bucket_size: 64
А это ошибка означает, что в хэш попытались положить элемент
длиннее заданного server_names_hash_bucket_size, что выглядит как
ошибка в конфигурации. Если это не ошибка, и вы действительно
хотили такое положить в хэш - это можно сделать, явно увеличив
server_names_hash_bucket_size.
> nginx: configuration file /etc/nginx/nginx.conf test failed
>
> или такие:
>
> nginx: [emerg] could not build server_names_hash, you should increase
> server_names_hash_bucket_size: 64
> nginx: configuration file /etc/nginx/nginx.conf test failed
>
> и т.п.
>
> Почему нельзя его научить самостоятельно подбирать нужные ему размеры?
>
> Например, так:
>
> server_names_hash_max_size auto;
> server_names_hash_bucket_size auto;
>
> и забыть про эти глюки как про страшный сон?
>
> Документацию http://nginx.org/ru/docs/hash.html читал,
> но так и не понял, почему nginx не может это делать самостоятельно,
> пусть даже ценой некоторой небольшой задержки пре релоаде конфигурации.
>
> Небольшая задержка при релоаде конфигурации имхо - это гораздо лучше,
> чем выдавать ошибку и в случайные и непредсказуемые моменты времени
> полностью игнорировать добавление нового хоста в конфиг.
Проблем тут две:
- "Небольшая задержка" - это, скажем так, оптимистичный взгляд на
проблему. Скажем, один перебор всех возможных значений
количества bucket'ов - то есть, фактически, построение хэша с
большим значением server_names_hash_max_size - может легко
занимать минуты процессорного времени.
- Нет априорного ответа на вопрос "а что оптимальнее: сделать
больше bucket'ов или поднять размер одного bucket'а".
Поэтому сейчас всё работает так, что в отсутствии явных ошибок
конфигурации (как в случае выше - имён в конфиге, превышающих по
длине заданный размер bucket_size) - хэш всегда строится, а
информация о его возможной неоптимальности пишется в лог. Если же
в конфиге есть явные ошибки - то о них явно же и сообщается.
--
Maxim Dounin
http://mdounin.ru/
From nginx-forum на forum.nginx.org Mon May 11 21:37:33 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Mon, 11 May 2020 17:37:33 -0400
Subject: =?UTF-8?B?0YHQv9C+0YAg0LzQtdC20LTRgyDQvtGC0L/RgNCw0LLQutC+0Lkg0YfQtdGA0LU=?=
=?UTF-8?B?0LcgSFRUUCDQuCBGYXN0Q0dJ?=
Message-ID: <9cddbcab843e20ea30e7e950b23ac0f7.NginxMailingListRussian@forum.nginx.org>
хотелось бы прояснить для себя, почему некоторые выступают за HTTP-передачу
данных в демона, а не FastCGI ?
Я правильно понимаю, что HTTP тут это просто строка с хедером + тело,
которую надо распарсить.
А FastCGI будет бинарный набор расфасованных данных.
Непонятно, зачем их второй раз парсить, когда Nginx уже их распарсил (в
случае с HTTP-proxy он всё также все данные УЖЕ разложил, просто передаёт их
единой строкой)
В чём выигрыш тут? Есть какой-то оверхед на FastCGI?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287999,287999#msg-287999
From suharelli на gmail.com Tue May 12 00:51:56 2020
From: suharelli на gmail.com (=?UTF-8?B?0KHRg9GF0LDRgNC90LjQutC+0LIg0JXQstCz0LXQvdC40Lk=?=)
Date: Tue, 12 May 2020 10:51:56 +1000
Subject: =?UTF-8?B?UmU6INGB0L/QvtGAINC80LXQttC00YMg0L7RgtC/0YDQsNCy0LrQvtC5INGH0LU=?=
=?UTF-8?B?0YDQtdC3IEhUVFAg0LggRmFzdENHSQ==?=
In-Reply-To: <9cddbcab843e20ea30e7e950b23ac0f7.NginxMailingListRussian@forum.nginx.org>
References: <9cddbcab843e20ea30e7e950b23ac0f7.NginxMailingListRussian@forum.nginx.org>
Message-ID:
Потому что на дворе 2020 год, у нас есть такие чудесные вещи как java,
go, javascript, даже прости господи php сойдет. Ты просто принимаешь
json, делаешь что тебе надо и отдаешь json обратно, не нужно писать
никаких уязвимых парсеров. Все готово, бери и пользуйся, решай задачу,
а не изобретай велосипед.
вт, 12 мая 2020 г. в 07:37, greenwar :
>
> хотелось бы прояснить для себя, почему некоторые выступают за HTTP-передачу
> данных в демона, а не FastCGI ?
> Я правильно понимаю, что HTTP тут это просто строка с хедером + тело,
> которую надо распарсить.
> А FastCGI будет бинарный набор расфасованных данных.
> Непонятно, зачем их второй раз парсить, когда Nginx уже их распарсил (в
> случае с HTTP-proxy он всё также все данные УЖЕ разложил, просто передаёт их
> единой строкой)
> В чём выигрыш тут? Есть какой-то оверхед на FastCGI?
>
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287999,287999#msg-287999
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
С уважением, Евгений Сухарников.
From nginx-forum на forum.nginx.org Tue May 12 04:22:59 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Tue, 12 May 2020 00:22:59 -0400
Subject: =?UTF-8?B?UmU6INGB0L/QvtGAINC80LXQttC00YMg0L7RgtC/0YDQsNCy0LrQvtC5INGH0LU=?=
=?UTF-8?B?0YDQtdC3IEhUVFAg0LggRmFzdENHSQ==?=
In-Reply-To:
References:
Message-ID: <6ed7c6254b499ef2b00fd8b657bee1a6.NginxMailingListRussian@forum.nginx.org>
откуда json в HTTP-хедере ?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287999,288003#msg-288003
From nginx-forum на forum.nginx.org Fri May 15 07:14:56 2020
From: nginx-forum на forum.nginx.org (milov)
Date: Fri, 15 May 2020 03:14:56 -0400
Subject: =?UTF-8?B?bG9jYXRpb24gfiBwb2Rkb21lbiDQvdC1INC/0L7Qu9GD0YfQsNC10YLRgdGPINGA?=
=?UTF-8?B?0LXQsNC70LjQt9C+0LLQsNGC0Yw=?=
Message-ID: <2f38da3cc39458555462e97b046fab31.NginxMailingListRussian@forum.nginx.org>
Нужно закрыть паролем поддомен, на if ругается, а location не получается
придумать
location ~ poddomen\.domen\.ru {
auth_basic "Private zone. Only for administrator!";
auth_basic_user_file /home/.htpasswd;
}
В отдельный блок server Неохота выносить т.к. там кучу других правил
копипастить придётся.
Прошу помощи.
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288040,288040#msg-288040
From shadow.tehb на gmail.com Fri May 15 08:13:32 2020
From: shadow.tehb на gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCe0LvQtdCz0L7QstC40Yc=?=)
Date: Fri, 15 May 2020 11:13:32 +0300
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIH4gcG9kZG9tZW4g0L3QtSDQv9C+0LvRg9GH0LDQtdGC0YE=?=
=?UTF-8?B?0Y8g0YDQtdCw0LvQuNC30L7QstCw0YLRjA==?=
In-Reply-To: <2f38da3cc39458555462e97b046fab31.NginxMailingListRussian@forum.nginx.org>
References: <2f38da3cc39458555462e97b046fab31.NginxMailingListRussian@forum.nginx.org>
Message-ID: <172176543e0.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com>
Блок server. Правила в отдельный файл и пользуйся include.
"milov" 15 мая 2020 г. 10:15:07 написал:
> Нужно закрыть паролем поддомен, на if ругается, а location не получается
> придумать
>
> location ~ poddomen\.domen\.ru {
> auth_basic "Private zone. Only for administrator!";
> auth_basic_user_file /home/.htpasswd;
> }
>
> В отдельный блок server Неохота выносить т.к. там кучу других правил
> копипастить придётся.
> Прошу помощи.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288040,288040#msg-288040
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
From nginx-forum на forum.nginx.org Fri May 15 09:12:45 2020
From: nginx-forum на forum.nginx.org (milov)
Date: Fri, 15 May 2020 05:12:45 -0400
Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIH4gcG9kZG9tZW4g0L3QtSDQv9C+0LvRg9GH0LDQtdGC0YE=?=
=?UTF-8?B?0Y8g0YDQtdCw0LvQuNC30L7QstCw0YLRjA==?=
In-Reply-To: <172176543e0.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com>
References: <172176543e0.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com>
Message-ID: <4df78e015bb04371c33414f0a078912f.NginxMailingListRussian@forum.nginx.org>
Спасибо, чё то не подумал )
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288040,288043#msg-288043
From nginx-forum на forum.nginx.org Fri May 15 13:23:01 2020
From: nginx-forum на forum.nginx.org (vetallkvn)
Date: Fri, 15 May 2020 09:23:01 -0400
Subject: =?UTF-8?B?cHJveHkgcGFzcy4g0JLQt9Cw0LjQvNC+0LTQtdC50YHRgtCy0LjQtSDRgNC10YE=?=
=?UTF-8?B?0YPRgNGB0L7QsiDQt9CwIG5naW54?=
Message-ID: <031023e8120290ae9538ac532f18ab68.NginxMailingListRussian@forum.nginx.org>
Помогите советом. Ну или хотя бы направлением.
Есть сервер nginx-proxy. За ним два сервера (ххххх.4 и ххххх.5) . Как
сделать чтобы шли запросы от с сервера хххх.4 до ххххх.5 по доменному имени
(без указания порта)?
location / {
proxy_pass http://хххххх.4;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_send_timeout 900;
proxy_read_timeout 900;
send_timeout 900;
client_max_body_size 30M;
}
location /pdfcombiner/ {
proxy_pass http://хххххх.5:8092/;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
}
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288049,288049#msg-288049
From nginx-forum на forum.nginx.org Thu May 21 07:11:14 2020
From: nginx-forum на forum.nginx.org (windos321)
Date: Thu, 21 May 2020 03:11:14 -0400
Subject: =?UTF-8?B?0JrQvtC70LjRh9C10YHRgtCy0L4g0YHQvtC10LTQuNC90LXQvdC40Lkg0L3QsCA=?=
=?UTF-8?B?0LLQvtGA0LrQtdGA?=
Message-ID: <54ef78f90684d603e7e24eff30bdb0a8.NginxMailingListRussian@forum.nginx.org>
Здравствуйте!
Подскажите, пожалуйста, команду которая в linux покажет сколько соединений в
данный момент обрабатывает 1 воркер?
Нужно для теста распределения запросов по воркерам, ранее находил такую
команду в сети, но теперь не могу, уже 2 часа ищу...
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288080,288080#msg-288080
From alex.hha на gmail.com Thu May 21 07:12:58 2020
From: alex.hha на gmail.com (Alex Domoradov)
Date: Thu, 21 May 2020 10:12:58 +0300
Subject: =?UTF-8?B?UmU6INCa0L7Qu9C40YfQtdGB0YLQstC+INGB0L7QtdC00LjQvdC10L3QuNC5INC9?=
=?UTF-8?B?0LAg0LLQvtGA0LrQtdGA?=
In-Reply-To: <54ef78f90684d603e7e24eff30bdb0a8.NginxMailingListRussian@forum.nginx.org>
References: <54ef78f90684d603e7e24eff30bdb0a8.NginxMailingListRussian@forum.nginx.org>
Message-ID:
netstat/ss ?
On Thu, May 21, 2020 at 10:11 AM windos321
wrote:
> Здравствуйте!
> Подскажите, пожалуйста, команду которая в linux покажет сколько соединений
> в
> данный момент обрабатывает 1 воркер?
> Нужно для теста распределения запросов по воркерам, ранее находил такую
> команду в сети, но теперь не могу, уже 2 часа ищу...
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288080,288080#msg-288080
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL:
From nginx-forum на forum.nginx.org Thu May 21 07:19:20 2020
From: nginx-forum на forum.nginx.org (windos321)
Date: Thu, 21 May 2020 03:19:20 -0400
Subject: =?UTF-8?B?UmU6INCa0L7Qu9C40YfQtdGB0YLQstC+INGB0L7QtdC00LjQvdC10L3QuNC5INC9?=
=?UTF-8?B?0LAg0LLQvtGA0LrQtdGA?=
In-Reply-To:
References:
Message-ID: <7369d910f2acc8bb432b19c7bb61fbe9.NginxMailingListRussian@forum.nginx.org>
ALex_hha Wrote:
-------------------------------------------------------
> netstat/ss ?
netstat - он самый
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288080,288082#msg-288082
From nginx-forum на forum.nginx.org Thu May 21 07:20:19 2020
From: nginx-forum на forum.nginx.org (windos321)
Date: Thu, 21 May 2020 03:20:19 -0400
Subject: =?UTF-8?B?UmU6INCa0L7Qu9C40YfQtdGB0YLQstC+INGB0L7QtdC00LjQvdC10L3QuNC5INC9?=
=?UTF-8?B?0LAg0LLQvtGA0LrQtdGA?=
In-Reply-To: <7369d910f2acc8bb432b19c7bb61fbe9.NginxMailingListRussian@forum.nginx.org>
References:
<7369d910f2acc8bb432b19c7bb61fbe9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <32133487141902c52f3fb5280cd7673a.NginxMailingListRussian@forum.nginx.org>
Вот она netstat -antp|grep ESTABLISHED|grep nginx|awk -F" " '{print
$7}'|sort|uniq -c
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288080,288083#msg-288083
From nginx-forum на forum.nginx.org Fri May 22 02:33:25 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Thu, 21 May 2020 22:33:25 -0400
Subject: =?UTF-8?B?0J7QsdC90YPQu9C10L3QuNC1INCy0YvQtNC10LvQtdC90LjQuSDQv9GA0Lgg0Lg=?=
=?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC4IG1hcA==?=
Message-ID: <1b1d877f79349aff9596212410f8edce.NginxMailingListRussian@forum.nginx.org>
nginx/1.17.10
При использовании регулярных выражений в map обнуляются выделения уровня
location, даже в случае, если в выражениях map не используются выделения.
https://nginx.org/ru/docs/http/ngx_http_map_module.html
> Регулярное выражение может содержать именованные и позиционные выделения,
которые могут затем использоваться в других директивах совместно с
результирующей переменной.
-------------------------------------------------
map $uri $suffix {
'~*.' '';
}
…
server {
…
location ~* /test/(.+) {
# try_files $uri @blank; # non empty
try_files $uri$suffix $uri @blank; # empty
}
location @blank {
default_type 'text/plain';
return 200 '$1';
}
}
-------------------------------------------------
Обращаемся к /test/123 — получаем пустой ответ.
Стоит убрать $uri$suffix из try_files — получаем «123».
Обойти можно, используя именованные выделения в location.
Из формулировки в документации складывается ощущение, что значения
позиционных выделений location'а будут переопределены если они используются
в map.
Но если их в map нет, странно получать пустые значения.
Я неправильно понимаю документацию или это ошибка?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288093,288093#msg-288093
From nginx-forum на forum.nginx.org Fri May 22 03:41:34 2020
From: nginx-forum на forum.nginx.org (windos321)
Date: Thu, 21 May 2020 23:41:34 -0400
Subject: SSL_write() failed
Message-ID: <9e4e068e7aa48738b6ef2942d30379bc.NginxMailingListRussian@forum.nginx.org>
Добрый день!
В логах появляется ошибка:
*92584 SSL_write() failed
nginx version: nginx/1.18.0
built by gcc 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)
built with OpenSSL 1.1.1g 21 Apr 2020
В сети не нашел информации по ней.
Что она означает?
Как исправить?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288094,288094#msg-288094
From mdounin на mdounin.ru Fri May 22 12:33:01 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 22 May 2020 15:33:01 +0300
Subject: =?UTF-8?B?UmU6INCe0LHQvdGD0LvQtdC90LjQtSDQstGL0LTQtdC70LXQvdC40Lkg0L/RgNC4?=
=?UTF-8?B?INC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC4IG1hcA==?=
In-Reply-To: <1b1d877f79349aff9596212410f8edce.NginxMailingListRussian@forum.nginx.org>
References: <1b1d877f79349aff9596212410f8edce.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200522123301.GZ12747@mdounin.ru>
Hello!
On Thu, May 21, 2020 at 10:33:25PM -0400, gz wrote:
> При использовании регулярных выражений в map обнуляются выделения уровня
> location, даже в случае, если в выражениях map не используются выделения.
[...]
> Из формулировки в документации складывается ощущение, что значения
> позиционных выделений location'а будут переопределены если они используются
> в map.
> Но если их в map нет, странно получать пустые значения.
>
> Я неправильно понимаю документацию или это ошибка?
Ощущение складывается неправильное, переменные $1..$9 всегда
относятся к последнему поматчившемуся регулярному выражению. Если
в этом последнем выполненном регулярном выражении выделений нет
(или конкретное выделение не поматчилось, например, из-за
ветвлений), то они будут пустыми.
Это общий принцип работы переменных $1..$9 приблизительно везде,
так что он, видимо, в явном виде в документации не описан.
Скажем, в перле то же самое можно пронаблюдать так:
$ echo foobar | perl -nle 'm/(...)/; print "match: $1"; m/foo/; print "match: $1";'
match: foo
match:
С учётом декларативной природы конфигурации nginx'а - такое
поведение делат переменные $1..$9 малопригодными для использования
в сложных конфигурациях. Особенно следует быть осторожным при
использовании $1..$9, если значения получены из регулярных
выражений в server_name или location: работать будет только в
совсем простых конфигурациях. В сколько-нибудь сложных случаях
правильно, если есть необходимость использовать выделения,
использовать именованные выделения.
--
Maxim Dounin
http://mdounin.ru/
From nginx-forum на forum.nginx.org Sun May 24 23:37:21 2020
From: nginx-forum на forum.nginx.org (yyyuuu)
Date: Sun, 24 May 2020 19:37:21 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC0?=
=?UTF-8?B?0YDRg9Cz0L7QuSDQsNC00YDQtdGB?=
In-Reply-To:
References: <7392647de857488a3ab2209713d4bd7a.NginxMailingListRussian@forum.nginx.org>
<08d33518ddc55988dc4b61810de727f5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <75a80bf654728bdf2cfde7dcc8c67f2b.NginxMailingListRussian@forum.nginx.org>
server {
listen 80;
server_name ya.ru www.ya.ru;
return 301 https://www.google.ru;
}
Чем отличается первый пример от моего? НО он не работает
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287854,288115#msg-288115
From nginx-forum на forum.nginx.org Mon May 25 00:38:37 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Sun, 24 May 2020 20:38:37 -0400
Subject: =?UTF-8?B?UmU6INCe0LHQvdGD0LvQtdC90LjQtSDQstGL0LTQtdC70LXQvdC40Lkg0L/RgNC4?=
=?UTF-8?B?INC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC4IG1hcA==?=
In-Reply-To: <20200522123301.GZ12747@mdounin.ru>
References: <20200522123301.GZ12747@mdounin.ru>
Message-ID: <9ee4c00e2cf5e5e83c714420af54fa99.NginxMailingListRussian@forum.nginx.org>
Maxim Dounin Wrote:
-------------------------------------------------------
> Это общий принцип работы переменных $1..$9 приблизительно везде,
> так что он, видимо, в явном виде в документации не описан.
Отчасти да, но неочевидно, что location и map работают в одном контексте и
разделяют нумерованные выделения.
Ещё неожиданности добавляется отложенный характер выполнения map — не сразу
понимаешь, что обнуление происходит именно при её выполнении.
В целом, ясно, что в подобных случаях стоит продолжать использовать
именованные выделения.
Благодарю за разъяснение.
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288093,288116#msg-288116
From nginx-forum на forum.nginx.org Mon May 25 00:41:58 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Sun, 24 May 2020 20:41:58 -0400
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
=?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
=?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
=?UTF-8?B?IExpbms/?=
In-Reply-To: <4a0c59e377a1376190acf7b151359687.NginxMailingListRussian@forum.nginx.org>
References: <20200427191550.GS20357@mdounin.ru>
<52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
<69c608b37520c975cabbb7d89a29976d.NginxMailingListRussian@forum.nginx.org>
<146084e47d90b72e5f6f25079cf491f0.NginxMailingListRussian@forum.nginx.org>
<4a0c59e377a1376190acf7b151359687.NginxMailingListRussian@forum.nginx.org>
Message-ID:
S.A.N Wrote:
-------------------------------------------------------
> > Решение о push'е принимается при генерации HTML-ответа за запрос к
> > странице.
> > В этот момент доступны If-None-Match и/или If-Modified-Since только
> > самой страницы и странно ориентироваться на них, так как они ничего
> > не говорят о наличии в кэше клиента тех ресурсов, которые мы планируем
> > протолкнуть в ответе.
>
> Дело в том, что в этом ответе на запрос (у вас это НТМЛ страница),
> формируется url к ресурсам для push, если в эти url вы добавляете
> версии, вы можете включить хеш всех версий ресурсов для push, в ETag
> заголовка ответа НТМЛ страницы, тогда вы сможете сопоставлять
> клиенские заголовки If-None-Match и актуальные версии ресурсов, если
> вы не можете детектить валидность клиенского кеша для этих ресурсов,
> тогда лучше link без push.
Ясно, версии pushed-ресурсов влияют на слепок ETag'а.
Благодарю за информацию.
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,288117#msg-288117
From nginx-forum на forum.nginx.org Mon May 25 00:46:42 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Sun, 24 May 2020 20:46:42 -0400
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
=?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
=?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
=?UTF-8?B?IExpbms/?=
In-Reply-To: <20200429190027.GC2616@sie.protva.ru>
References: <20200429190027.GC2616@sie.protva.ru>
Message-ID: <23668e6fd1c8b5b00f3356027ad58582.NginxMailingListRussian@forum.nginx.org>
Evgeniy Berdnikov Wrote:
-------------------------------------------------------
> On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:
> > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> > дополнительный запрос к ресурсу.
>
> Если клиент умеет cache digest, то да, может отказаться заранее.
> А если нет, то к тому моменту, когда клиент сможет отклонить push,
> данные уже летят по сети и отъедают пропускную способность канала,
> это обстоятельство может навредить желанию загрузить все причандалы
> к странице побыстрее.
>
> Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю
> профит от сложной и очень тяжёлой технологии". И push в том ряду.
И мультиплексирование запросов?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,288118#msg-288118
From nginx-forum на forum.nginx.org Mon May 25 00:49:36 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Sun, 24 May 2020 20:49:36 -0400
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
=?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
=?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
=?UTF-8?B?IExpbms/?=
In-Reply-To:
References:
Message-ID: <49fe7c7e187d26e61d8e97a734bb3af7.NginxMailingListRussian@forum.nginx.org>
> насчет действительно связанных css и js - в принципе можно их
> эмбедить
> прямо в html разметку. и отдавать вместе с основной страницей.
> тот же push.
Только без потенциального выигрыша в попадании из push-кэша в основной с
возможностью отказаться от получения ресурса в дальнейшем.
А если клиент не умеет отказываться от ресурсов или не разделяет кэши —
получаем полный аналог простого включения в HTML.
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,288119#msg-288119
From nginx-forum на forum.nginx.org Mon May 25 02:19:20 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Sun, 24 May 2020 22:19:20 -0400
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
=?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
=?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
=?UTF-8?B?IExpbms/?=
In-Reply-To:
References:
Message-ID: <91c9b1fb1e5460fa39b3e709ce2cf768.NginxMailingListRussian@forum.nginx.org>
Илья Шипицин Wrote:
-------------------------------------------------------
> у вас же должны быть логи по html страницам и по css-файлам.
> посмотрите на них.
> если
>
> а) у вас хорошее кеширование (т.е. ноль 304-х)
> б) количество ответов css соответствует количеству отданных html страниц
>
> то, вероятно, в вашем случае будет профит от того, что сделаете push на
css
> ну и наоборот, если css отдается меньше, или отдается столько же, но
> много 304-х, то выигрыш будет отрицательный
Доля ответов 304 среди 304 + 200 для CSS за месяц — 0,094%.
Их практически нет.
Отношение CSS / HTML — 0,164.
На трафике порядка миллиона хитов к страницам в месяц.
CSS отдаётся «навечно», инвалидируется версией в URL.
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,288123#msg-288123
From nginx-forum на forum.nginx.org Mon May 25 03:28:24 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Sun, 24 May 2020 23:28:24 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC0?=
=?UTF-8?B?0YDRg9Cz0L7QuSDQsNC00YDQtdGB?=
In-Reply-To: <75a80bf654728bdf2cfde7dcc8c67f2b.NginxMailingListRussian@forum.nginx.org>
References: <7392647de857488a3ab2209713d4bd7a.NginxMailingListRussian@forum.nginx.org>
<08d33518ddc55988dc4b61810de727f5.NginxMailingListRussian@forum.nginx.org>
<75a80bf654728bdf2cfde7dcc8c67f2b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <6252477b6fda3249308649a438eb2cf0.NginxMailingListRussian@forum.nginx.org>
$request_uri где
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287854,288124#msg-288124
From nginx-forum на forum.nginx.org Tue May 26 11:51:04 2020
From: nginx-forum на forum.nginx.org (NaviTrack)
Date: Tue, 26 May 2020 07:51:04 -0400
Subject: =?UTF-8?B?Tmdpbngg0LLQvtC30LLRgNCw0YnQsNC10YIgSFRUUCBDb2RlIDUwMCDQtNC70Y8g?=
=?UTF-8?B?0LHQvtC70YzRiNC40YUgSlNPTiDQt9Cw0L/RgNC+0YHQvtCy?=
Message-ID: <00cb80bd36625d51d83973104dc177a4.NginxMailingListRussian@forum.nginx.org>
Добрый день.
Столкнулся со следующей проблемой: при отправке большого запроса с JSON
содержимым (более 10 kB),
Nginx возвращает ошибку "500 Internal Server Error".
Но, когда отправляю этот же запрос, но уменьшив содержимое, то все работает
нормально.
Вот что пытался сделать:
1. Включил "debug" режим для логов ошибок, но в файле error.log ничего нет.
2. Добавил '$upstream_response_length $upstream_response_time
$upstream_status $request_body' параметры в лог в access.log.
Для успешных запросов, вижу эти параметры.
Но как только отправляю большой запрос и получаю ошибку "500 Internal Server
Error", то уже не вижу этих параметров.
Вот пример строки из лога:
"POST /report/exportreport HTTP/1.1" 500 186 9216 "-" - - - -
"PostmanRuntime/7.25.0" "-"
3. Также пытался использовать параметр 'client_max_body_size' в конфиг
файле.
Но это не помогло.
Похоже на то, что Nginx "обрезает" часть запроса, когда доходит до какого то
лимита.
Подскажите, пожалуйста, куда смотреть, что еще попробовать?
Заранее спасибо.
Версия Nginx: 1.14.1
Конфиг Nginx:
user centos;
worker_processes auto;
error_log /var/log/nginx/error.log debug;
pid /run/nginx.pid;
# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent $request_length "$http_referer" '
'$upstream_response_length $upstream_response_time $upstream_status '
'$request_body '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
access_log on;
error_log on;
client_max_body_size 1m;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# don't send the nginx version number in error pages and Server header
server_tokens off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
# enable session resumption to improve https performance
# http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;
##
# Gzip Settings
##
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript
text/xml application/xml application/xml+rss text/javascript;
# Load modular configuration files from the /etc/nginx/conf.d directory.
# See http://nginx.org/en/docs/ngx_core_module.html#include
# for more information.
include /etc/nginx/conf.d/*.conf;
# frontnend
server {
if ($request_method !~ ^(GET|POST)$ )
{
return 405;
}
server_name www.fcs.navitrack.com.ua fcs.navitrack.com.ua;
listen 443 ssl;
listen [::]:443 ssl;
root /home/centos/navitrack/navitrack-fcs/frontend;
index index.html;
ssl_certificate
"/etc/letsencrypt/live/www.fcs.navitrack.com.ua/fullchain.pem";
ssl_certificate_key
"/etc/letsencrypt/live/www.fcs.navitrack.com.ua/privkey.pem";
ssl_trusted_certificate
"/etc/letsencrypt/live/www.fcs.navitrack.com.ua/fullchain.pem";
client_max_body_size 1m;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
add_header 'X-XSS-Protection' '1; mode=block' always;
add_header 'X-Content-Type-Option' 'nosniff' always;
add_header 'X-Frame-Options' 'SAMEORIGIN' always;
add_header 'Content-Security-Policy' "default-src 'self'; script-src 'self'
https://maps.googleapis.com; style-src 'self' 'unsafe-inline'
https://fonts.googleapis.com; img-src 'self' https://maps.googleapis.com
https://maps.gstatic.com data:; font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://api.fcs.navitrack.com.ua
https://maps.googleapis.com";
}
location /login {
alias /home/centos/navitrack/navitrack-fcs/frontend;
add_header 'X-XSS-Protection' '1; mode=block' always;
add_header 'X-Content-Type-Option' 'nosniff' always;
add_header 'X-Frame-Options' 'SAMEORIGIN' always;
add_header 'Content-Security-Policy' "default-src 'self'; script-src 'self'
https://maps.googleapis.com; style-src 'self' 'unsafe-inline'
https://fonts.googleapis.com; img-src 'self' https://maps.googleapis.com
https://maps.gstatic.com data:; font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://api.fcs.navitrack.com.ua
https://maps.googleapis.com";
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
# backend
server {
if ($request_method !~ ^(GET|POST|OPTIONS)$ )
{
return 405;
}
server_name api.fcs.navitrack.com.ua;
listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate
"/etc/letsencrypt/live/api.fcs.navitrack.com.ua/fullchain.pem";
ssl_certificate_key
"/etc/letsencrypt/live/api.fcs.navitrack.com.ua/privkey.pem";
ssl_trusted_certificate
"/etc/letsencrypt/live/api.fcs.navitrack.com.ua/fullchain.pem";
client_max_body_size 1m;
location / {
#add CORS
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' 'https://fcs.navitrack.com.ua'
always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers'
'Authorization,DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range'
always;
add_header 'Access-Control-Max-Age' 86400 always;
add_header 'Content-Type' 'text/plain; charset=utf-8' always;
add_header 'Content-Length' 0 always;
return 204;
}
if ($request_method = 'GET') {
add_header 'Access-Control-Allow-Origin' 'https://fcs.navitrack.com.ua'
always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers'
'Authorization,DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range'
always;
}
if ($request_method = 'POST') {
add_header 'Access-Control-Allow-Origin' 'https://fcs.navitrack.com.ua'
always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers'
'Authorization,DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range'
always;
}
proxy_pass http://localhost:18745;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffer_size 20k;
proxy_buffers 16 256k;
proxy_busy_buffers_size 512k;
}
}
}
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288138,288138#msg-288138
From kulmaks на gmail.com Tue May 26 12:16:52 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Tue, 26 May 2020 15:16:52 +0300
Subject: =?UTF-8?B?UmU6IE5naW54INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCIEhUVFAgQ29kZSA1MDAg0LQ=?=
=?UTF-8?B?0LvRjyDQsdC+0LvRjNGI0LjRhSBKU09OINC30LDQv9GA0L7RgdC+0LI=?=
In-Reply-To: <00cb80bd36625d51d83973104dc177a4.NginxMailingListRussian@forum.nginx.org>
References: <00cb80bd36625d51d83973104dc177a4.NginxMailingListRussian@forum.nginx.org>
Message-ID:
Для начала надо все же разобраться с логами. Есть у меня стойкое ощущение,
что ваши логи пишутся в файл с именем "on".
http://nginx.org/ru/docs/ngx_core_module.html#error_log
У директив access_log и error_log нет значения "on" и оно явно
воспринимается как путь к файлу.
Кроме этого, для получения логов уровня debug, необходимо собрать nginx
c --with-debug.
вт, 26 мая 2020 г. в 14:51, NaviTrack :
> access_log on;
>
error_log on;
>
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288138,288138#msg-288138
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL:
From mdounin на mdounin.ru Tue May 26 15:09:16 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 26 May 2020 18:09:16 +0300
Subject: nginx-1.19.0
Message-ID: <20200526150916.GJ12747@mdounin.ru>
Изменения в nginx 1.19.0 26.05.2020
*) Добавление: проверка клиентских сертификатов с помощью OCSP.
*) Исправление: при работе с gRPC-бэкендами могли возникать ошибки
"upstream sent frame for closed stream".
*) Исправление: OCSP stapling мог не работать, если не была указана
директива resolver.
*) Исправление: соединения с некорректным HTTP/2 preface не
логгировались.
--
Maxim Dounin
http://nginx.org/
From nginx-forum на forum.nginx.org Tue May 26 21:03:13 2020
From: nginx-forum на forum.nginx.org (NaviTrack)
Date: Tue, 26 May 2020 17:03:13 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCIEhUVFAgQ29kZSA1MDAg0LQ=?=
=?UTF-8?B?0LvRjyDQsdC+0LvRjNGI0LjRhSBKU09OINC30LDQv9GA0L7RgdC+0LI=?=
In-Reply-To:
References:
Message-ID: <36c267c8721c97bc6c5af39a580ebc37.NginxMailingListRussian@forum.nginx.org>
Добрый день.
После исправления логгирования, в error.log появилась такая ошибка:
[crit] 3993#0: *1 open() "/var/lib/nginx/tmp/client_body/0000000001" failed
(13: Permission denied), client: xxxx, server: xxxxxxxx, request: "POST
/report/exportreport HTTP/1.1", host: "xxxxxxxxxxx"
Оказалось, проблема с настройкой прав.
После добавления нужных прав, все заработало.
Спасибо большое за помощь.
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288138,288159#msg-288159
From kulmaks на gmail.com Wed May 27 06:01:00 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Wed, 27 May 2020 09:01:00 +0300
Subject: =?UTF-8?B?UmU6IE5naW54INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCIEhUVFAgQ29kZSA1MDAg0LQ=?=
=?UTF-8?B?0LvRjyDQsdC+0LvRjNGI0LjRhSBKU09OINC30LDQv9GA0L7RgdC+0LI=?=
In-Reply-To: <36c267c8721c97bc6c5af39a580ebc37.NginxMailingListRussian@forum.nginx.org>
References:
<36c267c8721c97bc6c5af39a580ebc37.NginxMailingListRussian@forum.nginx.org>
Message-ID:
У вас тело запроса сохраняется во временный файл. Если дисковая подсистема
не очень быстрая, а запросов будет много и при условии достаточного
количества RAM - лучше подкрутить
http://nginx.org/ru/docs/http/ngx_http_core_module.html#client_body_buffer_size
Заодно
и проблема с правами не возникла бы.
ср, 27 мая 2020 г. в 00:03, NaviTrack :
> Добрый день.
>
> После исправления логгирования, в error.log появилась такая ошибка:
> [crit] 3993#0: *1 open() "/var/lib/nginx/tmp/client_body/0000000001" failed
> (13: Permission denied), client: xxxx, server: xxxxxxxx, request: "POST
> /report/exportreport HTTP/1.1", host: "xxxxxxxxxxx"
>
> Оказалось, проблема с настройкой прав.
> После добавления нужных прав, все заработало.
>
> Спасибо большое за помощь.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288138,288159#msg-288159
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL:
From nginx-forum на forum.nginx.org Wed May 27 12:39:41 2020
From: nginx-forum на forum.nginx.org (NaviTrack)
Date: Wed, 27 May 2020 08:39:41 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCIEhUVFAgQ29kZSA1MDAg0LQ=?=
=?UTF-8?B?0LvRjyDQsdC+0LvRjNGI0LjRhSBKU09OINC30LDQv9GA0L7RgdC+0LI=?=
In-Reply-To:
References:
Message-ID:
Такие запросы будут достаточно редо приходить.
Но за совет спасибо, будем пробовать
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288138,288164#msg-288164
From nginx-forum на forum.nginx.org Wed May 27 22:40:31 2020
From: nginx-forum на forum.nginx.org (oradba25)
Date: Wed, 27 May 2020 18:40:31 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCIEhUVFAgQ29kZSA1MDAg0LQ=?=
=?UTF-8?B?0LvRjyDQsdC+0LvRjNGI0LjRhSBKU09OINC30LDQv9GA0L7RgdC+0LI=?=
In-Reply-To: <00cb80bd36625d51d83973104dc177a4.NginxMailingListRussian@forum.nginx.org>
References: <00cb80bd36625d51d83973104dc177a4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <84acce1d1cc01303b8c8666b361b6f07.NginxMailingListRussian@forum.nginx.org>
> error_page 404 /404.html;
> location = /40x.html {
> }
>
А 404 при таком подходе не улетит в рекурсию и 500 в конце концов?
Или таки существует страница /404.html?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288138,288172#msg-288172
From nginx-forum на forum.nginx.org Thu May 28 05:55:51 2020
From: nginx-forum на forum.nginx.org (FuckYouSystem)
Date: Thu, 28 May 2020 01:55:51 -0400
Subject: =?UTF-8?B?0J3QtSDQv9C+0LvRg9GH0LDQtdGC0YHRjyDRg9Cy0LXQu9C40YfQuNGC0Ywg0YA=?=
=?UTF-8?B?0LDQt9C80LXRgCDQv9GA0LjQvdC40LzQsNC10LzQvtCz0L4gUE9TVCDQt9Cw?=
=?UTF-8?B?0L/RgNC+0YHQsA==?=
Message-ID: <61a5dda7617a9df98bc95841ff583b71.NginxMailingListRussian@forum.nginx.org>
Нужно отправить запрос на сервер, методом POST. Получаю ошибку 414. Запрос
содержит более 8196 символов и отрпавляется с content-type: x-www-urlencode.
Если меньше символов, то все хорошо. Увеличивал в /etc/nginx/nginx.conf -
max-body-size, не получается, и так уже 256М стоит.
Сервер Debian 9, панель Vesta, связка с Apache, php 7.4
Обоше конфиги апачаи пхп, тоже не получается
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288174,288174#msg-288174
From kulmaks на gmail.com Thu May 28 05:59:28 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Thu, 28 May 2020 08:59:28 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8g0YPQstC10LvQuNGH0LjRgtGM?=
=?UTF-8?B?INGA0LDQt9C80LXRgCDQv9GA0LjQvdC40LzQsNC10LzQvtCz0L4gUE9TVCA=?=
=?UTF-8?B?0LfQsNC/0YDQvtGB0LA=?=
In-Reply-To: <61a5dda7617a9df98bc95841ff583b71.NginxMailingListRussian@forum.nginx.org>
References: <61a5dda7617a9df98bc95841ff583b71.NginxMailingListRussian@forum.nginx.org>
Message-ID:
http://nginx.org/ru/docs/http/ngx_http_core_module.html#large_client_header_buffers
чт, 28 мая 2020 г. в 08:56, FuckYouSystem :
> Нужно отправить запрос на сервер, методом POST. Получаю ошибку 414. Запрос
> содержит более 8196 символов и отрпавляется с content-type:
> x-www-urlencode.
> Если меньше символов, то все хорошо. Увеличивал в /etc/nginx/nginx.conf -
> max-body-size, не получается, и так уже 256М стоит.
> Сервер Debian 9, панель Vesta, связка с Apache, php 7.4
>
> Обоше конфиги апачаи пхп, тоже не получается
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288174,288174#msg-288174
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL:
From nginx-forum на forum.nginx.org Thu May 28 06:08:22 2020
From: nginx-forum на forum.nginx.org (FuckYouSystem)
Date: Thu, 28 May 2020 02:08:22 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8g0YPQstC10LvQuNGH0LjRgtGM?=
=?UTF-8?B?INGA0LDQt9C80LXRgCDQv9GA0LjQvdC40LzQsNC10LzQvtCz0L4gUE9TVCA=?=
=?UTF-8?B?0LfQsNC/0YDQvtGB0LA=?=
In-Reply-To:
References:
Message-ID: <7320cb0d98036aaac6bd07641cc05ed9.NginxMailingListRussian@forum.nginx.org>
http://nginx.org/ru/docs/http/ngx_http_core_module.html#large_client_header_buffers
Не сработало, выставлял 32k и 32m. Нгинкс рестартил
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288174,288176#msg-288176
From kulmaks на gmail.com Thu May 28 06:16:34 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Thu, 28 May 2020 09:16:34 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8g0YPQstC10LvQuNGH0LjRgtGM?=
=?UTF-8?B?INGA0LDQt9C80LXRgCDQv9GA0LjQvdC40LzQsNC10LzQvtCz0L4gUE9TVCA=?=
=?UTF-8?B?0LfQsNC/0YDQvtGB0LA=?=
In-Reply-To: <7320cb0d98036aaac6bd07641cc05ed9.NginxMailingListRussian@forum.nginx.org>
References:
<7320cb0d98036aaac6bd07641cc05ed9.NginxMailingListRussian@forum.nginx.org>
Message-ID:
Тогда нужен полный конфиг и ошибки из лога ошибок.
чт, 28 мая 2020 г. в 09:08, FuckYouSystem :
>
> http://nginx.org/ru/docs/http/ngx_http_core_module.html#large_client_header_buffers
>
>
> Не сработало, выставлял 32k и 32m. Нгинкс рестартил
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288174,288176#msg-288176
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL:
From nginx-forum на forum.nginx.org Thu May 28 06:35:43 2020
From: nginx-forum на forum.nginx.org (FuckYouSystem)
Date: Thu, 28 May 2020 02:35:43 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8g0YPQstC10LvQuNGH0LjRgtGM?=
=?UTF-8?B?INGA0LDQt9C80LXRgCDQv9GA0LjQvdC40LzQsNC10LzQvtCz0L4gUE9TVCA=?=
=?UTF-8?B?0LfQsNC/0YDQvtGB0LA=?=
In-Reply-To:
References:
Message-ID: <07d70dc3f8906848a82f59a8ae48c325.NginxMailingListRussian@forum.nginx.org>
# Server globals
user www-data;
worker_processes auto;
worker_rlimit_nofile 65535;
timer_resolution 50ms; #In order to free some CPU cycles
error_log /var/log/nginx/error.log crit;
pid /var/run/nginx.pid;
# Worker config
events {
worker_connections 1024;
use epoll;
multi_accept on;
}
http {
# Main settings
sendfile on;
tcp_nopush on;
tcp_nodelay on;
client_header_timeout 1m;
client_body_timeout 1m;
client_header_buffer_size 2k;
client_body_buffer_size 256k;
client_max_body_size 256m;
large_client_header_buffers 4 32m;
send_timeout 30;
keepalive_timeout 60 60;
reset_timedout_connection on;
server_tokens off;
server_name_in_redirect off;
server_names_hash_max_size 512;
server_names_hash_bucket_size 512;
# Log format
log_format main '$remote_addr - $remote_user [$time_local] $request
'
'"$status" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
log_format bytes '$body_bytes_sent';
#access_log /var/log/nginx/access.log main;
access_log off;
# Mime settings
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Compression
gzip on;
gzip_vary on;
gzip_comp_level 9;
gzip_min_length 512;
gzip_buffers 8 64k;
gzip_types text/plain text/css text/javascript text/js text/xml
application/json application/javascript application/x-javascript
application/xml application/xml+rss application/x-font-ttf image/svg+xml
font/opentype;
gzip_proxied any;
gzip_disable "MSIE [1-6]\.";
# Proxy settings
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass_header Set-Cookie;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffers 32 4k;
# Cloudflare https://www.cloudflare.com/ips
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/12;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2c0f:f248::/32;
set_real_ip_from 2a06:98c0::/29;
real_ip_header CF-Connecting-IP;
# SSL PCI Compliance
ssl_session_cache shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers
"ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
# Error pages
error_page 403 /error/403.html;
error_page 404 /error/404.html;
error_page 502 503 504 /error/50x.html;
# Cache settings
proxy_cache_path /var/cache/nginx levels=2 keys_zone=cache:10m
inactive=60m max_size=1024m;
proxy_cache_key "$host$request_uri $cookie_user";
proxy_temp_path /var/cache/nginx/temp;
proxy_ignore_headers Expires Cache-Control;
proxy_cache_use_stale error timeout invalid_header http_502;
proxy_cache_valid any 1d;
# Cache bypass
map $http_cookie $no_cache {
default 0;
~SESS 1;
~wordpress_logged_in 1;
}
# File cache settings
open_file_cache max=10000 inactive=30s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors off;
# Wildcard include
include /etc/nginx/conf.d/*.conf;
}
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288174,288178#msg-288178
From kulmaks на gmail.com Thu May 28 07:50:34 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Thu, 28 May 2020 10:50:34 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8g0YPQstC10LvQuNGH0LjRgtGM?=
=?UTF-8?B?INGA0LDQt9C80LXRgCDQv9GA0LjQvdC40LzQsNC10LzQvtCz0L4gUE9TVCA=?=
=?UTF-8?B?0LfQsNC/0YDQvtGB0LA=?=
In-Reply-To: <07d70dc3f8906848a82f59a8ae48c325.NginxMailingListRussian@forum.nginx.org>
References:
<07d70dc3f8906848a82f59a8ae48c325.NginxMailingListRussian@forum.nginx.org>
Message-ID:
А что в блоке server для конкретного хоста? Что с логом ошибок? Может 414
возвращает не nginx, а apache, который стоит за ним? Без логов этого не
понять.
чт, 28 мая 2020 г. в 09:35, FuckYouSystem :
> # Server globals
> user www-data;
> worker_processes auto;
> worker_rlimit_nofile 65535;
> timer_resolution 50ms; #In order to free some CPU cycles
> error_log /var/log/nginx/error.log crit;
> pid /var/run/nginx.pid;
>
>
> # Worker config
> events {
> worker_connections 1024;
> use epoll;
> multi_accept on;
> }
>
>
> http {
> # Main settings
> sendfile on;
> tcp_nopush on;
> tcp_nodelay on;
> client_header_timeout 1m;
> client_body_timeout 1m;
> client_header_buffer_size 2k;
> client_body_buffer_size 256k;
> client_max_body_size 256m;
> large_client_header_buffers 4 32m;
> send_timeout 30;
> keepalive_timeout 60 60;
> reset_timedout_connection on;
> server_tokens off;
> server_name_in_redirect off;
> server_names_hash_max_size 512;
> server_names_hash_bucket_size 512;
>
>
> # Log format
> log_format main '$remote_addr - $remote_user [$time_local] $request
> '
> '"$status" $body_bytes_sent "$http_referer" '
> '"$http_user_agent" "$http_x_forwarded_for"';
> log_format bytes '$body_bytes_sent';
> #access_log /var/log/nginx/access.log main;
> access_log off;
>
>
> # Mime settings
> include /etc/nginx/mime.types;
> default_type application/octet-stream;
>
>
> # Compression
> gzip on;
> gzip_vary on;
> gzip_comp_level 9;
> gzip_min_length 512;
> gzip_buffers 8 64k;
> gzip_types text/plain text/css text/javascript text/js
> text/xml
> application/json application/javascript application/x-javascript
> application/xml application/xml+rss application/x-font-ttf image/svg+xml
> font/opentype;
> gzip_proxied any;
> gzip_disable "MSIE [1-6]\.";
>
> # Proxy settings
> proxy_redirect off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_pass_header Set-Cookie;
> proxy_connect_timeout 90;
> proxy_send_timeout 90;
> proxy_read_timeout 90;
> proxy_buffers 32 4k;
>
>
> # Cloudflare https://www.cloudflare.com/ips
> set_real_ip_from 103.21.244.0/22;
> set_real_ip_from 103.22.200.0/22;
> set_real_ip_from 103.31.4.0/22;
> set_real_ip_from 104.16.0.0/12;
> set_real_ip_from 108.162.192.0/18;
> set_real_ip_from 131.0.72.0/22;
> set_real_ip_from 141.101.64.0/18;
> set_real_ip_from 162.158.0.0/15;
> set_real_ip_from 172.64.0.0/13;
> set_real_ip_from 173.245.48.0/20;
> set_real_ip_from 188.114.96.0/20;
> set_real_ip_from 190.93.240.0/20;
> set_real_ip_from 197.234.240.0/22;
> set_real_ip_from 198.41.128.0/17;
> set_real_ip_from 2400:cb00::/32;
> set_real_ip_from 2606:4700::/32;
> set_real_ip_from 2803:f800::/32;
> set_real_ip_from 2405:b500::/32;
> set_real_ip_from 2405:8100::/32;
> set_real_ip_from 2c0f:f248::/32;
> set_real_ip_from 2a06:98c0::/29;
> real_ip_header CF-Connecting-IP;
>
>
> # SSL PCI Compliance
> ssl_session_cache shared:SSL:10m;
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> ssl_prefer_server_ciphers on;
> ssl_ciphers
>
> "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
>
>
> # Error pages
> error_page 403 /error/403.html;
> error_page 404 /error/404.html;
> error_page 502 503 504 /error/50x.html;
>
>
> # Cache settings
> proxy_cache_path /var/cache/nginx levels=2 keys_zone=cache:10m
> inactive=60m max_size=1024m;
> proxy_cache_key "$host$request_uri $cookie_user";
> proxy_temp_path /var/cache/nginx/temp;
> proxy_ignore_headers Expires Cache-Control;
> proxy_cache_use_stale error timeout invalid_header http_502;
> proxy_cache_valid any 1d;
>
>
> # Cache bypass
> map $http_cookie $no_cache {
> default 0;
> ~SESS 1;
> ~wordpress_logged_in 1;
> }
>
>
> # File cache settings
> open_file_cache max=10000 inactive=30s;
> open_file_cache_valid 60s;
> open_file_cache_min_uses 2;
> open_file_cache_errors off;
>
>
> # Wildcard include
> include /etc/nginx/conf.d/*.conf;
> }
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288174,288178#msg-288178
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL:
From nginx-forum на forum.nginx.org Thu May 28 07:55:34 2020
From: nginx-forum на forum.nginx.org (NaviTrack)
Date: Thu, 28 May 2020 03:55:34 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCIEhUVFAgQ29kZSA1MDAg0LQ=?=
=?UTF-8?B?0LvRjyDQsdC+0LvRjNGI0LjRhSBKU09OINC30LDQv9GA0L7RgdC+0LI=?=
In-Reply-To: <84acce1d1cc01303b8c8666b361b6f07.NginxMailingListRussian@forum.nginx.org>
References: <00cb80bd36625d51d83973104dc177a4.NginxMailingListRussian@forum.nginx.org>
<84acce1d1cc01303b8c8666b361b6f07.NginxMailingListRussian@forum.nginx.org>
Message-ID:
Да, есть страница 404.html
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288138,288181#msg-288181
From nginx-forum на forum.nginx.org Thu May 28 08:19:48 2020
From: nginx-forum на forum.nginx.org (FuckYouSystem)
Date: Thu, 28 May 2020 04:19:48 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8g0YPQstC10LvQuNGH0LjRgtGM?=
=?UTF-8?B?INGA0LDQt9C80LXRgCDQv9GA0LjQvdC40LzQsNC10LzQvtCz0L4gUE9TVCA=?=
=?UTF-8?B?0LfQsNC/0YDQvtGB0LA=?=
In-Reply-To:
References:
Message-ID: <2e8d4a7852db204bdf26ce8d141a07ba.NginxMailingListRussian@forum.nginx.org>
А где хранится лог?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288174,288182#msg-288182
From kulmaks на gmail.com Thu May 28 08:23:02 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Thu, 28 May 2020 11:23:02 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8g0YPQstC10LvQuNGH0LjRgtGM?=
=?UTF-8?B?INGA0LDQt9C80LXRgCDQv9GA0LjQvdC40LzQsNC10LzQvtCz0L4gUE9TVCA=?=
=?UTF-8?B?0LfQsNC/0YDQvtGB0LA=?=
In-Reply-To: <2e8d4a7852db204bdf26ce8d141a07ba.NginxMailingListRussian@forum.nginx.org>
References:
<2e8d4a7852db204bdf26ce8d141a07ba.NginxMailingListRussian@forum.nginx.org>
Message-ID:
Где-то в конфиге nginx должны быть директивы error_log. Искать конфиги,
видимо, надо здесь: /etc/nginx/conf.d/*.conf
чт, 28 мая 2020 г. в 11:19, FuckYouSystem :
> А где хранится лог?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288174,288182#msg-288182
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL:
From nginx-forum на forum.nginx.org Thu May 28 08:36:59 2020
From: nginx-forum на forum.nginx.org (FuckYouSystem)
Date: Thu, 28 May 2020 04:36:59 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8g0YPQstC10LvQuNGH0LjRgtGM?=
=?UTF-8?B?INGA0LDQt9C80LXRgCDQv9GA0LjQvdC40LzQsNC10LzQvtCz0L4gUE9TVCA=?=
=?UTF-8?B?0LfQsNC/0YDQvtGB0LA=?=
In-Reply-To:
References:
Message-ID: <73317b10617214a0736217b937194ef7.NginxMailingListRussian@forum.nginx.org>
В логаха нгинкс пусто, в логаха апача просто коннекты с юзер агентами
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288174,288184#msg-288184
From kulmaks на gmail.com Thu May 28 09:11:02 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Thu, 28 May 2020 12:11:02 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8g0YPQstC10LvQuNGH0LjRgtGM?=
=?UTF-8?B?INGA0LDQt9C80LXRgCDQv9GA0LjQvdC40LzQsNC10LzQvtCz0L4gUE9TVCA=?=
=?UTF-8?B?0LfQsNC/0YDQvtGB0LA=?=
In-Reply-To: <73317b10617214a0736217b937194ef7.NginxMailingListRussian@forum.nginx.org>
References:
<73317b10617214a0736217b937194ef7.NginxMailingListRussian@forum.nginx.org>
Message-ID:
Если в логах ошибок пусто:
1. Ошибку возвращает не nginx, а апстрим.
2. Не в тех логах смотрите.
3. Ошибок нет.
Как вариант, можно поставить уровень логов - info. Или найти фрилансера,
который все сделает.
чт, 28 мая 2020 г. в 11:37, FuckYouSystem :
> В логаха нгинкс пусто, в логаха апача просто коннекты с юзер агентами
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288174,288184#msg-288184
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL:
From nginx-forum на forum.nginx.org Fri May 29 08:01:43 2020
From: nginx-forum на forum.nginx.org (l0ving1991)
Date: Fri, 29 May 2020 04:01:43 -0400
Subject: Nginx proxy cache
Message-ID:
Есть ли возможность получить доступ к инфе о кеширование объектов через
proxy_cache
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288211,288211#msg-288211