Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее. Думаю не все знают как выглядит заголовок ответа сервера, зато уверен, каждый, пользующийся интернетом, не раз сталкивались, со страницей 404 Not Found или 403 Forbadden . Это и есть, видимый пользователю результат, выдачи сервером, того или иного кода статуса в строке заголовке.

Коды состояния HTTP , разделены на 5 категорий. Клиент может быть не знаком с тем или иным кодом ответа HTTP , однако он должен отреагировать согласно категории кода. Итак протокол HTTP поддерживает следующие коды статуса, разделенные по категориям:

1xx: Information — информационные

100 Continue — Продолжать. Сервер доволен данными в запросе клиента, можно продолжать передачу заголовков HTTP/1.1 . 101 Switching Protocols — Переключение протоколов. Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1. 102 Processing — Обрабатывается. Используется в протоколе WebDAV , работающем поверх HTTP протокола. Данный код статуса информирует клиента о том, что запрос принят, но на его обработку может понадобится определенное время, что-бы он (клиент), не сбрасывал соединение. Клиент в этом случае должен обнулить таймер и ожидать следующей команды.

2xx: Success — Успешное завершение

200 OK — Хорошо. Запрос к ресурсу выполнен успешно. Данные, запрошенные клиентом, находятся в заголовке и/или в теле ответа. Появился в протоколе версии HTTP/1.0. 201 Created — Создано. Запрос выполнен успешно, новый ресурс создан. В ответе сервера, в заголовке Location , указывается местоположение созданного ресурса. Кроме того, серверу рекомендуется указывать характеристики созданного ресурса, в заголовке ответа. Появился в протоколе версии HTTP/1.0 . 202 Accepted — Принято. Запрос принят, но еще в обработке. Появился в протоколе версии HTTP/1.0 . 203 Non-Authoritative Information — Информация из неавторитетного источника. Аналогично коду 200, но в данном случае информация может быть неактуальной, так как взята не из первоисточника. Появился в протоколе версии HTTP/1.1 . 204 No Content — Отсутствует содержимое. Сервер успешно обработал запрос, но не вернул содержимого. Появился в протоколе версии HTTP/1.0 . 205 Reset Content — Сбросить содержимое. Сервер успешно обработал запрос, но не вернул содержимого. В отличии от кода 204, данный код, требует от клиента, сбросить представление документа. Появился в протоколе версии HTTP/1.1 . 206 Partial Content — Часть содержимого. Сервер вернул результат запроса клиентом, части содержимого, с помощью заголовка range. Используется для докачки файлов или для многопоточной закачки. Появился в протоколе версии HTTP/1.1 . 207 Multi-Status — Многостатусный. Возвращаемое сервером тело сообщения, представляет из себя XML документ со статусами выполнения нескольких подзапросов. Используется в протоколе WebDAV . 226 IM Used — Использовано IM Расширение HTTP для поддержки «дельта кодирования» (delta encoding ). Заголовок A-IM принят, данные возвращаются согласно установленным параметрам.

3xx: Redirection — Редирект (перенаправление)

Коды данной категории, сообщают клиенту, что для завершения запроса, ему необходимо выполнить дополнительный запрос, как правило по другому URI , соответствующий адрес указывается в строке Location , ответа сервера. Программа — клиент может совершать дополнительные запросы без участия пользователя, при условии что дополнительный запрос делается методами GET или HEAD .

Некоторые клиенты некорректно работают с редиректами 301 и 302 , применяя в запросе ко второму ресурсу метод GET , несмотря на то, что первый запрос был сделан с использованием другого метода. В протоколеHTTP версии 1.1 , вместо ответа статуса 302 , были введены дополнительные коды ответов, 303 и 307 . Изменять метод, необходимо только в случает ответа сервера со статусом 303 , в остальных случаях использовать исходный метод.

300 Multiple Choices — Несколько вариантов выбора. По запрошенному URI , существует несколько вариантов ресурса, различных по MIME типу. языку или другим признакам. В ответе сервера, передается список альтернатив, выбираемый клиентским приложением автоматически или самим пользователем. Появился в протоколе версии HTTP/1.0 . 301 Moved Permanently — Перемещёно окончательно. Запрошенный ресурс был окончательно перемещен на URI , указанный в строке заголовка Location , ответа сервера. Некоторые клиенты, при обработке данного кода, ведут себя некорректно, см. выше. Появился в протоколе версии HTTP/1.0 . 302 Found — Найдено (Moved Temporarily) Данный код статуса сообщает клиенту, что ресурс временно доступен по другому URI Location , заголовка ответа сервера. Данный код используется например, при согласовании содержимого (Content Negotiation ), выполняемого сервером. Появился в протоколе версии HTTP/1.0. 303 See Other — Смотреть другое. Документ из запрошенного URI , нужно запросить по адресу, указанному в строке заголовка Location , заголовка ответа сервера, используя метод GET , невзирая на то, каким методом был сделан первый запрос. Появился в протоколе версии HTTP/1.1. 304 Not Modified — Не изменялось. Данный код выдается в случае запроса документа, методом GET , с использованием заголовков If-Modified-Since или If-None-Match , и документ не был изменен с указанного момента времени. Появился в протоколе версии HTTP/1.0 . 305 Use Proxy — Использовать прокси сервер. Запрос к ресурсу, должен выполняться через прокси-сервер., адрес которого, указан в строке заголовка Location , заголовка ответа сервера. Появился в протоколе версии HTTP/1.1. 307 Temporary Redirect — Временное перенаправление Запрошенный ресурс временно доступен по URI , указанному в строке заголовка Location , заголовка ответа сервера. Появился в протоколе версии HTTP/1.1 .

4xx: Client Error — Ошибка клиента

Коды данной категории служат для указание на ошибку со стороны клиента. При использовании любых методов запроса, кроме HEAD , сервера возвращает пользователю гипертекстовое пояснение по данной ошибке.

