NGINX: вихідний час вичерпано (110: Час з'єднання вичерпано) під час зчитування заголовка відповіді з висхідного потоку

У мене Puma працює як сервер додатків за течією, а Riak - мій фоновий кластер. Коли я надсилаю запит, що карта зменшує шматок даних приблизно для 25K користувачів і повертає його з Riak в додаток, я отримую помилку в журналі Nginx:

вихідний час вичерпано (110: Час з'єднання вичерпано) під час зчитування заголовка відповіді з висхідної лінії

Якщо я запитую свій прямий потік безпосередньо без проксі-сервера nginx, з тим же запитом я отримую необхідні дані.

Час очікування Nginx відбувається після введення проксі-сервера.

**nginx.conf**

http {
    keepalive_timeout 10m;
    proxy_connect_timeout  600s;
    proxy_send_timeout  600s;
    proxy_read_timeout  600s;
    fastcgi_send_timeout 600s;
    fastcgi_read_timeout 600s;
    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

  location / {
    # match the name of upstream directive which is defined above
    proxy_pass http://ss_api; 
    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;
  }
}

Nginx має купу директив про таймаут. Я не знаю, чи пропускаю щось важливе. Будь-яка допомога буде дуже вдячна ....

Це трапляється тому, що ваш верхній потік займає занадто багато часу, щоб відповісти на запит, і NGINX вважає, що висхідний потік вже не вдався при обробці запиту, тому він відповідає з помилкою. Просто включіть і збільшить proxy_read_timeout у locationконфігураційний блок. Зі мною трапилось те саме, і я використав 1 годину таймауту для внутрішнього додатка на роботі:

proxy_read_timeout 3600;

З цим NGINX чекатиме години (3600), щоб повернути щось вище.

Ви завжди повинні утримуватися від збільшення тайм-аутів, я сумніваюся, що ваш час відповіді сервера - це проблема в будь-якому випадку.

Я вирішив цю проблему, очистивши прапор збереження живого з'єднання та вказавши версію http відповідно до відповіді тут: https://stackoverflow.com/a/36589120/479632

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;
    }
}

На жаль, я не можу пояснити, чому це працює, і не вдалося розшифрувати це з документів, згаданих у відповіді, зв'язаних так, якщо у когось є пояснення, мені було б дуже цікаво почути це.

Спершу з’ясуйте, яка верхня течія сповільнюється, скориставшись файлом журналу помилок 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;
     ...
 }

Дивіться: оригінальний пост

У вашому випадку це допоможе трохи оптимізувати проксі, або ви можете використовувати "# налаштування тайм-ауту"

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;
}

Я думаю, що ця помилка може статися з різних причин, але вона може бути специфічною для модуля, який ви використовуєте. Наприклад, я бачив це за допомогою модуля uwsgi, тому довелося встановити "uwsgi_read_timeout".

Я б рекомендував поглянути на error_logs, зокрема, на верхню частину, де показано конкретний верхній потік, який закінчується.

Тоді виходячи з того, що ви можете налаштувати proxy_read_timeout, fastcgi_read_timeoutабо uwsgi_read_timeout.

Також переконайтеся, що ваша конфігурація завантажена.

Більше деталей тут вичерпано час виходу Nginx (чому і як виправити)

Як багато інших вказували тут, збільшення налаштувань тайм-ауту для NGINX може вирішити вашу проблему.

Однак збільшення налаштувань тайм-ауту може бути не таким простим, як багато з цих відповідей підказують. Я сам стикався з цією проблемою і намагався змінити налаштування тайм-ауту у файлі /etc/nginx/nginx.conf , як це пропонують майже всі в цих потоках . Це не допомогло мені жодного шматочка; явних змін у налаштуваннях часу очікування NGINX не було. Тепер, через багато годин, мені нарешті вдалося виправити цю проблему.

Рішення лежить у цій темі форуму , і в ньому йдеться про те, що слід встановити налаштування тайм-ауту в /etc/nginx/conf.d/timeout.conf (і якщо цього файлу не існує, його слід створити). Я використовував ті самі налаштування, що і в потоці:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

У мене була така ж проблема, і в результаті цього в контролері рейок сталася помилка "щодня". Я не знаю чому, але на виробництві Puma запускає помилку знову і знову, викликаючи повідомлення:

вихідний час вичерпано (110: Час з'єднання вичерпано) під час зчитування заголовка відповіді з висхідної лінії

Можливо, тому, що Nginx намагається отримувати дані з puma знову і знову. Смішним є те, що помилка спричинила повідомлення про час очікування, навіть якщо я викликаю іншу дію в контролері, тож один типовий блок блокує всю програму.

Перевірте свій файл log / puma.stderr.log, щоб побачити, чи така ситуація.

З нашої сторони він використовував шпіон з проксі-кешем. Коли кеш закінчується, ми отримуємо цю помилку, поки кеш не буде оновлений.

Сподіваємось, це комусь допомагає: я зіткнувся з цією помилкою, і причиною був неправильний дозвіл у папці журналу для phpfpm, змінивши її, щоб phpfpm міг писати до неї, все було добре.

Для proxy_upstream тайм-ауту я спробував вищевказані налаштування, але вони не спрацювали.

Налаштування resolver_timeoutпрацювало для мене, знаючи, що потрібно 30 років для створення повідомлення про час очікування. Наприклад, не вдалося вирішити проблему me.atwibble.com (110: Операція вичерпана) .

http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver_timeout