Sometimes you may get 503 Service Temporarily Unavailable error in NGINX due to various reasons. In this article we will look at what is 503 service temporarily unavailable error, and how to fix 503 service temporarily unavailable error in NGINX.
503 Service Temporarily Unavailable Error means that NGINX is unable to handle the request as it is temporarily overloaded or facing resource constraints. It is different from 500 internal server error where the server is simply unable to process your request. In this case, the server continues to function properly but has chosen to return 503 error code.
Bonus Read : How to Fix 500 Internal Server Error in NGINX
How to Fix 503 Service Temporarily Unavailable Error in NGINX
Here is how to fix 503 service temporarily unavailable error in NGINX.
1. Reboot NGINX Server
One of the easiest ways to fix 503 service temporarily unavailable error is to simply restart NGINX server. Many times, NGINX may get overloaded due to too many open connections and temporary files. Restarting your server will close all these open connections and delete temporary files that are causing the bottleneck. If NGINX is a reverse proxy with multiple web servers, make sure to reboot even the web servers down the chain to ensure that your website/application is completely refreshed.
Bonus Read : How to Fix 504 Gatweway Timeout Error in NGINX
2. Check for Unexpected Updates / Maintenance
Have you enabled auto-updates in your web site/application? If so, then it might be downloading/installing updates for one or more plugins. This is quite common in CMS based systems like WordPress and Magento. In such cases, just turn off auto-updates in your system.
Similarly, check if you have any scheduled maintenance running in the background. In such cases also, your web server will return 503 service temporarily unavailable.
Bonus Read : How to Fix 502 Bad Gateway in NGINX
3. Server Connectivity
NGINX may also throw 503 service temporarily unavailable error if it is unable to connect to the web server (e.g Apache) or any of the third-party APIs.
Since today’s web architecture requires multiple web servers and third-party services, NGINX is likely to give 503 service temporarily unavailable if any of them goes down. In such cases check if all web servers and third party services are up and running.
Bonus Read : How to Increase Request Timeout in NGINX
4. Examine Server Logs
NGINX server log records the IP address, device, requested URL, response code and date time for each request. You can use any server log monitoring tool to find out which requested URL gives 503 service temporarily unavailable error. Once you have identified the problematic URLs, you can investigate further into the underlying cause.
Bonus Read : How to Increase File Upload Size in NGINX
5. Application Bugs
Based on previous step, once you have identified the requested URLs that return 503 service temporarily unavailable error, look for bugs in code or script that serve those URLs. Look into your version control system’s commit history for any recent modifications to the code that serves those URLs. This will help you identify and fix problems quickly.
Hopefully, the above tips will help you fix 503 service temporarily unavailable error in Apache.
Ubiq makes it easy to visualize data in minutes, and monitor in real-time dashboards. Try it Today!
Related posts:
- About Author
I’m setting up nginx-proxy in front of an app server. They’re defined in separate compose definitions. For some reason I’m getting a 503, but I don’t know why and I’ve gone over the nginx-proxy docs in detail.
The app server originally served https over 443 with 10443 exposed on the host. I switched to serving http over 80 with 10443 exposed on the host.
I can curl from the app server directly, but curling through nginx-proxy throws up an error
I initially had nginx-proxy on 443, but I switched it to 80 for now.
Until I added default.crt and default.key, I was getting a connection refused error. After adding them, I’m getting a 503.
curl http://foo.example.com:80/apidocs --verbose --insecure
* Hostname was NOT found in DNS cache
* Trying 10.x.x.x...
* Connected to foo.example.com (10.x.x.x) port 80 (#0)
> GET /apidocs HTTP/1.1
> User-Agent: curl/7.35.0
> Host: foo.example.com
> Accept: */*
>
< HTTP/1.1 503 Service Temporarily Unavailable
* Server nginx/1.9.12 is not blacklisted
< Server: nginx/1.9.12
< Date: Thu, 21 Apr 2016 17:26:16 GMT
< Content-Type: text/html
< Content-Length: 213
< Connection: keep-alive
<
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body bgcolor="white">
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx/1.9.12</center>
</body>
</html>
* Connection #0 to host foo.example.com left intact
Here’s my compose definition for nginx-proxy. I’m using network_mode: bridge which is supposed to work even with version: 2.
version: '2' # Not yet compatible with custom networks in v2 of Compose services: nginx: image: jwilder/nginx-proxy # Necessary until nginx-proxy fully supports Compose v2 networking network_mode: bridge ports: - "80:80" restart: always volumes: - "certs:/etc/nginx/certs:ro" - "nginx-log:/var/log/nginx" - "/var/run/docker.sock:/tmp/docker.sock:ro" volumes: certs: external: true nginx-log: external: true
Here’s my app server composition:
version: '2' services: database: image: sameersbn/postgresql:9.4-13 restart: always # Necessary until nginx-proxy fully supports Compose v2 networking network_mode: bridge ports: - "55433:5432" environment: - DB_USER=foo - DB_PASS=... - DB_NAME=foo_staging - USERMAP_UID=1000 volumes: - "foo-data:/var/lib/postgresql" foo: image: private-registry.example.com/dswb/foo:1.4.3 restart: always container_name: "dswb-foo" links: - "database:database" # Necessary until nginx-proxy fully supports Compose v2 networking network_mode: bridge ports: - "10443:80" volumes: - "certs:/home/rails/webapp/certs" environment: # - "CERT_NAME=example.com" - "VIRTUAL_HOSTNAME=foo.example.com" - "VIRTUAL_PORT=80" - "VIRTUAL_PROTO=http" # command: "bash -c 'rake db:migrate && thin --ssl --ssl-key-file certs/star_example_com.key --ssl-cert-file certs/star_example_com.bundle.crt --port 443 --address 0.0.0.0 start'" command: "bash -c 'rake db:migrate && thin --port 80 --address 0.0.0.0 start'" volumes: foo-data: driver: local certs: external: true
The certs are less relevant since I switched to port 80 to debug. I have a wildcard certificate for *.example.com. I made a copy named foo.example.com in case nginx-proxy couldn’t find it. I tried both setting and not setting CERT_NAME. I’ve now also generated the dhparam stuff.
root@8b02a7deb220:/etc/nginx/certs# ls -la
total 48
drwxr-xr-x 2 root root 4096 Apr 21 18:15 .
drwxr-xr-x 4 root root 4096 Apr 21 18:06 ..
-rw------- 1 root root 3575 Apr 21 18:03 example.com.crt
-rw-r--r-- 1 root root 769 Apr 21 18:03 example.com.dhparam.pem
-rw------- 1 root root 1679 Apr 21 18:03 example.com.key
-rw-r--r-- 1 root root 1838 Apr 21 18:03 default.crt
-rw-r--r-- 1 root root 3268 Apr 21 18:03 default.key
-rw------- 1 root root 3575 Apr 21 17:37 foo.example.com.crt
-rw-r--r-- 1 root root 769 Apr 21 18:15 foo.example.com.dhparam.pem
-rw------- 1 root root 1679 Apr 21 17:37 foo.example.com.key
This is the only thing that shows up in the nginx-proxy log when I curl:
nginx.1 | foo.example.com 10.x.x.x - - [21/Apr/2016:17:26:16 +0000] "GET /apidocs HTTP/1.1" 503 213 "-" "curl/7.35.0"
Nothing shows up in app server log, meaning it does not see the request.
How do I debug this? Are there better logs somewhere?
FYI:
- I run Kubernetes on docker desktop for mac
- The website based on Nginx image
I run 2 simple website deployments on Kubetesetes and use the NodePort service. Then I want to make routing to the website using ingress. When I open the browser and access the website, I get an error 503 like images below. So, how do I fix this error?
### Service
apiVersion: v1
kind: Service
metadata:
name: app-svc
labels:
app: app1
spec:
type: NodePort
ports:
- port: 80
selector:
app: app1
---
apiVersion: v1
kind: Service
metadata:
name: app2-svc
labels:
app: app2
spec:
type: NodePort
ports:
- port: 80
selector:
app: app2
### Ingress-Rules
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: app-ingress
annotations:
ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /app1
backend:
serviceName: app-svc
servicePort: 30092
- path: /app2
backend:
serviceName: app2-svc
servicePort: 30936
Dan Bonachea
2,3585 gold badges16 silver badges31 bronze badges
asked Oct 25, 2019 at 10:24
3
Yes, i end up with same error. once i changed the service type to «ClusterIP», it worked fine for me.
answered Apr 28, 2020 at 17:41
Found this page after searching for a solution to nginx continually returning 503 responses despite the service names all being configured correctly. The issue for me was that I had configured the kubernetes service in a specific namespace, but did not update the ingress component to be in the same namespace. Despite being such a simple solution it was not at all obvious!
answered Jun 3, 2020 at 14:28
Ben WessonBen Wesson
5896 silver badges16 bronze badges
I advise you to use service type ClusterIP
Take look on this useful article: services-kubernetes.
If you use Ingress you have to know that Ingress isn’t a type of Service, but rather an object that acts as a reverse proxy and single entry-point to your cluster that routes the request to different services. The most basic Ingress is the NGINX Ingress Controller, where the NGINX takes on the role of reverse proxy, while also functioning as SSL. On below drawing you can see workflow between specific components of environment objects.
Ingress is exposed to the outside of the cluster via ClusterIP and Kubernetes proxy, NodePort, or LoadBalancer, and routes incoming traffic according to the configured rules.
Example of service definition:
---
apiVersion: v1
kind: Service
metadata:
name: app-svc
labels:
app: app1
spec:
type: ClusterIP
ports:
- port: 80
selector:
app: app1
---
apiVersion: v1
kind: Service
metadata:
name: app2-svc
labels:
app: app2
spec:
type: ClusterIP
ports:
- port: 80
selector:
app: app2
Let me know if it helps.
answered Oct 25, 2019 at 11:10
MalgorzataMalgorzata
6,2151 gold badge10 silver badges26 bronze badges
2
First, You need to change the service type of your app-service to ClusterIP, because the Ingress object is going to access these Pods(services) from inside the cluster. (ClusterIP service is used when you want to allow accessing a pod inside a cluster).
Second, Make sure the services are running by running kubectl get services and check the running services names against the names in backend section in Ingress routing rules
answered Oct 24, 2020 at 16:31
Mu-MajidMu-Majid
8331 gold badge9 silver badges16 bronze badges
Little late to this journey but here is my comment on the issue.
I was having the same issue and having the same environment. (Docker Desktop-based Kubernetes with WSL2)
a couple of items probably can help.
- add the host entry in the rules section. and the value will be kubernetes.docker.internal like below
rules:
- host: kubernetes.docker.internal
http:
paths:
- path....- check the endpoints using
kubectl get servicesto confirm that the same port is in your ingress rule definition for each of those backend services.
backend:
service:
name: my-apple-service
port:
number: 30101kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-apple-service ClusterIP 10.106.121.95 <none> 30101/TCP 9h
my-banada-service ClusterIP 10.99.192.112 <none> 30101/TCP 9hanswered Dec 1, 2021 at 15:04
I’m setting up nginx-proxy as a reverse proxy in front of Docker container running an app server. They’re defined in separate Docker compose definitions. For some reason I’m getting a 503, but I don’t know why and I’ve gone over the nginx-proxy docs in detail.
(I’ve also opened this as a github issue for nginx-proxy.)
The app server originally served https over 443 with 10443 exposed on the host. I switched to serving http over 80 with 10443 exposed on the host.
I can curl from the app server directly, but curling through nginx-proxy throws up an error
I initially had nginx-proxy on 443, but I switched it to 80 for now.
Until I added default.crt and default.key, I was getting a connection refused error. After adding them, I’m getting a 503.
curl http://foo.example.com:80/apidocs --verbose --insecure
* Hostname was NOT found in DNS cache
* Trying 10.x.x.x...
* Connected to foo.example.com (10.x.x.x) port 80 (#0)
> GET /apidocs HTTP/1.1
> User-Agent: curl/7.35.0
> Host: foo.example.com
> Accept: */*
>
< HTTP/1.1 503 Service Temporarily Unavailable
* Server nginx/1.9.12 is not blacklisted
< Server: nginx/1.9.12
< Date: Thu, 21 Apr 2016 17:26:16 GMT
< Content-Type: text/html
< Content-Length: 213
< Connection: keep-alive
<
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body bgcolor="white">
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx/1.9.12</center>
</body>
</html>
* Connection #0 to host foo.example.com left intact
Here’s my compose definition for nginx-proxy. I’m using network_mode: bridge which is supposed to work even with version: 2.
version: '2'
# Not yet compatible with custom networks in v2 of Compose
services:
nginx:
image: jwilder/nginx-proxy
# Necessary until nginx-proxy fully supports Compose v2 networking
network_mode: bridge
ports:
- "80:80"
restart: always
volumes:
- "certs:/etc/nginx/certs:ro"
- "nginx-log:/var/log/nginx"
- "/var/run/docker.sock:/tmp/docker.sock:ro"
volumes:
certs:
external: true
nginx-log:
external: true
Here’s my app server composition:
version: '2'
services:
database:
image: sameersbn/postgresql:9.4-13
restart: always
# Necessary until nginx-proxy fully supports Compose v2 networking
network_mode: bridge
ports:
- "55433:5432"
environment:
- DB_USER=foo
- DB_PASS=...
- DB_NAME=foo_staging
- USERMAP_UID=1000
volumes:
- "foo-data:/var/lib/postgresql"
foo:
image: private-registry.example.com/dswb/foo:1.4.3
restart: always
container_name: "dswb-foo"
links:
- "database:database"
# Necessary until nginx-proxy fully supports Compose v2 networking
network_mode: bridge
ports:
- "10443:80"
volumes:
- "certs:/home/rails/webapp/certs"
environment:
# - "CERT_NAME=example.com"
- "VIRTUAL_HOSTNAME=foo.example.com"
- "VIRTUAL_PORT=80"
- "VIRTUAL_PROTO=http"
command: "bash -c 'rake db:migrate && thin --port 80 --address 0.0.0.0 start'"
volumes:
foo-data:
driver: local
certs:
external: true
The certs are less relevant since I switched to port 80 to debug. I have a wildcard certificate for *.example.com. I made a copy named foo.example.com in case nginx-proxy couldn’t find it. I tried both setting and not setting CERT_NAME. I’ve now also generated the dhparam stuff.
root@8b02a7deb220:/etc/nginx/certs# ls -la
total 48
drwxr-xr-x 2 root root 4096 Apr 21 18:15 .
drwxr-xr-x 4 root root 4096 Apr 21 18:06 ..
-rw------- 1 root root 3575 Apr 21 18:03 example.com.crt
-rw-r--r-- 1 root root 769 Apr 21 18:03 example.com.dhparam.pem
-rw------- 1 root root 1679 Apr 21 18:03 example.com.key
-rw-r--r-- 1 root root 1838 Apr 21 18:03 default.crt
-rw-r--r-- 1 root root 3268 Apr 21 18:03 default.key
-rw------- 1 root root 3575 Apr 21 17:37 foo.example.com.crt
-rw-r--r-- 1 root root 769 Apr 21 18:15 foo.example.com.dhparam.pem
-rw------- 1 root root 1679 Apr 21 17:37 foo.example.com.key
This is the only thing that shows up in the nginx-proxy log when I curl:
nginx.1 | foo.example.com 10.x.x.x - - [21/Apr/2016:17:26:16 +0000] "GET /apidocs HTTP/1.1" 503 213 "-" "curl/7.35.0"
Nothing shows up in app server log, meaning it does not see the request.
How do I debug this? Are there better logs somewhere?
Ошибки 5XX означают, что есть проблемы со стороны сервера. Например, 500 ошибка значит, что сервер столкнулся с внутренней ошибкой, из-за которой не смог обработать запрос. К ней могут привести неверные директивы в .htaccess или ошибки в скриптах сайта. А ошибка 503 означает, что сервер не может обработать ваш запрос в данный момент. После номера ошибки часто идёт краткое описание. 503 ошибка сервера часто сопровождается фразой «Service Temporarily Unavailable» (сервис временно недоступен). Если на вашем сайте часто встречается 503 ошибка, значит самое время выяснить её причину.
В этой статье мы рассмотрим возможные причины возникновения 503 ошибки на сайте и способы её устранения.
Ошибка 503 Service Unavailable
Что такое ошибка 503 (Service Temporarily Unavailable)
Эта ошибка означает, что сервер не готов обработать запрос в данный момент. Подразумевается, что это временно и нужно повторить попытку позже. Но это не всегда так. HTTP 503 Service Unavailable — это код состояния, который содержится в ответе веб-сервера и показывает, успешно ли выполнен запрос. Коды 5XX принадлежат классу серверных ошибок. В спецификации RFC 7231 указано, что код 503 сообщает о том, что сервер в настоящее время не может обработать запрос из-за временной перегрузки или планового технического обслуживания
Спецификация RFC 7231
Если вы встретили эту ошибку, скорее всего, веб-сервер не успевает обрабатывать все поступающие на него запросы из-за нехватки ресурсов или технического обслуживания. Однако бывает, что ошибка 500 возникает не со стороны сервера, а со стороны клиента. Поэтому сначала стоит определить, на чьей стороне проблема. Если вы не являетесь администратором сайта, на котором встретили ошибку, проверьте, нет ли проблем с вашей стороны.
Как исправить ошибку 503 со стороны пользователя
-
1.
Перезагрузите страницу при помощи клавиши F5. Бывает, что проблема действительно временная и возникла в прошлый раз, когда вы пытались открыть страницу.
-
2.
Если после нескольких перезагрузок страницы ошибка всё равно возникает, попробуйте открыть сайт через другой браузер. Если в другом браузере ошибка не воспроизводится, очистите кэш на своем браузере. Например, в Google Chrome нажмите комбинацию клавиш Ctrl+Shift+Delete:
Очистить историю в Google Chrome
-
3.
Если действия выше не помогли, попробуйте перейти на сайт с другого устройства. Будет лучше, если оно будет подключено к другой сети, чтобы исключить проблему со стороны интернет-провайдера. Откройте сайт на телефоне через мобильный интернет или попросите сделать это кого-нибудь ещё. Если на другом устройстве сайт работает, попробуйте перезагрузить ваше устройство. При возможности то же самое лучше сделать и с роутером.
-
4.
Если ничего из перечисленного вам не помогло, попробуйте связаться с владельцем сайта. Сделать это можно через форму обратной связи или по email, указанному на сайте. Если недоступен сайт целиком, а не какая-то определенная страница, попробуйте найти контакты в поисковых системах, в социальных сетях или на форумах.
Эти действия помогут понять, с чьей стороны проблема. Если вам самостоятельно не удалось решить проблему, то остаётся только ждать решения проблемы владельцем сайта. Скорее всего, это массовая проблема, и её решением уже занимаются. Попробуйте открыть сайт позже.
Ошибка недоступности, если вы владелец сайта
Частые ошибки 503 на вашем сайте могут негативно сказаться на позициях в поисковых системах и привести к снижению трафика. Посетители могут просто не вернуться на ваш сайт. Не игнорируйте проблему и сразу приступайте к её решению. Вот несколько вариантов решения:
- На любом хостинге есть ограничения и лимиты, которые не стоит превышать. Их устанавливает хостинг-провайдер. Превышение лимитов может привести к возникновению проблем на сайте, в том числе и к ошибке 503. Изучить характеристики вашего тарифного плана вы можете на сайте хостинг-провайдера. Для хостинга REG.RU действуют следующие технические ограничения.
- Хостинг может не справляться с большим количеством посетителей на сайте. В этом случае может помочь смена тарифного плана или переезд к новому хостинг-провайдеру.
- Бывает, что неактуальные версии плагинов и других компонентов движка нарушают работу сайта. Попробуйте по очереди отключать установленные плагины вашей CMS и проверять работоспособность сайта после каждого. Если ошибка не возникает после отключения очередного плагина, обновите этот плагин до последней версии. Возможно, что в новой версии разработчик уже внёс исправления. Если обновление не помогло, плагину нужно искать альтернативу.
- Регулярно обновляйте CMS и её компоненты. Зачастую обновления направлены на оптимизацию работы движка, устранение уязвимостей, борьбу с багами, повышение безопасности и быстродействия. Удалите все ненужные компоненты, которыми не пользуетесь. Оставьте только самые необходимые, чтобы уменьшить нагрузку на сервер.
- Проанализируйте скрипты сайта. К HTTP Error 503 может привести неправильная работа скриптов на сайте. Выполните их диагностику и убедитесь, что на сайте не включен режим технических работ.
- Не загружайте крупные файлы при помощи PHP. Очень часто хостинг-провайдер ограничивает время выполнения скрипта, и вы можете не уложиться в этот лимит. Ещё одним минусом передачи файлов через PHP является создание отдельного PHP-процесса, который будет занят загрузкой файла, а не обработкой запросов посетителей. Загружайте файлы по FTP, чтобы уменьшить нагрузку на хостинг.
- Запускайте массовые почтовые рассылки в периоды минимальной активности на вашем сайте. Точно так же стоит поступить и с техническими работами на сайте и сервере.
- Поисковые роботы могут генерировать большое количество обращений к сайту. Проанализируйте статистику по User-Agent и выясните, какие роботы создают нагрузку. При помощи файла robots.txt задайте временной интервал обращений.
- Настройте кэширование средствами CMS или хостинга. В WordPress вы можете настроить кэширование с помощью нашей инструкции: Что такое кэширование и как управлять им в WordPress. В панели управления хостингом тоже часто имеются встроенные инструменты по настройке кэширования.
- Запросы к сторонним ресурсам могут замедлять генерацию и отдачу контента, что в итоге может привести к 503 ошибке. Если удалённый сервер недоступен, ваш сайт потратит больше времени на ожидание ответа. Уменьшите тайм-аут ожидания ответа от стороннего ресурса или вовсе откажитесь от таких запросов. Работоспособность сторонних сервисов невозможно контролировать.
Не всегда проблему можно решить самостоятельно. Иногда лучше сразу обратиться за помощью к опытным специалистам. Если считаете, что вашего опыта и умений недостаточно для решения проблемы, свяжитесь со службой поддержки вашего хостинг-провайдера.
Ошибка 503 на хостинге REG.RU
-
1.
Ошибка может возникнуть из-за превышения лимита на количество PHP-процессов. Согласно техническим ограничениям, на тарифных планах Host максимальное количество процессов PHP составляет 4, на тарифных планах VIP — 32.
Чтобы посмотреть запущенные PHP-процессы, подключитесь по SSH и выполните следующую команду:
ps aux | grep php | grep u1234567Где u1234567 — ваш логин хостинга (Как узнать логин хостинга).
Чтобы завершить текущие php-процессы, измените версию PHP на отличную от текущей. Затем включите версию PHP, которая была установлена ранее.
-
2.
Максимальное количество процессов на тарифных планах Host составляет 18, а на VIP — 48. Если общее количество процессов (PHP, IMAP, Cron и др.) будет превышено, то может возникнуть ошибка «503 временно недоступен».
Технические ограничения хостинга REG.RU
Чаще всего причиной является большое количество процессов IMAP из-за многочисленных подключений к ящикам. В качестве решения проблемы попробуйте подключаться к почтовому серверу по протоколу POP3. Это позволит уменьшить общее количество процессов.
-
3.
Максимальное количество HTTP-запросов в секунду на один домен: 75 на тарифах Host и 300 на VIP. При превышении этого лимита 503 ошибку может возвращать весь сайт или часть контента на нём. Причиной может быть большое количество запросов в секунду или контента на сайте (картинки, баннеры).
-
4.
На VPS ошибка может возникнуть из-за DDoS-атаки, из-за которой увеличивается нагрузка на сервер.
Если вам не удалось решить проблему на хостинге REG.RU самостоятельно, напишите заявку в службу поддержки.