proxy_pass http://host:port; и proxy_pass http://host:port/; — это две большие разницы. Во втором случае текущий location не будет дописан к uri

Прочитал тут: http://www.opennet.ru/opennews/art.shtml?num=41903 и возник вопрос, а зачем операции с файлами они выносят в отдельный пул потоков, если эти операции, так же как и работу с сокетами можно сделать неблокирующимися?

Боги нжинкса, а из-за чего может быть такая пепяка в error.log?

no live upstreams while connecting to upstream

Нет, не потому что я мудак, ибо:
1. Апстрим один, локальный, в tcpdump никаких попыток коннекта к нему нет
2. В лимит коннектов тоже не могли упереться, ибо за две секунды до этого обменялись FIN-ACK'ами c апстримом
3. Просто не хочется думать о плохом

В1. Вы настроили nginx кэшировать тело POST-запроса, но на любое тело отдаётся закэшированный результат от первого запроса?
О1. Вам нужно использовать $request_body в proxy_cache_key. Например, так: proxy_cache_key "$request_uri\n$request_body";

В2. На запросы с большим (десятки кб) телом вы получаете 500 Internal Server Error?
О2. Вам нужно задать временную директорию для сохранения тела запроса. Например, так: client_body_temp_path /tmp/nginx/body_temp_cache 1 2;

В3. Теперь на большие запросы с разным телом отдаётся закэшированный результат первого запроса?
О3. Вы можете прочитать историю целиком, но если в кратце, то если дело дошло до сохранения тела на диск, то в $request_body оказывается пустота. Зато в $request_body_file оказывается путь к файлу и такие запросы можно пустить в обход кэша: proxy_no_cache $request_body_file; Чтобы увеличить размер тела для которого кэширование будет выполняться, нужно поправить два параметра: client_body_buffer_size 64k; proxy_buffer_size 64k;

Кэшируйте и процветайте!

собираюсь на nginx включить кэширование POST-запросов (GET-запросы уже кэширую). В теле запроса будет пара килобайт json'а. кто-нибудь, расскажите мне какой я мудак и почему

Избавился от костылей для чтения rss из i2p. Добавил в nginx перенаправление всех запросов на 127.0.0.1:80 в похапэскрипт, который все i2p запросы заворачивает в i2p-проксю:

        server {
            listen 127.0.0.1;

            root /var/www/localhost/htdocs;

            rewrite ^(.*)$ /i2p-proxy.php break;

            location / {
                proxy_read_timeout 5m;
                include fastcgi.conf;
                fastcgi_index i2p-proxy.php;
                fastcgi_pass 127.0.0.1:9000;
            }
        }

Ну и прописал саму проксю в /var/www/localhost/htdocs/tt-rss/config.php:
define('_CURL_HTTP_PROXY', '127.0.0.1:80');

Теперь rss-фиды из i2p добавляются точно так же как фиды из большого интернета, и, при этом, грузятся фавиконки и всякое

