Quantcast
Channel: Nginx Forum - Nginx Mailing List - Russian
Viewing all 3102 articles
Browse latest View live

Не работает proxy_cache_lock (no replies)

$
0
0
Доброго утра!

Я напоролся на проблему с proxy_cache_lock. Ниже минимальный конфиг, на который я шлю порядка 150 простых запросов в секунду. Каждые пять секунд, когда инвализируется кеш, на апстрим уходит от пяти до двадцати запросов, в зависимости от времени ответа апстрима, тогда как я жду, что уйдёт только один запрос, а остальные будут ждать его обработки. Отключени proxy_cache_lock не влияет на проблему никак.


user nginx;
worker_processes 2;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;


events {
worker_connections 1024;
}


http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format main escape=json
'$time_iso8601 $request_id '
'$remote_addr $request_length $host "$request" "$http_referer" "$http_user_agent" '
'$request_time $status $body_bytes_sent';

access_log /var/log/nginx/access.log main;

proxy_cache_path /var/cache/nginx/CACHE levels=1:2 keys_zone=CACHE:16m;

server {
listen 80 default_server;
listen [::]:80 default_server;

proxy_cache CACHE;

proxy_cache_lock on;
proxy_cache_lock_age 10s;
proxy_cache_lock_timeout 20s;

proxy_cache_valid 200 5s;
proxy_ignore_headers X-Accel-Expires Expires Cache-Control Set-Cookie Vary;

proxy_set_header Host HOST;

location / {
proxy_pass https://HOST;
}

}
}


Запускаю вот таким образом:
$ docker run --rm -it -v (pwd)/nginx.conf:/etc/nginx/nginx.conf:ro -p 80:80 nginx:alpine
Пробовал версии, от 1.10 до 1.15.

Re: Не работает proxy cache lock (1 reply)

$
0
0
> On 21 Jun 2018, at 17:43, ZZZ <nginx-forum@forum.nginx.org> wrote:
>
> Доброго утра!
>
> Я напоролся на проблему с proxy_cache_lock. Ниже минимальный конфиг, на
> который я шлю порядка 150 простых запросов в секунду. Каждые пять секунд,
> когда инвализируется кеш, на апстрим уходит от пяти до двадцати запросов, в

http://nginx.org/r/proxy_cache_use_stale/ru

“дополнительный параметр updating разрешает использовать устаревший
закэшированный ответ, если на данный момент он уже обновляется”

--
Sergey Kandaurov

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Не работает proxy cache lock (2 replies)

$
0
0
ZZZ писал 2018-06-21 17:43:
> Доброго утра!

Добрый день!

> Я напоролся на проблему с proxy_cache_lock. Ниже минимальный конфиг, на
> который я шлю порядка 150 простых запросов в секунду. Каждые пять
> секунд,
> когда инвализируется кеш, на апстрим уходит от пяти до двадцати
> запросов, в
> зависимости от времени ответа апстрима,

Вероятно, у вас значения proxy_{connect,send,read}_timeout в 5-20 раз
меньше времени ответа вашего бэкенда. И цикл
- лочим кеш и отправляем запрос на бэкенд
- запрос таймаутится
успевает повториться несколько раз.


Другая версия - срабатывает proxy_cache_lock_age

Посмотрите по логам - эти лишние запросы отправляются на бэкенд
равномерно в течение времени его неответа? или "пачкой" после первого
запроса?


--
Best regards,
Andrey A. Kopeyko <andrey@kopeyko.ru>
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

curl: Empty reply from server nginx/1.12.0 (no replies)

$
0
0
Добрый день!

Используется:
nginx -V
nginx version: nginx/1.12.0
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/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='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie'


Делаю запрос

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' там дальше запрос и URL

В логах вижу запись с 200 кодом

Дальше делаю еще раз запрос
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' там дальше запрос и URL
И получаю ответ curl: (52) Empty reply from server

А в логах nginx пусто!

Изменил error_log путь до лога debug;
Остановил nginx. Запустил nginx-debug.


