NGINX: тайм-аут восходящего потока (110: время ожидания соединения) при чтении заголовка ответа от восходящего потока
У меня есть Puma, работающая как сервер приложений вверх и Riak в качестве моего фона db-кластера. Когда я отправляю запрос, который преобразует карту, уменьшает кусок данных для примерно 25 тыс. Пользователей и возвращает его из приложения Riak в приложение, я получаю сообщение об ошибке в журнале Nginx:
тайм-аут вверх (110: время ожидания подключения) при чтении ответный заголовок вверх по течению
Если я запрошу свой upstream напрямую без прокси nginx, с тем же запросом, я получу необходимые данные.
Тайм-аут Nginx возникает после ввода прокси.
**nginx.conf**
user www-data;
worker_processes 2;
pid /var/run/nginx.pid;
events {
worker_connections 4000;
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 10m;
proxy_connect_timeout 600s;
proxy_send_timeout 600s;
proxy_read_timeout 600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;
types_hash_max_size 2048;
proxy_cache_path /opt/cloud/cache levels=1 keys_zone=cloud:10m;
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
gzip on;
gzip_disable "msie6";
include /etc/nginx/sites-enabled/*.conf;
}
**virtual host conf**
upstream ss_api {
server 127.0.0.1:3000 max_fails=0 fail_timeout=600;
}
server {
listen 81;
server_name xxxxx.com; # change to match your URL
if ($http_x_forwarded_proto != 'https') {
return 301 https://$server_name$request_uri;
}
location / {
proxy_pass http://ss_api; # match the name of upstream directive which is defined above
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache cloud;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
proxy_cache_bypass $http_authorization;
proxy_cache_bypass http://ss_api/account/;
add_header X-Cache-Status $upstream_cache_status;
}
location ~ /\. { deny all; }
}
Nginx имеет множество директив тайм-аута. Я не знаю, не хватает ли я чего-то важного. Любая помощь будет высоко оценена....
Ответы
Ответ 1
Вы всегда должны воздерживаться от увеличения тайм-аутов, я сомневаюсь, что ваше время отклика на серверный сервер является проблемой здесь в любом случае.
Я обошел эту проблему, очистив флаг keep-alive подключения и указав http-версию в соответствии с ответом здесь:
fooobar.com/questions/117490/...
server {
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
# these two lines here
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://localhost:5000;
}
}
К сожалению, я не могу объяснить, почему это работает, и не удалось расшифровать его из документов, упомянутых в ответе, связанных, так что, если у кого есть объяснение, мне было бы очень интересно его услышать.
Ответ 2
В вашем случае это помогает немного оптимизировать прокси-сервер, или вы можете использовать "# тайм-аут"
location /
{
# time out settings
proxy_connect_timeout 159s;
proxy_send_timeout 600;
proxy_read_timeout 600;
proxy_buffer_size 64k;
proxy_buffers 16 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_pass_header Set-Cookie;
proxy_redirect off;
proxy_hide_header Vary;
proxy_set_header Accept-Encoding '';
proxy_ignore_headers Cache-Control Expires;
proxy_set_header Referer $http_referer;
proxy_set_header Host $host;
proxy_set_header Cookie $http_cookie;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Ответ 3
Я думаю, что эта ошибка может произойти по разным причинам, но она может быть специфичной для используемого вами модуля. Например, я видел это с помощью модуля uwsgi, поэтому пришлось установить "uwsgi_read_timeout".
Ответ 4
Я бы порекомендовал посмотреть на error_logs, в частности, на восходящей части, где он показывает определенный выход, который отключен.
Затем на основе этого вы можете настроить proxy_read_timeout fastcgi_read_timeout или uwsgi_read_timeout.
Также убедитесь, что ваша конфигурация загружена.
Подробнее здесь Nginx upstream тайм-аут (почему и как исправить)
Ответ 5
Сначала выясните, какой вверх по потоку замедляется, консультируясь с журналом ошибок nginx
файла и отрегулируйте время чтения
в моем случае это был fastCGI
2017/09/27 13:34:03 [error] 16559#16559: *14381 upstream timed out (110: Connection timed out) while reading response header from upstream, client:xxxxxxxxxxxxxxxxxxxxxxxxx", upstream: "fastcgi://unix:/var/run/php/php5.6-fpm.sock", host: "xxxxxxxxxxxxxxx", referrer: "xxxxxxxxxxxxxxxxxxxx"
Поэтому мне нужно настроить fastcgi_read_timeout в конфигурации моего сервера
.........................
location ~ \.php$ {
fastcgi_read_timeout 240;
............
}
................................
Смотрите: оригинальное сообщение
Ответ 6
Возможно, стоит посмотреть http://howtounix.info/howto/110-connection-timed-out-error-in-nginx (он помещает proxy_read_timeout в блок location
Ответ 7
Это происходит потому, что ваш восходящий поток слишком сильно реагирует на запрос, и NGINX считает, что восходящий поток уже не прошел обработку запроса, поэтому он отвечает на ошибку.
Просто включите и увеличьте proxy_read_timeout в местоположении.
То же самое произошло со мной, и я использовал тайм-аут 1 часа для внутреннего приложения на работе:
proxy_read_timeout 3600;
При этом NGINX будет ждать часа, пока его восходящий поток ничего не вернет.
Ответ 8
С нашей стороны он использовал spdy с прокси-кешем. Когда кеш истекает, мы получаем эту ошибку до тех пор, пока кеш не будет обновлен.
Ответ 9
У меня была такая же проблема, и это привело к ошибке "каждый день" в контроллере rails. Я не знаю почему, но при производстве puma снова и снова вызывает ошибку:
тайм-аут upstream (110: время ожидания соединения) при чтении заголовка ответа вверх по течению
Вероятно, потому что Nginx пытается получить данные из puma снова и снова. Самое смешное, что ошибка вызвала сообщение о тайм-ауте, даже если я вызываю другое действие в контроллере, поэтому одна опечатка блокирует все приложение,
Проверьте файл журнала /puma.stderr.log, чтобы убедиться, что это так.
