Ошибка сокета битрикс

Итак, многие сталкиваются с такой проблемой как ошибка сокетов при проверке сайта (а с 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С-Битрикс: Управление сайтом появилось предупреждение «Обнаружены ошибки в работе сайта. Проверить и исправить.» При проверке системы выдает следующую ошибку — «Работа с сокетами — ошибка»? Тогда вы по адресу и сейчас я расскажу вам как исправить ошибку.

Чаще всего данная ошибка появляется по следующим причинам:

1. Некорректно указан корневой каталог в конфигурации вашего домена на сервере. Например сайт расположен в директории «varwwwmydomain», а в конфигурации указан путь «varwwwdocsmydomain». В этом случае достаточно будет отредактировать конфигурационный файл Apache или Nginx и проблема будет решена.

2. Во втором случае ошибка появляется после перевода сайта на https протокол. В этом случае вы увидите в журнале проверки ошибку: Работа с сокетами (check_socket): Fail Connection to ssl://mydomain.ru:443 Fail Socket error [0]:. Для начала проверим наш сертификат с помощью командной строки сервера через Putty или Shell клиента в панели вашего сервера — curl https://ваш_сайт:443 если ответом будет not found ca-bundle или похожая значит вы не совсем корректно установили сертификат SSL. Даже если сайт при этом открывается по протоколу HTTPS. Также убедиться в том корректно или нет установлен сертификат поможет сервис — https://www.sslshopper.com/ssl-checker.html во всех пунктах проверки не должно быть ошибок. 

Что-же делать если ошибка есть — необходимо установить промежуточный сертификат. Для этого чтобы не генерировать ca-bundle, просто находим его тут — https://www.namecheap.com/support/knowledgebase/article.aspx/9393/69/where-do-i-find-ssl-ca-bundle (искать по названию). И далее устанавливаем по инструкции к вашему серверу или хостингу. Возможно потребуется удалить имеющийся сертификат. 
!Внимание: перед удалением или правкой сертификата SSL убедитесь что у вас имеется сам сертификат а также ключ сертификата!

После установки промежуточного сертификата еще раз проводим проверку вышеуказанными способами, видим что ошибок нет, и после этого выполняем проверку системы 1С-Битрикс. 

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

После установки 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

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

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

В инструментах запустил проверку системы. После завершения проверки, отображается ошибка работы с сокетами «Ошибка! Не работает».
В логе проверки вот такое выдает:

Особенно подчеркну предложение Александра. Кроме 404 и 302 ошибка бывает Советую внимательно посмотреть логи и какой ответ сервера. Вот на фото подчеркнуто красным. Чуть ниже надписи Работа с сокетами (check_socket): Fail . Долго искал в поисковике bitrix socket error , нашел интересную и подробную статью Bitrix. Исправляем ошибку «Работа с сокетами — Ошибка! , чтобы сформулировать правильное задание ТЗ , а то вовсе без техподдержки решить проблему после » Полного тестирования системы» /bitrix/admin/site_checker.php?lang=ru

У меня другая ошибка была, неправильный redirect Но суть в том, что эта проблема с сокетом. может быть причиной значительного увеличения нагрузки на сервер.. (фото ДО и после ))
Очень рад что есть такой полезный инструмент «Проверка системы», он позволяет не создавать лишней работы по оптимизация скриптов и вообще избежать много другого страшного гемора, например потерянные ссылки на сайте.

Особенно подчеркну предложение Александра. Кроме 404 и 302 ошибка бывает Советую внимательно посмотреть логи и какой ответ сервера. Вот на фото подчеркнуто красным. Чуть ниже надписи Работа с сокетами (check_socket): Fail . Долго искал в поисковике bitrix socket error , нашел интересную и подробную статью Bitrix. Исправляем ошибку «Работа с сокетами — Ошибка! , чтобы сформулировать правильное задание ТЗ , а то вовсе без техподдержки решить проблему после » Полного тестирования системы» /bitrix/admin/site_checker.php?lang=ru

У меня другая ошибка была, неправильный redirect Но суть в том, что эта проблема с сокетом. может быть причиной значительного увеличения нагрузки на сервер.. (фото ДО и после ))
Очень рад что есть такой полезный инструмент «Проверка системы», он позволяет не создавать лишней работы по оптимизация скриптов и вообще избежать много другого страшного гемора, например потерянные ссылки на сайте.

