Thanks Maxim and GreenGecko for the insights
The worker process does match my number of cpu cores (running on 8 cores
atm)
How can i know the number of handshakes per seconds occurring on the
server
The openssl speed result have been posted on http://pastebin.com/hNeVhJfa
for readability
On 1 Jul 2014 07:58, Lucas Rolff lu...@slcoding.com wrote:
Hi guys,
I'm currently running nginx version 1.6.0 (after upgrading from 1.4.4).
Sadly I've found out, after upgrading proxy_pass_header seems to stop
working, meaning no headers is passed from the upstream at all
You need to read
Well, it used to work before 1.6.0..
For me
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header
shows that I should do:
proxy_pass_header Cache-Control;
So that should be correct
Best regards,
Lucas Rolff
Jonathan Matthews wrote:
On 1 Jul 2014 07:58, Lucas Rolff
On 1 Jul 2014 10:20, Lucas Rolff lu...@slcoding.com wrote:
Well, it used to work before 1.6.0..
For me
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header
shows that I should do:
proxy_pass_header Cache-Control;
So that should be correct
No. You have misread the
On 1 Jul 2014 10:34, Lucas Rolff lu...@slcoding.com wrote:
Do you have a link to a documentation that has info about this then?
Because in the below link, and in
http://wiki.nginx.org/HttpProxyModule#proxy_pass_header theres nothing
about what it accepts.
How about the doc you already found,
So.. Where is the thing that states I can't use proxy_pass_header
cache-control, or expires? :)))
Maybe I'm just stupid
Best regards,
Lucas Rolff
Jonathan Matthews wrote:
On 1 Jul 2014 10:34, Lucas Rolff lu...@slcoding.com
mailto:lu...@slcoding.com wrote:
Do you have a link to a
On 1 Jul 2014 11:01, Lucas Rolff lu...@slcoding.com wrote:
So.. Where is the thing that states I can't use proxy_pass_header
cache-control, or expires? :)))
The proxy_hide_header and proxy_pass_header reference docs.
___
nginx mailing list
I've verified that 1.4.4 works as it should, I receive the cache-control
and expires headers sent from upstream (Apache 2.4 in this case),
upgrading to nginx 1.6.0 breaks this, no config changes, nothing.
But thanks for the explanation Robert!
I'll try investigate it further to see if I can
I've been investigating, and seems like it's related to 1.6 or so -
because 1.4.2 and 1.4.4 works perfectly with the config in the first email.
Any that can possibly reproduce this as well?
Best regards,
Lucas R
Robert Paprocki wrote:
Can we move past passive aggressive posting to a public
On Tuesday 01 July 2014 10:30:47 Lucas Rolff wrote:
I've verified that 1.4.4 works as it should, I receive the cache-control
and expires headers sent from upstream (Apache 2.4 in this case),
upgrading to nginx 1.6.0 breaks this, no config changes, nothing.
But thanks for the explanation
nginx:
curl -I http://domain.com/wp-content/uploads/2012/05/forside.png
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 01 Jul 2014 10:42:06 GMT
Content-Type: image/png
Content-Length: 87032
Last-Modified: Fri, 08 Mar 2013 08:02:48 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: 51399b28-153f8
Hello!
On Mon, Jun 30, 2014 at 11:10:52PM -0400, Paul Schlie wrote:
Regarding:
In http, responses are not guaranteed to be the same. Each
response can be unique, and you can't assume responses have to be
identical even if their URLs match.
Yes, but potentially unique does not
You need to examine traffic over the wire between the proxy and the
origin as you send a request from an outside client to the proxy. This
will allow you to see if the origin is even returning the expected
headers to the proxy, or if the proxy is seeing a different response
than a direct client
We've an origin and edge server with nginx-1.6 . Origin web-server(Located
in U.S) is configured with nginx_geo_module and edge(Local ISP) is
configured with proxy_cache in order to cache files from origin server and
serve from their lately. We're using following method for caching with
Our caching method is :-
client origin --- edge.
On Tue, Jul 1, 2014 at 4:57 PM, shahzaib shahzaib shahzaib...@gmail.com
wrote:
We've an origin and edge server with nginx-1.6 . Origin web-server(Located
in U.S) is configured with nginx_geo_module and edge(Local ISP) is
configured with
Hello!
On Tue, Jul 01, 2014 at 01:00:05PM +0200, Lucas Rolff wrote:
nginx:
curl -I http://domain.com/wp-content/uploads/2012/05/forside.png
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 01 Jul 2014 10:42:06 GMT
Content-Type: image/png
Content-Length: 87032
Last-Modified: Fri, 08 Mar 2013
As it appears a downstream response is not cached until first completely read
into a temp_file (which for a large file may require 100's if not 1,000's of MB
be transferred), there appears to be no cache node formed which to lock or
serve stale responses from, and thereby until the first cache
But if files was served from backend I would assume to see the
$upstream_response_time variable in nginx would return other stuff than
a dash in 1.4.4
Like this, using logformat:
$request$status$body_bytes_sent$http_referer$http_user_agent$request_time$upstream_response_time';
GET
Hello!
On Tue, Jul 01, 2014 at 02:33:54PM +0200, Lucas Rolff wrote:
Hmm, okay..
Then I'll go back to an old buggy version of nginx which gives me the
possibility to use the headers from Backend!
You don't need to go back (and I doubt it will help) - if you
don't want nginx to serve files
Hello!
On Tue, Jul 01, 2014 at 08:44:47AM -0400, Paul Schlie wrote:
As it appears a downstream response is not cached until first
completely read into a temp_file (which for a large file may
require 100's if not 1,000's of MB be transferred), there
appears to be no cache node formed which
Hello!
On Tue, Jul 01, 2014 at 03:10:07AM -0400, khav wrote:
Thanks Maxim and GreenGecko for the insights
The worker process does match my number of cpu cores (running on 8 cores
atm)
Good. It may be also good idea to make sure you don't have
multi_accept enabled, just in case.
How
Then how could multiple streams and corresponding temp_files ever be created
upon successive requests for the same $uri with proxy_cache_key $uri and
proxy_cache_lock on; if all subsequent requests are locked to the same
cache_node created by the first request even prior to its completion?
I am currently using 1024 bit dhparams for maximum compatibility
Here is my ssllabs report :
https://www.ssllabs.com/ssltest/analyze.html?d=filterbypass.me
If i remove the DH from my cipher suites , will handshake simulation be
still a success for all browsers listed in the ssllabs report
On 01 Jul 2014, at 09:35, audvare nginx-fo...@nginx.us wrote:
Roman Arutyunyan Wrote:
---
Currently nginx does not seem to be able to do what you want. If
you’re ready to patch
the source here’s the patch fixing the issue.
diff -r
Hello!
On Tue, Jul 01, 2014 at 10:15:47AM -0400, Paul Schlie wrote:
Then how could multiple streams and corresponding temp_files
ever be created upon successive requests for the same $uri with
proxy_cache_key $uri and proxy_cache_lock on; if all
subsequent requests are locked to the same
Hello Maxim,
On 6/22/14, 7:32 AM, Maxim Dounin mdou...@mdounin.ru wrote:
If there is nothing in error logs, and you are getting 502 errors,
then there are two options:
1. The 502 errors are returned by your backend, not generated by
nginx.
2. You did something wrong while configuring error
Thank you for your patience.
I mistakenly thought the 5 second default value associated with
proxy_cache_lock_timeout was the maximum delay allowed between successive
responses from the backend server is satisfaction of the reverse proxy request
being cached prior to the cache lock being
Lastly, is there any way to try to get proxy_store to work in combination with
proxy_cache, possibly by enabling the completed temp_file to be saved as a
proxy_store file within its uri logical path hierarchy, and the cache_file
descriptor aliased to it, or visa versa?
(As it's often nice to
Hello,
I am seeing an odd thing occur in the error logs. We are developing an API,
and when our mobile devices first hit the nginx server after waking up, the
mobile device is rejecting the ssl cert. In the logs, we see that the ssl
handshake is being closed.
[info] 1450#0: *16 peer closed
I forgot to mention that this is running on Ubuntu 12.04LTS, with nginx
version: nginx/1.6.0.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,251423,251424#msg-251424
___
nginx mailing list
nginx@nginx.org
vamshi Wrote:
---
header_filter_by_lua '
ngx.header.content_length = nil
ngx.header.set_cookie = nil
if ngx.header.location then
local _location = ngx.header.location
Hello,
Could your issue be caused by this bug
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/965371. It looks
like Ubuntu is not going to fix this bug in precise. Also see here
http://serverfault.com/questions/436737/forcing-a-particular-ssl-protocol-for-an-nginx-proxying-server.
In the
Hi Filipe,
What if I look into this one http://trac.nginx.org/nginx/ticket/485
This kind of change in the ngx_http_request_t struct will be accepted (and
furthermore auth basic module, upstream ...) ??
Thanks in advance.
On 30 June 2014 09:05, Filipe Da Silva fdasilv...@gmail.com wrote:
Hi,
Максим, а можно немного подробнее про нюансы с unix сокетами?
30 июня 2014 г., 21:54 пользователь Maxim Dounin mdou...@mdounin.ru
написал:
Hello!
On Sun, Jun 29, 2014 at 09:07:55PM +0400, Maxim Kozlov wrote:
Использовать сторонние модули желания нет.
Простой workaround - сделать
Вряд ли дело в этом: размер блока у меня 1 Кб, средний размер файлов во
втором кэше — около 100 Кб, файлов порядка полумиллиона. Так что погрешность
может быть не больше полугигабайта.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251307,251352#msg-251352
Maxim Dounin, спасибо вам огромное! взял вариант с return.
Несколько суток потратил на пробы, из них около половины потратил на поиски
ответа на задачу
Огромное спасибо!
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251323,251363#msg-251363
Максим, спасибо за ответ!
Действительно, таймер был увеличен ранее специально, правда решали не совсем
эту задачу.
На бэкенде обрабатывались продолжительные запросы, соединение держалось
открытым, поэтому все таймауты были увеличены. Постепенно с этой проблемой
разобрались, перевели долгие
Подсмотрели с коллегами у новелла
http://www.novell.com/support/kb/doc.php?id=7007165
Попробовали посмотреть изменение параметра с включенным tcpdump - счетчик не
растет.
Могли бы вы подсказать, какие еще есть средства диагрности и как можно
исправить данный показатель счетчика?
Posted at
Hello!
On Tue, Jul 01, 2014 at 02:36:19AM -0400, Давид Мзареулян wrote:
Вряд ли дело в этом: размер блока у меня 1 Кб, средний размер файлов во
втором кэше — около 100 Кб, файлов порядка полумиллиона. Так что погрешность
может быть не больше полугигабайта.
Бывают ещё:
- некорректный размер
Хм, кажется, это «сюрпризы». У меня XFS как раз.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251307,251375#msg-251375
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Правда, у меня не выставлен allocsize. Вот мои параметры, если это как-то
поможет в будущем победить баг:
$ mount -l
...
/dev/xvdf1 on /mnt1 type xfs (rw,noatime,nodiratime)
$ xfs_info /mnt1
meta-data=/dev/xvdf1 isize=256agcount=4, agsize=26214144
blks
=
Если после tcpdump счетчик не поднялся, то либо backlog надо увеличить +
проверить текущие параметры сетевых карт на frontend и backend и всех
свитчах по дороге, что везде full duplex и скорость сетевой карты равна
скорости порта на свитче, и нет никаких ошибок.
Как вариант, в логах Apache
Hello!
On Tue, Jul 01, 2014 at 08:10:29AM -0400, Давид Мзареулян wrote:
Правда, у меня не выставлен allocsize. Вот мои параметры, если это как-то
поможет в будущем победить баг:
По умолчанию allocsize, если верить интернетам, 64k, при типичном
размере ответа 100k - этого будет достаточно,
Виталий, спасибо за информацию! Попробуем настроить и понаблюдать.
Сейчас только обнаружил, что ошибся и возможно ввел заблуждение насчет
счетчиков.
Посмотрел показатели не на том адаптере (взял показатели для management
адаптера).
Вот такие показатели на основном
RX
Hello!
On Tue, Jul 01, 2014 at 09:13:47AM +0300, Sargas wrote:
Максим, а можно немного подробнее про нюансы с unix сокетами?
Например, одно время как минимум на двух разных операционных
системах были проблемы с sendfile()'ом через unix-сокеты, что
приводило к проблемам при отправке запросов
Здравствуйте, Andruxa.
Вы писали 1 июля 2014 г., 20:16:15:
Виталий, спасибо за информацию! Попробуем настроить и понаблюдать.
Сейчас только обнаружил, что ошибся и возможно ввел заблуждение насчет
счетчиков.
Посмотрел показатели не на том адаптере (взял показатели для management
Hello!
On Tue, Jul 01, 2014 at 05:30:03AM -0400, Andruxa wrote:
Максим, спасибо за ответ!
Действительно, таймер был увеличен ранее специально, правда решали не совсем
эту задачу.
На бэкенде обрабатывались продолжительные запросы, соединение держалось
открытым, поэтому все таймауты были
Благодарю, с подобным пока не сталкивался, но теперь буду знать куда
смотреть в случае подобной проблемы. Экспериментальный патч это Async
sendfile ?
1 июля 2014 г., 16:27 пользователь Maxim Dounin mdou...@mdounin.ru
написал:
Hello!
On Tue, Jul 01, 2014 at 09:13:47AM +0300, Sargas wrote:
Hello!
On Tue, Jul 01, 2014 at 07:39:25PM +0300, Sargas wrote:
Благодарю, с подобным пока не сталкивался, но теперь буду знать куда
смотреть в случае подобной проблемы. Экспериментальный патч это Async
sendfile ?
Да.
--
Maxim Dounin
http://nginx.org/
Добрый день! Подскажите пожалуйста, че-то не получается админку запустить
чтобы через SSL работает, браузер пишет циклическая переадресация постоянно,
в чем может быть причина ? Подкорректируйте конфигурацию пожалуйста
server {
server_name mysite.com www.mysite.com;
Думаю это может помочь:
http://kulmaks.by/работа-wordpress-на-nginx-apache-постоянный-301-редирект/
И SSL тут совсем не виноват.
1 июля 2014 г., 19:45 пользователь hitarcherru nginx-fo...@nginx.us
написал:
Добрый день! Подскажите пожалуйста, че-то не получается админку запустить
чтобы через
так что именно мне нужно в мой конфиг дописать или изменить ?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251401,251404#msg-251404
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
потому что без поддержки https:// все нормально работает
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251401,251406#msg-251406
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Вместо 2 и 3 location добавить:
location / {
index index.php index.html index.htm;
try_files $uri $uri/ @fallback;
}
location ~[^?]*/$ {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For
А можно глянуть конфиг апача? (Он же в качестве бэкэнда работает?)
01.07.2014 21:07 пользователь hitarcherru nginx-fo...@nginx.us написал:
потому что без поддержки https:// все нормально работает
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251401,251406#msg-251406
проправил, все равно не работает
server {
server_name xn8sbwecba5aajmm6f.xn--p1ai
www.xn8sbwecba5aajmm6f.xn--p1ai;
listen 78.108.92.172;
listen 78.108.92.172:443 ssl;
set $root_path
да пожалуйста
Directory /home/data/www/site.com
Options -ExecCGI -Includes
php_admin_value open_basedir /home/data:.
php_admin_flag engine on
/Directory
VirtualHost 192.168.1.100:81
ServerName site.com
AssignUserID user user
CustomLog
Предыдущее уточнение про работу с http было весомым и сейчас надо смотреть
в конфиг бэкэнда.
01.07.2014 21:30 пользователь hitarcherru nginx-fo...@nginx.us написал:
проправил, все равно не работает
server {
server_name xn8sbwecba5aajmm6f.xn--p1ai
ну че скажите ?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251401,251412#msg-251412
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Попробуйте добавить в конфиг апача строку:
SetEnvIf X-Forwarded-Proto https HTTPS=on
И почитайте, на всякий, http://habrahabr.ru/post/142363/
2014-07-01 21:42 GMT+03:00 hitarcherru nginx-fo...@nginx.us:
ну че скажите ?
Posted at Nginx Forum:
теперь появилось сообщение 500 Internal Server Error при запросе к https://
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251401,251414#msg-251414
___
nginx-ru mailing list
nginx-ru@nginx.org
wp-login.php?redirect_to=https%3A%2F%2Fsite.com%2Fwp-admin%2Freauth=1
ерунда в урле
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251401,251415#msg-251415
___
nginx-ru mailing list
nginx-ru@nginx.org
может еще что-то надо в .htaccess прописать ?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251401,251416#msg-251416
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
63 matches
Mail list logo