400 Bad Request — Плохой запрос. Из-за синтаксической ошибки, запрос не был понят сервером. Появился в протоколе версии HTTP/1.0 . 401 Unauthorized — Не авторизован. Ресурс требует идентификации пользователя. Клиентское приложение запрашивает у пользователя данные для аутентификации (имя, пароль) и передает их на сервер в заголовке WWW-Authenticate . Если данные указаны не правильно, будет снова выдан этот-же код статуса. Появился в протоколе версии HTTP/1.0. 402 Payment Required — Необходима оплата. Пока не используется. Появился в протоколе версии HTTP/1.1. 403 Forbidden — Запрещено. Сервер отказал в доступе к запрошенному ресурсу ввиду ограничений. Ограничения могут быть любыми, установленными администратором сервера, или определенным веб приложением. Например, в целях безопасности, закрыт доступ к файлу, .htacces или .htpasswd или к закрытой директории сайта, или в случае, когда аутентификация должна производится через веб приложение (например сайтовый движок), ну или блокировка по IP адресу, в случае слишком частых обращений. Появился в протоколе версии HTTP/1.0 . 404 Not Found — Не найдено. Сервер не нашел запрошенный ресурс по указанному адресу. Кроме того данный код ответа можно использовать вместо 403, с целью, скрыть расположение документа, доступ к которому запрещен. Появился в протоколе версии HTTP/1.0 . 405 Method Not Allowed — Метод не поддерживается. Клиент попытался использовать метод, недопустимый для данного ресурса. Сервер передает в заголовке, строку Allow , содержащую список допустимых методов. Появился в протоколе версии HTTP/1.1 . 406 Not Acceptable — Не приемлемо. Запрошенный ресурс, не удовлетворяет, запрошенные характеристики. В случае, если запрос был сделан не методом HEAD , сервер вернет список допустимых характеристик запрошенного ресурса. Появился в протоколе версии HTTP/1.1. 407 Proxy Authentication Required — Необходима прокси авторизация. Данный код статуса, аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Появился в протоколе версии HTTP/1.1 . 408 Request Timeout — Время ожидания истекло. Истек таймаут ожидания передачи данных, между сервером и клиентом. Появился в протоколе версии HTTP/1.1 . 409 Conflict — Конфликт. Конфликтная ситуация при обращении к ресурсу. Такое может произойти, например, при попытке одновременного изменения файла, методом PUT , несколькими клиентами. Появился в протоколе версииHTTP/1.1 . 410 Gone — Удалён. Данный ответ выдается в случае, если документ был по указанному URI , но в данный момент удален. Появился в протоколе версии HTTP/1.1 . 411 Length Required — Необходима длина. Этот код статуса говорит о том, что для данного URI , в заголовке запроса, должно быть указано значение в поле Content-Length . Появился в протоколе версии HTTP/1.1. 412 Precondition Failed — Условие «ложно. Данный код выдается в случае, если ни одно из условных полей заголовка не было удовлетворено. Появился в протоколе версии HTTP/1.1. 413 Request Entity Too Large — Запрошены слишком большие данные. Данный код выдается, если сервер по каким-либо причинам, не может передать, требуемый объем данных. Если это временная проблема, сервер может указать время, по истечении которого можно будет попробовать повторно запросить ресурс, в строке заголовка, Retry-After . Появился в протоколе версии HTTP/1.1. 414 Request-URI Too Long — Запрашиваемый URI слишком длинный. Слишком длинная строка запроса. Такая ситуация может произойти, например в случае попытки, передать данные методом GET , вместо использования POST . Появился в протоколе версии HTTP/1.1. 415 Unsupported Media Type — Неподдерживаемый тип данных. Сервер, по какой-то причине, отказался обрабатывать запрошенные данные, используемым методом. Появился в протоколе версии HTTP/1.1. 416 Requested Range Not Satisfiable — Запрашиваемый диапазон не достижим. В строке заголовка запроса Range, установлен диапазон, выходящий за рамки запрошенного ресурса и отсутствует строка If-Range . Появился в протоколе версии HTTP/1.1. 417 Expectation Failed — Ожидаемое не приемлемо. Сервер не может обработать строку заголовка запроса Expect . Появился в протоколе версии HTTP/1.1. 422 Unprocessable Entity — Необрабатываемый экземпляр. Запрос принят, тип данных может быть обработан, синтаксис XML данных в теле запроса верен, но имеет место логическая ошибка, не позволяющая обработать запрос к ресурсу. Используется в протоколеWebDAV . 423 Locked — Заблокировано. Запрошенный ресурс заблокирован от данного метода. Используется в протоколе WebDAV . 424 Failed Dependency — Невыполненная зависимость. Выполнение запроса, может зависеть от результата выполнения, какой-либо другой операции, при невыполнении данного условия, будет выдан этот код статуса. Используется в протоколе WebDAV . 425 Unordered Collection — Беспорядочный набор. Этот код статуса будет выдан в случае, если клиент отправил запрос обозначив положение в неотсортированной коллекции или используя порядок следования элементов отличный от серверного. Введено в черновике по WebDAV Advanced Collections Protocol . 426 Upgrade Required — Требуется обновление. Указание сервера, клиенту, обновить протокол. Заголовок ответа, должен содержать правильно составленные поля Upgrade и Connection . Введено в RFC 2817 для возможности перехода к TLS посредствомHTTP . 449 Retry With — Повторить с… Выдается в случае поступления не достаточного количества информации для обработки запроса. В заголовок ответа сервера, помещается строка Ms-Echo-Request . Введено корпорацией Microsoft дляWebDAV .

5xx: Server Error — Ошибка на стороне сервера

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

500 Internal Server Error — Внутренняя ошибка сервера. Любая внутренняя ошибка на стороне сервера не подпадающая под остальные ошибки из категории 5хх. Появился в протоколе версии HTTP/1.0. 501 Not Implemented — Не реализовано. Сервер не поддерживает, необходимых для обработки запроса, возможностей. (например не поддерживается необходимый метод обработки). Появился в протоколе версии HTTP/1.0 . 502 Bad Gateway — Плохой шлюз. Сервер, работающий в качестве прокси или шлюза, получил сообщение о неудачное в промежуточной операции. Появился в протоколе версии HTTP/1.0 . 503 Service Unavailable — Сервис недоступен. Сервер не в состоянии обрабатывать запросы клиентов по техническим причинам. Появился в протоколе версии HTTP/1.0 . 504 Gateway Timeout — Истек таймаут ожидания ответа шлюза. Проксирующий сервер или шлюз, не дождался ответа от вышестоящего сервера для завершения обработки запроса. Появился в протоколе версии HTTP/1.0 . 505 HTTP Version Not Supported — Версия HTTP протокола не поддерживается. Сервер не поддерживает, или не может обработать, указанную в заголовке версию HTTP протокола. Появился в протоколе версии HTTP/1.0. 506 Variant Also Negotiates — Вариант тоже согласован. Из-за не верной конфигурации, выбранный вариант указывает сам на себя, в следствии чего, связывание прерывается. Добавлено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation . 507 Insufficient Storage — Переполнение хранилища. Недостаточно места для обработки текущего запроса. Возможно временная проблема. Используется в протоколе WebDAV . 509 Bandwidth Limit Exceeded — Пропускная возможность канала исчерпана. Данный код статуса, используется в случае превышения веб площадкой, отведенного ей лимита, на потребляемый трафик. Данный код не описан ни одним RFC и используется только модулем bw/limited , панели веб-хостинга cPanel . 510 Not Extended — Нет расширения. У сервера отсутствует расширение, которое пытается использовать клиентом. Сервер может передавать информацию, об имеющихся у него расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

