Не удалось подключиться к сокету. Отказано в подключении

Обновлено: 30.06.2024

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

Недавно я установил сервер vnc на виртуальную машину Centos8. Я выполнил все шаги настройки, которые находятся в этом файле (кстати, тот, который vnc рекомендует использовать, так как я думаю, что vnc был обновлен, и метод настройки не такой, как раньше). После этого сервер работает без проблем. (видимо) Проблема возникает, когда я хочу подключиться с другой виртуальной машины (Fedora), сервер отклоняет подключение и выдает следующую ошибку:

На сервере я выполняю следующую инструкцию

Я проконсультировался на некоторых форумах, и там упоминалось, что это проблема брандмауэра, который не пропускает связь. Поэтому отключите брандмауэр и Selinux на обеих виртуальных машинах, однако проблема не исчезнет. Я знаю, что сервер работает правильно, потому что я получаю следующий вывод.

Мне также назначены эти порты, которые говорят мне, что сервер прослушивает

Возможно, это похоже на дубликат вопроса из следующего форума. И действительно так, только не могу найти отношение, так как vnc обновлен и конфигурация не та (т.е. для запуска сервера я уже не могу поставить команду "vncserver"), и предполагаю что решение будет другим

в файле, на который вы ссылаетесь, я вижу в разделе «Ограничения», что вы не можете подключиться, когда пользователь уже вошел в систему, поэтому я подозреваю, что попытка локального подключения никогда не сработает, поэтому попробуйте извне.< /p>

1 Ответ 1

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

Я не уверен, какой vnc вы установили, но с tigervnc я сделал следующее:

На данный момент сервер vnc прослушивает порт 5901, соответствующий display:1 для пользователя, user1 в моем случае.

Вам потребуется установить программу просмотра vnc на другую виртуальную машину или даже на вашу локальную систему.

Если вы раскомментировали localhost в файле vncserver-config-defaults, то запустите туннель с вашего локального компьютера ssh -L 5901:localhost:5901 user@server (выход из этого соединения закроет туннель, если вы всегда хотите, чтобы он был открыт , ssh -N -f -L 5901:localhost:5901 пользователь@сервер). Откройте другое окно на локальном компьютере, чтобы запустить vncviewer из командной строки.

Запустите vncviewer и введите IP:порт в поле сервера, в моем случае 192.168.122.40:5901, и нажмите Подключить . Если бы я запустил туннель, сервер был бы localhost:5901 .

При запросе пароля введите пароль, который вы указали для vncpasswd. Это устанавливает соединение.

На данный момент ваш сеанс gnome запущен и доступен для просмотра. Возможно, вам придется нажать клавишу Enter/Return, чтобы запросить учетные данные.

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

У меня есть сокет-приложение, написанное на языке C, и я выполняю его в Linux, но когда я запускаю сервер (./server), я получаю следующую ошибку:

не удалось установить соединение, в соединении отказано.

Вот код:

Ваш код у меня работает без изменений. Запускаете ли вы и клиент, и сервер в одной системе (и запускали ли вы сервер перед запуском клиента)? Запуск на разных системах не будет работать, поскольку вы явно указали 127.0.0.1 (т. е. локальный хост) в качестве цели.

Моей основной системой является Mac OS, но я установил Ubuntu на виртуальную машину, так что не могли бы вы мне помочь, какую цель мне указать? спасибо

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

Понимаете, я запускаю оба внутри UBUNTU Vm, но даже тогда я получаю отказ в подключении, я даже не могу запустить сервер. это как-то связано с портом, который я использую?8080?

1 Ответ 1

Ошибка "отказ в соединении" означает, что вы пытаетесь подключиться к IP:порту сервера, который:

не открыт для прослушивания

слишком много ожидающих клиентских подключений в невыполненной работе

заблокирован брандмауэром/маршрутизатором/антивирусом.

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

Поскольку ваш клиент пытается подключиться к 127.0.0.1 , клиент и сервер ДОЛЖНЫ работать на одном компьютере. Вы не сможете подключаться через границы компьютеров, включая границы виртуальных машин между хост-системами и клиентскими системами.

При этом я вижу ряд ошибок в вашем коде, но ни одна из них не вызывает ошибку подключения.

socket() возвращает -1 при ошибке, а не 0.