И все равно пусто.

Что может быть?

Время записи в лог (2 replies)

$
0
0
Добрый день.

Есть такая схема nginx(ubuntu) -> nginx(freebsd) -> БЕ

Есть проблемный запрос, который обрабатывался более 20 секунд

[16/Jun/2018:15:41:15 +0300] "GET /123" request_time=20.483 upstream_response_time=20.483 upstream_addr=10.10.10.10:80" "200" "nginx/1.10.1/289427"

Тот же запрос (это точно) на следующем nginx:
2018-06-16T15:40:54+03:00 "GET /123" request_time=0.031 upstream_response_time=0.031 upstream_addr=unix:/tmp/nginx_news.socket" "200"

Время на всех серверах синхронизировано. Как я понял из того, что удалось нагуглить, то запись в лог происходит только после того, как клиент получил ответ на запрос. Т.е. теоретически время в логе может отличаться только на дельту между upstream_response_time и request_time.

Первый nginx стоковый,из коробки в ubuntu. А вот про второй nginx известно, что он может быть собран с какими-то самописными модулями. Правильно ли я понимаю, что вышеописанная ситуация невозможна, со стандартными nginx, и проблему стоит искать на втором сервере, или я ошибаюсь?

Переменная с именем файла на диске (фича реквест) (2 replies)

$
0
0
Добрый день.

В nginx сейчас нет переменной, которая бы содержала имя файла на диске
для локальных файлов.

$request_filename не подходит, т.к. содержит в себе и GET параметры.

Переменная нужна для фильтрации доступов, например, её было бы хорошо
использовать в map.

Сейчас единственный способ зафильтровать по расширению имени файла это
сделать location, но иногда этот способ сильно не удобен, т.к. вместо

map $real_name $my_access {
"~.js$" 404;
default 0;
}

server {
location /111/ {
if ($my access) {}
}
}

надо делать вложенные локейшены что сильно нагромождает конфиг

--
Рустам
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Аналог функционала IncludeOptional в Apache2 (1 reply)

$
0
0
Приветствуем!

Уточните, пожалуйста, планируется ли к реализации или можно ли запросить
аналог на https://httpd.apache.org/docs/2.4/mod/core.html#includeoptional

Юзкейс простой - есть панель управления сервером, которая генерирует
виртуальные хосты для пользователей вида

server {
server_name DOMAIN.TLD ;

listen IPv4_ADDR:443 ssl http2;
listen [IPv6_ADDR]:443 ssl http2;

ssl_certificate
'/var/www/httpd-cert/DOMAIN.TLD_2018-06-21-18-54-45.crt';
ssl_certificate_key
'/var/www/httpd-cert/DOMAIN.TLD_2018-06-21-18-54-45.key';

gzip on;
gzip_min_length 1024;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/css image/x-ico application/pdf image/jpeg image/png
image/gif application/javascript application/x-javascript
application/x-pointplus;

disable_symlinks if_not_owner from=$root_path;
set $root_path /var/www/USER/data/www/DOMAIN.TLD;
root $root_path;

location / {
proxy_pass http://127.0.0.1:81;
proxy_redirect http://127.0.0.1:81/ /;
include /etc/nginx/proxy_params;
}

location ~*
^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpeg|avi|zip|gz|bz2|rar|swf|ico)$
{
try_files $uri $uri/ @fallback;
expires 30d;
}

location @fallback {
proxy_pass http://127.0.0.1:81;
proxy_redirect http://127.0.0.1:81/ /;
include /etc/nginx/proxy_params;
}

include /etc/nginx/fastpanel2-sites/USER/DOMAIN.TLD.includes;
include /etc/nginx/fastpanel2-includes/*.conf;

error_log /var/www/USER/data/logs/DOMAIN.TLD-frontend.error.log;
access_log /var/www/USER/data/logs/DOMAIN.TLD-frontend.access.log;
}

server {
listen IPv4_ADDR:80;
listen [IPv6_ADDR]:80;
server_name DOMAIN.TLD ;
return 301 https://$host$request_uri;
}

Для некоторых хостов требуются кастомные локейшены, например include
/etc/nginx/fastpanel2-sites/USER/DOMAIN.TLD.includes;

Но эти кастомные локейшены требуются довольно редко, что приводит к тому,
что мы создаем большое количество пустых файлов.

Спасибо!
---
Respectfully, Dmitrii Kovalkov
FASTVPS technical department
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Не работает proxy cache lock (no replies)

$
0
0
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Воркер падает в корку по SIGSEGV (с примером) (no replies)

$
0
0
Всех приветствую!

Есть простой perl-модуль, который работает под nginx без проблем на древних версиях (кажется до 1.7), а на свежих версиях nginx этот модуль приводит к тому, что воркеры начинают падать в корку по SIGSEGV.
Разобрал модуль до мелочей и нашёл, что всё падает на send_http_header().
Вот пример этого модуля:

package post_download;

use nginx;
use strict;

sub handler {
my $r = shift;

$r->send_http_header("text/plain");
$r->print("OK\n");

return OK;
}

Воркеры падают не на каждый такой запрос, а после нескольких таких запросов.

Подключается этот модуль обычным способом:
perl_require /etc/nginx/perl/post_download.pm;

100% баг наблюдается на двух версиях: 1.12.2 и на 1.15.0.

image_filter size (no replies)

$
0
0
Здравствуйте.
Есть модуль https://nginx.ru/ru/docs/http/ngx_http_image_filter_module.html
В нём есть директива image_filter size;
Так вот, извините за глупый вопрос, где посмотреть ответ данной директивы? И возможно его вытащить в переменную?

Задачка простая - уменьшать картинки, с этим проблем нет. С недавних пор понадобилось поворачивать картинки у которых высота меньше ширины.

Запуск php скриптов из разных директории (1 reply)

$
0
0
Здравствуйте,

имеются директории:

/home/admin/ - в этой папке находятся файлы (напр. index.php, conf.php, admin/index.php), которые нужно скрыть от юзера (но запускать он их может).
/home/user/ - в этой папке файлы юзера.

Задача:

ЕСЛИ (запрошенный http адрес соответствует файлу в папке /home/user/)
{
ТО вернуть клиенту этот файл
}
ИНАЧЕ
{
ЕСЛИ (файл /home/user/index.php существует)
{
ТО вызвать скрипт /home/user/index.php для обработки запроса
}
ИНАЧЕ
{
указать root -директорию /home/admin/ и

ЕСЛИ (запрошенный http адрес соответствует файлу в папке /home/admin/)
{
ТО вернуть клиенту этот файл
}
ИНАЧЕ
{
вызвать скрипт /home/admin/index.php для обработки запроса
}
}
}


Т.е. если юзер создает файл, например, /home/user/index.php, то при открытии сайта должен запускаться именно этот файл. Если же этого файла нет, то запускаться должен /home/admin/index.php и тд. При этом в папках кроме php-файлов могут находиться файлы css, картинки и другие.

Подскажите пожалуйста рабочий конфиг для такой задачи.

Пробовал через try_files пока ничего не получается...

unit: будет ли поддержка задания переменных _SERVER ? (1 reply)

$
0
0
Здравствуйте!

Сегодня попробовал unit в продакшене. Немного отзывов, вопросы через абзац.

Переключил на него matomo(piwik), который обслуживает сайт с 300000
посетителей ежедневно. В php-fpm мне давно не нравилось, как он
использует память в static режиме (он её, собственно, сжирает как не в
себя. последняя php  ветки 7.0). Так вот unit оказался прекрасным
продуктом с точки зрения производительности. Потребление памяти теперь
фискированное и упало в разы. Завтра буду пробовать переводить ядро
самого сайта.

Вопрос:ы

В nginx при работе с php-fpm по fastcgi, можно было подделать любой
заголовок, чаще всего это делалось с https. Сегодня мне очень не хватало
GEOIP_* заголовков. Если заголовки проксировать, то на бэкэнд они
приезжают с префиксом HTTP_, и бэкэнд их не видит. Планируется ли как-то
решить этот вопрос? Переменные окружения - это не то, это другой массив.

Планируется ли поддержка юникс-сокетов в listener'ах?

Статистика? Хотя бы аналогичная nginx_stats.

Ну и вы, наверное, в курсе, но у вас документация отстаёт от
действительности. Не описаны нововведения из unit 1.2.

В остальном - спасибо за прекрасный продукт!

С уважением, Иван.

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

unit: 400 ошибка при заголовках, содержащих юникод (1 reply)

$
0
0
Здравствуйте!

Только я научил бэкэнд получать геоданные из HTTP_* заголовков, так
столкнулся со следующей проблемой.

Если в заголовке содержаться какие-то юникодные символы, например,
кириллица *или *'ü' , то unit возвращает 400 ошибку.

Это баг unit или заголовки по стандарту не умеют юникод?

Если баг, готов его оформить на гитхабе.

Если не баг и так задумано, то я совсем не понимаю как передавать geoip
данные от nginx (использую geoip2 модуль) к бэкэнду за unit. Если у меня
клиент из немецкого Baden-Württemberg Region или французского
Île-de-France, unit на каждый запрос вернет ему 400.

С уважением, Иван.

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

nginx-1.15.1 (no replies)

$
0
0
Изменения в nginx 1.15.1 03.07.2018

*) Добавление: директива random в блоке upstream.

*) Добавление: улучшена производительность при использовании директив
hash и ip_hash совместно с директивой zone.

*) Добавление: параметр reuseport директивы listen теперь использует
SO_REUSEPORT_LB на FreeBSD 12.

*) Исправление: HTTP/2 server push не работал, если SSL терминировался
прокси-сервером перед nginx'ом.

*) Исправление: директива tcp_nopush всегда использовалась для
соединений к бэкендам.

*) Исправление: при отправке сохранённого на диск тела запроса на
gRPC-бэкенд могли возникать ошибки.


--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

"worker_connections are not enough" - обсудим ? (2 replies)

$
0
0
привет!

налетели на ситуацию. сценарий, как воспроизвести на стенде

1. centos 7, nginx-1.15.1 из официального репозитория
2. конфиг

# cat /etc/nginx/nginx.conf

user root;
worker_processes auto;

events {
worker_connections 512;
}

stream {
include /etc/nginx/conf.d/*.conf;
}

т.е. видим (дефолтное ограничение в "worker_connections 512;")
далее при помощи вот такого генератора

# cat generator.sh
#!/bin/bash

i=2000
while [ $i -le 2700 ]
do
((i++))

cat <<EOF >> /etc/nginx/conf.d/stream.conf
server {
listen 127.0.0.1:${i};
proxy_pass 127.0.0.2:${i};
}
EOF

done

генерируем 700 стримов.

проверяем, nginx говорит, что ему конфиг ок

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
#

перезапускаем, все тоже ок

# systemctl restart nginx
#


но в процессах только мастер, воркера нет.
смотрим лог:

# cat /var/log/nginx/error.log | tail -2
2018/07/05 14:27:53 [alert] 1546#1546: 512 worker_connections are not enough
2018/07/05 14:27:53 [alert] 1545#1545: worker process 1546 exited with
fatal code 2 and cannot be respawned
#


кажется, что было бы логично отсекать такие ошибки во время "nginx -t"
что думаете ?


Илья Шипицин
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Почему статические файлы (20Кб) в локальной сети(1Gbit/s) отдаются 1,5 секунды? (7 replies)

$
0
0
Добрый день!

Имеем очень медленную отдачу закэшированной статики. Посоветуйте пожалуйста как можно ускорить работу.

Статика, скажем, размером 20kb отдаётся порядка 1-1.5 секунды. При чём TTFB относительно быстрый - 200-300 ms, а доставка от nginx до браузера уже 1-1.5 секунды. По логам видно, что эта статика берётся из кэша всё-таки ($upstream_response_time = 0).
Условия проверки: обращение к титульной странице нашего сайта - это 80 запросов, 2.7Mb трафика суммарно, по https, http2.
Конфиг вроде бы стандартный, без особого тюнинга (приложен)
Если скачивать один только статический файл (1 запрос) - то он скачивается без этих задержек - 27 ms.

Топология:
nginx-сервер в нашей конфигурации является проскирующим и кэширующим сервером:
кэширует статику с сервера приложений, к-ый расположен в этой же локальной сети.

Ошибок на сетевых интерфейсах клиента и сервера нет. Каналы не перегружены. (Пропускная способность 1Гбит/с), И в момент обращения к nginx - загрузка максимум 5Mbit/s). В лимиты ЦПУ/память/ дисковый I/O /сеть не упираемся судя по vmstat, top, atop, zabbix. Хотя очевидно есть какое-то ограничение, про к-ое мне пока неизвестно.
8 ядер, 8Gb RAM, Load average 0.00, 0.00, 0.00

В error логах пусто, строки о nginx: [warn] the "ssl" directive is deprecated, use the "listen ... ssl" directive instead in /etc/nginx/conf.d/ не считаю важными.

Также я пробовал размещать proxy_cache_path на tmpfs (в ОЗУ) - не дало никакого прироста.

nginx последний stable, из оффициального репозитория nginx.org

Я проверял в разных сетях (с разным коммутационным оборудованием), на разных физических серверах, на разных дистрибутивах Linux.


_____________________________________________________________

Версии ПО и конфиги :
root@proxy4:~# uname -a
Linux proxy4 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
nginx 1.14.0-0ubuntu1
дефолтовые настройки sysctl
root@proxy4:~# lsb_release -a
Description: Ubuntu 18.04 LTS
root@proxy4:~# nginx -V
nginx version: nginx/1.14.0
built by gcc 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
built with OpenSSL 1.1.0g 2 Nov 2017
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.14.0/debian/debuild-base/nginx-1.14.0=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'


/etc/nginx/nginx.conf

user www-data;
worker_processes 8;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 4000;
}
worker_rlimit_nofile 200000;
http {
client_max_body_size 10m;
charset utf-8;
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=all:512m;
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" $upstream_response_time';
access_log /var/log/nginx/access.log main buffer=16k;
server_tokens off;
client_body_buffer_size 128k;
keepalive_requests 1000;
sendfile on;
sendfile_max_chunk 512k;
proxy_buffering on;
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
keepalive_timeout 65;
include /etc/nginx/conf.d/*.conf;
}


/etc/nginx/conf.d/beta.domain.ru.conf

proxy_cache_path /tmp/nginx_CACHE_ZONE keys_zone=CACHE:2048M;
proxy_temp_path /tmp/nginx_temp;
upstream backend {
server 195.209.xx:80;
}
upstream backend_old {
server 195.209.xx:8098;
}
server {
listen 443 ssl http2;
server_name www.domain.ru;
access_log /var/log/nginx/www.domain.ru.access.log main buffer=16k;
error_log /var/log/nginx/www.domain.ru.error.log;
client_max_body_size 20m;
keepalive_timeout 60;
gzip on;
gzip_proxied any;
gzip_types *;
gzip_vary on;
ssl on;
ssl_certificate /etc/dehydrated/certs/domain.ru/fullchain.pem;
ssl_certificate_key /etc/dehydrated/certs/domain.ru/privkey.pem;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/crt/dhparam.pem;
charset utf-8;
proxy_send_timeout 300;
proxy_read_timeout 300;
location = / {
proxy_cache_valid 200 301 302 304 5m;
proxy_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri";
proxy_hide_header "Set-Cookie";
proxy_ignore_headers "Cache-Control" "Expires";
proxy_cache_use_stale error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_cache CACHE;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;
}
location ~* ^(/static/|/buildpack/|/assets/|/devadm/|/desktop/|/bitrix/|/jsframework/|/templates/|/upload/|/tmp/).+\.(jpg|jpeg|gif|png|ico|css|css.*|js|js.*|swf|txt|ico|svg|woff2)$ {
expires 1h;
add_header Cache-Control public;
proxy_hide_header "Set-Cookie";
proxy_pass http://backend;
proxy_cache CACHE;
proxy_cache_valid 1h;
}
location / {
proxy_set_header Accept-Encoding "";
sub_filter 'http://' 'https://';
sub_filter_once off;

proxy_redirect off;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend_old;
}
}

root@proxy4:~# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 7716604 25012 264788 0 0 4 2 54 36 0 0 100 0 0
0 0 0 7716632 25012 264788 0 0 0 0 418 286 0 0 100 0 0
0 0 0 7716664 25020 264784 0 0 0 28 408 285 0 0 100 0 0
0 0 0 7716728 25020 264788 0 0 0 0 434 300 0 0 100 0 0
0 0 0 7716600 25020 264788 0 0 0 0 411 290 0 0 100 0 0
0 0 0 7716604 25020 264804 0 0 0 28 615 305 1 0 99 0 0
0 0 0 7716604 25020 264804 0 0 0 0 582 283 0 0 99 0 0
0 0 0 7716508 25020 264804 0 0 0 0 396 256 0 0 100 0 0

проблемы rewrite + secure link, экранизация символа ? (вопроса) (no replies)

$
0
0
Здравствуйте форумчане, целый день провозился с проблемой, помогите пожалуйста, буду признателен!
nginx version: nginx/1.14.0

стоит реврайт:
rewrite ^/sec/(.*)/(\d+)/((film|serial)/(.*))$ /stream/$3?md5=$1&expires=$2 last;

и есть этот локейшен:

location /stream {
secure_link $arg_md5,$arg_expires;
secure_link_md5 "$secure_link_expires$uri$remote_addr secret";

if ($secure_link = "") {
return 200 "$query_string $arg_md5 $uri $secure_link_expires $uri $remote_addr secret";
}

if ($secure_link = "0") {
return 410;
}

rewrite ^/stream/(.*)$ /content/vod/$1 break;
}

и запросы не приходят в локейшен /stream (Почему? я пологаю что не передаются hash и expires, но даже без них должен обрабатываться запрос?), стоит только добавить в регулярное вырожение экранирование \? (rewrite ^/sec/(.*)/(\d+)/((film|serial)/(.*))$ /stream/$3\?md5=$1&expires=$2 last;) - так все работает. НО! в переменную $3 добавляется этот слэш - "\", и расшифровка не происходит.. Что делать?

Интересно что даже без ЧПУ ссылок, ввида:

/stream/film/rampage.2018.720p/hls/720/index.m3u8?md5=sC-pYJ0gHU5PjJDi-18BOQ&expires=1530842792
запрос не работает тоже, в локейшен не попадает, добавляю \ перед ? (вопросов) и все опять работает!!!

Надеюсь на вашу помощь. На другом сервере, на старой версии подобные реврайты работают.

Релиз Unit 1.3 (no replies)

$
0
0
Здравствуйте.

Рад сообщить о выпуске новой версии NGINX Unit.

Изменения в Unit 1.3 13.07.2018

*) Изменение: в значениях полей заголовка запроса разрешены символы UTF-8.

*) Добавление: настройка ограничения на размер тела запроса.

*) Добавление: настройка различных таймаутов HTTP соединения.

*) Добавление: теперь модуль Ruby автоматически использует Bundler, если
тот доступен.

*) Добавление: интерфейс http.Flusher в модуле Go.

*) Исправление: различные проблемы при обработке ошибок в HTTP соединении.

*) Исправление: запросы с телом могли некорректно обрабатываться в
модуле PHP.

*) Исправление: отдельные опций конфигурации PHP, установленные через API,
сбрасывались после обработки первого запроса в процессе приложения.


Пример конфигурации с новыми параметрами:

{
"settings": {
"http": {
"header_read_timeout": 30,
"body_read_timeout": 30,
"send_timeout": 30,
"idle_timeout": 180,
"max_body_size": 8388608
}
},

"listeners": {
"127.0.0.1:8034": {
"application": "mercurial"
}
},

"applications": {
"mercurial": {
"type": "python 2",
"module": "hgweb",
"path": "/data/hg"
}
}
}


Все таймауты указываются в секундах.
Значение "max_body_size" задается в байтах.

Обратите внимание, что в данном примере параметры объекта "http" установлены
в свои значения по умолчанию. Если данные значения вас устраивают, то нет
необходимости задавать их явно.

Пакеты для дистрибутивов Linux, а также Docker-образы доступны по ссылкам:

- Пакеты: https://unit.nginx.org/installation/#precompiled-packages
- Docker: https://hub.docker.com/r/nginx/unit/tags/

Также следите за статьями в нашем блоге, где подробнее рассказывается о новых
возможностях в свежих версиях Unit'a:

- https://www.nginx.com/blog/tag/nginx-unit/

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

ngx_ssl_certificates вызывается даже для сайтов без ssl (no replies)

$
0
0
Имеется конфигурация с ~500-600 сайтов, из них примерно 10% с поддержкой https, в остальных только http.
wildcard-ключ с сертификатом указан в блоке "http".

Обратил внимание, что "nginx -t" и "nginx -s reload" стали отрабатывать секунд по 10.

Профайлер говорит, что 90% времени уходит на ngx_http_ssl_merge_srv_conf => ngx_ssl_certificates,
количество вызовов у них одинаковое.

Переместил сертификат в блоки "server", где используется ssl - nginx стал читать конфигурацию в несколько раз быстрее.

Какой смысл проверять сертификаты для серверов без https?
Можно ли отключить такую проверку?

Re: ngx ssl certificates вызывается даже для сайтов без ssl (no replies)

$
0
0
Hello!

On Sat, Jul 14, 2018 at 11:20:59PM -0400, Ilya Evseev wrote:

> Имеется конфигурация с ~500-600 сайтов, из них примерно 10% с поддержкой
> https, в остальных только http.
> wildcard-ключ с сертификатом указан в блоке "http".
>
> Обратил внимание, что "nginx -t" и "nginx -s reload" стали отрабатывать
> секунд по 10.
>
> Профайлер говорит, что 90% времени уходит на ngx_http_ssl_merge_srv_conf =>
> ngx_ssl_certificates,
> количество вызовов у них одинаковое.
>
> Переместил сертификат в блоки "server", где используется ssl - nginx стал
> читать конфигурацию в несколько раз быстрее.
>
> Какой смысл проверять сертификаты для серверов без https?
> Можно ли отключить такую проверку?

В силу исторических причин на уровне server{} в момент merge'а
конфигурации неизвестно, может ли в него попасть HTTPS-соединение,
или нет. Скажем, вот в такой конфигурации HTTPS-соединение может
попасть и в сервер foo, и в сервер bar, но nginx об этом знает
только в сервере foo:

server {
listen 443;
server_name foo;
ssl on;
}

server {
listen 443;
server_name bar;
}

Соответственно признаком для того, что нужно создавать
SSL-контекст и загружать сертификаты служит собственно наличие
сертфикатов. Если SSL-сертификат в данном сервере задан (или
унаследован с уровня http) - то SSL-контекст создаётся. Если не
задан - не создаётся.

Начиная с 1.15.0 nginx ругается на наличие директивы "ssl", и
предлагает вместо неё использовать "listen ... ssl". Когда мы её
окончательно запретим - возможно, дойдут руки и до оптимизации
создания SSL-контекстов, благо при использовании "listen ... ssl"
это получается сделать несколько проще.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Viewing all 3102 articles
Browse latest View live