Работа с сокетами битрикс как исправить

Здравствуйте.

У меня вот какая проблема.

При проверке системы  (Рабочий стол-> Настройки-> Инструменты-> Проверка системы) происходит следующее:

Если в .htaccess в корне сайта закомментирована строка php_value mbstring.internal_encoding UTF-8, то (как и следует ожидать) выводится ошибка:

Ошибка! Сайт работает в UTF кодировке, настройки mbstring:
mbstring.func_overload=2
mbstring.internal_encoding=
требуется:
mbstring.func_overload=2
mbstring.internal_encoding=utf-8

если мы раскомментируем строку, то сообщение об ошибке кодировки не выводится, но выводится другая ошибка:
Работа с сокетами — Ошибка! Не работает

Смотрим журнал проверки. Ситуация следующая (обращаю внимание — домен кириллический):

Когда не указана кодировка utf-8, то в журнале имеется запись:
2013-Dec-19 15:25:56 Работа с сокетами (check_socket): Ok
Connection to xn——dlcdhdea0afa5acqdcd1cjk8r.xn--p1ai:80 Success

Как только мы в .htaccess указываем mbstring.internal_encoding utf-8, то в журнале просто нет хоста, к которому проверяется подключение:
2013-Dec-19 15:34:42 Работа с сокетами (check_socket): Fail
Connection to :80 Fail
Socket error [0]: php_network_getaddresses: getaddrinfo failed: Name or service not known

____________________________________________________________­

>Connection to xn——dlcdhdea0afa5acqdcd1cjk8r.xn--p1ai:80 Success

>Connection to :80 Fail

т.е. система не видит адреса, к которому нужно подключаться.
____________________________________________________________­

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

Как быть?

Итак, многие сталкиваются с такой проблемой как ошибка сокетов при проверке сайта (а с 30 сентября 2021 так еще больше таких проблем, решение будет ниже):

Из-за этой ошибки сайт не может проверить все остальные параметры и вы видите очень много красных предупреждений: «Замечание. Не удалось проверить из-за ошибки в работе с сокетами». Она бывает при установке сайта на виртуальную машину Битрикс.

Что делать?

Первое что нужно сделать при запуске сайта на виртуальной машине Битрикс, это прописать домен в файле hosts. Заходим на сервер по sftp под root-пользователем, идем в корневую папку etc, открываем файл hosts.

В первой строке через пробел прописываем домен (если доменов несколько, прописываем все через пробелы в этой строке).

Получится примерно так:
127.0.0.1       localhost.localdomain localhost rushstudio.by

Сохраняем файл и перезагружаемся. Готово, все работает.

Домен прописан, ошибка осталась

Сейчас (осень 2021) у всех массово возникли проблемы. Это касается изменений на стороне центра сертификации let’s encrypt (30 сентября 2021 года подошел к концу срок действия корневого сертификата IdenTrust DST Root CA X3.). И если у вас было все настроено и работало, ошибка все-равно появляется.

Решается все довольно просто. Подключаемся по SSH, выходим из открывшегося меню (ctrl+c) и вводим команды подряд:
yum install ca-certificates
update-ca-trust

Готово. Теперь все будет работать.

Думаю в следующих обновлениях Виртуальной машины это поправят, но пока это решение рабочее на 100%.

Все-равно не помогло?

Первым делом проверьте AAAA-запись у домена, если она есть, удалите.
Не помогло? Проверьте что доступ к админке, где вы запускаете тест, открыт (нет ограничений по IP или других блокировок).

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

«1С-Битрикс: Управление сайтом» — одна из самых популярных коммерческих CMS. Как и в случае с любой другой CMS, при работе с Битриксом возникают разные ошибки, мешающие нормальной работе сайта. Выявить их можно с помощью встроенного функционала проверки системы в панели администратора Битрикс.

Чтобы запустить проверку системы, перейдите в панель администратора по ссылке https://example.com/bitrix/admin (замените example.com на ваш домен), введите логин и пароль учетной записи администратора сайта, перейдите в Настройки — Инструменты — Проверка системы и нажмите на кнопку Начать тестирование. Дождитесь окончания проверки. В форме Проверка системы могут быть ошибки, которые, на первый взгляд, не влияют на работу сайта, однако требуют внимания владельца или системного администратора сайта.

В данной статье рассмотрим способы устранения популярных ошибок, возникающих в CMS Битрикс.  

Ошибка «The script encountered an error and will be aborted. To view extended error messages, enable this feature in .settings.php.» при переходе на сайт

Такая ошибка в большинстве случаев означает некорректное подключение к базе данных. В первую очередь проверьте, работает ли СУБД, введя следующую команду в терминал:

# systemctl status mysql

Если СУБД работает, проверьте файлы, расположенные в /home/bitrix/www/bitrix/.settings.php и /home/bitrix/www/bitrix/php_interface/dbconn.php (при необходимости замените /home/bitrix/www на корневую директорию вашего проекта, далее в статье будут использованы относительные пути вида /bitrix/php_interface/dbconn.php). В этих файлах указываются доступы для подключения к базе данных сайта.

Для файла .settings.php

'host' => 'localhost',
'database' => 'database_name',
'login' => 'user_name',
'password' => 'secret_password',

Для файла dbconn.php

$DBHost = "localhost";
$DBLogin = 'user_name';
$DBPassword = 'secret_password’;
$DBName = "database_name";

Проверьте корректность указанных данных:

• хост базы данных (должен быть localhost, если СУБД установлена локально),
• название базы данных (замените в обоих файлах database_name на название своей базы данных),
• имя пользователя базы данных (замените user_name на имя своего пользователя базы данных)
• и пароль пользователя базы данных (замените secret_password на пароль пользователя вашей базы данных).

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

«Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron» при проверке системы 

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

Как правило, для настройки выполнения агентов на cron достаточно следовать рекомендациям проверки системы. Для этого нажмите на вопросительный знак справа от уведомления:

Однако такой способ срабатывает не всегда. Если в файле /bitrix/php_interface/dbconn.php есть строка define('BX_CRONTAB_SUPPORT', true); и в cron есть задание на ежеминутный запуск скрипта /var/www/bitrix/modules/main/tools/cron_events.php, попробуйте следующее решение.

Отключим выполнение агентов на хитах, для этого в панели администратора Битрикс переходим в Настройки — Инструменты — Командная PHP-строка, вводим следующую команду и нажимаем Выполнить:

COption::SetOptionString("main", "agents_use_crontab", "N"); 
echo COption::GetOptionString("main", "agents_use_crontab", "N"); 
COption::SetOptionString("main", "check_agents", "N"); 
echo COption::GetOptionString("main", "check_agents", "Y");

Результат выполнения PHP-команды должен быть «NN».

Далее в файле /bitrix/php_interface/dbconn.php закомментируем следующие строки (добавьте перед строками знак #):

define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);

После чего в этот же файл dbconn.php добавьте строки:

if(!(defined("CHK_EVENT") && CHK_EVENT===true))
define("BX_CRONTAB_SUPPORT", true);

Далее необходимо из учетной записи владельца сайта (если вы работаете в консоли сервера из-под учетной записи root, что не рекомендуется, после создания файла измените владельца файла с помощью команды chown) создать новый файл cron_events.php в директории /bitrix/php_interface/ и добавить в него следующий код:

<?php
$_SERVER["DOCUMENT_ROOT"] = realpath(dirname(__FILE__)."/../..");
$DOCUMENT_ROOT = $_SERVER["DOCUMENT_ROOT"];
define("NO_KEEP_STATISTIC", true);
define("NOT_CHECK_PERMISSIONS",true);
define('BX_NO_ACCELERATOR_RESET', true);
define('CHK_EVENT', true);
define('BX_WITH_ON_AFTER_EPILOG', true);
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
@set_time_limit(0);
@ignore_user_abort(true);
CAgent::CheckAgents();
define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);
CEvent::CheckEvents();
if(CModule::IncludeModule('sender'))
{
    BitrixSenderMailingManager::checkPeriod(false);
    BitrixSenderMailingManager::checkSend();
}
require($_SERVER['DOCUMENT_ROOT']."/bitrix/modules/main/tools/backup.php");
CMain::FinalActions();
?>

После того, как файл создан с нужными правами, добавляем его в cron. Обязательно делаем это для владельца сайта, так как задания cron для пользователя root могут стать серьезной угрозой безопасности для сайта и сервера. Выполним следующую команду (в нашем случае владелец сайта — bitrix, замените это значение на имя пользователя своего сайта при необходимости):

# crontab -ubitrix -e

Откроется файл с заданиями crontab пользователя сайта. Вставьте следующую строку:

*/1 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cron_events.php

В данной строке значение */1 * * * * означает выполнение скрипта раз в минуту, вы можете скорректировать частоту выполнения в зависимости от ваших требований к проекту.

Путь /usr/bin/php — путь для PHP, оставьте его таким же, если у вас на сервере нет альтернативных версий PHP. Если вы используете панель ISPmanager, возможно, ваш сайт работает на альтернативной версии PHP. Проверить версию можно в панели ISPmanager, а узнать корректный путь для PHP — с помощью команды whereis php в консоли сервера. Например, для альтернативной версии PHP 8.1 путь может быть таким: /opt/php81/bin/php. Замените путь к скрипту /home/bitrix/www/bitrix/php_interface/cron_events.php на свой в случае необходимости.

Если в cron есть запись для выполнения скрипта /var/www/bitrix/modules/main/tools/cron_events.php — ее лучше закомментировать.

Ошибка работы с сокетами при проверке системы

При проверке системы в панели администратора Битрикс может возникнуть ошибка «Работа с сокетами. Ошибка! Не работает».

Также из-за ошибки работы с сокетами другие тесты проводятся некорректно, выдавая ошибку «Замечание. Не удалось проверить из-за ошибки в работе с сокетами».

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

Если А-записи указаны корректно, возможно в файле /etc/hosts на сервере указан неверный IP для вашего домена. Проверьте файл и укажите правильное значение:

1.2.3.4 example.com

Замените 1.2.3.4 на IP адрес вашего сервера, а example.com на доменное имя вашего сайта.

Бывает, что на сервере может возникнуть проблема с корневыми сертификатами. Можно попробовать обновить их. В CentOS 7 ведите в консоли сервера:

# yum install ca-certificates -y
# update-ca-trust

Ошибка! Не работает «Отправка почты» и «Отправка почтового сообщения больше 64Кб» при проверке системы

Из описания ошибки понятно, что она означает. В большинстве случаев для устранения данной ошибки требуется вмешательство системного администратора или технической поддержки Битрикс. Проблем, из-за которых почта не работает, много. Они могут быть на стороне сервера, в настройках проекта, либо из-за некорректно работающих модулей отправки почты.

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

Также можно выполнить проверку с помощью следующего кода PHP (вставьте его в командную строку PHP в панели администратора Битрикс):

$mail="test@testmail.ru"; // укажите ваш почтовый ящик, на который нужно отправить тестовое письмо
$subject ="test" ; // укажите любую тему письма
$text= "test message"; // укажите любой текст письма
if( mail($mail, $subject, $text) )
{
echo 'Письмо отправлено!'; }
else{
echo 'Ошибка! Не отправлено';
}

Если письмо не пришло, но вы получили уведомление «Письмо отправлено», значит, письма уходят и проблема в настройках CMS либо в модуле отправки почты. В данном случае можно обратиться в техподдержку Битрикс для выявления проблем в настройках CMS или к разработчику модуля отправки почты.

Не исключено, что письмо просто попало в спам. Можно попробовать отправить на другой почтовый ящик (с другим почтовым доменом). Если письмо пришло — значит, адрес отправителя в черном списке почтового домена, до которого письмо не дошло. Если письмо не дошло — возможно, ваш почтовый домен или IP-адрес попали в глобальные черные списки.

Если письмо не пришло, а вы получили уведомление «Отправка не удалась» — необходимо более детальное изучение проблемы. В таком случае потребуется вмешательство системного администратора.

«Служебные скрипты в корне сайта. Ошибка! Файл существует» при проверке системы

Такая ошибка говорит о наличии в корне сайта служебных скриптов, например, restore.php. Данные скрипты, как правило, добавляют временно для проведения каких-либо работ (например, restore.php — для восстановления сайта из резервной копии). Так или иначе, после выполнения работ такие скрипты необходимо удалить с сервера, так как они представляют угрозу безопасности сайту и данным.

Ошибка «Загрузка файла» и «Загрузка файла больше 4Мб» при проверке системы

Проверка системы Битрикс загружает файл размером более 4Мб. В большинстве случаев такая ошибка говорит об ограничениях в параметре upload_max_filesize для PHP.

Необходимо в файле конфигурации PHP установить данное значение выше 4Мб и перезапустить веб-сервер. В зависимости от окружения файл конфигурации PHP может находится в разных местах. Обычно данное значение устанавливается в файле /etc/php.ini.

Если вы используете панель ISPmanager — поправить конфигурацию можно прямо в ней: выберите нужный сайт, нажмите на кнопку PHP в верхней панели, найдите параметр upload_max_filesize и укажите нужное значение. Если вы используете окружение BitrixVM, необходимо вносить изменения в специальные файлы конфигурации, чтобы после перезагрузки сервера они не вернулись в исходное состояние. Подробнее можете узнать по ссылке.

После установки SSL сертификата в битриксе на виртуальной машине BitrixVM версии 7.4.1 начала появляться ошибка с сокетами, при этом если перейти на сайт по обычному http, то такой проблемы не наблюдается.
Ниже описано как решить данную проблему с сокетами при использование SSL сертификата и протокола HTTPS в Bitrix virtual appliance version 7.4.1 («1С-Битрикс: Веб-окружение»).

Открываем SSH клиет (PuTTY).
Если меню битрикса не отображается сразу, то заходим в меню следующей командой:

cd
./menu.sh

Затем выбираем поочередно пункты в меню:

8. Manage pool web servers
3. Configure certificates
2. Configure own certificate

Если данных пунктов у вас нет, то сначала нужно обязательно создать пул:
1. Create Management pool of server

После того, как зашли в пункт 2. Configure own certificate, указываем сайт или оставляем по умолчанию Enter site name (default):

Указываем:
Private Key path: /etc/nginx/ssl/cert.key
Certificate path: /etc/nginx/ssl/cert.crt
Certificate Chain path: /etc/nginx/ssl/cert_ca.crt

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

После вопроса Please confirm you want to update certificate settings for the sites (N|y): вводим Y и нажимаем enter.

Готово, сайт должен открываться по HTTPS, но у меня не работало, поскольку я не указывал Certificate Chain path, у меня не было сертификатов для цепочки (промежуточных) и пока я не указал эти сертификаты в Certificate Chain path у меня SSL не работал. Точнее сам сайт по HTTPS открывался нормально в защищённом режиме, но в проверке системы битрикс показывалась ошибка с сокетами: 
Ошибка! Работа с сокетами (check_socket): Fail Connection to ssl://site.com:443 Fail, Connection to ssl://site.com:443 Fail Socket error [0]: 
Подробности ошибки указаны в журнале проверки системы.

Также если обратится к сайту в консоли через curl командой:
curl https:// site.com :443
выходило следующие curl: (60) Peer’s Certificate issuer is not recognized.
При нормальной работе должен показываться HTML код сайта. 

Проблема еще была в том, что у меня не было никаких промежуточных сертификатов, а только публичный сертификат (CRT) и приватный ключ (Private KEY).

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

Как же их получить? 
Нашёл решение такое, открываем сайт в браузере Firefox, нажимаем на замочек, затем на стрелку справа от зеленной надписи «Защищенное соединение», затем внизу «Подробнее».
После чего откроется окно «Информация о странице». Там нажимаем «Просмотреть сертификат».
Откроется страница с различными данными и параметрами сертификата. Находим ниже ссылки Загрузить PEM (сертификат) и PEM (цепочка сертификатов). Именно последний нам и нужен. Качаем PEM (цепочка сертификатов).

Формат PEM я переименовал в CRT. У меня сработало с ним, но возможно и с PEM сработает. 
После того как я указал этот chain сертификат, как указано выше в Certificate Chain path, у меня наконец-то пропала ошибка с сокетами и все наконец стало работать как надо. 

Записи о сертификатах создаются в файле:
/etc/nginx/bx/site_avaliable/ssl.s1.conf 

там указано где хранятся сертификаты:
ssl_certificate   /etc/nginx/certs/default/cert.crt;
ssl_certificate_key  /etc/nginx/certs/default/cert.key;
ssl_trusted_certificate /etc/nginx/certs/default/cert_ca.crt;

Также данные записи были сделаны в файле /etc/nginx/bx/conf/ssl-push-custom.conf
А изначально настройки брались из /etc/nginx/bx/conf/ssl.conf

В документации вообще сказано, что для сайта по умолчанию s1 (который находится в директории /home/bitrix/www) файл будет называться /etc/nginx/bx/site_avaliable/s1.ssl.conf, а для дополнительных сайтов (которые создаются в директории /home/bitrix/ext_www/название_хоста) — /etc/nginx/bx/site_avaliable/bx_ext_ssl_название_хоста.conf.

Поэтому нужный файл конфигурации здесь еще нужно постараться определить.

Не забываем также указать в файле /etc/hosts ваш IP и домен. я указал два ip версии 4 и 6, а также 127.0.0.1 localhost

После правок нужно выполнить команду 
nginx  -t
И перезагрузить 
service nginx restart или # /etc/init.d/nginx restart

Если нужно установить бесплатный сертификат LetsEncrypt, об это написано в этой статье Установка SSL сертификата LetsEncrypt на BitrixVM

Загрузка

Во время тестирования сайта, выскакивает следующая ошибка:

Работа с сокетами (check_socket): Fail

А в журнале мы видим следующий лог:

2016-Feb-27 13:41:10 Работа с сокетами (check_socket): Fail
Connection to site.ru:80  Success
== Request ==
GET /bitrix/admin/site_checker.php?test_type=socket_test&unique_id=83f81a8666278b68e58012ce161a1dd0 HTTP/1.1
Host:  site.ru


== Response ==
HTTP/1.1 404 Not Found
Server: nginx/1.4.6 (Ubuntu)
Date: Sat, 27 Feb 2016 12:41:10 GMT
Content-Type: text/html
Content-Length: 177
Connection: keep-alive

== Body ==
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.4.6 (Ubuntu)</center>
</body>
</html>

==========

Для начала мы видим в этом логе, что при запросе система получает 404 ошибку. Нам нужно понять почему она происходит. Для этого нам нужно проверить логи веб-сервера. Так как у меня работает на nginx + apache2, я открыл логи nginx (Linux /var/log/nginx/error.log).

В данном логе я ищу мой запрос

2016/02/27 13:41:10 [error] 2309#0: *658 openat() "/usr/share/nginx/html/bitrix/admin/site_checker.php" failed (2: No such file or directory), client: 127.0.0.1, server: localhost, request: "GET /bitrix/admin/site_checker.php?test_type=socket_test&unique_id=83f81a8666278b68e58012ce161a1dd0 HTTP/1.1", host: "site.ru"

И что мы тут видим? Когда скрипт обращается сам к себе, то происходит обращение вообще не понятно по какому адресу «/usr/share/nginx/html/bitrix/admin/site_checker.php», тогда как сайт лежит: /var/www/site.ru/www/bitrix/admin/site_checker.php

Так же обратите внимание по какому адресу обращается скрипт:

client: 127.0.0.1, server: localhost, 

Из этого мы делаем вывод что site.ru привязан к localhost и при обращении сайта к самому себе пытается найти файлы не в папке сайта, а в папке nginx по умолчанию. Открыв фаил /etc/hosts я увидел следующую запись:

127.0.0.1 localhost.localdomain localhost site.ru

Изменив эту строчку на

127.0.0.1 localhost.localdomain localhost

я успешно прошел тест, и ошибка больше не возникала!