On Fri, Nov 29, 2013 at 04:59:24PM +, Matthew Ngaha wrote:
Hi there,
One of the best things you can learn about is your server error log.
Read that, and it should tell you why nginx thinks something failed,
every time.
> Location blocks. Is the idea here to have as many location blocks as
>
On Fri, Nov 29, 2013 at 05:44:41PM -0500, Todd@VRG wrote:
Hi there,
> nginx is forwarding traffic to webservers..
> proxy_set_header X-Forwarded-For $remote_addr;
> the ip address I still see in the logs is the eth0 = internal_ ip
Using tcpdump, or otherwise, watch the request going from nginx
Hi,
I have nginx reverse proxy setup on a ubuntu server to pass to webservers...
Setup..
Ubuntu-nginx
eth1 = external_ ip
eth0 = internal_ ip
Webserver 1 ip XX1
webserver 2 ip XX2
nginx is forwarding traffic to webservers..
I tried both..
proxy_set_header X-Forwarded-For $remote_addr;
Hi guys i'm very new to web dev, and getting started with nginx i just
wanted to ask a few things.
Location blocks. Is the idea here to have as many location blocks as
you have web pages? if a location has many files in it will nginx
search if the requested file is in that location? i put a file
"
Yes, you are absolutely right. Thanks again!
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Many thanks, works like a charm. The reason is Wrong location settings.
On Fri, Nov 29, 2013 at 5:02 PM, Maxim Dounin wrote:
> Hello!
>
> On Fri, Nov 29, 2013 at 04:59:56PM +0400, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Fri, Nov 29, 2013 at 03:36:18PM +0400, Oleg V. Khrustov wrote:
> >
>
Hello!
On Fri, Nov 29, 2013 at 03:50:52PM +0400, Oleg V. Khrustov wrote:
> nginx/1.5.4
> location / {
> ...
> fastcgi_pass bg;
> fastcgi_next_upstream off;
> ...
> }
>
> upstream bg {
>
> server unix:/tmp/dsp.1.sock;
> server unix:/tmp/dsp.2.sock;
> server unix:/tm
1) /etc/init.d/nginx configtest
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
It was definitely reloaded prior doing any tests.
2) I have a separate access log file for this specific (root) location
with custo
Hello!
On Fri, Nov 29, 2013 at 04:59:56PM +0400, Maxim Dounin wrote:
> Hello!
>
> On Fri, Nov 29, 2013 at 03:36:18PM +0400, Oleg V. Khrustov wrote:
>
> > nginx/1.5.4 doesnt intercept fastcgi errors.
> > location / {
> >
> > fastcgi_pass bg;
> > error_page 500 502 503 504 40
Hello!
On Fri, Nov 29, 2013 at 03:36:18PM +0400, Oleg V. Khrustov wrote:
> nginx/1.5.4 doesnt intercept fastcgi errors.
> location / {
>
> fastcgi_pass bg;
> error_page 500 502 503 504 408 404 =204 /204.htm;
> fastcgi_intercept_errors on;
>
> .
> }
>
> H
On 11/29/2013 10:13 AM, Maxim Dounin wrote:
> Connections are handled by worker processes. On SIGHUP, master
> process parses new configuration and spawns new worker processes
> (while old workers still handle requests). Then it asks old
> workers to gracefully shutdown. That is, all the time
Hello!
On Fri, Nov 29, 2013 at 09:12:39AM -0200, Andre Nathan wrote:
> Hello
>
> In an apache webserver with many virtual hosts, a "reload" command can
> cause a (quick) unavailability of the service while apache re-reads its
> configuration files.
>
> Does anyone have any experience with this
Hi and thank you for your help Francis ;)
I had already tested the IP resolver with Google DNS, but I just realized
that the firewall of the company blocked the DNS traffic !!! Also, my server
has a DNS entry (/etc/resolv.conf) so I do not understand why I had to add
this tag in nginx.
Anyway, wi
Hello,
Sometimes reading the documentation might help :
http://nginx.org/en/docs/control.html
If you look at your service file, you'll notice that a 'reload' means
sending SIGHUP to the master process for the particular case of nginx.
I'll leave the conclusion to you, assuming that the doc is cle
nginx/1.5.4
location / {
...
fastcgi_pass bg;
fastcgi_next_upstream off;
...
}
upstream bg {
server unix:/tmp/dsp.1.sock;
server unix:/tmp/dsp.2.sock;
server unix:/tmp/dsp.3.sock;
server unix:/tmp/dsp.4.sock;
server unix:/tmp/dsp.5.sock;
server unix:/tmp/
nginx/1.5.4 doesnt intercept fastcgi errors.
location / {
fastcgi_pass bg;
error_page 500 502 503 504 408 404 =204 /204.htm;
fastcgi_intercept_errors on;
.
}
However in root location access log we still see
91.192.148.232 - - [29/Nov/2013:13:39:20 +0400]
Hello
In an apache webserver with many virtual hosts, a "reload" command can
cause a (quick) unavailability of the service while apache re-reads its
configuration files.
Does anyone have any experience with this on Nginx? Will sending it a
SIGHUP cause the main process to block and not be able to
17 matches
Mail list logo