Источник

Не удалось проверить из-за ошибки в работе с сокетами

Коллеги, помогите пожалуйста разобраться раз и навсегда, после установки коробки, при тестировании системы на ошибки вышло много ошибок связанных с сокетами. Вот скрин: https://prnt.sc/xo6dso

Не удалось проверить из-за ошибки в работе с сокетами. Как исправить данную ошибку, помогите пожалуйста научиться раз и навсегда. Благодарю!

Я смотрел, исходя из того что написано там, я так и не понял что конкретно требуется сделать.

Осуществляется сетевое подключение с веб-сервера к самому себе. Это необходимо чтобы проверить работу сетевых функций, а также требуется для ряда последующих тестов.

А значит, если этот базовый тест не отработал, то дальнейшие тесты, где требуется создание независимого php процесса, не могут быть произведены.

Обычно проблема возникает, если подключение запрещено фаерволом, доступ к административной части запрещен по IP или для входа на сайт требуется HTTP/NTLM авторизация. На этапе тестирования необходимо отключить эти ограничения.

А в журнале ошибок написано:

2021-Jan-26 21:53:49 Работа с сокетами (check_socket): Fail Connection to 176.120.203.37:80 Fail Socket error [111]: Connection refused Ошибка! Не работает

Источник

Ошибка проверки сайта Работа с сокетами — Socket error [111]: Connection refused

в файле /etc/hosts пропишите
127.0.0.1 _ВАШ_ДОМЕН_

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

Посмотрите лог проверки (что-то типа /home/bitrix/www/bitrix/site_checker_d64fb2e3f5834fc1af5d853 ­77f2c3f3c.log). В нем будет написано куда пытается подключиться скрипт:

2013-Feb-25 06:49:58 Работа с сокетами (check_socket): Fail
Connection to 123.456.789.123:80
Socket error [110]: Connection refused

В моем случае проблема была в том, что заказчик предоставил только адрес шлюза 123.456.789.123, а на нем пробросил порт 80 на хост с виртуалкой. А виртуалка ничего не знала про этот IP.

В своем локальном файле c:WindowsSystem32driversetchosts я добавил запись:
80.66.94.230 portal.localdom

А на виртуалке добавил /etc/hosts имя portal.localdom
127.0.0.1 localhost.localdom localhost localhost portal.localdom

После этого проверка сокетов прошла успешно.

Еще одна причина возникновения данной ошибки:
На сайте стоит http-авторизация через утилиту passwd и .htaccess в вышележащей папке.

Соответственно, после того, как убираем из .htaccess в папке «..»
AuthName «Private zone»
AuthType Basic
AuthUserFile .htpasswd
require valid-user

Проверка сайта проходит успешно!

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

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

Если в .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

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

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

Источник

Ошибка проверки сайта Работа с сокетами — Socket error [111]: Connection refused

подскажите алгоритм установка не самоподписанного ?

и файла *.key нет
есть только такие

Еще вариант решения
в /etc/hosts

127.0.0.1 localhost
00.000.00.00 site1.ru site2.ru site3.ru

гда 00.000.00.00 — ip адрес сервера

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

И к тому же что apache, что nginx выдавали что-то типа «httpd: (98)Address already in use: make_sock: could not bind to address», первый – немного, второй – много занятых портов.

Пробовал решать различными путями – ничего не помогало. Набрел на инструкцию Comodo — https://support.comodo.com/index.php?/Knowledgebase/Article/View/1091/37/certificate-installation—nginx В ней говорится, что для nginx нужно объединить сертификаты «xxx. ca-bundle» и «xxx.crt» и уже такой объединенный файл подсовывать nginx-у. Но у меня-то небыло ни crt-файла ни ca-bundle-файла. На это Comodo на этой же страничке инструкции предлагает скачать ca-bundle-файл, а вернее, несколько файлов – для домена, файл расширенной валидации и файл для организации. Мне нужен был для домена, его я и скачал — https://support.comodo.com/index.php?/Knowledgebase/Article/GetAttachment/1091/1282988

Называется он «domain_validated.ca-bundle»