объясните нубу, как избавиться от дубликации конфига тута вот:
```nginx
server {
listen 10.100.0.1;
server_name *.i2p;

        root /var/www/localhost/htdocs;

        rewrite ^(.*)$ /i2p-proxy.php break;

        location / {
            proxy_read_timeout 5m;
            include fastcgi.conf;
            fastcgi_index i2p-proxy.php;
            fastcgi_pass 127.0.0.1:9000;
        }
    }

    server {
        listen 127.0.0.1;

        root /var/www/localhost/htdocs;

        rewrite ^(.*)$ /i2p-proxy.php break;

        location / {
            proxy_read_timeout 5m;
            include fastcgi.conf;
            fastcgi_index i2p-proxy.php;
            fastcgi_pass 127.0.0.1:9000;
        }
    }

как видно, две секции отличаются только listen и наличием/отсутствием server_name

поделитесь кто-нибудь примером конфига nginx, который бы служил обычной кэширующей проксёй для хождения в интернеты, типа сквида. а то поднимать на одной машине и нжинкс и сквид не хочется, а нагуглить работающий конфиг у меня что-то не получается никак

очередной (костыль)[https://gist.github.com/hirthwork/f07b4a4d2a3245500b53], чтобы tt-rss на впске читал rss с i2p-сайтов. Приходится каждый раз править конфиг и добавлять в tt-rss новые фиды как http://127.0.0.1:82/rss20.xml, но хоть какое-то решение

Буду краток: теперь я с телефона открываю адреса вида http://tracker2.postman.i2p
Как этого добился:
1. С телефона коннекчусь к vpn на vps. Ключевой момент в конфиге openvpn это пробрасывание DNS на клиент:
push "dhcp-option DNS 10.100.0.1"
2. Далее делаем резолвинг i2p на этот же хост в конфиге dnsmasq:
address=/.i2p/10.100.0.1
3. Там же висит nginx с таким вот сервером (этот же nginx tt-rss обслуживает):
```
server {
listen 10.100.0.1;
server_name *.i2p;

root /var/www/localhost/htdocs;

rewrite ^(.*)$ /i2p-proxy.php break;

location / {
    include fastcgi.conf;
    fastcgi_index i2p-proxy.php;
    fastcgi_pass 127.0.0.1:9000;
}

}
``
4. Финальный аккорд — сам i2p-proxy.php, который делает так:$url = 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];`. Вот он целиком:

<?php
session_start();
ob_start();

$url = 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];

// Open the cURL session
$curlSession = curl_init();

curl_setopt($curlSession, CURLOPT_URL, $url);
curl_setopt($curlSession, CURLOPT_HEADER, 1);
curl_setopt($curlSession, CURLOPT_PROXY, '10.100.0.1:4444');
#curl_setopt($curlSession, CURLOPT_HTTPHEADER,
#    array('Host: ' . $_SERVER['HTTP_HOST']));


if($_SERVER['REQUEST_METHOD'] == 'POST'){
        $postinfo = '';
        foreach($_POST as $key=>$value) {
                $postinfo .= $key.'='.urlencode($value).'&';
        }
        rtrim($postinfo,'&');

        curl_setopt ($curlSession, CURLOPT_POST, 1);
        curl_setopt ($curlSession, CURLOPT_POSTFIELDS, $postinfo);
}

curl_setopt($curlSession, CURLOPT_RETURNTRANSFER,1);
curl_setopt($curlSession, CURLOPT_TIMEOUT,300);

//Send the request and store the result in an array
$response = curl_exec ($curlSession);

// Check that a connection was made
if (curl_error($curlSession)){
        // If it wasn't...
        print curl_error($curlSession);
} else {
        $ar = explode("\r\n\r\n", $response, 2);

        $header = $ar[0];
        $body = $ar[1];

        //handle headers - simply re-outputing them
        $header_ar = explode("\r\n",$header);
        foreach($header_ar as $header){
                $header = trim($header);
                if(!preg_match("/^Transfer-Encoding/",$header)){
                        header($header);
                }
        }

        print $body;
}

curl_close ($curlSession);
?>

Пока не знаю нахуя, но уже дважды кончил от собственной охуенности.

всё утро фиксишь багу в nginx-1.4.7 @ оказывается, что в nginx-1.6.0 она уже починена

Сычи, есть один сервер, который пишет HTTP-ответ в transfer chunked encoding, также есть один nginx, который делает proxy_cache над этим сервером. Всё заебись работает кроме того случая, когда сервер умирает во время записи ответа в сокет. Т.е. zero chunk не записывается, но при этом nginx считает этот ответ полным и сохраняет себе в кэш. Как сделать так чтобы nginx обрезанные ответы не сохранял и в следующий раз снова пошёл на сервер?

в сегодняшнем выпуске: статические сайты на nginx — производительность и упорство, кэширующая прокся поверх ssi — насколько вы задрачиваете производительность? дефолтная 404.html — тайное послание от Игоря Сысоева, какие тайны он решил нам открыть?