Ошибка proxy 503

Как и любая проблема с доступом к интернет-ресурсам, ошибка 503 Service Unavailable («Сервис недоступен») может быть вызвана сбоями как на стороне пользователя, так и на стороне сервера, на котором находится сайт. Поэтому первое, что нужно сделать, если вы столкнулись с таким сообщением при посещении веб-ресурса, попробовать устранить сбой своими силами. Это намного проще и быстрее, чем пытаться донести информацию о возникших сложностях до владельца сайта.

Процедура устранения проблемы со стороны администратора веб-ресурса более сложная, но в большинстве случаев именно неправильные настройки на уровне хостинга или настроек сайта в панели управления CMS приводят к появлению ошибки сервера с кодом 503.

Устранение ошибки 503 пользователем

Возникает резонный вопрос: почему бы просто не покинуть проблемный сайт, пусть сами разбираются со своими багами? Это решение очевидное, но не совсем верное. Во-первых, вам может быть очень необходимо посетить именно этот веб-ресурс. Во-вторых, появление сигнала об ошибке доступа может говорить о том, что с вашим браузером, программным обеспечением, компьютером или другими устройствами что-то не в порядке. И тогда это уже ваша проблема, которая может повторяться систематически и при посещении других сайтов. Рассмотрим, что можно сделать самому, чтобы исправить ошибку 503, двигаясь от простого к сложному.

1. Обновите вкладку браузера. Это покажется странным, но зачастую такое простое действие приводит к положительному результату. Нажмите клавишу F5 или воспользуйтесь специальной кнопкой в меню браузера.
2. Закройте и откройте браузер. Таким образом вы произведете сброс текущей сессии соединения и обновите его. При новом подключении скрипт браузера может не обнаружить ошибку 503, если она была воспринята им ошибочно.
3. Стоит убедиться, что сбой не связан именно с вашим компьютером. Это особенно актуально, если ошибки соединения с веб-ресурсами повторяются регулярно и возникают с разными кодировками на других сайтах. Для этого необходимо посетить проблемную страницу с другого устройства и желательно через новое интернет-соединение.
4. Зайдите на страницу, выдавшую ошибку 503, используя другой браузер. Вполне вероятно, что дефект возникает из-за некорректных настроек текущего. Если это подтвердится, стоит в них покопаться и найти источник возникновения проблемы. Самое простое, это восстановить настройки по умолчанию.
5. Перезагрузка компьютера. Как и любой программный сбой на уровне операционной системы или другого программного обеспечения, он может быть исправлен автоматически при новой загрузке системы.
6. Очистка кэша и удаление файлов cookies.  В зависимости от настроек конкретного браузера в них может сохраняться много «лишней» информации при обмене web-данными. Операция довольно несложная, но стоит предварительно посмотреть help по данному вопросу, т.к. в каждом браузере она проводится по-разному.
7. Перезагрузка сетевого оборудования. Часто сложности при соединении с интернет-ресурсами возникают из-за некорректного поведения ПО на внешних устройствах, через которые вы получаете трафик. Это может быть роутер, раздающий интернет как по кабелю, так и через Wi-Fi. Необходимо отключить соответствующую железку по питанию, т.е. полностью обесточить ее примерно на одну минуту. Если провайдер выдает вам динамический ip-адрес, то произойдет его смена, что тоже может привести к устранению появления ошибки 503.
8. Смена DNS-адреса на сервере. Это решение является наиболее сложным для обычного пользователя. В большинстве интернет-соединений используется общедоступный DNS-адрес Google. Изменить его можно через «Панель управления компьютера» в «Центре управления сетями и общим доступом». Данные манипуляции довольно критичны для устойчивой работы интернета на вашем компьютере. Поэтому производить их стоит только тогда, когда вы абсолютно уверены в своей IT-подготовке.

Если ни один из вышеприведенных способов не помог, а достучаться до сайта ну очень нужно, пишите о проблеме в техподдержку данного ресурса, приложив скриншот страницы с кодом и описанием ошибки.

Ошибка 503 может отображаться в разных форматах с дополнительными информативными сообщениями. Появление страницы «503 Service Temporary Unavailable – Сервис временно недоступен» говорит о том, что проблема носит временный характер. В этом случае пользователю рекомендуется не предпринимать никаких действий и просто дождаться, когда доступ восстановится автоматически.

Решение проблем с ошибкой 503 администратором веб-ресурса

При возникновении ошибки 503 Service Unavailable в любом ее проявлении администратор web-ресурса в первую очередь должен разобраться в причине ее появления. Игнорирование данной процедуры по принципу «само пройдет» может привести к тому, что сайт понесет глобальные потери в объеме пользовательского трафика и, как следствие, конверсии. Посетители, регулярно сталкивающиеся с проблемами доступа к определенному ресурсу, очень быстро занесут его в «игнор».

В зависимости от конкретного тарифного плана хостинга каждый сайт имеет ограничения по одновременной обработке запросов, поступающих на сервер от конечных пользователей. Более простые запросы браузеров обрабатываются практически мгновенно, сложные ожидают очереди в порядке их поступления. Количество отложенных запросов лимитировано, при превышении нормы каждый следующий отклоняется. В этом случае посетитель сайта видит на экране сообщение с кодировкой error 503.

Наиболее частые причины возникновения ошибки 503 на стороне сервера

1. При получении запроса от пользователя конкретная страница сайта не может установить соединение с базой данных MySQL.
2. Некорректная работа плагинов и расширений из-за внутренних ошибок или конфликта между собой.
3. Использование недорого хостинга и маломощного сервера приводит к тому, что оборудование не справляется с обработкой входящего трафика.
4. Ресурсоемкие скрипты создают дополнительную нагрузку на сервер.
5. Задействован почтовый сервис, выполняющий автоматическую рассылку сообщений в большом объеме.
6. Соединение с удаленным сервером может привести к замедлению обработки запросов.
7. Передача файлов большого объема при помощи PHP-скрипта.
8. Значительное количество нерабочих модулей конкретной CMS.

Как видим, решение практически всех проблем, приводящих к появлению ошибки 503, достигается использованием более мощных серверов и высокоскоростного качественного хостинга. Отрицательная сторона этого способа в его затратности. Распределение пользовательского трафика неравномерно по времени, и банальный апгрейд железа не поможет полностью исключить сбои в моменты пиковых нагрузок.

Как избежать появления ошибок 503

Для начала рекомендуется провести статистический анализ через административную панель (снять логи), чтобы понять, какие процессы создают максимальную нагрузку на сервер, и произвести определенные изменения в настройках.

Уменьшение нагрузки на базу данных можно добиться следующими способами:

• Регулярное обновление CMS, которое позволяет оптимизировать работу движка, уменьшить количество багов.
• Установка защиты от ботов и парсеров, которые часто запускаются вашими конкурентами, чтобы создать дополнительную нагрузку на ресурс и тем самым вывести его частично или полностью из строя.
• Уменьшение размера и, если это возможно, количества графических файлов на сайте, а также «тяжелых» таблиц.
• Ввод ограничений на количество одновременных участников в чате.

Оптимизация работы скриптов

• Отключите все лишние плагины и дополнения, кроме тех, которые реально необходимы для бесперебойной работы сайта (кэширование, оптимизация базы данных, создание бэкапов, сжатие изображений).
• Осуществляйте передачу файлов большого объема через FTP, т.к. использование других способов передачи данных приводит к созданию отдельного процесса.
• Осуществляйте массовую почтовую рассылку в моменты отсутствия пиковой нагрузки на сайт, например, ночью или ранним утром.
• При использовании удаленного сервера минимизируйте время ответа и оптимизируйте канал соединения.
• Проверьте наличие проблемных запросов к базе MySQL в файле mysql-slow.log.

Дополнительную нагрузку на сервер, приводящую к появлению ошибки 503, могут создать DDoS-атаки. Защита от них с помощью фильтрации относится к отдельной теме обсуждения.

Следует отметить, что ошибка 503, вызванная перегрузкой серверных мощностей, может пройти сама собой, без внешнего вмешательства. Чтобы понять, произошло ли исправление ситуации, достаточно периодически перезагружать сайт.

Заключение

Ошибка 503 Service Unavailable может возникнуть на любом сайте, управляемом одной из наиболее популярных CMS – WordPress (Вордпресс), Joomla (Джумла), DLE (ДЛЕ) и любой другой, использующей базы данных MySQL. Способов ее решения много, начиная от самых простых на уровне пользователя и заканчивая довольно сложными процедурами, которые должен выполнить администратор сайта.

Буду благодарен, если вы нашли нестандартный подход к устранению сбоя с кодировкой 503 и готовы поделиться своим опытом в комментариях!

My server was doing just fine up until yesterday. It was running Redmine, and it was the happiest little server until my «friend» imported a SQL table that my little guy couldn’t take. Unfortunately, after an hour of trying to get the lil guy to respond, we had to power cycle him.

Now after restart, we get a 503 error when trying to visit the domain connected to Redmine. It’s hooked up to a Mongrel daemon, and we use Apache Proxy to direct all connections to the port Redmine is running on.

Using Lynx on the server (http://localhost:8000) you can see the Ruby application working fine. But this bit is not working in my Apache configuration file:

<VirtualHost *:80>
    ServerName sub.example.com
    ProxyPass / http://localhost:8000
    ProxyPassReverse / http://localhost:8000
    ProxyPreserveHost on
    LogLevel debug
</VirtualHost>

Here’s the error log output for Apache:

[debug] mod_proxy_http.c(54): proxy: HTTP: canonicalising URL //localhost:8000
[debug] proxy_util.c(1335): [client 216.27.137.51] proxy: http: found worker http://localhost:8000 for http://localhost:8000/
[debug] mod_proxy.c(756): Running scheme http handler (attempt 0)
[debug] mod_proxy_http.c(1687): proxy: HTTP: serving URL http://localhost:8000/
[debug] proxy_util.c(1755): proxy: HTTP: has acquired connection for (localhost)
[debug] proxy_util.c(1815): proxy: connecting http://localhost:8000/ to localhost:8000
[debug] proxy_util.c(1908): proxy: connected / to localhost:8000
[debug] proxy_util.c(2002): proxy: HTTP: fam 2 socket created to connect to localhost

[error] (13)Permission denied: proxy: HTTP: attempt to connect to 127.0.0.1:8000 (localhost) failed
[error] ap_proxy_connect_backend disabling worker for (localhost)

[debug] proxy_util.c(1773): proxy: HTTP: has released connection for (localhost)

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?

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?