we have used Nginx 1.4.x (the “extras”, full featured package) for a
year
with no major troubles. Only some relatively rare error 403 we can’t
find
the source of, it only happens when our XEN VPS (Ubuntu 12.04 LTS) is
under
(other sharing customers) load and our website is itself under high
load.
I have upgraded to 1.6, the (Ondrej PPA). I had to downgrade to 1.4.7
VERY
fast because error 403 (access forbidden) were literally spammed every
other
page just with a smidge of load.
The same content shows not a single error is used under light load so
it’s
not a basic “wrong permissions” or similar issue.
I’d love if somebody could give me pointers about how to find out the
real
source of those errors 403. I can’t replicate the issue on a basic
“mule”
computer, our setup uses a lot of features including varnish 3, GeoIP
both
at Nginx and PHP-fpm levels and so on.
The odd thing is, version 1.4.7 very seldom shows that spurious error,
whereas to 1.6 it is a showstopper. To worsen things, sometimes varnish
caches those 403 pages so unrelated users start seeing those errors as
well.
I think the issue might be caused by too small buffers or something. The
config file is massively huge so I don’t know if it’s a good idea to
post it
(nobody would care to read it all).
So I am just looking for pointers and ideas about how to pinpoint the
problem source.
It is probably your application / backend that is generating the 403,
it’s
unlikely nginx is responsible for this. I guess rate / connection
limiting
with a custom error code may cause this, but you should know if you
configured this. Please show us your config and describe your backend in
more detail.
Your config is returning a 403 from any referrer containing “love” any
you
have such URLs on your own site according to your log excerpt. I would
not
recommend such referrer matching, it’s unlikely to help in any case.
The apps are several, they all follow the “index.php is the controller”
paradygm.
# Make sure files with the following extensions do not get
loaded by
nginx because nginx would display the source code, and these files can
contain PASSWORDS!
location ~*
.(engine|inc|ini|info|install|make|module|profile|test|po|sh|.sql|theme|tpl(.php)?|xtmpl)$|^(..|Entries.*|Repository|Root|Tag|Template)$|.php_
{
deny all;
}
location ~ /config.php {
deny all;
}
It’s not the UFW firewall as well, because the error shows up even with
UFW
disabled. So the potential culprit may be php-fpm or some weird nginx
option. Here’s the master conf file, the others don’t specify anything
but
location
Thank you so much. I am pretty sure the 403 comes from another source as
well (as it does not happen under light http server load) but the ‘love’
regex was really a good show of having a nice hawk eye from yours
For future reference:
empyrical observation seems to show that 1.6 is a bit heavier than
1.4.7.
I have raised some php-fpm.conf daemon settings and timeouts and the
situation improved: