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;
}
}
``
$url = 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];`. Вот он целиком:
4. Финальный аккорд — сам i2p-proxy.php, который делает так:
<?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 она уже починена