Strange error: nginx does not flush the buffer back to the client

Hi,

I’m completely new to nginx - I’ve just started using it a day ago, but
I’ve
managed to set up a reverse proxy szenario with nginx as a front end and
3
apache servers (2.0.63) as the backend servers.

*The strange thing that is happening is: sometimes the pages are not
displayed to the user, but it just freezes, i.e. the page is not
loading,
BUT when I kill the nginx process (the only connection to the outer
world)
all files from the current request (that was hanging) are served
immediately. It seems like the buffer is not written to the open
connection
and killing nginx causes nginx to release the connection and thus the
data
on it?!?!

Can anyone help solving the Gordic know as per why the data is not send,
but
the request hangs? Is nginx waiting for something before sending the
request
out? If so why and more importantly: can I turn this behavior off? *

The apache servers are listening on the following addresses:

  • 192.168.0.1:80 → web1
  • 192.168.0.2:80 → web2
  • 192.168.0.3:80 → web3

My public IP address is 69.64.147.249 and nginx is listening on web1 on
port
80. I have to match 4 different domains to consider:

I have defined 2 upstreams

**
The described problem occurs in versions nginx-0.7.38 and nginx-0.6.35.

Thanks so much for your help!

Bests,
Peter

This is my configuration:

##########

user nginx nginx;

worker_processes 1;

events {
worker_connections 1024;
}

http {
include mime.types;
default_type text/plain;

sendfile            on;

keepalive_timeout    65;

server_name_in_redirect off;

gzip                on;
gzip_min_length        1100;
gzip_types            text/plain text/html text/css

application/x-javascript text/xml application/xml application/xml+rss
text/javascript image/x-icon image/png;

upstream proxy1.example.com  {
    server 192.168.0.1:80;
}

upstream proxy2.example.com {
    server 192.168.0.1:80;
    server 192.168.0.2:80;
    server 192.168.0.3:80;
}

server {
    listen 69.64.147.249;
    server_name  www.example.com;
    rewrite ^(.*) http://example.com$1 permanent;
}

server {
    listen     69.64.147.249;
    server_name example.com app.example.com;;
    location / {
        access_log      off;
        proxy_pass http://proxy1.example.com;

        proxy_set_header               Host             $host;
        proxy_set_header               X-Real-IP 

$remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
}

server {
    listen     69.64.147.249;
    server_name *.app.example.com;
    location / {
        access_log      off;
        proxy_pass http://proxy2.example.com;

        gzip off;
        proxy_set_header               Host             $host;
        proxy_set_header               X-Real-IP 

$remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;

        proxy_buffering               on;
        proxy_buffer_size            4k;
        proxy_buffers                4 32k;
        proxy_busy_buffers_size        64k;
        proxy_temp_file_write_size     64k;
    }
}

server {
    listen          69.64.147.249;
    server_name     static.example.com;
    access_log      logs/access.www.example.com.log;

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    location ~ /\.ht {
        deny  all;
    }
}

}

##########

I would be sure to check the error logs (for nginx, apache, and maybe
the
system too), because this does not seem at all like normal behavior. If
you
find something in the error logs, you should provide that. If you
can’t,
you might try more hardcore debugging and provide an strace or
something.

On Mon, Feb 23, 2009 at 9:24 PM, Peter Langhans <