From nginx-forum на nginx.us Sun Nov 1 18:41:07 2015 From: nginx-forum на nginx.us (hans777) Date: Sun, 01 Nov 2015 13:41:07 -0500 Subject: =?UTF-8?B?0LrQvtC90YLRgNC+0LvRjCDRhNCw0LnQu9C+0LI=?= Message-ID: <252e8f1ea92b8966fe93f20491956b68.NginxMailingListRussian@forum.nginx.org> ngnix установлен в качестве прокси апач2 бэкенд задача контролировать файлы . файлы для контроля находятся в директории /var/www/html/files/[0-9]+/[a-Z]+/ user www-data; # Юзер от которого работает nginx worker_processes 4; # Эта цифра должна соответствовать числу ядер у процессора pid /var/run/nginx.pid; user www-data; # Юзер от которого работает nginx worker_processes 4; # Эта цифра должна соответствовать числу ядер у процессора pid /var/run/nginx.pid; events { worker_connections 768; # multi_accept on; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; server_tokens off; # server_names_hash_bucket_size 64; # server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; gzip_min_length 1100; gzip_proxied any; gzip_comp_level 4; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; #include /etc/nginx/naxsi_core.rules; #passenger_root /usr; #passenger_ruby /usr/bin/ruby; #include /etc/nginx/conf.d/*.conf; # если папка conf.d пустая, то можно закомментировать #include /etc/nginx/sites-enabled/*; # Отключаем дефолтный файл, так как все настройки находятся тут server { listen 80; server_name serv.com serv.com; # Название Вашего сайта root /var/www/html/; # пака сервера (вдруг у Вас другая) index index.html index.php; #### xrennaideshmyphpmyadmin - это ваш секретный путь к phpMyadmin, таким образом всё #### что касается phpMyadmin, будет отдавать Apache и страница будет корректно отображаться. #### Картинки и прочее отдаёт Nginx location ~* ^(?!/xrennaideshmyphpmyadmin/).+\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bmp|rtf|swf|ico|flv|txt|xml|docx|xlsx)$ { access_log off; expires 30d; } location ~ /\.ht { deny all; } location / { proxy_pass http://127.0.0.1:8080/; # Порт на котором висит Apache proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-for $remote_addr; proxy_set_header Host $host; proxy_connect_timeout 60; proxy_send_timeout 90; proxy_read_timeout 90; proxy_redirect off; proxy_set_header Connection close; proxy_pass_header Content-Type; proxy_pass_header Content-Disposition; proxy_pass_header Content-Length;} location ~ ^/files/[0-9]+/[A-z]+/.*$ { root /var/www/html/; internal; # Здесь я заблокировал доступ<-- } }} Но после блокировки если на сайте к примеру появляется код то картинка отображается, так же с видео и музыкой Вопрос : Как мне получить контроль над файлами и желательно контролировать с помощью скрипта в php при помощи сессии, что бы недобросовестный пользователь не смог воспользоваться контентом через html теги к примеру? Может ли ngnix помочь? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262556,262556#msg-262556 From nginx-forum на nginx.us Wed Nov 4 10:11:31 2015 From: nginx-forum на nginx.us (znak-ognya) Date: Wed, 04 Nov 2015 05:11:31 -0500 Subject: =?UTF-8?B?0J/RgNC4INC/0L7Qv9GL0YLQutC1INC+0YLQutGA0YvRgtGMINC70L7QutCw0Ls=?= =?UTF-8?B?0YzQvdGL0Lkg0YHQsNC50YIg0LLRgdGRINCy0YDQtdC80Y8g0L7RgtC60YA=?= =?UTF-8?B?0YvQstCw0LXRgtGB0Y8gL3Zhci93d3c=?= Message-ID: Здравствуйте, Причина: Стоял Апач и два локальных сайта для тренировок, решил обновить дистрибутив, заодно установился NGINX, попробовал его настроить как прокси, перечитал кучу разных инструкций, nginx ошибок не показывает, phpmyadmin открывается через (localhost:порт), сайты стоят в /home/user/sites/test/www (и второй там же sites/.../www), пользователь добавлен в группу www-data, права есть, пути для прокси nginx указаны в (ссылках) sites-enabled, папки сайтов реально называются одним словом без всяких расширений (для удобства)... Строки с указанием разных images комментировал, чтобы просто увидеть сайты, ничего не получается... Ставил минимальные настройки прокси с этого сайта, тоже ничего не открывается... Вопрос: Почему при попытке открыть сайт test открывается папка /var/www с родным файлом [TXT] index.nginx-debian.html ??? Почему игнорируются прописанные реальные пути сайтов?.. Спасибо... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262595,262595#msg-262595 From alex.hha на gmail.com Wed Nov 4 10:45:44 2015 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 4 Nov 2015 12:45:44 +0200 Subject: =?UTF-8?B?0JDQvdCw0LvQvtCzIFByb3h5UGFzc1JldmVyc2U=?= Message-ID: Столкнулся с проблемой необходимости перевести apache на nginx. На данный момент в apache в настройках виртуалхоста есть директивы ProxyPassReverse / http://javaclr.example.net/ ProxyPassReverse / http://imagesclr.example.net/ ProxyPassReverse / http://aspclr.example.net/ ProxyPassReverse / http://vsclr.example.net/ В офф документации nginx - https://www.nginx.com/resources/wiki/start/topics/examples/likeapache/ говорится, что достаточно использовать proxy_pass и передавать соотв хедеры. Но тут возникает вопрос, а как мне в одном location использовать несколько директив proxy_pass. Или единственный выход использовать map, что то вида map $host $proxy_host { default ""; "~(javaclr|imagesclr|aspclr|vsclr)\.example\.net" "$host"; } server { listen 80; server_name javaclr.example.net imagesclr.example.net aspclr.example.net vsclr.example.net; location / { proxy_pass http://$proxy_host; 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; } } ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From igor на sysoev.ru Wed Nov 4 11:46:29 2015 From: igor на sysoev.ru (Igor Sysoev) Date: Wed, 4 Nov 2015 14:46:29 +0300 Subject: =?UTF-8?B?UmU6INCQ0L3QsNC70L7QsyBQcm94eVBhc3NSZXZlcnNl?= In-Reply-To: References: Message-ID: On 04 Nov 2015, at 13:45, Alex Domoradov wrote: > Столкнулся с проблемой необходимости перевести apache на nginx. На данный момент в apache в настройках виртуалхоста есть директивы > > ProxyPassReverse / http://javaclr.example.net/ > ProxyPassReverse / http://imagesclr.example.net/ > ProxyPassReverse / http://aspclr.example.net/ > ProxyPassReverse / http://vsclr.example.net/ > > В офф документации nginx - https://www.nginx.com/resources/wiki/start/topics/examples/likeapache/ говорится, что достаточно использовать proxy_pass и передавать соотв хедеры. > > Но тут возникает вопрос, а как мне в одном location использовать несколько директив proxy_pass. Или единственный выход использовать map, что то вида > > map $host $proxy_host { > default ""; > "~(javaclr|imagesclr|aspclr|vsclr)\.example\.net" "$host"; > } > > server { > listen 80; > server_name javaclr.example.net imagesclr.example.net aspclr.example.net vsclr.example.net; > > location / { > proxy_pass http://$proxy_host; > 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; > } > } > Аналог ProxyPassReverse - proxy_redirect: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_redirect Но, возможно, правильнее не валить всё в одну кучу, а сделать несколько серверов. -- Igor Sysoev http://nginx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на nginx.us Wed Nov 4 12:12:08 2015 From: nginx-forum на nginx.us (skeletor) Date: Wed, 04 Nov 2015 07:12:08 -0500 Subject: =?UTF-8?B?c2V0IHByb3h5IHN0b3JlINC90LDQu9C10YLRgw==?= Message-ID: <386d542bb6d8c57b4979685bf8e21edf.NginxMailingListRussian@forum.nginx.org> Всем привет. Есть локейшин, внутри которого есть условие if (...) { set $proxy_store_root ''; set $proxy_store off; } но по факту всё равно файлы сохраняются на диск (смотрю через dtrace). Глобально выключить в локейшине не могу. Нужно именно менять значение переменной, если срабатывает условие if. Такое впечатление, что менять proxy_store налету нельзя. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262598,262598#msg-262598 From semenukha на gmail.com Wed Nov 4 18:18:23 2015 From: semenukha на gmail.com (Styopa Semenukha) Date: Wed, 04 Nov 2015 13:18:23 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQuCDQv9C+0L/Ri9GC0LrQtSDQvtGC0LrRgNGL0YLRjCDQu9C+0Lo=?= =?UTF-8?B?0LDQu9GM0L3Ri9C5INGB0LDQudGCINCy0YHRkSDQstGA0LXQvNGPINC+0YI=?= =?UTF-8?B?0LrRgNGL0LLQsNC10YLRgdGPIC92YXIvd3d3?= In-Reply-To: References: Message-ID: <5616158.Yzcz2adtX0@hydra> Добрый день! Если приведете ваш конфиг и вывод, например, команды curl, вам смогут помочь намного быстрее. Пока что информации для ответа явно недостаточно. On Wednesday, November 04, 2015 05:11:31 AM znak-ognya wrote: > Здравствуйте, > > Причина: Стоял Апач и два локальных сайта для тренировок, решил обновить > дистрибутив, заодно установился NGINX, попробовал его настроить как прокси, > перечитал кучу разных инструкций, nginx ошибок не показывает, phpmyadmin > открывается через (localhost:порт), сайты стоят в /home/user/sites/test/www > (и второй там же sites/.../www), пользователь добавлен в группу www-data, > права есть, пути для прокси nginx указаны в (ссылках) sites-enabled, папки > сайтов реально называются одним словом без всяких расширений (для > удобства)... Строки с указанием разных images комментировал, чтобы просто > увидеть сайты, ничего не получается... Ставил минимальные настройки прокси с > этого сайта, тоже ничего не открывается... > > Вопрос: Почему при попытке открыть сайт test открывается папка /var/www с > родным файлом [TXT] index.nginx-debian.html ??? Почему игнорируются > прописанные реальные пути сайтов?.. > > Спасибо... > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262595,262595#msg-262595 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Sincerely yours, Styopa Semenukha. From alex.hha на gmail.com Wed Nov 4 19:13:34 2015 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 4 Nov 2015 21:13:34 +0200 Subject: =?UTF-8?B?UmU6INCQ0L3QsNC70L7QsyBQcm94eVBhc3NSZXZlcnNl?= In-Reply-To: References: Message-ID: т.е. надо делать как то так? server { listen 80; server_name www.example.net ; location ~ \.jsp$ { proxy_pass http://javaclr.example.net:8080; 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_redirect http://javaclr.example.net:8080/ /; } location ~ \.asp$ { proxy_pass http://aspclr.example.net :8080; 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_redirect http://aspclr.example.net :8080/ /; } location ~ \.(png|jpg|js|css)$ { proxy_pass http://s3aws.example.net ; 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_redirect http://s3aws.example.net / /; } } Из того что я понял apache лишь выполняет роль обычного reverse proxy, просто вся логика у него реализована через .htaccess. например там есть такие строки RewriteRule (.*)\.(jsp|do)$ http://javaclr.example.net/$1.$2 [QSA,P] RewriteRule (.*)\.asp$ http://aspclr.example.net/$1.asp [P] RewriteRule ^(applet) http://javaclr.example.net/$1 [P] RewriteRule (.*)\.(jpg|gif|png|js|css|html|zip|jar|xml|class|pdf|swf|mp4|ico)$ http://images.example.net.s3-website-us-west-2.amazonaws.com/$1.$2 [NC,P] ну и т.д. 2015-11-04 13:46 GMT+02:00 Igor Sysoev : > On 04 Nov 2015, at 13:45, Alex Domoradov wrote: > > Столкнулся с проблемой необходимости перевести apache на nginx. На данный > момент в apache в настройках виртуалхоста есть директивы > > ProxyPassReverse / http://javaclr.example.net/ > ProxyPassReverse / http://imagesclr.example.net/ > ProxyPassReverse / http://aspclr.example.net/ > ProxyPassReverse / http://vsclr.example.net/ > > В офф документации nginx - > https://www.nginx.com/resources/wiki/start/topics/examples/likeapache/ > говорится, что достаточно использовать proxy_pass и передавать соотв хедеры. > > Но тут возникает вопрос, а как мне в одном location использовать несколько > директив proxy_pass. Или единственный выход использовать map, что то вида > > map $host $proxy_host { > default ""; > "~(javaclr|imagesclr|aspclr|vsclr)\.example\.net" "$host"; > } > > server { > listen 80; > server_name javaclr.example.net imagesclr.example.net > aspclr.example.net vsclr.example.net; > > location / { > proxy_pass http://$proxy_host; > 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; > } > } > > > Аналог ProxyPassReverse - proxy_redirect: > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_redirect > Но, возможно, правильнее не валить всё в одну кучу, а сделать несколько > серверов. > > > -- > Igor Sysoev > http://nginx.com > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Thu Nov 5 11:37:23 2015 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 05 Nov 2015 14:37:23 +0300 Subject: =?UTF-8?B?UmU6IHNldCBwcm94eSBzdG9yZSDQvdCw0LvQtdGC0YM=?= In-Reply-To: <386d542bb6d8c57b4979685bf8e21edf.NginxMailingListRussian@forum.nginx.org> References: <386d542bb6d8c57b4979685bf8e21edf.NginxMailingListRussian@forum.nginx.org> Message-ID: <38074678.ftHEIZprjl@vbart-workstation> On Wednesday 04 November 2015 07:12:08 skeletor wrote: > Всем привет. > Есть локейшин, внутри которого есть условие > > if (...) { > set $proxy_store_root ''; > set $proxy_store off; > } > > но по факту всё равно файлы сохраняются на диск (смотрю через dtrace). > Глобально выключить в локейшине не могу. Нужно именно менять значение > переменной, если срабатывает условие if. Такое впечатление, что менять > proxy_store налету нельзя. > С помощью set вы задали две переменные. Вы после этого их где-то используете? -- Валентин Бартенев From jd на jdwuzhere.ru Thu Nov 5 22:22:02 2015 From: jd на jdwuzhere.ru (Vladimir Sopot) Date: Fri, 6 Nov 2015 01:22:02 +0300 Subject: Task already active error Message-ID: <5336E2C2-0D27-486E-BECE-22CFC1984064@jdwuzhere.ru> Привет! С чем могут быть связаны ошибки? 2015/11/06 00:46:18 [alert] 24396#24396: task #12042 already active 2015/11/06 00:46:20 [alert] 24391#24391: task #22904 already active 2015/11/06 00:46:23 [alert] 24396#24396: task #12239 already active 2015/11/06 00:46:57 [alert] 24396#24396: task #14705 already active Железка раздаёт немного статики, иногда ходя к соседям с proxy_store. # ../sbin/nginx -V nginx version: nginx/1.9.6 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) configure arguments: --without-mail_pop3_module --without-mail_smtp_module --without-http_autoindex_module --without-http_userid_module --with-file-aio --without-http_scgi_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_uwsgi_module --without-http_memcached_module --with-threads # uname -a Linux host7 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Спасибо From nginx-forum на nginx.us Fri Nov 6 07:57:30 2015 From: nginx-forum на nginx.us (skeletor) Date: Fri, 06 Nov 2015 02:57:30 -0500 Subject: =?UTF-8?B?UmU6IHNldCBwcm94eSBzdG9yZSDQvdCw0LvQtdGC0YM=?= In-Reply-To: <38074678.ftHEIZprjl@vbart-workstation> References: <38074678.ftHEIZprjl@vbart-workstation> Message-ID: <1cdd28d40cedc7ea1e15efbba2455349.NginxMailingListRussian@forum.nginx.org> Понял ошибку. Я почему-то подумал, что это встроенные переменные самого nginx'a Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262613,262630#msg-262630 From vbart на nginx.com Fri Nov 6 12:02:14 2015 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 06 Nov 2015 15:02:14 +0300 Subject: =?UTF-8?B?UmU6IHNldCBwcm94eSBzdG9yZSDQvdCw0LvQtdGC0YM=?= In-Reply-To: <1cdd28d40cedc7ea1e15efbba2455349.NginxMailingListRussian@forum.nginx.org> References: <38074678.ftHEIZprjl@vbart-workstation> <1cdd28d40cedc7ea1e15efbba2455349.NginxMailingListRussian@forum.nginx.org> Message-ID: <1717284.cPi2oXYSK2@vbart-workstation> On Friday 06 November 2015 02:57:30 skeletor wrote: > Понял ошибку. Я почему-то подумал, что это встроенные переменные самого > nginx'a > Полный список встроенных переменных можно увидеть тут: http://nginx.org/ru/docs/varindex.html и на самом деле большинство из них нельзя переопределять за редкими исключениями, который обычно описаны явно. -- Валентин Бартенев From nginx-forum на nginx.us Fri Nov 6 13:02:17 2015 From: nginx-forum на nginx.us (skeletor) Date: Fri, 06 Nov 2015 08:02:17 -0500 Subject: =?UTF-8?B?UmU6IHNldCBwcm94eSBzdG9yZSDQvdCw0LvQtdGC0YM=?= In-Reply-To: <1717284.cPi2oXYSK2@vbart-workstation> References: <1717284.cPi2oXYSK2@vbart-workstation> Message-ID: <571a480641cb5591fbd9e094bdaa95ed.NginxMailingListRussian@forum.nginx.org> Спасибо, буду знать. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262613,262633#msg-262633 From vbart на nginx.com Fri Nov 6 14:06:01 2015 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 06 Nov 2015 17:06:01 +0300 Subject: Task already active error In-Reply-To: <5336E2C2-0D27-486E-BECE-22CFC1984064@jdwuzhere.ru> References: <5336E2C2-0D27-486E-BECE-22CFC1984064@jdwuzhere.ru> Message-ID: <2414417.lcuKvg4yta@vbart-workstation> On Friday 06 November 2015 01:22:02 Vladimir Sopot wrote: > Привет! > > С чем могут быть связаны ошибки? > > 2015/11/06 00:46:18 [alert] 24396#24396: task #12042 already active > 2015/11/06 00:46:20 [alert] 24391#24391: task #22904 already active > 2015/11/06 00:46:23 [alert] 24396#24396: task #12239 already active > 2015/11/06 00:46:57 [alert] 24396#24396: task #14705 already active > > Железка раздаёт немного статики, иногда ходя к соседям с proxy_store. > > # ../sbin/nginx -V > nginx version: nginx/1.9.6 > built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) > configure arguments: --without-mail_pop3_module --without-mail_smtp_module --without-http_autoindex_module --without-http_userid_module --with-file-aio --without-http_scgi_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_uwsgi_module --without-http_memcached_module --with-threads > > # uname -a > Linux host7 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > Спасибо Большинство ошибок уровня alert указывают на проблемы в самом nginx, чаще всего возникающими от использования сторонних модулей и патчей. Было бы интересно увидеть конфиг. -- Валентин Бартенев From nginx-forum на nginx.us Mon Nov 9 09:45:00 2015 From: nginx-forum на nginx.us (shureg) Date: Mon, 09 Nov 2015 04:45:00 -0500 Subject: =?UTF-8?B?0JrQsNC6INGB0L7Qt9C00LDRgtGMINC/0L7QtCDQtNC+0LzQtdC9Pw==?= Message-ID: <6d3afe60c67d1ffba7f056f79d54f7c5.NginxMailingListRussian@forum.nginx.org> Ситуация такова, поднят Nginx без апача Основной домен работает, нужно добавить под домен, попробовал создать файл в sites-enabled , скопировал конфиг с основного домена и заменил в нем все на под домен :) не работает :( можно по полочкам объяснить или дать ссылки, на то как создать под домен.... Нужно ли проводить манипуляции с основным доменом или достаточно настроить конфиги для nginx панели управления сайтом нету, только ssh Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262655,262655#msg-262655 From alex.hha на gmail.com Mon Nov 9 10:07:14 2015 From: alex.hha на gmail.com (Alex Domoradov) Date: Mon, 9 Nov 2015 12:07:14 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: <6d3afe60c67d1ffba7f056f79d54f7c5.NginxMailingListRussian@forum.nginx.org> References: <6d3afe60c67d1ffba7f056f79d54f7c5.NginxMailingListRussian@forum.nginx.org> Message-ID: > можно по полочкам объяснить или дать ссылки, на то как создать под домен.... Куда уж проще server { server_name example.net; root /vhosts/example.net; ... } server { server_name subdomain1.example.net; root /vhosts/subdomain1.example.net; ... } P.S. reload/restart делали? 2015-11-09 11:45 GMT+02:00 shureg : > Ситуация такова, поднят Nginx без апача > > Основной домен работает, нужно добавить под домен, попробовал создать файл > в > sites-enabled , скопировал конфиг с основного домена и заменил в нем все на > под домен :) не работает :( > > можно по полочкам объяснить или дать ссылки, на то как создать под > домен.... > Нужно ли проводить манипуляции с основным доменом или достаточно настроить > конфиги для nginx > панели управления сайтом нету, только ssh > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,262655,262655#msg-262655 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxout.mail на gmail.com Mon Nov 9 10:38:36 2015 From: maxout.mail на gmail.com (=?UTF-8?B?0JzQsNC60YHQuNC8?=) Date: Mon, 9 Nov 2015 16:38:36 +0600 Subject: =?UTF-8?B?VW5kZWZpbmVkINC/0LXRgNC10LzQtdC90L3QsNGPINC/0YDQuCDQu9C+0LPQuNGA?= =?UTF-8?B?0L7QstCw0L3QuNC4?= Message-ID: Есть вот такой вот набор (в реальности всё разумеется сложнее, но свелось к этому компактному конфигу): error_log /bla/error.log warn; http { uninitialized_variable_warn on; log_format combinedvhost '$host_short $remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; access_log /bla/access_log combinedvhost; server { set $host_short "MYSTRING"; listen blah:80; server_name all; ..... } Всё логируется замечательно, но иногда приходит некий (некорректный, видимо) запрос, и с переменной $host_short творится странное: в error_log: 2015/11/09 13:16:45 [warn] 58369#0: *41 using uninitialized "host_short" variable while logging request, client: 109.196.xxx.xx, server: all в access_log: 109.196.xxx.xx - - [09/Nov/2015:13:16:45 +0300] "-" 400 0 "-" "-" Как видно из первого лога, мы попали в правильный блок server{} Но как видно из обоих логов, в нём не обработалась директива set. Видимо, в nginx есть какая-то оптимизация внутри для некорректного запроса, и исполнение инструкций внутри server{} отбрасывается. Прав ли я в этом? А самое главное, как решить проблему порчи логов? set на уровне http очевидно невозможен. Будет ли полноценным решением воспользоваться функционалом из nginx 1.7.0 по условному логгированию? как-то так, чтоли: access_log /path/to/access.log combined_vhost if=($status != 400); Или это тоже не будет работать? Можно ли как-то решить вопрос, не обновляясь до 1.7.0? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на nginx.us Mon Nov 9 10:44:35 2015 From: nginx-forum на nginx.us (shureg) Date: Mon, 09 Nov 2015 05:44:35 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: References: Message-ID: ALex_hha, попробовал вписать.... не работает... :( Рестарт делал Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262655,262660#msg-262660 From nginx-forum на nginx.us Mon Nov 9 10:52:24 2015 From: nginx-forum на nginx.us (vitcool) Date: Mon, 09 Nov 2015 05:52:24 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: References: Message-ID: а этот домен 3-го уровня на отдельном IP? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262655,262661#msg-262661 From nginx-forum на nginx.us Mon Nov 9 10:53:36 2015 From: nginx-forum на nginx.us (shureg) Date: Mon, 09 Nov 2015 05:53:36 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: References: Message-ID: vitcool Wrote: ------------------------------------------------------- > а этот домен 3-го уровня на отдельном IP? да Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262655,262662#msg-262662 From nginx-forum на nginx.us Mon Nov 9 10:54:54 2015 From: nginx-forum на nginx.us (shureg) Date: Mon, 09 Nov 2015 05:54:54 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: References: Message-ID: <8db30686dde16da1b5301776913ba912.NginxMailingListRussian@forum.nginx.org> ой ошибся, у поддомена IP как и у основного домена Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262655,262663#msg-262663 From alex.hha на gmail.com Mon Nov 9 11:32:54 2015 From: alex.hha на gmail.com (Alex Domoradov) Date: Mon, 9 Nov 2015 13:32:54 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: <8db30686dde16da1b5301776913ba912.NginxMailingListRussian@forum.nginx.org> References: <8db30686dde16da1b5301776913ba912.NginxMailingListRussian@forum.nginx.org> Message-ID: Что значит не работает? Что в логах? 2015-11-09 12:54 GMT+02:00 shureg : > ой ошибся, у поддомена IP как и у основного домена > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,262655,262663#msg-262663 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на nginx.us Mon Nov 9 11:43:40 2015 From: nginx-forum на nginx.us (shureg) Date: Mon, 09 Nov 2015 06:43:40 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: References: Message-ID: <76e6a404ce64053911086adc34628c6f.NginxMailingListRussian@forum.nginx.org> При попытке зайти на под домен выдает ошибку, что сервер не найден, логи пусты ALex_hha Wrote: ------------------------------------------------------- > Что значит не работает? Что в логах? > > 2015-11-09 12:54 GMT+02:00 shureg : > > > ой ошибся, у поддомена IP как и у основного домена > > > > Posted at Nginx Forum: > > https://forum.nginx.org/read.php?21,262655,262663#msg-262663 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262655,262665#msg-262665 From denis на webmaster.spb.ru Mon Nov 9 11:46:28 2015 From: denis на webmaster.spb.ru (denis) Date: Mon, 09 Nov 2015 14:46:28 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: References: Message-ID: <56408794.2020400@webmaster.spb.ru> 09.11.2015 13:44, shureg пишет: > ALex_hha, попробовал вписать.... не работает... :( > Рестарт делал Включаю телепата: основной домен описан не как site.ru www.site.ru а как *.site.ru или просто .site.ru Для начала, переименовываем конфиг поддомена так, чтобы он всегда читался раньше основного, например 000_site.ru.conf. Раньше я поддомены начинал с _, но мартышки в дебиане сделали всё с _ игнорировать, на чём много нервов потратил, на основных серверах у нас freebsd и там это работало. Теперь даже с основным доменом с точки будет работать. В свою очередь, у нгинха нет валидации итога глазами, то есть нельзя вывести склеенный конфиг, "намэтонинада", и отладка поддоменов может быть мучительной. Ну и в таких случаях обычно прикладывают конфиги, лучше на пастебин, сюда только если кусочки From defan на nginx.com Mon Nov 9 11:48:57 2015 From: defan на nginx.com (Andrei Belov) Date: Mon, 9 Nov 2015 14:48:57 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: <56408794.2020400@webmaster.spb.ru> References: <56408794.2020400@webmaster.spb.ru> Message-ID: <072DE827-892C-45FF-A3EA-FF6AD2646221@nginx.com> > On 09 Nov 2015, at 14:46, denis wrote: > > 09.11.2015 13:44, shureg пишет: >> ALex_hha, попробовал вписать.... не работает... :( >> Рестарт делал > Включаю телепата: основной домен описан не как site.ru www.site.ru а как *.site.ru или просто .site.ru > > Для начала, переименовываем конфиг поддомена так, чтобы он всегда читался раньше основного, например 000_site.ru.conf. Раньше я поддомены начинал с _, но мартышки в дебиане сделали всё с _ игнорировать, на чём много нервов потратил, на основных серверах у нас freebsd и там это работало. > Теперь даже с основным доменом с точки будет работать. > > В свою очередь, у нгинха нет валидации итога глазами, то есть нельзя вывести склеенный конфиг, "намэтонинада", и отладка поддоменов может быть мучительной. Начиная с 1.9.2 есть "-T". http://nginx.org/ru/docs/switches.html From dmitriy на lyalyuev.info Mon Nov 9 11:49:29 2015 From: dmitriy на lyalyuev.info (Dmitriy Lyalyuev) Date: Mon, 9 Nov 2015 13:49:29 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: <76e6a404ce64053911086adc34628c6f.NginxMailingListRussian@forum.nginx.org> References: <76e6a404ce64053911086adc34628c6f.NginxMailingListRussian@forum.nginx.org> Message-ID: <56408849.2020105@lyalyuev.info> Так может проблема не в Nginx, а стоит прописать поддомен в DNS? 09.11.2015 13:43, shureg пишет: > При попытке зайти на под домен выдает ошибку, что сервер не найден, > логи пусты > ALex_hha Wrote: > ------------------------------------------------------- >> Что значит не работает? Что в логах? >> >> 2015-11-09 12:54 GMT+02:00 shureg : >> >>> ой ошибся, у поддомена IP как и у основного домена >>> >>> Posted at Nginx Forum: >>> https://forum.nginx.org/read.php?21,262655,262663#msg-262663 >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262655,262665#msg-262665 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From denis на webmaster.spb.ru Mon Nov 9 11:50:19 2015 From: denis на webmaster.spb.ru (denis) Date: Mon, 09 Nov 2015 14:50:19 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: <072DE827-892C-45FF-A3EA-FF6AD2646221@nginx.com> References: <56408794.2020400@webmaster.spb.ru> <072DE827-892C-45FF-A3EA-FF6AD2646221@nginx.com> Message-ID: <5640887B.6050509@webmaster.spb.ru> 09.11.2015 14:48, Andrei Belov пишет: > Начиная с 1.9.2 есть "-T". Неужели таки сдались? Я эту опцию просил ещё лет 8 назад, и с тех пор не раз. Позиция была всегда "не хотим" From maxim на nginx.com Mon Nov 9 11:52:26 2015 From: maxim на nginx.com (Maxim Konovalov) Date: Mon, 9 Nov 2015 14:52:26 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: <5640887B.6050509@webmaster.spb.ru> References: <56408794.2020400@webmaster.spb.ru> <072DE827-892C-45FF-A3EA-FF6AD2646221@nginx.com> <5640887B.6050509@webmaster.spb.ru> Message-ID: <564088FA.50204@nginx.com> On 11/9/15 2:50 PM, denis wrote: > 09.11.2015 14:48, Andrei Belov пишет: >> Начиная с 1.9.2 есть "-T". > Неужели таки сдались? Я эту опцию просил ещё лет 8 назад, и с тех > пор не раз. Позиция была всегда "не хотим" > Русские не сдаются, you know. -- Maxim Konovalov From maxim на nginx.com Mon Nov 9 12:12:03 2015 From: maxim на nginx.com (Maxim Konovalov) Date: Mon, 9 Nov 2015 15:12:03 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: <072DE827-892C-45FF-A3EA-FF6AD2646221@nginx.com> References: <56408794.2020400@webmaster.spb.ru> <072DE827-892C-45FF-A3EA-FF6AD2646221@nginx.com> Message-ID: <56408D93.5040606@nginx.com> [...] >> В свою очередь, у нгинха нет валидации итога глазами, то есть >> нельзя вывести склеенный конфиг, "намэтонинада", и отладка >> поддоменов может быть мучительной. > > Начиная с 1.9.2 есть "-T". > > http://nginx.org/ru/docs/switches.html > И даже более того, c --with-debug можно сдампить конфигурацию из процесса/core dump https://www.nginx.com/blog/new-debugging-features-probe-nginx-internals/ -- Maxim Konovalov From nginx-forum на nginx.us Mon Nov 9 12:17:28 2015 From: nginx-forum на nginx.us (shureg) Date: Mon, 09 Nov 2015 07:17:28 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: <56408849.2020105@lyalyuev.info> References: <56408849.2020105@lyalyuev.info> Message-ID: <3b58e72daba9845770b62db7bbfe4217.NginxMailingListRussian@forum.nginx.org> Dmitriy Lyalyuev Wrote: ------------------------------------------------------- > Так может проблема не в Nginx, а стоит прописать поддомен в DNS? оО у меня панели управления нет, а днс для основного домена просто прописал у регистратора Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262655,262672#msg-262672 From dmitriy на lyalyuev.info Mon Nov 9 12:19:09 2015 From: dmitriy на lyalyuev.info (Dmitriy Lyalyuev) Date: Mon, 9 Nov 2015 14:19:09 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: <3b58e72daba9845770b62db7bbfe4217.NginxMailingListRussian@forum.nginx.org> References: <56408849.2020105@lyalyuev.info> <3b58e72daba9845770b62db7bbfe4217.NginxMailingListRussian@forum.nginx.org> Message-ID: <56408F3D.9020807@lyalyuev.info> Вероятно там же стоит прописать и поддомен. Тема ДНС никак не связана с данным списком рассылки. Почитайте про принципы работы ДНС - много вопросов отпадут сами собой. 09.11.2015 14:17, shureg пишет: > Dmitriy Lyalyuev Wrote: > ------------------------------------------------------- >> Так может проблема не в Nginx, а стоит прописать поддомен в DNS? > > оО у меня панели управления нет, а днс для основного домена просто прописал > у регистратора > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262655,262672#msg-262672 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From denis на webmaster.spb.ru Mon Nov 9 12:28:44 2015 From: denis на webmaster.spb.ru (denis) Date: Mon, 09 Nov 2015 15:28:44 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC+0LfQtNCw0YLRjCDQv9C+0LQg0LTQvtC80LXQvT8=?= In-Reply-To: <56408D93.5040606@nginx.com> References: <56408794.2020400@webmaster.spb.ru> <072DE827-892C-45FF-A3EA-FF6AD2646221@nginx.com> <56408D93.5040606@nginx.com> Message-ID: <5640917C.7090901@webmaster.spb.ru> 09.11.2015 15:12, Maxim Konovalov пишет: > [...] >>> В свою очередь, у нгинха нет валидации итога глазами, то есть >>> нельзя вывести склеенный конфиг, "намэтонинада", и отладка >>> поддоменов может быть мучительной. >> Начиная с 1.9.2 есть "-T". >> >> http://nginx.org/ru/docs/switches.html >> > И даже более того, c --with-debug можно сдампить конфигурацию из > процесса/core dump > > https://www.nginx.com/blog/new-debugging-features-probe-nginx-internals/ > Щикарно! Жить станет чуть проще. From mdounin на mdounin.ru Mon Nov 9 13:38:33 2015 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 9 Nov 2015 16:38:33 +0300 Subject: =?UTF-8?B?UmU6IFVuZGVmaW5lZCDQv9C10YDQtdC80LXQvdC90LDRjyDQv9GA0Lgg0LvQvtCz?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuA==?= In-Reply-To: References: Message-ID: <20151109133833.GS74233@mdounin.ru> Hello! On Mon, Nov 09, 2015 at 04:38:36PM +0600, Максим wrote: > Есть вот такой вот набор (в реальности всё разумеется сложнее, но свелось к > этому компактному конфигу): > > error_log /bla/error.log warn; > > http { > uninitialized_variable_warn on; > log_format combinedvhost '$host_short $remote_addr - $remote_user > [$time_local] ' > '"$request" $status $body_bytes_sent ' > '"$http_referer" "$http_user_agent"'; > > access_log /bla/access_log combinedvhost; > > server { > set $host_short "MYSTRING"; > > listen blah:80; > server_name all; > > ..... > } > > Всё логируется замечательно, но иногда приходит некий (некорректный, > видимо) запрос, и с переменной $host_short творится странное: > > в error_log: > 2015/11/09 13:16:45 [warn] 58369#0: *41 using uninitialized "host_short" > variable while logging request, client: 109.196.xxx.xx, server: all > > в access_log: > 109.196.xxx.xx - - [09/Nov/2015:13:16:45 +0300] "-" 400 0 "-" "-" > > Как видно из первого лога, мы попали в правильный блок server{} > Но как видно из обоих логов, в нём не обработалась директива set. Потому что до обработки директивы set дело не дошло - запрос клиента некорректен, ему вернули ошибку 400 ещё до того, как началась какая-либо обаботкабез всякой обработки. (В данном случае, видимо, запроса вообще не было, и nginx старый. В nginx 1.3.15 просто открытие соединения больше как 400 ошибка не логгируется. Впрочем, это не важно.) > Видимо, в nginx есть какая-то оптимизация внутри для некорректного запроса, > и исполнение инструкций внутри server{} отбрасывается. Прав ли я в этом? Почти. Это не оптимизация, просто оно так устроено - в случае возникновения ошибки обработка запроса прекращается. В данном случае обработка прекратилась ещё до того, как началась. > А самое главное, как решить проблему порчи логов? set на уровне http > очевидно невозможен. Если совсем просто, то так: uninitialized_variable_warn off; Подробнее - http://nginx.org/r/uninitialized_variable_warn. Ну или можно подумать подробнее над конфигурацией, и, скажем, переделать всё на использование map, http://nginx.org/r/map. > Будет ли полноценным решением воспользоваться функционалом из nginx 1.7.0 > по условному логгированию? > как-то так, чтоли: access_log /path/to/access.log combined_vhost > if=($status != 400); > > Или это тоже не будет работать? Работать, возможно, и будет, но это выглядит как плохая идея. -- Maxim Dounin http://nginx.org/ From maxout.mail на gmail.com Mon Nov 9 13:53:12 2015 From: maxout.mail на gmail.com (=?UTF-8?B?0JzQsNC60YHQuNC8?=) Date: Mon, 9 Nov 2015 19:53:12 +0600 Subject: =?UTF-8?B?UmU6IFVuZGVmaW5lZCDQv9C10YDQtdC80LXQvdC90LDRjyDQv9GA0Lgg0LvQvtCz?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuA==?= In-Reply-To: <20151109133833.GS74233@mdounin.ru> References: <20151109133833.GS74233@mdounin.ru> Message-ID: > > > А самое главное, как решить проблему порчи логов? set на уровне http > > очевидно невозможен. > > Если совсем просто, то так: > > uninitialized_variable_warn off; > > Подробнее - http://nginx.org/r/uninitialized_variable_warn. > > Ну или можно подумать подробнее над конфигурацией, и, скажем, > переделать всё на использование map, http://nginx.org/r/map. > > uninitialized_variable_warn off; выключит записи в error_log, но они как раз не беспокоят. Проблемой является нарушение формата access_log, так как получается, что первого элемента в строчке лога может не быть в некоторых запросах. Парсеры страдают, и вообще некрасиво. То есть если вместо set я на уровне http пропишу map с тем же смыслом, что нынешний set - этот map будет обрабатываться и в случае "плохого" запроса? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxout.mail на gmail.com Mon Nov 9 14:39:28 2015 From: maxout.mail на gmail.com (=?UTF-8?B?0JzQsNC60YHQuNC8?=) Date: Mon, 9 Nov 2015 20:39:28 +0600 Subject: =?UTF-8?B?UmU6IFVuZGVmaW5lZCDQv9C10YDQtdC80LXQvdC90LDRjyDQv9GA0Lgg0LvQvtCz?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuA==?= In-Reply-To: References: <20151109133833.GS74233@mdounin.ru> Message-ID: Переделал на MAP, всё работает как ожидалось, огромное спасибо! 2015-11-09 19:53 GMT+06:00 Максим : > > >> > А самое главное, как решить проблему порчи логов? set на уровне http >> > очевидно невозможен. >> >> Если совсем просто, то так: >> >> uninitialized_variable_warn off; >> >> Подробнее - http://nginx.org/r/uninitialized_variable_warn. >> >> Ну или можно подумать подробнее над конфигурацией, и, скажем, >> переделать всё на использование map, http://nginx.org/r/map. >> >> > uninitialized_variable_warn off; выключит записи в error_log, но они как > раз не беспокоят. > Проблемой является нарушение формата access_log, так как получается, что > первого элемента в строчке лога может не быть в некоторых запросах. Парсеры > страдают, и вообще некрасиво. > > То есть если вместо set я на уровне http пропишу map с тем же смыслом, что > нынешний set - этот map будет обрабатываться и в случае "плохого" запроса? > > > > > Это сообщение было отправлено с неинфицированного компьютера, защищенного программой Avast. www.avast.com <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Nov 9 14:44:23 2015 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 9 Nov 2015 17:44:23 +0300 Subject: =?UTF-8?B?UmU6IFVuZGVmaW5lZCDQv9C10YDQtdC80LXQvdC90LDRjyDQv9GA0Lgg0LvQvtCz?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuA==?= In-Reply-To: References: <20151109133833.GS74233@mdounin.ru> Message-ID: <20151109144423.GV74233@mdounin.ru> Hello! On Mon, Nov 09, 2015 at 07:53:12PM +0600, Максим wrote: > > > > > А самое главное, как решить проблему порчи логов? set на уровне http > > > очевидно невозможен. > > > > Если совсем просто, то так: > > > > uninitialized_variable_warn off; > > > > Подробнее - http://nginx.org/r/uninitialized_variable_warn. > > > > Ну или можно подумать подробнее над конфигурацией, и, скажем, > > переделать всё на использование map, http://nginx.org/r/map. > > > > > uninitialized_variable_warn off; выключит записи в error_log, но они как > раз не беспокоят. > Проблемой является нарушение формата access_log, так как получается, что > первого элемента в строчке лога может не быть в некоторых запросах. Парсеры > страдают, и вообще некрасиво. Ну как бы у вас переменная, которая в некоторых случаях может быть не установленной, и, соответственно, пустой. С точки зрения формата логов штатный путь это обработать - кавычки вокруг значения. > То есть если вместо set я на уровне http пропишу map с тем же смыслом, что > нынешний set - этот map будет обрабатываться и в случае "плохого" запроса? Значение map вычисляется в тот момент, когда потребовалось значение соответствующей переменной. Соответственно, если значение потребовалось при записи в лог - тогда оно и будет вычислено. -- Maxim Dounin http://nginx.org/ From maybe на arjlover.net Mon Nov 9 16:56:47 2015 From: maybe на arjlover.net (Anton Kuznetsov) Date: Mon, 9 Nov 2015 19:56:47 +0300 Subject: =?UTF-8?B?0LTRg9Cx0LvQuCDQsiDQutGN0YjQtQ==?= Message-ID: Добрый день! Обнаружил странность. В конфиге: fastcgi_cache_key "$request_method|$cache_gzip|$host|$request_uri"; Все стандартно, $cache_gzip=0|1 - переменная выставляется от енкодинга браузера. Грепаю директорию кэша по урлу и вижу 6 файлов, хотя ожидал увидеть 2! Как так случилось что появилось 5 файлов с абсолютно одинаковым KEY? Причем они живут своей жизнью. Я вижу что этот урл бегает на бэкенд 4-5 раз в час, хотя должен час жить и умирать только раз в час. KEY: GET|gzip|example.com|/api/v1/2213992 X-Powered-By: PHP/5.4.5 Expires: Tue, 27 Oct 2015 14:04:38 GMT Pragma: cache Cache-Control: max-age=3600, must-revalidate KEY: GET|gzip|example.com|/api/v1/2213992 X-Powered-By: PHP/5.4.5 Expires: Tue, 27 Oct 2015 14:00:51 GMT Pragma: cache Cache-Control: max-age=3600, must-revalidate KEY: GET||example.com|/api/v1/2213992 X-Powered-By: PHP/5.4.5 Expires: Tue, 27 Oct 2015 13:20:50 GMT Pragma: cache Cache-Control: max-age=3600, must-revalidate KEY: GET|gzip|example.com|/api/v1/2213992 X-Powered-By: PHP/5.4.5 Expires: Tue, 27 Oct 2015 13:49:07 GMT Pragma: cache Cache-Control: max-age=3600, must-revalidate KEY: GET|gzip|example.com|/api/v1/2213992 X-Powered-By: PHP/5.4.5 Expires: Tue, 27 Oct 2015 14:07:01 GMT Pragma: cache Cache-Control: max-age=3600, must-revalidate KEY: GET|gzip|example.com|/api/v1/2213992 X-Powered-By: PHP/5.4.5 Expires: Tue, 27 Oct 2015 13:37:40 GMT Pragma: cache Cache-Control: max-age=3600, must-revalidate -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Mon Nov 9 17:02:05 2015 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 9 Nov 2015 20:02:05 +0300 Subject: =?UTF-8?B?UmU6INC00YPQsdC70Lgg0LIg0LrRjdGI0LU=?= In-Reply-To: References: Message-ID: <20151109170205.GA74233@mdounin.ru> Hello! On Mon, Nov 09, 2015 at 07:56:47PM +0300, Anton Kuznetsov wrote: > Добрый день! > > Обнаружил странность. > В конфиге: > fastcgi_cache_key "$request_method|$cache_gzip|$host|$request_uri"; > > Все стандартно, $cache_gzip=0|1 - переменная выставляется от енкодинга > браузера. > > Грепаю директорию кэша по урлу и вижу 6 файлов, хотя ожидал увидеть 2! Как > так случилось что появилось 5 файлов с абсолютно одинаковым KEY? Причем они > живут своей жизнью. Я вижу что этот урл бегает на бэкенд 4-5 раз в час, > хотя должен час жить и умирать только раз в час. Несколько файлов для одного ключа бывают в случае, если используются вторичные ключи из-за Vary в ответе бекенда. Лечится выпиливанием Vary из ответа бекенда, либо использованием fastcgi_ignore_headers Vary. Подробнее тут: http://nginx.org/r/fastcgi_ignore_headers http://nginx.org/r/fastcgi_cache_valid -- Maxim Dounin http://nginx.org/ From maybe на arjlover.net Mon Nov 9 18:54:08 2015 From: maybe на arjlover.net (Anton Kuznetsov) Date: Mon, 9 Nov 2015 21:54:08 +0300 Subject: =?UTF-8?B?UmU6INC00YPQsdC70Lgg0LIg0LrRjdGI0LU=?= In-Reply-To: <20151109170205.GA74233@mdounin.ru> References: <20151109170205.GA74233@mdounin.ru> Message-ID: Но позвольте, зачем тогда нужен ключ кэширования? Я же четко сказал от чего он должен зависить? Почему он зависит еще от чего-то? 2015-11-09 20:02 GMT+03:00 Maxim Dounin : > Hello! > > On Mon, Nov 09, 2015 at 07:56:47PM +0300, Anton Kuznetsov wrote: > > > Добрый день! > > > > Обнаружил странность. > > В конфиге: > > fastcgi_cache_key "$request_method|$cache_gzip|$host|$request_uri"; > > > > Все стандартно, $cache_gzip=0|1 - переменная выставляется от енкодинга > > браузера. > > > > Грепаю директорию кэша по урлу и вижу 6 файлов, хотя ожидал увидеть 2! > Как > > так случилось что появилось 5 файлов с абсолютно одинаковым KEY? Причем > они > > живут своей жизнью. Я вижу что этот урл бегает на бэкенд 4-5 раз в час, > > хотя должен час жить и умирать только раз в час. > > Несколько файлов для одного ключа бывают в случае, если > используются вторичные ключи из-за Vary в ответе бекенда. > > Лечится выпиливанием Vary из ответа бекенда, либо > использованием fastcgi_ignore_headers Vary. > > Подробнее тут: > > http://nginx.org/r/fastcgi_ignore_headers > http://nginx.org/r/fastcgi_cache_valid > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maybe на arjlover.net Mon Nov 9 19:03:42 2015 From: maybe на arjlover.net (Anton Kuznetsov) Date: Mon, 9 Nov 2015 22:03:42 +0300 Subject: =?UTF-8?B?UmU6INC00YPQsdC70Lgg0LIg0LrRjdGI0LU=?= In-Reply-To: References: <20151109170205.GA74233@mdounin.ru> Message-ID: Включил логирование Vary - обнаружил ровно два варианта. Четко повторяют что передал браузер и соответственно четко следует за моей переменной $cache_gzip=0|1- вроде бы должно получаться два моих задуманных варианта. 2015-11-09 21:54 GMT+03:00 Anton Kuznetsov : > Но позвольте, зачем тогда нужен ключ кэширования? Я же четко сказал от > чего он должен зависить? Почему он зависит еще от чего-то? > > 2015-11-09 20:02 GMT+03:00 Maxim Dounin : > >> Hello! >> >> On Mon, Nov 09, 2015 at 07:56:47PM +0300, Anton Kuznetsov wrote: >> >> > Добрый день! >> > >> > Обнаружил странность. >> > В конфиге: >> > fastcgi_cache_key "$request_method|$cache_gzip|$host|$request_uri"; >> > >> > Все стандартно, $cache_gzip=0|1 - переменная выставляется от енкодинга >> > браузера. >> > >> > Грепаю директорию кэша по урлу и вижу 6 файлов, хотя ожидал увидеть 2! >> Как >> > так случилось что появилось 5 файлов с абсолютно одинаковым KEY? Причем >> они >> > живут своей жизнью. Я вижу что этот урл бегает на бэкенд 4-5 раз в час, >> > хотя должен час жить и умирать только раз в час. >> >> Несколько файлов для одного ключа бывают в случае, если >> используются вторичные ключи из-за Vary в ответе бекенда. >> >> Лечится выпиливанием Vary из ответа бекенда, либо >> использованием fastcgi_ignore_headers Vary. >> >> Подробнее тут: >> >> http://nginx.org/r/fastcgi_ignore_headers >> http://nginx.org/r/fastcgi_cache_valid >> >> -- >> Maxim Dounin >> http://nginx.org/ >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > Best regards, > Anton Kuznetsov. > -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Mon Nov 9 19:35:31 2015 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 9 Nov 2015 22:35:31 +0300 Subject: =?UTF-8?B?UmU6INC00YPQsdC70Lgg0LIg0LrRjdGI0LU=?= In-Reply-To: References: <20151109170205.GA74233@mdounin.ru> Message-ID: <20151109193531.GG74233@mdounin.ru> Hello! On Mon, Nov 09, 2015 at 10:03:42PM +0300, Anton Kuznetsov wrote: > Включил логирование Vary - обнаружил ровно два варианта. Четко повторяют > что передал браузер и соответственно четко следует за моей переменной > $cache_gzip=0|1- > вроде бы должно получаться два моих задуманных варианта. В заголовке Vary указываются заголовки запроса, от которых зависит вторичный ключ кеширования. Т.е. даже при ровно одном варианте, Vary: Vary: Accept-Encoding количество возможных варинтов ответов начинает определяеться количеством возможных значений Accept-Encoding, которые присылает клиент. > 2015-11-09 21:54 GMT+03:00 Anton Kuznetsov : > > > Но позвольте, зачем тогда нужен ключ кэширования? Я же четко сказал от > > чего он должен зависить? Почему он зависит еще от чего-то? Явно заданный ключ кеширования работает тогда и только тогда, когда мы заранее знаем, от чего зависит ответ бекенда. В этом случае проверку Vary можно выключить, и использовать только явно заданный ключ. Если же результат ответа бекенда заранее не известен, то приходится пытаться придумывать что-то, что позволило бы бекенду контролировать процесс. В HTTP/1.1 для этого придуман механизм вариативности ресурсов - ресурс может существовать в нескольких вариантах, и с помощью заголовка Vary бекенд сообщает о том, от каких именно заголовков завист, какой вариант будет выбран. Механизм, скажем так, не очень, и приводит к ужасному дублированию ресурсов при кешировании (особенно, если пытаться использовать "Vary: User-Agent", как некоторые делают), но уж какой есть. Задачу свою он, так или иначе, выполняет, и позволяет обеспечить корректность ответов в общем случае, когда поведение бекенда заранее не известно. Если вам этот механизм не нужен - в nginx'е есть ручка, позволяющая поддержку этого механизма выключить, и, соответветственно, явно прописать правила руками. Подробнее тут, как уже говорилось, тут: http://nginx.org/r/fastcgi_ignore_headers http://nginx.org/r/fastcgi_cache_valid -- Maxim Dounin http://nginx.org/ From bgx на protva.ru Mon Nov 9 21:21:40 2015 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 10 Nov 2015 00:21:40 +0300 Subject: =?UTF-8?B?UmU6INC00YPQsdC70Lgg0LIg0LrRjdGI0LU=?= In-Reply-To: <20151109193531.GG74233@mdounin.ru> References: <20151109170205.GA74233@mdounin.ru> <20151109193531.GG74233@mdounin.ru> Message-ID: <20151109212139.GG3896@sie.protva.ru> On Mon, Nov 09, 2015 at 10:35:31PM +0300, Maxim Dounin wrote: > > 2015-11-09 21:54 GMT+03:00 Anton Kuznetsov : > > > > > Но позвольте, зачем тогда нужен ключ кэширования? Я же четко сказал от > > > чего он должен зависить? Почему он зависит еще от чего-то? > > Явно заданный ключ кеширования работает тогда и только тогда, > когда мы заранее знаем, от чего зависит ответ бекенда. В этом > случае проверку Vary можно выключить, и использовать только явно > заданный ключ. Поддерживаю Антона: поведение совершенно неожиданное, и к тому же никак не описанное в документации. Прежде всего нужно эту засаду задокументировать, чтобы прилежные читатели не налетали на грабли. -- Eugene Berdnikov From maybe на arjlover.net Tue Nov 10 00:46:23 2015 From: maybe на arjlover.net (Anton Kuznetsov) Date: Tue, 10 Nov 2015 03:46:23 +0300 Subject: =?UTF-8?B?UmU6INC00YPQsdC70Lgg0LIg0LrRjdGI0LU=?= In-Reply-To: <20151109193531.GG74233@mdounin.ru> References: <20151109170205.GA74233@mdounin.ru> <20151109193531.GG74233@mdounin.ru> Message-ID: Спасибо, вырезал Vary - полет нормальный. Вообще странно, что об этом прямо не упомянуто в доке в абзаце про cache_key. Какое-то отдельное знание сейчас. 2015-11-09 22:35 GMT+03:00 Maxim Dounin : > Hello! > > On Mon, Nov 09, 2015 at 10:03:42PM +0300, Anton Kuznetsov wrote: > > > Включил логирование Vary - обнаружил ровно два варианта. Четко повторяют > > что передал браузер и соответственно четко следует за моей переменной > > $cache_gzip=0|1- > > вроде бы должно получаться два моих задуманных варианта. > > В заголовке Vary указываются заголовки запроса, от которых зависит > вторичный ключ кеширования. Т.е. даже при ровно одном варианте, > Vary: > > Vary: Accept-Encoding > > количество возможных варинтов ответов начинает определяеться > количеством возможных значений Accept-Encoding, которые присылает > клиент. > > > 2015-11-09 21:54 GMT+03:00 Anton Kuznetsov : > > > > > Но позвольте, зачем тогда нужен ключ кэширования? Я же четко сказал от > > > чего он должен зависить? Почему он зависит еще от чего-то? > > Явно заданный ключ кеширования работает тогда и только тогда, > когда мы заранее знаем, от чего зависит ответ бекенда. В этом > случае проверку Vary можно выключить, и использовать только явно > заданный ключ. > > Если же результат ответа бекенда заранее не известен, то > приходится пытаться придумывать что-то, что позволило бы бекенду > контролировать процесс. > > В HTTP/1.1 для этого придуман механизм вариативности ресурсов - > ресурс может существовать в нескольких вариантах, и с помощью > заголовка Vary бекенд сообщает о том, от каких именно заголовков > завист, какой вариант будет выбран. Механизм, скажем так, не > очень, и приводит к ужасному дублированию ресурсов при > кешировании (особенно, если пытаться использовать "Vary: > User-Agent", как некоторые делают), но уж какой есть. Задачу свою > он, так или иначе, выполняет, и позволяет обеспечить корректность > ответов в общем случае, когда поведение бекенда заранее не > известно. > > Если вам этот механизм не нужен - в nginx'е есть ручка, > позволяющая поддержку этого механизма выключить, и, > соответветственно, явно прописать правила руками. > > Подробнее тут, как уже говорилось, тут: > > http://nginx.org/r/fastcgi_ignore_headers > http://nginx.org/r/fastcgi_cache_valid > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kuznetsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на nginx.us Tue Nov 10 08:18:19 2015 From: nginx-forum на nginx.us (Michael Mikhulya) Date: Tue, 10 Nov 2015 03:18:19 -0500 Subject: =?UTF-8?B?UmU6IHNwZHkg0LHQvtC70YzRiNC+0LkgdHRmYg==?= In-Reply-To: References: Message-ID: если используете limit_req, то убедитесь, что его действие не распространяется на раздачу статики. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,261748,262696#msg-262696 From nginx-forum на nginx.us Tue Nov 10 13:44:47 2015 From: nginx-forum на nginx.us (S.A.N) Date: Tue, 10 Nov 2015 08:44:47 -0500 Subject: =?UTF-8?B?UmU6INC00YPQsdC70Lgg0LIg0LrRjdGI0LU=?= In-Reply-To: <20151109212139.GG3896@sie.protva.ru> References: <20151109212139.GG3896@sie.protva.ru> Message-ID: > Поддерживаю Антона: поведение совершенно неожиданное, и к тому же > никак не описанное в документации. Прежде всего нужно эту засаду > задокументировать, чтобы прилежные читатели не налетали на грабли. Это не засада, это описано в спеке HTTP/1.1 :) Если разработчики бекенда не знают спецификации Vary, зачем тогда они используют этот заголовок? Но я согласен, более безопасно чтобы по дефолту Nginx не обрабатывал Vary, лучше если будет отдельная директива для включению Vary, уверен что многие не знаю что в Nginx 1.9.х по дефолту включена обработка Vary. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262685,262707#msg-262707 From mdounin на mdounin.ru Tue Nov 10 13:57:48 2015 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 10 Nov 2015 16:57:48 +0300 Subject: =?UTF-8?B?UmU6INC00YPQsdC70Lgg0LIg0LrRjdGI0LU=?= In-Reply-To: References: <20151109212139.GG3896@sie.protva.ru> Message-ID: <20151110135748.GJ74233@mdounin.ru> Hello! On Tue, Nov 10, 2015 at 08:44:47AM -0500, S.A.N wrote: > > Поддерживаю Антона: поведение совершенно неожиданное, и к тому же > > никак не описанное в документации. Прежде всего нужно эту засаду > > задокументировать, чтобы прилежные читатели не налетали на грабли. > > Это не засада, это описано в спеке HTTP/1.1 :) > Если разработчики бекенда не знают спецификации Vary, зачем тогда они > используют этот заголовок? > > Но я согласен, более безопасно чтобы по дефолту Nginx не обрабатывал Vary, > лучше если будет отдельная директива для включению Vary, уверен что многие > не знаю что в Nginx 1.9.х по дефолту включена обработка Vary. Самое плохое, что может случиться от "неожиданной" обработки Vary - это падение эффективности кеширования. А от его необработки - теряется корректность возвращаемых ответов, и, e.g., клиенту, который не понимает gzip, может быть возвращён сжатый ответ из кеша. Т.е., фактически, клиент не получит ответ. И, более того, администратор сможет узнать об этом только в том случае, если пользователь сам пожалуется. Поэтому поведение по умолчанию - обрабатывать Vary. -- Maxim Dounin http://nginx.org/ From bgx на protva.ru Tue Nov 10 14:34:42 2015 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 10 Nov 2015 17:34:42 +0300 Subject: =?UTF-8?B?UmU6INC00YPQsdC70Lgg0LIg0LrRjdGI0LU=?= In-Reply-To: References: <20151109212139.GG3896@sie.protva.ru> Message-ID: <20151110143442.GJ3896@sie.protva.ru> On Tue, Nov 10, 2015 at 08:44:47AM -0500, S.A.N wrote: > > Поддерживаю Антона: поведение совершенно неожиданное, и к тому же > > никак не описанное в документации. Прежде всего нужно эту засаду > > задокументировать, чтобы прилежные читатели не налетали на грабли. > > Это не засада, это описано в спеке HTTP/1.1 :) Мы обсуждаем директивы конфигурации nginx, а не протокол HTTP. Директивы, по возможности, должны быть понятны и иметь названия, отражающее стоящие за ними алгоритмы, чтобы пользователь понимал что он делает и что получит, применив эту директиву. В данном случае нет никаких намёков на то, что указанный ключ не единственный и в коде зашито что-то ещё... Даже тот, кто отлично знает протокол, может про Vary/Set-Cookie/etc просто забыть. Поэтому документация должна как минимум предупреждать о возможной проблеме. > Если разработчики бекенда не знают спецификации Vary, зачем тогда они > используют этот заголовок? Разработчики движков и админы сайтов (пользователи) это, как правило, совершенно разные люди с несоразмерной квалификацией. Админ может даже не подозревать, что движок его бэкенда использует какой-то там Vary, и что с этим могут быть связаны проблемы. Но он вправе ожидать, что найденная им в мануале директива будет делать в точности то, что про неё написано. -- Eugene Berdnikov From nginx-forum на nginx.us Tue Nov 10 20:32:01 2015 From: nginx-forum на nginx.us (S.A.N) Date: Tue, 10 Nov 2015 15:32:01 -0500 Subject: =?UTF-8?B?UmU6INC00YPQsdC70Lgg0LIg0LrRjdGI0LU=?= In-Reply-To: <20151110135748.GJ74233@mdounin.ru> References: <20151110135748.GJ74233@mdounin.ru> Message-ID: <1733634c8fb91897057cb70a1661c9d8.NginxMailingListRussian@forum.nginx.org> > А от его необработки - теряется корректность возвращаемых ответов, > и, e.g., клиенту, который не понимает gzip, может быть возвращён > сжатый ответ из кеша. Т.е., фактически, клиент не получит ответ. > И, более того, администратор сможет узнать об этом только в том > случае, если пользователь сам пожалуется. Это не совсем так, если ответ бекенда зависит от заголовков, значения этих заголовков добавляли в ключ кеша, самостоятельно, в противном случаи клиенты бы получали не корректные ответы, кстати автор сабжа делал так же, плюс отдавались правильные заголовки Vary, для прокси и поисковых роботов, это уже давняя практика. Проблема в том, что тогда ещё никто не знал, что Nginx в будущем будет автоматически обрабатывать Vary. По этому я предложил, по умолчанию Vary не обрабатывать, но возможно достаточно описать Vary в документации про ключи кеширования Nginx и люди самостоятельно будут обновлять свои конфигурации. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,262685,262718#msg-262718 From jd на jdwuzhere.ru Wed Nov 11 17:41:24 2015 From: jd на jdwuzhere.ru (Vladimir Sopot) Date: Wed, 11 Nov 2015 20:41:24 +0300 Subject: SSI vs sendfile+aio threads Message-ID: <4262265A-3983-44C2-A66F-E6FBDB79B869@jdwuzhere.ru> Привет! Столкнулся тут с микро адом nginx version: nginx/1.9.6 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) configure arguments: --without-mail_pop3_module --without-mail_smtp_module --without-http_autoindex_module --without-http_userid_module --with-file-aio --without-http_scgi_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_uwsgi_module --without-http_memcached_module --with-threads --with-debug nginx.conf: sendfile on; aio threads; server { server_name test.ru; location / { root /wwwroot/test.ru/htdocs; index index.shtml; default_type text/html; ssi on; } index.shtml this is the beginning