Вы не можете установить несколько параметров сокета одновременно с помощью setsockopt() , вы должны установить их по отдельности с помощью отдельных вызовов setsockopt() .

вы заполняете serv_addr символами '0' вместо 0 байтов.

С обеих сторон вы не выполняете никакой обработки ошибок в send() . Но что более важно, вы не включаете нулевой терминатор сообщения в отправку, поэтому одноранговый узел не может узнать, когда достигнут конец сообщения. TCP — это потоковый транспорт, поэтому вам нужно кадрировать ваши сообщения в вашем протоколе данных. Отправьте длину сообщения перед отправкой самого сообщения. Или отправьте уникальный терминатор после сообщения. Затем одноранговый узел может прочитать длину перед чтением сообщения или прочитать до тех пор, пока не будет достигнут терминатор.

И send(), и read() возвращают количество фактически отправленных/полученных байтов, что может быть (и часто бывает) меньше байтов, чем запрошено. Вам нужно вызвать их в цикле, чтобы убедиться, что вы отправляете/получаете все, что ожидаете.

Кроме того, read() не возвращает строку с завершающим нулем, но при использовании printf() она ожидается. Проверьте valread на наличие ошибок, и только если read() прошла успешно, передайте valread в printf() в качестве входного параметра, чтобы он знал, сколько данных на самом деле находится в буфере:

Нам нужна дополнительная информация о вашей настройке. Самый быстрый способ решить вашу проблему — воспользоваться функцией поиска по форуму или гуглом. Мы ответили на этот вопрос уже 1000 раз.

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

Именно после обновления у меня начались проблемы со входом.

У меня не установлены дополнения.

Я также пробовал запустить apt-get install --reinstall openmediavault
но это тоже не помогло.

Любой совет будет оценен по почте.

Что получается

Спасибо за ответ, но бог знает, что случилось с моей установкой.

Повреждена корневая файловая система?

Похоже, это не так, к тому же, когда я запускаю omv-engined -f -d , openmediavault работает как надо, я просто не могу закрыть его в командной строке.

статус systemctl openmediavault-engined

У меня та же проблема, и я получаю такое же сообщение об ошибке.

Когда я запускаю "omv-engined -f -d", я могу войти в систему, и все работает правильно. В любом случае вывод "omv-engined -f -d" выглядит следующим образом (обратите внимание, что я остановил это примерно через 1 минуту после входа в систему).
Вывод "omv-engined -f -d"

Я просто обновил ядро до версии 3.2.96, и теперь оно работает как положено.

Просто чтобы другие не следовали этому совету:

Скорее всего, ядро не было исправлением.

Возможно, перезагрузка или что-то еще.

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

Не удалось найти модуль openmediavault.service.

Загружено: замаскировано (Причина: модуль openmediavault-engined.service замаскирован.)

Активный: неактивный (мертвый)

ii openmediavault 5.6.0-1 all openmediavault — открытое сетевое решение для хранения данных

ii openmediavault-keyring 1.0 все ключи архива GnuPG архива OpenMediaVault

Когда я запускаю omv-engined -f -d, он работает.

Также переустановил пакет openmediavault, ничего не решилось.

Запустите systemctl unmask openmediavault-engined.service и systemctl перезапустите openmediavault-engined.service, чтобы он снова заработал.

Я установил kali linux с помощью wsl2. Затем я следовал этому руководству, чтобы установить win-kex. До сегодняшнего утра все работало нормально.

Теперь, если я попытаюсь запустить kex, я получу следующую ошибку:

Если я запускаю kex stop или kex kill, я получаю следующий вывод:

Я погуглил, чтобы найти различные способы исправить это. В большинстве статей/обсуждений предлагаются следующие способы:

Установите dbus-x11
- Проблема уже установлена
Выполните следующую команду:

В третьем способе, если я сделаю все это, а затем запущу vncserver, запустив:

И если я запускаю kex после этого, я получаю сообщение об ошибке "Нет соответствующего типа безопасности"

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

выполнить sudo su (все команды должны выполняться пользователем root) ;
удалите символическую ссылку в /tmp/.X11-unix (просто выполните команду rm /tmp/.X11-unix);
запустите vncserver (теперь он сможет создать сервер);
Запустите kex, и все должно заработать.

Ответы

У меня нет ответа. Я просто хотел сказать, что это делает то же самое для меня

mzfr 15 марта 2021 г.

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

В основном установите xfce4 и xfce4-goodies и kali-desktop-xfce . Также установите vcxsrv (либо скачайте с Sourceforge, либо используйте choco). vcxsrv будет установлен на вашем компьютере с Windows, а не внутри виртуальной машины kali.

Теперь выполните следующую команду в терминале kali:

если wsl1, экспортировать DISPLAY=:0.0
если wsl2, то экспортируйте DISPLAY=$(grep -m 1 nameserver /etc/resolv.conf | awk ''):0.0

После того, как все это будет сделано, запустите xfce4-session , если все сделано правильно, вы увидите графический интерфейс kali.

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

выполнить sudo su (все команды должны выполняться пользователем root) ;
удалите символическую ссылку в /tmp/.X11-unix (просто выполните команду rm /tmp/.X11-unix);
запустите vncserver (теперь он сможет создать сервер);
Запустите kex, и все должно заработать.

Отмечено как ответ

mzfr 15 июля 2021 г.

@afonsofrancof Я удалил свой kali wsl, поэтому просто отмечу ваш ответ как правильный.

Кроме того, я сделал то, что предложил в ответе выше. Использование xfce4 было намного лучше, потому что я смог использовать приложение внутри kali, выскочившее, как любое приложение в обычной настройке. Это помогло легко делать вещи с помощью alt + tab. Я даже дал свой OSCP с этой настройкой.

CodeBunny09, 6 августа 2021 г.

по-прежнему не работает

Выбор сделан 31 августа 2021 г.

Добавив решение, найденное @afonsofrancof,
мне удалось воссоздать это. Следуя журналам vncserver, в которых говорится:

Я не проводил тщательного тестирования, но считаю, что проблема заключается в том, как стандартный пользователь и связанные с ним разрешения создаются во время первоначальной настройки через WSL2. Насколько я могу судить, единственный способ запустить среду KeX прямо сейчас — это сделать это как root. Однако это создает еще одну потенциальную проблему: логин среды KeX GUI будет root.

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

Ошибка подключения к серверу KeX.
Пожалуйста, попробуйте "kex start", чтобы запустить службу.
Если сервер не запускается, попробуйте "kex kill" или перезапустите сеанс WSL2 и повторите попытку.

Я рекомендую опубликовать это обсуждение в качестве отчета об ошибке сообществу Kali и/или соответствующим разработчикам KeX.

абсолютно 15 октября 2021 г.

Полагаю, вы правы. Мой kex работал очень хорошо, когда я обновил систему Windows до 11, ядро wsl или что-то еще.
Эта ошибка все еще беспокоит меня, потому что учетная запись root не может хорошо поддерживать Gui, многие программы не разрешают вход в систему с правами root.
Кстати, вы или кто-то еще сообщал об этой ошибке?

nannerpusser 21 декабря 2021 г.

Ошибка подключения к серверу KeX.
Пожалуйста, попробуйте "kex start", чтобы запустить службу.
Если сервер не запускается, попробуйте "kex kill" или перезапустите сеанс WSL2 и повторите попытку.

Отсталый, только что обновил Win 11 и, ну, Windows собирается Windows/сломать все. Переустановил ли WSL 2 Kali и закрыл начальное диалоговое окно нового пользователя до завершения, так как мне нужен root-доступ только к двум вещам. Работает нормально, но VNC не работает, и я получаю те же ошибки Refused. Это решение отлично сработало для меня без единой ошибки или события.

Привет, просто для информации. У меня была та же проблема, но мне помогло то, что я проверил свою версию WSL и увидел, что использовал
версию 1. Поэтому я обновился до версии 2, и теперь она работает отлично!

КириТоваха, 1 октября 2021 г.

корневой или не root?

Мартин Оберхаузер, 1 октября 2021 г.

Вы должны установить версию WSL в Windows виртуальной машины.
например. wsl --set-версия кали 2

Я установил kali linux с помощью wsl2. Затем я следовал этому руководству, чтобы установить win-kex. До сегодняшнего утра все работало нормально.

Теперь, если я пытаюсь запустить kex, я получаю следующую ошибку:

Если я запускаю kex stop или kex kill, я получаю следующий вывод:

Установите dbus-x11
- Проблема уже установлена
Выполните следующую команду:

И если я запускаю kex после этого, я получаю сообщение об ошибке "Нет соответствующего типа безопасности"

просто используйте «sudo kex» вместо «kex», кажется, работает хорошо

Сушант-Падха, 2 ноября 2021 г.

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

У меня есть аналогичная проблема в моем win 11,
хотя решение, предоставленное @afonsofrancof, работает, все еще есть некоторые проблемы,
команда kex выдает «Ошибка подключения к серверу KeX».
а vncserver выдает "Ошибка сегментации"
команда sudo kex теперь работает отлично, но я бы предпочел не использовать root из соображений безопасности

Я решил проблему с помощью "kex --esm --ip -sound", который хорошо работает с учетной записью без полномочий root.

gwd999 21 января 2022 г.

Мне очень нравится это решение, у меня также возникли те же проблемы из ниоткуда, или из-за перехода на WIN11, я совершенно забыл о параметре RDP. Так что пока остановимся на этом - спасибо, что напомнили мне о esm
Думаю, я добавлю хороший псевдоним в мой .zshrc и буду ждать обновлений по этому вопросу.

Сообщите мне об этих работах?

Правильно работает на kali linux rootless на Android.

Если ваша ошибка все еще существует, попробуйте эти

cd ~/.vnc/
rm -rf *.log *.pid
cd /

rm -rf /tmp/.X* /tmp/.xfsm* /tmp/.l2s* /tmp/.ICE-unix
vncserver -kill :*
vncserver -depth 24 -геометрия 1920x1080:1

//Удаление файлов pid журнала в каталоге ~/.vnc
//Удаление некоторых файлов и каталогов в /tmp

Я решил с.

Запустите команду ps, если есть какой-либо процесс, ссылающийся на kex, завершите ее

sudo rm -rf /tmp/.X* (если существует '/tmp/.X11-unix')
sudo mkdir /tmp/.X11-unix
sudo chmod 1777 /tmp/. X11-unix
sudo chown root /tmp/.X11-unix/
vncserver -localhost no

sudo nano ~/.vnc/xstartup

sudo chmod 777 ~/.vnc/xstartup
vncserver -localhost нет
kex --win -s

Хорошо, пришлось немного покопаться, но с этой ошибкой многое произошло.

Чтобы было ясно, проблема в том виде, как она определена, заключается в невозможности запуска kex от имени НЕ-АДМИНИСТРАТОРА.
запуск с помощью sudo или root НЕ является решением. Ошибка возникает при попытке запустить kex/xfce без прав администратора.

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

Я испробовал все, что было в этих предложениях, и ничего не помогло. На самом деле некоторые сделали еще хуже.

Здесь работает сумасшедшее взаимодействие компонентов xfce. DBUS, ICE, PolicyKit, TigerVNC и т. д. и т. д. и т. д.

Я заметил, что DBUS ничего обо мне не знает. В файле .xsessionerrors в ~ я видел повторяющиеся сообщения, похожие на

"dbus-update-activation-environment: systemd --user не найден, игнорируется аргумент --systemd"

Отчасти это не относится к делу, так как wsl не использует systemd, но часть сообщения "пользователь не найден" очень интересна.

Мне нужно было сообщить ему, как меня найти. и что мы не находимся в среде инициализации systemd.

Проверил журналы еще раз, и я получил сеанс dbus, который был в процессе, поэтому я перешел к следующей ошибке в списке.

"_IceTransmkdir: владельцем /tmp/.ICE-unix должен быть root"
Поэтому я проверил полную установку на настоящую виртуальную машину Ubuntu и заметил, что файл принадлежит root:root и режим был 1777

Поэтому я воссоздал его с соответствующими разрешениями

После этого ошибка ICE исчезла из журнала ~.xsessionerrors, но я видел

"(xfwm4:7394): Gtk-WARNING **: 18:06:13.137: невозможно открыть дисплей: wayland-0

(xfce4-panel:7411): libxfce4ui-WARNING **: 18:06:14.261: Ошибка ввода-вывода ICE"

Порыскав в поисках каталога среды выполнения ICE, я обнаружил там файл блокировки и pid для wayland 0, поэтому удалил их.

cd /mnt/wslg/runtime-dir
rm -rf wayland*

Затем я запустил kex --win -s и бум. У меня стабильный рабочий стол.

Я написал скрипт, чтобы это исправить. вы установите его как исполняемый файл и запустите его sudo. Не как корень. Учетная запись без прав администратора.. sudo.

Затем просто запустите "kex --win -s" в обычном режиме. Никаких небезопасных параметров локального хоста, никакой геометрии в vncserver. Просто запустите его так, как он предназначен для работы.

Надеюсь, это поможет.

Kali-win-kex обновлен до версии 3.0 и исправляет большинство проблем. Теперь также совместим с WSLg в Windows 11.

SK-Infidel, 7 февраля 2022 г.

Не совсем так. Все это время я работал с wslg/2, и у меня все те же проблемы.

звукоподражание, 7 февраля 2022 г.

@SK-Infidel Я имею в виду, что распространенные ошибки, такие как отказ в подключении OP, должны быть устранены при новой установке kali с win-kex 3.0. Спасибо за сценарий и вообще, .xsessionerrors показывает эти ошибки, но ни одна из них не должна влиять на конечного пользователя при запуске kex.

Кстати, в сценарии rm -rf /tmp/.X10-unix/* не должно быть rm -rf /tmp/.X11-unix/* ?

абсолютно 8 февраля 2022 г.

Я пробовал самую новую версию. Теперь он хорошо работает в оконном режиме, но в бесшовном режиме я столкнулся с новой проблемой.

И журнал:

[xkb] Запуск '"\wsl.localhost\kali-linux\usr\lib\win-kex\VcXsrv\xkbcomp" -w 1 "-R\wsl.localhost\kali-linux\usr\lib\win -kex\VcXsrv\xkbdata" -xkm "C:\Users\Absolute OB\AppData\Local\Temp\xkb_a15144" -em1 "Компилятор раскладки клавиатуры XKEYBOARD (xkbcomp) сообщает:" -emp "> " -eml "Ошибки от xkbcomp не являются фатальными для X-сервера" "C:\Users\Absolute OB\AppData\Local\Temp\server-3.xkm"' не удалось: неверная функция
(EE) Ошибка компиляции раскладки (сервер-3) при выполнении '"\wsl.localhost\kali-linux\usr\lib\win-kex\VcXsrv\xkbcomp" -w 1 "-R\wsl.localhost\kali-linux\usr\lib\win-kex\VcXsrv\xkbdata" -xkm "C:\Users\Absolute OB\AppData\Local\Temp\xkb_a15144" -em1 "Компилятор раскладки клавиатуры XKEYBOARD (xkbcomp) сообщает:" -emp "> " -eml "Ошибки от xkbcomp не являются фатальными для X-сервера " "C:\Users\Absolute OB\AppData\Local\Temp\server-3.xkm"'
(EE) XKB: не удалось скомпилировать раскладку
(EE) XKB: не удалось загрузить раскладку . Вместо этого загрузка раскладки по умолчанию.
[xkb] Запуск '"\wsl.localhost\kali-linux\usr\lib\win-kex\VcXsrv\xkbcomp" -w 1 "-R\wsl.localhost\kali-linux\usr\lib\ win-kex\VcXsrv\xkbdata" -xkm "C:\Users\Absolute OB\AppData\Local\Temp\xkb_a15144" -em1 "Компилятор раскладки клавиатуры XKEYBOARD (xkbcomp) сообщает:" -emp "> " -eml "Ошибки из xkbcomp не является фатальным для X-сервера" "C:\Users\Absolute OB\AppData\Local\Temp\server-3.xkm"' не удалось: неправильная функция
(EE) Ошибка компиляции раскладки (сервер-3) выполнение '"\wsl.localhost\kali-linux\usr\lib\win-kex\VcXsrv\xkbcomp" -w 1 "-R\wsl.localhost\kali-linux\usr\lib\win-kex\VcXsrv\xkbdata " -xkm "C:\Users\Absolute OB\AppData\Local\Temp\xkb_a15144" -em1 "Компилятор раскладки клавиатуры XKEYBOARD (xkbcomp) сообщает:" -emp "> " -eml "Ошибки xkbcomp не являются фатальными для X server" "C:\Users\Absolute OB\AppData\Local\Temp\server-3.xkm"'
(EE) XKB: не удалось скомпилировать раскладку
XKB: не удалось скомпилировать раскладку
Инициализация клавиатуры не удалась. Это может быть отсутствие или неправильная настройка xkeyboard-config.
(EE)
Неустранимая ошибка сервера:
(EE) Не удалось активировать виртуальную основную клавиатуру: 2(EE)
(EE) Сервер завершен с ошибкой (1). Закрытие файла журнала.

Неспособность отправить почту в нужное время может даже привести к потере важной деловой возможности.

Очень обидно! мы знаем.

А когда сообщения об ошибках содержат технический жаргон, это еще больше раздражает.

Одной из таких ошибок является «не удалось подключиться к сокету, время ожидания подключения истекло».

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

Сегодня мы обсудим 4 основные причины этой ошибки и способы ее устранения.

Не удалось подключиться к сокету: время ожидания подключения истекло. Что это значит?

Проще говоря, сокет — это конечная точка связи.

При обычной доставке почты сокет клиента подключается к сокету прослушивающего сервера. И общение происходит после успешного подключения.

‘failed to connect socket connection timeed out’ означает, что соединение с почтовым сервером не установлено или почтовый сервер недоступен.

Не удалось подключиться к сокету: время ожидания подключения истекло – причины и способы устранения

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

1) Неверный хост и порт SMTP

Пользователи должны ввести данные почтового сервера в своем почтовом приложении.

Иногда к этой ошибке может привести опечатка в имени хоста или неактивный почтовый сервер.

Аналогично порт SMTP по умолчанию — 25, но некоторые поставщики услуг электронной почты используют настраиваемые порты, например 587, для уменьшения количества спама.

Кроме того, некоторые почтовые серверы разрешают отправлять электронные письма только через SSL-порт 465.

Таким образом, неверный хост SMTP или порт в настройках SMTP приложения электронной почты может привести к ошибкам доставки электронной почты.

Решение

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

Кроме того, чтобы определить правильный порт SMTP и его подключение, мы используем приведенную ниже команду.

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

[Проблемы с электронной почтой и вы не можете определить, что пошло не так? Не беспокойтесь, наши инженеры службы поддержки могут вам помочь.]

2) Ограничения брандмауэра сервера

Брандмауэры играют решающую роль в обеспечении безопасности сервера.Эти брандмауэры иногда могут блокировать доступ к некоторым IP-адресам или диапазонам IP-адресов из-за ненормального поведения.

Например, некоторые серверы блокируют доступ с IP-адреса, если количество подключений с этого IP-адреса превышает пороговое значение.

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

Решение

Если IP-адрес заблокирован брандмауэром сервера, мы немедленно удаляем его и восстанавливаем подключение к электронной почте. После этого мы определяем причину блокировки брандмауэром и информируем заказчика.

Кроме того, мы вносим IP-адрес сервера в белый список на определенный период времени после подтверждения законности запроса.

3) Блокировка портов провайдера

Порт SMTP по умолчанию — 25. Но большинство интернет-провайдеров блокируют этот порт, чтобы ограничить спам и злоупотребления.

И это еще одна распространенная причина ошибки.

Решение

Наши специалисты службы поддержки проверяют результаты traceroute от ПК пользователя до почтового сервера.

Это дает представление о проблемах с сетевым подключением в любой из промежуточных сетей между почтовым сервером и ПК пользователя.

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

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

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

4) Проблемы с брандмауэром ПК

Это может происходить время от времени.

Антивирусное программное обеспечение или сторонние брандмауэры на компьютере пользователя иногда могут блокировать подключения к определенным IP-адресам, включая IP-адрес сервера.

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

Решение

Чтобы проверить проблемы с подключением ПК пользователя к почтовому серверу, мы получаем результаты telnet от ПК пользователя к порту почтового сервера.

Таким образом мы определяем, может ли пользователь подключиться к SMTP-порту почтового сервера.

В случае сбоя подключения мы предлагаем клиентам отключить локальный брандмауэр и антивирус и попробовать.

Заключение

Короче говоря, «не удалось подключиться к сокету, ошибка тайм-аута подключения» может возникать из-за неправильных настроек хоста или порта SMTP, блокировок брандмауэра интернет-провайдера и других причин. Сегодня мы обсудили 4 основные причины этой ошибки и то, как наши инженеры службы поддержки их устраняют.

Читайте также: