Как на уровне сервера для return задать другую схему?
т.е. в конфиге что бы можно было писать 'return 301 /path'
сам nginx работает на http, но есть вариант что через проксю с
терминацией https на ней и в этом случае хотелось бы что бы
'return 301 /path' использовал https.
и map и set на $scheme ругаются: the duplicate "scheme" variable
Приветствую, знаю что с версии 1.21.1 nginx пишет ошибку 400, в случае
пробелов в запросе к серверу.
Но есть старые клиенты, которых нужно поддерживать, подскажите, может есть
какие-то варианты обойти проблему?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294819,294819#msg-294819
Прошу посильной помощи, появилась ошибка 400 Bad Request с http на https
после обновления сертификата летс энкрипт
Конфиг nginx не менялся уже года 3 как минимум, редиректы хорошо работали.
Вчера обновил сертификат летс энкрипт и тут понеслись ошибки редиректа, хотя
и раньше обновлял этот сертификат и было всё хорошо.
Вот конфиг:
server {
listen 80;
server_name .local.map;
rewrite ^(.*) https://$host$1 permanent;
#return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/local.map/fullchain.pem;
ssl_trusted_certificate /etc/letsencrypt/live/local.map/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/local.map/privkey.pem;
server_name .local.map;
set $root /var/www/msk/data/local.map;
root $root;
access_log off;
и т.д....
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294635#msg-294635
Изменения в nginx 1.23.1 19.07.2022
*) Добавление: оптимизация использования памяти в конфигурациях с
SSL-проксированием.
*) Добавление: теперь с помощью параметра "ipv4=off" директивы
"resolver" можно запретить поиск IPv4-адресов при преобразовании имён
в адреса.
*) Изменение: уровень логгирования ошибок SSL "bad key share", "bad
extension", "bad cipher" и "bad ecpoint" понижен с уровня crit до
info.
*) Исправление: при возврате диапазонов nginx не удалял строку заголовка
"Content-Range", если она присутствовала в исходном ответе бэкенда.
*) Исправление: проксированный ответ мог быть отправлен не полностью при
переконфигурации на Linux; ошибка появилась в 1.17.5.
--
Maxim Dounin
http://nginx.org/
Здравствуйте, All!
nginx/1.23.0 из официального репозитория nginx.org
В логах есть такой варнинг:
2022/07/12 13:56:37 [warn] 14352#14352: *183 a client request body is
buffered to a temporary file /var/cache/nginx/client_temp/0000000011,
client: 10.23.154.207, server: sentry.example.com, request: "POST
/api/22/envelope/ HTTP/2.0", host: "sentry.example.com"
Судя по информации из access-лога - размер контента - 41 байт:
# grep /api/22/envelope/ access.log | grep 13:56:37 | less
2022-07-12T13:56:37+03:00 GB 10.23.154.207 https
sentry.example.com POST "/api/22/envelope/" 200 41
"-" "sentry.php.laravel/2.9.0" 0.010 0.002
Если прописать в nginx.conf директиву client_body_buffer_size 32k;
- тогда варнинг из error.log пропадает, но если вернуть дефолтовое
значение client_body_buffer_size 16k; - варнинг снова появляется логах.
Размер контента - всего 41 байт. Как такое может быть?
client_body_buffer_size - эта переменная задает только статический
размер буфера, и в nginx сейчас нельзя сделать динамическое выделение
буфера по необходимости, как это сделано в директиве proxy_buffers ?
Возможно было бы логичним, для экономии памяти сделать возможность
задавать client_body_buffer_size по аналогии с proxy_buffers,
например так:
client_body_buffer_size 8k;
client_body_buffers 32 8k;
--
Best regards,
Gena
Добрый день,
нужно избирательно кешировать ответы бэкэнда в nginx. Некоторые ответы
содержат Set-Cookie заголовки.По-умолчанию их кешировать не нужно, но
если встречается определённая куки, то такой ответ нужно кешировать.
пример:
кешируем ответ с заголовком:
Set-Cookie: pll_language=en; expires=Fri, 07-Jul-2023 11:37:39 GMT;
Max-Age=31536000; path=/; secure; SameSite=Lax
не кешируем ответ с сессией пользователя с заголовком:
Set-Cookie: login=i324iuhkj324; expires=Fri, 10-Jul-2023 11:37:39 GMT;
Max-Age=31536000; path=/; secure
пытаюсь делать так:
map $upstream_http_set_cookie $bypass_cache {
"~*.pll" 0;
default 1;
}
server {
[..]
location @granted {
[..]
proxy_ignore_headers Set-cookie;
proxy_no_cache $bypass_cache;
proxy_cache_bypass $bypass_cache;
add_header X-Bypass $bypass_cache;
add_header X-upstream-set-cookie "aaa $upstream_http_set_cookie";
[..]
}
[..]
}
в ответе получаю:
X-Bypass: 1
X-upstream-set-cookie: aaa pll_language=en; expires=Fri, 07-Jul-2023
11:37:39 GMT; Max-Age=31536000; path=/; secure; SameSite=Lax
такое впечатление, что директива add_header корректно видит содержимое
заголовка ответа апстрима, а вот map (и if тоже пытался) - не видят
содержимого ни $upstream_http_set_cookie ни
$upstream_cookie_pll_language.
Может быть есть какие-то мысли как такое лучше реализовать и возможно
ли это вообще?
nginx -v
nginx version: nginx/1.19.2
nginx -V
nginx version: nginx/1.19.2
built by gcc 8.3.0 (Debian 8.3.0-6)
built with OpenSSL 1.1.1d 10 Sep 2019
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--modules-path=/usr/lib/nginx/modules
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx
--group=nginx --with-compat --with-file-aio --with-threads
--with-http_addition_module --with-http_auth_request_module
--with-http_dav_module --with-http_flv_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_mp4_module --with-http_random_index_module
--with-http_realip_module --with-http_secure_link_module
--with-http_slice_module --with-http_ssl_module
--with-http_stub_status_module --with-http_sub_module
--with-http_v2_module --with-mail --with-mail_ssl_module --with-stream
--with-stream_realip_module --with-stream_ssl_module
--with-stream_ssl_preread_module --with-cc-opt='-g -O2
-fdebug-prefix-map=/data/builder/debuild/nginx-1.19.2/debian/debuild-base/nginx-1.19.2=.
-fstack-protector-strong -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now
-Wl,--as-needed -pie'
Здравствуйте.
Испольузем на больших серверах панель ISPmanager, в качестве веб-сервов
связка nginx+apache(в некоторых случая nginx+php-fpm), столкнулись с такой
ситуация что выполнение команды nginx -t может происходить более чем 5-8
секунд, что напрямую влияет на работу панели и т.д., в ходе анализа
выявленно что для каждого домена панель создает несколько include, и один из
них "подключает" 7-8 стандартных файлов с директории
/etc/nginx/vhosts-includes/ и выходит что при каждом nginx -t проверяеться
конфигурация домена, и каждого из его includ'ов, и в результате из общего
количества открытия файлов во время nginx -t(используя просмотр через
strace) в ~60тис файлов, 30тис обращений являються обращениями к одним и тем
же 8 файлам. То есть по 3,5тис обращений на одини тот же файл.
Вот и возникакет вопрос, ести ли какой то функционал возможно-го кеша, что
бы подключенные через include одни и те же файлы не проверялись при
2,3,4...проверке(т.к. достаточно 1 раз проверить), и если нет(что скорее
всего), стоит ли ожидать какой-то такой реализации в ядре nginx(как по мне
"загнать" файл в кеш, и при последующей его проверка во время выполнения
nginx -t/reload/restart уже не проверять)?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294669,294669#msg-294669
Добрый день.
Подскажите пожалуйста, есть софт, в докере поднятый.
Работает только с location / {
proxy_pass http://127.0.0.1:3333;
...
}
Хочу сделать чтобы открывался location /soft {
proxy_pass http://127.0.0.1:3333;
...
}
Но с последним выдаёт, что не может найти скрипты и прочее.
Я так понимаю он посылает заголовок, который непонятен софту.
Что необходимо сделать, куда копнуть, подскажите пожалуйста.
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294617,294617#msg-294617
Добрый день,
> On 28 Jun 2022, at 09:01, izorkin(a)gmail.com wrote:
>
> Добрый день, Роман.
>
> Я ещё заметил одну ошибку в работе HTTP 3 протокола.
> Через очень долгое время (5-8 часов), браузер начинает отправлять запросы по HTTP 2 протоколу, вместо
> HTTP 3. Собрал debug-лог, но не смог проследить с какого момента прошло переключение. Если понадобится,
> то к вечеру смогу отправить вам логи.
Проблема появилась тогда, когда вы начали реконфигурацию nginx (послали SIGHUP).
При появлении новых воркеров ломается логика распределения квиковых соединений по воркерам.
В итоге, например, новый пакет может прийти в старый воркер, которым он будет проигнорирован.
Все бы могло относительно быстро рассосаться после череды ошибок, если бы у вас не висел один запрос с
проксировнием вебсокетов, который не давал завершиться старому воркеру.
Кроме того, похоже, у вас выключен таймаут на шатдаун воркеров.
Если у вас (свежий) Linux, то проблема с распределением квиковых клиентов по воркерам решается включением bpf-модуля.
Для этого укажите следующую директиву на верхнем уровне конфига:
quic_bpf on;
При этом nginx должен иметь админские права (CAP_SYS_ADMIN) при запуске.
----
Roman Arutyunyan
arut(a)nginx.com