Ну хорошо, ca-bundle-файл – есть, но никакого crt – нет как нет. Поэтому за неимением вместо crt взял pem-файл.

В консоли перешел в папку сертификатов: «cd /etc/nginx/ssl/».

И запустил объединение файлов командой «cat server.pem domain_validated.ca-bundle > ssl-bundle.crt», в результате чего в папке сертификатов был создан объединенный файл «ssl-bundle.crt».

Вот этот вновь созданный сертификат я и подсунул nginx, то есть в файле конфигурации было: «ssl_certificate /etc/nginx/ssl/xxx.pem;»

А стало: «ssl_certificate /etc/nginx/ssl/ssl-bundle.crt;»

Рестартанул nginx “service nginx restart”

И пошел проверять. В Битрикс – админке – ошибки исчезли. В Битрикс скрипте проверки – тоже.

Тест в консоли «curl https://somebody.ru:443» — также прошел на ура и выдал содержимое страницы в консоль. Тесты на сайтах тестирования сертификатов – улучшились, но уровень «A» таки получить не удалось, — остался «B» — https://www.ssllabs.com/ssltest/ . Тестер комодо — https://sslanalyzer.comodoca.com/ тоже выдал некоторые проблемы с « DH 1024-bit». И в инфо на https://weakdh.org/sysadmin.html было рекомендовано создать новую группу командой «openssl dhparam -out dhparams.pem 2048», что я и сделал в консоли. Скрипт предупредил, что это может продлиться долго – на практике это заняло 1-2 минуты (как раз чтобы налить себе чаю).

openssl dhparam -out dhparams.pem 2048

openssl dhparam -out dhparams.pem 2048

Generating DH parameters, 2048 bit long safe prime, generator 2

This is going to take a long time

Файл сертификата “dhparams.pem” был создан по адресу: /etc/nginx/ssl/

Проверяем nginx – nginx –t

service nginx restart

И – вуаля! Общий уровень – “A”!

как я решал эту проблему .

тоже напоролся дважды при переводе сайта из1251 на ю-8 и уходе из облака в коробку на Б-24

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

комбинация такая Linux CentOS 7.4 + nginx 1.12.2 + тело

1. раздобыть сертификат SSL
у нас изначально стоял КОМОД и по принципу «от добра добра не ищут» поперся обратно к ним же, т.к. дают на 3 месяца бесплатный с возможностью продления
самоподписанты — дело хорошее, но до поры — до времени и не для публичного сайта

для знакомых с английским языком не по наслышке — можно напрямую написать через сайт КОМОДа, для нуждающихся в шефской помощи — мне лично понравился сервис и отношение к клиентам на FirstSSL
у КОМОДа примерно час, у этих минут 30 заняло

беда! : КОМОД пришлет 4 файла, из которых 1 — это сам сертфикат, а три других надо саморучно подвергнуть конкатенации, дабы слепить из них *.ca-bundle файл
одна ошибка в последовательности и сертификат уже не пройдет проверку на ssllabs и прочих подобных ресурсах, будет или некорректно построеная цепочка, или отсутствие цепочки или еще чего не так, и снова — все на «НЕРУССКОМ ЯЗЫКЕ»:

• Root CA Certificate — AddTrustExternalCARoot.crt
• Intermediate CA Certificate — COMODORSAAddTrustCA.crt
• Intermediate CA Certificate — COMODORSADomainValidationSecureServerCA.crt
• Your Free SSL Certificate — your_domain_ru.crt

вот тут как раз и зарыта большая собака, т.к. корневой сертификат надо класть в конец файла а оба иммедиата в начало но в строго определенном порядке №1-№2_корень

если тип сертификата предполагает не 1 и не 2 промежуточных — то заплутать очень даже большая вероятность!

от FirstSSL же пришло все готовенькое, оставалось только засунуть в нужное место, т.е. сам сертификат и собраный *.ca-bundle

2. теперь пытаемся пробраться в каталог /etc/nginx/ssl/ и засунуть туда оба эти произведения ИТ-исскуства, предварительно хорошенько запомнив их названия! для этой цели я использовал классический прием по типу Мойдомен_ру.*
после того, как они уже там — поиграться с правами на доступ

