Содержание
- 504 ошибка битрикс на стороне сервера
- 504 gateway time-out nginx/1.4.2 битрикс
- Как узнать, какой запрос в настоящий момент выполняет php-cgi процесс
- Ошибка проверки сайта Работа с сокетами — Socket error [111]: Connection refused
- Socket error 110 connection timed out битрикс
- Тесты и сертификат
- Комментарии к урокам
- У нас часто спрашивают, сколько нужно заплатить
- Баллы опыта
- Не удалось проверить из-за ошибки в работе с сокетами
504 ошибка битрикс на стороне сервера
504 gateway time-out nginx/1.4.2 битрикс
Данная ошибка частенько вылетает при открытии страницы сайта. При просмотре логов сайта можем обнаружить следующую ошибку upstream timed out (110: Connection timed out) while reading response header from upstream В данном случае сервер nginx отправил запрос на apache и не дождался ответа. По умолчанию время ожидания ответа состовляет 60с. Бывает что сайт очень тяжелый, много скриптов и если ты уверен в работоспособности всех модулей и компонентов, можно добавить времени ожидания, прописав в конфиге nginx в секции location следующие строки
- На Centos конфиг хранится по следующему пути etcnginxnginx.conf
- Логи сайта храниятся в папке varwwwwww-rootdatalogs
В моем случае это не помогло. Ошибка 504 gateway time out в битрикс вылетала из-за загруженности процесса httpd на 85%.
Переведя сайт на CGI PHP 5.4.45 полетели ошибки в логах Timeout waiting for output from CGI script /var/www/php-bin-isp-php56/www-root/php и Script timed out before returning headers: php При помощи команды top я увидел загруженность процесса php на 75%. Значит все дело в исполнении php скрипта. Похоже, что есть какая-то ошибка в РНР-скриптах сайта, потому как подключений совсем немного, а нагрузка от обработки ощутимая:
Как узнать, какой запрос в настоящий момент выполняет php-cgi процесс
Покопавшись в интернете, я собрал очень полезные утилиты для работы с процессами на стороне сервера. Установку делал с помощью yum install strace Благодаря команде lsof, описание дал ниже, увидел последний файл, который был открыт процессом php. Это xml-файл yandex_torg04042015.php создавался агентом CCatalog::PreGenerateXML битрикс для системы Яндекс.Товары Происходил экспорт товаров в файл из инфоблока каталога товаров в количестве 15944шт Соответственно убрав выполнение агента, сайт быстренько открылся. Т.к. ошибка возникала на тестовом сервере, убрал выполнение всех агентов прописав в dbconn.php
- topВыводит список процессов и информации о них в режиме реалтайм
- mod_statusПозволяет контролировать в реальном времени производительность сервера
- strace -p PIDПоказывает системные вызовы, которые происходят в данный момент в процессе
- ps ax| grep PIDВыдача информации о состоянии процессов
- lsof -p PIDПоказывает список файлов, открытых процессом
- kill -SIGKILL PIDУбивает процесс
Работаю © 2012 — 2023 год
Все права защищены
Навыки и умения Знание PHP5, MySQL, JS, HTML5, CSS3. Работа с технологиями XML, AJAX, GIT, SOAP Большой опыт взаимодействия с сервером. Работа с 1C-BITRIX FRIMEWORK, BITRIX24
Источник
Ошибка проверки сайта Работа с сокетами — Socket error [111]: Connection refused
| Цитата |
|---|
| Дмитрий Ипатов написал: Затем в настройках nginx /etc/nginx/bx/conf/ssl.conf прописал пути к файлам сертификата |
подскажите алгоритм установка не самоподписанного ?
и файла *.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”!
| Цитата |
|---|
| Андрей Иванов написал: Проблему решил так, необходимо объединить crt и ca-bundle: |
как я решал эту проблему .
тоже напоролся дважды при переводе сайта из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, ибо он тоже на это завязан
Источник
Socket error 110 connection timed out битрикс
Курс предназначен для организаций, предоставляющих услуги хостинга и желающих получить компетенцию Рекомендуемый хостинг.
В курсе рассматриваются требования платформы Bitrix Framework к хостингу, вопросы установки, настройки продукта а также вопросы инструментов и методов оптимизации серверов и баз данных для работы с системой
Для хостеров не является обязательным, но рекомендуется изучение курсов Контент-менеджер и Администратор. Базовый для получения более полного представления о возможностях системы и способах работы с ней.
Рекомендуется ознакомиться с опытом настройки и тестирования серверов в блоге Дениса Шаромова, а так же с отзывами клиентов о хостингах в группе Черный и белый список хостингов социальной сети компании «1С-Битрикс».
Если ваш хостинг на Windows, то вам может быть полезна группа 1С-Битрикс на платформе Windows Server 2008 в социальной сети сайта «1С-Битрикс». В ней пользователи делятся опытом работы системы на IIS 7.
Тесты и сертификат
После изучения курса вам будет предложено пройти тесты на сертификацию. При успешной сдаче линейки тестов на странице Моё обучение можно просмотреть результат обучения и загрузить сертификат в формате PDF.
Также Вы можете поделиться ссылкой на страницу со своими сертификатами. Для этого на странице Моё обучение отметьте опцию Разрешить публичный доступ к резюме студента 

Комментарии к урокам
| На каждой странице курса авторизованный на сайте посетитель может дать комментарий к содержимому страницы. Комментарий — не форум, там не ведётся обсуждений или разъяснений. Это инструмент для сообщений нам об ошибках, неточностях. Для отправки комментария воспользуйтесь расположенной в правом нижнем углу окна браузера кнопкой: | ![]() |
У нас часто спрашивают, сколько нужно заплатить
Курс полностью бесплатен. Изучение курса, прохождение итоговых тестов и получение сертификатов — ничего из этого оплачивать не нужно.
Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.
Баллы опыта
В конце каждого урока есть кнопка Прочитано! . При клике на неё в Вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:

Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат — это если общее число набранных Вами баллов отличается от максимального на 1-2%.

Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox
iPhone:
FBReader
CoolReader
iBook
Bookmate
Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome
iOS
Marvin for iOS
ShortBook
Linux:
Calibre
FBReader
Cool Reader
Okular обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла от 03.11.2022.
Источник
Не удалось проверить из-за ошибки в работе с сокетами
Коллеги, помогите пожалуйста разобраться раз и навсегда, после установки коробки, при тестировании системы на ошибки вышло много ошибок связанных с сокетами. Вот скрин: 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
- Ошибка проверки сайта Работа с сокетами — Socket error [111]: Connection refused
Ошибка работы с сокетами
В инструментах запустил проверку системы. После завершения проверки, отображается ошибка работы с сокетами «Ошибка! Не работает».
В логе проверки вот такое выдает:
| Цитата |
|---|
| Александр Гусев написал: My_site.eu — в логах так и пишется? |
| Цитата |
|---|
| Scrooge написал: домен наверно еще не знает про новый сервер? |
| Цитата |
|---|
| Scrooge написал: Если на сайт через hosts заходите, то будет писать эту ошибку, как домен делегируете, ошибка сама исчезнет |
| Цитата |
|---|
| Александр Гусев написал: значит покопайте, почему 404 для /bitrix/admin/site_checker.php |
Особенно подчеркну предложение Александра. Кроме 404 и 302 ошибка бывает Советую внимательно посмотреть логи и какой ответ сервера. Вот на фото подчеркнуто красным. Чуть ниже надписи Работа с сокетами (check_socket): Fail . Долго искал в поисковике bitrix socket error , нашел интересную и подробную статью Bitrix. Исправляем ошибку «Работа с сокетами — Ошибка! , чтобы сформулировать правильное задание ТЗ , а то вовсе без техподдержки решить проблему после » Полного тестирования системы» /bitrix/admin/site_checker.php?lang=ru
У меня другая ошибка была, неправильный redirect Но суть в том, что эта проблема с сокетом. может быть причиной значительного увеличения нагрузки на сервер.. (фото ДО и после ))
Очень рад что есть такой полезный инструмент «Проверка системы», он позволяет не создавать лишней работы по оптимизация скриптов и вообще избежать много другого страшного гемора, например потерянные ссылки на сайте.
| Цитата |
|---|
| Александр Гусев написал: значит покопайте, почему 404 для /bitrix/admin/site_checker.php |
Особенно подчеркну предложение Александра. Кроме 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
| Цитата |
|---|
| Дмитрий Ипатов написал: Затем в настройках nginx /etc/nginx/bx/conf/ssl.conf прописал пути к файлам сертификата |
подскажите алгоритм установка не самоподписанного ?
и файла *.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”!
| Цитата |
|---|
| Андрей Иванов написал: Проблему решил так, необходимо объединить crt и ca-bundle: |
как я решал эту проблему .
тоже напоролся дважды при переводе сайта из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, ибо он тоже на это завязан
Источник
504 gateway time-out nginx/1.4.2 битрикс
Данная ошибка частенько вылетает при открытии страницы сайта. При просмотре логов сайта можем обнаружить следующую ошибку upstream timed out (110: Connection timed out) while reading response header from upstream В данном случае сервер nginx отправил запрос на apache и не дождался ответа. По умолчанию время ожидания ответа состовляет 60с. Бывает что сайт очень тяжелый, много скриптов и если ты уверен в работоспособности всех модулей и компонентов, можно добавить времени ожидания, прописав в конфиге nginx в секции location следующие строки
proxy_connect_timeout 300; proxy_send_timeout 300; proxy_read_timeout 300;
- На Centos конфиг хранится по следующему пути etcnginxnginx.conf
- Логи сайта храниятся в папке varwwwwww-rootdatalogs
В моем случае это не помогло. Ошибка 504 gateway time out в битрикс вылетала из-за загруженности процесса httpd на 85%.
Переведя сайт на CGI PHP 5.4.45 полетели ошибки в логах Timeout waiting for output from CGI script /var/www/php-bin-isp-php56/www-root/php и Script timed out before returning headers: php При помощи команды top я увидел загруженность процесса php на 75%. Значит все дело в исполнении php скрипта. Похоже, что есть какая-то ошибка в РНР-скриптах сайта, потому как подключений совсем немного, а нагрузка от обработки ощутимая:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31386 www-root 20 0 619956 184084 14328 S 75.0 18.1 1:19.59 php
Как узнать, какой запрос в настоящий момент выполняет php-cgi процесс
Покопавшись в интернете, я собрал очень полезные утилиты для работы с процессами на стороне сервера. Установку делал с помощью yum install strace Благодаря команде lsof, описание дал ниже, увидел последний файл, который был открыт процессом php. Это xml-файл yandex_torg04042015.php создавался агентом CCatalog::PreGenerateXML битрикс для системы Яндекс.Товары Происходил экспорт товаров в файл из инфоблока каталога товаров в количестве 15944шт Соответственно убрав выполнение агента, сайт быстренько открылся. Т.к. ошибка возникала на тестовом сервере, убрал выполнение всех агентов прописав в dbconn.php
define("NO_AGENT_CHECK", true);
define("NO_AGENT_STATISTIC", true);
- top Выводит список процессов и информации о них в режиме реалтайм
- mod_status Позволяет контролировать в реальном времени производительность сервера
- strace -p PID Показывает системные вызовы, которые происходят в данный момент в процессе
- ps ax| grep PID Выдача информации о состоянии процессов
- lsof -p PID Показывает список файлов, открытых процессом
- kill -SIGKILL PID Убивает процесс
Итак, многие сталкиваются с такой проблемой как ошибка сокетов при проверке сайта (а с 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 авторизация (тут уже просто на время тестирования отключите ее).
Views: 15695
Last Modified: 07.07.2020
While attempting to update, the error «Error connecting the update server: [110] Connection timed out» appears. |
This error indicates that the update script cannot connect to update the server www.bitrixsoft.com on port 80. This may occur due to the following reasons:
- Socket functions are unavailable, particularly fsockopen();
- Connections to port 80 are forbidden on the server;
- Insufficient memory on the server (often occurs on VPS with virtualization OpenVZ and 256 Mb RAM);
- Network problems.
Please contact the server administrator and provide them with the error description.
Update error [SITE_LICENSE_VIOLATION] Number of licensed site exceeded
This error indicates that either no sites were registered in the system, or all sites are deactivated, or number of active sites, permitted by the current licence has been exceeded.
Register at least a single site to solve this issue and to allow to download and install updates. You can also activate an existing пышеу from the same section or deactivate number of sites until your instance has the number of sites permitted by your current licence:
Desktop > Settings > System Settings > Websites > Websites.
Update error [ERROR_WRONG_CODE]
The product update system becomes related to a specific installation and “remembers” the status of the system after the latest update. An error occurs if the current status is inconsistent with that at the time of the last update. This feature is intended to prevent the update attempts of an unlimited number of product installations using one license key.
According to the license agreement, two system installations are permitted for each license key – one public and one local (for developer) installation, the latter being inaccessible from the Internet. Accordingly, the system is set to save data about two installations. In this case, two copies may be updated independently without any problems and without the need to move a copy from a local computer to the server and back. If you have to move the product to a local computer, only one of two copies should be updated – either that on the server or the local one (at your discretion).
The same procedure should be followed when moving your site to a new server. Copy file structure and database onto a new server, and after that, without updating the product on the old server, delete it immediately after updating the DNS.
На локальной машине все ок. Все отправляется на почту.
На удаленном серваке так
TimeoutError: [Errno 110] Connection timed out
Гугление пока результата не дало….
Кто может сталкивался с этим?
Как решали?
Last login: Tue May 24 09:59:29 2022 from 95.188.77.167
> root@templ-ubuntu-2004:~# cd /root/bots/ulya_bot2
> root@templ-ubuntu-2004:~/bots/ulya_bot2# python3.8 main.py
> FSM запущена
> подключил вторую часть
> РАБОТАЮ!
> executor.py [LINE:362] #INFO [2022-05-24 10:01:13,292] Bot: Juli_Key_bot [ @333t]
> executor.py [LINE:358] #WARNING [2022-05-24 10:01:14,379] Updates were skippe d successfully.
> Бот вышел онлайн
> Подключился к БД1
> dispatcher.py [LINE:358] #INFO [2022-05-24 10:01:14,381] Start polling.
> Valid email
> DataFrame:
> user_id name username e_mail phone
> 0 1284986166 Olga olga_viktorovna3335 jenya82333@inbox.ru 793333368
> base_events.py [LINE:1707] #ERROR [2022-05-24 10:03:51,235] Task exception was never retrieved
> future: <Task finished name='Task-47' coro=<Dispatcher._process_polling_update s() done, defined at /usr/local/lib/python3.8/dist-packages/aiogram/dispatcher/d ispatcher.py:407> exception=TimeoutError(110, 'Connection timed out')>
> Traceback (most recent call last):
> File "/usr/local/lib/python3.8/dist-packages/aiogram/dispatcher/dispatcher.p y", line 415, in _process_polling_updates
> for responses in itertools.chain.from_iterable(await self.process_updates( updates, fast)):
> File "/usr/local/lib/python3.8/dist-packages/aiogram/dispatcher/dispatcher.p y", line 235, in process_updates
> return await asyncio.gather(*tasks)
> File "/usr/local/lib/python3.8/dist-packages/aiogram/dispatcher/handler.py", line 116, in notify
> response = await handler_obj.handler(*args, **partial_data)
> File "/usr/local/lib/python3.8/dist-packages/aiogram/dispatcher/dispatcher.p y", line 256, in process_update
> return await self.message_handlers.notify(update.message)
> File "/usr/local/lib/python3.8/dist-packages/aiogram/dispatcher/handler.py", line 116, in notify
> response = await handler_obj.handler(*args, **partial_data)
> File "/root/bots/ulya_bot2/handlers/Partnerbase1.py", line 69, in get_phone
> await sqlite_db1.sql_add_command(state)
> File "/root/bots/ulya_bot2/data_base/sqlite_db1.py", line 43, in sql_add_com mand
> send_email(user, pwd, recipients, "Test Subject")
> File "/root/bots/ulya_bot2/data_base/sqlite_db1.py", line 38, in send_email
> server = smtplib.SMTP('smtp.jino.ru: 587')
> File "/usr/lib/python3.8/smtplib.py", line 255, in __init__
> (code, msg) = self.connect(host, port)
> File "/usr/lib/python3.8/smtplib.py", line 339, in connect
> self.sock = self._get_socket(host, port, self.timeout)
> File "/usr/lib/python3.8/smtplib.py", line 310, in _get_socket
> return socket.create_connection((host, port), timeout,
> File "/usr/lib/python3.8/socket.py", line 808, in create_connection
> raise err
> File "/usr/lib/python3.8/socket.py", line 796, in create_connection
> sock.connect(sa)
<b>> TimeoutError: [Errno 110] Connection timed out</b>
[2020-03-24 16:28:44,787: INFO/MainProcess] mingle: all alone
[2020-03-24 16:30:23,873: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/celery/worker/consumer/consumer.py", line 318, in start
blueprint.start(self)
File "/usr/local/lib/python3.7/site-packages/celery/bootsteps.py", line 119, in start
step.start(parent)
File "/usr/local/lib/python3.7/site-packages/celery/worker/consumer/consumer.py", line 599, in start
c.loop(*c.loop_args())
File "/usr/local/lib/python3.7/site-packages/celery/worker/loops.py", line 83, in asynloop
next(loop)
File "/usr/local/lib/python3.7/site-packages/kombu/asynchronous/hub.py", line 364, in create_loop
cb(*cbargs)
File "/usr/local/lib/python3.7/site-packages/kombu/transport/redis.py", line 1088, in on_readable
self.cycle.on_readable(fileno)
File "/usr/local/lib/python3.7/site-packages/kombu/transport/redis.py", line 359, in on_readable
chan.handlers[type]()
File "/usr/local/lib/python3.7/site-packages/kombu/transport/redis.py", line 693, in _receive
ret.append(self._receive_one(c))
File "/usr/local/lib/python3.7/site-packages/kombu/transport/redis.py", line 703, in _receive_one
response = c.parse_response()
File "/usr/local/lib/python3.7/site-packages/redis/client.py", line 3453, in parse_response
response = self._execute(conn, conn.read_response)
File "/usr/local/lib/python3.7/site-packages/redis/client.py", line 3427, in _execute
return command(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/redis/connection.py", line 734, in read_response
response = self._parser.read_response()
File "/usr/local/lib/python3.7/site-packages/redis/connection.py", line 316, in read_response
response = self._buffer.readline()
File "/usr/local/lib/python3.7/site-packages/redis/connection.py", line 248, in readline
self._read_from_socket()
File "/usr/local/lib/python3.7/site-packages/redis/connection.py", line 193, in _read_from_socket
raise ConnectionError(SERVER_CLOSED_CONNECTION_ERROR)
redis.exceptions.ConnectionError: Connection closed by server.
[2020-03-24 16:30:23,911: INFO/MainProcess] Connected to redis://redis:11535//





