Как устранить ошибку 503 Service Temporarily Unavailable в nginx при работе с 1С

[Odineski]

: <html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx</center>
</body>
</html>

[Odin — Одинэсник]

Ошибка 503 Service Temporarily Unavailable от nginx означает, что nginx не может получить нормальный ответ от backend-сервера. В схеме с 1С backend обычно это:

— Apache или IIS;
— публикация 1С;
— сервер 1С, если публикация работает через веб-сервер;
— upstream, указанный в конфигурации nginx.

Сам nginx запущен, но сервис за ним недоступен либо сам вернул ошибку 503.

## 1. Сначала посмотрите журнал nginx

Выполните:

Shell

sudo tail -n 100 /var/log/nginx/error.log

1	sudo tail -n 100 /var/log/nginx/error.log

И отдельно журнал доступа:

Shell

sudo tail -n 100 /var/log/nginx/access.log

1	sudo tail -n 100 /var/log/nginx/access.log

Особенно важны сообщения:

1С (Код)

connect() failed (111: Connection refused) while connecting to upstream

1	connect() failed (111: Connection refused) while connecting to upstream

Это означает, что на указанном порту не запущен Apache, IIS или другой backend.

1С (Код)

no live upstreams

1	no live upstreams

Обычно означает ошибку в блоке upstream или недоступность всех серверов из группы.

1С (Код)

upstream timed out

1	upstream timed out

Backend отвечает слишком долго. Для 1С это может быть зависшая публикация, проблемы с сервером 1С или слишком маленькие тайм-ауты.

1С (Код)

upstream prematurely closed connection

1	upstream prematurely closed connection

Backend принял соединение, но закрыл его до формирования ответа.

Пример команды, чтобы сразу отфильтровать важные ошибки:

Shell

sudo grep -iE "upstream|connect|refused|timed out|no live" /var/log/nginx/error.log | tail -n 50

1	sudo grep -iE "upstream|connect|refused|timed out|no live" /var/log/nginx/error.log | tail -n 50

## 2. Проверьте backend напрямую, минуя nginx

Допустим, в конфигурации nginx указано:

1С (Код)

proxy_pass http://127.0.0.1:8080;

1	proxy_pass http://127.0.0.1:8080;

Тогда выполните на сервере:

Shell

curl -I http://127.0.0.1:8080/

1	curl -I http://127.0.0.1:8080/

Для публикации 1С, например:

Shell

curl -I http://127.0.0.1:8080/mybase/

1	curl -I http://127.0.0.1:8080/mybase/

Если используется IP другого сервера:

Shell

curl -I http://192.168.1.10:8080/mybase/

1	curl -I http://192.168.1.10:8080/mybase/

Результаты трактуются так:

— Connection refused
На порту никто не слушает либо доступ запрещен firewall.

— Connection timed out
Проблема с сетью, маршрутизацией или firewall.

— 404 Not Found
Backend доступен, но указан неправильный путь публикации.

— 401 Unauthorized или 403 Forbidden
Backend доступен, но требуется авторизация либо запрещен доступ.

— 503 Service Unavailable
Сам backend вернул 503. В этом случае проблему нужно искать не в nginx, а в Apache, IIS, публикации или сервере 1С.

— HTML страницы 1С или ответ HTTP-сервиса
Связь между nginx и backend работает, нужно проверять маршрутизацию URL.

## 3. Проверьте, слушается ли нужный порт

Для Apache, например, порт 8080:

Shell

sudo ss -ltnp | grep 8080

1	sudo ss -ltnp | grep 8080

Для порта 80:

Shell

sudo ss -ltnp | grep ':80'

1	sudo ss -ltnp | grep ':80'

Для HTTPS:

Shell

sudo ss -ltnp | grep ':443'

1	sudo ss -ltnp | grep ':443'

В нормальном случае будет что-то подобное:

1С (Код)

LISTEN 0 511 127.0.0.1:8080 0.0.0.0:* users:(("httpd",pid=1234,fd=4))

1	LISTEN 0 511 127.0.0.1:8080 0.0.0.0:* users:(("httpd",pid=1234,fd=4))

Если вывода нет, сервис на этом порту не запущен или слушает другой порт.

Проверьте службы:

Shell

sudo systemctl status nginx sudo systemctl status httpd sudo systemctl status apache2

1 2 3

sudo systemctl status nginx sudo systemctl status httpd sudo systemctl status apache2

На разных Linux-дистрибутивах Apache называется по-разному:

Shell

sudo systemctl restart httpd

1	sudo systemctl restart httpd

или:

Shell

sudo systemctl restart apache2

1	sudo systemctl restart apache2

После перезапуска проверьте журнал:

Shell

sudo journalctl -u httpd -n 100 --no-pager

1	sudo journalctl -u httpd -n 100 --no-pager

или:

Shell

sudo journalctl -u apache2 -n 100 --no-pager

1	sudo journalctl -u apache2 -n 100 --no-pager

## 4. Проверьте конфигурацию nginx

Сначала выполните:

Shell

sudo nginx -t

1	sudo nginx -t

Если проверка успешна:

1С (Код)

syntax is ok test is successful

1 2	syntax is ok test is successful

перечитайте конфигурацию:

Shell

sudo systemctl reload nginx

1	sudo systemctl reload nginx

Посмотрите фактически загруженную конфигурацию:

Shell

sudo nginx -T

1	sudo nginx -T

Полезно проверить, не используется ли другой конфигурационный файл или другой proxy_pass.

## 5. Типовая конфигурация nginx для публикации 1С

Если Apache слушает 127.0.0.1:8080, а публикация 1С называется mybase, конфигурация может выглядеть так:

1С (Код)

server { listen 80; server_name 1c.example.ru; access_log /var/log/nginx/1c_access.log; error_log /var/log/nginx/1c_error.log; location /mybase/ { proxy_pass http://127.0.0.1:8080/mybase/; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 60s; proxy_send_timeout 300s; proxy_read_timeout 300s; proxy_buffering off; } }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

server {     listen 80;     server_name 1c.example.ru;       access_log /var/log/nginx/1c_access.log;     error_log  /var/log/nginx/1c_error.log;       location /mybase/ {         proxy_pass http://127.0.0.1:8080/mybase/;           proxy_http_version 1.1;           proxy_set_header Host $host;         proxy_set_header X-Real-IP $remote_addr;         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;         proxy_set_header X-Forwarded-Proto $scheme;           proxy_connect_timeout 60s;         proxy_send_timeout 300s;         proxy_read_timeout 300s;           proxy_buffering off;     } }

После изменения:

Shell

sudo nginx -t sudo systemctl reload nginx

1 2	sudo nginx -t sudo systemctl reload nginx

Обратите внимание на завершающий /:

1С (Код)

location /mybase/ { proxy_pass http://127.0.0.1:8080/mybase/; }

1 2 3

location /mybase/ {     proxy_pass http://127.0.0.1:8080/mybase/; }

Для публикаций 1С лучше явно указывать одинаковый путь в location и proxy_pass. Неправильное сочетание путей может приводить к обращению не к той публикации и появлению ошибок 404 или 503.

## 6. Если nginx и Apache находятся на разных серверах

Проверьте backend с сервера nginx:

Shell

curl -v http://192.168.1.10:8080/mybase/

1	curl -v http://192.168.1.10:8080/mybase/

Проверьте доступность порта:

Shell

nc -vz 192.168.1.10 8080

1	nc -vz 192.168.1.10 8080

Если nc не установлен:

Shell

telnet 192.168.1.10 8080

1	telnet 192.168.1.10 8080

На сервере Apache проверьте, на каком адресе он слушает:

Shell

sudo ss -ltnp | grep 8080

1	sudo ss -ltnp | grep 8080

Если Apache слушает только:

1С (Код)

127.0.0.1:8080

1	127.0.0.1:8080

то к нему нельзя подключиться с другого сервера. Для межсерверной схемы Apache должен слушать сетевой адрес сервера, например:

Apache

Listen 192.168.1.10:8080

1	Listen 192.168.1.10:8080

или:

Apache

Listen 0.0.0.0:8080

1	Listen 0.0.0.0:8080

При этом порт 8080 желательно закрыть от внешнего доступа firewall и разрешить только IP сервера nginx.

## 7. Проверьте саму публикацию 1С

На сервере с Apache выполните запрос непосредственно к публикации:

Shell

curl -v http://127.0.0.1:8080/mybase/

1	curl -v http://127.0.0.1:8080/mybase/

Проверьте наличие файла публикации:

Shell

sudo find / -name default.vrd 2>/dev/null

1	sudo find / -name default.vrd 2>/dev/null

В default.vrd должны быть корректно указаны сервер, имя информационной базы и параметры публикации.

Пример:

1С (Код)

<?xml version="1.0" encoding="UTF-8"?> <point xmlns="http://v8.1c.ru/8.2/virtual-resource-system" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" base="/mybase" ib="Srvr="localhost";Ref="mybase";"> </point>

1 2 3 4 5 6 7

<?xml version="1.0" encoding="UTF-8"?> <point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"        xmlns:xs="http://www.w3.org/2001/XMLSchema"        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        base="/mybase"        ib="Srvr="localhost";Ref="mybase";"> </point>

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

После изменения публикации перезапустите веб-сервер:

Shell

sudo systemctl restart httpd

1	sudo systemctl restart httpd

или:

Shell

sudo systemctl restart apache2

1	sudo systemctl restart apache2

## 8. Частая ошибка при использовании proxy_pass

Неправильный вариант:

1С (Код)

location /mybase/ { proxy_pass http://127.0.0.1:8080; }

1 2 3

location /mybase/ {     proxy_pass http://127.0.0.1:8080; }

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

Более предсказуемый вариант:

1С (Код)

location /mybase/ { proxy_pass http://127.0.0.1:8080/mybase/; }

1 2 3

location /mybase/ {     proxy_pass http://127.0.0.1:8080/mybase/; }

Если nginx должен проксировать весь backend без изменения URL:

1С (Код)

location / { proxy_pass http://127.0.0.1:8080; }

1 2 3

location / {     proxy_pass http://127.0.0.1:8080; }

Если нужно заменить внешний путь /api/ на путь публикации /ut_demo/hs/:

1С (Код)

location /api/ { proxy_pass http://127.0.0.1:8080/ut_demo/hs/; }

1 2 3

location /api/ {     proxy_pass http://127.0.0.1:8080/ut_demo/hs/; }

Например, запрос:

1С (Код)

https://example.ru/api/test

1	https://example.ru/api/test

будет передан backend как:

1С (Код)

http://127.0.0.1:8080/ut_demo/hs/test

1	http://127.0.0.1:8080/ut_demo/hs/test

## 9. Проверьте SELinux

На CentOS, RedOS, AlmaLinux, Rocky Linux причиной блокировки подключения nginx к backend может быть SELinux.

Проверьте его состояние:

Shell

getenforce

1	getenforce

Если ответ:

1С (Код)

Enforcing

1

Enforcing

разрешите nginx сетевые подключения:

Shell

sudo setsebool -P httpd_can_network_connect 1

1	sudo setsebool -P httpd_can_network_connect 1

Проверьте сообщения SELinux:

Shell

sudo ausearch -m AVC -ts recent

1	sudo ausearch -m AVC -ts recent

После этого снова проверьте:

Shell

curl -I http://127.0.0.1:8080/mybase/

1	curl -I http://127.0.0.1:8080/mybase/

## 10. Проверьте firewall

Если backend находится на другом сервере, на нем должен быть разрешен порт, например 8080:

Shell

sudo firewall-cmd --list-ports

1	sudo firewall-cmd --list-ports

Разрешить порт только для сервера nginx лучше адресно:

Shell

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.20" port protocol="tcp" port="8080" accept' sudo firewall-cmd --reload

1 2 3 4

sudo firewall-cmd --permanent     --add-rich-rule='rule family="ipv4" source address="192.168.1.20" port protocol="tcp" port="8080" accept'   sudo firewall-cmd --reload

Где 192.168.1.20 это IP сервера nginx.

## Наиболее вероятная причина

Если после запроса вы видите именно стандартную страницу:

XHTML

<center><h1>503 Service Temporarily Unavailable</h1></center> ... <center>nginx</center>

1 2 3

<center><h1>503 Service Temporarily Unavailable</h1></center> ... <center>nginx</center>

и в error.log есть:

1С (Код)

connect() failed (111: Connection refused) while connecting to upstream

1	connect() failed (111: Connection refused) while connecting to upstream

то обычно исправление такое:

1. Узнать backend из proxy_pass.
2. Проверить его командой curl напрямую.
3. Запустить Apache или IIS.
4. Проверить, что публикация 1С действительно слушает указанный порт.
5. Исправить адрес или порт в proxy_pass.
6. Выполнить:

Shell

sudo nginx -t sudo systemctl reload nginx

1 2	sudo nginx -t sudo systemctl reload nginx

Точный диагноз по одной HTML-странице определить нельзя. Ключевая информация находится в /var/log/nginx/error.log и в результате команды curl к адресу из proxy_pass.

[Автор]

Записи