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

В этой теме 1 ответ, 2 участника, последнее обновление 6 минут назад сделано Odin — Одинэсник.

Просмотр 1 ветки ответов

Автор

Записи

8 октября 2026 в 11:41 #38822
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>

8 октября 2026 в 11:41 #38823

Участник

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

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

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

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

Выполните:

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

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

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

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

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

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

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

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

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

no live upstreams

1	no live upstreams

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

upstream timed out

1	upstream timed out

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

upstream prematurely closed connection

1	upstream prematurely closed connection

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

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

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 указано:

proxy_pass http://127.0.0.1:8080;

1	proxy_pass http://127.0.0.1:8080;

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

curl -I http://127.0.0.1:8080/

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

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

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

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

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

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:

sudo ss -ltnp | grep 8080

1	sudo ss -ltnp \| grep 8080

Для порта 80:

sudo ss -ltnp | grep ':80'

1	sudo ss -ltnp \| grep ':80'

Для HTTPS:

sudo ss -ltnp | grep ':443'

1	sudo ss -ltnp \| grep ':443'

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

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))

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

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

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

sudo systemctl status nginx

sudo systemctl status httpd

sudo systemctl status apache2

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

sudo systemctl restart httpd

1	sudo systemctl restart httpd

или:

sudo systemctl restart apache2

1	sudo systemctl restart apache2

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

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

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

или:

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

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

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

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

sudo nginx -t

1	sudo nginx -t

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

syntax is ok
test is successful

1 2	syntax is ok test is successful

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

sudo systemctl reload nginx

1	sudo systemctl reload nginx

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

sudo nginx -T

1	sudo nginx -T

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

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

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

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

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;

}

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

sudo nginx -t
sudo systemctl reload nginx

1 2	sudo nginx -t sudo systemctl reload nginx

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

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

location /mybase/ {

proxy_pass http://127.0.0.1:8080/mybase/;

}

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

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

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

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

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

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

nc -vz 192.168.1.10 8080

1	nc -vz 192.168.1.10 8080

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

telnet 192.168.1.10 8080

1	telnet 192.168.1.10 8080

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

sudo ss -ltnp | grep 8080

1	sudo ss -ltnp \| grep 8080

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

127.0.0.1:8080

1	127.0.0.1:8080

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

Listen 192.168.1.10:8080

1	Listen 192.168.1.10:8080

или:

Listen 0.0.0.0:8080

1	Listen 0.0.0.0:8080

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

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

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

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

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

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

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

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

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

Пример:

<?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>

<?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 должны быть указаны корректные параметры кластера и информационной базы.

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

sudo systemctl restart httpd

1	sudo systemctl restart httpd

или:

sudo systemctl restart apache2

1	sudo systemctl restart apache2

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

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

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

location /mybase/ {

proxy_pass http://127.0.0.1:8080;

}

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

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

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

location /mybase/ {

proxy_pass http://127.0.0.1:8080/mybase/;

}

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

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

location / {

proxy_pass http://127.0.0.1:8080;

}

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

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

location /api/ {

proxy_pass http://127.0.0.1:8080/ut_demo/hs/;

}

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

https://example.ru/api/test

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

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

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.

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

getenforce

1	getenforce

Если ответ:

Enforcing

Enforcing

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

sudo setsebool -P httpd_can_network_connect 1

1	sudo setsebool -P httpd_can_network_connect 1

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

sudo ausearch -m AVC -ts recent

1	sudo ausearch -m AVC -ts recent

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

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

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

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

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

sudo firewall-cmd --list-ports

1	sudo firewall-cmd --list-ports

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

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

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.

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

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

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

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

...

<center>nginx</center>

и в error.log есть:

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. Выполнить:

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.

Автор

Записи

Просмотр 1 ветки ответов

Для ответа в этой теме необходимо авторизоваться.

Вы пропустили

Новый курс «Администратор 1С v4.1»

Автономный сервер 1С — публикация ИБ

Установка PostgreSQL 17 для 1С на Windows server 2022

Как запустить «Сервер 1С» на Ubuntu 24.04 LTS ?