3. теперь надо зайти в каталог /etc/nginx/bx/conf/ и отредактировать файл ssl.conf

там уже будут три строчки:

которые относятся ко встроенному сертификату Битрик Вэбокружение, которому никто не доверяет все равно
приводим их к такому виду :

и выше пишем все с точностью, меняя только название и расширение для своих сертификатов (по умолчанию там будет *.pem, и придется заменить на *.crt & *.key)

не забываем перезапустить сам nginx после всех этих манипуляций

если же у вас просто апач, то принцип то действий похожий, вот только каталог будет /etc/pki/tls// и в нем две папочки
— cert для сертификатов
-private для ключей

также рекомендуется перезапустить апач

радости не было конца, думал, что все уже решил, однако не тут то было! часть ошибок с сокетами ушла, которая ниже этажом, а сама строка Работа с сокетами = по прежнему fail.

бежим в файл /etc/hosts и видим такую печальную картину

127.0.0.1 local local.localdomain
::1 local local.domain local6 local.localdomain6

#ANSIBLE MANAGED. НЕ совать ничего после этой строчки
ваш_внутренний адрес_сервера имя сервера имя_сервера.домен

если все работает только внутри сети = это еще куда ни шло, но когда выпустили джинна наружу, то вместо пустоты выше последних строк
пишем

ваш_внутренний адрес_сервера DNS_адрес_узла
(192.168.1.23 my_domain.*)
причем записать надо разом оба варианта с www и без
можно даже употребить формочку

#bx-host
(192.168.1.23 my_domain.*)
если у вас на сервре будет крутиться несколько сайтов
и для некоторых сетей может потребоваться добавление и внешнего IP тоже, хотя не всегда

только после ВСЕХ этих манипуляций все прекрасно завелось и поехало, замок позеленел с досады, что больше не к чему придраться и придется открывать страницу

и только после того как — удалось поднять Push, ибо он тоже на это завязан

Источник

Битрикс: ошибка работы с сокетами

Ошибка работы с сокетами выявляется в BitrixVM при запуске инструмента «Проверка системы»:

Сообщения об этом будет выведено в нескольких разделах теста:

Расшифровка ошибки и ее причины, согласно отчету могут быть следующие (открывается по клику на иконке вопроса):

Осуществляется сетевое подключение с веб-сервера к самому себе. Это необходимо чтобы проверить работу сетевых функций, а также требуется для ряда последующих тестов.

А значит, если этот базовый тест не отработал, то дальнейшие тесты, где требуется создание независимого php процесса, не могут быть произведены.

Обычно проблема возникает, если подключение запрещено фаерволом, доступ к административной части запрещен по IP или для входа на сайт требуется HTTP/NTLM авторизация. На этапе тестирования необходимо отключить эти ограничения.

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

В журнале будет следующая информация:

где IP 9………114:80 — внешний IP адрес BitrixVM сервера.

Если доступ к серверу ограничен фаерволом, а подключение происходит только по IP-адресу (домен не привязан), то ошибка работы с сокетами исправляется следующим образом:

• Проверяется корректность настройки DNS-сервера(ров) в панели управления виртуальной машиной (т.е. у VPS-провайдера);
• Проверяется корректность настройки DNS-сервера(ров) на BitrixVM;
• К серверу привязывается доменное имя;
• Административная панель открывается по домену и тест запускается повторно.

Подробное описание:

1. Если VPS-провайдер предоставляет уже настроенную виртуальную машину, то DNS-сервера хостера скорее всего в виртуальной машине уже прописаны. Если, виртуальная машина создается самим пользователем с нуля, т.е. создается сеть, подключается фаервол, выбирается дистрибутив ОС, то записи DNS-сервера(ров) в конфигурации сети следует обязательно проверить.

2. Используемые DNS-сервера (ниже — для примера приведены Google Public DNS сервера) в BitrixVM должны быть прописаны в следующие файлы:

3. В панели управления доменом указывается IP-адрес BitrixVM сервера.

И, дополнительно в файл: /etc/hosts вместо записей вида localhost, прописывается привязанный домен:

4. Теперь, при запуске «Проверки системы» сайта через доменное имя:

http://site.ru/bitrix/admin/site_checker.php?lang=ru

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

Примеры: