Изменения в nginx 1.23.0 21.06.2022
*) Изменение во внутреннем API: теперь строки заголовков представлены
связными списками.
*) Изменение: теперь nginx объединяет произвольные строки заголовков с
одинаковыми именами при отправке на FastCGI-, SCGI- и uwsgi-бэкенды,
в методе $r->header_in() модуля ngx_http_perl_module, и при доступе
через переменные "$http_...", "$sent_http_...", "$sent_trailer_...",
"$upstream_http_..." и "$upstream_trailer_...".
*) Исправление: если в заголовке ответа бэкенда было несколько строк
"Vary", при кэшировании nginx учитывал только последнюю из них.
*) Исправление: если в заголовке ответа бэкенда было несколько строк
"WWW-Authenticate" и использовался перехват ошибок с кодом 401 от
бэкенда или директива auth_request, nginx пересылал клиенту только
первую из этих строк.
*) Изменение: уровень логгирования ошибок SSL "application data after
close notify" понижен с уровня crit до info.
*) Исправление: соединения могли зависать, если nginx был собран на
Linux 2.6.17 и новее, а использовался на системах без поддержки
EPOLLRDHUP, в частности, на системах с эмуляцией epoll; ошибка
появилась в 1.17.5.
Спасибо Marcus Ball.
*) Исправление: nginx не кэшировал ответ, если строка заголовка ответа
"Expires" запрещала кэширование, а последующая строка заголовка
"Cache-Control" разрешала кэширование.
--
Maxim Dounin
http://nginx.org/
Здравствуйте, All!
В документации к nginx встречается
упоминание про директиву memcached_force_ranges
https://nginx.org/en/docs/http/ngx_http_memcached_module.html#memcached_for…
Однако, в исходниках nginx нет директивы memcached_force_ranges
- похоже на то, что директиву из исходников nginx удалили,
а документацию и файл CHANGES обновить забыли?
nginx/src/http/modules/ngx_http_memcached_module.c
/* the hardcoded values */
conf->upstream.force_ranges = 1;
--
Best regards,
Gena
Привет.
Че-то я туплю. Пересмотрел конфиги и документацию не один раз, но ошибку не
вижу.
Есть основной сайт, который должен открываться только по адресу
httpS://site.ru, но при этом по адресу http://beta.site.ru должна работать
так сказать тестовая версия сайта без шифрования.
Суть проблемы – почему-то при заходе по адресу httpS://beta.site.ru
открывается основная версия сайта. Почему - понять не могу. По адресу
http://beta.site.ru – все ок.
Конфиг:
# по умолчанию
server
{
listen 80 default_server;
server_name 1.2.3.4;
allow 127.0.0.1;
deny all;
}
# версия для тестов
server
{
listen 80;
server_name beta.site.ru ;
…
}
# редирект с http на https
server
{
listen 80;
server_name site.ru;
access_log off;
return 301 https://site.ru$request_uri;
}
# редирект с www на non-www
server
{
listen 443 ssl;
# ssl_certificate domain.crt;
# ssl_certificate_key domain-key.txt;
server_name www.site.ru;
access_log off;
rewrite ^(.*)$ https://site.ru$1 permanent;
}
# основная версия сайта
server
{
listen 443 ssl http2;
server_name site.ru ;
…
}
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294517,294517#msg-294517
Здравствуйте.
Протестировал последнюю ревизию nginxQuic 5b1011b5702b.
Проблема с долгим ответом от сервера всё ещё сохранилась.
От клиента приходит запрос, через tcpdump видно что запрос доходит до сервера nginx (в debug логе отображается событие), но
по какой-то причине, nginx отдаёт ответ только через 5-7 секунд. В конечном итоге происходят задержки в работе сайта и бразуер переключается
на работу по http2 протоколу.
--
С уважением,
Izorkin mailto:izorkin@gmail.com
Здравствуйте
Linux 3.10.0-1160.66.1.el7.x86_64
Компиляция/сборка самого nginx проходит без проблем
При попытке компилить сам модуль naxsi выходит ошибка
cc -c -fPIC -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror
-g -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -I
src/http -I src/http/modules -I src/http/v2 -I src/mail -I src/stream \
-o objs/addon/naxsi_src/naxsi_runtime.o \
../naxsi/naxsi_src/naxsi_runtime.c
In file included from src/event/ngx_event.h:526:0,
from ../naxsi/naxsi_src/naxsi.h:18,
from ../naxsi/naxsi_src/naxsi_runtime.c:8:
src/event/ngx_event_udp.h:37:27: ошибка: field «pkt6» has incomplete type
struct in6_pktinfo pkt6;
^
make[1]: *** [objs/addon/naxsi_src/naxsi_runtime.o] Ошибка 1
Поиском попадалось, что это возможно из-за более раннего включения системных
заголовков, чем заголовки nginx
Но тут вроде все безопасно
В самом naxsi.h
#include "ext/libinjection/libinjection_sqli.h"
#include "ext/libinjection/libinjection_xss.h"
#include <ctype.h>
#include <nginx.h>
#include <ngx_config.h>
#include <ngx_core.h>
#include <ngx_event.h> <--- Вот тут и ломается
#include <ngx_http.h>
#include <ngx_http_core_module.h>
#include <ngx_md5.h>
#include <pcre.h>
В двух первых подключается только string.h
Лечится комментированием в ngx_event_udp.h
#if (NGX_HAVE_INET6 && NGX_HAVE_IPV6_RECVPKTINFO)
/* struct in6_pktinfo pkt6;*/
#endif
IPv6 у нас не ходит, и возможно, это пролезет
Но как-то корявенько
Может подскажете, как решить более штатными средствами
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294312,294312#msg-294312
Здравствуйте.
Подскажите пожалуйста, есть ли способ настроить nginx так, чтобы он
читал более большими кусками файлы? У меня стоит задача раздавать файлы,
размер которых от 0,7 до 8 мегабайт. Большая часть больше 1М .
Собрал массив на тестовом сервере.
lsi raid1, размер чанка 1М,
Тест fio с размером блока 1М показывает производительность массива
185-190 МБ/с
Nginx , судя по iostat avgrq-sz, читает кусками чуть меньше 256КБ .
Пиковая производительность в 2 раза меньше (около 80-85МБ/с).
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s
avgrq-sz avgqu-sz await svctm %util
sdd 0.60 0.00 348.80 0.00 73.39 0.00
430.93 7.01 20.08 2.45 85.44
Пробовал как ext4, так и xfs. Результат примерно одинаков. Максимальный
размер io у VD дисков выставлен в 1 мегабайт:
/queue/max_hw_sectors_kb:1024
/queue/max_sectors_kb:1024
В тесте fio avgrq-sz близок к 2048, чего и хотелось бы достичь от nginx.
Нигде в документации не нашёл параметров, которые явно могли бы на это
повлиять. Различные буферы "крутить" пробовал, не помогает.
Заранее, большое спасибо за помощь.
С уважением,
Александр Кунич.
Привет всем.
Сайт попал под DDoS. Атакующий как-то криво настроил атаку, все запросы и от
него идут с "левыми" параметром метода:
103.15.245.238 - - [11/May/2022:14:53:53 +0300] "T /
165.25.7.72 - - [11/May/2022:14:53:53 +0300] "ET /
и т.д.
Подскажите, можно на уровне nginx заблокировать такие методы?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294197,294197#msg-294197
Приветствую.
Набрел на ссылку http://wiki.nginx.org/HttpAuthDigestModule/ , ведущую
вроде как на nginx.org, но стоит очень старый Wordpress, судя по коду,
вероятно похацканный.
Там ничего лишнего не поселилось?
С Уважением,
Александр.