I have Puma running as the upstream app server and Riak as my background db cluster. When I send a request that map-reduces a chunk of data for about 25K users and returns it from Riak to the app, I get an error in the Nginx log:
upstream timed out (110: Connection timed out) while reading
response header from upstream
If I query my upstream directly without nginx proxy, with the same request, I get the required data.
The Nginx timeout occurs once the proxy is put in.
**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 has a bunch of timeout directives. I don’t know if I’m missing something important. Any help would be highly appreciated….
bschlueter
3,7981 gold badge30 silver badges48 bronze badges
asked Sep 11, 2013 at 12:01
1
This happens because your upstream takes too long to answer the request and NGINX thinks the upstream already failed in processing the request, so it responds with an error.
Just include and increase proxy_read_timeout in location config block.
Same thing happened to me and I used 1 hour timeout for an internal app at work:
proxy_read_timeout 3600;
With this, NGINX will wait for an hour (3600s) for its upstream to return something.
answered Sep 13, 2017 at 19:51
Sergio GonzalezSergio Gonzalez
1,7021 gold badge11 silver badges12 bronze badges
3
You should always refrain from increasing the timeouts, I doubt your backend server response time is the issue here in any case.
I got around this issue by clearing the connection keep-alive flag and specifying http version as per the answer here:
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;
}
}
Unfortunately I can’t explain why this works and didn’t manage to decipher it from the docs mentioned in the answer linked either so if anyone has an explanation I’d be very interested to hear it.
answered Apr 13, 2016 at 5:17
AlmundAlmund
5,5483 gold badges30 silver badges35 bronze badges
13
First figure out which upstream is slowing by consulting the nginx error log
file and adjust the read time out accordingly
in my case it was 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"
So i have to adjust the fastcgi_read_timeout in my server configuration
location ~ .php$ {
fastcgi_read_timeout 240;
...
}
See: original post
Finwe
6,2452 gold badges28 silver badges44 bronze badges
answered Sep 27, 2017 at 14:19
2
In your case it helps a little optimization in proxy, or you can use «# time out settings»
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;
}
answered Dec 19, 2013 at 10:13
DimitriosDimitrios
1,13311 silver badges10 bronze badges
4
I would recommend to look at the error_logs, specifically at the upstream part where it shows specific upstream that is timing out.
Then based on that you can adjust proxy_read_timeout, fastcgi_read_timeout or uwsgi_read_timeout.
Also make sure your config is loaded.
More details here Nginx upstream timed out (why and how to fix)
Eje
3544 silver badges8 bronze badges
answered Apr 22, 2017 at 17:36
gansbrestgansbrest
7591 gold badge8 silver badges11 bronze badges
1
I think this error can happen for various reasons, but it can be specific to the module you’re using. For example I saw this using the uwsgi module, so had to set «uwsgi_read_timeout».
answered Oct 10, 2013 at 10:50
RichardRichard
1,78316 silver badges17 bronze badges
1
As many others have pointed out here, increasing the timeout settings for NGINX can solve your issue.
However, increasing your timeout settings might not be as straightforward as many of these answers suggest. I myself faced this issue and tried to change my timeout settings in the /etc/nginx/nginx.conf file, as almost everyone in these threads suggest. This did not help me a single bit; there was no apparent change in NGINX’ timeout settings. Now, many hours later, I finally managed to fix this problem.
The solution lies in this forum thread, and what it says is that you should put your timeout settings in /etc/nginx/conf.d/timeout.conf (and if this file doesn’t exist, you should create it). I used the same settings as suggested in the thread:
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
answered Feb 9, 2019 at 9:54
Please also check the keepalive_timeout of the upstream server.
I got a similar issue: random 502, with Connection reset by peer errors in nginx logs, happening when server was on heavy load. Eventually found it was caused by a mismatch between nginx’ and upstream’s (gunicorn in my case) keepalive_timeout values. Nginx was at 75s and upstream only a few seconds. This caused upstream to sometimes fall in timeout and drop the connection, while nginx didn’t understand why.
Raising the upstream server value to match nginx’ one solved the issue.
answered Jul 9, 2021 at 15:29
Eino GourdinEino Gourdin
4,0492 gold badges38 silver badges66 bronze badges
If you’re using an AWS EC2 instance running Linux like I am you may also need to restart Nginx for the changes to take effect after adding proxy_read_timeout 3600; to etc/nginx/nginx.conf, I did: sudo systemctl restart nginx
answered Jul 15, 2022 at 18:17
AmonAmon
2,6635 gold badges29 silver badges52 bronze badges
I had the same problem and resulted that was an «every day» error in the rails controller. I don’t know why, but on production, puma runs the error again and again causing the message:
upstream timed out (110: Connection timed out) while reading response header from upstream
Probably because Nginx tries to get the data from puma again and again.The funny thing is that the error caused the timeout message even if I’m calling a different action in the controller, so, a single typo blocks all the app.
Check your log/puma.stderr.log file to see if that is the situation.
answered Dec 26, 2016 at 19:28
aarkerioaarkerio
2,1452 gold badges20 silver badges34 bronze badges
Hopefully it helps someone:
I ran into this error and the cause was wrong permission on the log folder for phpfpm, after changing it so phpfpm could write to it, everything was fine.
answered Jan 3, 2019 at 1:08
From our side it was using spdy with proxy cache. When the cache expires we get this error till the cache has been updated.
answered Jun 18, 2014 at 21:26
timhaaktimhaak
2,4032 gold badges13 silver badges7 bronze badges
For proxy_upstream timeout, I tried the above setting but these didn’t work.
Setting resolver_timeout worked for me, knowing it was taking 30s to produce the upstream timeout message. E.g. me.atwibble.com could not be resolved (110: Operation timed out).
http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver_timeout
Eje
3544 silver badges8 bronze badges
answered Nov 25, 2019 at 13:44
we faced issue while saving content (customt content type) giving timeout error. Fixed this by adding all above timeouts, http client config to 600s and increasing memory for php process to 3gb.
answered Dec 10, 2021 at 5:44
1
I test proxy_read_timeout 100s and find timeout 100s in access log,set 210s appeared,so you can set 600s or long with your web.
proxy_read_timeout
accesslog
answered Mar 10 at 5:17
If you are using wsl2 on windows 10, check your version by this command:
wsl -l -v
you should see 2 under the version.
if you don’t, you need to install wsl_update_x64.
Dijkgraaf
10.9k17 gold badges39 silver badges53 bronze badges
answered Jan 22, 2022 at 6:25
new add a line config to location or nginx.conf, for example:
proxy_read_timeout 900s;
answered Mar 19, 2021 at 10:57
1
upstream timed out 101 — ошибка, которая возникает при превышении лимита ожидания выполнения скрипта веб-сервером. Часто при таймауте соединения клиент будет видеть 504 ошибку.
upstream timed out 110 connection timed out в Nginx
В логах ошибки будут выглядеть так:
grep ‘upstream timed out’ /var/log/nginx/error.log
2018/08/13 17:01:03 [error] 32147#32147: *1197966 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 123.123.123.123, server: example.com, request: «POST /api.php/shop.product.update?id=3268 HTTP/1.1», upstream: «fastcgi://unix:/var/run/php7.0-example.sock», host: «example.com»
Если такие записи появляются прежде всего нужно установить причины.
Возможны два варианта:
- код так работать не должен — ждет ответа от какого-то недоступного ресурса или базы
- длительное выполнение нормально в данной ситуации
В первом случае нужно проводить диагностику, искать и устранять причины.
Во втором случае достаточно увеличить лимиты. Обычно так приходится делать в случае с выгрузками товаров на сайт, которые могут выполняться в течение нескольких часов.
Параметры значения которых нужно править зависят от сервиса, который используется на бэкенде. Это тот сервис, в который проксирует запросы Nginx и который обрабатывает скрипты.
В случае с PHP таких сервиса может быть два: PHP-FPM и Apache.
Как исправить ошибку если используется PHP-FPM
Про связку Nginx + PHP-FPM можно найти информацию в статье по ссылке
Если скрипты выполняет fpm — меняется значение параметра fastcgi_read_timeout 400; (о директиве в документации Nginx)
Значение в секундах можно значительно увеличивать, обычно достаточно 400.
location / {
index index.php;
try_files $uri $uri/ =404;
fastcgi_connect_timeout 20;
fastcgi_send_timeout 120;
fastcgi_read_timeout 400;
}
Лимит может превышаться при длительном выполнении PHP скриптов.
Как исправить ошибку если используется Apache
Материал про данную конфигурацию доступен по ссылке.
При проксировании требуется добавить директиву proxy_read_timeout 150;
Значение также как в первом случае задается в секундах и означает лимит времени между операциями чтения.
location / {
index index.php;
try_files $uri $uri/ =404;
proxy_read_timeout 150;
…
}
После изменения конфигурации веб-сервер требуется её перечитать командой nginx -s reload. После этого процесс увидит и начнет использовать новые параметры и значения.
Периодически появляются ошибки «upstream timed out (110: Connection timed out) while connecting to upstream», особенно когда какой нибудь бот индексирует страницы. Понятно, что это означает, что сервер вовремя не вернул результат. Но сами страницы отдаются очень быстро, на них нету slow queries, да и сервер особо не нагружен. Что ещё может вызывать такие ошибки? Куда можно копать?
-
Вопрос заданболее трёх лет назад
-
5201 просмотр
Пригласить эксперта
Варианты:
1) на бекенде к которому обращается nginx кончаются коннекты
2) На сервере кончаются дескрипторы
Как обычно информации мало, в проблеме так не разобраться.
Как правило ошибка лечится увеличением
proxy_read_timeout 300s;
еще посмотрите вот эти директивы:
proxy_connect_timeout 300s;
proxy_send_timeout 300s;
Они все по дефолту 60 сек
+ если у вас php-fpm, могут быть
fastcgi_send_timeout
fastcgi_read_timeout
Смотрите всё, тестируйте, проверяйте
-
Показать ещё
Загружается…
Сбер
•
Нижний Новгород
от 170 500 ₽
05 июн. 2023, в 23:42
300 руб./за проект
05 июн. 2023, в 23:25
25000 руб./за проект
05 июн. 2023, в 22:21
1500 руб./за проект
Минуточку внимания
Исправление ошибки “Upstream timed out (110: Connection timed out)”, из-за долгого ответа сервера.
[error] upstream timed out (110: Connection timed out) while reading response header from upstream,
client: xxx.xxx.xxx.xxx, server: mydomain.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080", host: "mydomain.com", referrer: "requested_url"
Вносим изменения в конфигурационный файл nginx.conf в директиву proxy_read_timeout, а именно — увеличим значение при котором сервер будет ожидать ответа на запрос. По умолчанию 60 секунд, мы выставим — 300 секунд.
server {
listen 80;
server_name mydomain.com;
location / {
...
proxy_read_timeout 300;
...
}
...
}
Это решит возникшую проблему.
Thank you for reading this post, don’t forget to subscribe!
ошибка upstream timed out (110: Connection timed out) может возникать в двух случаях. Причем название самой ошибки указывает на решение — необходимо увеличить время ожидания в настройках веб-сервера.
Nginx в качестве proxy или reverse proxy
В этом случае ошибка может возникать, если истекло время ожидания на чтение ответа от прокси-сервера.
То есть Nginx отправил запрос и не дождался ответа. Если вы уверены, что ваше веб-приложение работает корректно, то необходимо увеличить этот таймаут в файле конфигурации nginx.conf в секции locatio
[codesyntax lang=»php»]
|
location / { ... proxy_send_timeout 150; proxy_read_timeout 150; ... } |
[/codesyntax]
Установка времени ожидания на отправку и чтение ответа, в секундах
Nginx с подключенными FastCGI-серверами
В этом случае ошибка возникает, если истекло время ожидания на чтение ответа от подключенных сервисов или приложений, PHP-FPM, к примеру.
Решение такое же банальное, как и в первом случае — необходимо увеличить время ожидания:
[codesyntax lang=»php»]
|
location ~* .php$ { include fastcgi_params; ... fastcgi_read_timeout 150; ... } |
[/codesyntax]
Самое главное
Прежде чем увеличить время ожидания, которое в данном случае по умолчанию составляет 60 с, следует проверить работоспособность всех компонентов и модулей. Если же все работает как нужно, то увеличение таймаута будет самым простым решением проблемы.
https://github.com/midnight47/
Практика показывает, что ошибка upstream timed out (110: Connection timed out) может возникать в двух случаях. Причем название самой ошибки указывает на решение — необходимо увеличить время ожидания в настройках веб-сервера.
Nginx в качестве proxy или reverse proxy
В этом случае ошибка может возникать, если истекло время ожидания на чтение ответа от прокси-сервера.
То есть Nginx отправил запрос и не дождался ответа. Если вы уверены, что ваше веб-приложение работает корректно, то необходимо увеличить этот таймаут в файле конфигурации nginx.conf в секции location:
location / {
...
proxy_send_timeout 150;
proxy_read_timeout 150;
...
}
Установка времени ожидания на отправку и чтение ответа, в секундах.
Nginx с подключенными FastCGI-серверами
В этом случае ошибка возникает, если истекло время ожидания на чтение ответа от подключенных сервисов или приложений, PHP-FPM, к примеру.
Решение такое же банальное, как и в первом случае — необходимо увелчить время ожидания:
location ~* .php$ {
include fastcgi_params;
...
fastcgi_read_timeout 150;
...
}
Время ожидания на чтение ответа, в секундах.
Прежде чем увеличить время ожидания, которое в данном случае по умолчанию составляет 60 с, следует проверить работоспособность всех компонентов и модулей. Если же все работает как нужно, то увеличение таймаута будет самым простым решением проблемы.
Our experts have had an average response time of 9.78 minutes in Apr 2023 to fix urgent issues.
We will keep your servers stable, secure, and fast at all times for one fixed price.
Nginx “upstream timeout (110: Connection timed out)” error appears when nginx is not able to receive an answer from the webserver.
As a part of our Server Management Services, Our Support Engineers helps webmasters fix Nginx-related errors regularly.
Let us today discuss the possible reasons and fixes for this error.
What causes Nginx “upstream timed out” error
The upstream timeout error generally triggers when the upstream takes too much to answer the request and NGINX thinks the upstream already failed in processing the request. A typical error message looks like this:
Some of the common reasons for this error include:
- Server resource usage
- PHP memory limits
- Server software timeouts
Let us now discuss how our Support Engineers fix this error in each of the cases.
How to fix Nginx “upstream timed out” error
Server resource usage
One of the most common reasons for this error is server resource usage. Often heavy load makes the server slow to respond to requests.
When it takes too much time to respond, in a reverse proxy setup Nginx thinks that the request already failed.
We already have some articles discussing the steps to troubleshoot server load here.
Our Support Engineers also make sure that there is enough RAM on the server. To check that they use the top, htop or free -m commands.
In addition, we also suggest optimizing the website by installing a good caching plugin. This helps to reduce the overall resource usage on the server.
PHP memory limits
At times, this error could be related only to specific PHP codes. Our Support Engineers cross-check the PHP FPM error log in such cases for a more detailed analysis of the error.
Sometimes, PHP would be using too much RAM and the PHP FPM process gets killed. In such cases, we would recommend to make sure that the PHP memory limit is not too high compared to the actual available memory on the Droplet.
For example, if you have 1GB of RAM available your PHP memory limit should not be more than 64MB.
Server software timeouts
Nginx upstream errors can also occur when a web server takes more time to complete the request.
By that time, the caching server will reach its timeout values(timeout for the connection between proxy and upstream server).
Slow queries can lead to such problems.
Our Support Engineers will fine tune the following Nginx timeout values in the Nginx configuration file.
proxy_connect_timeout 1200s;
proxy_send_timeout 1200s;
proxy_read_timeout 1200s;
fastcgi_send_timeout 1200s;
fastcgi_read_timeout 1200s;Once the timeout values are added, need to reload Nginx to save these parameters.
Conclusion
In short, Nginx upstream timed out triggers due to a number of reasons that include server resource usage and software timeouts. Today, we saw how our Support Engineers fix this error.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
SEE SERVER ADMIN PLANS
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
I am facing the same issue as well on AWS EKS (v1.24 and v1.25). I tried increasing timeouts, but to no avail. I thought it was a networking issue (btw, no error logs on the vpc-cni plugin) and therefore removed aws-vpc-cni and installed calico, but that did not fix it. Tested again with v1.4.0, v1.5.1 and the latest v1.6.4. The weird thing is that other deployments are working properly and some are recovering intermittently. Here’s controller logs with v1.4.0 and calico. The deployments failing are a simple php app and the kubernetes dashboard (both worked earlier).
-------------------------------------------------------------------------------
NGINX Ingress controller
Release: v1.4.0
Build: 50be2bf95fd1ef480420e2aa1d6c5c7c138c95ea
Repository: https://github.com/kubernetes/ingress-nginx
nginx version: nginx/1.19.10
-------------------------------------------------------------------------------
W0308 16:01:20.042700 7 client_config.go:617] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
I0308 16:01:20.042834 7 main.go:209] "Creating API client" host="https://172.20.0.1:443"
I0308 16:01:20.053563 7 main.go:253] "Running in Kubernetes cluster" major="1" minor="25+" git="v1.25.6-eks-48e63af" state="clean" commit="9f22d4ae876173884749c0701f01340879ab3f95" platform="linux/amd64"
I0308 16:01:20.191543 7 main.go:104] "SSL fake certificate created" file="/etc/ingress-controller/ssl/default-fake-certificate.pem"
I0308 16:01:20.209341 7 ssl.go:533] "loading tls certificate" path="/usr/local/certificates/cert" key="/usr/local/certificates/key"
I0308 16:01:20.228686 7 nginx.go:260] "Starting NGINX Ingress controller"
I0308 16:01:20.249621 7 event.go:285] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"ingress-nginx-controller", UID:"a675086a-b232-4ec0-bf44-846230a8276c", APIVersion:"v1", ResourceVersion:"12352", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/ingress-nginx-controller
I0308 16:01:21.332896 7 store.go:430] "Found valid IngressClass" ingress="kubernetes-dashboard/kubernetes-dashboard-ingress" ingressclass="nginx"
I0308 16:01:21.333572 7 store.go:430] "Found valid IngressClass" ingress="pc-dev/example-web-ingress" ingressclass="nginx"
I0308 16:01:21.333966 7 store.go:430] "Found valid IngressClass" ingress="pc-dev/summarizer-app-ingress" ingressclass="nginx"
I0308 16:01:21.334163 7 event.go:285] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"kubernetes-dashboard", Name:"kubernetes-dashboard-ingress", UID:"11d64d69-2dbb-4839-a6ca-6ece0ebea21f", APIVersion:"networking.k8s.io/v1", ResourceVersion:"6445", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync
I0308 16:01:21.334182 7 event.go:285] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"pc-dev", Name:"example-web-ingress", UID:"9824d39d-161d-4efd-8e4e-2418cf60dc9a", APIVersion:"networking.k8s.io/v1", ResourceVersion:"326107", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync
I0308 16:01:21.334228 7 store.go:430] "Found valid IngressClass" ingress="pc-dev/summarizer-text-extractor-ingress" ingressclass="nginx"
I0308 16:01:21.334442 7 event.go:285] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"pc-dev", Name:"summarizer-app-ingress", UID:"b58b0e53-be25-4691-900b-edc8a57ab967", APIVersion:"networking.k8s.io/v1", ResourceVersion:"6629", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync
I0308 16:01:21.334466 7 event.go:285] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"pc-dev", Name:"summarizer-text-extractor-ingress", UID:"2daea083-90de-43e3-8f66-0a5074fd598f", APIVersion:"networking.k8s.io/v1", ResourceVersion:"6637", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync
I0308 16:01:21.431012 7 nginx.go:303] "Starting NGINX process"
I0308 16:01:21.431042 7 leaderelection.go:248] attempting to acquire leader lease ingress-nginx/ingress-nginx-leader...
I0308 16:01:21.435027 7 nginx.go:323] "Starting validation webhook" address=":8443" certPath="/usr/local/certificates/cert" keyPath="/usr/local/certificates/key"
I0308 16:01:21.435553 7 controller.go:168] "Configuration changes detected, backend reload required"
I0308 16:01:21.436278 7 status.go:84] "New leader elected" identity="ingress-nginx-controller-6b5fc6b8b4-77zn5"
I0308 16:01:21.507529 7 controller.go:185] "Backend successfully reloaded"
I0308 16:01:21.507806 7 controller.go:196] "Initial sync, sleeping for 1 second"
I0308 16:01:21.508248 7 event.go:285] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-nginx", Name:"ingress-nginx-controller-5d86fb679c-w2dqg", UID:"50d47abf-850e-45c6-901b-38258638ec53", APIVersion:"v1", ResourceVersion:"369098", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload triggered due to a change in configuration
I0308 16:02:20.427978 7 leaderelection.go:258] successfully acquired lease ingress-nginx/ingress-nginx-leader
I0308 16:02:20.428079 7 status.go:84] "New leader elected" identity="ingress-nginx-controller-5d86fb679c-w2dqg"
2023/03/08 16:02:35 [error] 31#31: *569 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.227.25, server: dev-aws.example.com, request: "GET / HTTP/1.1", upstream: "http://192.168.215.1:80/", host: "dev-aws.example.com"
2023/03/08 16:02:40 [error] 31#31: *569 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.227.25, server: dev-aws.example.com, request: "GET / HTTP/1.1", upstream: "http://192.168.215.1:80/", host: "dev-aws.example.com"
2023/03/08 16:02:45 [error] 31#31: *569 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.227.25, server: dev-aws.example.com, request: "GET / HTTP/1.1", upstream: "http://192.168.215.1:80/", host: "dev-aws.example.com"
108.162.227.25 - - [08/Mar/2023:16:02:45 +0000] "GET / HTTP/1.1" 504 562 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" 1100 14.998 [pc-dev-example-web-service-80] [] 192.168.215.1:80, 192.168.215.1:80, 192.168.215.1:80 0, 0, 0 5.000, 5.000, 5.000 504, 504, 504 a7c98d98ac870f64981a997cd2f373a1
2023/03/08 16:04:26 [error] 32#32: *1488 upstream timed out (110: Operation timed out) while connecting to upstream, client: 172.68.34.41, server: dev-aws.example.com, request: "GET / HTTP/1.1", upstream: "http://192.168.215.1:80/", host: "dev-aws.example.com"
2023/03/08 16:04:31 [error] 32#32: *1488 upstream timed out (110: Operation timed out) while connecting to upstream, client: 172.68.34.41, server: dev-aws.example.com, request: "GET / HTTP/1.1", upstream: "http://192.168.215.1:80/", host: "dev-aws.example.com"
2023/03/08 16:04:36 [error] 32#32: *1488 upstream timed out (110: Operation timed out) while connecting to upstream, client: 172.68.34.41, server: dev-aws.example.com, request: "GET / HTTP/1.1", upstream: "http://192.168.215.1:80/", host: "dev-aws.example.com"
172.68.34.41 - - [08/Mar/2023:16:04:36 +0000] "GET / HTTP/1.1" 504 160 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Safari/605.1.15" 742 15.001 [pc-dev-example-web-service-80] [] 192.168.215.1:80, 192.168.215.1:80, 192.168.215.1:80 0, 0, 0 5.000, 5.000, 5.000 504, 504, 504 609b3af0a29debd459f45785048c7c8c
108.162.226.149 - - [08/Mar/2023:16:05:39 +0000] "GET / HTTP/1.1" 200 45 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" 1086 0.002 [pc-dev-summarizer-app-service-4000] [] 192.168.203.74:5000 45 0.004 200 bcf467f76d1806a985cbfa539e32497d
2023/03/08 16:05:39 [error] 31#31: *2096 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.227.25, server: dev-aws.example.com, request: "GET / HTTP/1.1", upstream: "http://192.168.215.1:80/", host: "dev-aws.example.com"
108.162.226.251 - - [08/Mar/2023:16:05:42 +0000] "GET / HTTP/1.1" 200 91 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" 1090 0.002 [pc-dev-summarizer-text-extractor-service-4000] [] 192.168.203.75:3000 91 0.004 200 8be160fd79da18035ef74ee2737fca96
2023/03/08 16:05:44 [error] 31#31: *2096 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.227.25, server: dev-aws.example.com, request: "GET / HTTP/1.1", upstream: "http://192.168.215.1:80/", host: "dev-aws.example.com"
2023/03/08 16:05:49 [error] 31#31: *2096 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.227.25, server: dev-aws.example.com, request: "GET / HTTP/1.1", upstream: "http://192.168.215.1:80/", host: "dev-aws.example.com"
108.162.227.25 - - [08/Mar/2023:16:05:49 +0000] "GET / HTTP/1.1" 504 562 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" 1126 15.008 [pc-dev-example-web-service-80] [] 192.168.215.1:80, 192.168.215.1:80, 192.168.215.1:80 0, 0, 0 5.000, 5.004, 5.004 504, 504, 504 deaefe97e08770d2ff6f7cc05e85967a
2023/03/08 16:05:52 [error] 32#32: *2215 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.226.135, server: np-k8s-dashboard.example.com, request: "GET / HTTP/1.1", upstream: "https://192.168.215.3:8443/", host: "np-k8s-dashboard.example.com"
2023/03/08 16:05:57 [error] 32#32: *2215 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.226.135, server: np-k8s-dashboard.example.com, request: "GET / HTTP/1.1", upstream: "https://192.168.215.3:8443/", host: "np-k8s-dashboard.example.com"
2023/03/08 16:06:02 [error] 32#32: *2215 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.226.135, server: np-k8s-dashboard.example.com, request: "GET / HTTP/1.1", upstream: "https://192.168.215.3:8443/", host: "np-k8s-dashboard.example.com"
108.162.226.135 - admin [08/Mar/2023:16:06:02 +0000] "GET / HTTP/1.1" 504 562 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" 1159 15.001 [kubernetes-dashboard-kubernetes-dashboard-443] [] 192.168.215.3:8443, 192.168.215.3:8443, 192.168.215.3:8443 0, 0, 0 5.000, 5.000, 5.000 504, 504, 504 6ece79b7fc58d5d20c5b308eaad44f8b
2023/03/08 16:06:09 [error] 31#31: *2359 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.227.23, server: np-k8s-dashboard.example.com, request: "GET /favicon.ico HTTP/1.1", upstream: "https://192.168.215.3:8443/favicon.ico", host: "np-k8s-dashboard.example.com", referrer: "https://np-k8s-dashboard.example.com/"
2023/03/08 16:06:14 [error] 31#31: *2359 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.227.23, server: np-k8s-dashboard.example.com, request: "GET /favicon.ico HTTP/1.1", upstream: "https://192.168.215.3:8443/favicon.ico", host: "np-k8s-dashboard.example.com", referrer: "https://np-k8s-dashboard.example.com/"
172.71.150.63 - - [08/Mar/2023:16:06:18 +0000] "HEAD / HTTP/1.1" 200 0 "-" "Site24x7" 364 0.001 [pc-dev-summarizer-text-extractor-service-4000] [] 192.168.203.75:3000 0 0.000 200 852bf6287ddb9841d8461deeff676fd2
172.71.151.111 - - [08/Mar/2023:16:06:18 +0000] "HEAD / HTTP/1.1" 200 0 "-" "Site24x7" 360 0.001 [pc-dev-summarizer-app-service-4000] [] 192.168.203.74:5000 0 0.000 200 94c8d6f9e2d8843ff90b11de7c1986eb
2023/03/08 16:06:19 [error] 31#31: *2359 upstream timed out (110: Operation timed out) while connecting to upstream, client: 108.162.227.23, server: np-k8s-dashboard.example.com, request: "GET /favicon.ico HTTP/1.1", upstream: "https://192.168.215.3:8443/favicon.ico", host: "np-k8s-dashboard.example.com", referrer: "https://np-k8s-dashboard.example.com/"
108.162.227.23 - admin [08/Mar/2023:16:06:19 +0000] "GET /favicon.ico HTTP/1.1" 504 562 "https://np-k8s-dashboard.example.com/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" 1118 14.997 [kubernetes-dashboard-kubernetes-dashboard-443] [] 192.168.215.3:8443, 192.168.215.3:8443, 192.168.215.3:8443 0, 0, 0 5.000, 5.000, 5.000 504, 504, 504 e9edc959a02abc0823d7b6382095afb8
Curl
* Trying 104.21.20.159:443...
* TCP_NODELAY set
* Connected to dev-aws.example.com (104.21.20.159) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.example.com
* start date: Jan 26 10:03:30 2023 GMT
* expire date: Apr 26 10:03:29 2023 GMT
* subjectAltName: host "dev-aws.example.com" matched cert's "*.example.com"
* issuer: C=US; O=Let's Encrypt; CN=E1
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5590454692f0)
> GET / HTTP/2
> Host: dev-aws.example.com
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 504
< date: Wed, 08 Mar 2023 16:25:42 GMT
< content-type: text/html
< cf-cache-status: DYNAMIC
< report-to: {"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v3?s=x4Pi5TFU5x%2FsaUDI0but%2BhguGiYTarmFSwjwMiFQJjfeuLX29z8y2wCZTSxFFW83nhO6SwtV7g6McNqosaOeaqWURUk%2FcgYvVPAPWyQPFOL%2FDPwBUg%2BsKs8%2FWzVRyr5yGbQ%2Bq5Ee5m8KNUI%3D"}],"group":"cf-nel","max_age":604800}
< nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
< server: cloudflare
< cf-ray: 7a4c6f22ffe03fca-SIN
< alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
<
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host dev-aws.example.com left intact
-
baijianpeng
- Posts: 301
- Joined: Tue Dec 22, 2015 2:06 pm
what does «upstream timed out» error mean?
My Joomla website is running on VestaCP on CentOS 7. The PHP version is 5.6.21, which was installed with «PHP Selector» from skamasle.
Today I checked the log file /var/log/httpd/domains/joomlagate.com.error.log, there are following error records:
2016/05/15 06:08:51 [error] 30728#30728: *1920053 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 42.236.48.92, server: joomlagate.com, request: «GET /index.php HTTP/1.1», upstream: «http://120.27.137.71:8080/index.php», host: «www.joomlagate.com», referrer: «http://www.joomlagate.com/index.php»
2016/05/15 06:08:51 [error] 30728#30728: *1920063 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 220.181.108.162, server: joomlagate.com, request: «GET /index.php?option=com_kunena&view=category&defaultmenu=155&Itemid=154&catid=46&limitstart=20 HTTP/1.1», upstream: «http://120.27.137.71:8080/index.php?opt … itstart=20», host: «www.joomlagate.com»
2016/05/15 06:09:08 [error] 30729#30729: *1919841 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 59.127.53.104, server: joomlagate.com, request: «POST /?option=com_komento HTTP/2.0», upstream: «https://120.27.137.71:8443/?option=com_komento», host: «www.joomlagate.com», referrer: «https://www.joomlagate.com/»
2016/05/15 06:09:08 [error] 30729#30729: *1919841 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 59.127.53.104, server: joomlagate.com, request: «POST /?option=com_komento HTTP/2.0», upstream: «https://120.27.137.71:8443/?option=com_komento», host: «www.joomlagate.com», referrer: «https://www.joomlagate.com/»
2016/05/15 06:09:08 [error] 30729#30729: *1919844 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 117.136.0.91, server: joomlagate.com, request: «POST /?option=com_komento HTTP/2.0», upstream: «https://120.27.137.71:8443/?option=com_komento», host: «www.joomlagate.com», referrer: «https://www.joomlagate.com/»
2016/05/15 06:09:08 [error] 30729#30729: *1920045 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 106.120.85.34, server: joomlagate.com, request: «POST /?option=com_komento HTTP/2.0», upstream: «https://120.27.137.71:8443/?option=com_komento», host: «www.joomlagate.com», referrer: «https://www.joomlagate.com/»
2016/05/15 06:09:08 [error] 30729#30729: *1920045 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 106.120.85.34, server: joomlagate.com, request: «POST /?option=com_komento HTTP/2.0», upstream: «https://120.27.137.71:8443/?option=com_komento», host: «www.joomlagate.com», referrer: «https://www.joomlagate.com/»
2016/05/15 06:09:08 [error] 30729#30729: *1920056 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 203.208.60.233, server: joomlagate.com, request: «GET /index.php?option=com_kunena&view=topic&catid=59&id=61436&layout=unread&Itemid=154 HTTP/1.1», upstream: «http://120.27.137.71:8080/index.php?opt … Itemid=154», host: «joomlagate.com»
2016/05/15 06:50:53 [crit] 30728#30728: *1921989 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early) while SSL handshaking, client: 64.41.200.103, server: 120.27.137.71:443
2016/05/15 06:50:53 [crit] 30728#30728: *1921990 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early) while SSL handshaking, client: 64.41.200.103, server: 120.27.137.71:443
What does «upstream timed out» error mean? How to fix this?
Thank you.
-
SS88
- Posts: 336
- Joined: Thu Nov 19, 2015 12:40 pm
Re: what does «upstream timed out» error mean?
Post
by SS88 » Sun May 15, 2016 12:16 am
That means it takes your web server more than 60 seconds to respond. To solve this problem in nginx.conf change the value of proxy_read_timeout directive. This directive determines how long nginx will wait to get the response to a request. By default it’s 60 seconds. Change it to 300 seconds:
ref: http://howtounix.info/howto/110-connect … r-in-nginx
-
baijianpeng
- Posts: 301
- Joined: Tue Dec 22, 2015 2:06 pm
Re: what does «upstream timed out» error mean?
Post
by baijianpeng » Sun May 15, 2016 1:00 am
hi,@SS88, your instruction worked. After I insert that line to the «server» section of my snginx.conf (I use HTTPS) , there is no more «upstream timed out» errors recorded in the log file.
However, now I got following new errors, could you please give me further help to solve this?
[Sun May 15 08:26:54.946756 2016] [fcgid:warn] [pid 25306] [client 124.88.120.128:44564] mod_fcgid: read data timeout in 120 seconds, referer: https://www.joomlagate.com/index.php?op … &Itemid=19
[Sun May 15 08:26:54.946818 2016] [core:error] [pid 25306] [client 124.88.120.128:44564] End of script output before headers: index.php, referer: https://www.joomlagate.com/index.php?op … &Itemid=19
[Sun May 15 08:33:11.776640 2016] [fcgid:warn] [pid 25308] [client 101.226.166.218:44846] mod_fcgid: read data timeout in 120 seconds, referer: https://120.27.137.71/index.php?Itemid= … w=category
[Sun May 15 08:33:11.776699 2016] [core:error] [pid 25308] [client 101.226.166.218:44846] End of script output before headers: index.php, referer: https://120.27.137.71/index.php?Itemid= … w=category
[Sun May 15 08:42:05.375294 2016] [fcgid:warn] [pid 25009] [client 113.240.234.205:45175] mod_fcgid: read data timeout in 120 seconds, referer: https://www.joomlagate.com/
[Sun May 15 08:42:05.375362 2016] [core:error] [pid 25009] [client 113.240.234.205:45175] End of script output before headers: index.php, referer: https://www.joomlagate.com/
Thank you.
-
SS88
- Posts: 336
- Joined: Thu Nov 19, 2015 12:40 pm
Re: what does «upstream timed out» error mean?
Post
by SS88 » Sun May 15, 2016 10:48 am
Change these to all 300.
Code: Select all
keepalive_timeout 300;
proxy_read_timeout 300;
proxy_connect_timeout 300;
fastcgi_read_timeout 300;300 = 5 minutes
If your pages are not loading within 5 minutes I would look into why. I had a browse and pages were loading for me quite quickly so you may want to take a look as to why these pages are not loading within 120 seconds (as that’s a very long time to wait)
You also may need to increase FcgidIOTimeout to 300 (this setting is a Fast CGI setting)
-
baijianpeng
- Posts: 301
- Joined: Tue Dec 22, 2015 2:06 pm
Re: what does «upstream timed out» error mean?
Post
by baijianpeng » Fri Jan 27, 2017 2:58 am
Today I met «upstream timed out» error again on my re-installed VPS server. So I followed your above post to change those timing values.
Well, I found all those 4 parameters in this file: /etc/nginx/nginx.conf.
However, the format of «keepalive_timeout» directive is not a single value, but a pair :
This is the default value of that line.
What kind of new value should I change to for this line?
Thank you.
-
SS88
- Posts: 336
- Joined: Thu Nov 19, 2015 12:40 pm
Re: what does «upstream timed out» error mean?
Post
by SS88 » Fri Jan 27, 2017 1:20 pm
baijianpeng wrote:Today I met «upstream timed out» error again on my re-installed VPS server. So I followed your above post to change those timing values.
Well, I found all those 4 parameters in this file: /etc/nginx/nginx.conf.
However, the format of «keepalive_timeout» directive is not a single value, but a pair :
This is the default value of that line.
What kind of new value should I change to for this line?
Thank you.
Syntax: keepalive_timeout timeout [header_timeout];
Default: keepalive_timeout 75s;
Context: http, server, location
The first parameter sets a timeout during which a keep-alive client connection will stay open on the server side. The zero value disables keep-alive client connections. The optional second parameter sets a value in the “Keep-Alive: timeout=time” response header field. Two parameters may differ.
The “Keep-Alive: timeout=time” header field is recognized by Mozilla and Konqueror. MSIE closes keep-alive connections by itself in about 60 seconds.
http://nginx.org/en/docs/http/ngx_http_ … ve_timeout
-
SS88
- Posts: 336
- Joined: Thu Nov 19, 2015 12:40 pm
Re: what does «upstream timed out» error mean?
Post
by SS88 » Fri Jan 27, 2017 8:16 pm
ashleycalebhart wrote:May i ask why you would set a tmeout limit of 5 minutes? asking for DDos troubles here?
If you’re under a real DDoS you have no chance anyway.
-
baijianpeng
- Posts: 301
- Joined: Tue Dec 22, 2015 2:06 pm
Re: what does «upstream timed out» error mean?
Post
by baijianpeng » Sat Jan 28, 2017 12:32 am
Well, I tried to change both number to «300» for the «keepalive_timeout» parameter, then I saved that conf file and tried to restart Nginx, then I got following error:
Code: Select all
root@mail:/etc/nginx# systemctl restart nginx
Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
root@mail:/etc/nginx# systemctl status nginx
● nginx.service - LSB: Stop/start nginx
Loaded: loaded (/etc/init.d/nginx; bad; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2017-01-28 08:28:44 CST; 9s ago
Docs: man:systemd-sysv-generator(8)
Process: 6286 ExecStop=/etc/init.d/nginx stop (code=exited, status=0/SUCCESS)
Process: 6325 ExecStart=/etc/init.d/nginx start (code=exited, status=1/FAILURE)
CGroup: /system.slice/nginx.service
├─25307 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.con
├─25308 nginx: worker process
└─25309 nginx: cache manager process
Jan 28 08:28:43 mail.joomlagate.com nginx[6325]: nginx: [emerg] bind() to 120.27.137.71:443 failed (98: Address a
Jan 28 08:28:43 mail.joomlagate.com nginx[6325]: nginx: [emerg] bind() to 10.47.93.1:80 failed (98: Address alrea
Jan 28 08:28:43 mail.joomlagate.com nginx[6325]: nginx: [emerg] bind() to 120.27.137.71:80 failed (98: Address al
Jan 28 08:28:43 mail.joomlagate.com nginx[6325]: nginx: [emerg] bind() to 127.0.0.1:8084 failed (98: Address alre
Jan 28 08:28:43 mail.joomlagate.com nginx[6325]: nginx: [emerg] bind() to 120.27.137.71:443 failed (98: Address a
Jan 28 08:28:44 mail.joomlagate.com nginx[6325]: nginx: [emerg] still could not bind()
Jan 28 08:28:44 mail.joomlagate.com systemd[1]: nginx.service: Control process exited, code=exited status=1
Jan 28 08:28:44 mail.joomlagate.com systemd[1]: Failed to start LSB: Stop/start nginx.
Jan 28 08:28:44 mail.joomlagate.com systemd[1]: nginx.service: Unit entered failed state.
Jan 28 08:28:44 mail.joomlagate.com systemd[1]: nginx.service: Failed with result 'exit-code'.
lines 1-21/21 (END)
At the same time, I checked the Nginx log files and found following records:
root@mail:/var/log/nginx# tail error.log
2017/01/28 08:28:41 [emerg] 6331#6331: bind() to 120.27.137.71:443 failed (98: Address already in use)
2017/01/28 08:28:41 [emerg] 6331#6331: bind() to 10.47.93.1:80 failed (98: Address already in use)
2017/01/28 08:28:41 [emerg] 6331#6331: bind() to 120.27.137.71:80 failed (98: Address already in use)
2017/01/28 08:28:41 [emerg] 6331#6331: bind() to 127.0.0.1:8084 failed (98: Address already in use)
2017/01/28 08:28:41 [emerg] 6331#6331: bind() to 120.27.137.71:443 failed (98: Address already in use)
2017/01/28 08:28:41 [emerg] 6331#6331: bind() to 10.47.93.1:80 failed (98: Address already in use)
2017/01/28 08:28:41 [emerg] 6331#6331: bind() to 120.27.137.71:80 failed (98: Address already in use)
2017/01/28 08:28:41 [emerg] 6331#6331: bind() to 127.0.0.1:8084 failed (98: Address already in use)
2017/01/28 08:28:41 [emerg] 6331#6331: bind() to 120.27.137.71:443 failed (98: Address already in use)
2017/01/28 08:28:41 [emerg] 6331#6331: still could not bind()
Now my Nginx can NOT be restarted, even after I change those numbers back to «60 60».
But, my website pages can still be opened. This is weird!
-
baijianpeng
- Posts: 301
- Joined: Tue Dec 22, 2015 2:06 pm
Re: what does «upstream timed out» error mean?
Post
by baijianpeng » Sat Jan 28, 2017 12:41 am
Ok, since I am not a pro , so I choose to «reboot» my server. After reboot, Nginx seems OK now.
Code: Select all
root@mail:~# systemctl status nginx
● nginx.service - LSB: Stop/start nginx
Loaded: loaded (/etc/init.d/nginx; bad; vendor preset: enabled)
Active: active (running) since Sat 2017-01-28 08:37:55 CST; 1min 35s ago
Docs: man:systemd-sysv-generator(8)
Process: 783 ExecStart=/etc/init.d/nginx start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/nginx.service
├─1037 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.con
├─1038 nginx: worker process
└─1039 nginx: cache manager process
Jan 28 08:37:54 mail.joomlagate.com systemd[1]: Starting LSB: Stop/start nginx...
Jan 28 08:37:55 mail.joomlagate.com systemd[1]: Started LSB: Stop/start nginx.