Antony Gibbs's questions

Base on what I could read on nginx site https://www.nginx.com/blog/websocket-nginx/

The exemple they give will close all connections to backend. This isn't really what we want on a proxy setup, forcing to reopen a connection to backend on each new client.

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }
 
    upstream websocket {
        server 192.168.100.10:8010;
    }
 
    server {
        listen 8020;
        location / {
            proxy_pass http://websocket;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $host;
        }
    }
}

But is it required to close the connection after upgrading to a websocket?

can't we change the map so it maintains the 'keepalive' connection to the backend ? (for all non websocket requests)

    map $http_upgrade $connection_upgrade {
        default upgrade;
#       ''      close;
        ''      '';
    }

Being the only user on a test environment it didn't seem to create any issues, but will it be the same in production?

I have a setup with nginx proxy (ssl) to varnish (5.2) to apache on a debian linux.

varnish passing response without buffering to nginx (not buffering either)

sub vcl_backend_response {
  if ( std.integer(beresp.http.Content-Length, 0) > 10000 ) {
    set beresp.do_stream = true;
  }
}

If one downloads a big file (Ex: 8G), download start instantly (so stream seams to work) but varnish ram usage keeps growing.

Seems like varnish pulls form apache as fast as possible (faster then the output to the outer world) and steals all the ram needed.

If I get nginx to proxy directly to apache I don't have this issue.

Is there a way to tell varnish to limit it's buffering in this case?

Am I missing out something?

UPDATE

$ curl -i https://example.com/test.dmg | head

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 05 Jan 2019 21:26:43 GMT
Content-Type: application/x-apple-diskimage
Content-Length: 8743924593
Connection: keep-alive
Last-Modified: Wed, 28 May 2014 16:18:56 GMT
Accept-Ranges: bytes
Age: 0
X-Cache: MISS
Strict-Transport-Security: max-age=15768000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block

So on this graph, can someone explain why the red line (writing connections) could go above the green line (active connections)?

Isn't the "active connections" the sum of Reading + Writing + Waiting ?

Here using nginx 1.12.2 nginx-stable-trusty from launchpad (Ubuntu 14.04)

deb http://ppa.launchpad.net/nginx/stable/ubuntu trusty main

Edit 1:

The graph reflects the figures returned by nginx status

Active connections: 215
server accepts handled requests
218305659 218305659 919815892
Reading: 0 Writing: 230 Waiting: 36

I've been fighting with configuring Nginx as a reverse proxy. I've got most of the mechanics working, but I've been fighting for the last 3 days to control cache headers and being newbie to nginx this is driving me crazy...

It looks like I'm not getting how location block chain up.

I would really appreciate a bit of help

What I would like is simple

• all content-type text/html to have header Cache-Control: max-age=60, public, must-revalidate
• all css/js/images etc... to have header Cache-Control: max-age=315360000, public
• 404 and all errors not to have cache control

Thanks for any advice on how this should be done.

here I have the proxy settings (seems to work as expected)

proxy_cache_path /tmp/example levels=1:2 keys_zone=example:100m max_size=4g inactive=60m;
proxy_temp_path /tmp/example/tmp;

server {
  listen 80;
  server_name example.com;

  # is this realy needed?
  # Perhaps it should point to an empty folder
  root /var/www/vhosts/example.com/www;

  location ~ /\. {
    deny all;
  }

  location ~ /purge(/.*) {
    proxy_cache_purge nx_anto "$scheme$request_method$host$1";
  }

  location / {

    proxy_cache example;
    proxy_cache_key "$scheme$request_method$host$request_uri";
    proxy_connect_timeout 60s;

    proxy_cache_methods GET HEAD;

    # don't honour cache headers from the app server
    # proxy_ignore_headers Cache-Control Set-Cookie Expires Cache-Control;

    proxy_cache_lock on;
    # proxy_cache_min_uses 3;

    # proxy_cache_valid 301       24h;
    # keep objects long enough for proxy_cache_use_stale
    proxy_cache_valid 200 302     1h;    
    # 404 errors
    proxy_cache_valid any       5m;


    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;

    # to pass If-Modified-Since to the origin server
    # proxy_cache_revalidate on;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # hide cache-related headers
    proxy_hide_header X-Powered-By;

    # this avoids having duplicate Vary headers sent to final client.
    proxy_hide_header Vary;
    # proxy_hide_header Pragma;
    # proxy_hide_header Expires;
    # proxy_hide_header Last-Modified;
    # proxy_hide_header Cache-Control;
    # proxy_hide_header Set-Cookie;

    set $skip_cache 0;
    # POST requests and urls with a query string should always go to PHP
    if ($request_method = POST) {
      set $skip_cache 1;
    }
    # wordpress adds query strings to css and js that we want to cache
    #   if ($query_string != "") {
    #     set $skip_cache 1;
    #   }

    # Don't cache uris containing the following segments
    if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
        set $skip_cache 1;
    }

    # Don't use the cache for logged in users or recent commenters
    # if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
    # wordpress_[a-f0-9]+ was blocking cache on loged out users
    if ($http_cookie ~* "comment_author|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
        set $skip_cache 1;
    }

    proxy_cache_bypass $skip_cache;
    proxy_no_cache $skip_cache;

    # for debugging
    add_header "X-Cache-Status" $upstream_cache_status;
    add_header "X-Dummy" $sent_http_content_type;

    proxy_pass http://example.com:8080;
  }

}

now comes the app vhost

server {
  listen 8080;
  server_name example.com;
  root /var/www/vhosts/example.com/www;

  index index.php;

  server_tokens off;
  etag off;

  location / {
    try_files $uri $uri/ /index.php?$args;
  }

  location ~ .php$ {

    include fastcgi_params;
    fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php5.6-fpm_example.sock;
    access_log /var/log/nginx/phpfpmonly-access-example.log;

    try_files $uri /index.php =404;

## I never got this condition to work
#     if ($sent_http_content_type ~* "text/html") {
#      add_header "Cache-Control" "public, must-revalidate, proxy-revalidate";
#      expires 60s;
#     }
  }
}

now I would like to control headers for css/js etc...

location ~* \.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom||zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|css|js|ico|gif|jpe?g|png|svg|eot|otf|woff|woff2|ttf|ogg) {
  expires max;
  add_header Cache-Control "public";
}

I've tried putting this location block in any server block (proxy or app) and never got what I wanted. Placed in the app server block this break php (returning me php source code)

I have a server with multiple interface alias running debian. lets say eth0 eth0:0 and eth0:1

I'm looking for a simple solution, when connecting to host 1.2.3.4 (or host range, would be better) that I could enforce using ip address of eth0:1 (and not eth0 as it does by default) to access some external services that are open to only that ip on eth0:1 (eth0:1 is a ovh 'failover ip', it can be moved to a different server during maintenance tasks).