Каковы могут быть причины отказа отказались?

Могло быть много причин, но наиболее распространенными являются:

1. Порт не открыт на конечной машине.

2. Порт открыт на конечной машине, но его отставание от ожидающих соединений заполнено.

3. Брандмауэр между клиентом и сервером блокирует доступ (также проверяет локальные брандмауэры).

После проверки брандмауэров и открытия порта используйте telnet для подключения к ip / port для проверки возможности подключения. Это устраняет любые потенциальные проблемы из вашего приложения.

Ошибка означает, что ОС прослушивающего сокета распознала запрос входящего соединения, но решила отклонить его.

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

Существует еще одна причина, о которой еще не упоминалось, – прослушивающий порт фактически открыт и активно используется, но его отставание запросов на входящие запросы в очередь достигло максимума, поэтому нет места для запроса входящего соединения, который должен быть поставлен в очередь на этом момент. Код сервера еще не вызвал accept (), чтобы завершить очистку доступных слотов для новых элементов очереди.

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

Если вы попытаетесь открыть TCP-соединение с другим хостом и увидите сообщение об ошибке «Соединение отказано», это означает, что

1. Вы отправили TCP SYN-пакет другому хосту.
2. Затем вы получили пакет TCP RST в ответ.

RST бит в TCP-пакете, который указывает, что соединение должно быть сброшено. Обычно это означает, что другой хост получил попытку подключения и активно отказывается от вашего TCP-соединения, но иногда промежуточный брандмауэр может блокировать ваш TCP SYN-пакет и отправлять вам TCP RST.

См. https://tools.ietf.org/html/rfc793 стр. 69:

СИН-ПОЛУЧЕННОЕ СОСТОЯНИЕ

  If the RST bit is set If this connection was initiated with a passive OPEN (ie, came from the LISTEN state), then return this connection to LISTEN state and return. The user need not be informed. If this connection was initiated with an active OPEN (ie, came from SYN-SENT state) then the connection was refused, signal the user "connection refused". In either case, all segments on the retransmission queue should be removed. And in the active OPEN case, enter the CLOSED state and delete the TCB, and return. 

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

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

Общей ошибкой не является указание номера порта при привязке или подключении в сетевом порядке байтов …

Проверьте на стороне сервера, что он прослушивает порт 2080. Сначала попробуйте подтвердить его на серверной машине, отправив telnet на этот порт:

telnet localhost 2080

Если он слушает, он может ответить.

Хотя, похоже, это не так для вашей ситуации, иногда отказ в соединении может также указывать на наличие конфликта IP-адресов в вашей сети. Вы можете искать возможные конфликты ip, запустив:

  arp-scan -I eth0 -l | grep  

а также

 arping  

Этот вопрос AskUbuntu содержит дополнительную информацию.

1. Проверьте состояние своего сервера.

2. Проверьте состояние порта.

Например, 3306 netstat -nupl|grep 3306 .

3. Проверьте свои брандмауэры. Например, добавьте 3306

 vim /etc/sysconfig/iptables # add -A INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT 

С точки зрения брандмауэра Checkpoint вы увидите сообщение от брандмауэра, если на самом деле выбрать «Отклонить как действие», тем самым подвергая предполагаемого злоумышленника присутствие брандмауэра перед сервером. Брандмауэр отключит все соединения, которые не соответствуют политике. Соединение отказалось почти всегда от сервера

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

Chrome => Настройки => Изменить настройки прокси-сервера => Настройки локальной сети => проверить прокси-сервер обхода для локальных адресов.

В Ubuntu попробуйте sudo ufw allow разрешить брандмауэру доступ к вашему серверу и db.

У меня было то же сообщение с совершенно другой причиной: wsock32.dll не был найден. ::socket(PF_INET, SOCK_STREAM, 0); вызов продолжал возвращать INVALID_SOCKET но причина в том, что dll winsock не была загружена.

В итоге я запустил монитор процессов Sysinternals и заметил, что он искал dll «везде», но не нашел его.

Молчаливые неудачи – это здорово!