Методы обработки запросов HTTP

HTTP метод — это основная операция, которую необходимо выполнить над ресурсом. В названии могут использоваться любые символы, кроме управляющих последовательностей и разделителей, как правило это короткое слово на английском языке. Имена методов HTTP зависимы от регистра.

Любой веб сервер обязан работать, по крайней мере с двумя методами GET и HEAD . Если сервер не смог определить метод, указанный в заголовке запроса клиента, он должен вернуть код статуса 501 (Not Implemented) , если-же метод серверу известен, но неприменим к данному ресурсу, будет возвращен код статуса 405 (Method Not Allowed) . Как в первом, так и во втором случае, сервер должен включить в свой ответ, заголовок Allow со списком методов, которые он поддерживает.

Метод OPTIONS

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

Что-бы выяснить возможности сервера, клиент должен указать в запросе URI , символ — «* «, то есть данный запрос к серверу выглядит как: OPTIONS * HTTP/1.1 . Кроме прочего, данный запрос может быть использован для проверки работоспособности сервера и поддержки им протокола HTTP , версии 1.1 . Результаты данного запроса не кэшируются.

Метод GET

Метод GET , применяется для запроса конкретного ресурса. Так-же с помощью GET , может быть инициирован некий процесс, при этом, в тело ответа, включается информация о ходе выполнения инициированного запросом действия.

Параметры для выполнения запроса, передаются в URI запрашиваемого ресурса, после символа «? «. Запрос в таком случае выглядит примерно так: GET /some/resource?param1=val1¶m2=val2 HTTP/1.1 .

Как установлено в стандарте HTTP , запросы методом GET , являются идемпотентными, то есть, повторная отправка одного и того-же запроса, методом GET , должна приводить к одному и тому-же результату, в случае, если сам ресурс, в промежутках между запросами, изменен не был, что позволяет кэшировать результаты, выдаваемые на запрос методом GET .

Кроме вышесказанного, существуют еще два вида метода GET , это:
условный GET , содержащий заголовки If-Modified-Since, If-Match, If-Range и им подобные,
Частичный GET , содержащий заголовок Range с указанием байтового диапазона данных, которые сервер должен отдать. Данный вид запроса используется для докачки и организации многопоточных закачек.

Порядок работы с этими подвидами запроса GET , стандартами определен отдельно.

Метод HEAD

Данный метод, аналогичен методу GET , с той лишь разницей, что сервер не отправляет тело ответа. Метод HEAD , как правило используется для получения метаданных ресурса, проверки URL (есть-ли указанный ресурс на самом деле) и для выяснения факта изменения ресурса с момента последнего обращения к нему.

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

Метод POST

Метод POST , используется для передачи пользовательских данных на сервер, указанному ресурсу. Примером может послужить HTML форма с указанным атрибутом Method=»POST» , для отправки комментария к статье. После заполнения необходимых полей формы, пользователь жмет кнопку «Отправить» и данные, методом POST , передаются серверному сценарию, который в свою очередь выводит их на странице комментариев. Таким-же образом, с помощью метода POST , можно передавать файлы.

В отличии от GET , метод POST , не является идемпотентным, то есть неоднократное повторение запроса POST , может выдавать разные результаты. В нашем случае, будет появляться новая копия комментария при каждом запросе.

Если в результате запроса методом POST , возвращается код 200 (Ok) или 204 (No Content) , в тело ответа сервера, добавляется сообщение о результате выполнения запроса. Например, если был создан ресурс, сервер вернет 201 (Created) , указав при этом URI созданного ресурса в заголовке Location .

Ответы сервера, на выполнение метода POST , не кэшируются.

Метод PUT

Используется для загрузки данных запроса на указанный URI . В случае отсутствия ресурса по указанному в заголовке URI , сервер создает его и возвращает код статуса 201 (Created) , если ресурс присутствовал и был изменен в результате запроса PUT , выдается код статуса 200 (Ok) или 204 (No Content) . Если какой-то из переданных серверу заголовков Content-* , не опознан или не может быть использован в данной ситуации, сервер возвращает статус ошибки 501 (Not Implemented) .

Главное различие методов PUT и POST в том, что при методе POST , предполагается, что по указанному URI , будет производиться обработка, передаваемых клиентом данных, а при методе PUT , клиент подразумевает, что загружаемые данные уже соответствуют ресурсу, расположенному по данному URI .

Ответы сервера при методе PUT не кэшируются.

Метод PATCH

Работает аналогично методу PUT , но применяется только к определенному фрагменту ресурса.

Метод DELETE

Удаляет ресурс, расположенный по заданному URI.

Метод TRACE

При запросе методом TRACE, клиент может увидеть, какие изменения были сделаны в запросе, промежуточными серверами.

для платформы 8.2:

для платформы 8.3:

Замечание. Автоматическое обновление тонкого клиента под Windows XP и Windows Vista через 1С:Линк может не работать. Это не очень удобно и мы рекомендуем вам рассмотреть возможность перехода на более современную операционную систему.

Настройка Тонкого Клиента 1С для работы с платформой "1С: Предприятие 8" версии 8.3.4.437 и выше

Установите корневой сертификат сервиса "1С: Линк" в хранилище сертификатов Windows согласно инструкции для браузера Internet Explorer .

https://<ваш-сайт>.link.1c.ru/xxx

В качестве способа проверки сертификата сервера выберите пункт "Сертификаты Windows"

Нажмите кнопку "Готово"

Настройка автоматической авторизации на веб-сервере

• Выберите в Тонком клиенте 1С нужную ИБ и нажмите кнопку "изменить"
• Нажмите на ссылку "Дополнительно" (расположена под полем с адресом информационной базы)
• В разделе "Выберите способ аутентификации пользователя веб-сервера" выберите пункт "Выбирать автоматически" и нажмите "Далее".
• В окне настроек сертификата нажмите "Далее".
• В разделе "Дополнительные параметры запуска" укажите строку: где login - логин пользователя веб сервера, а password - его пароль.

Нажмите кнопку "Готово" и проверьте подключение к информационной базе.

Подробнее о настройках Тонкого клиента на сайте ИТС .

Настройка Тонкого Клиента 1С для работы с платформой "1С: Предприятие 8" версии 8.2.19.121 и выше

Для работы в тонком клиенте загрузите . Сохраните вместо <1C>\bin\cacert.pem , где <1C> - директория установки Тонкого клиента 1С. Это предотвратит появление ошибки SSL "Peer certificate cannot be authenticated with known CA certificates".

Введите название информационной базы, выберите пункт "Веб-сервер" и нажмите кнопку "Далее"

Введите адрес вашей информационной базы: https://<ваш-сайт>.link.1c.ru/xxx ,где xxx - ваш путь веб приложения.

Нажмите кнопку "Готово"

Настройка Тонкого Клиента 1С для работы с платформой "1С: Предприятие 8" версий, не входящих в список рекомендованных

Если для работы в сервисе "1С: Линк" вы хотите использовать версию тонкого клиента, отличную от рекомендованных выше, может потребоваться настройка работы по HTTP или установка STunnel .

Настройка Тонкого Клиента для работы через HTTP

В Линк-агенте есть возможность работать в тонком клиенте по протоколу HTTP. Однако, предпочтительным протоколом для работы в тонком клиенте через 1С:Линк является HTTPS. Не рекомендуется использовать протокол http, так как при его использовании данные передаются в незашифрованном виде и могут быть перехвачены злоумышленником.

Если вы уверены в необходимости использования данного протокола для работы в тонком клиенте через сервис 1С:Линк, можно воспользоваться инструкциями, которые представлены ниже:

Откройте панель управления линк-агентом и разрешите работу по HTTP (раздел 4.4 руководства пользователя 1С:Линк).

Настройте тонкий клиент:

Запустите тонкий клиент и нажмите кнопку добавить.

Введите название информационной базы, выберите пункт "Веб-сервер" и нажмите кнопку "Далее"

Введите адрес вашей информационной базы: http://<ваш-сайт>.link.1c.ru/xxx ,где xxx - ваш путь веб приложения.

Нажмите кнопку "Готово"

Установка и настройка Stunnel

На компьютер с Тонким Клиентом 1С установите программу Stunnel . После установки программы запустите её.

В открывшемся окне выберите пунк "Configuration"

В выпавшем меню укажите пункт "Edit stunnel.conf"

Откроется блокнот с конфигурационным файлом. Замените текст в файле на следующие строки.

Большинство проблем при подключении к серверу 1С:Предприятия связаны с адресами машин и доступностью серверов кластера сервера 1С.

Ошибка "Затребованное имя допустимо"

При подключении к серверу 1С:Предприятия получаем ошибку:

Server_addr=tcp://localhost.localdomain:1562 descr=Ошибка сетевого доступа к серверу (Windows Socket-11004(0х00002AFC). Затребованное имя допустимо и оно найдено в базе данных, но для имени отсутствует связанные с ним данные, которые были разрешены для него.) line=259 file=.\src\DataExchangeTcpClientlmpl.cpp

Ошибка 11004 показывает, что указанному имени сервера в DNS нет соответствующей записи типа A, которая определяет его IP адрес.

"Ошибка при выполнении операции с информационной базой" "Ошибка сетевого доступа к серверу" (Windows Sockets 11001(0x00002AF9). Этот хост неизвестен.)

Возможное решение

На ошибку "Затребованное имя допустимо и оно найдено в базе данных, но для имени отсутствует связанные с ним данные, которые были разрешены для него " в файлах

/home/usr1cv81/1c/1cv81/srvibrg.lst и /home/usr1cv81/1c/1cv81/reg_1541/s1CV8Reg.lst

нужно заменить везде localhost.localdomain (или адрес, который там указан) на IP-адрес сервера сервера (в кавычках), либо на имя машины (тоже в кавычках). При указании имени машины нужно обеспечить для имён машин прямую зону в DNS, а для IP-адресов - обратную.

Проверить этот совет не представилось возможным, т.к. не удалось воспроизвести проблему

Ошибка сетевого доступа к серверу

При запуске базы в режиме предприятия получаем ошибку: descr = Ошибка сетевого доступа к серверу (Windows Sockets - 10004(0x00002714).@) line=870 file=.\src\DataExchangeServerImpl.cpp

В качестве решения нужно прописать адрес и имя сервера в /etc/hosts

Дальнейшие действия для локализации проблемы.

1. Удостовериться в правильной и полной установки пакетов.

rpm -qa | grep nterprise

должно быть примерно:

1C_Enterprise-ws-nls-8.1.12-101

1C_Enterprise-crs-8.1.12-101

1C_Enterprise-server-nls-8.1.12-101

1C_Enterprise-crs-nls-8.1.12-101

1C_Enterprise-common-nls-8.1.12-101

1C_Enterprise-ws-8.1.12-101

1C_Enterprise-server-8.1.12-101

1C_Enterprise-common-8.1.12-101

2. Удостовериться в правильном и полном запуске сервера

1. ps aux | grep 1c

(должно быть ragent, rmngr, rphost)

3. Удостовериться в наличии и правильном содержании файлов srvribrg.lst 1CV8Reg.lst

4. Включить логи и изучить ошибки

Недоступность порта

Возможно не все сервера на кластере запустились. Проверить можно командой netstat -apn | grep:15 (выведет процессы, слушающие порты 15xx). Незапущенность серверов обычно связана с неверным указанием адресов узлов в конф. файлах. /home/usr1cv81/1c/1cv81/srvibrg.lst и /home/usr1cv81/1c/1cv81/reg_1541/s1CV8Reg.lst

Несоответствие системы

Если при первом запуске кластера выдаётся ошибка, и появляется только файл /home/usr1cv81/1c/1cv81/srvibrg.lst практически без содержимого, возможно нужно обновить систему.