Регистрация на облачном сервере ошибка socket connection error

 

Добрый день.

Тут на форуме есть похожая тема:  

https://dev.1c-bitrix.ru/support/forum/forum6/topic97363/

но не нашел на решения.

Суть проблемы: установил систему оплаты яндекс касса (от 3), все прописал правильно

http://prntscr.com/r6r1dt
http://prntscr.com/r6r1oy

об этом мне даже сказала служба поддержки яндекс кассы

Система оплаты видна на сайта при оформлении заказа, ее можно выбрать и оформить с ней заказ, но после на странице где есть переход на саму оплату и при попытки перейти к оплате  (  /personal/order/payment/?ORDER_ID=50&PAYMENT_ID=50/1 )  — происходит ошибка    Socket connection error   (только эта строка и выходит,  на этой странице просто вызов bitrix:sale.order.payment, он и вызывает эту ошибку)

сайт на https, при проверке в админке битрикса ошибок сокетов нету

я попробовал найти в коде эту ошибку, и обнаружил следующее
если запустить такой код:

Код 
<?
require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php");
$APPLICATION->SetTitle("test");

use \Bitrix\Main\Application,
    \Bitrix\Main\Web\Uri,
    \Bitrix\Main\Web\HttpClient;

function PRX($e) {
    echo "<pre>".print_r($e,true)."</pre>";
}

// опции по умолчанию:
$options = array(
    "redirect" => true, // true, если нужно выполнять редиректы
    "redirectMax" => 5, // Максимальное количество редиректов
    "waitResponse" => true, // true - ждать ответа, false - отключаться после запроса
    "socketTimeout" => 30, // Таймаут соединения, сек
    "streamTimeout" => 60, // Таймаут чтения ответа, сек, 0 - без таймаута
    "version" => HttpClient::HTTP_1_0, // версия HTTP (HttpClient::HTTP_1_0 или HttpClient::HTTP_1_1)
    "proxyHost" => "", // адрес
    "proxyPort" => "", // порт
    "proxyUser" => "", // имя
    "proxyPassword" => "", // пароль
    "compress" => false, // true - принимать gzip (Accept-Encoding: gzip)
    "charset" => "", // Кодировка тела для POST и PUT
    "disableSslVerification" => false, // true - отключить проверку ssl (с 15.5.9)
);
$httpClient = new HttpClient($options);
$params = array( 'a'=> 1 );    


$url = 'https://winkyou.ru'; 
$postData = json_encode($params);
$response = $httpClient->post($url, $postData);
if ($response === false){
    $errors = $httpClient->getError();
    PRX( $errors );
} else {
    PRX("OK");
}

$url = 'https://payment.yandex.net/api/v3/payments';
echo $url;
$postData = json_encode($params);
$response = $httpClient->post($url, $postData);
if ($response === false){
    $errors = $httpClient->getError();
    PRX( $errors );
}else {
    PRX("OK");
}

$url = 'https://myeggershop.ru';
echo $url;
$postData = json_encode($params);
$response = $httpClient->post($url, $postData);
if ($response === false){
    $errors = $httpClient->getError();
    PRX( $errors );
}else {
    PRX("OK");
}

( по сути такие же запросы и компонент кассы юзает )
то этот код выводит следующее:

т.е. проблема именно когда идет обращение к яндекс кассе, при этом такая же ошибка возникает, если обратиться например по несуществующему адресу например:

https://asdfasdfa.ru https://payment.yandex.net/api/v3/payments

 — этот адрес юзается яндекс кассой, однако выдает ошибку, поддержка яндекса пишет — что проблема не у них (наш домен не забанен), хостер тоже пишет, что де мол https в норме.

редакция битрикса:  1С-Битрикс: Управление сайтом 20.0.450. © Битрикс, 2016

еще попробовал установить модуль

Мибок: Платежный модуль для сайта

(mibok.pay)   — тоже для яндекс кассы, но эффект тот же самый.

В чем может быть проблема?

поддержка яндекс касса послала к поддержке битрикса, поддержка битрикса — говорит мол очень плотный график, в течении 4 дней ответят

Источник

Битрикс настройка SSL, ошибка работы с сокетами

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

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

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

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 : Подробности ошибки указаны в журнале проверки системы.

Также если обратится к сайту в консоли через 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

источник

Ошибка проверки сайта Работа с сокетами — 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): FailConnection to 123.456.789.123:80Socket error : Connection refused

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

В своем локальном файле c:\Windows\System32\drivers\etc\hosts я добавил запись:80.66.94.230 portal.localdom

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

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

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

Соответственно, после того, как убираем из .htaccess в папке «..» AuthName «Private zone»AuthType BasicAuthUserFile .htpasswdrequire 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

Когда не указана кодировка 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 : php_network_getaddresses: getaddrinfo failed: Name or service not known

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

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

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

источник

Bitrix. Исправляем ошибку «Работа с сокетами — Ошибка! Не работает»

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

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

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

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

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

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

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

источник

Источник

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

Работа с сокетами (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

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

Источник

Most often, we come across the CloudHSM “Daemon socket connection error” when we try to connect to the key management utility (KMU) command-line tool or the AWS CloudHSM client

Here, at Bobcares, we assist our customers with several AWS queries as part of our AWS Support Services.

Today, let us see how we can resolve this error.

CloudHSM “Daemon socket connection error”

Generally, we come across this error if:

The client’s daemon is stopped.

-or-

The client configuration file doesn’t contain the IP address of an active and reachable HSM in the cluster.

  • Troubleshooting lost connections to the cluster

We provide the IP address of the first HSM in the cluster when we configure the AWS CloudHSM client. The configuration file save it for the AWS CloudHSM client.

When the client starts, it tries to connect to this IP address. If it can’t, we might see errors like the following:

LIQUIDSECURITY: Daemon socket connection error
LIQUIDSECURITY: Invalid Operation

To resolve them, we need to update the configuration file with the IP address of an active, reachable HSM in the cluster.

To do so, our Support Techs recommend one of the following ways:

  1. View the HSMs tab on the cluster details page in the AWS CloudHSM console
  2. Use the AWS Command Line Interface (AWS CLI) to issue the describe-clusters command.

We need this IP address in a subsequent step.

Then we use the following command to stop the client:

Amazon Linux:

$ sudo stop cloudhsm-client

Amazon Linux 2, CentOS 7 & 8, RHEL 7 & 8, Ubuntu 16.04 LTS, Ubuntu 18.04 LTS:

$ sudo service cloudhsm-client stop

After that, to update the client’s configuration file, we provide the IP address that we found above:

$ sudo /opt/cloudhsm/bin/configure -a <IP address>

Finally, to start the client, we run:

Amazon Linux:

$ sudo start cloudhsm-client

Amazon Linux 2, CentOS 7 & 8, RHEL 7 & 8, Ubuntu 16.04 LTS, Ubuntu 18.04 LTS:

$ sudo service cloudhsm-client start

[Stuck in between? We are here for you]

Conclusion

In short, we saw how our Support Techs fix the AWS error for our customers.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

Источник

— На основе оценок
3
человек

При прохождении теста настроек Битрикса часто вылазит ошибка Socket error [111]: Connection refused, причин может быть несколько. Чтобы понять в чем именно причина, можно посмотреть логи проверки, но лучше в командной строке ввести аналогичную команду (по сути, битрикс ее выполняет). 


  	curl https://ваш_сайт
	#Если сайт через SSL работает
  	curl https://ваш_сайт:443

Битрикс не видит своего домена по URL

Если наблюдается такая ошибка (ее можно посмотреть в логах проверки битрикса), то необходимо в /etc/hosts прописать 127.0.0.1 ваш_сайт и ваш.IP ваш_сайт (все с новой строчки).

Ошибка с SSL.
curl: (60) server certificate verification failed.

Еще один распространенный вариант — неправильная установка SSL сертификата. Даже если у вас сайт открывается с зеленой полоской, нужно проверить еще раз тут — https://www.sslshopper.com/ssl-checker.html или в командной строке ввести запрос на сайт через curl.

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

curl: (7) Failed connect to crm.domain.ru:443;
Connection refused

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


  nmap -p80,443 crm.domain.ru

#если выдаст такое, значит порты закрыты
Starting Nmap 6.40 ( http://nmap.org ) at 2017-08-29 18:07 MSK
Nmap scan report for crm.capitalest.ru (192.2.2.2)
Host is up (0.00043s latency).
PORT    STATE  SERVICE
80/tcp  closed http
443/tcp closed https

Данная проблема лечится, как и писал выше, добавлением в /etc/hosts строчки 127.0.0.1 ваш_сайт и ваш.IP ваш_сайт (все с новой строчки).

Вас могут заинтересовать следующие услуги

Источник

Понравилась статья? Поделить с друзьями:

Интересное по теме:

  • Регистрация на облачном сервере ошибка aborted
  • Регистратор каркам ошибка карты памяти
  • Регистратор дахуа ошибка входа
  • Регистрация компоненты comcntr dll ошибка 0х80070005
  • Регистратор выдает ошибка карты памяти

    • Добавить комментарий

    ;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: