VBart

Используйте X-Accel-Redirect.

server {
    server_name ~^www\.(.+)\.example\.com$;
    return 301 $1.example.com/$request_uri;
}

Ну вот, сами донастраивались:
Ваш putit.ru:

upstream putit {
    # Адрес back-end'a
    server putit.ru:8080;
}

server {
    listen 80;
    server_name www.putit.ru putit.ru;

    access_log /home/username/domains/putit.ru/logs/nginx_access.log;
    error_log /home/username/domains/putit.ru/logs/nginx_error.log;

    # Перенаправление на back-end
    location / {
         proxy_pass backend;
         include /etc/nginx/proxy.conf;
    }

    ....
}

Ваш proxy.conf:

proxy_redirect 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_buffer_size 16k;
proxy_buffers 16 16k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

В свое время выбирал между exim и postfix. Остановился на exim и ни разу с тех пор не пожалел. Очень стабильный. Конфигурационный синтаксис легко читается, но в то же время настолько гибкий, что можно буквально запрограммировать в конфигурации всё что угодно. Для почтового сервера это достаточно важно, так у меня 85% спама срезается только лишь с помощью мощной системы всевозможных правил и проверок. А авторизация пользователей происходит запросом к PostgreSQL таблице, которую использует и Dovecot, таким образом получается полная интеграция между MTA-LDA и всё очень удобно прописывается из одного места. Доставляет мгновенно, кушает при этом мало, так что я бы назвал его прямым аналогом nginx. Есть модуль Яндекс спам-обороны, а также прекрасно интегрируется с ClamAV из коробки. DKIM, SPF — само собой. Имеется исчерпывающая документация и Wiki с примерами: exim.org/docs.html wiki.exim.org

Конфиг nginx будет выглядеть примерно так:

    server {
        server_name ~^(?<company>.+)\.site\.ru$;

        location / {
            try_files /path/to/static/media @django;
        }

        location @django {
            fastcgi_pass unix:/tmp/site.django.socket;

            fastcgi_param PATH_INFO /$company$uri;
            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param QUERY_STRING $query_string;
            fastcgi_param CONTENT_TYPE $content_type;
            fastcgi_param CONTENT_LENGTH $content_length;
            fastcgi_param REMOTE_ADDR $remote_addr;
        }
    }

Но вам следует иметь ввиду, что django при этом должна знать, как генерировать правильные ссылки. Т.е. вместо /company1/menu/item она должна будет создавать ссылку /menu/item.

Есть ещё, как минимум, SCGI и uwsgi, но сменить FastCGI они не грозят.

Кажется вы переизобрели велосипед, только я не очень понял какой, то ли php-fpm, то ли CppCMS.

Это называется cache lock:
nginx.org/r/proxy_cache_lock/ru
nginx.org/r/fastcgi_cache_lock/ru
etc…

Установив Content-Type: application/octet-stream вы лишь лишили клиента возможности распознать тип файла по заголовкам. В некоторых браузерах это приводит к загрузке файла.

Чтобы файлы скачивались нужно использовать заголовок Content-Disposition с параметром attachment. Портить же Content-Type не стоит, ибо вы тем самым мешаете браузеру предложить пользователю открыть файл сразу после загрузки в нужной программе.

tools.ietf.org/html/rfc6266